Re: Breaking the `opener` relationship.

On Fri, Apr 28, 2017 at 10:55 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Fri, Apr 28, 2017 at 10:39 AM, Mike West <mkwst@google.com> wrote:
> > Filed https://github.com/WICG/isolation/issues/12 to discuss, as I'd
> prefer
> > that approach to increasing the complexity of the `WindowProxy` checks
> > themselves.
>
> Sounds reasonable.
>
> Now, what happens when an isolated document messages with a
> same-origin document that is not isolated? Is that a risk we care
> about? If you have a capability-based security model you might hand
> around ports and assign authority to those ports. However, if these
> ports are introduced in your system through non-trustworthy pages (per
> the "people make mistakes" bit of the threat model), is that something
> we want to protect against? (Could also be a BroadcastChannel that
> starts emitting propaganda or some such.)
>

This is starting to verge back into the territory of the other thread. In
the hopes of keeping separate things separate: for the mechanism we're
discussing here, I think it's reasonable to say "Do whatever the existing
`WindowProxy` checks do." If they say do an same origin-domain check, then
do a same origin-domain check.

For the broader context, I generally agree with Charlie in
https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0074.html: I
would prefer for it not to be possible for a given origin to be loaded both
in an isolated and non-isolated way, both because it's hard to implement
and because it's hard to reason about.

If we do end up wanting to load both variants of a page, I think we'd need
to hook into the origin model in some way to make them sufficiently
dissimilar to fail a same origin-domain check. The `isolated` flag sketched
out in  https://wicg.github.io/isolation/#html-origin might be a reasonable
approach.

-mike

Received on Friday, 28 April 2017 09:34:39 UTC