Dan: Not sure I understand Motivation since it's saying devs will use [3rd party?] cookies but in the intro it says 3rd party cookies are being deprecated.

Yves: they imply that there is a mechanism to request accesss to stored cookies... To me if you have a shared storage like that then it's quite dangerous.

Dan: reviews what we said about storage access api Let's take it as read that Storage Access doesn't open the door to reinventing 3p cookies.

Yves: it's already there in the previous proposal... Anne / webkit has an issue with this one though https://github.com/WebKit/standards-positions/issues/262#issuecomment-1743104792

Dan: we could ask how they are going to respond to Anne's comment.

Yves: they mean using cookies as a storage mechanism that they can access through the storage api - and those can be 3rd parties... they just want to extend that to plain storage and not using cookies as a storage access mechanism...

Dan: in which case - i'm not sure I understand Anne's issue... what are the additional privacy & security concerns that they feel are unresolved?

Max: what they are trying to say is that this proposal don't introduce more security issues than using cookies...

Dan: it's clear the proposers think that. But webkit people seem to disagree.

Sangwhan: ...trying to untangle... I don't think it's a security & privacy concern..

Yves: i think it's an API issue...

Sangwhan: doesn't seem like a disagreement on the developer / user need. More the shape of the API...

Dan: feedback we could offer?

Sangwhan: only part where we could weigh in is .. is where the storagebucket API is considered a wrapper... to enable to enable (gate) storageaccess in different ways. that's an API philosophy issue and maybe an architectural issue. That's where the lack of consensus sits. I'd have to think about it... Really the question is - you have to look at 2 places to access the storage in different ways - maybe that's not a good thing.

...We could respond: we would have to think about the implications of the pattern - there's a pattern to be defined here regarding gating storage access... we could weigh in. if we suggest going down the sotagebucket route that would have worse ergonimics... supposed to be used to have more deterministic behavour under pressure... but it does have the right kind of abstratcions - but as of today i don't think its the right tool ... I can see both sides.

Dan: can we provide some guidance to the spec authors here?

bumped 2 weeks

Amy: was this waiting on Sangwhan to comment on API shape?

Amy: concerned about the wording in Privacy & Security section - "we believe non-cookie storage and communication APIs don’t enable any capability that could not be built with cookie access." Comparing against status quo instead of comparing against web without 3p cookies...

bump to plenary

Sangwhan: ... distilling a pattern ... the API shape seems to be fine... looking back... this is more of a design pattern ... we don't havea a princple... if this ships as is then this becomes a pattern....

Dan: what's the pattern?

Sangwhan: based on the webkit comment ... https://github.com/privacycg/storage-access/issues/102 "Don't re-invent access control and follow a similar pattern if you want to introduce access control..." We could let this go an distill the pattern out ... into a principle later down the road...

Dan: propose closing this "satisfied" with the following comment:

@archiv thanks again for sending this our way. We're happy with the way this is proceeding. We're happy with the use cases and API shape. And we're pleased to see the multi-implementer consensus taking shape.

Sangwhan: +1

no dissenters

closed as satisfied

Jeffrey: This got re-opened. We closed it a year ago, but they sent two more explainers and asked us if we could comment on them. A reasonable comment would be to ask them to send us another design review, but I re-opened it to keep it in our mind.

DanA: On my RADAR now. Not sure if we can make that decision in the time we have left. Not sure if I want to force them to open up another review if it's just an update on the current thing. Is it enough of an update, or should it be a new review in your view?

Jeffrey: I don't have s strong opinion. The first one is tweaks, the second is a new kind of non-cookie storage. But I think it's basically tweaks of the same review.

DanA: Let's agenda+ this for next week. Let's try to expedite it as we are kinda late. Would anyone else like to join?

Lola: Sure.

DanA: We needed to talk with Anusha.

Jeffrey: I think they're asking about access for shared workers.

DanA: Do you know if that's the scope of their request?

Jeffrey: Nods.

DanA: Haven't had chance to look over to have substantive discussion. Suggest we keep it open. Can ping Lola and try to make progress tomorrow.

Jeffrey: Suggest we avoid agenda+ until we have an opinion to discuss.

DanA: We needed to talk with Anusha.

Jeffrey: I think they're asking about access for shared workers.

DanA: Do you know if that's the scope of their request?

Jeffrey: Nods.

DanA: Haven't had chance to look over to have substantive discussion. Suggest we keep it open. Can ping Lola and try to make progress tomorrow.

Jeffrey: Suggest we avoid agenda+ until we have an opinion to discuss.

DanA: Concerned about the use cases. These don't seem like desirable things. I suggest:

