In context of an moz-extension URL 3rd party cookies should not get blocked
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: Manuel.Spam, Unassigned)
References
Details
The "same origin policy doesn't seem to be applied in context of moz-extension URLs which at least allows to use the "fetch" API to fetch any URL that is needed for the extension to work.
But if "third party cookie access" is blocked in the Firefox settings, then accessing any URL via "fetch" makes them fetched without any cookies transferred to the server. This should be fixed. Accessing an URL from an extension should not count as being "third party" as this would force users to allow third party cookies globally to make some addons work as they should.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
This issues looks like the exact opposite of Bug 1525917, we discussed at length in that issue and we decided to make sure that, when "third party cookies" are globally disabled in the Firefox settings, the expected behavior is also extended to the extensions.
The discussion has been pretty long, and there are a lot of technical details included in the comments exchanged there, but to try to summarize it in a single paragraph:
The main reason for that outcome of that discussion was the fact that these cookies were still making a third party website able to track the user (through the extension), and the user had no way to know that the settings wasn't having any effect on the installed extensions (and so the extensions ends up to having more power over that decision than the user itself).
I'm closing this issue as invalid, because this is currently the expected behavior.
Nevertheless, if you don't mind adding some additional details in a new comment, I'd like to know more about the specific use case (or some specific misbehaving extensions), so that we can double-check if it we should reopen this issue and cover explicitly some additional specific scenarios that may have been missed in our previous discussions about this topic in Bug 1525917.
|
Reporter | |
Comment 2•5 years ago
•
|
||
Bug 1525917 was about disabling cookies. If you disable cookies and this breaks Addons, then that's OK for me. Noone should disable all cookies. It will break most of the internet anyway so why shouldn't it break Addons?
But if Addons accessing any cookie are considered "3rd party", then for some Addons the only way to work properly would be to tell users to allow 3rd party cookies globally. How does Chrome handle this?
For example if I want to write an Addon which, for example, synchronizes Bookmarks to an external service and to initially log in you just open the login page for this service into a new tab, then the user may log in and the cookie is set but if the Addon itself wants to transfer data and expects the session cookie to be set to be able to communicate, then this will fail as soon as 3rd party cookies are disallowed.
The "moz-extension" URL already has an exception for "Same Origin Policy" to access any URL that is required for Addons to work. Why not also add an exception for 3rd party cookies so an user is able to disable 3rd party cookies for additional privacy while browsing but still have Addons work that need cookies to be set?
In my case the relevant issue is this one: https://github.com/M-Reimer/android-pdf-js/issues/3
No access to PDF files behind logins as soon as 3rd party cookies are not allowed.
But for me it wouldn't be too difficult to work around this case. I already cache the "Referer" header from the initial connection to readd it to the "fetch" request done by PDF.js. I could also cache the "Cookies" header the same way to also reapply it to the "fetch" request which would allow my users to access PDF's even if a cookie has to exist to access it.
I just thought it may be a good idea to fix this globally to prevent incompatibilities with Addons so disabling 3rd party cookies is impossible if the user uses some Addon that needs session cookies to be set for accessing some login protected URLs.
|
||
Comment 3•5 years ago
|
||
FYI requests from moz-extension documents (NOT content scripts) are treated as first-party since bug 1629436 got fixed,
PROVIDED that the extension has host permissions for the URL.
Description
•