W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2017

Re: Isolated Origins

From: Emily Stark <estark@google.com>
Date: Tue, 25 Apr 2017 19:07:12 -0700
Message-ID: <CAPP_2SYrpVEjGCiFQCx6ELYgt=wNCQVJCO1nJaB5FcU0-E54Aw@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Charlie Reis <creis@google.com>, David Ross <drx@google.com>, Tanvi Vyas <tanvi@mozilla.com>
On Tue, Apr 25, 2017 at 3:27 PM, Alex Russell <slightlyoff@google.com>
wrote:

> A few questions:
>
>    - The note about needing to process Isolation before cookies is
>    interesting. Does it mean that this won't be possible to do from a <meta>
>    tag equivalent?
>
> Quite possibly, yeah. I unfortunately don't see how we can make this play
nicely with meta tags; if the page sets cookies before it goes into
isolated mode, those cookies won't be accessible.

>
>    - What's the issue with isolation and iframing? I'd have thought that
>    one of the valuable aspects of double-keying is protection from iframing.
>    That is, you can run your main service as isolated and if anyone iframes
>    you, the isolation won't be invoked (you'll be in the main storage
>    container) and therefore that "version" simply won't have ambient authority.
>
> Hmm, this could probably be made to work. One concern I have is whether it
makes double-keying not enough and we actually need to key by the whole
frame tree. If isolated1.com frames isolated2.com which makes a
cross-origin request to blah.com, do the cookies for blah.com need to be
triple-keyed? I think they might need to be to be consistent with the
threat model.

(Also, this makes me realize that we didn't write anything in the spec
about double-keying storage other than cookies; that needs to be addressed.
Oops.)

>
>    - I'd love a solution to opener disownership that's generic.
>
> Can you clarify this? I don't understand.

>
>    - I'm not sure I understand the serviceworker integration points. If
>    the behavior of isolation is double-keying when isolated, doesn't this just
>    imply that these are parallel (separate) SW registrations?
>
> I don't think I understand this question either. The point of the SW
integration is that a SW from the isolated origin must explicitly allow
navigations to the isolated origin, and they'll fail otherwise. Does that
clarify it at all?


> Thanks!
>
> On Tuesday, April 25, 2017, Emily Stark <estark@google.com> wrote:
>
>> On the last call, I mentioned that I would send out an "Isolate-Me"
>> draft. This is a proposal for a mechanism by which an origin can opt in to
>> isolate itself from other web content -- probably most useful for
>> high-value security-critical applications that are willing to give up some
>> functionality for such isolation.
>>
>> Please take a look at this faint ghost of a spec that aims to explain the
>> threat model more and nail down what these isolation mechanisms are:
>> https://wicg.github.io/isolation/index.html
>>
>> Any comments or feedback, either here or in the GitHub repo, would be
>> very welcome.
>>
>> David Ross (cc'ed) might also want to share some thinking he's done about
>> alternative shapes for the part of the proposal that deals with navigation
>> restrictions.
>>
>> Thanks!
>> Emily
>>
>
Received on Wednesday, 26 April 2017 02:08:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:22 UTC