(In reply to :Ehsan Akhgari from comment #14)
(In reply to Luca Greco [:rpl] from comment #13)
We would still like to keep IndexedDB and localStorage working in the WebExtensions pages while cookieBehavior is set to 2, nevertheless the effect it has in the WebExtensions pages for the third party cookies sounds like something we may reasonably want to avoid.
Those two statements seem to be contradictory, no? Consider the fact that cookies and other forms of storage are in fact one thing (irrespective of the mechanism used to access the storage): client-side storage.
I don't disagree, I understand why all the form of client side storage should be blocked on all websites when that preference is set to
BEHAVIOR_REJECT = 2, and that is why we agreed with :asuth on that change as part of Bug 1406675.
In short the reasoning was that:
users that choose to set "Accept cookies from websites" as disabled don't expect the Extensions to break with that settings, because users do not perceive extensions as part of the websites, they consider extensions more similar to a part of the browser (and so there was a mismatch between the "user expectations" and the side-effect it had on the extensions).
(And, as an additional side note, extensions can also control the
cookieBehavior preference using the
privacy.websites API and by doing so, without the changes introduced by Bug 1406675, they were going to be able to break other extensions, or even the same extension that originated the call to
Now, when WebExtension pages are in third-party context, are you suggesting they should or should not have access to client-side storage?
Before bug 1406675 they did not. After bug 1406675 they do now.
This is only partially true, the extensions can also use browser.storage.local and browser.storage.sync as other forms of client-side storage, and so technically the extensions were able to use other forms of client-side storage with cookieBehavior set to 2 even without the changes introduced by bug 1406675.
We can go back to the behaviour before that bug. But a mixture of behaviours across different storage APIs makes the least amount of sense to me...
yeah, as I said above I agree, and I'm not sure that there is something that we could do differently that still make sense based on the meaning that the cookieBehavior should have, but I've not yet been able to "convince myself" that this issue can be closed just as "expected behavior" (even if the behavior is actually expected), nor that going back to "before Bug 1406675" is an option.
Nevertheless, based on this issue, it seems to me that there is still a mismatch between the "users expectations" and the actual behavior that the extension pages currently present:
the part that seems to do not match the "users expectations" is that the Extension are still accepting cookies (and then send them back automatically) from third party services that the extension may fetch data from internally, despite any value the user could have set on the cookieBehavior about:config preference.
With the current implementation (with the changes from Bug 1406675) when the principal is an extension principal the cookieBehavior preference is completely ignored and the behavior is always set to nsICookieService::BEHAVIOR_ACCEPT, and what I'm wondering is if "completely ignoring the cookieBehavior" was our only option, or if we could instead still allow cookieBehavior to have an effect on the extension pages on some extent.
As an example, could a strategy similar to the following be something that would still make sense and at the same time better match the "user expectations"?
- when the current principal is an extension principal
- leave behavior unchanged if it is nsICookieService::BEHAVIOR_REJECT_FOREIGN
- set behavior to nsICookieService::BEHAVIOR_REJECT_FOREIGN for the extension principals, if it is
set to nsICookieService::BEHAVIOR_REJECT for all the websites
(well, at that point I would also ask myself if a behavior set to nsICookieService::BEHAVIOR_LIMIT_FOREIGN or nsICookieService::BEHAVIOR_REJECT_TRACKER should also be leaved unchanged and what would be their meaning for an extension page).