Client-side redirects (e.g. Twitter t.co) loses user gesture, breaks text fragment

[kevinmarks]

I'm not sure of the exact mechanism, but tweeting or sharing a scroll to text fragment link via Twitter or Facebook does not work. As far as I can see the link expands correctly, but chrome does not scroll or highlight.
eg https://twitter.com/kevinmarks/status/1273197878354247681 contains http://microformats.org/wiki/process#:~:text=property%20name but that doesn't work when clicked, even though https://t.co/SZ7LTv4lUY?amp=1 resolves to it.
Is the 'hide things from the client page' paranoia in section 3.4 causing this?

[bokand]

No, sadly this is due to the user gesture requirement and client-based redirects. Twitter/Facebook/Google add a redirect for user generated links (e.g. in Twitter's case, all user links go to https://t.co).

We can propagate the fact that the navigation comes from a user gesture through an HTTP redirect (i.e. 301, 302, etc.) but these redirectors, for a variety of reasons, use a client-side redirect by replying with a 200 and some JavaScript that then sets window.location. This loses the fact that the navigation has a user gesture.

Chrome bug https://crbug.com/1055455 tracks this issue. Just realized we don't have a bug for it here so I'll rename and use this issue.

I think we could fix this by loosening the user gesture requirement slightly by propagating it specifically for text fragments through all navigations. That'd mean any given page load A could navigate to another page with a text fragment successfully without receiving a user gesture on page A. I suspect that might be workable; it would give an attacker a single text fragment navigation but I don't think this is novel, if you got a user to navigate to your page getting a single user gesture isn't hard. They still cannot perform repeated navigations without user gestures and we still have all the browsing context isolation requirements.

I'm also trying to better understand the use cases for client-side redirects rather than HTTP. There's a variety of interop bugs, UI bugs, and referrer behavior that's pushed redirectors to prefer a JS redirect. The reasons here are a mix of obsolete and existing. I'm trying to get a better sense of what's still preventing the switch and seeing if we can fix the underlying issues and get these redirectors onto HTTP redirects. This would be a long term push though so exploring this in parallel with the above.

Thoughts/ideas welcome!

[bokand]

Is the 'hide things from the client page' paranoia in section 3.4 causing this?

Regarding the paranoia, I've removed the spec text in #129 and opened #128 to discuss adding an API to be able to access this information.