1991688 - Storage-Access-Headers: Enable Nightly-Only

Status: RESOLVED FIXED

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

Comment 1

[Manuel Bucher [:manuel]]

Attachment: Bug 1991688 - Storage-Access-Headers: Enable Nightly-Only

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/07f704bf7c0c
https://hg.mozilla.org/integration/autoland/rev/780278f64cc0
Storage-Access-Headers: Enable Nightly-Only r=bvandersloot

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2d3ba50b466b
https://hg.mozilla.org/integration/autoland/rev/55bb35bc3305
Revert "Bug 1991688 - Storage-Access-Headers: Enable Nightly-Only r=bvandersloot" for causing wpt failures

Comment 4

[Sandor Molnar[:smolnar]]

Backed out for causing wpt failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/55bb35bc330560bfee9dcbf8f7b23f81312b5160

Push with failures

Failure log -> /fetch/metadata/generated/element-picture.sub.html

Comment 5

[Manuel Bucher [:manuel]]

This is due to Bug 1936389. Should be investigated and landed first.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/245cbd53c93d
https://hg.mozilla.org/integration/autoland/rev/eac7bb20d058
Storage-Access-Headers: Enable Nightly-Only r=bvandersloot

Comment 7

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/eac7bb20d058

Comment 8

[Manuel Bucher [:manuel]]

Adding dev-doc-needed. Noticed in Bug 1993965 that both "Sec-Fetch-Storage-Access" and "Activate-Storage-Access" headers aren't documented on mdn yet. Let me know if I should open a PR for documenting these myself. Also the implementation status should probably be tracked. Blink already shipped the feature. https://chromestatus.com/feature/6146353156849664?gate=5788202676518912.

I'm currently drafting an Intent-To-Prototype that I also can link later.

Comment 9

[Dianna Smith [:diannaS]]

:manuel did you want to mention this in the nightly release notes? Please nominate if so.

Comment 10

[Manuel Bucher [:manuel]]

Intent to prototype was sent: https://groups.google.com/a/mozilla.org/g/dev-platform/c/OPmJiLLZdak

Comment 11

[Manuel Bucher [:manuel]]

I think would be worth mentioning (sorry for confusion just got reminded that I wanted to link intent to prototype after reading comment #8, was drafting release note request after linking).

Release Note Request (optional, but appreciated)
[Why is this notable]: Supporting new draft. Part of broader project of third party cookie deprecation. Allowing easier access to unpartitioned cookies also for new resource types such as images that can't run scripts (previously only possible for iframe resources).
[Affects Firefox for Android]: yes
[Suggested wording]: Nightly now supports Storage-Access-Headers allowing servers to opt-in into unpartitioned cookies via HTTP headers if storage-access was granted prior with the Storage-Access-API.
[Links (documentation, blog post, etc)]:

• Spec: https://privacycg.github.io/storage-access-headers/
• Explainer: https://github.com/privacycg/storage-access-headers/blob/d73c092919f0ca44c02c0890c078046ef8a63a88/README.md
• Intent-To-Prototype: https://groups.google.com/a/mozilla.org/g/dev-platform/c/OPmJiLLZdak

Comment 12

[Dianna Smith [:diannaS]]

Thanks! Added to Nightly+ notes where it will show for 3 cycles(145,146,147) or until it is enabled by default (most likely 147 based on the intent email).
https://www.firefox.com/en-US/firefox/146.0a1/releasenotes/

Comment 13

[Manuel Bucher [:manuel]]

What I forgot to mention in the intent-to-prototype: This is my test website / playground for storage-access-headers that other might also find interesting: https://sah.neon.rocks/storage-access
Source: https://github.com/mb/scripts/tree/7b4a5d79ce4a3492453dc03f0558640c81c19138/sah

Comment 14

[Hamish Willee]

FF145 MDN work for this can be tracked in https://github.com/mdn/content/issues/41499

Let me know if I should open a PR for documenting these myself.

Generally if you feel a desire to document we'd love you to do so. However it is not a requirement. I've started these. @Manuel would love a technical review when I get a bit further.

Comment 15

[Manuel Bucher [:manuel]]

I've started these. @Manuel would love a technical review when I get a bit further.

Thanks! Sure, please request review at that point.

Comment 16

[Hamish Willee]

Hi @Manuel,

I have just finished the docs first draft https://github.com/mdn/content/pull/41614 - close enough to need a review.

In particular see the updates to https://pr41614.review.mdn.allizom.net/en-US/docs/Web/API/Storage_Access_API.
The section on "How it works" was rewritten because this mixed up permission granting and activation. I also added some mermaid sequence diagrams to make it more clear how the two flows differ.

https://pr41614.review.mdn.allizom.net/en-US/docs/Web/HTTP/Reference/Headers/Activate-Storage-Access also has examples, which are linked.
There is some duplication sorry.

Last of all, in the how it works section it says

Depending on the browser, the user will be asked whether to grant permission to the requesting embed in slightly different ways.

• Safari shows prompts for all embedded content that has not previously received storage access.
• Firefox only prompts users after an origin has requested storage access on more than a threshold number of sites.
• Chrome shows prompts for all embedded content that has not previously received storage access. It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same related website set.

For Firefox, is that still true, and does it mean that permission is not prompted until after Firefox has seen the embed a number of times. How is that supposed to help?

For Safari and Chrome, does that mean "activation" or "permission"? As I read it, the prompts appear for every new context, ignoring whether or not it has permission.

Comment 17

[Manuel Bucher [:manuel]]

1. On first load when you don't have permission the request would have Sec-Fetch-Storage-Access: none - would Activate-Storage-Access be omitted from the response.

Yes, we'd ignore the Activate-Storage-Access header. The initial activation of Storage-Access has to go through the Storage-Access-API in an iframe.

For Firefox, is that still true, and does it mean that permission is not prompted until after Firefox has seen the embed a number of times. How is that supposed to help?

It is true, that we still have the threshold. The idea behind it is: As long as it stays under the threshold, the (potential) tracker can't use it for cross-site tracking yet. And we don't want to introduce prompt-fatique by showing to many permission prompts to users. (training users to blindly click "Allow").
I think for sites, where we don't have any interaction yet, we still show the prompt (but I don't know the exact rules). Probably worth discussing with team a bit. Will bring up in team meeting on Monday.

For Safari and Chrome, does that mean "activation" or "permission"? As I read it, the prompts appear for every new context, ignoring whether or not it has permission.

I would have expected the prompt to be shown only once per (site <-> embedder) tuple. So only for the permission not for each activation. In the storage-access-headers there will be never a permission prompt, because the permission is prerequisite for storage-access-headers doing anything.

Sorry, didn't manage to take a look earlier. Hope that still helps.

Comment 18

[Hamish Willee]

Thanks @manuel

FYI This is done "good enough" for now, but might come and update it when this ships.

Specifically ...

I think for sites, where we don't have any interaction yet, we still show the prompt (but I don't know the exact rules). Probably worth discussing with team a bit. Will bring up in team meeting on Monday.

Interested to hear the results of this conversation. I still don't understand what you are saying re prompting. The threshold thing specifically.

What it sounds like is that the user selects (say) the button tied to the permission prompt with transient interaction, so should be prompted. However FF is going to choose not to prompt until the user has clicked a similar button on a bunch of pages for this embed.
That sounds broken - which makes me think I don't understand this.