1965552 - Iframe added to the page by an extension no longer has storage access

Status: RESOLVED FIXED

(WebExtensions :: General, defect)

Description

[Colin Maxfield]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

At Pendo.io we provide an extension to our customers that allows them to use Pendo over the applications they want. As part of that extension, we are able to launch our Visual Design Studio over an application to design in-app guidance for these applications. Starting in Firefox 140, our extension is no longer able to launch the Visual Design Studio due to window.localStorage access throwing a "DOMException: The operation is insecure" in the pendo frames opened by our extension. Local storage is used to communicate between multiple of our own pendo frames added to the page and this access is necessary for it to function. The steps below will only work if you have access to a paid Pendo subscription but I will include them anyways.

1. Install the Pendo Launcher add on (https://addons.mozilla.org/en-US/firefox/addon/pendo-launcher/)
2. Log in to your Pendo subscription on app.pendo.io
3. Launch the Visual Design Studio over the desired application.

This seems to be caused by the recent change in 140 Nightly to prevent access to referrer and storage by frames opened from extensions.
https://bugzilla.mozilla.org/show_bug.cgi?id=1962124
https://bugzilla.mozilla.org/show_bug.cgi?id=1957355

Actual results:

Errors are thrown in the console in our own app.pendo.io frame "DOMException: The operation is insecure."

Expected results:

As in Firefox 139, we should not be throwing errors for using local storage in our own frames.

Comment 1

[Colin Maxfield]

Confirmed that it is due to the default change in the linked bugs. Setting "privacy.antitracking.isolateContentScriptResources: false" makes the frames work correctly again. I think we are going to need a way to programmatically get storage access as this will completely kill our product in Firefox and drive all of our customers towards Chrome.

Comment 2

[Colin Maxfield]

What I'm not sure yet is if this is something that is solved by document.requestStorageAccess or not. If that is right path to take here feel free to let me know.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Andrea Marchesini [:baku]]

Do you have any thoughts about this? In particular, do you think document.requestStoreAccess is the right move? And do you know if it's supported in the latest changes?

Comment 5

[Tim Huang[:timhuang]]

By definition, document.requestStoreAccess allows an iframe to request access to client-side storage. So, it can be a path forward if we think the privacy implications of the injected content by extensions can be acceptable if the user agrees through the API.

However, the current implementation doesn't support the document.requestStoreAccess(). We will always reject the call in the current implementation.

Comment 6

[Rob Wu [:robwu]]

Attachment: iframe-dom-storage.zip

STR:

1. Load attached extension at about:debugging in Nightly (or if testing non-Nightly (139+) - set privacy.antitracking.isolateContentScriptResources to true).
2. Visit https://example.com
3. Look at the frame that the extension adds (iframe src is same-origin).
4. Visit https://example.net
5. Look at the frame that the extension adds (iframe src is cross-site).

Expected:

• At step 3, the iframe should be green - DOM storage access is allowed (same-origin).
• At step 5, the iframe should be green - DOM storage access is allowed (cross-site).

Actual:

• At step 3 and 5 the iframe is red - console shows Request to access cookie or storage on “https://example.com/?iframe” was blocked because we are blocking all storage access requests. and DOMException: The operation is insecure.

Comment 7

[Rob Wu [:robwu]]

I thought that we were only going to strip referrer headers. Apparently bug 1957355 expands this to cookies, and due to the implementation even DOM storage. It is far from uncommon for extensions to insert an iframe in content scripts, so this restriction is unlikely to be compatible with extensions, to the point that we cannot ship this to release.

Can we not block storage access from frames inserted by extensions? As my STR in comment 6 shows, this restriction is even applied to same-origin frames.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1962124

Comment 9

[Andrea Marchesini [:baku]]

We have a meeting next week to discuss this issue in more detail. For now, let's disable this feature in nightly.

Comment 10

[Andrea Marchesini [:baku]]

Attachment: Bug 1965552 - disable the anti-tracking protection for injected resources via content script, r?robwu

Comment 11

[Colin Maxfield]

Thank you so much for the update, let me know if you need anything else from me. Sorry for the doom and gloom in my previous messages, I panicked before I realized that I could at least turn it off using the config flag.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e8f59246d1ef
disable the anti-tracking protection for injected resources via content script, r=robwu

Comment 13

[Narcis Beleuzu [:NarcisB]]

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

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to Tim Huang[:timhuang] from comment #5)

However, the current implementation doesn't support the document.requestStoreAccess(). We will always reject the call in the current implementation.

That part is clearly a bug. We are still arguing over whether injected frames should be partitioned by default, but they definitely shouldn't be less capable than a frame inserted by the original page.

There will be strong pressure to provide an option for extensions themselves to create frames with storage access enabled: both to keep old extensions working and to avoid annoying users with storage access requests for content they presumably want their extension to be adding. The security team would prefer that require an explicit action on the part of extensions that could be checked in review (maybe a permission? an option/argument/attribute in the API?), but Web Extension team is concerned about breaking existing add-ons until their authors can update them (and all the addons with MIA authors who won't be around to update them).

For cases like Pendo.io I wonder if a better pattern would have been to sync the frames through the extension itself. If we ever got to the "no 3rd party cookies" world Chrome was pursuing with CHIPS, that, or storage access requests, would have been required anyway.

Local storage is used to communicate between multiple of our own pendo frames

storage is for state, not communication. Maybe the Broadcast Channel would be better suited? That's also partitioned and would be equally affected by this issue. I mention it as a general comment, not a "work around" for this (now fixed) regression. A "work around" would be for the frames to communicate via messages with the central extension.

Comment 15

[Daniel Veditz [:dveditz]]

avoid annoying users with storage access requests for content they presumably want their extension to be adding.

That presumption is often wrong, though: we discover and block a lot of shady extension, and are always finding more that slipped through. Permission prompts are annoying in the legitimate case, but their existence prevents bad extensions from trying things or aids in detecting them. The end result is that most users only see prompts in the cases that are "obviously OK" and therefore annoying.

Comment 16

[Colin Maxfield]

(In reply to Daniel Veditz [:dveditz] from comment #14)

(In reply to Tim Huang[:timhuang] from comment #5)

However, the current implementation doesn't support the document.requestStoreAccess(). We will always reject the call in the current implementation.

That part is clearly a bug. We are still arguing over whether injected frames should be partitioned by default, but they definitely shouldn't be less capable than a frame inserted by the original page.

There will be strong pressure to provide an option for extensions themselves to create frames with storage access enabled: both to keep old extensions working and to avoid annoying users with storage access requests for content they presumably want their extension to be adding. The security team would prefer that require an explicit action on the part of extensions that could be checked in review (maybe a permission? an option/argument/attribute in the API?), but Web Extension team is concerned about breaking existing add-ons until their authors can update them (and all the addons with MIA authors who won't be around to update them).

For cases like Pendo.io I wonder if a better pattern would have been to sync the frames through the extension itself. If we ever got to the "no 3rd party cookies" world Chrome was pursuing with CHIPS, that, or storage access requests, would have been required anyway.

Local storage is used to communicate between multiple of our own pendo frames

storage is for state, not communication. Maybe the Broadcast Channel would be better suited? That's also partitioned and would be equally affected by this issue. I mention it as a general comment, not a "work around" for this (now fixed) regression. A "work around" would be for the frames to communicate via messages with the central extension.

There are definitely better options for us in the long run and with enough heads up (like Chrome has attempted to do but sometimes failed pretty badly) we can move towards the other options. The current state of things is mostly legacy though at this point, this is back from when Pendo had to support much older browsers with different limitations and so the code for the extension and standard Pendo are the same. We do actually requestStorageAccess to get access to unpartitioned storage but we currently get to that point in our code since we will also try to use partitioned localStorage before that point. Chrome (as far as I know) will always let us use the partitioned storage without storage requests but then we have to request (with user interaction which we do) access to unpartitioned. Our use of localstorage to communicate between frames is very much legacy at this point (at least 6 years old) and exists from time when we needed wider browser support.

Comment 17

[Colin Maxfield]

Daniel do you know if this by chance got reverted back to the "broken" state? I am seeing the same failures that happened before but I am having a hard time finding the change listed in nightly.

Comment 18

[Rob Wu [:robwu]]

We re-enabled the functionality, with an exception for document requests, which ought have prevented this regression, in bug 1973018. If you are experiencing this bug again, could you create a new report and add reproduction steps? Ideally with a minimal self-contained extension/test case.

In the future, if you are interested in identifying a (recent) regression, use mozregression: https://mozilla.github.io/mozregression/

Comment 19

[Colin Maxfield]

(In reply to Rob Wu [:robwu] from comment #18)

We re-enabled the functionality, with an exception for document requests, which ought have prevented this regression, in bug 1973018. If you are experiencing this bug again, could you create a new report and add reproduction steps? Ideally with a minimal self-contained extension/test case.

Okay thank you, I will work on getting the simple repro case up because yeah we are back to the same state as the initial report it seems.

In the future, if you are interested in identifying a (recent) regression, use mozregression: https://mozilla.github.io/mozregression/

I have never used this before, thanks for the recommendation, I will add it to my tool bag.

Comment 20

[Colin Maxfield]

(In reply to Rob Wu [:robwu] from comment #18)

We re-enabled the functionality, with an exception for document requests, which ought have prevented this regression, in bug 1973018. If you are experiencing this bug again, could you create a new report and add reproduction steps? Ideally with a minimal self-contained extension/test case.

Actually it looks like I can use your same steps from comment #6 to repro the issue, I will file it as a new bug

Comment 21

[Colin Maxfield]

Here is the new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1973808