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

301–310 of 532 posts

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

#301

Post by bluGill »

dspillett wrote: post #191
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…

When I intentionally want to read something that is what I do. However once in a while I'm scrolling, selecting a window, or some other activity; and I happen to click on a link: instead of whatever action I intended I end up on a new page I didn't want to read (maybe I will want to read it, but I haven't go far enough cognitively to realize that). That is when I want my back button to work - a get out of here back to where I was.

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

#302

Post by wat10000 »

tripflag wrote: post #295
wat10000 wrote: post #289

Earlier quoted context omitted.

Better yet, just save. Storage is cheap and fast these days. The “do you want to save?” idiom is a leftover from the days when a moderately sized document would take a noticeable amount of time to save and eat up a decent chunk of your floppy disk.

But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.

If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.

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

#303

Post by zozbot234 »

Spare_account wrote: post #286
zozbot234 wrote: post #141

Earlier quoted context omitted.

It's a fix because it completely solves the issue on any site, without requiring changes from LinkedIn or any other actor.

>it completely solves the issue on any site It doesn't solve the problem with Instagram links, which in my experience do the following: 1) Open a new browser tab, with no history. 2) Close the original tab, so I can't easily get back to where I was.

That's a different kind of dysfunction, though. You can address it by copying the link and pasting it in a new tab, or if that's not possible, copying the current page to a new tab and clicking on the link there.

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

#304

Post by ImPostingOnHN »

thepasch wrote: post #194
miki123211 wrote: post #133

Earlier quoted context omitted.

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

There is already plenty of precedent for real-time-served ads which are annoying, or malicious, or install malware; or outright exploit vulnerabilities in the browser.

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

#305

Post by mixedbit »

An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.

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

#306

Post by cachvico »

I use Chrome on my Android and Mac. For a while I've appreciated the seemingly built-in anti-hijacking measure that always does what I expect on the second Back press. (The first Back may pop up a subscription box for example, but the second will always return me to where I came from).

I actually felt that this was a solved problem, so I'm surprised to see so many people still suffer getting stuck in redirect loops.

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

#308

Post by sznio »

blooalien wrote: post #206
Arainach wrote: post #135

Earlier quoted context omitted.

> The problem is, there are two conceptions of the back button, and the browser only implements one. In web browsers, there is only one concept. There is no concept of "up one level in the heirarchy". If you want that make your own button in your website.

> There is no concept of "up one level in the heirarchy". If you want that make your own button in your website. https://lifehacker.com/how-to-move-up-one-url-level-in-chrom... *shrug *

amazing, took me 5 clicks of the back button to finally get back from that link

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

#309

Post by [deleted] »

bastawhiz wrote: post #290
ChrisMarshallNY wrote: post #283

Earlier quoted context omitted.

Would this actually fall afoul of their new policy, though? Assume the way that universal links work, is that the site main page is loaded, and some hash is supplied, indicating the page to navigate to from there. That's annoying, but perfectly valid, and may be necessary for sites that establish some kind of context baseline from their landing page.

It's not valid. You went to a page. They said "no, you're actually on the feed," and then immediately navigate you to the page you'd actually intended to visit. This is that they're doing today, and it's terrible. If I go to a URL, I'm NOT going to your homepage feed. I never wanted to go there.

[deleted]

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

#310

Post by ImPostingOnHN »

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 likely scan the web pages themselves, but you shouldn't be using Chrome anyways, if you care about privacy from Google.
Post reply on HN