Intent to Implement: Storage Access API

[Brandon Maslen]

Contact emails

br...@microsoft.com

 

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/StorageAccessAPI/explainer.md

 

Design doc/Spec

https://docs.google.com/document/d/1q5Q-8MJcfZamGAXLpjiXiPYR1Tov5JOGw0Z8Fv0TWFk/

 

Summary

The Storage Access API is a JavaScript API intended to allow access to first party storage in a third-party context when a user has provided direct intent to allow content that would otherwise be blocked by the browser’s current configuration.

 

Motivation

As privacy is becoming increasingly important to users, requests for stricter browser defaults and user opt-in settings like blocking all third-party storage access are increasingly common. While these settings help improve privacy and block unwanted access by unknown or untrusted parties, they can have unwanted side effects such as blocking access to content the user may want to view (e.g. social media and embedded media content).

 

Users shouldn't have to compromise between privacy protections and enabling sites' embedded content to function correctly. The Storage Access API is a JavaScript API that allows fine-grained control of storage access permissions when access would otherwise be denied by the browser's current settings. Sites with meaningful scenarios that depend on loading third-party resources will be able to leverage the API to allow the user to explicitly choose, on an as-needed basis, when to allow more permissive access.

 

Risks

Interoperability and Compatibility

Edge: Intent to implement (this request)

Firefox: Shipped in 65

Safari: Shipped in 11.1

Web Discussion: https://github.com/whatwg/html/issues/3338 - includes other Chromium implementers and web framework developers.

https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

 

Ergonomics

This is a standalone API addition. There are scenarios where storage access is restricted, e.g. when third-party cookies are disabled, and in those cases the access result is currently static. In scenarios where the Storage Access API is used to grant access these APIs will now have dynamic behavior regarding permission.

 

Activation

There are existing implementations and documentation of this API is available on MDN. Sites that need to update may need to introduce more logic to defer storage access prior to permission potentially being granted async.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

 

Link to entry on the feature dashboard

TBD

 

Requesting approval to ship?

No – Will develop behind runtime flag and send a follow up I2S

[Rick Byers]

Adding this API to chromium makes sense to me. It's becoming broadly supported across browsers, and mechanisms for improving user privacy is a goal of the chromium project.

As the explainer calls out, adding the API is entirely independent from any change in storage policies. So simply shipping this API won't, by itself, change what storage is accessible.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40e40e1d-d6ce-4c3b-9f37-62107854e352%40chromium.org.

[rhal...@google.com]

I think this requires a review of the privacy team as well.

On Friday, July 26, 2019 at 10:33:04 PM UTC+2, Brandon Maslen wrote:

Contact emails

b...@microsoft.com

[bay...@gmail.com]

Ramin-- For such review, do we need to do something specific to loop the "Privacy Team" into the discussion? Thanks!

[rhal...@google.com]

I think at this stage it can be done by sending the design doc to chrome-privacy-core@.

Thanks,

Ramin

[Mike West]

Note that this is something that Microsoft engineers are implementing, and Edge is aiming to ship. An internal Google process is unlikely to help them make informed decisions. :)

-mike

--

-mike

[rhal...@google.com]

Thanks Mike,

I had not noted that it's only intended or Edge.

I will follow it up internally with privacy team.

Best,

Ramin

[Arvind Murching]

Hi Ramin, to clarify, the API (scope of the I2I) is intended for use by any Chromium-based browser, not only Edge. I defer to you and Mike about the scope and applicability of the privacy review that you alluded to.

Mike or Rick - I believe this needs an entry in chromestatus.com, is that correct?

Thanks

Arvind

[Brandon Maslen]

Status entry: https://www.chromestatus.com/feature/5612590694662144

Ramin, if you do decide a privacy review is warranted and are able to loop us into the process that would be appreciated.

Brandon

[rhal...@google.com]

Hi Arvind, Brandon,

It's in privacy team's queue. Will loop back when it's done.

Best,

Ramin

[mme...@google.com]

I'm not a big fan of the idea of interpreting a user gesture as consent - this has been heavily abused in the past.  Clicking on an inactive part of a window to focus it relatively isn't consent, nor is pressing the down arrow, for instance.  I'm seen quite a number of sites use various forms of gesture harvesting to either pop up new tabs, show ads that violate the better ads standard, create tiny Windows at the lower right of the screen, etc, all without anything I'd consider clear used consent to do so.  Highlighting text to use as a search query also isn't consent.

The common abuse of this model really concerns me, as does the assumption that casual use interaction in any manner is consent.

[roll...@gmail.com]

I am a big fan of of informed consent - and the relationship between the web-developers and users. It currently seems to be the general idea that users are in need of protection and we web-developers are sinister and always trying to pull a fast one on them. That's why we have to put up with user gestures, non-autoplay, media engagement index and other issues. We will always try to keep the user-experience as streamlined as possible so that users are able to use our systems as painless as possible. If this means we have to "abuse" the user-gesture to be able to dispatch an audible signal to user - because she got new messages, or an incoming webrtc call - so be it. We don't call it abuse though - we call it necessary. 

[Matt Menke]

That's not something I'd consider abuse.  I define abuse as behavior that users do not want, and takes advantage of web APIs to force that on the user (Note the cases cases I listed - hidden tiny windows to spam a user when they navigate away, abusive ads, unwanted new tabs).  The same facilities that allow web devs like you to make great experiences, other actors can and have abused in large number.  I can only speak for myself as an end user, but I care a lot more about protection from abusive actors (which are present even on legitimitate news sites) than most anything else.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/e5fu5Q06ntA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9bafa933-bfed-4a3c-beae-c62e4e38f30b%40chromium.org.

[Jochen Eisinger]

I agree that gating this on user gesture doesn't seem necessary (e.g. in Chrome, we inform the user that access was blocked in any case). I assume it's what Firefox and Safari shipped, however?

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvo1Gwx%2BgRBzmi4A7SUzHyQUDnFD8oJz4SET2CUzbGnmyQ%40mail.gmail.com.

[Brandon Maslen]

The user gesture primitive may not be perfect and could potentially benefit from rethinking within the platform as a whole as there are other actions gated on this like Matt mentions (e.g. popup creation) that could potentially be abused if users are tricked into generating a gesture they'd otherwise not have created. However I think rethinking user gestures is out of scope of this API.

While it is true that the other implementations (Firefox/Safari) rely on user gesture to gate the potential success of requesting storage access so we should follow suite it is also something I don't think should be removed. If the API was not gated on user gesture then any script could silently request access without any interaction (why wouldn't you try?) which would mean either a number of requests silently get granted or we would have to prompt the user more frequently and potentially on page load without any interaction with the embedded content. The current proposal does try to balance the goal of not prompting users too frequently as well as not being too liberal with what is granted from the limited signal of a user gesture by only allowing a small number of ephemeral grants using user gesture alone and progresses to requiring a prompt to be accepted. This is a tweakable knob though and can be adjusted as the usage of the api is seen and if use/abuse cases warrant. 

To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9bafa933-bfed-4a3c-beae-c62e4e38f30b%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Michaela Merz]

Why don't we take a page from the Android or iOS permissions cook book? When a web-app requires certain permissions, it will ask the user if she is willing to grant those. Yes, this would be inconvenient for regular web-sites, but your run of the mill website shouldn't even require any special permission. Web developers could even bundle all permission request into a single popup? which could (and should) additionally explain why the website / webapp requires the permissions in the first place.

As usual .. just my 2 cents.

m.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d92ded6-3147-4dd2-aa0b-199ee4cb8502%40chromium.org.