W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2018

Re: Storage Access API

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Tue, 09 Jan 2018 23:16:02 +0000
Message-ID: <CANh-dXmKZL-CVqe_rg-rM8b70uX2ofw2Rnwz=rWNC+W9V_Sktw@mail.gmail.com>
To: wilander@apple.com
Cc: public-webappsec <public-webappsec@w3.org>
On Tue, Jan 9, 2018 at 2:49 PM John Wilander <wilander@apple.com> wrote:

> Hi Jeffrey!
>
> And thanks for your comments.
>
> On Jan 9, 2018, at 2:24 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
> I *think* hasStorageAccess() could be defined as a piece of the permissions
> API <https://w3c.github.io/permissions/#permissions-interface>: (await
> navigator.permissions.query({name:'storage'})).state == 'granted'. Is
> there a particular reason you decided not to go that direction?
>
>
> The storage access we provide is tied to the document. Access goes away
> when you navigate the frame or detach from the DOM. Also, wouldn’t it be a
> little weird to have one piece on navigator and the other on document?
>

The permissions API does answer questions about the current
settings-object/global/realm, which are replaced in almost the same cases
that document is replaced. I'm torn about whether, given that, navigator
was the right place to put it, but it's stuck there now in any case. My
intuition is that it's still worth re-using that query API even if the
request function lives somewhere else, but I understand if other folks'
intuition disagrees.

> Is "storage" the right name for an API that governs cookie access and not
> access to other kinds of storage?
>
>
> As pointed out in the proposal, we do not see this API as limited to
> cookies. Only WebKit’s current implementation is limited in that way.
>

Ah, ok, I misunderstood the "The same problem" paragraph then.

Jeffrey

> The Permissions spec has a few algorithms at
> https://w3c.github.io/permissions/#requesting-more-permission that cover
> parts of your "Algorithm for requestStorageAccess()" and are designed to
> give different browsers the flexibility they need to provide their own UX
> as they think their particular users want.
>
> Restricting to 1st-level subframes sounds reasonable as a first attempt.
> In the long run, are you sure you want to prevent origins nested like "B
> inside A inside A" from accessing cookies
> https://wicg.github.io/feature-policy/ may have some useful ideas here.
>
>
> We would like the embedding top frame to be the parent of the frame that
> asks for storage access, especially if prompts are on the table. Also, it
> may be easier to avoid clickjacking if only direct children of the top
> frame can request storage access.
>
>    Regards, John
>
>
> On Tue, Jan 9, 2018 at 10:59 AM John Wilander <wilander@apple.com> wrote:
>
>> Hi WebAppSec and Happy New Year!
>>
>> Below you’ll find our proposal for Storage Access API. We discussed it at
>> TPAC. GitHub issue here: https://github.com/whatwg/dom/issues/560.
>> WebKit’s implementation will be available in Safari Technology Preview soon.
>>
>>    Regards, John
>> Storage Access APIProblem
>>
>> Tl;dr: Browsers that block access to third-party cookies break
>> authenticated embeds such as commenting widgets and subscribed video
>> services.
>>
>> In the context of cross-origin resource loads, cookies are popularly
>> referred to as third-party cookies. In reality, these cookies are often the
>> same as the first-party cookies so what we really mean with third-party
>> cookies is access to first-party cookies in a third-party context.
>>
>> A browser may have rules for third-party cookies that go beyond cookie
>> policy rules such as scheme, host, path, secure attribute etc. These
>> additional rules may be:
>>
>>    - Third-parties aren't allowed to set cookies,
>>    - Third-parties have their cookies partitioned or double-keyed, or
>>    - Third-parties have no cookie access.
>>
>> However, certain services are intended to be embedded as third-party
>> content and need access to first-party cookies for authentication. Examples
>> are commenting widgets, video embeds, document embeds, and social media
>> action widgets. These break if the third-party content has no access to its
>> first-party cookies.
>>
>> The same problem exists for other kinds of storage such as IndexedDB and
>> LocalStorage, except they are not tied to the HTTP protocol and are
>> typically not used for authentication purposes. From here on we will refer
>> to cookies except when the distinction between cookies and other storage
>> makes sense.
>> Proposed Solution
>>
>> Tl;dr: A new API with which cross-origin iframes can request access to
>> their first-party cookies when processing a user gesture such as a tap or a
>> click. This allows third-party embeds to authenticate on user interaction.
>>
>> We propose two new functions on the document:
>>
>> partial interface Document {
>>     Promise<bool> hasStorageAccess();
>>     Promise<void> requestStorageAccess();
>> };
>>
>> hasStorageAccess() can be called at any time to check whether access is
>> already granted and it doesn't require user interaction.
>>
>> requestStorageAccess() should only be called on user interaction such as
>> a tap or a click. It will check a set of rules and grant access if the
>> rules are fulfilled. Access to first-party cookies in the given iframe can
>> be assumed if the returned promise resolves. From that point, any sub
>> resource load in the iframe will have first-party cookies sent and incoming
>> cookies will be set in the first-party cookie jar.
>>
>> Note that no other third-party resources on that webpage are affected by
>> the storage access status of an individual iframe.
>> Algorithm for requestStorageAccess()
>>
>>    1. If the document already has been granted access, resolve.
>>    2. If the document has a null origin, reject.
>>    3. If the document's frame is the main frame, resolve.
>>    4. If the sub frame's origin is equal to the main frame's, resolve.
>>    5. If the sub frame is not sandboxed, skip to step 7.
>>    6. If the sub frame doesn't have the token
>>    "allow-storage-access-by-user-activation", reject.
>>    7. If the sub frame's parent frame is not the top frame, reject.
>>    8. If the browser is not processing a user gesture, reject.
>>    9. Check any additional rules that the browser has. Examples:
>>    Whitelists, blacklists, on-device classification, user settings,
>>    anti-clickjacking heuristics, or prompting the user for explicit
>>    permission. Reject if some rule is not fulfilled.
>>    10. Grant the document access to cookies and store that fact for the
>>    purposes of future calls to hasStorageAccess() and requestStorageAccess().
>>
>> Access Removal
>>
>> Storage access is granted for the life of the document and as long as the
>> document's frame is attached to the DOM. This means:
>>
>>    - Access is removed when the sub frame navigates.
>>    - Access is removed when the sub frame is detached from the DOM.
>>    - Access is removed when the top frame navigates.
>>    - Access is removed when the webpage goes away, such as a tab close.
>>
>> In addition, the browser may decide to remove access on a timeout basis
>> or on some dedicated user action such as switching cookie policy.
>> WebKit Specifics
>> WebKit's implementation of Storage Access API will be available in Safari
>> Technology Preview soon and on by default. It only covers cookie access,
>> i.e. no other storage mechanisms and the partitioning of them is affected
>> by a call to requestStorageAccess() at this point.
>>
>
>
Received on Tuesday, 9 January 2018 23:16:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 January 2018 23:16:39 UTC