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?
- 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.
- I'd love a solution to opener disownership that's generic.
- 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?
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
>