But the question is: why are sites allowed to hijack the Back Button?!?
Because it has a legitimate use. As anything, the tools will be abused by malicious actors
A new spam policy for “back button hijacking”
31–40 of 532 posts
Re: A new spam policy for “back button hijacking”
#32Cool, now maybe let's do something about all the shit I have to clear out out my face before I can read a simple web page. For example, on this very article I had to click "No thanks" for cookies and then "No thanks" for a survey or something. And then there was an ad at the top for some app that I also closed. It's like walking into some room and having to swat away a bunch of cobwebs before doing whatever it is you…
Haha, we had a solution for that, called pop-up blockers. Then when they became very usable, everyone switched to overlays injected with javascript, so they became unblockable. 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 c…
I'm waiting for someone to develop an augmented-reality system that detects branded ads or products, compares them against a corporate-ownership database, applies policies chosen by the user, and then adds warning-stripes or censor-bars over things the user has selected against.
It would finally put some teeth behind the myth of the informed consumer, and there would be gloriously absurd court-battles from corporations. ("This is our freedom of speech and commerce, it's essential, if people don't like what we're doing they can vote with their wallets... NOT LIKE THAT STOP USING SPEECH AND COMMERCE!")
Re: A new spam policy for “back button hijacking”
#33But the question is: why are sites allowed to hijack the Back Button?!?
So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Re: A new spam policy for “back button hijacking”
#34Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.
What does this have to do with sites being buggy? This change is about obvious intentional abuse.
Re: A new spam policy for “back button hijacking”
#35Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.
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...
Re: A new spam policy for “back button hijacking”
#36Earlier quoted context omitted.
I’d go back in a heartbeat. Making the web a software SDK was the worst thing to happen to it.
You talk about 1995 but I wouldn't even go back to 1999. Dialup was so painful. It advertised 56 know but in practice I never even say 48...
That seems like a separate thing. You can send 199x-era HTML over a gigabit connection.
Re: A new spam policy for “back button hijacking”
#37Earlier quoted context omitted.
It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).
It wasnt "fine".
Oh, the social media was much, much better. People much more open, tracking didn't exist. All the idiots still thought computers were only a thing for nerds and kids.
Re: A new spam policy for “back button hijacking”
#38Cool, now maybe let's do something about all the shit I have to clear out out my face before I can read a simple web page. For example, on this very article I had to click "No thanks" for cookies and then "No thanks" for a survey or something. And then there was an ad at the top for some app that I also closed. It's like walking into some room and having to swat away a bunch of cobwebs before doing whatever it is you…
Your problems have been solved for more than a decade. Set your browser to open pages in reader view by default and you don't have these issues.
Re: A new spam policy for “back button hijacking”
#39Frustrating it took this long for something to be done about this, but glad its now got something being done.
> When a user clicks the "back" button in the browser, they have a clear expectation: they want to return to the previous page. Back button hijacking breaks this fundamental expectation. 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.…
What about all the very legitimate uses of programmatically adding history entries?
Re: A new spam policy for “back button hijacking”
#40Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?
It's a valid question how they detect it. As there are valid usages, just checking for the existence of the function call would not be correct.
These sites likely pushState on consent actions so it appears like any user interaction.