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 privacycg/meetings#16.