We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.
We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.
This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.
But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.
So, policy-based solutions make sense to me here.
[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...
Classify history API, canvas etc etc as "webapp" APIs, and have them show a similar dialog to the webcam dialog.
Then I can just click no, and the scripts on the page can't mess around.
Yes Google Maps is great. No, my favorite news site doesn't need that level of access to my browser or machine, it just needs to show some images and text.
The back button itself feels overloaded. There's "go to previous state" and then there's "go to previous origin." In an ideal world when I doubleclick on the back button what I mean is: "get me off of this site, now."
I agree. It may also require some extra work to figure out what the correct previous origin was, but this will also help legitimate cases where sites send you through 10 different redirects before you get to an actual site (looking at you Microsoft login).
SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.
If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.
We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.
We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.
This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.
But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.
So, policy-based solutions make sense to me here.
[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...
[2]: https://developer.chrome.com/docs/web-platform/soft-navigati...
> We tried a few times
Classify history API, canvas etc etc as "webapp" APIs, and have them show a similar dialog to the webcam dialog.
Then I can just click no, and the scripts on the page can't mess around.
Yes Google Maps is great. No, my favorite news site doesn't need that level of access to my browser or machine, it just needs to show some images and text.
The back button itself feels overloaded. There's "go to previous state" and then there's "go to previous origin." In an ideal world when I doubleclick on the back button what I mean is: "get me off of this site, now."
I agree. It may also require some extra work to figure out what the correct previous origin was, but this will also help legitimate cases where sites send you through 10 different redirects before you get to an actual site (looking at you Microsoft login).
What does this have to do with sites being buggy? This change is about obvious intentional abuse.
SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.
If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.
Honestly if your site is buggy in a way that effectively breaks the browser, maybe you should be punished.
I recommend 14 days in jail for the site owner, and, if egregarious, the engineer as well.
Not life ruining but just enough to be annoying. Just like their website.