You know that little arrow in the corner of your browser. The one that points left, or on a phone becomes a swipe from the edge of the screen. Most people use it fifty times a day and never think about how much trust sits inside that gesture.
A browser keeps a list of where you have been. Press back, and it peels away the most recent entry so you can return to the page beneath it. Simple. Familiar. Boring, even.
Except sometimes it is not. Sometimes you press back and nothing happens. Sometimes you press it again and the same page comes roaring back with a fake Microsoft logo, a siren, and a phone number demanding that you call immediately. The page has trapped itself inside your browser history, and the button you trust most suddenly belongs to somebody else.
This is not a new trick. It has a paper trail stretching back fifteen years, and almost every stage of that trail was visible in public long before most users had ever heard the phrase back-button hijacking.
The Warning Buried in HTML5
On January 13, 2011, the HTML5 Working Draft included a quiet security warning about a new session-history feature. Browsers were being given a way for webpages to say, in effect, remember this as a new stop in the user's journey, even if the page had not really taken the user anywhere meaningful.
The standards editors used the right word early: hijack. They were worried that a page could abuse the history stack and interfere with the browser's back button. The warning was not a headline, not a vulnerability bulletin, not even a binding rule. It was a note in a draft. Then the web moved on.
For a few years, nothing public seemed to happen. The danger sat there in the specification like an unlocked side door, waiting for somebody to realize it could be used as more than a design convenience.
From Browser Bug to Scam Infrastructure
In 2014, a Chrome bug report documented what happened when that history-manipulation feature was called in a tight loop. The browser could freeze. Memory usage climbed. Fans spun up. A normal browsing session became a stalled machine. The bug went into the queue.
By November 2016, the idea had already escaped the queue and entered the wild. Security researchers documented webpages deliberately stuffing fake entries into browser history while displaying full-screen fake security warnings and urgent phone numbers. Closing the tab became difficult. Pressing back became useless. The victim was left staring at the same alarm page over and over again, nudged toward the call-centre number that had been there from the start.
Through 2018, the technique hardened into an ecosystem. Cheap domains. Affiliate networks. Offshore call centres. Payments routed through gift cards, prepaid cards, and wire transfers. The technical trick was small. The fraud machine built on top of it was not.
Chrome Solves the Easy Part
In May 2019, Google engineers announced what Chrome called the History Manipulation Intervention. The logic was straightforward: if a history entry had been inserted without a real user action such as a click, tap, or keypress, the browser could keep that entry on record but teach the back button to skip past it.
The fix shipped publicly in Chrome 76 in late July 2019. For Chrome users on current versions, the classic back-button trap mostly stopped working. Press back once, the synthetic entry gets skipped, and the user escapes.
That mattered because Chrome was, and remains, the dominant browser. But it was only a partial victory. Browser security is uneven, and uneven protection is exactly what fraud operators know how to exploit.
Firefox, Safari, and the Long Delay
Mozilla patched a related browser-freeze problem in 2020 under CVE-2020-26963, but that did not mean Firefox users got Chrome's skip-over-the-fake-history-entry behaviour by default. Mozilla had the capability, discussed it publicly, and left the protection sitting behind a preference most ordinary users would never touch.
In 2022, standards discussion opened around whether browsers should formally standardize this back-button-skip behaviour so everybody handled the attack the same way. Years later, no binding web standard exists. Even the browser vendors acknowledged that the heuristics were imperfect and inconsistent.
Apple moved more quietly. Safari 16.3, released on January 23, 2023, changed behaviour after researchers reported abuse affecting iPhones and iPads. That helped users on current Apple software. It did nothing for older devices left behind on unsupported versions, including many of the tablets and phones most often used by older Canadians.
Firefox finally flipped its safeguard on by default on February 4, 2025, with Firefox 135. That left roughly six years in which Chrome users were broadly protected while many Firefox users, unless they had manually changed advanced settings, were not.
Google Names the Technique, the Law Still Does Not
In April 2026, Google Search Central announced that pages caught using back-button hijacking would face ranking penalties beginning June 15, 2026. A major platform had finally named the behaviour in plain language and tied it to a real commercial consequence.
That is still not the same thing as legal accountability. The code itself remains in a grey zone where the downstream frauds may be prosecuted but the JavaScript mechanism that traps the victim inside the browser rarely appears in court as the thing being charged. The phone scams get noticed. The history manipulation upstream usually does not.
There is still no standalone criminal framework in Canada or the United States built around this technique. Fifteen years after the first standards warning, the strongest response is still mostly product design and platform policy, not law.
Can It Still Be Done Today?
Yes. On any browser where the skip intervention is absent, outdated, or disabled, the trap still works. Older Firefox versions before 135. Older iPads and iPhones that never reached iOS 16.3. Older Chrome installations. Aging devices whose manufacturers stopped shipping updates. Legacy environments that still exist in large numbers in the real world.
That matters because the attack is selective. Scam pages can fingerprint a device before committing to the trap. A current Chrome build on a fully updated machine may get redirected somewhere harmless. An older iPad running outdated Safari may get the full siren, the fake warning, and the history flood.
The protection gap is not random. It favours users with new hardware, current software, and the knowledge to update both. It leaves behind exactly the people scammers most want to reach: older users, casual users, and anyone still relying on devices that have aged out of the update cycle.
What To Do When the Back Button Stops Belonging to You
The first rule is simple: do not keep fighting with the back button. That is the control the page is trying to steal. Close the tab instead.
On Windows or Linux, use Ctrl+W. On a Mac, use Command+W. If the whole browser is frozen, force quit it through Task Manager on Windows or Force Quit on macOS. If the page is blaring audio, mute the device first. The sound is part of the attack. It is there to force a bad decision.
On a phone or tablet, switch to the app switcher and swipe the browser away completely. Reopen the browser and close the affected tabs from the tab overview rather than returning to the page itself. Do not call the number on the screen. Microsoft does not announce support through a screaming browser popup. Apple does not. Your bank does not. Your carrier does not. The number is the scam.
If money has already moved, contact the card issuer or bank immediately, report the incident to the Canadian Anti-Fraud Centre at 1-888-495-8501, and file a police report if you may need a case number for insurance or reimbursement. Gift cards and wire transfers are usually gone. Credit card charges are the transactions most likely to be reversed if the response is quick.
The Browser Still Remembers
Somewhere right now, a page is loading on an older phone or tablet. It looks harmless at first: a help page, a software download, a printer fix, a tax tool, something ordinary enough to lower the reader's guard. Then the script runs. It fills the history stack with places the user never truly went.
And when the victim presses back, that tiny familiar arrow they have trusted for years no longer points toward safety. Nothing happens. Or worse, something does. The fake warning comes back. The noise starts again. The panic deepens.
That is what makes this story endure. The code is not especially large. The trick is not especially glamorous. But it hijacks one of the oldest assumptions in everyday browsing: that the browser remembers honestly. For millions of people on current devices, that assumption is mostly safe again. For everyone else, the old trap is still waiting.
Behind the Story
This investigation began with a narrow question: was back-button hijacking a real, continuous technique with a traceable documentary history, or just a loose label pasted over several unrelated browser annoyances? The record turned out to be unusually clear. The technique is real. The warnings are old. The fixes arrived slowly and unevenly.
Primary-source research for this piece included the January 13, 2011 HTML5 Working Draft at w3.org, Chromium's engineering documentation for the History Manipulation Intervention, Chrome's May 7, 2019 developer announcement, Apple's Safari 16.3 security advisory dated January 23, 2023, Mozilla bug reports and Firefox 135 release notes from February 4, 2025, the still-open WHATWG standards discussion begun in 2022, and Google's April 13, 2026 Search Central policy announcement naming back-button hijacking directly.
Additional verification relied on Canadian Anti-Fraud Centre advisories, Competition Bureau consumer warnings, and years of security reporting that documented the technique in the wild from 2016 onward. Where a number could not be tied to a primary document or an authoritative secondary source, it was left out. The goal here was not to dramatize the attack. The attack does that for itself.
One editorial decision shaped the final piece more than any other: this story does not name individual scam crews, call-centre operators, or victims. The mechanism matters more than the personalities. The people running the fraud change. The trap inside the browser history has stayed recognizably the same for more than a decade.