Top-Frame lifetime, partitioned storage for embedded frames

[pes10k]

Currently frames can either have storage blocked or allowed, w/o an in between. This is unideal for several reasons. Some examples include

1. There are cases where two eTLD+1 equiv frames on the same page may wish to work together (and to use storage to do so) but are currently unable to without relying on the first party for intermediation.
2. Users may wish to prevent frames to have storage for privacy reasons, but to not have the embedded party's functionality break. Partitioned frame length storage would allow users / implementors a way to, by default, give frames storage "only for as long as i'm using it".
3. Frames may appear and disappear while a user is interacting with the top level frame. An option to tie the embedded frame's storage-lifetime to the top level frame provides a in-standard, temporary way for storage to be persisted for the third party, but only for as long as the user is interacting with the 1p.

Safari's current approach of persistent, partitioned 3p storage allows more than is needed in such cases, and other browsers "all block or all allow" approaches allow either too little (storage is blocked), or way too much (un partitioned storage).

The proposal here is to provide an in-standard way of defining the following:

1. By default all 3p frames created during the lifetime of the top level frame have storage cleared once the top level frame is closed
2. Two eTLD+1 equiv frames see the same storage area
3. These storage areas are partitioned (e.g. A under B sees different storage than A under C or A as top level)
4. Storage Access API allows frames to request persistent, unpartitioned storage

[michaelkleber]

Very interesting indeed! We've been thinking about something similar — or perhaps with a slightly longer "single-site session" lifetime, where A-under-B keeps seeing the same storage until the user navigates away from B. This would serve additional analytics use cases like "I want a 3rd-party service to count how many pages a user visits before leaving my site", which otherwise end up using the first party's storage.

[othermaciej]

Neat idea. One possible challenge for this approach is cookies. We've found that partitioned third party cookies cause more compat issues than blocked third party cookies. But maybe this can apply to only non-cookie storages, or it could have some kind of explicit opt-in.

[annevk]

By top level frame is closed do you mean its browsing context group? What if multiple browsing context groups are open with the same sites?

[pes10k]

@othermaciej can you say more about the kinds of web compat concerns here? The reason we decided to start prototyping partitioned storage in this way (top-frame length) was to avoid issues of having long lived, partitioned cookies. In this case, since the the embedded frame's storage is either a) ephemeral, partitioned and tied to the top level frame, or b) global-and-long-lived, I expect (hope) that we wouldn't hit the kinds of problems you hit with different sets of long lived cookies, as you'd have in WebKit. But, if your experience suggests otherwise, that would be enormously useful feedback!

@annevk @michaelkleber We hadn't deeply considered those kinds of cases to be honest, and would be very interested to discuss more about use cases and trade offs. It'd at least expand the possible scope of web compat issues (at least in practice, if not in principal), and would be more tricky (both in implementation, and thinking through how it interacts with other standards), but very interested to discuss more and think through the tradeoffs!

[pes10k]

Hi all, just to follow up on this, I mentioned the last time this was discussed on PrivacyCG that I'd report back once the study / paper part was done. Well its done! And Brave is finishing up an implementation of the above (looks like we'll land it a complete version in nightly in ~2 wk or so), though what we're shipping is slightly different than whats in the paper or described above.

https://arxiv.org/abs/2011.01267

Happy to discuss more if its of interest (the paper, what Brave is implementing, etc), but just mostly wanted to let the group know that Brave is still going forward with this and getting close to shipping.

[pes10k]

Just a heads up for the group, this has now been implemented in Brave https://brave.com/privacy-updates-7/

[TanviHacks]

@annevk and @pes10k - Would you like to talk about this proposal in the upcoming Cookies Ad Hoc discussion or a regular teleconference?

[pes10k]

Sure, Id be happy to share more about what Brave does if it'd be of interest to others (we've modified our policy slightly. No preference on my end between an ad hoc or "regular" call; happy to go with whichever the chair think would be best

[TanviHacks]

cc @annevk to add this into the Cookies Ad hoc discussion.

Sure, Id be happy to share more about what Brave does if it'd be of interest to others (we've modified our policy slightly. No preference on my end between an ad hoc or "regular" call; happy to go with whichever the chair think would be best

[annevk]

Added to https://github.com/privacycg/meetings/issues/16.

[annevk]

We did not get to this as part of the cookie discussion. It's probably also a broader topic as it applies to all partitioned state, including partitioned cookies, presumably. As such, marking agenda+ again for consideration for a future meeting.

[AramZS]

Reviewing this in advance of the PrivacyCG and wanted to note:

two eTLD+1 equiv frames on the same page may wish to work together (and to use storage to do so)

This is a fairly common use case for ad creatives in order to avoid repetitive creatives across a single page and one we'd like to see continued support for. Right now there are a bunch of creatives that do so using localStorage or cookies but presumably without this feature those creatives would push publishers to include a coordinating script on page, which would be an undesirable outcome.

[erik-anderson]

I have an additional scenario that's not super feasible today but likely would be if we had more partitioning knobs for sites to use.

Consider a scenario where top-level site A.example embeds B.example via two iframes and that it wants separate/partitioned storage between the two B.example iframes.

A concrete example of where this would be useful is if iframed origin B.example provides an embeddable chat app. Top-level site A.example wants to allow two different users of B.example to be loaded concurrently without B.example needing any special awareness of it.

If A.example could specify some partitioning key (perhap a "partitioning index" attribute set on the iframe prior to load), it could opt into more isolation for the embeddee if desired. The site could also choose to not provide a custom partitioning key in which case we would revert to whatever the desired default behavior ends up being.

[AramZS]

@erik-anderson I could actually see how that could be very useful as a web developer. I agree that the use case is not very feasible today, but I could see it easily enabling all new very useful development approaches, and giving more control on these things to the top level page is definitely desirable.