106 comments

[ 423 ms ] story [ 1327 ms ] thread
Frustrating it took this long for something to be done about this, but glad its now got something being done.
Some Microsoft sites have been very guilty of this. They are the ones that stick in my head in recent memory.
Microsoft Learn. I first noticed this a couple years ago not long after they changed the url from docs.microsoft.com to learn.microsoft.com. Each time you went from a google search to a learn page it would load, redirect to login.microsoftonline then go back to the learn page. Hitting back in the browser took you back to login.microsoftonline which forwarded you back to the learn page. Hitting back twice in quick succession took you back to the docs page then forwarded you to login.microsoftonline. Easier to close the tab and start again. Maybe it was something to do with the changes to the site to make it more like an online college, as that portion requires signin, but I’m just after first party doco! Dunno if this still happens today but at the time I was browsing docs every other day and it was super frustrating. Note: it only did this if you were already signed in elsewhere, something triggered Microsoft sso check. Similar to if you go to portal.office.com, it is a page that requires sign in and so does the login.microsoftonline redirect to check for active tokens.
The iron law of web encrapification: every web feature will (if possible) be employed to abuse the user, usually to push advertising.
Cool, now maybe let's do something about all the shit I have to clear out out my face before I can read a simple web page. For example, on this very article I had to click "No thanks" for cookies and then "No thanks" for a survey or something. And then there was an ad at the top for some app that I also closed.

It's like walking into some room and having to swat away a bunch of cobwebs before doing whatever it is you want to do (read some text, basically).

Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?
Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.
Reddit! I'm looking at you?
But the question is: why are sites allowed to hijack the Back Button?!?
>We believe that the user experience comes first

I’ll believe that when YouTube gives me the ability to block certain channels versus “not interested” and “don’t recommend channel” buttons that do absolutely nothing close to what I want.

Or a thousand other things, but that one in particular has been top of mind recently.

Now, if they only declared scroll hijacking as spam...
> 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.

Took long enough. Maybe I missed it, but I didn’t see them say how invested they are in tackling this. Promoting a rule is one thing, but everything SEO related becomes a cat and mouse game. I don’t have high confidence that this will work.
Ironically, we have an infringing website right now on the front-page of HN (nypost).
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.

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

Phew. for a moment there i thought they would start blocking alternate uses of the back button in apps (for like when it means "go back" and when it means "close everything")

That would have severely rustled my jimmies

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.

Now if only they'd do this for Android apps that hijack the back button to pop up things, or say "are you sure you want to leave?"
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.

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.

is there a policy on "home button hijacking"?

I'm tired of apps that intercept home button to ask "are you sure?" - home button is home button, return me to the main phone screen

also, ads at the bottom of the screen, so that if you miss home button you open a website

> We believe that the user experience comes first.

If by "user" you mean advertisers, sure you do. Everyone else is an asset to extract as much value from as possible. You actively corrupt their experience.

The fact these companies control the web and its major platforms is one of the greatest tragedies of the modern era.

Now to prevent scroll bar hijacking.