We have done an initial review, and have a few questions to begin the conversation:

1. What use cases are you explicitly designing for? Can you elaborate on "legacy use cases"? Why is just using iframes and the Storage Access API insufficient? 
2. What abuse scenarios have you considered, and what are the mitigations for them? The S&P questionnaire says, "While this functionality comes with a risk of abuse by third parties for tracking purposes, it is an explicit goal of the API and a key to its design to not undermine the gains of cross-site cookie deprecation." -- how does that work?
3. We see "Permission grants for storage access are double-keyed" in the S&P questionnaire, but this isn't in the spec - is there something to add here?
4. Why do images need access to storage? (The explainer alludes to uses for cookies, images and scripts).

Dan: anything we can do right now on these 3 things?

Amy: Hadley & I reviewed this - conjunction of FPS and this one... Change to FPS itself made sense. But this additional feature seemed to undo the benefits... We need to dig into it a bit more.

... Hadley also made a list of questions to ask them...

Dan: suggest getting the questions to them ahead of time.

Amy: I'll draft something for the plenary...

abbreviated rSA and rSAfor

Dan: recaps previous discussion

Hadley: we had a good look at the spec and explainer and security & privacy questionnaire... We put the questions in our issue 808.

Johann: saw those.

Amy: that's it - we also reviewed the FPS proposal on the morning of the same day.

Hadley: use cases... what are you trying to accomplish here?

belated intros

Johann: context of use cases... how the proposal developed. we were thinking about how to evolve fps based on feedback from browser vendors and the TAG. We had to change the synchronous same party cookie model. Storage access APi was the natural choice there - already being put forward by other browsers. FPS was meant for things like SSO... Use case for Nintendo - you log in for nintendo.de it forwards you to nintendo.com - they share info - and that's how the login works...It's a classic ccTLD use case. That sort of thing is SSO based... one of the things we want to solve. Using iframes is inconvenient ... also made more difficult based on changes to storage access API...

doc

... bunch of security attacks on the web - currently possible but would be prevented with 3rd party cookie deprecation. However if we have a really easy lever [for info sharing] then that opens up security vulnerabilities. Essentially the idea is - iframe restriction for rSA.

... There are non iframe flows that are enabled by passing images and setting cookies - not to be confused with a tracking pixel, it's on behalf of the user - but it's set through other than cookies. Eg. logging into wikipedia.org also set cookies for wikimedia org, all set in pixel images that would log you on everywhere. Whether that is the perfect programming pattern to use or not is another situation but it's something we see on the web and it's something we want to support.

Hadley: helpful background. Would be useful to have a concrete set of how you're going to measure your success? what's on the list of things it can do and it's done?

Johann: 1) adoption that we see from the ecosystem, if it's needed. 2) technical functionality - it's not that complicated for us, it's enable top level resource credentialed resource access, cross site resources with credentials, that aren't based on an iframe user flow. Seen these things in the wild. At Mozilla we built this into the browser .. saw that need

Amy: you said "this is not a tracking pixel" - so is that use case explicitly excluded or will there be a side effect of enabling tracking pixel case.

Johann: we have to look at this for all APIs. with rSA you still need a user action... So I'm pretty sure we made it explicit - not intended to be auto-granted on all sites. Silent auto-grant all the time should be discouraged. We see FPS as user-supplementing - for the cases where the user would clealry make the assocation between two sites..

Amy: worth digging into the threat model where users think they are consenting to one thing but there is still a tracking pixel going on - which is not what they consented to.

Johann: FedCM is the long term..

Amy: That was my next question - is this a temporary solution [in advance of fedCM]?

Johann: FedCM is one social sign-on use case... Mozilla really [likes] FedCM... and are concerned about FPS. FedCM - the way it's currently built - isn't meant to solve SSO cases... There are proposals to make it more ergonomic for SSO.. the reality is that browsers now do it with a mix of heuristics and ???. Some sites are broken, some sites work in chrome, some are covered by heuristics... I personally agree on the long term outlook that FedCM is the way forward... So I think extending FedCM is in our interest. But for the nintendo use cases - showing a prompt for those is not something we would not feel super comfortable with... Prompt spam is a problem on the web. We want to protect users from large scale tracking and put up theoretical barriers that are only in place to support theoretical concerns. We want to be practical.

Dan: good articulation.

Sangwhan: .cc tld case would be unscalable for a lot of companies - list so long that users would not read it and press okay anyawy. That dialog is not going to help anybody

Johann: we still have to find convergence there. Our way of thinking is not necessarily the correct one. Will turn out over time. Back to rsafor ..

... we want to stay on a path that has a chance of converging... sameParty cookie would have factured the ecosystem for a long time, this is better. We're talking about details that are convergable betwen brwosers

