Bug 225297 – ITP: Storage on subdomains of the same eTLD+1 is incorrectly partitioned

• Component: DOM
• Status: NEW

[Mattias Svanström]

Created attachment 427549 [details]
Reproduction files

According to https://webkit.org/tracking-prevention/ storage partitions are isolated to the same registerable domain / eTLD+1.

An example is given where 

> sub.news.example is considered first-party when loaded under news.example because they are considered to be the same site.

However, this is currently not working and storage for a.news.example gets a unique partition when embedded under news.example. This applies to LocalStorage, SessionStorage and IndexedDB. For cookies it seems to be working as intended (the embedded iframe's cookies are not partitioned off).

I am attaching two .html files on how to reproduce. They are also deployed on https://account.mmso/ and https://app.mmso.se/

This is working on Chrome and Firefox.

[John Wilander]

Hi! Thanks for filing. Is this a regression or behavior you've seen for long? Is it only in Safari or other clients using WebKit? If it's recent and Safari-only, it may be the same as https://bugs.webkit.org/show_bug.cgi?id=225344.

[Mattias Svanström]

Created attachment 427689 [details]
cross-site-tracking

[Mattias Svanström]

Hey John

We've seen this issue for some time yeah indeed. We are able to reproduce it on Safari 11.

The setting flag "Prevent cross-site tracking" has an effect. If it's enabled, it gets incorrectly partitioned on the same domain

[John Wilander]

(In reply to Mattias Svanström from comment #3)
> Hey John
> 
> We've seen this issue for some time yeah indeed. We are able to reproduce it
> on Safari 11.

Safari 11 is fairly ancient. Current version is Safari 14.*. Are you really saying Safari 11?

I'd be most interested to hear about Safari 14.0 and 14.1 since those are the most recent.

> The setting flag "Prevent cross-site tracking" has an effect. If it's
> enabled, it gets incorrectly partitioned on the same domain

[Mattias Svanström]

Sorry for the confusion. I meant that it's been an issue in every version since at least Safari 11 up until the current version. And possibly earlier, but I didn't test further back than that.

[Mattias Svanström]

To be clear this is happening on the current version too (Safari 14.*)

[John Wilander]

(In reply to Mattias Svanström from comment #5)
> Sorry for the confusion. I meant that it's been an issue in every version
> since at least Safari 11 up until the current version. And possibly earlier,
> but I didn't test further back than that.

Then it sounds more like a thing to fix in documentation.

[Mattias Svanström]

IMHO this should be considered a real bug, despite not being a regression, as the documentation makes more sense than the behavior.
In particular, cookies are correctly partitioned by eTLD+1, and an iframe can access subdomain-specific cookies even if it's embedded under a different subdomain in the same eTLD+1. And if it's embedded under a different eTLD+1, it can use the Storage Access API to get access to its cookies.
However, an iframe can't access its own LocalStorage if it's embedded under a different subdomain in the same eTLD+1. Using the Storage Access API also has no effect, presumably because that API correctly detects that the iframe is embedded under the same eTLD+1, so there should be no need to use this API.

In the ProtonMail web app, we would prefer to use LocalStorage rather than cookies, as we don't want this data to be sent to the server (for privacy reasons). The current behavior seems to push web developers towards cookies rather than LocalStorage, for no good reason, as far as we can tell.

[Radar WebKit Bug Importer]

<rdar://problem/77738085>

[Florian Schulz]

I think this issue is related to me bug report at:
https://bugs.webkit.org/show_bug.cgi?id=231879

foo.site.com embeds bar.site.com

bar.site.com gets treated as Third-Party and only gets partitioned + ephemeral storage.

Shouldn’t this be treated as a First-Party embed?