Re: Storage Access API

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 <http://example.com/>
Sub frame: social.org <http://social.org/>

The browser’s cookie policy denies social.org <http://social.org/> access to its cookies under example.com <http://example.com/>.

The social.org <http://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.