Amy: there are no user stories involving actual users :'(

Tess: the thing asking for storage access has a frame in the page. There are some sites that don't have a frame. What they're looking for here is if you use http headers to convey storage access information you won't need an iframe in the page to get at those cookies. The storage access api has a user gesture requirement, by design you don't get storage access unless you ask the user and the user grants. If it's rpeviously granted the promise resolves immediately but you have to call it and the user has to thinka bout it. if it's happening at the network request level when and how do we prompt the user? Do we block th enetwork request until we've got a response from the user? Very unusual circumstance to make fit with the storage access api privacy model, that everything is gated on meaningful user consent. I understand they don't want to rearchitect the code that doesn't require an iframe but... user needs something to click on. This makes the storage access api adoption a bit of a smoother expeirence for some existing code paths which potentially increases adoption overall so it's tempting. But feels like it's fundamentally subverting the design of the api. Jeffrey and Martin will have different opinions. Storage access api is spposed to be inconvenient. That's the idea.

Peter: feature is access without ser interaction "in cases determined to be safe". How are they determined to be safe?

Hadley: a list in the browser? They also say they are working with PrivacyCG chairs to adopt as a work item. There is no multi stakeholder approach here.

Jeffrey's proposed comment:

This strikes us as a good direction for the evolution of the storage access API, and we'd like to see the Privacy CG continue to iterate on the details. We don't expect to have much to contribute to a review of the final specification and are happy for that to proceed through the Privacy CG and WHATWG processes without our further review. We also encourage further work on allowing authenticated embeds to work with Javascript completely disabled, acknowledging that this is difficult given the goal that storage access should only be granted after user interaction with the cross-site content.

Tess: I was worried about this because "when does the user gesture requirement apply"? And Storage Access lets different browsers experiement. Does this cut off some branches of experimentation?

Jeffrey: Add to the comment something about "don't close off experimentation."

Tess: Also make sure they go through the PING?

Jeffrey: I feel like this particular extension won't raise privacy risks, even if Storage Access as a whole should go through PING.

This strikes us as a good overall direction for the evolution of the storage access API.

One concern: the Storage Access API is architected such that implementations may differentiate themselves by imposing stricter or more lax policies on sites. Does this feature narrow the window of possible policies? Put another way, could websites misuse this feature such that some policies would fail to work? If this header becomes widely adopted, could browsers find themselves needing to change their policy for compat reasons?

Another minor concern: We find the use of the Sec- prefix to be unnecessary. Sites presently receive requests with and without cookies. That a new signal might elicit new and inappropriate reactions from a server is possible, but not a particularly credible one. Denying web applications the option to elicit one more inappropriate action using this mechanism is wasteful.

We'd like to see the Privacy CG investigate this and continue to iterate on the details.

We don't expect to have much to contribute to a review of the final specification and are happy for that to proceed through the Privacy CG and WHATWG processes without our further review. We also encourage further work on allowing authenticated embeds to work with JavaScript completely disabled, acknowledging that this is difficult given the goal that storage access should only be granted after user interaction with the cross-site content.