Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

111–120 of 532 posts

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

#112
post #111

A browser feature I wasn't aware of for too long: long press the back button, to get a list of recent URLs, allowing you to skip anything trying to hijack the back button.

That’s surely bounded now much it can show, so an attacker can just fill it up till the api throws an error

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

#113

> Notably, some instances of back button hijacking may originate from the site's ... advertising platform I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.

This feels like a reasonable counter-measure.

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

#114
post #73

> Notably, some instances of back button hijacking may originate from the site's ... advertising platform I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.

While i agree, the current JS security model rally doesn't allow for distinguishing origin for JS code. Should that ever change, advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.

The advantage would be that I know beforehand, and have the opportunity to test and, possibly, reject, what the advertiser want me to send to someone’s browser.

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

#115

Earlier quoted context omitted.

i love it. my mac doesn't have the home row (don't know if that's how that row of buttons is called) so I use spacebar and shift+spacebar as pgdown and pgup when I am reading

They're called the navigation keys. Fn + Up/Down (arrow keys) is PgUp/PgDn, and Fn + Left/Right is Home/End. But of course, those keys are on completely opposite sides of the keyboard, so Space is more convenient.

yeah, with spacebar i can use either of my hands while the arrow keys would require me to use both of my hands

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

#117

Earlier quoted context omitted.

They're called the navigation keys. Fn + Up/Down (arrow keys) is PgUp/PgDn, and Fn + Left/Right is Home/End. But of course, those keys are on completely opposite sides of the keyboard, so Space is more convenient.

yeah, with spacebar i can use either of my hands while the arrow keys would require me to use both of my hands

I am often annoyed Mac does not have a right Ctrl or a right Fn.

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

#118

Easy fix: JS doesn't let you change back button behaviour. Q. But what about SPA? A. Draw your own app-level back button top left of page. Another solution: make it a permisson.

Yeah, no thanks. I want to use my browser’s standard keyboard shortcut to navigate back. And also forward again. And I want to be able to inspect the history listing before I go back or forward.

Let the browser do the browsery things. Don’t make SPAs suck even more than they already do.

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

#119
Amazing change, fighting with the back button is my least favorite part of the ad web and a blindspot for ublock. I wonder how Google is going to track this and if SPA style react router sites would be downranked because of the custom back button behavior. I doubt it due to their popularity but I'm curious how they're going to determine what qualifies as spam

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

#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 homepage first (location.replace(...) doesn't change the browser history). Then the browser history state is pushed to the original link. So it seems like you landed on the home page first then you clicked on a link. When you click the back button, you are taken back to the homepage where your feed entices you to stay longer on LinkedIn.

Post reply on HN