Dan: Can we talk about the specific functionality of requestStorageAccessForOrigin which is different from requeststorageaccess and why that's necessary to support these use cases. In the discussion between Amy and Hadley you uncovered that these were functionality that other browser vendors had specifically discounted from request storage access. That seemed to be concerning. Diddn't seem like that was related to antipathy for FPS but more at a general level.

Johann: the functionality in rsafor was explicitly thrown out of rsa - we led the effort, everyone agreed to it. We discsused at TPAC, all browser vendors agreed to reduce the scope of rsa mostly because of security concerns. rsa as an api really doesn't work that well with per page storage access. It's really complicated.

...Previously rsa worked in the way that you had to as a third party embed it inside in an iframe in a top level document. You had to get user gesture and call the code to request storage access yourself. However that storage access was then expanded onto all resources you had loaded on a page. If you were in an iframe and then the top level page tried to load an image fo ryou that would also work. Google docs in an iframe on example.com, and googledocs called the storage access api in the iframe, if example.com then loaded an image from google photos accounts.google.com that would also load with credentials. Two big problems - developer understanding and sameness.. it's hard to work with for developers when they don't know when something is going to happen because it happens in a separate iframe - always a concern. Then what tipped us over to restricting to the iframe was security concerns. We realised that when .. that can be a problem, you have an iframe that loads google docs, but as a top level you can make requests to google accounts - that is potentially bad. Google docs wanted to have this one iframe and load credential and do something with it. The user wanted to load the document in a personalised state, but it just opens google as a whole up to an attack from the top level example.com. That was the initial concern. That applies to google and also everyone else. Unless you narrowly scope down in terms of security, the top level can arbitrarily attack all your endpoints. See more in the doc.

...Originally Martin Thompson suggested scoping back to iframe. We had a bunch of creative solutions to work around that, but none really worked, to preserve that per page state. So back to iframe grants. Only get storage access for that iframe, it doesn't escape. It has great security properties, you can't be attacked by framing, you have to opt in to this potentially dangerous behaviour, and it only works on documents that really need it. if google docs calls it, the attacker can't forward to google accounts, because it wouldn't cal the api. So we threw out the per page behaviour.

...Both mozilla and google at the time said we are not comforetable with losing that top level ability to load credentialled images and scripts. We had at the time proposed rsafor we felt it was needed, and it was a prefect fit for that. So sitll security concerns for rsafor - we fixed it by adding a CORS requirement on any resources loaded on rsafor. if example.com now calls rsafor on google accounts, it can make credentialled requests, but the requests always send an origin header, and google accounts always has to respond with the correct cors response, or the resource wouldn't be loaded. That is protecting against access leaks. There a few edge cases, which we considered out of scope and not solveable. We're losing some cross site developer functionality

Hadley: what's the cross browser participation, different between rsa and rsafor

Johann: ...we hope that rsafor takes the same path as rsa had. rsa is older, has a lot more history. We think we have a really nice solution with rsa. rsafor is a very early proposal, still gathering feedback from other browser vendors. it was developed together with mozilla at tpac, and google went on to formalise it. I feel like we've hit a few points o fdisagreement with mozilla that we have to work through that weren't clear at the time we developed it together. I'm hopeful that we can.. it might take a while.. it look a long time for rsa, but I'm hopeful we can converge on something together. There are concerns, but it doesn't rise to the point of FPS

Dan: question in the breakout about images - credential images - to focus on that - tracking pixels..

Johann: images are .. pixels is the right word. Has a bad connotation, tracking pixels embedded everywhere. Definitely possible on browsers that don't block 3p cookies by default. They're a technology you can use but it doesn't stop there. If you took away the ability for people to do credentialled images they would do fetch requests, or they'd embed iframes. Pixels and images are so frequently called out and used because they're so convenient. People like embedding 0x0 images which set cookies. We need to ensure that these cookies can't be used for the purpose of cross site tracking. But it doesn't make sense to say a lot of people use tracking pixels, let's not allow people to laod images across sites with credentials. That doesn't really fix anything because people would move onto the next technology. That whole space means it could be fetch requests, script loads. A bunch of things that carry credentials across sites that are used by 3p resources on the top level site. loading iframes is complicated. fetch credentails, post message up. We're not talking about cookie theft - if you send around your credentials via js apis you run a much greater risk of having them intercepted. Eg. Sony and Playstation - sony wants to authenticate on playstation, you visit playstation.com, open a popup window with sony, login with sony, sony embeds an image, a credentailled pixel, carries a cookie that has your login information. Sets that, could either be an image that has the origin playstation com, or has the origin sony.com. Say it has a pixel of sony.com itself embedded, you go back to playstation.com and then that cross site flow happens, where playstation.com has to receive the same information somehow. Actually sony.com embeds the pixel for playlsation com, then you reload the document and it loads without js being involved, portecting against cookie theft. Iframe is much less conveneint. Could we not possibly put this restriction in place on the web? Not impossible. If you were to rewrite all cases from scratch you could do it. But given there are so many sites that use images and scripts with credentials, it doesn't seem feasible for us to ask the entire web to rewrite, at least not in the short to mid term.

