A new spam policy for “back button hijacking”

https://developers.google.com/search/blog/2026/04/back-button-hijacking

by zdw • 3 months ago

918 513 3 months ago

developers.google.com

CableNinja• 3 months ago

Frustrating it took this long for something to be done about this, but glad its now got something being done.

When a user clicks the "back" button in the browser, they have a clear expectation: they want to return to the previous page. Back button hijacking breaks this fundamental expectation.

It seems pretty stupid. Instead of expanding the SEO policy bureaucracy to address a situation where a spammer hijacks the back button, the browser should have been designed in the first place to never allow that hijacking to happen. Second best approach is modify it now. While they're at it, they should also make it impossible to hijack the mode one.... oh yes, Google itself does that.

spankalee• 3 months ago

What about all the very legitimate uses of programmatically adding history entries?

pwdisswordfishq2• 3 months ago

Especially since, who cares about traditional SEO any more?

al_borland2• 3 months ago

Some Microsoft sites have been very guilty of this. They are the ones that stick in my head in recent memory.

sixothree• 3 months ago

Epic store makes it impossible to navigate backwards from the checkout on mobile at least. Not sure if it's design or just poor design.

quantum_magpie• 3 months ago

I think most checkouts do that, to prevent duplicate payments. Dunno about epic, but I often encounter that mitigated by a dedicated ‘go back to store’ button post-checkout

542458• 3 months ago

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.

surround• 3 months ago

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.

lamasery• 3 months ago

IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.

PhageGenerator• 3 months ago

I think that is because some "pages" are really full screen modals. So the back button does take you back to the previous page, but it looks like you went back two pages (closes modal + goes back). I don't spend too much time in the Azure portal but this behavior is rampant in the Entra admin center.

boomlinde2• 3 months ago

Having used Azure I believe that this is the result of pure, distilled incompetence rather than malicious intent.

SuperNinKenDo5• 3 months ago

Happened to me yesterday through a link off here. I was already expecting it given the domain, but usually mashing back fast enough does the trick eventually. Not this time. Had to kill the tab.

Tepix• 3 months ago

In most browsers you can hold the back button for a second and it will let you skip back more than one step.

UntappedShelf21• 3 months ago

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.

musicale• 3 months ago

The iron law of web encrapification: every web feature will (if possible) be employed to abuse the user, usually to push advertising.

chongli4• 3 months ago

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

AuthAuth• 3 months ago

It wasnt "fine".

pottertheotter• 3 months ago

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.

raincole• 3 months ago

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.

miki1232114• 3 months ago

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.

endgame• 3 months ago

I cannot even reliably press [Space] any more to page down through sites that are meant to be all about content!

kiddico• 3 months ago

I've always found that behavior baffling so it's interesting to hear someone using it as intended instead of being frustrated by it.

turtleyacht• 3 months ago

One more for the spacebar to advance the page. Have never encountered a broken site (so far). Fingers crossed.

globular-toast2• 3 months ago

This is my biggest gripe with modern browsers. Stop fucking with my keyboard. I want my keyboard to control my agent, not some script. No key seems to be safe. The quick-search key (/) is often overriden by "clever" web devs, but not even in a consistent way. Ctrl-K to go to the browser search box is gone. I use emacs keybindings in text boxes, but those can be randomly overriden by scripts (e.g. Ctrl-B might by overridden to make stuff "bold" etc.).

I want to be able to say "Don't let any script have access to these keyboard keys". But apparently that can't be done even with extensions. I've strongly considered forking Firefox to do this, but I know how much effort that would be to maintain.

How hard would it be to write scripts that expose an interface that the user can bind to keys themselves, if they wish to?

xnx• 3 months ago

Those features that can't be used to show more ads will be used for fingerprinting.

zelphirkalt4• 3 months ago

I feel like we need a complete black box layer or something, where a website can send requests to the browser to do something, but never gets any kind of reply, as to whether anything actually happened. But that would limit usefulness of it quickly, I guess.

miki1232114• 3 months ago

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.

phoronixrly• 3 months ago

This is the price we pay for bloat...

pwdisswordfishq2• 3 months ago

This is the price we pay for stuffing browsers with tons of imperative APIs that the browser has no choice but to implement to the letter, since analysing how they are actually used runs afoul of Rice's theorem.

bschwindHN• 3 months ago

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

internet101010• 3 months ago

Don't forget the useless "Got it!" popups, especially when the site blurs the screen to guide you to it.

pwg• 3 months ago

With uBlockOrigin set to default deny all the javascript on the page there are:

zero cookie banners

zero surveys popping up

zero ads to be closed

Just the text of the page with no other distractions in the way.

not_your_vase• 3 months ago

Haha, we had a solution for that, called pop-up blockers. Then when they became very usable, everyone switched to overlays injected with javascript, so they became unblockable.

But thinking of this at this moment, this could be a good use for a locally ran LLM, to get rid of all this crap dynamically. I wonder why Firefox didn't use this as a usecase when they bolted AI on top of Firefox. Maybe it is time for me to check what api FF has for this

Terr_• 3 months ago

I'm waiting for someone to develop an augmented-reality system that detects branded ads or products, compares them against a corporate-ownership database, applies policies chosen by the user, and then adds warning-stripes or censor-bars over things the user has selected against.

It would finally put some teeth behind the myth of the informed consumer, and there would be gloriously absurd court-battles from corporations. ("This is our freedom of speech and commerce, it's essential, if people don't like what we're doing they can vote with their wallets... NOT LIKE THAT STOP USING SPEECH AND COMMERCE!")

93po• 3 months ago

ublock origin with annoyance filters on solves 95% of this

carlosjobim• 3 months ago

Your problems have been solved for more than a decade. Set your browser to open pages in reader view by default and you don't have these issues.

synack• 3 months ago

Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?

omcnoe• 3 months ago

No, only if your website abuses window.history.pushState to redirect the user to spam/ad content is it considered abuse.

tgsovlerkhgsel5• 3 months ago

Because clicking on a navigation button in a web app is a good reason to window.history.pushState a state that will return the user to the place where they were when they clicked the button.

