Give non-eTLD+1 frames site-length, ephemeral storage

[pes10k]

Currently non eTLD+1 frames get do not have any storage, which means frames expecting normal acting localStorage, document.cookie, etc will have web compat problems.

non eTLD+1 frames should instead get

1. Empty storage (e.g. the frame at start doesn't see any stored values)
2. site length storage (all storage is deleted when all top-level frames pointing at the site are closed / deleted)
3. API compatible storage (e.g. document.cookie acts in the weird ways document.cookie acts, etc.)
4. Isolation from other ways of getting to the domain's normal storage (e.g. either prevent them from spinning up workers, or ensure that those workers get similar ephemeral / isolated storage)
5. partitioned-by-frame storage (two A frames under the same B frame see the same storage, but A frames under different B frames see different storage, A under B sees different storage than A under C or top-level-A)
6. (possibly) Storage Access API escape valve (sites wanting more storage can use storage access API to get global / unpartitioned storage)

[pes10k]

Note to self: check to see if this fixes #6046 when this is closed

[pes10k]

https://fivethirtyeight.com/videos/do-you-buy-that-biden-should-pick-a-running-mate-from-a-swing-state/ is another example of a site this would unbreak

[pes10k]

This would also unbreak https://community.brave.com/t/chart-is-blank-in-brave-browser/138464

[pes10k]

Would also unbreak https://www.rdocumentation.org/packages/grid/versions/3.6.2/topics/grid.plot.and.legend

[pes10k]

W3C related conversation on the updated version of this approach / idea privacycg/proposals#18

[pes10k]

Would remove the need for this exception: #10494

[dlecan]

Hi,
all Rocket.chat livechat widgets are broken on any sites because they are using iframes with null storages on Brave (example: https://unikname.com)
If any, what is the release plan of this feature?

Thank you

[pes10k]

@dlecan we're getting close! No promises, but looks like we might land an implementation in nightly in the next week or three (though the holidays might slow things down). It'd then take two releases (~6 weeks) for it to make its way to stable unless we do an uplift (which, given the need for testing here, is unlikely)

[dlecan]

Thank you!
Tell us as soon as a nightly embeds this new feature, I'd like to test it on my sites!

[pes10k]

Hello @bogger33; no it would not, there is not any way for a third party frame to access its 1p / un-partitioned storage. We also don't have any plans to implement storage access API, though we've considered it (I personally don't like the permission fatigue it seems to encourage). If the first party intends a tight coupling w/ a third-party frame like this, where the third-party needs long term storage, the best way (by design) to do this in Brave for the foreseeable future will be for the first-party to intentionally allow the 3p to use the 1p storage (and pass long term values back and forth with postMessage or similar.

That wouldn't solve the automatic login use, but, functionality wise, it would only require the user to login once per 1p.

I appreciate that this may not fulfill what you're looking for, but we think (or at least want to test whether) this will be best for our users, given the privacy/compat/convenience all the tradeoffs.

Thanks very much for your comment!

[dlongley]

@pes10k,

We also don't have any plans to implement storage access API, though we've considered it (I personally don't like the permission fatigue it seems to encourage). If the first party intends a tight coupling w/ a third-party frame like this, where the third-party needs long term storage, the best way (by design) to do this in Brave for the foreseeable future will be for the first-party to intentionally allow the 3p to use the 1p storage (and pass long term values back and forth with postMessage or similar.

This sounds like it would not support our use case, described here:

privacycg/storage-access#10 (comment)

Is there a version of the Storage Access API that Brave could implement that would not involve any prompts (presuming this is what you are concerned about with respect to permission fatigue)? Do you have any other suggestions for how to enable our use case in Brave?

[bogger33]

@pes10k
In my case, I control both domains and they point to the same server, however one of them hosts user generated HTML, and the other one houses the comment form and the main site. This was done all the way back in the age of ie6, when you couldn't safely host user generated html on the same TLD or a subdomain without risking letting users hijack accounts, and it's not possible to change it now. Would there be any way to do this if I am in control of both domains, and they're hosted on the same server/share full data access on the backend? I can easily run arbitrary scripts on both domains, but I'm not really sure how to authenticate one from the other with the way things work in brave

for the first-party to intentionally allow the 3p to use the 1p storage (and pass long term values back and forth with postMessage or similar.

could you elaborate what you mean by this? or do you just mean to move the login form to the first party domain that houses the comment form in the iframe currently, and then pass that on? that wouldn't work in our setup unfortunately

thank you for your response

[pes10k]

@bogger33 If you control both frames, you can use the main / 1p site as your permanent data store, and send those persistently-stored values to the third-party frame using postMessage, and then use those values as you like in the 3p frame. Just know (as in Safari, for example) that any values that are stored in the storage area of the 3p frame will be lost when the frame closes.

@dlongley the best I can suggest for now (besides an extension or browser integration) would be using 1p redirect, and bouncing the credentials back to the original site. So, in your example, rp.example would have a link to authn.io (which is where the 1p auth storage is if i understand correctly). User clicks that link, is taken to authn.io, which does what it needs to do, and redirects back to rp.example w/ the values in the URL or otherwise (basically, an oAuth flow). I think that'd work for ya, and as long as you steered clear of getting classified as a tracking origin by Firefox or Safari (as determined by Disconnect or ITP) you'd be fine in those browsers.

Brave also has upcoming plans for protecting against using the above pattern for bounce tracking, but nothing concrete yet.

Hope that helps!

[bogger33]

@pes10k I can't really do that, since hosting the login on the domain with the user generated html content is just an invitation for people to make phishing forms on that domain, and there's more than one domain the comment form gets embedded from (basically it's a site generator so people can hook up their own domain names). I guess I will also have to go with an oauth type of thing in a popup, although I was trying to avoid it since it adds a lot of friction for leaving a comment. I know it's not a simple problem to solve, but I wish there was a better way to transfer credentials accross domains that belong to the same site.

[dlongley]

@pes10k,

the best I can suggest for now (besides an extension or browser integration) would be using 1p redirect, and bouncing the credentials back to the original site. So, in your example, rp.example would have a link to authn.io (which is where the 1p auth storage is if i understand correctly). User clicks that link, is taken to authn.io, which does what it needs to do, and redirects back to rp.example w/ the values in the URL or otherwise (basically, an oAuth flow). I think that'd work for ya, and as long as you steered clear of getting classified as a tracking origin by Firefox or Safari (as determined by Disconnect or ITP) you'd be fine in those browsers.

Unfortunately, falling back to an oauth-style flow would defeat one of the main purposes of the credential handler technology. It was created, in part, to eliminate the problem of redirection and loss of state on the relying party. The polyfill works on browsers that support the Storage Access API -- but it is sounding like there is no clear and privacy-preserving alternative means to polyfill for Brave. I do hope the Brave team will reconsider implementing the Storage Access API in the future.

[pes10k]

Closing this issue since the feature has been merged in for a while, is on by default on Beta and Nightly, and being deployed to stable through Griffin (currently ~20% enabled)

[kjozwiak]

@pes10k is there anything that QA needs to do here? If so, is there any STR/Cases?

[pes10k]

@kjozwiak nothing other than the tests https://dev-pages.brave.software/storage/ephemeral-storage.html (which I think have already been tied to another related issue IIRC; there are several issues all relating to ephemeral storage)

[kjozwiak]

Sounds good 👍 Going to label this as QA/No. Is this something we should mention in our release notes or has this been covered in a previous release or another issue within 1.22.x ?

[pes10k]

I am not sure if its been mentioned in release notes (given that the roll out is being controlled by griffin), but i think a QA/No sounds 👍

[dlecan]

Closing this issue since the feature has been merged in for a while, is on by default on Beta and Nightly, and being deployed to stable through Griffin (currently ~20% enabled)

Awesome work!
Everything is working as expected on our site with Brave stable 💪 ... but only for the happy fews who have the "ephemeral-storage" flag enabled by default 😂
Do you know when this flag will be enabled for anyone?

[pes10k]

@dlecan it should be default on for all users now, as per brave/brave-variations#13. Are seeing otherwise?

[dlecan]

Thank you for the pointer, I haven't found anything about 'Griffin" before :)

Screenshot of https://griffin.brave.com/ a few seconds ago:

Beta variation is at 100%.

If I run Brave with "beta" variation (brave-browser --fake-variations-channel=beta), ephemeral storage is enabled.

What's wrong with release variation?

[pes10k]

thanks @dlecan , that is unexpected, i will talk to folks and get back to you shortly!

[pes10k]

Hi @dlecan looks like a task runner fell over when trying to deploy the "on for everyone" update. If you referesh https://griffin.brave.com/ you'll see we're at 100% for all channels now.

Thanks for letting us know!

[dlecan]

Enabled for everyone this morning and working as expected 💪
Thank you!