> > 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 > browsing. > > Yes. This is right. But I don't think we should block postMessage(). Btw, the same issue can be used as workaround for document.requestStorageAccess().
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 new cookie policy - at least until the page is reloaded. - 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 promise-based). This is a different model compared with cookie policy. Cookie policy is a kind-of internal browser setting which should not be exposed to webpages when changing. Cookie permission is a way to implement exceptions on top of the cookie policy. We should not treat the cookie 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
