Re: Storage Access API

> On Jan 9, 2018, at 6:27 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> I think perhaps I misunderstood what is going on.  Is this a new API
> to request access to something that the sub frame would ordinarily
> have access to if it were same origin or a top frame?

Yes, exactly. I had a feeling that that was the misunderstanding but I wanted to make sure. Sorry about not making it more clear.

> You are talking
> about dealing with the consequences of new browser policy that would
> deny access to these capabilities unless certain preconditions were
> met.

I think most browsers at least have opt-in policies that block cross-origin subresources from accessing or using their cookies.

Some browsers block or double-key cookie/storage access for cross-origin subresources by default.

The Storage Access API allows a cross-origin iframe to request access when the user interacts with it. Such interaction can be to start a video clip, initiate a checkout flow, or post a comment.

   Regards, John

> It seems to be that this is in an uncomfortable place between
> permissions (asking the user seems like a bad idea, but
> permissions.request() is clearly great) and feature policy.  I think
> that given the way that user interaction seems unlikely, permissions
> is a poor fit.  That is, even if .request() has some merit and feature
> policy apparently does not have an analogue.
> 
>> On Wed, Jan 10, 2018 at 10:24 AM, John Wilander <wilander@apple.com> wrote:
>> Hi Martin!
>> 
>> Thanks for your comments.
>> 
>> On Jan 9, 2018, at 3:13 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>> I have a few questions:
>> 
>> Does Safari prompt the user?  If so, what do you ask?  How do you
>> signal the source of the request?
>> 
>> 
>> The API proposal is not browser-specific. WebKit’s implementation does not
>> currently prompt the user but as you see in the proposal, prompts are an
>> option.
>> 
>> Why is postMessage insufficient for this purpose?
>> 
>> 
>> I don’t understand how postMessage can be used for this purpose. Please
>> elaborate.
>> 
>> Why is this not governed by feature policy and *disabled by default*?
>> 
>> 
>> I’m open to have it managed by feature policy but I think we’d like to have
>> the API enabled by default in Safari, i.e. as part of the default website
>> data policy.
>> 
>> It seems like you given example.com access to cookies from app.example
>> without any meaningful controls on access.  app.example would seem to
>> have no real control over this unless they somehow already chose to
>> sandbox iframes (which, despite being good practice, isn't uniformly
>> deployed).  I realize that some people might understand what it means
>> to exchange cookies such that a user prompt gets a meaningful signal
>> of informed consent, but that set might not be much larger than the
>> set of people reading this message.  Also, your message doesn't imply
>> that any of the possible access controls are mandatory.
>> 
>> 
>> The API doesn’t poke any holes in the same-origin policy if that’s what
>> worries you. Here’s an example:
>> 
>> Top frame: example.com
>> Sub frame: social.org
>> 
>> The browser’s cookie policy denies social.org access to its cookies under
>> example.com.
>> 
>> The social.org iframe calls document.requestStorageAccess() upon a click in
>> its iframe, the browser makes a decision, and access is either granted or
>> denied.
>> 
>> How does the sub frame access the storage APIs for the top frame?
>> 
>> 
>> It doesn’t, because of the same-origin policy.
>> 
>> window.parent.document.cookie?  How would you envisage access to other
>> APIs working?
>> 
>> 
>> Which other APIs? document.cookie changes with the storage access status if
>> that’s what you mean.
>> 
>>   Regards, John
>> 
>> 
>> On Wed, Jan 10, 2018 at 5:54 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 API
>> 
>> Problem
>> 
>> 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()
>> 
>> If the document already has been granted access, resolve.
>> If the document has a null origin, reject.
>> If the document's frame is the main frame, resolve.
>> If the sub frame's origin is equal to the main frame's, resolve.
>> If the sub frame is not sandboxed, skip to step 7.
>> If the sub frame doesn't have the token
>> "allow-storage-access-by-user-activation", reject.
>> If the sub frame's parent frame is not the top frame, reject.
>> If the browser is not processing a user gesture, reject.
>> 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.
>> 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 Wednesday, 10 January 2018 03:06:34 UTC