Hi we are looking aththe use cases described in the explainer today and we really think these need to be fleshed out more. For example, a developer embeds chat.com on two of their sites, site-a.com and site-b.com, and they want to use shared worker to maintain a user session. Ok but sometimes it's neither desirable nor appropriate for a session between two sites to share user data. For example, site-a might be an insurance site and site-b might be a medical information site. If you're searching for information about medical symptoms, you don't want that information leaking to the insurance site and thereby causing your premiums to go up.

Lola: Had a look at the extension part

... this is slightly different from related website sets, because it's opt-in

... on developer level rather than organizational, which is a pro

... web developers want a way to manage user sessions across parties

... having a chat with site A within site B

... have seen of the better proposals regarding this use case

... but it's still the same problem, increases the fingerprinting area

... if I am logged into site A in site B, and site C can see that

... I'm not sure if this matches user's expectations

... think we will continue to get requests for this feature

... still one of the better ones because of permissions and restricted access (same-site lax)

Jeffrey: This is storage access, so C only gets it to know if the user clicks the prompt

... (FedCM)

Lola: These aren't cookies which can be transported around

Jeffrey: Don't think this is much of a difference

... if you have a worker that is running on two sites, you can transport data between them

Dan A: Still concerned that in the explainer, they don't seem to be paying attention to nuances

... just talking about a developer that embeds chat.com on two of their sites

... chat.com uses a shared worker to maintain the user's session

... want to know more about the whole user journey

... what is site A, what is site B

... do users know that the site is from the same developer?

... What are we doing to mitigate this? For example, Google and YouTube or a person searching for certain symptoms, then visiting an insurance website

Jeffrey: User has granted storage access, they clicked

... multiple sites run by the same cooking brand

... support chat that they reused across brand websites

... agree that explainer doesn't explain the use case well

Dan A: Would like to see more normative language about how they want to mitigate abuse potential

... agreed to it at one point in time

... spec should say something about periodic reminders or hints

Lola: The shared worker isn't permanent

... how long does it have access

... when you are shopping, you can log on at multiple payment providers

... but you know if you processed the payment, the third party site does not store my login

... may not be clear when the connection ends

... don't think the connection should run longer than the browser session

Jeffrey: Shared worker might have to be restarted, but the shared storage will stick around

... would you like to draft a comment in the brainstorming repo?

... original issue is old and reopened, will create a brainstorming issue manually

Picking this up from B

Dan: We asked them to come back with more details user needs. They did add some use cases to the proposal. https://github.com/privacycg/saa-non-cookie-storage/blob/main/shared-workers.md Maintaining sessions, transferring array buffers. These are well-stated needs. They got the brief.

Martin: Dan, are you happy?

Dan: Happy-ish, but slightly uncomfortable with stuff that shares state across sites. Need to ensure that we aren't enabling more than we did before. Where we got to before was that this doesn't do that. This doesn't enable more sharing of state, but because we're talking about workers, it could mean more powerful means of sharing information across origins. That makes me slightly concerned.

Lola: It was that there are protections in place, but if somebody really wanted to send data between workers, they could. However, this needs a user to opt in. Other mechanisms might not have user opt-in.

Dan: (quotes from proposal) what do others feel? should be push back and require language about informing users, or should we push for more normative language about checks, periodic checks maybe. This starts to verge into territory where the browsers differentiate. We could push for more normative force.

Lola: something that came up last time - that I agree with - was that there are no ways to know that this is active. there should be a mechanism that re-asks after a set period of time or that lets the user know that this is active.

Martin: disagree: the first release of information is complete privacy loss, nothing that happens afterwards makes it worse

Xiaocheng: does this enable cross-origin access with just one switch? That sounds wrong to me. Even if we want to allow cross-origin access, shouldn't that require some agreement between origins?

Martin: not about cross origin access to storage.. it's about origin A getting access to origin A's unpartitioned storage... Storage access gets them access to the same cookies they would get if they were the top level... The fundamental privacy problem is that if you're able to connect identities between web sites ... once google.com has access to on example.com then you have connected identities on the two accounts. Youtube.com and google.com separate entities from a site pov but once linked then google "knows" and can share info behind the scenes. The problem is that web sites break because they assume that this access is possible... It's an escape valve. What's worse is that storage access is automatically granted based on heurisitics which is terrible. But the web wouldn't work if we didn't do that.

Lola: Based on this discussion, I don't think that this is something we should resolve as satisfied. I'd like to get Jeffrey's input as well. Maybe he has some insight. This brings me back to a point from a few weeks ago. This isn't the first of this kind of technology we've seen. Browser vendors want to do this thing. We can keep saying no, which would be reasonable, but they will still want to do this sort of thing. One step removed from this: should we have something that addresses this question? Should we be encouraging spec authors to work together to find a solution that is more private, or should we say that we're not going to do this. Even in my time on the TAG, this is number four of this kind of thing.

Dan: This is complicated because it's an elaboration on a spec that we didn't criticize at the time. That doesn't mean we can't go back and re-visit.

