Html: nullable window.top.

[jdalton]

I'm working on an implementation for isolating code and noticed that the window.top is non-configurable. I'd like the ability to null it or make it opaque within an iframe even if the iframe is of the same origin. Has iframe feature/capabilities for nullable or opaque window.top come up in some way or is there a proposal that more closely aligns along those lines?

Update:

Maybe an expansion or addition of a Feature-policy?

[jdalton]

I found the proposal I was looking for:
https://github.com/dtapuska/documentaccess 😸

[annevk]

That doesn't really address this as top is cross-origin accessible. Also, only masking top is rather insufficient as, e.g., parent is also cross-origin accessible.

[jdalton]

Unlike top, parent is mutable. Since we're creating the iframe we're first in and can remove/rewire access. If there is a way to make top of a same-origin iframe be treated like an opaque cross-origin window that would be rad too (null or opaque is great).

[jdalton]

@annevk You can see a proof of concept at here and checkout the examples/web-components demo.

[annevk]

Note that due to Spectre you cannot really run untrusted code securely in the same origin as your application.

[dtapuska]

As I indicated before as well in another topic. Making things mutable is just allowing the variable to be stashed on another variable before it gets nulled out. Things like this need to be done in a descriptive manner before the agents are constructed so they are prevented from construction time. That is what the documentaccess proposal addresses although I recognize that proposal doesn't address the problem you are trying to solve.

[jdalton]

As I indicated before as well in another topic. Making things mutable is just allowing the variable to be stashed on another variable before it gets nulled out. Things like this need to be done in a descriptive manner before the agents are constructed so they are prevented from construction time.

Yep, totally cool with that route. 👍

That is what the documentaccess proposal addresses although I recognize that proposal doesn't address the problem you are trying to solve.

Any possibility of expanding the scope to include things like just ‘top’?

[dtapuska]

No unfortunately the way the proposal works is that the bindings will check whether the agent cluster is the same or not. And if will fail if they aren't the same agent cluster. It isn't knowledegable about the "direction" of the access, ie. child to parent, parent to child, child to cousin/sibling, etc..

[caridy]

@annevk we are less concern about security (this feature request is not really about security in that sense), and it is focused on encapsulation and stability. The economics of Spectre and co. is probably another discussion.

[annevk]

FWIW, I have some interest in the opposite, letting a document declare that its cross-origin WindowProxy shouldn't be able to enumerate children as that's an existing leak and somewhat bad news for "iframe" sites. Doing this is maybe somewhat like the inverse of that, where the same-origin view cannot get certain properties. It seems worthy of exploration, but probably quite involved and tricky to get right. (Coupled with nobody being happy to touch WindowProxy as it's already one of the trickiest objects in the platform.)

The other wrinkle I have here is that there's probably a reason top was made unforgeable and breaking that could be bad security news for plugins, but maybe that's no longer a thing people care about. (This is also why Location is the way it is, for instance.)