Prevent cross document access via policy

[dtapuska]

Consider adding a policy to prevent same origin cross document access.
See: https://github.com/dtapuska/documentaccess as an alternate for issue 2757.

@annevk @bzbarsky

[annevk]

I like the general idea, but I wonder what boundary we are looking for. E.g., if we want these documents to (potentially) end up in different processes, the isolation needs to be at a different level (the agent cluster key) as otherwise there would still be shared memory between these documents, for instance.

And as these "window" agent clusters really belong to the browsing context group, this seems like the kind of thing to decide when the browsing context group is created.

[dtapuska]

I'm not thinking strictly about enforcing process isolation. More like I want to embed this content and it really doesn't have to interact with my content so let me limit the scope I expose to it. So I don't think it necessarily ties into the agent cluster key.

ie. having two documents directly scriptable probably isn't widely used and it should be easy to opt out of it.

[annevk]

Unless we also provide the ability for UAs to optionally process-isolate them it's not entirely clear to me it's worth it. Otherwise they can still (accidentally) share memory via SharedArrayBuffer and affect each other's execution flow.

[dtapuska]

I think these are good points. I probably want to make the definition of the js bindings dependent on the agent cluster key and then adjust the agent cluster key based on the feature policy. Is that what you were thinking?

[annevk]

Yeah, other things to resolve:

1. Should this be per-origin or per-document.
2. Should you be able to enforce this same-site, but cross-origin.
3. How does this affect further embedded or auxiliary browsing contexts' documents. (If they use the normal key again they would have same-origin access, destroying the encapsulation, which makes me think this needs to be decided at browsing context group creation or per-origin, but there might be further alternatives. I didn't consider this too long.)

And then depending on the resolutions to those there's more, I suspect.

[dtapuska]

Are not all your points addressed how feature policies work? If set on an iframe it is on the container policy, otherwise documents can opt into it via the header.

[annevk]

I don't understand how I'm afraid.