Clicking the dismiss button on the cookie banner is not a reason to push a state that will show the user a screen full of ads when they try to leave. (Mentioning the cookie banner because AFAIK Chrome requires a "user gesture" before pushState works normally, https://groups.google.com/a/chromium.org/g/blink-dev/c/T8d4_...)

kro2• 3 months ago

It's a valid question how they detect it. As there are valid usages, just checking for the existence of the function call would not be correct.

These sites likely pushState on consent actions so it appears like any user interaction.

tgsovlerkhgsel5• 3 months ago

No idea how they actually do it, but I wouldn't be surprised if manual reports and actions play a big role. The policy doesn't need to be enforced reliably as long as it is plausible for reasonably big actors to get caught sooner or later and the consequences of getting caught are business-ruining.

But detecting it on a technical level shouldn't be hard either. Visit the page, take a screenshot, have an AI identify the dismiss button on the cookie/newsletter popups, scroll a bit, click something that looks inactive, check if the URL changes, trigger the back action. Once a suspicious site is identified, put it in the queue for manual review.

tgsovlerkhgsel5• 3 months ago

Now do paywalls next.

ladberg• 3 months ago

How would you recommend that creators of valuable content get paid?

renewiltord• 3 months ago

Ideally, when I create valuable content I am paid and when I consume valuable content I don't pay. Advertising does this but I hate it so I don't want that. So ideally, there is no way to extract value from me but I am able to extract value from others. I think I would support someone who finds a way to enforce this.

But I am also willing to pay for valuable content an exorbitant amount if it is valuable enough. For instance, for absolutely critical information I might pay 0.79€ a month.

tgsovlerkhgsel5• 3 months ago

Paywalls are, of course, the author's choice.

But a paywall is a rather useless page, so it shouldn't be shown in search results. Normally, serving Google one page (e.g. a full article) and showing users something else (e.g. a paywall) would be grounds to ban that site forever, but Google built a special exemption for paywalls.

Showing search results that the user can't actually use is user hostile. It's essentially an ad disguised as a search result, with the problem that those ads displace other results that I might actually be able to read.

Of course, if the policy was to not index paywalled content, we might have avoided the paywallization of the Internet. Somehow, decades ago, when the Internet was smaller and there were fewer eyeballs, high quality content could successfully get monetized with non-tracking ads.

Now we have invasive ads that try to profile you, ads that are full of scams because quality control has gone out the window, and yet, somehow, everything needs to be behind a paywall...

charcircuit3• 3 months ago

Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.

SuperNinKenDo5• 3 months ago

Honestly if your site is buggy in a way that effectively breaks the browser, maybe you should be punished.

bot4032• 3 months ago

I recommend 14 days in jail for the site owner, and, if egregarious, the engineer as well.

Not life ruining but just enough to be annoying. Just like their website.

josephcsible2• 3 months ago

What does this have to do with sites being buggy? This change is about obvious intentional abuse.

charcircuit3• 3 months ago

SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.

If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.

domenicd• 3 months ago

We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.

We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.

This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.

But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.

So, policy-based solutions make sense to me here.

[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...

[2] https://developer.chrome.com/docs/web-platform/soft-navigati...

themafia2• 3 months ago

The back button itself feels overloaded. There's "go to previous state" and then there's "go to previous origin." In an ideal world when I doubleclick on the back button what I mean is: "get me off of this site, now."

magicalhippo• 3 months ago

We tried a few times

Classify history API, canvas etc etc as "webapp" APIs, and have them show a similar dialog to the webcam dialog.

Then I can just click no, and the scripts on the page can't mess around.

Yes Google Maps is great. No, my favorite news site doesn't need that level of access to my browser or machine, it just needs to show some images and text.

twism• 3 months ago

Reddit! I'm looking at you?

itopaloglu83• 3 months ago

Scroll on Reddit on mobile and click on a link. The comments open in a new tab. Close the tab and the previous tab is also at the link you’ve just closed.

Makes it impossible to browse around and long click to open on a new tab doesn’t solve the issue either.

kaelwd2• 3 months ago

And if the tab was unloaded then you press back it changes the URL but not the actual contents of the page.

rc_kas• 3 months ago

I feel like facebook is the worst culprit with this

concinds2• 3 months ago

Those are all weird WebKit issues, and reddit not testing MobileSafari.

It works perfectly on Chrome, if it was intentional they would have broken it on Chrome too.

As always you can count on Apple/Safari team to not give a shit, not try to fix it, not reach out to reddit to ask them to fix it, etc.

snowwrestler3• 3 months ago

You think Reddit does not test in their #1 browser?

mlmonkey• 3 months ago

But the question is: why are sites allowed to hijack the Back Button?!?

filcuk• 3 months ago

Because it has a legitimate use. As anything, the tools will be abused by malicious actors

josephcsible2• 3 months ago

So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

not2b• 3 months ago

If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.

phkahler5• 3 months ago

> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.

transcriptase• 3 months ago

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.

bot4032• 3 months ago

Or if they ever bring back the "ignore this domain" feature so we can ignore ai slop and copycat sites.

It's why I went to Kagi.

PeterStuer• 3 months ago

Let me permanently hide "shorts".

VileSquirrel• 3 months ago

You can mostly do it with ublock origin filters. Here are mine, though they do more.

www.youtube.com###contents-container > .ytd-rich-shelf-renderer.style-scope

www.youtube.com###rich-shelf-header

www.youtube.com###content > .ytd-rich-section-renderer.style-scope

||www.youtube.com/shorts/$document

Alternatively on firefox you can use either the "unhook" extension (https://addons.mozilla.org/en-US/firefox/addon/youtube-recom...) or "enhancer for youtube" (https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-...) extension (which has an option for this).

incognito124• 3 months ago

Now, if they only declared scroll hijacking as spam...

andreareina• 3 months ago

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.

kvdveer• 3 months ago

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.

lmm• 3 months ago

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.

Ma8ee• 3 months ago

The advantage would be that I know beforehand, and have the opportunity to test and, possibly, reject, what the advertiser want me to send to someone’s browser.

apatheticonion2• 3 months ago

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 from a distribution standpoint to embed this code in the page bundle as it's often managed externally and has its own release schedule.

friendzis4• 3 months ago

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

jampekka• 3 months ago

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

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

friendzis4• 3 months ago

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

optionalsquid2• 3 months ago

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

least4• 3 months ago

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.

This feels like a reasonable counter-measure.

RobotToaster• 3 months ago

anything loaded from a third party domain shouldn't be allowed to run scripts.

pas• 3 months ago

facebook.com does this as a first party site, shit sites trying to squeeze eyeball time from visitors should be put on Google's malware sites list, but apparently those are the best sites nowadays... :/

bell-cot• 3 months ago

Maybe it's not quite your meaning - but there are browser plugins which allow per-domain blocking of js. I use one, with the default set to deny js.

lxgr10• 3 months ago

That restriction would both be trivial to circumvent by malicious advertisers and annoying for many legitimate web concepts.

zelphirkalt4• 3 months ago

If it happened browsers started to warn their users about third party JS doing back button history stuff, I have a hunch, that many frontendies would just shrug and tell their visitors: "Oh but for our site it is OK! Just make an exception when your browser asks!" just like we get all kinds of other web BS shoved down our throats. And when the next hyped frontend framework does such some third party integration for "better history functionality" it will become common, leading to skeptics being ridiculed for not trusting sites to handle history.

latexr• 3 months ago

Your parent commenter didn’t suggest asking for permission, they suggested not allowing it, period.

dspillett6• 3 months ago

I feel like anything loaded from a third party domain

Unfortunately this would break some libraries for SPA management that people sometimes load from CDNs (external, or under their control but not obviously & unambiguously 1st-party by hostname) instead of the main app/page location. You could argue that this is bad design IMO, and I'd agree, but it is common design so enforcing such a limit will cause enough uproar to not be worth any browser's hassle.

I do like that they follow up this warning with “We encourage site owners to thoroughly review …” - too many site/app owners moan that they don't have control over what their dependencies do as if loading someone else's code absolves them from responsibility for what it does. Making it clear from the outset that this is the site's problem, not the user's, or something that the UA is doing wrong, or the indexer is judging unfairly, is worth the extra wordage.

ekjhgkejhgk• 3 months ago

GOOGLE is an advertising platform.

ori_b• 3 months ago

The history stack shouldn't be controlled by any loaded sites. The browser needs to treat websites as hostile.

hysan• 3 months ago

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.

onli• 3 months ago

Seems invested enough to me. Adding this to the anti spam policy means they will list sites using this lower or not at all, when detected. And they use automated and manual detection for such things. Not much more they can do? And should be effective, who employs scam tactics like this is also interested in having visitors.

psidium• 3 months ago

Ironically, we have an infringing website right now on the front-page of HN (nypost).

dnnddidiej3• 3 months ago

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.

Hamuko• 3 months ago

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

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

dnnddidiej3• 3 months ago

I agree. Because most SPAs don't need a back button. VS Code doesn't have one (undo is not back). Thunderbird doesn't. My MP3 player doesn't.

kaelwd2• 3 months ago

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

sublinear2• 3 months ago

Why not just put up a fake captcha page? When the user clicks the link to continue, the back button is now hijacked.

layer82• 3 months ago

Yeah, no thanks. I want to use my browser’s standard keyboard shortcut to navigate back. And also forward again. And I want to be able to inspect the history listing before I go back or forward.

Let the browser do the browsery things. Don’t make SPAs suck even more than they already do.

dnnddidiej3• 3 months ago

So when you use a desktop app there is no back button but there is a switch to another app shortcut. Same idea.

sublinear2• 3 months ago

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

monegator• 3 months ago

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

p4bl0• 3 months ago

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.

csomar3• 3 months ago

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.

rbits2• 3 months ago

This relates to Chrome, not to search.

To me, it appears to relate to search

Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results.

direwolf203• 3 months ago

Try Marginalia Search but be warned it doesn't index the entire web

mx7zysuj4xew2• 3 months ago

What aggravates me is that somewhere at Google headquarters some asshole thinks he's a fucking genius for turning the web into nerfed walled garden

gunapologist99• 3 months ago

I'm actually surprised when I hear someone technical say they still use Google Search (the search product specifically - they still reign supreme with Maps, etc). I used to love it, but that was quite a long time ago.

I personally use Brave Search and perplexity for those very rare instances when brave search doesn't instantly find what I am looking for. Literally the only thing I (rarely) miss from google is super-deep support for boolean search operators, but then I just tag a !g (exactly like DDG's brilliant bangs) on the end and that works. (I also tried Kagi and did like it, but didn't find compelling differences over Brave Search, especially compared to brave search's excellent and free AI.)

SoftTalker2• 3 months ago

no ads

There's yer problem....

Google isn't interested in helping people find pages with no ads.

kstenerud• 3 months ago

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?"

oliwarner• 3 months ago

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.

bob10292• 3 months ago

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.

karim79• 3 months ago

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.

koen_hendriks• 3 months ago

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

bob10292• 3 months ago

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.

lxgr10• 3 months ago

TIL that this (or rather, the lack of this) is why some pages show that annoying "do you want to resubmit your post" notification, but not others, and the name for it. Thank you!

NooneAtAll3• 3 months ago

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

imiric• 3 months ago

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.

Animats• 3 months ago

Now to prevent scroll bar hijacking.

slurpyb• 3 months ago

Porno sites do this thing where every click is a new tab and when you refocus the previous tab, it reloads to an ad.

Or so I have been told.

ffsm82• 3 months ago

I would like to mention that Google own SPA framework, angular, has redirect routes which effectively do back button hijacking if used, because they add the url you're redirecting from to the history.

https://angular.dev/guide/routing/redirecting-routes

sam1r2• 3 months ago

That's only because SPAs routing maybe internal for that particular app. In that case, the UI/UX to end user is *only* possible and smooth when they hijack the back button as such.

bryanhogan• 3 months ago

Yeah, I think people are forgetting that if we want PWAs to behave and function like "native apps" that this functionality is needed.

I revently built an app with SvelteKit + Capacitor and had to implement the stack-based navigation one expects from a phone app myself.

nailer2• 3 months ago

getAngular was an online JSON storage service. The guys reused their code when they went to work in DoubleClick at Google. Not made by Google not Google’s framework and plenty of Google people think it’s rubbish.

ffsm82• 3 months ago

While that's an interesting history tidbit, angular 2 was remade entirely under Google's leadership - the previous AngularJS framework was not reused to my knowledge - so I'd strongly push back on your statement it not being made by Google

G_o_D• 3 months ago

Instagram comments page requires 2 quick back press or else it won't take to previous page

kristopolous• 3 months ago

Almost 30 years ago I wrote an article advocating for domain level back button with a quasi mode like ctrl to traverse domains.

Would have fixed this. Too late now

_ink_• 3 months ago

A browser feature I wasn't aware of for too long: long press the back button, to get a list of recent URLs, allowing you to skip anything trying to hijack the back button.

Asmod4n• 3 months ago

That’s surely bounded now much it can show, so an attacker can just fill it up till the api throws an error

asqueella• 3 months ago

Surely the browser could enforce a limit on a domain, and make sure that the real page you came from (typically the search engine) is prominently displayed.

voidUpdate• 3 months ago

Or right click

totalwebtool• 3 months ago

The most egregious cases of back button hijacking will leave you with a very long list of entries, which is why it's good to see Google taking this seriously. It's annoying and can be outright malicious in many cases on the part of the offending website.

vsgherzi• 3 months ago

Amazing change, fighting with the back button is my least favorite part of the ad web and a blindspot for ublock. I wonder how Google is going to track this and if SPA style react router sites would be downranked because of the custom back button behavior. I doubt it due to their popularity but I'm curious how they're going to determine what qualifies as spam

firefoxd• 3 months ago

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 homepage first (location.replace(...) doesn't change the browser history). Then the browser history state is pushed to the original link. So it seems like you landed on the home page first then you clicked on a link. When you click the back button, you are taken back to the homepage where your feed entices you to stay longer on LinkedIn.

giorgioz• 3 months ago

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.

cli• 3 months ago

I do not see this behaviour on the latest version of Firefox. I do use old.reddit, however.

DaiPlusPlus• 3 months ago

I'm pretty sure what you're describing is this long-standing bug[1] I've experienced only when using Mobile Safari on Reddit - affecting both old.reddit.com and the (horrible) modern Reddit. It just doesn't happen in other browsers/engines except on iOS. It's especially annoying on an iPad when I tend to use back/forward instead of open-in-new-tab-then-close on iPhone.

[1] At least, I hope it's a bug.

Bombthecat• 3 months ago

News sites are doing it too. Displaying a full display ad when you try to leave

ChocolateGod• 3 months ago

I usually find the back button just doesn't work on new Reddit at all.

hobofan• 3 months ago

IIRC Reddit is also doing the same thing on their mobile (Android) app.

SilasX• 3 months ago

Even on old.reddit, it breaks the back button. When you navigate back, it usually reloads the entire page you were on and ignores all your collapse actions on conversations.

zozbot2346• 3 months ago

The fix is to hold down the back button so the local history shows up, and pick the right page to go back to. Unfortunately, some versions of Chrome and/or Android seem to break this but that's a completely self-inflicted problem.

Rygian• 3 months ago

That's not a fix. It's a workaround.

neya2• 3 months ago

The fix is to not to implement anti-user patterns. What you're describing is a loophole around it.

miki1232114• 3 months ago

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.

Arainach2• 3 months ago

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.

TeMPOraL8• 3 months ago

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.

thn-gap• 3 months ago

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.

neya2• 3 months ago

If you reached point B from point A - and you tell someone "I would like to go back", then you are expecting to go back to A. Not some intermediate, arbitrarily chosen point C.

eviks2• 3 months ago

You're describing 2 different concepts, back and up, not 2 backs

dspillett6• 3 months ago

You get a link from LinkedIn [or such]. 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, […]

I've taken to opening anything in a new tab. Closing the tab is my new back button. In an idea world I shouldn't have to, of course, but we live in a world full of disks implementing dark patterns so not an ideal one. Opening in a new tab also helps me apply a “do I really care enough to give this reading time?” filter as my browsers are set to not give new tabs focus - if I've not actually looked at that tab after a little time it gets closed without me giving it any attention at all.

Specifically regarding LinkedIn and their family of dark patterns, I possibly should log in and update my status after the recent buy-out. I've not been there since updating my profile after the last change of corporate overlords ~9 years ago. Or I might just log in and close my profile entirely…

bertil• 3 months ago

I do that everywhere, but it seems to fail for LinkedIn: they don’t redirect the link if it’s not in the same tab.

troupo• 3 months ago

Closing the tab is my new back button.

In Safari if you open a new tab, don't navigate anywhere, and click back, the tab closes and takes you back to the originating page. I've gottent so used to it, I now miss it in any other browser

znort_• 3 months ago

I've taken to opening anything in a new tab.

this is the way.

sidewndr462• 3 months ago

given the level of hostility most businesses have towards their customers, we should probably be opening links in disposable virtual machines

bluGill• 3 months ago

When I intentionally want to read something that is what I do. However once in a while I'm scrolling, selecting a window, or some other activity; and I happen to click on a link: instead of whatever action I intended I end up on a new page I didn't want to read (maybe I will want to read it, but I haven't go far enough cognitively to realize that). That is when I want my back button to work - a get out of here back to where I was.

RajT88• 3 months ago

This is the way. People think I am eccentric for the number of tabs I keep open.

cortesoft• 3 months ago

I have always done this, although mostly so I don’t have to reload the page I am coming from when I hit the back button.

globular-toast2• 3 months ago

LinkedIn is malware and it's frankly embarrassing that we seem to be stuck with it. It's like a mechanic being stuck with a wrench that doesn't just punch you in the face while using it, it opens your toolbox just to come out and punch you randomly.

integralid• 3 months ago

What do you mean "stuck with it"? I just don't use LinkedIn. Do you need it for job hunting for example?

SunshineTheCat• 3 months ago

You know what's funny, just the other day I tried to do an "export" of my data from my account.

The option I chose was "profile data" because I wanted to get my whole work history/projects/etc. for a new resume.

The export took several hours.

When I finally downloaded it, it included my name, Email, short description, and my Email address...

jarek83• 3 months ago

LinkedIn won't bother - they don't rely on SEO

Simulacra• 3 months ago

and then if you click the back button again it just reloads the page, trapped in a vicious loop!

ChrisMarshallNY3• 3 months ago

Would this actually fall afoul of their new policy, though?

Assume the way that universal links work, is that the site main page is loaded, and some hash is supplied, indicating the page to navigate to from there. That's annoying, but perfectly valid, and may be necessary for sites that establish some kind of context baseline from their landing page.

bastawhiz2• 3 months ago

It's not valid. You went to a page. They said "no, you're actually on the feed," and then immediately navigate you to the page you'd actually intended to visit. This is that they're doing today, and it's terrible. If I go to a URL, I'm NOT going to your homepage feed. I never wanted to go there.

abustamam• 3 months ago

Facebook does this as well.

Thanks for explaining how they do it BTW! I didn't really think about it. I just knew it was shitty.

01284a7e• 3 months ago

Can we reach out directly to Reid Hoffman? Or is he too wrapped up doing damage control from being all over the Epstein Files?

venusenvy473• 3 months ago

Regarding Google and LinkedIn, I keep complaining to them about a stupid feature of Gmail. If I get an invitation from someone, Gmail puts "accept" as a button in the subject of the email - so if you aren't careful you can accept while you are scrolling through the subject lines. That is just the worst feature to put in their subject line.

Barbing4• 3 months ago

Does "accept" support "undo send"?

Barbing4• 3 months ago

I like Gmail asking me for no reason to stay on the page when I try to leave.

New spam policy for navigate-away blocking, hope that's Google's next article.

cik• 3 months ago

Great. Now do Android phones...

parasti• 3 months ago

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.

sheept• 3 months ago

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

rbits2• 3 months ago

If it automatically adds something to the history when you visit the page, then yes. If it only adds to the history when the user clicks something, then I would assume it would be fine. Hopefully.

lxgr10• 3 months ago

Isn't this a heuristic implemented by browsers already these days?

the_gipsy• 3 months ago

We believe that the user experience comes first.

Excuse me??

globalnode• 3 months ago

will google really punish sites for doing this? and if so how do i report a site? i guess i could email the site with the google link and suggest they fix it first

mikkom• 3 months ago

Maybe we can get facebook finally drop this dark pattern

nottorp3• 3 months ago

So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?

dominicrose• 3 months ago

It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.

nottorp3• 3 months ago

In a single-page application it may not trigger a navigation event.

So isn't that also back hijacking?

worksonmine• 3 months ago

This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.

red_admiral• 3 months ago

In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.

nottorp3• 3 months ago

This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.

For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.

alpaca128• 3 months ago

Great! So they'll fix the back button bugs on YouTube, and return me to the previous set of video recommendations when I use it on the homepage, right? Right? And let me return to the actual site when it detects that I lost the web connection for 0.01 seconds and hides all the content, and I then press the back button?

Aardwolf• 3 months ago

Why not fix this at the browser level? E.g. long or double click on back button = go to previous non-javascript-affected page (I mean by that: last page navigated to in the classical sense, ignoring dynamic histories altered by js and dynamic content)

chakintosh2• 3 months ago

That wouldn't work because this technique messes with your history. Long press on the button will just show you a list of the previous pages you visited, and all of them will have the same link to the one you're in, with just one at the bottom of the actual URL you came from. But that's so much friction UX-wise.

mrob2• 3 months ago

Double clicking is not a fix because it doubles latency, and more than doubles latency if you don't want to issue page loads that are immediately aborted. Long clicking is such a bizarre anti-feature that I never considered it might exist until I read about it in this HN discussion. Putting touchscreen-specific workarounds for lack of mouse buttons and modifier keys in a traditional GUI app is insanity.

chakintosh2• 3 months ago

Google should probably talk to Microsoft about this because for me they are the biggest offenders with this back button hijacking in their support forums.

LLLDP• 3 months ago

So someone developed a malicious plugin to achieve this? Otherwise, I can't imagine how they could bypass the browser to do this.

vladde• 3 months ago

i wonder if this includes sites that do auto-redirect: A -> B (auto-redirect) -> C

if i'm on page C and go back, page B will take me to page C again. i think this is more about techincal incompetence rather than malicious intent, but still annoying.

kartik_malik• 3 months ago

that's crazy things goin on

eviks2• 3 months ago

Why are we taking action? We believe that the user experience comes first.

What's the real reason?

nubinetwork• 3 months ago

It broke Gemini and of course we can't have that...

Havoc2• 3 months ago

Great. Can we do ctrl-f search hijacking next.

So jarring when websites replace core functionality with their own broken crap because they think they’re special.

Some also seem to hijack right click menu now

Mate4• 3 months ago

Firefox allows you to bypass right click hijacking by holding shift before pressing right click.

gonzalohm• 3 months ago

There is also an option in about:config: "dom.event.contextmenu.enabled" set it to false

arielcostas• 3 months ago

Some also hijack the shortcuts to open devtools (like F12), so you have to find the option in the browser menu itself

lebuin• 3 months ago

You can also click the address bar and then press you shortcut. Should be faster and works for all shortcuts AFAIK.

ivanjermakov• 3 months ago

Don't get me started on scroll hijacking.

amadeuspagel• 3 months ago

This misses the point. Websites are allowed to replace default keyboard shortcuts for a reason. There are only a few exceptions to this, like Ctrl+W. In other words, you can design your website however you want, except to make it more difficult to leave. This is an implementation of the same philosophy.

Havoc2• 3 months ago

you can design your website however you want, except to make it more difficult to leave.

Who decreed that page navigation is in scope and search navigation is outside?

taco_emoji2• 3 months ago

CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.

pornel• 3 months ago

Browsers can deal with very long documents. Ctrl+F works like a breeze on HTML that's 100K lines long.

Browsers only struggle to run heavy JS frameworks that wrap every line in a dozens of spans with dozens of handlers and mutate it all on every line scrolled.

rat_on_the_run2• 3 months ago

They can have a search button for that, not hijacking default browser functions. Often I want both kinds of search.

MrMember• 3 months ago

Github hijacks '/' and it's really annoying, it gets me all the time.

Yizahi• 3 months ago

I'm at a stage when I click back button extremely rarely and is amazed when it works as I expected.

seanalltogether• 3 months ago

Does this also apply to sites like instagram that simply erase your entire back button history if you visit the site.

shevy-java• 3 months ago

I don't trust Google.

We need to go back to an independent and competent research group designing standards. Right now Google pwns and controls the whole stack (well, not really ALL of it 1:1, but it has a huge influence on everything via the de-facto chrome monopoly).

Remember how Google took out ublock origin. They also lied about this aka "not safe standards" - in reality they don't WANT people to block ads.

edg5000• 3 months ago

Power is taken but also given. It's a dynamic and I agree it's gotten way, way out of hand. It may eventually supress progress and become a real parasitic presence, but we've not reached that point yet (in net terms). Google has been relatively responsible with the power, but cracks have been starting to show. It will get a whole lot worse before it gets better. That is why I embrace vertical integration despite the tremendous cost. Call it the cockroach approach; it allows being partially decoupled from outside fluctuations.

Addition: People underestimate Google's influence. It's easy to forget they de-facto control Firefox, leaving only Apple and Google in control of the Web. Scary, but looking away won't help either. The Americans have been consistently competent with technology since the advent of the transistor right after WW2. They're reaping the benefits of that still to this day. I say that as a European.

SCdF• 3 months ago

Ironically the only place I encounter this is using google news, where news sites seem to detect you're in google news (I don't think these same sites do it when I'm just browing normally?), and try to upsell you their other stories before you go back to the main page.

felixding• 3 months ago

This is great. Can Google also stop scroll hijacking?

a13o• 3 months ago

This would have been great back when I used a search engine to visit web pages.

gadders• 3 months ago

I hope this applies to Android as well. Reddit is a particularly egregious offender.

skrebbel• 3 months ago

How does this work? How can a site inject a totally different site into the history? I thought eg the History API only lets you add to the stack and pop, not modify history?

lxgr10• 3 months ago

There's also a replace() method, and trying to limit that to only same origin or already visited URLs seems futile, as the pages hosted there can themselves detect that the user is navigating back and can just forward you in a number of ways.

neeeeeeal• 3 months ago

Is there not a plugin that helps to fix this?

XCSme• 3 months ago

Thank you!

One of the worst is TikTok, even as a developer, when someone sends me a TikTok link and I have to visit it, I get stuck in the browser (same with the app but I uninstalled it), and it feels almost device-breaking the way they trap you in.

saagarjha• 3 months ago

TikTok is actually very adamant to boot me out of the browser

bityard• 3 months ago

As usual, it's a good first step but doesn't go far enough. I don't want my back-button hijacked by _anything_.

My issue with back-button hijacking isn't even spam/ads (I use an ad-blocker so I don't see those), but sites that do a "are you sure you want to leave? You haven't even subscribed to our newsletter yet?!"

Sayrus2• 3 months ago

On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.

wat100003• 3 months ago

Better yet, just save. Storage is cheap and fast these days. The “do you want to save?” idiom is a leftover from the days when a moderately sized document would take a noticeable amount of time to save and eat up a decent chunk of your floppy disk.

gwbas1c2• 3 months ago

That API has quite a few heuristics that protect the user:

(At least on the Chromium browsers that I've tested it with)

1: It fails silently if the user hasn't interacted with the page. (IE, the user needs to "do something" other than scroll, like click or type.) This generally stops most SPAM.

2: The browser detects loops / repeated prompting and has a checkbox to get out of the loop.

---

It was a little jarring the first time I used that API and tested my code with it; but I appreciate the protections. I've come across far too many "salesman putting their foot in the door" usage of it.

NoGravitas• 3 months ago

There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page. The same would be true for multi-page apps using HTMX or Turbo or something - if you change pages without doing a full page load, you need to push your new URL. The guiding principle is that the browser back button should work as the user expects - you should only mess with the browser history stack to fix any nonsense you did to it in the first place.

phkahler5• 3 months ago

> There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page.

No, You SPA should have it's own back button within the app. My browser back button should get me out of there no matter what.

_fat_santa• 3 months ago

are you sure you want to leave

I would argue there is a place for this in web-apps. For example I have a SaaS app and I employ this on any form pages where the user has already started to enter information in.

I have considered form persistence so in the event a user goes back to a previous page, realizes it's a mistake and goes forward again, their form state from the previous state is persisted.

But I would like to ask, what would users prefer the behavior be on a form page like this?

lexicality• 3 months ago

That's fine, there's already an API for this: https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...

That's very different to sites like tomshardware that pops up a "hey why don't you check out this extra slop you didn't ask for" when you try to navigate away

encom2• 3 months ago

Spawning a new tab is also hijacking the back-button, and should be disallowed completely. No exceptions. Opening a new tab, or god forbid a window, is messing with client software. Violations should carry a minimum 6 month jail sentence.

Pre-empting the web-mail comment: I know. I don't care.

jbonatakis• 3 months ago

We believe that the user experience comes first

Bold coming from the company who gives me the most confusing “Open in app” prompts that are designed to confuse you and get you to use their app rather than the web

https://mjtsai.com/blog/2024/03/29/those-obnoxious-sign-in-w...

cientifico• 3 months ago

Click on any Youtube video from any web in android. If you press anything that is not the back button immediately, you will loose the option to go back.

So this coming from google... it's funny. Welcome, but funny.

blacksoil• 3 months ago

Yes please! It's very annoying how clicking an FB or Insta result from a Google search result would disallow going back to the search result!

sidewndr462• 3 months ago

too little, too late. The API for interacting with the back button in Javascript should never have existed in any capacity.

snowwrestler3• 3 months ago

Wait, how does one website (google.com) know what happens inside my browsing session on another website (bad-blog.com) after I click over? Hmmmmm

This sort of announcement just emphasizes the extent to which Google observes ALL your web browsing behavior, thanks primarily to their eyes inside Chrome browser.

You know those warnings when you install a browser extension, about all the things that extension will be able to see and do? Well so can Chrome itself…

beastman82• 3 months ago

They've been crawling the web since inception

snowwrestler3• 3 months ago

A web crawler reads page content, extracts content and URLs, places them into an index, and then follows links in that index to further build the index and content corpus. Google and others have special crawlers that execute JavaScript to crawl content delivered dynamically.

Crawlers do not use the browser back button or browser history. So the only way Google could observe such problems is by observing live human browsing behavior.

Also, we know from exhibits in the U.S. DOJ trial that Google does use Chrome browsing behavior as a signal in search ranking. It’s not a hypothetical.

ImPostingOnHN2• 3 months ago

They likely scan the web pages themselves, but you shouldn't be using Chrome anyways, if you care about privacy from Google.

mixedbit• 3 months ago

An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.

cachvico• 3 months ago

I use Chrome on my Android and Mac. For a while I've appreciated the seemingly built-in anti-hijacking measure that always does what I expect on the second Back press. (The first Back may pop up a subscription box for example, but the second will always return me to where I came from).

I actually felt that this was a solved problem, so I'm surprised to see so many people still suffer getting stuck in redirect loops.

cnees• 3 months ago

It's about time. Google is doing so much to keep the web usable. They're the only ones with the teeth to back up standards for mobile web load time, max sender spam rates, leaving browser history alone, etc.

righthand• 3 months ago

They’re also the ones frequently making it worse with their monopoly.

phkahler5• 3 months ago

I never understood why browsers ever allowed this in the first place. It's obviously bad. Yeah, yeah there are "reasons" but it's still obviously a bad solution to whatever "problem" they were trying to solve.

jonahs197• 3 months ago

Microsoft joke support forum stil does this?

gwbas1c2• 3 months ago

It seems like a lot of the APIs that make a website act like an application need to be disabled by default; and some kind of friction needs to exist to enable them.

Edit: I'm not sure what kind of friction is needed, either an expensive review process (that most application developers would complain about but everyone else would roll their eyes) or a reputation system. Maybe someone else can think of a better approach than me?

wbshaw• 3 months ago

Is there any click-bait news site that DOESN'T do this? You hit back and land on a list of their click-bait articles and add links instead of the page you expect.

halfmatthalfcat• 3 months ago

I remember when I worked at HuffPo and they started doing this. I called out the org and they all just shrugged.

htk• 3 months ago

Popups were dealt in a way that could be useful here, they're only permitted when the user directly generates the interaction that creates the popup (not scripted). The back button could use the same algorithm back in history, only go back to screens that the user directly navigated.

radium3d• 3 months ago

What about map applications which manipulate the history to store the position of the map as users drag and release to make back and forward work to the users expectation in a single page app? It’s not malicious, but will Google flag it?

taco_emoji2• 3 months ago

Really wish this was applied to phone apps. In Android at least, app A linking to app B will FREQUENTLY break the "back" functionality, allowing app B to handle the "back" action instead of doing what every user would expect 100% of the time, which is to go back to app A.

celdon25• 3 months ago

Since this is Google we’re talking about, I’m fully expecting them to penalize benign uses of the back button override.

davidczech• 3 months ago

There should be some browser-level enforcement of this. For example, it would seem possible to detect a user frustratingly mashing the back button, and offer a remediation dialog to disable any hackery that's hijacking the back buttons.

TehCorwiz• 3 months ago

I want my browser history to be immutable and operate like a tree and not like a stack.

ux266478• 3 months ago

I've been kicking around an idea in my head of a modern browser implementing some kind of "hardening" against anti-features. Deviating from the standard, implementing certain architectural features like this WORM history graph, etc. I don't want to ditch javascript entirely as I don't think it's particularly unreasonable as a feature. That being said, I don't want my extensions to be available via a URL query (even if obfuscated like what Firefox does.) I have yet to find a single webpage utilizing scrolljacking where I would care if it was broken and completely unnavigable. I can count on one hand webpages where I felt like input reading was justified, and even then I wouldn't miss them if the facilities which enable input reading were just made completely undefined.

There certainly is a satisfaction that would come from a shit site like linkedin or youtube being reduced to a gibbering mess of exceptions. Scripting is a privilege, and it's a nice one, but abuse of it shouldn't be tolerated. I really don't see a usecase for boiling it down to a binary of allowing the whole gamut of complex programmability web browsers expose, or allowing none of it. I'd rather just draw a line and say "programs that use these features are acceptable, programs that use these ones aren't".

mrheosuper• 3 months ago

Nice. This has been existed for too long.

hmokiguess• 3 months ago

It's getting very tiring seeing things that could be first-class user defined controls baked in the browser so that you have true agency over the behaviour being done like this

It's like the other thread from before where LinkedIn scans for your extensions, the fact they can do that without prompting for permission from the user is baffling

TexanFeller• 3 months ago

When I first heard of the APIs that allowed websites to modify browser history it sounded like a huge mistake. I still feel that way to this day.

dylan6043• 3 months ago

It only made sense in the SPA way of working. Allowing the history to be updated would allow the browser's default navigation to work. Outside of SPA type of sites, it was only ever going to be abused.

rat_on_the_run2• 3 months ago

I wish the browsers had a function of disabling all keyboard shortcuts of a website. I binded Ctrl+E to opening a new tab just beside the current tab (built-in hotkey in Brave). It's frustrating to see it changed to something like opening the emoji menu on Discord.

blfr• 3 months ago

Another one is hijcking ctrl+click (open in the new tab) into mere click (open here). I am shocked how many ecommerce sites do this.

myself2482• 3 months ago

And many of them don't even have a real click action, that I can find. I can't even right-click and manually pick "open in new tab", because the browser doesn't recognize what I'm clicking on as a link.

I agree, ecommerce sites are the place that I most often want to open several items in tabs and decide between them, and the place this function is most often blocked! I wish I could scream at the jerk who implemented this, but that jerk is not among the options of screamable people.

eastbound• 3 months ago

That’s because of React. The React Router is bad and people don’t spend extra time configuring it against its own bugs.

lemoncucumber• 3 months ago

This one drives me nuts. I get it if it’s a single page app, but in many cases right-clicking the same link and choosing “open in new tab” works fine so that’s not the issue.

matusfaro• 3 months ago

This usually happens in single page apps (SPA):

The proper way is to have an actual link but to override the behavior to navigate within the SPA. So if you click it, the navigation will be within the SPA but if you ctrl+click it, the browser takes over and opens the underlying link in a new page.

Typical issue is when a developer forgets to make it an actual link, but only inclides the SPA navigation.

declan_roberts• 3 months ago

Ctrl+f is a bad offender. No I don't want to use your contextual search. I want to search for this word on this page!

kube-system2• 3 months ago

Half of the time those sites also lazy load anyway so whatever you're looking for isn't even in the DOM yet

raydev• 3 months ago

If the page is lazy loading content then the local ctrl+f is not going to work, obviously.

If you’re hinting at an argument about whether lazy loading content should exist, that’s a separate discussion. In my experience, pages that override ctrl+f do it for a good reason

darajava• 3 months ago

Just use Ctrl+G - it does almost the exact same thing as Ctrl+F

magiclaw• 3 months ago

Yeah, super annoying when that happens. A workaround is to click the address bar (or press ctrl+l unless that's been hijacked too) and then do ctrl+f.

Cider9986• 3 months ago

Ctrl-f for page search and ctrl-k for website search[1].

[1] https://fmhy.net

kule• 3 months ago

Looking at you ctrl+r in web outlook...I want to reload the page not reply to the email!

qup• 3 months ago

Try ctrl shift r

igor47• 3 months ago

I use vimium in Firefox and so my default key bindings are the plug-in ones. I push 't' to create a new tab, for instance. If I want to use the website key bindings I have to to into "insert mode" ('i'), or I opt into specific keys by site.

I do like when websites use ctrl-k -- it means nothing to my plug-in so websites always get it, plus it helps with key binding discovery.

mrandish4• 3 months ago

I recently vibe-coded a browser UserScript to ensure certain keys are always passed through to my browser (and any other scripts I'm running). There's also an 'aggressive mode' activated by an assignable hotkey for poorly behaved sites that refuse to pass through any keys.

  // ==UserScript==
  // @name           Key Passthrough 2.0
  // @description    Ensure specific hotkeys reach userscripts on greedy sites. Ctrl+Shift+/ toggles aggressive mode for sites that swallow keys entirely.
  // @run-at         document-start
  // @include        *
  // @exclude        http://192.168.*
  // Always-enabled key codes: 27=Esc, 116=F5 (Refresh), 166=Browser_Back, 167=Browser_Fwd, 191=/
  // Other keycodes to consider: 8=BS, 9=Tab, 16/160/161=Shift, 17/162/163=Ctrl, 18=Alt, 37=LArrow, 39=RArrow, 46=Delete, 112=F1
  // ==/UserScript==

  (function () {
    'use strict';

    // Keys to passthrough in normal mode.
    // Esc, Ctrl, / (191) and Browser nav (166/167) are the core cases.
    // F1/F5 included if you have AHK remaps on those.
    // Esc included to prevent sites trapping it in overlays.
    const PASSTHROUGH_KEYS = new Set([27, 116, 166, 167, 191]);

    // Aggressive mode toggle hotkey: Ctrl+Shift+/
    const AGGRESSIVE_TOGGLE_CODE = 191;

    const REFIRE_FLAG = '_kp_refire';

    let aggressiveMode = sessionStorage.getItem('kp_aggressive') === '1';

    const logPrefix = '[KeyPassthrough]';

    const announce = (msg) => console.log(`${logPrefix} ${msg}`);

    if (aggressiveMode) announce('Aggressive mode ON (persisted from earlier in session)');

    // --- Normal mode ---
    // We're first in the capture chain at document-start.
    // For passthrough keys, do nothing — just let the event propagate naturally.
    // The site's listeners follow ours in the chain, so we've already won the race.

    // --- Aggressive mode ---
    // For sites that still swallow keys via stopImmediatePropagation in an
    // inline <script> that races document-start: block the site's listeners,
    // then re-dispatch a clone after the current call stack clears so our
    // userscripts get a clean second shot.

    function refire(e) {
        // Build a plain init object from the original event
        const init = {
            key:            e.key,
            code:           e.code,
            keyCode:        e.keyCode,
            which:          e.which,
            charCode:       e.charCode,
            ctrlKey:        e.ctrlKey,
            shiftKey:       e.shiftKey,
            altKey:         e.altKey,
            metaKey:        e.metaKey,
            repeat:         e.repeat,
            bubbles:        true,
            cancelable:     true,
            composed:       true,
        };
        const clone = new KeyboardEvent(e.type, init);
        clone[REFIRE_FLAG] = true;
        // After current capture/bubble cycle fully completes
        setTimeout(() => document.dispatchEvent(clone), 0);
    }

    function handleKey(e) {
        // Ignore our own re-dispatched events
        if (e[REFIRE_FLAG]) return;

        // Aggressive mode toggle: Ctrl+Shift+/
        if (e.ctrlKey && e.shiftKey && e.keyCode === AGGRESSIVE_TOGGLE_CODE) {
            aggressiveMode = !aggressiveMode;
            sessionStorage.setItem('kp_aggressive', aggressiveMode ? '1' : '0');
            announce(`Aggressive mode ${aggressiveMode ? 'ON' : 'OFF'}`);
            e.stopImmediatePropagation();
            return;
        }

        if (!PASSTHROUGH_KEYS.has(e.keyCode)) return;

        if (aggressiveMode) {
            // Block the site from seeing this key, then re-dispatch for our scripts
            e.stopImmediatePropagation();
            refire(e);
        }
        // Normal mode: do nothing, let event propagate naturally
    }
    document.addEventListener('keydown', handleKey, true);
    document.addEventListener('keyup',   handleKey, true);
  })();

joquarky2• 3 months ago

There should be a toggle control near the navigation buttons that toggles between document mode and app mode.

jeffalyanak• 3 months ago

Rather than outright disabling it, I wish it was a permission the site would have to request.

That way trusted sites that used it responsibly could be given permission, but it could not be used by any random site.

binkHN• 3 months ago

This is the way.

varenc• 3 months ago

I keep a bookmarklet handy that blocks all keypress listeners to disable this stuff. Agreed it's quite annoying! Can share if desired, though pretty straightforward.

nesk_• 3 months ago

Actually, you can do that with Firefox, either per site or as a global policy.

https://superuser.com/a/1317514

Baljhin4• 3 months ago

Big thanks for that!

damn!- was sitting in the Fx queue for TEN years: https://bugzilla.mozilla.org/show_bug.cgi?id=380637

merelysounds• 3 months ago

Looks like there is also a client side solution for that, at least in Firefox; it's possible to prevent a page from modifying browser history:

Open the about:config page in Firefox
Search for "pushstate"
Double-click "browser.history.allowPushState"

source: https://superuser.com/a/1688290

pfg_• 3 months ago

Usually when I see this from non-spam sites, it's not even pushstate, it's just some page that redirects as soon as it loads. So you press back twice and it goes back -> forwards -> back -> forwards. Disabling pushstate doesn't fix that, it just makes pushstate equivalent to a redirect.

chmod775• 3 months ago

I haven't had that problem in a while. Did browser vendors already do something about it?

fluoridation• 3 months ago

That's relatively easy to work around. Right-clicking on the back button lets you go back several steps at once. I don't know about Chrome, but it does work on Firefox.

SquareWheel2• 3 months ago

Single Page Applications use the History API to create a working back/forward history within the SPA. This will cause you to navigate away on use, and potentially lose data.

joquarky2• 3 months ago

That sounds like a design failure.

HappMacDonald2• 3 months ago

Why don't they just use # hash urls for their in-SPA page urls instead? That's what Elm and Elixir LiveView both do.

mrandish4• 3 months ago

Browser.history.allowPushState was deprecated in Firefox V47 (2016) once they'd restricted the ability of sites to muck with history state via JS. This used to be a pretty big issue but as a daily Firefox user for 20 years, sites changing history state hasn't been a problem in recent memory, so whatever they did works pretty well.

But the TFA is about a related issue with a similar symptom, hijacking (or disabling) the back button in Chrome browser. This also hasn't been an issue in Firefox in recent memory (kind of shocked to learn it still was until now in Chrome). However, I did have a problem in recent years in Firefox with sites hijacking the Browser_Back keycode and/or hotkey (keycode 166 or Alt+Left Arrow) but I solved it with a small UserScript I posted elsewhere in this thread.

I rarely click the back arrow icon on the interface since I have a three-finger tap on my touchpad assigned to send the Browser_Back keycode when the active window is Firefox. Being a keycode, this can be intercepted by site JS. While sites intercepting Browser_Back (keycode 166) is rare, some video players use the arrow keys to skip forward/back and Alt+Arrow to skip more. Since Firefox uses Alt+Left Arrow as the back hotkey, this can be an issue. I fixed it with a UserScript that prevents sites from blocking certain keycodes. Note: you can also change all Firefox's hotkeys by going to "about:keyboard".

ohnoesjmr• 3 months ago

What about SPAs tho? Some of the state is in the URL, and as the user fills the form, you might push state to undo last step of the form. Does this mean that in this context the user gets thrown to about:blank? That would break tons of websites.

mancerayder• 3 months ago

Do we include reddit.com here, or too big to influence?

vashchylau• 3 months ago

I initially thought this is for Android.

Which has a long overdue problem of "Tap Back again to exit" type hijacks.

Or feed-based apps (hi Reddit, TikTok, Instagram) refreshing your timeline in hopes you reconsider exiting and keep doomscrolling.

One can only hope…

tgtweak• 3 months ago

Was honestly thinking "yeah nice Google, now do it for Android" since the worst offenders are apps (looking at you, Tiktok)

butokai• 3 months ago

Same for me! It took me a while staring at the article and wondering why "browser" was mentioned so many times, to realize it was not Android

KevinMS• 3 months ago

what about back buttons reloading the page so to have any continuity you have to open everything in a separate tab? youtube for example

sam1r2• 3 months ago

Finally! (For this feature to be shipped).

Almost unrelated, but.. I wonder ..if there was an APM intern[1] behind this, or maybe this was this project. Because, this, would have been an excellent one!

[1] I had the fortune to be one myself in June 2012 for the Chrome Team.

benj111• 3 months ago

Ah the irony. Wouldn't let me go back without clicking the cookie thing.

urbandw311er• 3 months ago

The idea of Google lecturing anybody about hijacking UI for dark patterns is absurd.

The company that hijacked an open source mobile OS and turned it into a closed source profit machine.

The company that hijacked the web so “accelerated mobile pages” could effect a walled garden.

The company that hijacked a browser and turned it into an anti-privacy tracking system.

It’s like R. Kelly giving a keynote on safeguarding minors.

EDIT: …but, yes, to be clear, I loathe the hijacking of back buttons too. Just a shame I have to read this sanctimonious shit from a company with such a terrible track record on trust.

SilentM68• 3 months ago

That's a great step in the right direction since that happens to me all the time. But the penalty of "Manual spam action or automated demotion in Google Search results (as a 'malicious practices' spam violation)" seems a bit lenient.

arewethereyeta• 3 months ago

20 years too late SEO fix.

nullc• 3 months ago

Maybe there should be a policy against links that display one destination but actually go somewhere else by changing the target with an onclick event.

oh wait.. that won't happen: google is the biggest offender, using that technique to surveil browsing activity.

bartread• 3 months ago

I assume this is not going to negatively impact well behaved use of the History API to facilitate back/forward navigation within SPAs?

youknownothing• 3 months ago

Isn't this going to break a lot of React Router navigation? Are they going to manually check every website to see if their manipulation of the history is legit or spammy?

nixpulvis• 3 months ago

Broken back buttons have been one of my biggest complaints since we enabled SPAs to access the history API in the first place. I don't see it as a net win so far, but maybe a decade later we can solve it?

wafflemaker• 3 months ago

I sometimes forget there's good people working at Google too.

Sorry for every time I called Google the Satan and didn't add exception for the good people working there!

A new spam policy for “back button hijacking”

Related Stories