Deprecating same-documentness of navigations with a cross-origin initiator

[Camille Lamy]

Hi Blink API owners,

We have gotten reports of XS-Leaks which are based on the difference between cross-document navigation and same-document navigation (i.e. in one case you make a network request and re-layout the document, in the other you don't). We believe that in order to address them, all navigations initiated by a cross-origin initiator should follow the cross-document navigation path (and make a network request and layout the document). This would effectively turn existing same-document navigations into cross-document navigations when they are initiated cross-origin.

Same-document navigations with a cross-origin initiator happen in 0.03% of page loads. We're wondering if this is a level at which you would be comfortable with the change. Note that navigations would not be blocked, but just not treated as fragment navigations anymore, but a reload.

Thanks!

Camille

[Chris Harrelson]

Hi Camille,

Could you give us an example where a same-document navigation is caused by a cross-origin initiator?

Also, do you know which sites trigger this use counter?

Thanks,

Chris

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAMKsNvrDj%3DchPVLhWhcBUDYkq_dZnAaOJ3-963-woRc%3Dqj21LQ%40mail.gmail.com.

[Dominic Farolino]

I assume given informal approval, the plan is still to follow the normal launch process, and send an intent to deprecate or ship, make the corresponding standards changes, get other browsers on board etc., right? (Just making sure that this email isn't the only PSA/communication about this topic).

> Could you give us an example where a same-document navigation is caused by a cross-origin initiator?

The trivial case would be a main frame embedding a cross-origin iframe, and then assigning its location.href to a URL that's the same as the inner document, but with a fragment:

data:text/html,<iframe id=iframe height="400px" src=https://domfarolino.com/chromium-notes/></iframe><script>setTimeout(() => iframe.src+='%23testing',1500)</script>

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZstF3ahikHcC9aGE4FxmGFrQpGGKdiKDOBCcCqiw27KqQ%40mail.gmail.com.

[Camille Lamy]

 Yes, we would absolutely go through the normal deprecation process. But I wanted to check beforehand if the idea seemed reasonable given usage before kickstarting the whole process.

On Mon, Dec 16, 2024 at 4:12 PM Dominic Farolino <domfa...@google.com> wrote:

I assume given informal approval, the plan is still to follow the normal launch process, and send an intent to deprecate or ship, make the corresponding standards changes, get other browsers on board etc., right? (Just making sure that this email isn't the only PSA/communication about this topic).

> Could you give us an example where a same-document navigation is caused by a cross-origin initiator?

The trivial case would be a main frame embedding a cross-origin iframe, and then assigning its location.href to a URL that's the same as the inner document, but with a fragment:

data:text/html,<iframe id=iframe height="400px" src=https://domfarolino.com/chromium-notes/></iframe><script>setTimeout(() => iframe.src+='%23testing',1500)</script>

Yes, that's the kind of navigations that would now cause a reload of the iframe.

[Dominic Farolino]

I'm not an API OWNER, but from my HTML perspective, I think I'm personally fine with this change. It always felt a little weird to me that a cross-origin (likely cross-process) document could have this effect on another document, doing what feels to me like reaching into it and navigating it in a very specific same-origin-ey kinda way.

[Chris Harrelson]

On Tue, Jan 7, 2025 at 8:01 AM Dominic Farolino <domfa...@google.com> wrote:

I'm not an API OWNER, but from my HTML perspective, I think I'm personally fine with this change. It always felt a little weird to me that a cross-origin (likely cross-process) document could have this effect on another document, doing what feels to me like reaching into it and navigating it in a very specific same-origin-ey kinda way.

On Tue, Jan 7, 2025 at 4:32 AM Camille Lamy <cl...@google.com> wrote:

 Yes, we would absolutely go through the normal deprecation process. But I wanted to check beforehand if the idea seemed reasonable given usage before kickstarting the whole process.

On Mon, Dec 16, 2024 at 4:12 PM Dominic Farolino <domfa...@google.com> wrote:

I assume given informal approval, the plan is still to follow the normal launch process, and send an intent to deprecate or ship, make the corresponding standards changes, get other browsers on board etc., right? (Just making sure that this email isn't the only PSA/communication about this topic).

> Could you give us an example where a same-document navigation is caused by a cross-origin initiator?

The trivial case would be a main frame embedding a cross-origin iframe, and then assigning its location.href to a URL that's the same as the inner document, but with a fragment:

data:text/html,<iframe id=iframe height="400px" src=https://domfarolino.com/chromium-notes/></iframe><script>setTimeout(() => iframe.src+='%23testing',1500)</script>

Yes, that's the kind of navigations that would now cause a reload of the iframe.

I see. I can see sites doing this on purpose (ads or teaching UI maybe?).

0.03% may still be a risky threshold, depending on what sites are using it. It also sounds like something that could affect enterprise.

I'm supportive of going through the process to deprecate the old behavior and move towards the new behavior if it's necessary to prevent privacy leaks. But we'll need UKM on what sites are affected, plus an enterprise policy, and possibly a deprecation period with devtools warnings (depending on what UKM shows).