Headers may limit possible Storage Access API policies

[sjledoux]

Taken from this comment:

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?

[cfredric]

CC @jyasskin since he provided the original feedback from the TAG, in case he wants to provide more context.

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?

This proposal avoids that narrowing as much as possible, while still providing utility to websites. This feature is designed such that websites (still) must request the storage-access permission from the user (after having obtained a user gesture) via JavaScript. Sites cannot assume that "header-only" usage will work, because it won't. User agents therefore have leeway in whether they choose to support these headers, since the site must support the "first-visit" fallback path (via JS) anyway.

Note that if a user agent does not support these headers, or does not support the header-based opt-in, then the non-iframe use case has no general solution in that user agent. This is unavoidable (unless the UA sacrifices security instead), and highlights the usefulness of this feature.

This concern was previously discussed in a weekly PrivacyCG call (minutes).

Tentatively closing, please reopen or leave comments as needed.

[jyasskin]

@hober, do you think this answer addresses the concern?