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

191–200 of 532 posts

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

#191

Post by dspillett »

firefoxd wrote: post #120

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

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

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

#192

Post by notpushkin »

TeMPOraL wrote: post #167
PhageGenerator wrote: post #60

Earlier quoted context omitted.

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.

> full screen modals Thanks. I never imagined this is a thing, it's an useful addition to my mental model of software components, to explain why back button on web behaves in weird ways for some apps. But it sure does sound like a dumb pattern on the web.

While we’re making sure that modals are recorded in history so that you can close them with the back button on mobile (e.g. https://svelte.dev/docs/kit/shallow-routing), MSFT can’t be bothered. But when it comes to abusing the very same history API to grab the user’s attention for a bit longer...

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

#193

Post by notpushkin »

AndrewDucker wrote: post #90
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.

You can right-click on the back button in Firefox to see a list of previous sites to go back to.

Yeah, it’s the same feature, just two different gestures. (And long tap works with Firefox on Android, btw.)

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

#194

Post by thepasch »

miki123211 wrote: post #133
lmm wrote: post #77

Earlier quoted context omitted.

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

More likely, advertisers will need you to insert a "bootloader" that fetches their code and passes it to eval(). Alternatively, they might require you to set up a subdomain with a cname alias pointing to them (or a common CDN), negating any security benefits of such a practice.

> More likely, advertisers will need you to insert a “bootloader” that fetches their code and passes it to eval().

Sounds like legal precedent waiting to be set. “Run our code so that it looks like your code, acts like your code, and has all the same access as your code” seems like it should be a slam dunk if said code ends up doing a Very Bad Thing to your visitors.

But of course that’s assuming common sense, and the law’s relationship with that isn’t always particularly apparent.

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

#195

Post by direwolf20 »

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…

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

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

#196

Post by nottorp »

dominicrose wrote: post #168
nottorp wrote: post #159

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

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.

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

So isn't that also back hijacking?

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

#197

Post by krater23 »

socalgal2 wrote: post #173
ryandrake wrote: post #25

Earlier quoted context omitted.

I’d go back in a heartbeat. Making the web a software SDK was the worst thing to happen to it.

So, apparently you don't use google maps (or any other mapping website)

The data that google maps is caching in my browser is more than Google World needed disc space back then. So why not just use Google World for that?

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

#198

Post by csomar »

rbits wrote: post #179
csomar wrote: post #105

Earlier quoted context omitted.

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…

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

Good point. Chrome has a “feature” where if your website is google-flagged, it’ll display a danger alert when visiting it. For some reason I confused that with this.

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

#200

Post by zelphirkalt »

andreareina wrote: post #57

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

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.
Post reply on HN