Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

211–220 of 532 posts

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

#211

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…

LinkedIn is malware and it's frankly embarrassing that we seem to be stuck with it. It's like a mechanic being stuck with a wrench that doesn't just punch you in the face while using it, it opens your toolbox just to come out and punch you randomly.

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

#212
post #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.

So when you use a desktop app there is no back button but there is a switch to another app shortcut. Same idea.

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

#214
post #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!

This is my biggest gripe with modern browsers. Stop fucking with my keyboard. I want my keyboard to control my agent, not some script. No key seems to be safe. The quick-search key (/) is often overriden by "clever" web devs, but not even in a consistent way. Ctrl-K to go to the browser search box is gone. I use emacs keybindings in text boxes, but those can be randomly overriden by scripts (e.g. Ctrl-B might by overridden to make stuff "bold" etc.).

I want to be able to say "Don't let any script have access to these keyboard keys". But apparently that can't be done even with extensions. I've strongly considered forking Firefox to do this, but I know how much effort that would be to maintain.

How hard would it be to write scripts that expose an interface that the user can bind to keys themselves, if they wish to?

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

#215

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…

The problem is, there are two conceptions of the back button, and the browser only implements one. One conception is "take me back to the previous screen I was on", one is "take me one level up the hierarchy." They're often but not always the same. Mac Finder is a perfect example of a program correctly implementing the two. If you're deep in some folder and then press cmd+win+l to go to ~/Downloads, cmd+up will get y…

You're describing 2 different concepts, back and up, not 2 backs

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

#216
post #138
post #126

Earlier quoted context omitted.

I do not see this behaviour on the latest version of Firefox. I do use old.reddit, however.

I don't use old Reddit, and haven't noticed this behaviour either.

Sounds like maybe some prevention against this is already implemented in either particular Android browsers, or ad blockers, maybe even for specific sites?

Just speculating, I can't imagine a reason why they'd implement this especially for Safari.

Other than A/B-testing or trash code that coincidentally doesn't work in all mobile browsers.

Maybe they use the same AI that generates their fictious relationship stories to add these dark patterns to their code base :D

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

#217

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…

> You get a link from LinkedIn [or such]. 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, […] I've taken to opening anything in a new tab. Closing the tab is my new back button. In an idea world I shouldn't have to, of course, but we live in a world full of disks implementing dark patterns so not an ideal one. Opening in…

I do that everywhere, but it seems to fail for LinkedIn: they don’t redirect the link if it’s not in the same tab.

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

#218

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…

[dead]

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

#219
post #4

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

This is the price we pay for openness and decentralization. On one side, we have Apple giving us great APIs but telling us how to use them. On the other, we have W3C being extremely conservative with what they expose, exactly because of things like this.

This is the price we pay for stuffing browsers with tons of imperative APIs that the browser has no choice but to implement to the letter, since analysing how they are actually used runs afoul of Rice's theorem.
Post reply on HN