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

Add a facility to allow specifying session-based third-party storage restrictions #1437

Open
ehsan opened this issue Jul 30, 2019 · 5 comments

Comments

@ehsan
Copy link

ehsan commented Jul 30, 2019

As various browser engines collaborate in the area of new privacy interventions, it's becoming increasingly important to be able to write web-platform tests for the cross-engine behaviour that web developers should be expecting when the policies applies by each engine would determine that cookies, storage and communication APIs need to be blocked in the third-party context. There are various use cases for writing such tests, including:

  • On by default privacy interventions shipped in browsers like Safari, Firefox, Edge and Brave.
  • APIs such as Storage Access API
  • Existing non-default privacy interventions shipped in almost all browsers, such as third-party cookie blocking

It's important to note that the desire to be able to write such tests isn't related to the default policy shipped in each browser. That is, while browsers may differ in what policies they apply to various browsing contexts, it would be nice to be able to converge on cross-engine behaviours for cases when a given browsing context has its storage and communication capabilities restricted based on some policy decision through the browser defaults or user configuration.

My strawman proposal here would be adding a list of restricted origins to each session, and then adding a few new endpoints in order to add to, remove from, and query that list.

With that, we would be able to create testdriver JS APIs which would allow us to write web-platform tests that for example add a wpt origin to this list, then test how the behaviour of loading an iframe from that origin changes, and then remove the origin from the list.

Feedback appreciated! (Please note that this is the first time I'm proposing something to webdriver, so I may be completely off base...)

+@johnwilander
+@annevk
+@Brandr0id

@pes10k
Copy link

pes10k commented Jul 30, 2019

This looks great! Would it be possible to amend the proposal to allow for configuring what storage policy should be imposed on each origin (session length storage, no storage, possibly more) as Brave is currently considering several approaches in this direction.

@ehsan
Copy link
Author

ehsan commented Aug 3, 2019

This looks great! Would it be possible to amend the proposal to allow for configuring what storage policy should be imposed on each origin (session length storage, no storage, possibly more) as Brave is currently considering several approaches in this direction.

Sure. Do you mean for example instead of blocking storage in the third-party context allowing it but restricting its lifetime to the end of the current session? I believe that would makes sense.

@pes10k
Copy link

pes10k commented Aug 4, 2019

Yea, I think that'd be useful, especially if some of the use case for the WebDriver extension is to experiment with new policies against live sites, and not only to test existing deployed policies.

@thejohnjansen
Copy link
Contributor

I think this sounds really useful. Initially, I'd like to implement as a Capability (probably vendor prefixed) in Chromium for both ChromeDriver and MSEdgeDriver. I wish we had been able to discuss this at TPAC... @AutomatedTester or @shs96c, do either of you have objections to this?

@bwalderman
Copy link
Contributor

@AutomatedTester, @shs96c, I'm helping the Privacy CG define a new extension command for this:
privacycg/storage-access#42

Would either of you be able to take a look? I'd like to get some expert input from the WebDriver side as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants