
Google Chrome to stop back-button hijacking - huntermeyer
https://chromium-review.googlesource.com/c/chromium/src/+/1344199
======
jlebar
I implemented the history.pushState API in Firefox many moons ago. Dunno why I
didn't add this protection then, other than, it was a simpler time. It was
around then that we added the API for vibrating a phone and we all sort of
said "eh, someone _could_ abuse this, but why would they?" (In my defense on
that one I was on the side arguing that they would do it specifically for ads
and we needed to lock it down.)

Anyway, I approve of this change.

~~~
aerovistae
Can you explain how this change stops abusers while still allowing front-end
routing? I’m a bit confused because they seem mutually exclusive to me, or
should I say they come together or not at all.

~~~
dfabulich
The commit comment explains, "Entries that are added to the back/forward list
without the user's intention are marked to be skipped on subsequent back
button invocations."

The commit doesn't include a mechanism for marking the
should_skip_on_back_forward_ui flag, but the normal way Chrome verifies
"user's intention" is waiting for a gesture/click in the page.

So if you're doing front-end routing in response to a user clicking on a link
or button in your UI, or swiping the page or what have you, that will allow
you to pushState and then intercept the back button, as you can today.

But if you attempt to pushState on load, that's not enough to establish
intention; the back button will then skip your pushed states and leave the
page.

~~~
nikanj
A lot of seedier sites already abuse these mechanisms, by doing nasty things
when you click to close a GDPR notification, focus a search box, or similar
intention.

Browsers will probably never be clever enough to tell which clicks had "the
right kind" of intention. The arms race continues!

~~~
ht85
Yeah but in that case the malicious website should only be allowed to push a
single frame, allowing you to escape by going back twice.

This is much better then the current solution where you have to long-clicking
the back button and manually pick a safe entry.

