Address third-party-cookie blocking

[jyasskin]

@wanderview keeps reminding us to consider browsers that block third-party cookies, and we keep failing to do it. Here's my attempt for portals:

When a portal is promoted, that's a navigation, which is a point at which any first-party page can pass arbitrary data via query parameters or even a POST body to a third-party as that third-party is becoming a first-party. So, while the <portal> is a portal, browsers should block its access to cookies/storage in the same way they block any third-party (which resembles the https://github.com/KenjiBaheux/portals/blob/master/explainer.md#constraint-2 restrictions), but then if it gets promoted, it can gain access to its cookies/storage without needing any state it's built up as a <portal> to be cleared. After all, with a cooperating first-party, it could pass that state up and then back to itself through the query parameters.

@wanderview, is that convincing, or have I missed something?

[wanderview]

I think you need to consider the partitioned origin case as well. For example, webkit "double keys" storage when origins are loaded as a 3rd party. Firefox also has some configurations which do the same thing. This is not as simple as blocking storage.

For example, a hostile page could load its entire partitioned database into memory and then check to see if its promoted to first party status. If it is, then it shoves all its precious tracking data into the first party storage to be exfiltrated later.

Of course, webkit has a similar issue with their "storage access API" which promotes storage to non-partitioned status without reloading. AFAICT their best answer to this issue of data cross boundaries is to hand wave "heuristics" as preventing promotion on these sites. Seems risky to me.

There are other APIs affected by this kind of partitioning as well:

• SharedWorker
• BroadcastChannel
• ServiceWorker

Its kind of unclear to me the implications of all this without a more concrete processing model to look at.

[KenjiBaheux]

For example, a hostile page could load its entire partitioned database into memory and then check to see if its promoted to first party status. If it is, then it shoves all its precious tracking data into the first party storage to be exfiltrated later.

I don't see how "check to see if its promoted to first party status. If it is, then it shoves all its precious tracking data into the first party storage to be exfiltrated later" could happen though.

Scenario:

1. The user is on a page featuring a portal pointing to an privacy-hostile page in the Isolated mode.
2. While still a <portal>, the hostile page has access to storage but under a unique origin (not sure if this is Chrome-only concept but this isn't an actual origin, it can't be addressed later on IUC).
3. The hostile page had 2 options to pick from beforehand in order to define what happens when navigated to via a portal.

• Continue to operate under its unique origin
• Reload itself under its canonical origin at the cost of losing access to the local state it had previously setup.

If the hostile page picked "Continue to operate under its unique origin", then it can't access or merge the data into its canonical origin storage.

If the hostile page picked "Reload to work under its canonical origin", then the unique origin data is lost and can't be merged into its canonical origin storage.

Am I missing something?

[wanderview]

If the hostile page picked "Continue to operate under its unique origin", then it can't access or merge the data into its canonical origin storage.

If the hostile page picked "Reload to work under its canonical origin", then the unique origin data is lost and can't be merged into its canonical origin storage.

I think this addresses my immediate concern, thanks. And I agree with the initial issue here that we can't do much if the first party is participating to funnel data out.

Note, we do have the concept of an opaque unique origin, but I'm not sure if they can access storage or not. That can be implemented, though.

[KenjiBaheux]

@wanderview @jyasskin Let me know if the PR resolves this issue.

[KenjiBaheux]

Tentatively closing.

[wanderview]

Sorry, I've had looking at this again on my todo list for the last week.

The PR looks reasonable based on our above discussion. I did think of another possible privacy issue with restricted mode in browsers that double-key, though:

1. Hostile page is opened in a restricted mode portal
2. Hostile portal cannot run js, but it can have markup that loads tracking subresources like images with a unique hash in their name.
3. When promoted to first party the hostile page sends an XHR/fetch to the server with the same unique hash.
4. Hostile page/server can now connect the first party storage state with the double-keyed cookie state.

Also, what should happen in the various portal modes if there are outstanding network requests? For example, the hostile server keeps the connection to the tracking image open for a long time instead of allowing it to complete normally. Should these be canceled, allowed to complete in the 3rd party context, or allowed to complete in the new 1st party context?

Finally, do you think browsers that do double-keying will be able to achieve the use cases desired here? It would seem if the portal site contains any kind of logged in information the promotion won't work as expected as content will need to change or the user will have to log back in, etc. Its probable I don't understand the use cases well enough, though.

[ericfs]

Hostile portal cannot run js, but it can have markup that loads tracking subresources like images with a unique hash in their name.

Would this network access be allowed in Isolated Mode?

It says:

Trusted entities must be able to serve complete Portal-aware pages. Web Packages, i.e. a bundle of Signed Exchanges, would enable this.

Does that mean that Signed Exchanges are required and all network access would fail?

[wanderview]

Hmm, maybe? I guess it would be nice to clarify it with an example if that is the case.

I'm a little confused by the second bullet there:

Communicate to browsers the desire to restrict network activity to privacy safe entities: the serving (trusted) origin, fresh assets in the local HTTP cache, the source origin. Web packages served with a self-contained hint would enable this.

Does that mean it could have a non-self-contained package that hits the same-origin server with a hashed resource? I guess it could use some clarification.

As a side note, it might be nice to summarize the concrete restrictions in another document or another section. Its kind of hard to see the whole picture when they are intermixed through the explainer with design discussion.

[ericfs]

Just submitted #9, which I think is a related question and also could be clarified with more details about restrictions.