search

privacycg / storage-access

The Storage Access API
https://privacycg.github.io/storage-access/
212 stars 27 forks source link

Storage Access and custom protocol frames #73

Closed csuwildcat closed 3 years ago

csuwildcat commented 3 years ago

For a site the user has added as a registered protocol handler for a safelisted scheme or web+ custom protocol, Storage Access seems as though it will break the use case of loading a registered protocol as an iframe's src to establish an app-to-app API channel.

To understand the use case, consider an example, web+wallet, wherein a user has added a site as its web+wallet handler. The web+wallet community ships a small lib to create a frame that loads the web+wallet protocol in an iframe's src, allowing top-level site to interact whatever site a user has installed for the web+wallet handler via the postMessage API conduit. It is important we not break protocol-loaded frames, as this is the only means installed handlers have to provide a background process/API channel to sites that integrate support.

Recommendation: because registering a protocol handler already requires a visit to the domain of the registered site and explicit user action to install a handler, protocol handler-loaded frames should be exempt from these requirements.

johannhof commented 3 years ago

Hello, thanks for filing an issue!

Just for my understanding, are you requesting that for custom protocol frames no storage restrictions should apply at all, or are you saying that the requirement of prior 1st-party user interaction should not apply?

Both of these aren't specified in the Storage Access API spec and you'd have to bring them up with the respective browser vendors, in the former case Mozilla, Apple/WebKit and Microsoft (maybe in the Chromium bug tracker).

In the latter case it should be a question only for Safari, since prior 1st-party user interaction is mostly a WebKit-only requirement (Firefox had it, then dropped it and we're now considering an intermediate solution of always showing a prompt without prior 1st-party user interaction).

In any case it doesn't seem like this issue is actionable for this repository, though it's possible I misunderstood, so I'm leaving this open for now to get clarification.

csuwildcat commented 3 years ago

@johannhof the action item here would be to ensure that frames loaded with registered protocol sources are not in any way bound by these requirements, even if hidden and not being interacted with by the user. These are the reasons for such an exception:

  1. To install a protocol handler for a safelisted scheme or web+ custom scheme a user must already have visited the origin of the installed handler directly
  2. The user also has to explicitly install a protocol handler via trusted UI prompt, the most overt signal we can get that they want to allow such interactions

For the reasons above, frames populated with protocol handler sources should not be subject to any Storage Access requirements. If you're saying this is somehow already the case, that is great, but I did not notice that called out anywhere. If it is not specifically called out and accounted for in spec text, I would like to get it in there. Shall I do a PR, if that is the case?

johannhof commented 3 years ago

@csuwildcat yeah, I think I understand your "why", but I'm not sure I understand what you're referring to when you say "Storage Access requirements". Is that the Storage Access API restrictions (e.g. calling document.requestStorageAccess shouldn't need user interaction), and if yes, which exactly? Or do you mean that browsers should not block or isolate third party storage for custom protocol frames at all?

csuwildcat commented 3 years ago

"browsers should not block or isolate third party storage for custom protocol frames at all" <-- this is the need. Many custom protocol apps in the decentralized web space use custom protocol handlers to enable wallet apps that act as agents for users. These apps, when loaded as frames, can be messaged to facilitate many activities for users, and doing so requires them to be able to access their own global storage state (their global Indexeddb storage, for example). Given protocol handler apps already have such a high bar of explicit user action required to even install in the first place, their frames should be exempt from isolation and all of these app-breaking blockages. I am coordinating with the Edge team to ensure we are able to continue using these features, but would like to see this addressed by the wider group - which calls are the best to attend to help ensure this is accounted for? Shall I submit a PR to this repo or some other to get this exemption language in?

johannhof commented 3 years ago

Aha, thanks for clarifying. So, this repo is probably the wrong place for that discussion (it’s for the Storage Access API which can be used by iframes that do not have 1st party storage access). I would recommend the following:

johnwilander commented 3 years ago

Just a comment from WebKit’s perspective. It’s not a great starting point to say “this must be changed, where should I send the PR?” Browsers and browser engines decide what they want to implement and support. In the case of access to global storage as a third-party, it’s a privacy boundary that some browsers have worked for many years to set up. In the case of WebKit we shipped storage partitioning in 2013 and got to full third-party cookie blocking in 2020. Punching holes in that storage policy is a big issue for us and needs to be discussed as such before any PRs and spec changes are made (unless of course the editors don’t agree with us and would like to just go ahead).

johannhof commented 3 years ago

Yeah, to be clear I’m not saying that Gecko is endorsing this proposal, I’m just trying to get it in front of the right group for discussion. I agree with John that this isn’t reporting a bug or unintended behavior but rather a proposal for explicitly weakening privacy guarantees that needs discussion before there can be a pull request of any sort.

csuwildcat commented 3 years ago

Just a comment from WebKit’s perspective. It’s not a great starting point to say “this must be changed, where should I send the PR?” Browsers and browser engines decide what they want to implement and support. In the case of access to global storage as a third-party, it’s a privacy boundary that some browsers have worked for many years to set up. In the case of WebKit we shipped storage partitioning in 2013 and got to full third-party cookie blocking in 2020. Punching holes in that storage policy is a big issue for us and needs to be discussed as such before any PRs and spec changes are made (unless of course the editors don’t agree with us and would like to just go ahead).

Yes, I'm aware - I worked at Mozilla for half a decade and am currently coordinating browser needs for the decentralized web/app ecosystem at Microsoft.

I have explainers and requirements in the works for Edge, but was looking to extend our concerns to a more general forum of discussion (wherever that is). I'll take a look at the places Johann cited. Full transparency: I will be firmly asking, across the stack, that we not break APIs and functionality the decentralized web/app community needs for their important work, which puts users first in a more bold way than ever before. Privacy, security, and user control are exactly what dweb is about, and we'd like to take all three many steps beyond the status quo.