Hi all,

When the cookie policy or a cookie permission changes, firefox applies the
new behavior to any existing documents immediately. I would like to change
this, applying the new behavior to new documents only.

Let's start with an introduction. When I say cookies, I mean cookies,
localStorage, sessionStorage, indexedDB and so on: anything that composes
the cookie jar of a website (origin).

The user, in firefox, can choose between several cookie policies: They are:
- nsICookieService::BEHAVIOR_ACCEPT - the default one in release. Any
cookie is accept.
- nsICookieService::BEHAVIOR_REJECT - all rejected.
- nsICookieService::BEHAVIOR_REJECT_FOREIGN - 3rd party context's cookies
rejected.
- nsICookieService::BEHAVIOR_LIMIT_FOREIGN - 3rd part context's cookies
rejected if that origin has not been visited previously.
- nsICookieService::BEHAVIOR_REJECT_TRACKER - by default in nightly.
Cookies from trackers are rejected (it's a bit more complex than this, but
I need to simplify).

On top of this we have cookie permissions. They allow the user to set
custom cookie policies per origin. They are many, but, exposed to
UI/webextensions, they are only these:
- nsICookiePermission::ACCEPT_DEFAULT - follow the current cookie policy.
- nsICookiePermission::ACCEPT_ALLOW - accept all for this origin.
- nsICookiePermission::ACCEPT_DENY - reject any cookie for this origin.
- nsICookiePermission::ACCEPT_SESSION - accept cookies but make them
session only.

The reasons why I think we should not apply the new behavior to
live-documents are this:

*websites can break*
If we go from BEHAVIOR_ACCEPT to BEHAVIOR_REJECT (or ACCEPT_DENY), all the
storage APIs will start throwing exceptions (or reject promises). This is
an unpredictable behavior which can break the website's logic and makes the
storage APIs inconsistent. Note that this is different than blocking
cookies since the document loading.
Plus it doesn't give any extra security/privacy benefit: the website could
have already copied cookie data into local variables and it can still send
this data to the server.
If we go from BEHAVIOR_REJECT to BEHAVIOR_ACCEPT (or ACCEPT_ALLOW),
basically no website can "recover" itself without a reloading.

*complexity in our code base*
Some of our storage APIs have heavy code to switch between one cookie
behavior to another. For instance, sessionStorage and localStorage need to
choose the correct internal dataset at each getter/setter call, based on
the current cookie policy. They also need, in same cases, to move data from
1 dataset to another: for instance if we go from ACCEPT_DEFAULT to
ACCEPT_SESSION:
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/LocalStorageCache.cpp#184-209
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/SessionStorageCache.cpp#12-33

*performance*
This is not just a extra complexity, but it's also a performance issue:
checking the current cookie policy requires several steps: is the origin in
the content-blocking allow list? is the current window a 3rd party? is the
channel marked as a tracker? has this window being visited in the past? etc.
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/base/nsContentUtils.cpp#8085-8451
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/toolkit/components/antitracking/AntiTrackingCommon.cpp#785-1429

What I would like to do is this: each nsIChannel loading a document or a
subdocument content, stores the cookie behavior (permission + policy) for
its principal at creation time. The policy is applied to the whole
document's cookie jar and it doesn't change.
For BEHAVIOR_REJECT_TRACKER, when the storage access is granted (see
AccessStorage API and the anti-tracking heuristics), we recalculate the
document's cookie policy.

When the cookie policy or a cookie permission is changed, we inform the
user that the current tabs must be reloaded in order to apply the new
settings.

Of course, I don't want to apply the same logic to other permissions, such
as 'geo', 'fullscreen' and so on, because them are strongly connected with
APIs, user-interaction and permission prompting.

I want to conclude describing what other browsers do:
- Safari does something similar to what firefox is currently doing: cookie
policy is immediately applied.
- Chrome does something similar to what I propose: cookie policy is applied
to new documents only.

b
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to