Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pes10k opened this issue Mar 3, 2020 · 36 comments
Closed

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

pes10k opened this issue Mar 3, 2020 · 36 comments
Assignees
Labels
OS/Android Fixes related to Android browser functionality OS/Desktop privacy-pod Feature work for the Privacy & Web Compatibility pod QA/No release-notes/exclude webcompat/not-shields-related Sites are breaking because of something other than Shields. webcompat/shields Shields is breaking a website.

Comments

@pes10k
Copy link
Contributor

pes10k commented Mar 3, 2020

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 pes10k added webcompat/not-shields-related Sites are breaking because of something other than Shields. webcompat/shields Shields is breaking a website. privacy-pod Feature work for the Privacy & Web Compatibility pod labels Mar 3, 2020
@pes10k
Copy link
Contributor Author

pes10k commented Mar 12, 2020

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

@pes10k
Copy link
Contributor Author

pes10k commented May 26, 2020

@pes10k
Copy link
Contributor Author

pes10k commented Jun 30, 2020

@pes10k
Copy link
Contributor Author

pes10k commented Jun 30, 2020

@pes10k
Copy link
Contributor Author

pes10k commented Jul 8, 2020

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

@pes10k
Copy link
Contributor Author

pes10k commented Jul 19, 2020

Would remove the need for this exception: #10494

@dlecan
Copy link

dlecan commented Nov 23, 2020

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
Copy link
Contributor Author

pes10k commented Nov 25, 2020

@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
Copy link

dlecan commented Nov 25, 2020

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

@bogger33
Copy link

bogger33 commented Feb 10, 2021

@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

@anthonypkeane anthonypkeane added OS/Android Fixes related to Android browser functionality OS/Desktop labels Feb 11, 2021
@pes10k
Copy link
Contributor Author

pes10k commented Feb 13, 2021

@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
Copy link

@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
Copy link

@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
Copy link
Contributor Author

pes10k commented Mar 18, 2021

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)

@pes10k pes10k closed this as completed Mar 18, 2021
@pes10k pes10k added this to the 1.21.x - Release #5 milestone Mar 18, 2021
@kjozwiak kjozwiak modified the milestones: 1.21.x - Release #5, 1.22.x - Release Mar 19, 2021
@kjozwiak
Copy link
Member

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

@pes10k
Copy link
Contributor Author

pes10k commented Mar 19, 2021

@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
Copy link
Member

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 ?

@kjozwiak kjozwiak added QA/No and removed QA/Yes labels Mar 19, 2021
@pes10k
Copy link
Contributor Author

pes10k commented Mar 19, 2021

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
Copy link

dlecan commented Apr 6, 2021

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
Copy link
Contributor Author

pes10k commented Apr 6, 2021

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

@dlecan
Copy link

dlecan commented Apr 7, 2021

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

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

image

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
Copy link
Contributor Author

pes10k commented Apr 7, 2021

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

@pes10k
Copy link
Contributor Author

pes10k commented Apr 8, 2021

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
Copy link

dlecan commented Apr 9, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS/Android Fixes related to Android browser functionality OS/Desktop privacy-pod Feature work for the Privacy & Web Compatibility pod QA/No release-notes/exclude webcompat/not-shields-related Sites are breaking because of something other than Shields. webcompat/shields Shields is breaking a website.
Projects
None yet
Development

No branches or pull requests

7 participants