Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

391–400 of 532 posts

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

#391

Earlier quoted context omitted.

I'm not sure what exact device you're using, but on iPhone 12 Mini, old.reddit.com is borderline unusable, very different experience compared to if you could access r/all like before via the actually usable web+mobile version, a comparison: https://imgur.com/a/AVGjjCN Anyways, the end result has been I don't use reddit at all on the phone, so kind of ended up being good for me anyways.

“Borderline unusable” is such a hyperbolic way to describe a fully functional design that doesn’t happen to be responsive. Hacker News must be borderline unusable for you as well then, no?

> Hacker News must be borderline unusable for you as well then, no?

On my phone? Yes, absolutely, impossible to hit the links correctly even if I zoom in. Both old reddit and HN is "Fully functional" on desktop, agree, but far cry from "fully functional" on my arguably tiny iPhone.

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

#392

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!

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

#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

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

#394
post #113

Earlier quoted context omitted.

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page. This feels like a reasonable counter-measure.

> It's also a great way to store state so that a user may bookmark or link something directly. Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.

Sure. I'm not speaking about preserving the full history stack in the URL, just storing state. Apologies in advance if my explanation for what I mean is something you already understand.

This can be as simple as having a single checkbox with a checked/unchecked state.

when you load the webpage, the javascript can pull in the url parameters with URLSearchParams (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchPa...). If the url parameter you set is set to 'on' then the checkbox, which is by default unchecked, can be set to on.

You have your checkbox:

    
And then you have your javascript:

    const check = document.getElementById('check');
  
    // get state of checkbox from URL parameter
    check.checked = new URLSearchParams(location.search).get('state') === 'on';
    
    // add event listener to call history api to alter the URL state.
    check.onchange = () => { history.replaceState(null, '', check.checked ? '?state=on' : '?state=off'); };

The history.replaceState() replaces the URL in your history with the one including the URL parameter, so if a user were to bookmark it, it would store that and reload it when they revisit the webpage.

If I used history.pushState(), each time I clicked on the checkbox, a new item would be added to the stack. for a checkbox this is almost certainly a bad idea because your browser history is going to be polluted pretty quickly if you happen to click it multiple times.

pushState can be useful when it matches the user expectations, though, like if it is an SPA and the user clicks on an internal link to another section of the site, they'd expect to be able to go back to the previous page, even though we're still on the same actual html page.

So you would not be preserving the entire history stack. You can sort of do this by encoding state changes into another url parameter, but the behavior isn't entirely consistent between browsers. It also does require, as far as I know, an explicit action from the user for it to actually affect their navigation. So a website couldn't just add 1000 entries to the user's history on load without some explicit interaction on the web page.

Once the user interacts, though, it does seem like it opens up a lot of opportunity to abuse it, intentionally or not. You can asynchronously push thousands of entries into the browser history without blocking interactivity of the site. you can even continue to push state to the URL from other inputs while doing so.

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

#395

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.

Looking at you ctrl+r in web outlook...I want to reload the page not reply to the email!

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

#396

I want my browser history to be immutable and operate like a tree and not like a stack.

I've been kicking around an idea in my head of a modern browser implementing some kind of "hardening" against anti-features. Deviating from the standard, implementing certain architectural features like this WORM history graph, etc. I don't want to ditch javascript entirely as I don't think it's particularly unreasonable as a feature. That being said, I don't want my extensions to be available via a URL query (even if obfuscated like what Firefox does.) I have yet to find a single webpage utilizing scrolljacking where I would care if it was broken and completely unnavigable. I can count on one hand webpages where I felt like input reading was justified, and even then I wouldn't miss them if the facilities which enable input reading were just made completely undefined.

There certainly is a satisfaction that would come from a shit site like linkedin or youtube being reduced to a gibbering mess of exceptions. Scripting is a privilege, and it's a nice one, but abuse of it shouldn't be tolerated. I really don't see a usecase for boiling it down to a binary of allowing the whole gamut of complex programmability web browsers expose, or allowing none of it. I'd rather just draw a line and say "programs that use these features are acceptable, programs that use these ones aren't".

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

#398

Earlier quoted context omitted.

As a user, I don’t really care about the building materials used in construction. But that doesn’t mean builders should cut corners.

A building collapse and a poorly built website UI are completely different in terms of actual risk.

A building collapsing isn’t the only way people are affected by choices in construction. But if you want to talk about worst case scenarios then I can pick out some examples in IT too:

We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.

And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.

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

#399
post #105
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…

What aggravates me is that somewhere at Google headquarters some asshole thinks he's a fucking genius for turning the web into nerfed walled garden

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

#400

Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.

What does this have to do with sites being buggy? This change is about obvious intentional abuse.

SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.

If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.

Post reply on HN