Re:Google Chrome to stop back-button hijacking
by nikanj on Wednesday December 19, 2018 @03:01AM
(#18714008)
A lot of seedier sites already abuse these mechanisms, by doing nasty things when you click to close a GDPR notification, focus a search box, or similar intention.
Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!
Re:Google Chrome to stop back-button hijacking
by ht85 on Wednesday December 19, 2018 @03:37AM
(#18714162)
Yeah but in that case the malicious website should only be allowed to push a single frame, allowing you to escape by going back twice.
This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.
Re:Google Chrome to stop back-button hijacking
by Trufa on Wednesday December 19, 2018 @01:38AM
(#18713576)
If I understood you correctly, if someone wanted to highjack my back history they could still do it on a random click? Is it only preventing non user interactive changes to the history or did I understand you wrong?
The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.
So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.
But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.