Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

Post reply on HN
Print view View original

461–470 of 532 posts

Re: A new spam policy for “back button hijacking”

#461

Post by lxgr »

zozbot234 wrote: post #444
lxgr wrote: post #253

Earlier quoted context omitted.

Why on Earth would the user be expected to implement a fix for a problem they didn't cause themselves in the first place?

Why the Earth should the user not want to implement a fix/workaround/whatever for a problem they didn't cause themselves but can trivially solve?

Because I expect my browser to work for me instead of having memorize workarounds for the new web annoyance of the day.

Clicking "back", noticing that the site broke it, moving the mouse and long-pressing "back" (I normally navigate with a mouse thumb button or a trackpad gesture) is much more annoying than my browser just preventing this from happening in the first place.

Re: A new spam policy for “back button hijacking”

#462

Post by stronglikedan »

darajava wrote: post #456
declan_roberts wrote: post #392

Earlier quoted context omitted.

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!

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

it's asking me for a line number

Re: A new spam policy for “back button hijacking”

#463

Post by gunapologist99 »

csomar wrote: post #105
p4bl0 wrote: post #76

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 inclu…

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 any…

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

Re: A new spam policy for “back button hijacking”

#464

Post by tgsovlerkhgsel »

kro wrote: post #455
tgsovlerkhgsel wrote: post #355

Earlier quoted context omitted.

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 t…

The URL does not even need to change, you can pushState with just a JavaScript object, catch the pop and do something like display a modal. (I use this pattern to allow closing fullscreen filter overlays the user opened) Still, requires user interaction, on any element, once. So the crawler needs to identify and click most likely the consent/reject button. Which may not even trigger for Googlebot. So they likely will…

Field data is a great point - it should be really obvious when people click "back", and many then click back again immediately after (or close the tab, or whatever people do to "escape").

Re: A new spam policy for “back button hijacking”

#465

Post by NetMageSCW »

SuperNinKenDo wrote: post #406
Tepix wrote: post #46

Earlier quoted context omitted.

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

Probably should have mentioned it, but I was on my phone browser where that option either doesn't exist or isn't surfaced well. A long press on the back button just does the same thing as tapping once, so I'm all out of ideas.

Probably should also mention which phone browser on which phone OS.

Re: A new spam policy for “back button hijacking”

#466

Post by totalwebtool »

_ink_ wrote: post #111

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.

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.

Re: A new spam policy for “back button hijacking”

#467

Post by ohnoesjmr »

mrandish wrote: post #448
merelysounds wrote: post #393

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

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) t…

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.

Re: A new spam policy for “back button hijacking”

#468

Post by magiclaw »

declan_roberts wrote: post #392
rat_on_the_run wrote: post #383

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.

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!

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.

Re: A new spam policy for “back button hijacking”

#469

Post by urbandw311er »

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.

Re: A new spam policy for “back button hijacking”

#470

Post by jeffalyanak »

rat_on_the_run wrote: post #383

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.

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.

Post reply on HN