Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

11–20 of 532 posts

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

#11

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

IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.

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

#13

Cool, 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…

Don't forget the useless "Got it!" popups, especially when the site blurs the screen to guide you to it.

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

#14
post #9

Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?

Because clicking on a navigation button in a web app is a good reason to window.history.pushState a state that will return the user to the place where they were when they clicked the button.

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

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

#16
post #7
post #4

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

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

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

#17

Cool, 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…

With uBlockOrigin set to default deny all the javascript on the page there are:

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.

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

#18
post #8

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

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.

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

#19
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!

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

#20
post #7
post #4

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

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.
Post reply on HN