Hadley: thus far it sounds like you've talked about SSO and tracking. Are there other examples or situations in which you're finding somebody would to be able to use it in this way?

Johann: a lot of 3p cookie deprecation, cross-site use cases that are non-tracking, are in some way about authentication. They reduce to authentication and login to some extent. That's why people say FedCM is the long term future. I think for FPS it's really about finding that set of authentication use cases or recognition of the user identity use cases that are both non-privacy invasive and also not something that the user should be confronted with a prompt about. Another example for FPS is the service domains where we have something like githubusercontent or an experiment domain separated for security concerns in jsfill but the content needs to load in a credentialled fashion if it loads on the top level. For me it wouldn't make sense to ask the user if you want to connect jsfill with jsfill. That is speaking to FPS. Important to say for rsafor a lot of what it does and its long term future is to provide that technological underpinning, the capability to load these images, do these requests in a safe manner, gated on other things. Could be a good prompt design, could be FPS, or whatever we end up converging on on the 'front end' as brwosers. Both requeststorageaccess and rsafor provide the technological underpinnings to allow us to restore safe cross site cookie access. Long term, eventually browsers have converged on this way ...

Hadley: in S&P it says "...risk of abuse.. to not undermine the gains of cross site cookie deprecation". Sounds like a fantastic ambition, what does it mean in practice? Will it depend per browser? And in Chrome FPS will be the limitation for who will be allowed to use this technology with each other?

Johann: I think that was a good summary of the current status. A lot of this is due to necessity becuase of different opinions on what the end user flow should be. Browser choice. A bunch of baseline anti abuse mechanisms in the api right now. User interaction requirements, security retaliation(?), security restrictions etc.. we have a bunch of baseline protections. I agree the big privacy gate is something that we still have to converge on. The point of the sepc is that it requires this sort of gate. At the very least by saying the user agent has to ask the user for permission, which includes for FPS or heuristics, taking steps to not ask if you are confident that' it's fine, but generally the UA is required to ask for permission at the last step. They need to make there is some sort of privacy check, privacy gate. That's how we consider the design to be protecting the user.

Hadley: as a developer wouldn't that make for really different user experience on each browser?

Johann: yes, agree that's a problem. SOmething we have to work towards. But we can't ignore the reality. I'd love to be in charge of all browsers and find this common way of gating user consent for all sites. But we have a couple of really great approaches, like FedCM.. can see not everyone is on board with FPS. Some browsers have prompts. I'm more worried about the developer experience than about the remergence of widespread cross site tracking. All the methods we have put in browsers right now are very private and in the intersts of the user, but I agree the developer experience suffers, that's a task for us.

Hadley: helpful. And the user experience is potentially very different and confusing.

Johann: true, fair concern. Both rsa and rsafor are designed in a way that tolerates.. two edged sword.. on one hand by being so open to the browser can dow hatever it wants to ensure user consents, it creats a diverging ux.. but also ensure we're future compatible with whatever hopefully better solution we can converge on at some point. That's the problem with sameParty cookie - was closely married to FPS. Couldn't rip FPS out. But you can rip prompt or FPS out of storageaccess and put something better in front of it. We'll see, maybe FedCM. You still have the technological capabilities.

Dan: what you said about CORS being the thing that helps you mitigate the issue that was raised with the forOrigin part.. is that something that .. how do you think mozilla and other browser engines feel about that. Is it a consensus view that having CORS sufficiently mitigates the risk?

Johann: I wouldn't expect that to be contentious. May be discussions over details. One aspect of CORS where it doesn't prevent CSRF (cross-site resource forgery), you can still make the requests, but hoepfully it prevents leaks becuase the server has to respond. But CSRF we consider somewhat out of scope because it's possible in other ways. You can open a top level URL, new tab with that url you want to attack. Other way stop do it so out of scope, and also would be hard to completely solve. We won't have a lot of issues on the CORS question. Seems fine to me.

Dan: what's the pathway for standardisation for rsafor?

Johann: we've made good progress at tpac last year, leading up to the point where we are now. There are a few points of contention that we have right now, mostly around this frontend question. How do we really expose this to users? We are generally aligned with technology.. that this would at the very least not be harmful. Varying degrees of people saying it would also be useful among browser vendors. Big question is how do we expose this ot users - chrome has a clear answer, FPS. Also looking into prompts and developing a prompt strategy. Other browser vendors don't. They need time to look into it and figure out how comfortable they feel. And needs further discussion to ensure their concerns are heard, what does this look like if chrome uses FPS and we prompt, what does that look like for us.

