Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

Post reply on HN
Print view View original

41–50 of 532 posts

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

#41

Post by wmf »

pottertheotter wrote: post #20
chongli wrote: post #7

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

Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.

You're not wrong but we've never really tried the combination of modern CSS with no JS. It could produce elegant designs that load really fast... or ad-filled slop but declarative.

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

#42

Post by itopaloglu83 »

twism wrote: post #23

Reddit! I'm looking at you?

Scroll on Reddit on mobile and click on a link. The comments open in a new tab. Close the tab and the previous tab is also at the link you’ve just closed.

Makes it impossible to browse around and long click to open on a new tab doesn’t solve the issue either.

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

#43

Post by transcriptase »

>We believe that the user experience comes first

I’ll believe that when YouTube gives me the ability to block certain channels versus “not interested” and “don’t recommend channel” buttons that do absolutely nothing close to what I want.

Or a thousand other things, but that one in particular has been top of mind recently.

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

#45

Post by not2b »

josephcsible wrote: post #33
mlmonkey wrote: post #29

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

If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.

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

#46

Post by Tepix »

SuperNinKenDo wrote: post #28
al_borland wrote: post #3

Some Microsoft sites have been very guilty of this. They are the ones that stick in my head in recent memory.

Happened to me yesterday through a link off here. I was already expecting it given the domain, but usually mashing back fast enough does the trick eventually. Not this time. Had to kill the tab.

In most browsers you can hold the back button for a second and it will let you skip back more than one step.

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

#47

Post by kiddico »

endgame wrote: post #19
musicale wrote: post #4

The iron law of web encrapification: every web feature will (if possible) be employed to abuse the user, usually to push advertising.

I cannot even reliably press [Space] any more to page down through sites that are meant to be all about content!

I've always found that behavior baffling so it's interesting to hear someone using it as intended instead of being frustrated by it.

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

#48

Post by bonesss »

pottertheotter wrote: post #20
chongli wrote: post #7

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

Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.

I published my first website in 1995 (and while it wasn’t even a little popular, eventually a spammy gay porn site popped up with the exact same joke name, leading to a pretty odd early “what if you search for your own site” experience).

If you put 2026 media players (with modern bandwidth), on the manually curated small-editorial web of ‘95 it’d be amazing.

We used to have desktop apps, these SPA JS monstrosities are the result of MS missing the web then MS missing mobile. Instead of a desktop monopoly where ActiveX could pop up (providing better app experiences in many cases than one would think), we have cross-platform electron monstrosities and fat react apps that suck, are slow, and omfgbbq do they break. And suck. And eat up resources. Copy and paste breaks, scrolling breaks, nav gets hijacked, dark mode overridden.

Netflix, Spotify, MS have apps I see breaking on the regular on prime mainstream hardware. My modern gaming windows laptop, extra juicy GPU for all the LLM and local kubernetes admin, chokes on windows rendering. Windows isn’t just regressing, their entire stack is actively rotting, and all behind fancy web buttons.

Old man yelling at cloud, but: geeeez boys, I want to go back.

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

#49

Post by mock-possum »

not2b wrote: post #45
josephcsible wrote: post #33

Earlier quoted context omitted.

So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.

Of course, but programmatically, how do you enforce that?

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

#50

Post by dataflow »

surround wrote: post #18
542458 wrote: post #8

Earlier quoted context omitted.

Are they? This seems about deceptive or malicious content (i.e., redirecting to ads) rather than “something in my history triggers a JS redirect”. I’ve definitely experienced the latter with MS, but never the former.

It seems like Google's policy is unconcerned with the intent of the practice. If a website JS redirect ruins the user experience by breaking the back button, it will be demoted in search results. It doesn't matter whether or not the redirect was meant to be deceptive or malicious, websites shouldn't be ruining the user experience.

> It seems like Google's policy is unconcerned with the intent of the practice.

I'm reading the opposite: "If you're currently using any script or technique that inserts or replaces deceptive or manipulative pages into a user's browser history that [...]"

Post reply on HN