> Presumably if there is an opener relationship between the tabs, things
> might be a little odd, because you can postMessage, but not use
> localStorage. So I don't think that this is exactly like private-normal
Yes. This is right. But I don't think we should block postMessage(). Btw,
the same issue can be used as workaround for
I get that this is difficult, but can you talk a bit about what you think
> the driving principles are here? You mention presenting a consistent
> experience with respect to access to state, which is a fine principle. If
> we model access to that state as a permission that can be actively
> requested by a site - as per - document.requestStorageAccess - how does
> that fit? (I confess to not having good kept up with developments on that
> API, so I apologize if this is off the reservation.)
requestStorageAccess is part of the Storage API and it's meant to be used
by 3rd party contexts, marked as trackers by the URL-Classifier. We
deliberately block their cookie jar before document.requestStorageAccess()
or before the heuristic. So, trackers are a corner case. We are planning to
create a fully separate cookie jar for them and I'll tell you more at the
end of this email.
I think I described why we should go in the direction of my proposal, in
particular for normal websites: performance; less code complexity;
consistency in APIs.
I would like to add a couple of reasons more:
- security/privacy/bugs: at the moment, many APIs are not able to deal with
changes in cookie permission/policy: after the changes, they behave as
before. This is definitely a bug, but it's also true that it's hard to
support these changes correctly and consistently. I would say:
security/privacy because each 'broken' API can be used to workaround the
- cookie permission vs other permissions: Let me compare geolocation and
cookie permissions: geolocation is strongly connected with 1 API and its
setting is usually triggered by that API (the user must accept it via
permission prompt, of course). The API knows that, in order to have geo
data, it must ask for it, and it must handle a possible rejection. The
workflow is: asking, permission granted or denied (callback-based, or
exposed to webpages when changing. Cookie permission is a way to implement
policy as a normal permission setting.
For the anti-tracking project, we are planning to introduce the concept of
'StoragePrincipal' (Q2?). The details are not finalized yet, but here is
the rough idea: a StoragePrincipal is, for non-tracker documents, equal to
the document's origin, which, in gecko-world, is called the NodePrincipal
(nsIPrincipal interface). For trackers, before having the storage access
permission granted, StoragePrincipal will be the NodePrincipal plus
first-party-isolation. This means that trackers will have a separate cookie
jar, double-keyed with the top-level origin: same tracker, as 3rd party on
different websites, will have separate cookie jars. We want to use
StoragePrincipal everywhere we give access to the cookie jar, such as
storage APIs, network/image cache and messaging APIs (BroadcastChannel,
Reporting API and so on).
When the storage access permission is granted (by the heuristic or by the
Storage Access API), we reset the StoragePrincipal to be equal to the
NodePrincipal and we recreate sessionStorage, localStorage and so on. At
this point, the tracker will have access to its first-party cookie jar.
There are several comments to do here:
- localStorage objects (or any other storage API) before and after the
permission granted will be different and, both will work after, but
pointing to different cookie jars.
- postMessages between window will work as it does today, because it will
use the NodePrincipal, and not the StoragePrincipal.
I suspect that all of this is out of topic. StoragePrincipal has been
discussed during several anti-tracking meeting and with during the last
All-Hands too. If interested I can send a separate email when we will have
a concrete plan.