Hadley: ..about double keying?

Johann: not an oversight, we just didn't make it clear enough. They way it's keye on rsafor is it's in the permission descriptor. Added a nonnormative note to the spec in response to your comment.

Hadley: thanks for clarifying in the spec.

dan: the prompt spam point is a good one

Hadley: fragmentaiton is concerning... want to spend more time - conversation was really helpful.

Amy: a piece of positive feedback: separating each of these compontents out and making them pluggable is good - gives a space to improve different bits separately...

Amy: it would be useful to talk to some of the people who were around when this functionality was originally excluded from StorageAccess API. Are there other stakeholders who agree / disagree with this?

Hadley: Definitely

Amy: Yes.

Dan: totally reasonable to ask other editors of StorageAccessAPI to comment on this issue. Especially Anne who is ex-TAG.

Peter: question on the sso use case.

Dan: I think it's reasonable ... sso use case.

Hadley: we're asking users to fundamentally shift their understanding of the security boundaries of the web, from a url to a brand

Peter: .. sometiems I have the opposite experience, I want to be using two different accounts on two related tlds for reasons. Shouldn't be automatica and transparent and seamless, user should be able opt out. The other thing - part of the SSO answer is to get some other behaviours.. FedCM will get there as the right way to do it and they want to do it as a workaround in the meanwhile. New capability with potential for abuse as a temporary patch to do something in a way that isn't as good as the way to do it as the right way

Hadley: seconded

Dan: yes, and... they might say browsers already do this. To Hadley's point about changing the user expectation... you could argue it's already set the other way, because of the exceptions that browsers have put in place. That is the arguement being made. It's highly contextual. The [gaming brand] case that Johann made is quite clear that the intention would be .. especially with the audience of a gaming domain .. they would expect minimum fuss to get to content. However if you starta pplying this to things like google and youtube that's where it gets fuzzy. We all know that google owns youtube, but a lot of people don't know that and don't necessarily make the connection and wouldn't be okay with their google account details being shared with youtube without there being some kind of authentication

Peter: side note -there are implications, if I'm in EUrope and go to [gaming brand].de, I'm expecting european data protections vs [gaming brand].com. Conflating those two has legal ramifications. I understand the user expectation

Hadley: not just data protection. Also shopping, where they'll only use local addresses or credit cards. TWo amazon accounts for shipping to different places.

Peter: content restricted to regions for licensing purposes..

Hadley: If the goal is to embrace the way people think it should work ([gaming brand].de is part of the same user journey as [gaming brand].com]) -- then I think it's worth saying that this isn't the status quo all around. The data protections and payments and regional content restrictions we just discussed show that.

Peter: And that goal may not be welcome.

Amy: discomfort about "legacy use cases" .. fine line between backward compat and advancing the technology in a beneficial way

Hi @annevk @bvandersloot-mozilla as co-editors with @johannhof of [StorageAccess API](https://github.com/w3ctag/design-reviews/issues/807) could either/both of you let us know your perspective on this proposal? We understand that requestStorageAccessForOrigin was a [departure from StorageAccessAPI](https://github.com/privacycg/storage-access/issues/113). Is this direction likely to gain your support?

Dan: pastes comment

Peter: [I will also leave a comment on the SSO issue we discussed]

bumped to plenary

Amy: it's good that Johan took Anne's feedback and spun up 2 issues on that... These security issues are pending... If you look at their issue 29 .. it's too bound to FPS. So at this point I feel it's unsatisfied based on lack of multi-stakeholder support, open security issues and dependency on FPS.

Amy: FPS stands on its own as a registry function - by itself - is harmless. But if it's used for automatically granting access to storage without the user's permission then that's problematic. But it's not dependent on RequestStorageAccessFor ...

Amy: comment from Alex in April - I2S..

Dan: leaves comment pinging the issue

[Hadley: regrets for this breakout C, but it looks like it's with Johann. They have put out an intent to ship, but our concerns haven't yet been resolved.]

We're waiting to hear back from them in September.

Hi all. We've looked at this during our W3CTAG f2f. We are still hoping for replies to our previous two comments from @plinss and @cynthia. Any thoughts?

Dan: response from Johann - on timngs...

Hadley: 2 comments .. from Johan.

bumped to 4-september

Martin: there's been a lot of churn in this area

Amy: we are waiting for an update from them

Martin: leaves nudge, propose close

Yves: there is support from Wordpress for the functionality... same for payments... part of the ongoing attempts to poke holes into iframes isolation...

also bumped to plenary

Hadley: from Johan's comment from last year it sounds like they need more time.. could be fine for us to close and ask him to re-open...