Re: [w3ctag/design-reviews] Early design review: Storage Access Headers (Issue #982)

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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/982#issuecomment-2316819239
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/982/2316819239@github.com>