Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

131–140 of 532 posts

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

#131
I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.

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

#132

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 you to ~/, but cmd+[ will get you back to where you were before, even if this was deep in some network drive, nowhere near ~.

I feel like mobile OSes lean towards "one level up" as the default behavior, while traditional desktop OSes lean more towards tracking your exact path and letting you go back.

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

#133
post #77
post #73

Earlier quoted context omitted.

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.

> advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model. It will become harder for advertisers to deny responsibility for ads that violate their stated policies if they have to submit the ads ahead of time. Also site operators will need a certain level of technical competence to do this.

More likely, advertisers will need you to insert a "bootloader" that fetches their code and passes it to eval().

Alternatively, they might require you to set up a subdomain with a cname alias pointing to them (or a common CDN), negating any security benefits of such a practice.

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

#134
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.

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

#135

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…

> The problem is, there are two conceptions of the back button, and the browser only implements one.

In web browsers, there is only one concept.

There is no concept of "up one level in the heirarchy". If you want that make your own button in your website.

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

#136
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).

The web was not fine.

If you wanted to accomplish anything more substantial than reading static content (like an email client that beeps when you get an important email, or a chat app that shows you new messages as they come in), you needed to install a desktop app. That required you to be on the same OS that the app developer supported (goodbye Linux on the desktop), as well as to trust the dev a lot more.

We seem to have collectively forgotten the trauma of freeware. Operating an installer in the mid 2000s was much like walking through a minefield; one wrong move, and your computer was infected with crapware that kept changing your home page and search engine. It wasn't just shady apps, mainstream software (I definitely remember uTorrent and Skype doing this) was also guilty. Even updates weren't safe.

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

#137

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…

Desktop had this solved, on Windows there was and remains a distinction between "back" (history) and "up" (navigation).

Browsers actually used to have hierarchical navigation support, with buttons and all, back in the age of dinosaurs - all one had to do is to set up some meta tags in HTML head section to tell which URL is "prev"/"next"/"up". Alas, this has proven too difficult for web developers, who eventually even forgot web was meant for documents at all, and at some point browsers just hid/removed those buttons since no one was using them anyway.

The "Back" remains, and as 'Arainach wrote, it's only one concept and it's not, and never has been "up one level in the hierarchy".

EDIT:

The accepted/expected standard way for "take me up one level in hierarchy" on the web is for the page itself to display the hierarchy e.g. as breadcrumbs. The standard way to go to top level of the page is through a clickable logo of the page/brand. Neither of those need, or should, involve changing behavior of browser controls.

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

#138
post #126

Earlier quoted context omitted.

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.

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.

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

#139

I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.

Your game probably has poor SEO to begin with, so the Google Search policy changes would not apply

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

#140

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…

> one is "take me one level up the hierarchy." They're often but not always the same.

Who expects this behavior? It doesn't make sense. You just want to go back where you were. Most file browsers I've used wanting to implement going up a level in hierarchy, have an arrow pointing up.

Post reply on HN