does not.

A recent change in chrome policies actually makes the lake of proper background splitting a fairly big issue. Chrome a while ago changed how webextensions can make use of requests. https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

This means that content_scripts no longer directly can do requests between subdomains even if permission is granted in the manifest. The suggestion given there is to move request to the background page of the webextension. Which is what we did for our extension and works fine except when users open up the website in incognito mode as there all requests are done from the regular context.

This is a huge privacy risk as far as I am concerned as I suspect that more webextensions will make this change or have made this change to accommodate for Chrome.

(In reply to creesch.r from comment #4)

This is a huge privacy risk as far as I am concerned as I suspect that more webextensions will make this change or have made this change to accommodate for Chrome.

Split mode extensions can still communicate with themselves between contexts, so implementing it does not gain what you think it does.

(In reply to Shane Caraveo (:mixedpuppy) from comment #5)

(In reply to creesch.r from comment #4)

This is a huge privacy risk as far as I am concerned as I suspect that more webextensions will make this change or have made this change to accommodate for Chrome.

Split mode extensions can still communicate with themselves between contexts, so implementing it does not gain what you think it does.

Are you sure about that? The way chrome implements it when you have a regular window open (window A) and an incognito window (window B)open you also get two background pages. The one for window A operates with sessions and cookies within the context of window A and window B does the same within the context of window B.

Also please read the chromium article about the cors change they made before drawing conclusions.

I wrote the above on my phone last night, I wanted to edit it to clarify a few things but it appears that I somehow can't. So apologies for the double post.

To sum it up here are the things in play.

• The Chromium project announced a few months ago in this article that content scripts will face much stricter CORS policies.
• In that article they suggest to move any request mechanism to the extension background page and make content scripts relay requests through browser.runtime.sendMessage.
• This affected our extension since it lives on a website with a variety of subdomains with an API that is not accessible from each subdomain.
• So we made the suggested change and everything did seem to work fairly well.

Now, here is where the context of the split permission comes into play:

• As it turns out any requests done from the background page are done in the context of the regular browser session.
• This means that even requests relayed from an incognito window get done through the regular browser session.
• Since our extension makes use of the user's session on the website to access the api this means that people in an incognito window started to get responses as if they where authorized with a session in the main window.
• This effectively means that data from the incognito and non incognito window starts to mix.

As a result we looked at the webextension documentation and found this MDN article about the incognito permission. Here it clearly states:

"split": the extension will be split between private and non-private windows. There are effectively two copies of the extension running: one sees only non-private windows, the other sees only private windows. Each copy has isolated access to Web APIs (so, for example, localStorage is not shared).

Implementing this and testing this out in any chromium based browser does indeed show that:

1. There are now two background pages. One for the non incognito context and one for the incognito context.
2. Requests done through a background page are now down within the context of the session they belong to. So
   • Requests relayed from an incognito content script are now returning data that indeed belongs to the session with which the user is logged in there.
   • Request relayed from a non incognito content script also return data corresponding to their respective session.

Impact

• The lack of a working split permission means we had to disable our extension in incognito mode.
• Since we had to do so proactively it means that by default there is a fairly big privacy impact as incognito still has an effect on the regular session.
• Considering that this is the result of chromium making this change I suspect that there are multiple other extension developers who will have made similar changes without realizing the impact and without the ability to make their extension function properly in incognito mode.

There are ways to deal with this, any of these should work:

• Keep a separate code path for Firefox where you do your requests in the content scripts.
• Use XHR to set cookies you retrieve using the cookies api.
• Use webRequest.onBeforeRequest to modify the cookies being sent (get the private cookies via the cookies api).

I understand split would make things easier for you, but even if we put this as our #1 priority you wouldn't see it any time soon.

Keep a separate code path for Firefox where you do your requests in the content scripts.

We are a small open source project with limited resources. Keeping two entirely different request methods around is less than ideal and likely will result in a less stable product. In fact I know it will as in the past we had to support firefox jetpack, chrome webextension and the safari method I'd rather not even think about again. We finally got to the point where supporting all major browsers could be supported with minimal browser specific code.

In that regard I don't think that the below suggestion is feasible either.

webRequest.onBeforeRequest

Because isn't that the same API that has been in the news lately regarding chromium possibly removing it?

Use XHR to set cookies you retrieve using the cookies api.

I didn't realize the cookie api can actually differentiate between the two contexts. Makes me wonder why it isn't possible to tell requests directly in which context they need to communicate.
In any case this might be a possible solution we will explore. Thank you for your feedback, I'd still think that there is a solid case for firefox supporting split background for the reasons I already mentioned.

(In reply to Shane Caraveo (:mixedpuppy) from comment #8)

There are ways to deal with this, any of these should work:

• Keep a separate code path for Firefox where you do your requests in the content scripts.
• Use XHR to set cookies you retrieve using the cookies api.
• Use webRequest.onBeforeRequest to modify the cookies being sent (get the private cookies via the cookies api).

I understand split would make things easier for you, but even if we put this as our #1 priority you wouldn't see it any time soon.

It turns out that this solution also doesn't work as it isn't possibly to set a cookie in the background page resulting in this result.

To clarify, the XHR route does not work.

Is there any progress on this feature?
If not could firefox just ignore the "split" mode so it does not throw an error for now?

I want to perform an XHR request in the background page to push HttpOnly-cookies into the current context's cookie store, but there is no way to define which cookie store (default or private) should be used for the XHR, so would there be any workaround for this?

I have been following the discussion for bug 1635490 a little bit where it is mentioned that extensions are encouraged to do requests through the background page. I was also attended to bug 1578405 at which point there is no way to work around the lack of proper split permission support.