Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

71–80 of 532 posts

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

#71
> Notably, some instances of back button hijacking may originate from the site's included libraries or advertising platform. We encourage site owners to thoroughly review their technical implementation...

Hah. In my time working with marketing teams this is highly unlikely to happen. They're allergic to code and they far outnumber everyone else in this space. Their best practices become the standard for everyone else that's uninitiated.

What they will probably do is change that vanity URL showing up on the SERP to point to a landing page that meets the requirements (only if the referer is google). This page will have the link the user wants. It will be dressed up to be as irresistible as possible. This will become the new best practice in the docs for all SEO-related tools. Hell, even google themselves might eventually put that in their docs.

In other words, the user must now click twice to find the page with the back button hijacking. Even sweeter is that the unfettered back button wouldn't have left their domain anyway.

This just sounds like another layer of yet more frustration. Contrary to popular belief, the user will put up with a lot of additional friction if they think they're going somewhere good. This is just an extra click. Most users probably won't even notice the change. If anything there will be propaganda aimed at aspiring web devs and power users telling them to get mad at google for "requiring" landing pages getting in the way of the content (like what happened to amp pages).

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

#72

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.

>Draw your own app-level back button top left of page.

This is the worst idea I’ve heard all day.

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

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

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

#74

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.

Can I preventDefault on mouse5? What about the physical back button on Android?

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

#76
That's cool if they can make it work.

I don't understand how Google's indexing work anymore. I've had some website very well indexed for years and years which suddenly disappeared from the index with no explanation, even on the Search Console ("visited, not indexed"). Simple blog entries, lightweight pages, no JavaScript, no ads, no bad practices, https enabled, informative content that is linked from elsewhere including well indexed websites (some entries even performed well on Reddit). At the same time, for the past few years I've found Google search to be a less and less reliable tool because the results are less often what I need.

Anyway, let's hope this new policy can improve things a little.

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

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

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

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

#79
Now do the Amazon app.

Number of times I've looked for something on my phone, gone through to a product page on Amazon but then have had to back out multiple times to get back to the search listing. Sometimes it's previously viewed products, sometimes it's "just" the Amazon home page. It should be one-and-done.

eBay too. I'm sure there are others.

Post reply on HN