Re: Storage Access API

> On Jan 9, 2018, at 7:37 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Why do you need an API, as opposed to just opening access at the
> appropriate moment?

First, it’s desirable to have the iframe deliberately switch from one set of cookies to another instead of doing it speculatively just because the user clicks or taps in an iframe.

Second, the iframe will want to know the exact time when it has access to first-party cookies and can check for an existing session. At that point it may decide it needs to navigate the user to its site for login or inform the user of something.

Third, if prompting is involved, we want to limit it and have it be under the domain’s control, at least so that there is no prompt if the iframe doesn’t need or want storage access.

Finally, opening storage access and keeping track of it may be a semi-expensive operation involving inter process communication and maintaining session state. You only want to do that when requested to and not on arbitrary iframe clicks/taps.

> It's almost as though
> https://patrickkettner.github.io/cookie-change-events/ is what you are
> looking for, maybe with permissions API or feature policy hooks to
> support asking about the status of the API.  Note that permissions
> doesn't have an event API, and feature policy doesn't even have a
> query interface at all, so your approach is entirely justified.
> 
> I think that the push back here is trying to understand this more
> generally so that we don't add another bespoke access control feature
> on top of the many we already struggle to reconcile.

Sure.

   Regards, John

> (For the record, I'm not a fan of cookie change events, but largely
> only because I've little interest in improving something that we'd all
> be better of without.)
> 
>> On Wed, Jan 10, 2018 at 2:06 PM, John Wilander <wilander@apple.com> wrote:
>> 
>>> 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 04:26:40 UTC