search

WICG / scroll-to-text-fragment

Proposal to allow specifying a text snippet in a URL fragment
Other
589 stars 42 forks source link

Modify spec to allow text fragment when initiated from browser UI #102

Closed bokand closed 4 years ago

bokand commented 4 years ago

Fixes #101

Preview | Diff

bokand commented 4 years ago

Hey @arturjanc! Could you just gut-check that this is ok? It comes from feedback from Mozilla's standards-position.

I think that if the navigation is coming from browser UI then even if an attacker could listen to changes on the page it's ok to scroll/activate because they can't control the text snippet used. Is this right?

arturjanc commented 4 years ago

This seems reasonable to me overall, but in the Fetch Metadata spec we ran into a lot of nuance when trying to decide which navigations are coming from the browser UI (because we needed to set Sec-Fetch-Site: none for browser-controlled navigations, as opposed to Sec-Fetch-Site: cross-origin for web-controlled navigations).

The difficulty is that there are a lot of types of navigations in the grey area, e.g. the Open in new tab option in the context menu or a Ctrl+click on a link. In this case the website is under the control of the navigation URL, but the interaction isn't spoofable in the same way as a regular link click or interactionless window.location assignment is.

So my guess is that you may at some point need to define this more precisely, and it could make sense to align this with the logic in Fetch Metadata.

bokand commented 4 years ago

Thanks Artur, the Sec-Fetch-Site header does appear to have a very similar intent. I've added a note and TODO about this. (for practical purposes I don't think it matters quite as much here since we're determining whether to check for an isolated browsing context group but the grey areas like "open in new tab/window" will force that to happen anyway.