------
feross
One by one, the Chrome engineers continue to chip away at the techniques in
The Annoying Site [https://theannoyingsite.com](https://theannoyingsite.com)
(warning: open in a secondary browser).

Talk video here: [https://www.youtube.com/watch?v=QFZ-
pwErSl4](https://www.youtube.com/watch?v=QFZ-pwErSl4) Source code here:
[https://theannoyingsite.com/index.js](https://theannoyingsite.com/index.js)

Well done.

~~~
Spivak
What is allowing site JS to physically move the browser window on my screen
and how do I burn this feature with fire?

~~~
quietbritishjim
This only works in popup windows. According to the guy who made this website
[1] this is to stop cross-origin communication, which is quite interesting.
But it also has the effect that if you force popup windows to appear in tabs
rather than windows then you do indeed burn the feature with fire. And IMO
it's worth doing anyway, because no one has the right to open a browser window
on my computer except me. It's possible in FireFox by changing
browser.link.open_newwindow.restriction to 0 in about:config [2].

[1] [https://youtu.be/QFZ-pwErSl4?t=558](https://youtu.be/QFZ-pwErSl4?t=558)

[2] [https://support.mozilla.org/en-
US/questions/1066799](https://support.mozilla.org/en-US/questions/1066799)

~~~
giancarlostoro
FireFox used to have an option to disallow pop ups to move themselves... I
can't find that setting anymore, and I think Chrome used to as well, it still
might. It's one of the first things I disable on my browsers due to some prank
sites using this tactic for maximum trolling.

~~~
badestrand
I wonder what could possibly be a use case why they would allow it and even
built an API/interface for that.

------
justkez
I've recently noticed Chrome (71) on Mac is now hijacking the `Command + Q`
shortcut and asking if I really want to quit. I appreciate people will
occasionally shut down a Chrome session by mistake, but it seems a little
ironic that they're clamping down on behaviour hijacking in one space whilst
implementing it in another.

(Caveat: I'm not sure if this change is being committed by a Google Chrome dev
or non-Google Chromium dev)

~~~
slig
When using Command + W to close a tab, it's only a fat finger away to close
the entire browser. Years ago that happened and it was a huge hassle since it
wasn't easy to reopen all the tabs you had.

~~~
woodrowbarlow
wasn't "reopen recent tabs" a launch-day feature for chrome?

~~~
slig
I'm not sure. I remember hitting Command+Q a few times by mistake and losing
whatever tabs I had open. Maybe I didn't know about that feature at that time.

------
SECProto
Funny, one of the things that convinced me to switch away from chrome (back to
Firefox) was when chrome got rid of the backspace-key-navigates-back. Sure, I
could use an addon to restore the feature but .... why should I live with a
browser that subverts decades of standard keyboard shortcuts?

~~~
SquareWheel
It was a horrible keyboard shortcut that caused countless lost form entries.
Just because something is standard doesn't mean it is good.

~~~
SECProto
Google had several possible solutions:

\- warn before navigating

\- give options for the keyboard shortcut

\- change shortcut unilaterally

They chose the third, which some (likely the overwhelming majority) preferred.
I didn't, so I switched to Firefox. We're both happy this way I guess.

~~~
SquareWheel
>warn before navigating

This requires too much page context. A search field being partially filled is
very different than a long registration form being worked on.

>give options for the keyboard shortcut

You said yourself, they released an extension for this.

~~~
SECProto
> You said yourself, they released an extension for this.

Oh was there an official one? At the time, the only extension I could find was
some slightly-sketchy third party one that allowed you to set hot keys for
many things.

> This requires too much page context. A search field being partially filled
> is very different than a long registration form being worked on.

Fair enough.

~~~
SquareWheel
>Oh was there an official one?

Yes, Google released an official extension to coincide with the update that
removed the hotkey.

[https://chrome.google.com/webstore/detail/go-back-with-
backs...](https://chrome.google.com/webstore/detail/go-back-with-
backspace/eekailopagacbcdloonjhbiecobagjci?hl=en)

------
sliken
Only the most anti-social sites break the back button, I kill the tab of any
site that does.

What I hate and is much more common is the "do you want notifications". I'd
love a "never ask about notifications again" option.

~~~
Klathmon
That's an option right in the settings. Along with all other permission
requests.

Just set it to "never ask" or something similar and it will auto-deny all
notification permission requests.

You can also enable it for specific sites if you want.

~~~
paulie_a
There is a bit of hubris when it comes to websites even asking to allow
notifications. No site is that important. why would I ever want to enable
notifications under any circumstance ever. I generally get badgered about it
by a site I'll probably only visit once.

~~~
hakfoo
It makes sense for web applications that are real applications. The CI suite
my company uses sends notifications for a passed/broken build, which is a
reasonable use. Mail sites can send new messages.

The problem is that there's lots of content the publisher thinks is
notification worthy, but not the user. No, I don't need a notification every
time you post to RandomNewsSite.com.

~~~
JohnFen
"The CI suite my company uses sends notifications for a passed/broken build,
which is a reasonable use. Mail sites can send new messages."

That would still annoy the hell out of me.

~~~
paulie_a
This is basically why I don't read work email. If it's important, someone will
come over to my desk asking if I got the email within 30 seconds. Hell I
stopped listening to voicemail from a previous boss and just deleted it, For
three years or so and it never caused a problem.

My default is now "select all, delete"

~~~
JohnFen
I just leave my email client and systems report open all the time. That way I
can easily glance over and check if something needs my attention when I have
some attention to spare, rather than be distracted by a notification appearing
randomly over my work.

------
lichenwarp
The full page email popups/page dimming are the worst, I hate that it has
caught on so much.

~~~
kurtisc
At least they have a nice big div to hit with your element blocker.

------
baybal2
I know why Google has reacted now, I noticed few month ago that "clickfarm"
websites began visually spoofing popular websites.

You accidentally click "clickfarm.com" from, say, google.com; then you press
back button, it seems that you are "back," by the moment you click on another
link, you realise that google.com page was fake, and is stuffed with invisible
ads.

~~~
fooker
What purpose does invisible ads serve?

~~~
happppy
I think opacity set to 0, you didn't knew but you saw the ad and this will
count as view?

~~~
baybal2
Google looks for obscured ads, but there are new ways of tricking both the bot
and the ads code coming out almost monthly.

What they look above all else are the organic clicks from clear IP ranges.

------
denormalfloat
Please also fix the back button on the PDF reader built into Chrome; pressing
the back button on my mouse seems to go nowhere.

------
cronix
I quit using chrome, but it would be nice if they alerted you to the fact that
the site is hijacking the button. Personally, when sites do that, I
immediately add them to a block list because they are shit and I don't want to
visit them ever again. Now you'll never know.

~~~
tylerhou
How do you define "hijacking the button?" There are many valid uses of pushing
state to history, and it's very difficult to distinguish a malicious use from
a non-malicious use in the general case.

------
xg15
More in-depth discussion about the rationale and design process behind the
intervention:
[https://github.com/WICG/interventions/issues/21](https://github.com/WICG/interventions/issues/21)

------
seanwilson
How does this work with single page apps where it's not uncommon to modify the
history?

~~~
sincerely
I mean, aren't SPAs kind of a hijacking of how browsers are intended to be
used?

~~~
evrydayhustling
I get what you're saying, but browsers haven't been stateless url-loaders
since the late 90s. JavaScript in general, cookies, local storage, and plug-
ins are all compromises with "pure" http navigation that (a) can be abused but
(b) offer some much needed client-side cooperation in maintaining continuity
and reducing repetitive traffic with the server.

~~~
kurtisc
There are ways of doing SPAs without polluting the history. In fact, I find
them less frustrating to use. If your design relies on cues taken from malware
pages, that's on you.

~~~
evrydayhustling
This is a frankly ignorant statement about SPA design. Pushing history on
major navigation events has nothing to do with malware patterns. It is way of
making SPAs compatible with user expectations and protocol investments based
on the non-SPA web. It allows them to use their own tools for bookmarking,
link sharing, and history management rather than forcing a from-scratch
experience when they come to the sites.

Accessible navigation patterns are a key part of making the web accesible to
decentralized improvement. If every SPA was a black box with its own
navigation regime, the web would regress to walled garden apps that
characterize 90s desktop and early iOS ecosystems.

~~~
kurtisc
I fail to see how I can be ignorant of what I find less frustrating and more
compatible with my user expectations.

>It allows them to use their own tools for bookmarking, link sharing, and
history management rather than forcing a from-scratch experience when they
come to the sites.

Such as the behaviour of buttons outside the sandbox the browser provides? To
quote you:

>browsers haven't been stateless url-loaders since the late 90s

Why break the expectations of the back button to hack the other tools to work
how you'd expect when, really, all of the features you're describing worked
perfectly fine before SPAs. The very reason pages like this frustrate me are
because they don't work with the history management I expect.

~~~
evrydayhustling
The ignorant part was accusing SPA authors of copying malware patterns.

Regarding your opinion, I'm still not sure what you are comparing /
suggesting.

Are you saying that late 90s reactivity on the web was good enough? I think
you are very much in the minority on that one.

Are you saying SPA authors shouldn't expose URLs for different navigation
paths to the browser? I think you would be surprised at all the places your
browser experience breaks, like not being able to restore tabs, or copy links
to interesting news stories.

The _right_ way to do SPA is to design nav actions that feel like links, and
only update the history in those. A user not watching carefully for page
refreshes or net traffic shouldn't be able to tell the difference - and
perhaps there are times this is happening on your browser that you aren't
aware of because it _can_ be done smoothly.

~~~
kurtisc
Hijacking history is a pattern used by malware and trying to stop it has
broken some honest websites. This happened with Flash, with Java applets, with
popups. It shouldn't be a surprise. As I see it, you're considering the
malware an acceptable sacrifice for having SPAs work slightly better (for what
you value as better and I don't).

Websites as apps will continue to work, they'll either lose this functionality
or use normal links - the kind that are good enough for Facebook et al. Or for
Hacker News.

>Are you saying SPA authors shouldn't expose URLs for different navigation
paths to the browser? I think you would be surprised at all the places your
browser experience breaks, like not being able to restore tabs, or copy links
to interesting news stories.

No. All of these work with links. Aren't you trying to fit a SPA shaped piece
in a website shaped hole?

~~~
evrydayhustling
Links force a reload of additional assets, break ongoing socket connections,
and at minimum requires a re-rendering of the entire DOM, which is a waste for
many navigation actions that still deserve their own URL. In particular, the
many tcp handshakes necessary for a total page refreshes are expensive on
mobile.

As a concrete exampke, rich news experiences that let you scroll through
preloaded stories benefit a lot from not needing to re-render all of the
surrounding layout when the content changes, and from assigning a different
url to each story.

Btw, I never said this was worth the current trade-off with malicious sites,
just that the history features were originally inspired and still used by
honest sites. Fortunately we have better options than all or nothing; sounds
like Chrome is implementing a heuristic that makes sure url history can only
be updated in some proportion to human actions. Another option might be a
whitelist check like "<site> would like to update your history".

------
jwilk
This works with JS disabled:

[https://bugs.chromium.org/p/chromium/issues/detail?id=907167](https://bugs.chromium.org/p/chromium/issues/detail?id=907167)

~~~
acdha
Thanks - the mountain of JS on the other page failed on iOS

------
yalogin
This is very much needed. Every site I visit through google news hijacks the
back button. They only show their news letter signup page for the most part
but still very annoying.

------
nbevans
How about stopping right-click hijacking and smooth-scroll hijacking too?

~~~
skohan
Right-click is very useful in some cases. I have some productivity apps I have
built for myself using web technologies, and it's extremely useful to be able
to have custom context menus. Since web applications are doing more of the
work that native apps used to, I'm ok with some level of annexation of the
browser's UX territory when a site can really justify it.

That said, I would be in favor of an option to disable it globally, or for
certain domains.

------
TACIXAT
Right now you can't close a tab with ctrl+w if the "Would you like to see
desktop notifications?" dialog is up. For a second I thought this was a fix
for that.

------
catmanjan
Does this mean they no longer support history.pushState?

------
ivanhoe
Will this affect SPA routers? How is "without the user's intention" defined,
does it mean programmatically added items or something else?

~~~
shortercode
If the current event loop task ( you may need to read up on the JS event loop
) was spawned by something like a click event then it is marked as a "user
interaction". These tasks can do things like opening a popup window, start
audio playback etc. whereas normal tasks are normally blocked from doing this.

It's a clever mechanism but malicious sites tend to just attach a click
listener to the page and trigger everything when the user clicks for the first
time.

On the other hand it can also be a pain to program around this if you need it.
Say you have a webapp that allowed you render an image then display it in a
popup. But the rendering is time consuming, so you do asynchronously in the
background. The user clicks the button and you start the render. When the
render is complete you try and open the popup, but your now in a different
task where the popup is blocked. The best way to work around this is to
display a modal dialog, saying that the render is complete. Then when the user
hits "ok" you can use the task that the event created to display the popup.
But it might confuse the user why they need to confirm the render is complete.

~~~
mikewhy
Couldn't you open the popup immediately while keeping a reference, do the
proceeding, then just manipulate the reference to the window you just opened?

------
thefounder
This is bad for my Electron app. I wish there would be a flag to disable all
the web "security"(i.e isTrusted field requirements).

