1978856 - Reconsider "Sec-Fetch-Storage-Access: none"

Status: NEW

(Core :: Privacy: Anti-Tracking, task, P3)

Description

[Manuel Bucher [:manuel]]

In my opinion, it doesn't add much. However adds complexity and adds 32bytes (uncompressed) to all cross-origin sub-resource requests. This is an excessive amount, also adding latency. It contains minimal and AFAICT not actionable information to the server. I'd be for dropping this header value.

Needs spec work. Filing now to keep this in mind.

Comment 1

[Manuel Bucher [:manuel]]

This was raised before: https://github.com/privacycg/storage-access-headers/issues/15

Comment 2

[Manuel Bucher [:manuel]]

We do leak some internal state with this header. It also is possible to use the other Sec--headers to determine the state.
https://searchfox.org/firefox-main/rev/21a394033d607022640b4a32d85694aac8b19a54/toolkit/components/antitracking/AntiTrackingUtils.cpp#451-458

Comment 3

[Manuel Bucher [:manuel]]

https://github.com/privacycg/storage-access-headers/issues/15#issuecomment-2320624882

In all three cases, the server can send an (unpartitioned) cookie and be sure that the browser will honor it. That is the signal I expect from the absence of the Sec-Fetch-Storage-Access header.

Not entirely sure, but since Firefox does partition cookies by default instead of dropping third party cookies, the server would expect us not to send the Sec-Fetch-Storage-Access: none-header?