Yves: Just to say that shared cookie storage already exists. You can already marshall whatever you like into it. This is a cleaner way to access this capability.

Martin: this is one of those cases where there is very strong alignment between the browsers. I don't like that but we should provide constructive feedback. As Yves points out once you have cookies, these additional features are ergonimics... One thing that I think would be good to press people on ... generally ... is committing to a longer term plan for what to do with storage access. Is it a temporary hack that allows sites to work? How do we ensure that storage access doesn't become a feature of the web... there are bunch of places where the partitioning are incomplete. E.g. popup windows... another example of a nested browsing context that don't get partitioned... If I'm on a web site and a google login window pops up, that page is now partitioned... Problems abound in this space.

Dan: My strawman proposal is to say we are satisfied with concerns, and that the concerns would be expressed in a way as to point out the growth in the use of storage access. Is this going to become a permanent feature of the web, etc.. Also channeling comments about this being part of a pattern of things that are tying sites together and we have security/privacy concerns about that trend. Push on them to have stronger mitigation in their specification against abuse. That's not something I see in the explainer.

Matthew: It would be great if we could do some long-term planning on these types of issues. This is an opportunity to provide leadership on. In this occasion, we have the right people, so it seems like we really should get on top of this. This is something that should be temporary if we have people and bandwidth. The taskforce for preventing things from getting worse. Foundational problems that we can do something about. Not sure about committing my time, but with the expertise we have, we might be able to do something.

Dan: Might make sense.

Matthew: Need to be careful about scope.

Martin: ... there is some opportunity but to my knowledge there is an entire team at mozilla to think about this problem. Same for Google. We want to push in the direction the TAG wants us to push in - e.g. less use of storage access - but already pushing as hard as they can and finding a lot of breakage (of web sites). Google also dedicated resources and time to this problem. It's not for lack of trying. It's because the web is really big... the reason we have storage access is as a safety valve, so we can move parts of the web forward while the others are stuck in the 90s or wherever we are...

Dan: something that comes to mind, Martin you say there are groups are trying to move the web in that direction. But I don't know if we've articulated that in one place. That voice is dispersed over a number of design review responses etc. That sounds to me like a finding. Could we write "We would like to see you all move away from that approach, we want you all to understand that this is a TAG position"?

Martin: I think the principle is documented in the privacy principles. I don't think the TAG has specifically pointed at Storage access to say it's a transitionary technology and its use should be trending towards zero. Not sure that that view would get wide agreement. Might be worth trying to get agreement on that.

Hadley: you don't think we'd get consensus in the TAG on that

Martin: A lot of discussion in privacy CG and Privacy WG, which wouldn't necessarily agree with us ... over last years ... not clear to me if there is alingment on what the future of API is.

Hadley: we in TAG can still have an opinion.

Martin: sure

Yves: Best to say satisfied with concerns: 1. It can become an integral part of the platform instead of a transient API. 2. The other is about general concern about sharing between sites with unknown consequences.

Dan: I'll take an action to write something up and see if we can come to a conclusion on a response next week.

Lola: Would like more time on this one.

Jeffrey: I contacted the team; they have improved their use cases section.

DanA: That was merged last week; ACK. Will review new use cases. Bump to C?

bumped to C

Jeffrey: This is specifically about shared workers. There was discussion over the last couple of weeks.

Recent discussions: https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/906

Yves: Action on Dan to write the closing comment.

Matthew: We talked about doing some long-term planning on this too (also relating to related sites TF, that I think we're going to set up).

Lola: +1 on doing more work - aligns better with Privacy WG? Planning to pitch to Nick.

Jeffrey: Do you have a sense of whether the WG or CG is the better venue?

Lola: Haven't been involved in CG in a couple of years. Could pitch it there too.

Jeffrey: I'm neutral too. The spec is officially in the CG, but don't know if they discussed this change.

Lola: For this specifically I think the CG is best, but I'm thinking about the proposed TF work (on specifying related sites).

Jeffrey: Catching up with minutes.

Lola: Also sharing data across domains. Trying to address the umbrella thing.

Matthew: Pretty sure I suggested Ehsan to participate in this, who I nominated as an Associate. There are multiple efforts in different groups to express relationships between sites. Different use cases, privacy/security properties. Reduce wheel-reinvention. Relates to the recreation of 3p cookies. User control in addition to author control.

Lola to file the WG issue / Talk to Nick Doty. After hearing from DanA. Re-discuss tomorrow.

We came back to this later

DanA: This is a good idea, to raise it with the Privacy WG.

Lola: I will create an issue; can be taken off tomorrow's agenda.

torgo: Last time, did we challenge them on the use cases in some way?

Jeffrey: They replied with updated use cases. Now waiting on closing comment

torgo: On it! Will get this done today/tomorrow, will be out next week

Lola: On my todo list is filing a issue, will do this week, will be out next two weeks

Jeffrey: Skip today