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

441–450 of 532 posts

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

#441

Post by yegg »

daemon325 wrote: post #427
mx7zysuj4xew wrote: post #397

Earlier quoted context omitted.

Kagi costs money and isn't that great to begin with

People just keep pitching Kagi as revolutionary, especially software engineers and people on HN. I respect a lot of them, people I respect a lot, and I saw people like Jon Gjengset use it. so I gave it a few months of daily use. I just eventually drifted back to Google. The results weren't better for anything I search for. It felt different, but not better in any measurable way. $10/mo for a different feel is a stran…

This hasn't been our experience; can you please reach out to me with specific examples? My email is in my profile.

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

#442

Post by SquareWheel »

joquarky wrote: post #437
SquareWheel wrote: post #434

Earlier quoted context omitted.

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.

That sounds like a design failure.

Well, yes, but that's why it's behind an about:config flag and users should not enable it without understanding its effects.

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

#443

Post by butokai »

vashchylau wrote: post #417

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…

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

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

#444

Post by zozbot234 »

lxgr wrote: post #253
zozbot234 wrote: post #163

Earlier quoted context omitted.

> The fix is to not to implement anti-user patterns. That's not a fix the user can implement themselves. Holding down the back button is comparatively trivial.

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?

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

#445

Post by fluoridation »

pfg_ wrote: post #401
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

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.

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.

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

#447

Post by sam1r »

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.

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

#448

Post by mrandish »

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

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

#449

Post by myself248 »

fragmede wrote: post #419
myself248 wrote: post #414

Earlier quoted context omitted.

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…

> the browser doesn't recognize what I'm clicking on as a link. It's entirely possible the browser itself does , but that the site's JavaScript is (also) overriding the right click handler. There's browser extensions to override their override but having to do that is stupid.

I've installed one of those and it doesn't seem to help in the ecommerce case.

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

#450

Post by snowwrestler »

beastman82 wrote: post #298
snowwrestler wrote: post #293

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…

They've been crawling the web since inception

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.

Post reply on HN