A new spam policy for “back button hijacking” • Hacker News Board

Re: A new spam policy for “back button hijacking”

#471

Post by LorenPechtel » Tue, Apr 14, 2026, 9:49 PM UTC

kube-system wrote: post #418

jeffbee wrote: post #314

Earlier quoted context omitted.

I would just like to point out that this was one of the things that the AMP straightjacket prevented. The whole online news industry has conclusively demonstrated that it can't be trusted with javascript and must be hospitalized, but they refuse to acknowledge their own illness.

Is it news sites fault or is it the fault of web standards/browser developers for failing to build any viable mechanisms for monetizing content? The issue is hardly isolated to news outlets. It's endemic to the web.

Yeah, and I think it's pretty much impossible to solve.

Look what happened with Netflix. They actually got it right, a reasonable price for a bunch of stuff which would end up appropriated based on demand (they needed to have the disk to rent.) And how you have a bunch of players trying to compete in the space, each with it's exclusive content to try to make you choose them.

And look what's happened with Google's "news". It's more and more and more clickbait. I used to think the answer was a small charge per article, run through some aggregator that tracked payment. But these days we see things designed to get you to open the page, not to actually provide value. Or look at the problems Amazon has had with it's Kindle Unlimited stuff--books designed to game the metrics, groups engaging in read each other's books behavior etc.

Re: A new spam policy for “back button hijacking”

#472

Post by adrianmonk » Tue, Apr 14, 2026, 9:53 PM UTC

snowwrestler wrote: post #450

beastman82 wrote: post #298

Earlier quoted context omitted.

They've been crawling the web since inception

A web crawler reads page content, extracts content and URLs, places them into an index, and then follows links in that index to further build the index and content corpus. Google and others have special crawlers that execute JavaScript to crawl content delivered dynamically. Crawlers do not use the browser back button or browser history. So the only way Google could observe such problems is by observing live human br…

> Crawlers do not use the browser back button or browser history.

Couldn't you instrument the crawler's browser engine to observe whether (while crawling) the page does any behaviors that would result in back button hijacking? No back buttons have to be clicked.

You just have to watch whether the mousetrap is set. Since you know how mousetraps work, you don't have to grab the cheese.

Re: A new spam policy for “back button hijacking”

#473

Post by johnfn » Tue, Apr 14, 2026, 10:25 PM UTC

raydev wrote: post #453

declan_roberts wrote: post #392

Earlier quoted context omitted.

Ctrl+f is a bad offender. No I don't want to use your contextual search. I want to search for this word on this page!

If the page is lazy loading content then the local ctrl+f is not going to work, obviously. If you’re hinting at an argument about whether lazy loading content should exist, that’s a separate discussion. In my experience, pages that override ctrl+f do it for a good reason

I think I've seen one page override ctrl-f for good reason -- it was a page that lazy loaded literally millions of lines of text that wouldn't have fit into RAM.

Every single other page that does it just wastes my time. It's always a super janky slow implementation that somehow additionally fails to actually search through all the text on the page.

Re: A new spam policy for “back button hijacking”

#474

Post by SilentM68 » Tue, Apr 14, 2026, 10:34 PM UTC

That's a great step in the right direction since that happens to me all the time. But the penalty of "Manual spam action or automated demotion in Google Search results (as a 'malicious practices' spam violation)" seems a bit lenient.

Re: A new spam policy for “back button hijacking”

#475

Post by SilasX » Tue, Apr 14, 2026, 10:59 PM UTC

giorgioz wrote: post #121

firefoxd wrote: post #120

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

Also www.reddit.com is/was doing the same back button hijacking. From google.com visiting a post, then clicking back and you would find yourself on Reddit general feed instead of back to Google.

Even on old.reddit, it breaks the back button. When you navigate back, it usually reloads the entire page you were on and ignores all your collapse actions on conversations.

Re: A new spam policy for “back button hijacking”

#476

Post by arewethereyeta » Tue, Apr 14, 2026, 11:22 PM UTC

20 years too late SEO fix.

Re: A new spam policy for “back button hijacking”

#477

Post by nullc » Tue, Apr 14, 2026, 11:24 PM UTC

Maybe there should be a policy against links that display one destination but actually go somewhere else by changing the target with an onclick event.

oh wait.. that won't happen: google is the biggest offender, using that technique to surveil browsing activity.

Re: A new spam policy for “back button hijacking”

#478

Post by sam1r » Tue, Apr 14, 2026, 11:26 PM UTC

ffsm8 wrote: post #91

I would like to mention that Google own SPA framework, angular, has redirect routes which effectively do back button hijacking if used, because they add the url you're redirecting from to the history. https://angular.dev/guide/routing/redirecting-routes

That's only because SPAs routing maybe internal for that particular app. In that case, the UI/UX to end user is *only* possible and smooth when they hijack the back button as such.

Re: A new spam policy for “back button hijacking”

#479

Post by Barbing » Tue, Apr 14, 2026, 11:33 PM UTC

daemon325 wrote: post #427

mx7zysuj4xew wrote: post #397

Earlier quoted context omitted.

Kagi costs money and isn't that great to begin with

People just keep pitching Kagi as revolutionary, especially software engineers and people on HN. I respect a lot of them, people I respect a lot, and I saw people like Jon Gjengset use it. so I gave it a few months of daily use. I just eventually drifted back to Google. The results weren't better for anything I search for. It felt different, but not better in any measurable way. $10/mo for a different feel is a stran…

>$10/mo for a different feel is a strange value prop.

Thought Kagi would want the strange part to be, say:

"strange to let advertisers cover your monthly search bill, trading your privacy and using Google--we're only ten bucks a month!"

So, pay for peace of mind.

(do recognize $10 is an entire e.g. daily wage for some)

Re: A new spam policy for “back button hijacking”

#480

Post by Barbing » Tue, Apr 14, 2026, 11:34 PM UTC

venusenvy47 wrote: post #341

firefoxd wrote: post #120

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

Regarding Google and LinkedIn, I keep complaining to them about a stupid feature of Gmail. If I get an invitation from someone, Gmail puts "accept" as a button in the subject of the email - so if you aren't careful you can accept while you are scrolling through the subject lines. That is just the worst feature to put in their subject line.

Does "accept" support "undo send"?