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.
A new spam policy for “back button hijacking”
101–110 of 532 posts
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…
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”
#103This 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.
Re: A new spam policy for “back button hijacking”
#104Earlier 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.
Re: A new spam policy for “back button hijacking”
#105That'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…
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.
Re: A new spam policy for “back button hijacking”
#107Earlier 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.
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…
https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...
Re: A new spam policy for “back button hijacking”
#109The 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).
Re: A new spam policy for “back button hijacking”
#110This 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.