First-party-origin WindowProxy isolation

[annevk]

From mikewest/securer-contexts#2.

WindowProxy (and Location) leak a bunch of data that ideally would only be exposed through a mutually agreed postMessage() API. (This is a premise and it'd be great to hear pushback to this, if any.)

Given that premise, it'd be interesting to consider a new mode whereby that data is not exposed for a browsing context group. (It's not entirely clear to me it can be more granular as everyone kind of has to agree to this mode of operation as otherwise you can end up with very weird situations that might not be expected to all parties involved.)

If we had such a mode and you'd be looking at cross-origin things:

• Location would not be exposed
• WindowProxy would only expose postMessage().
• Window might have a new API that lets you find all your-party-origin WindowProxy objects. I'm not sure if this is a set of objects or if they need to provide some additional data as to whether that particular WindowProxy is a top-level or not.

(Another thing to consider is making more drastic changes also in the same-origin case, as the indexed/named getters are a source of issues there too, but that might make this harder to adopt. Thoughts welcome though. This is still very exploratory.)

cc @mikewest

[mikewest]

WindowProxy (and Location) leak a bunch of data that ideally would only be exposed through a mutually agreed postMessage() API.

Nit: I think the mutually-agreed bit is important. I wouldn't be dogmatic about it being agreed-upon via postMessage().

Given that premise, it'd be interesting to consider a new mode whereby that data is not exposed for a browsing context group.

This is an approach worth exploring!

I think it's also worth exploring what kinds of changes we could make without requiring opt-in. For instance, could we explore changing the window.frames/window.length contract to enumerate only cross-origin children? Could we make setting location a no-op for windows you didn't open? Can we neuter onload events by screwing with their timing?

As you note, that has a little more deployment risk, but it would also be more robust.

[annevk]

Are you saying that we cannot enforce a postMessage() API is agreed upon? If so, agreed.

I'm not thrilled about interventions, but they might well be worth exploring given the potential security/privacy wins.

[dtapuska]

I'm trying to reconcile how this is different than my proposal for the disallowdocumentaccess iframe attribute.

I believe we expose things but actually treat them as cross origin. ie. Location can be set but not read,