It seems pretty stupid. Instead of expanding the SEO policy bureaucracy to address a situation where a spammer hijacks the back button, the browser should have been designed in the first place to never allow that hijacking to happen. Second best approach is modify it now. While they're at it, they should also make it impossible to hijack the mode one.... oh yes, Google itself does that.

zero cookie banners

zero surveys popping up

zero ads to be closed

Just the text of the page with no other distractions in the way.

But thinking of this at this moment, this could be a good use for a locally ran LLM, to get rid of all this crap dynamically. I wonder why Firefox didn't use this as a usecase when they bolted AI on top of Firefox. Maybe it is time for me to check what api FF has for this

You are a decade behind in your life. Why didn't you look for a solution to your problems, does it feel better to complain?

Clicking the dismiss button on the cookie banner is not a reason to push a state that will show the user a screen full of ads when they try to leave. (Mentioning the cookie banner because AFAIK Chrome requires a "user gesture" before pushState works normally, https://groups.google.com/a/chromium.org/g/blink-dev/c/T8d4_...)

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...