Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

101–110 of 532 posts

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

#101
post #7

Earlier quoted context omitted.

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.

I would also go back in a heartbeat

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

#102

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

There are valid use cases however the issue is rooted in lacking browser APIs. For instance, - if you want to do statistics tracking (how many hits your site gets and user journeys) - You have a widget/iframe system that needs to teardown when the SPA page is navigated away - etc The browser does not have a; globalThis.history.addEventListener('navigate') So you must monkey patch the history API. It's impractical fro…

> - if you want to do statistics tracking (how many hits your site gets and user journeys)

You can do all of that server-side and much more reliably at that. The only reason to do any of this tracking client-side is advertisers trusting fake number go up more than sales numbers.

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

#103
post #83
post #80

This seems like a good time to advertise the post/redirect/get pattern. https://en.wikipedia.org/wiki/Post/Redirect/Get Not strictly about hijacking back navigation but it can make experience less bumpy if you've got form submissions in the middle of the path.

I'm a huge fan of this pattern (and as a greybeard). I honestly wonder if people think about such things this day and age where everything is react.

There are frameworks that navigate like this. Laravel is the first that comes to mind. I think Django and Spring do this as well.

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

#104
post #8

Earlier quoted context omitted.

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.

This is Google. Most likely they will deploy an automatic scanner bot that "supposed to" handle all the edge cases. When it don't work, you will be blamed for not writing your js in the way the bot can understand.

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

#105
post #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 inclu…

This relates to Chrome, not to search. In regard to search, they have taken a new direction that I don't think is going to change any time soon. Some time in the last 2 years, they started removing any thing that doesn't get significant natural traffic (ie: have a 30 year old user manual for something odd that people only search for once in a while? -> removed). Last few months, I noticed that they will not index anything that seems broad (ie: if similar content exists, they won't index it regardless of your page authority).

Basically, they are turning search into Tiktok. If you try to make a search, you'll notice that now they give precedence to AI overview, Youtube, News stories, Maps, Products, etc. Anything but content.

tl;dr: content is dead in Google search.

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

#106

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

It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide

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

#107
post #55

Earlier quoted context omitted.

I’d go back in a heartbeat. Making the web a software SDK was the worst thing to happen to it.

Gemini websites are pretty much the old web: https://en.wikipedia.org/wiki/Gemini_(protocol) Both in terms of comprehensiveness and in terms of functionality.

Geminispace is a very chill place. It’s definitely not a replacement for the web, but if you can handle the compromises, it feels like both the past and the future.

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

#108

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

There are valid use cases however the issue is rooted in lacking browser APIs. For instance, - if you want to do statistics tracking (how many hits your site gets and user journeys) - You have a widget/iframe system that needs to teardown when the SPA page is navigated away - etc The browser does not have a; globalThis.history.addEventListener('navigate') So you must monkey patch the history API. It's impractical fro…

Browsers now have window.navigation.addEventListener("navigate") that allows just this.

https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...

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

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

If JavaScript hadn't been a thing, Flash and JavaApplet would have been far more popular than they were and I really don't appreciate that timeline.

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

#110
post #83
post #80

This seems like a good time to advertise the post/redirect/get pattern. https://en.wikipedia.org/wiki/Post/Redirect/Get Not strictly about hijacking back navigation but it can make experience less bumpy if you've got form submissions in the middle of the path.

I'm a huge fan of this pattern (and as a greybeard). I honestly wonder if people think about such things this day and age where everything is react.

It's amazing how often highly-polished web infrastructure gets put into the trash in pursuit of narrow objectives like avoiding a full page load. Very few applications actually benefit from being a single page. You tend to lose a lot more than you gain in terms of UX.
Post reply on HN