Some thoughts:

1. We don't track the initiator of a navigation, so we don't even have the right bits plumbed through to even implement this.

2. Changing this behavior might expose potential attack vectors (maybe a page assumes that it can embed arbitrary data URLs without sandboxing?)… although this is already an unsafe assumption in Firefox. So I'm not sure how bad this really will be…

3. One gain from doing this is page info could show a more useful origin. We could do this without matching the spec behavior for data: URLs, but it feels weird to me of the browser and renderer report different origins…

Could we blanket allow cross-origin access to frames sourced with the "data" protocol?

> This behaviour in Chrome does not match Firefox.

It also doesn't match the spec. It does match WebKit, from which we inherited the behavior. I don't remember which way Edge chose... I'll have to look into that.

> We don't track the initiator of a navigation, so we don't even have the right bits plumbed through to even implement this.

Exactly. Implementing this correctly would be hard, and it's not clear to me that it would valuable.

> Could we blanket allow cross-origin access to frames sourced with the "data" protocol?

That would expose data from sites that are relying on either Chrome's current behavior or Firefox's current behavior (as pages that were previously cross-origin would magically become same-origin). I don't think it's something that's worth the risk.

`srcdoc` is a workaround that might be useful to you (since we do inherit origins for `<iframe srcdoc>` consistently, cross-browser).

We can't to do that: the same-origin policy is a fundamental building block of web security. This would let a page embed a data: URL and abuse it as a universal XSS vector to script any other origin.

> This would let a page embed a data: URL and abuse it as a universal XSS vector to script any other origin.

Is there an example of accessing a data: document becoming a gateway to other origins or is denying it more of a precaution?

> `srcdoc` is a workaround that might be useful to you (since we do inherit origins for `<iframe srcdoc>` consistently, cross-browser).

I was not aware of this, thanks!

> Is there an example of accessing a data: document
> becoming a gateway to other origins or is denying
> it more of a precaution?

Perhaps I misunderstood the original idea: my reading it's proposing any origin can access a frame with a data: URL. However, if frame A can access frame B, the reverse is also true: frame B can access frame A.

Thus, allowing this means a data: URL could access a frame with any origin, completely bypassing SOP.

> if frame A can access frame B, the reverse is also true: frame B can access frame A.

I wasn't aware access was always bidirectional, thanks for clarifying.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The spec shifted to match Chrome: https://github.com/whatwg/html/pull/1756