Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Chrome Google Security IT Technology

Google Working on Blocking Back Button Hijacking in Chrome (zdnet.com) 152

Google engineers are currently working on a Chrome browser update that will block malicious websites from hijacking the browser's history and, indirectly, the Back button. From a report: The issue at hand is a well-known tactic often seen employed by many shady sites across the Internet. A user would visit a website, then he'd accidentally click or tap on an ad, and be taken to a new page. But when the user presses the Back button to go back to the previous page, the browser just reloads the same page over and over again, keeping the user trapped on the ad page. [...] Recent source code updates to the Chromium project, the open-source browser engine behind the Chrome browser, reveal that Google engineers are planning to crack down on this type of abusive behavior. These code updates will allow Chrome to detect when browser history entries have been generated by user interaction, or by an automated method.
This discussion has been archived. No new comments can be posted.

Google Working on Blocking Back Button Hijacking in Chrome

Comments Filter:
  • by Anonymous Coward

    But I'm sure there will be some of this
    https://xkcd.com/1172/

  • Easy (Score:1, Informative)

    by Anonymous Coward

    Store date and url.
    Remove all urls displayed less than 3s.

  • I suspect the notice fails to mention this feature is not entirely new.
    I remember that in a few shadier sites I used in the past for watching movies, the redirects did not go into the history, I had to monitor DNS when I was trying to blacklisting them, however they changed them every day, and then I resorted to whitelisting.
    Maybe some shadier sites found out strategies to get around it, but then the newspiece is not entirely clear on that feature not being entirely new.
    • Re: (Score:1, Flamebait)

      Hitting the back button in the browser takes you to the previous site in the history. If the redirects from your shady site weren't going into the history, hitting the back button would go to what was in your history, not a redirect page that would keep you trapped on the site.

      Here's tip: When you're trying to sound super intelligent, make sure that you haven't gotten the logic in your post ass-backwards.

    • by PPH ( 736903 )

      Shady sites get opened in their own tab. Or window. And then get closed when I'm tired of fighting with them.

  • Disclaimer: Web developer here.

    Whenever I need to fix a broken or out of control sequence on a bloated POS website, catching the Backbutton is one of the quick and dirty hacks that sort of solve the problem. It doesn't feel right though.

    PWAs are borderline, IMHO, because they interfere with the network and Adress bar. However there seems to be sort of a standard on how to do it and you can expect a good site to follow suit. Service Worker is to cool a concept to leave out, it's a good hack that makes the we

    • by Hentes ( 2461350 )

      But isn't the back button breaking web apps a good argument to allow it to go back to the previous page? Then your web app wouldn't have to worry about it.

  • The embrace of "use javascript to do whatever the fuck you want" has really come back to bite users. It makes people money, so it's not going anywhere until someone gets fed up with all the cat and mouse games and makes a legit system that doesn't rely on it.

    • by Merk42 ( 1906718 )

      The embrace of "use javascript to do whatever the fuck you want" has really come back to bite users. It makes people money, so it's not going anywhere until someone gets fed up with all the cat and mouse games and makes a legit system that doesn't rely on it.

      Which would either be:

      Full page refreshes for every action:
      Sites are free to do this now (even you or any of the armchair developers in here could build a site doing this!), but they probably wouldn't because users are used to instant response in their actions

      Use some other language:
      Which would then evolve to be able to do the same things as JavaScript anyway.

      • by lgw ( 121541 )

        I'm perfectly happy with web sites that do nothing until I click on a link. Everything I've seen that relies on JS tricks is just bad UX and we're better off without it. From the evidence before me, JS is used entirely to make the UX suck.

        But, still, the average Web UX is vastly better than the average mobile app UX, so it's go that going for it. Sadly, mobile app UX brain damage is starting to leak into web design, so all hope will eventually be lost.

        • I'm perfectly happy with web sites that do nothing until I click on a link. Everything I've seen that relies on JS tricks is just bad UX and we're better off without it. From the evidence before me, JS is used entirely to make the UX suck.

          But, still, the average Web UX is vastly better than the average mobile app UX, so it's go that going for it. Sadly, mobile app UX brain damage is starting to leak into web design, so all hope will eventually be lost.

          Meh, I don't have a problem with, say, Slashdot's UX, where comments aren't loaded until you click on them (except for the first few lines, and any comments that meet the threshold for inlining). That sort of JS UX is fine with me.

      • Which would either be:
          Full page refreshes for every action:
        Use some other language:

        Only two options and nothing else? [imgur.com] hmm...

        • by Merk42 ( 1906718 )
          First off, it's not a dichotomy since there is the 3rd option of Status Quo. Second, if you can provide a third (fourth?) situation, I'm all ears.
          • There are so many options.

            * expand HTML/CSS so that javascript isn't needed
            ** "onVisible" which loads contents into a div from a provided URL
            ** expand CSS to have (non-chainable) animation events that can be activated by "onClick"/"onHover"/etc...

            * restrict javascript's communication/loading/computational capability
            ** only allow a single domain to load javascript from
            ** limit javascript to being able to interact a specified (in the html document) list of domains
            ** remove lots of the "features" that enable b

            • by Merk42 ( 1906718 )

              * expand HTML/CSS so that javascript isn't needed ** "onVisible" which loads contents into a div from a provided URL ** expand CSS to have (non-chainable) animation events that can be activated by "onClick"/"onHover"/etc...

              Not sure how much of that belongs in CSS, though that's really semantics. Even still, it falls under "use a different language that would evolve to do the same stuff anyway."

              restrict javascript's communication/loading/computational capability ** only allow a single domain to load javascript from ** limit javascript to being able to interact a specified (in the html document) list of domains ** remove lots of the "features" that enable bullshit like this ** make javascript computation a resource which will halt after so instructions are executed

              Sure, your web apps will need special whitelisting to work but nobody gives a shit.

              Okay so something that is restricted in functionality by design? Sounds great [ampproject.org]

              • Not sure how much of that belongs in CSS, though that's really semantics. Even still, it falls under "use a different language that would evolve to do the same stuff anyway."

                Incorrect. The purpose is that it would be limited to user interaction based animations, incapable of chaining events and thus no longer be Turing complete. Turing completeness is really what's enabling bad behavior. Remove the capability and remove the threat.

                Okay so something that is restricted in functionality by design? Sounds great [ampproject.org]

                AMP modifies pages and there is no mandate compliance. The idea is to stop bad behavior rather than just avoid it's consequences.

                • by Merk42 ( 1906718 )
                  Right, you just want reduced functionality and think that users as a whole would be fine with that.
                  • Not at all. I'm sure plenty of idiots will bemoan the loss of javascript games. Likewise people who build their business models on selling information will be upset.

                    The truth is that scripting isn't needed for building web pages but it sure is profitable.

                    • by Merk42 ( 1906718 )
                      Ah yes, literally the only two purposes for JavaScript are games or harvesting information.

                      Now who's using a dichotomy?
    • Exactly. I hate JavaScript. Everyone disliked Flash but Javascript is much worse because it spreads all over the page DOM. At least Flash was confined to a single DOM node (aka a single box in the page). The only benefit of Javascript is the client implementations are better, but the concept is much worse. Even if browsers prevent back-button hijacking, there is still the problem of pop-ups having come back in force by using javascript overlays. And pages that load ads dynamically when you just want to read
  • Teach your idiot friends and family how to use Task Manager to kill the Chrome process, instead of calling the "Microsoft Support" number and giving them your credit card number!
    • That's great... except of course you've now closed the page (that had the ad you accidentally clicked) you were trying to view, as well. So now you have to re-navigate to it.

      Google's seems like a perfectly fine solution to an irritating problem that bites me occasionally.

  • by Oswald McWeany ( 2428506 ) on Wednesday December 19, 2018 @10:25AM (#57829874)

    I'm curious if they are going to discriminate between legitimate and illegitimate forms of updating the browse history. On some of my single-page apps I change where the back-button takes them. Not to trap them, but to provide functionality. I wonder if this is going to be blocked for everyone, or just the people who set up an infinite loop of back buttons leading to the same page.

    • by Anonymous Coward

      On some of my single-page apps I change where the back-button takes them.

      Since the first time I loaded up Mosaic, I have expected the back button to take me back. Not sideways.

      • by reanjr ( 588767 ) on Wednesday December 19, 2018 @10:42AM (#57829978) Homepage

        That's fine when every click loads a new page, but If a click simply loads new content into the same page, it makes sense to tweak the history in those cases to make the back button work as expected.

        • ^ This.

          If all I need to do is send a XHR request for a few to hundreds of KB to render what is required, why reload the page and all the dependencies and images (let's ignore caching for argument sake). Sure, the front-load of a few MB for the whole application is a few seconds, but the rest of your experience is immediate and responsive.

          Don't you wait for Photoshop, Word, Outlook, whatever-game-you-play etc to finish loading before you start using it?

          This idea works well for pages where I will be visiting

          • by jenningsthecat ( 1525947 ) on Wednesday December 19, 2018 @02:45PM (#57831394)

            And then in that case, you take control of the back button so it doesn't break the experience.

            No, in that case you provide a clearly marked Back button or link as part of YOUR interface. If necessary, you add a brief explanation as to why YOUR back button is better in the current context than the browser's Back button. Don't be messing with MY interface - Home, Forward, Back, and Stop buttons. When you screw with those, you've 'broken the experience' by definition, you've created non-standard behaviour, and you've pissed me off to the extent that your site is on my shitlist and I won't be visiting it again.

            • The standard behavior is to let websites screw around with the browser's history. If it's done properly it's practically invisible - sure if you're watching for it you'll see the manipulation going on, but to most users the browser's back button does actually do what they expect it too and they are completely oblivious as to what actually happened and the technical details of how the website really works. However, like a lot of things on the web that were created to make things more user-friendly, this ca

        • but If a click simply loads new content into the same page

          Then you should make it clear to the user that the context of your page has a different interface than the standard one they expect, and not change the defined behaviour of an existing system which has a different functionality.

      • Re: (Score:3, Interesting)

        Since the first time I loaded up Mosaic, I have expected the back button to take me back. Not sideways.

        If you're using AJAX within a webpage though, sometimes you expect the back button to take you to what you were previously viewing NOT make you leave the site altogether. If a single page is dynamically updating content based upon what you click on, you probably want script manipulation of the back button.

        Example, I have a table of widgets- I click on a widget and it loads details (you haven't changed website or been forwarded to a new address)... if you click the back button you probably want it to return

        • Re: (Score:3, Insightful)

          I can see what you're getting at. In some cases, when a user navigates through a web page that is built and displayed dynamically through javascript without reloading its parent page, a user might expect that hitting "back" would take them to the previous frame of whatever content they last navigated through. They could become annoyed when "back" actually takes them wherever they were before arriving at the site initially and losing all their progress.

          But I don't agree that selectively modifying "back" bu

          • by Oswald McWeany ( 2428506 ) on Wednesday December 19, 2018 @12:13PM (#57830618)

            I also understand that the browser allows you to modify how things like the back button work. I just personally wouldn't build important functionality in my site around something the browser normally controls, and wouldn't be terribly surprised if it stopped working the way I'd originally intended after a browser update.

            Well, the answer is you don't build important functionality into the back-button, you give other options and try to get the user to use those other options for navigating; HOWEVER, you can't control a user and can't prevent them clicking the back-button if they really want to (all you can do is try to handle it gracefully if they do). In an ideal world the end-user wouldn't use the back button from navigating in a web-application; but you can't easily prevent them.

            • In an ideal world the end-user wouldn't use the back button from navigating in a web-application; but you can't easily prevent them.

              Sure you can - just not the first time. Put your own nav buttons in your UI, and warn about using the browser's Back button. If they hit the latter and lose a half-hour's worth of whatever they're doing, then the next time they'll heed the directions. Don't break my experience because some people won't follow instructions.

              BTW, over the years I've experienced MANY warnings about not using the Back button, so it's not as though I just pulled the idea out of my ass.

              • BTW, over the years I've experienced MANY warnings about not using the Back button, so it's not as though I just pulled the idea out of my ass.

                Yeah... and it doesn't work. People still click the back button.

    • Most likely, they will track the source of the history update and ignore it if isn't a click. Additionally, they will likely squash multiple history updates from a single click into one.

      • by skids ( 119237 )

        Yeah, that seems like the most reasonable approach. You only get one per click (or kb enter outside a textbox)

    • If you came from a different domain name, then the back button has probably been hijacked.
      Also, all they have to do is add a property to the history log: user click vs script modification.

    • Re: (Score:3, Insightful)

      by Dan East ( 318230 )

      They usually flood the navigation history with many bogus entries, so you'd have to click Back a hundred times to actually go back. That would be easy to detect.
      If they are more intelligent and just use a single bogus history entry, and when it is navigated to always create another, well that is easy to detect too.

      Another way to solve this is to only allow as many navigation history events to be added as there are user interactions. So if the user doesn't interact at all, no navigation history events can be

    • by MobyDisk ( 75490 ) on Wednesday December 19, 2018 @11:18AM (#57830272) Homepage

      This isn't talkong about an Angular app with routing that uses back properly. It is talking about automatic redirects like HTTP 301 or meta refresh tags. For those the sokution is easy, Firefox has done this for years. If you hit back, and the page then auto-redirects you immediately, ignore the redirect. The user then just has to hit back a few times, but at least they aren't stuck. Even better would be if hitting back went back to the most recent page that did not have an automatic redirect in it.

    • Not to trap them, but to provide functionality.

      Nope. You've broken the concept of the back button as well as the usability guidelines for some operating systems. If you want to provide functionality you should do it via the appropriate means. Changing the defined functionality of something is not appropriate.

  • by biggaijin ( 126513 ) on Wednesday December 19, 2018 @10:42AM (#57829986)

    I have encountered several fairly well-known news sites that fool with the back button, making it difficult to back up past their home page.

    Even more than this, I would love to see the browser people find a way to absolutely, positively block auto-play videos. The one at the top of a news story is irritating, but when you scroll past it and a little clone of the window pops up in the right margin and starts playing it really gets on my nerves.

    • Under Chrome/Centbrowser there is an extension called "AutoplayStopper" I have tested out and it works 100% of the time. Also "flash control" to catch flash stuff.

  • by Kohlrabi82 ( 1672654 ) on Wednesday December 19, 2018 @11:12AM (#57830206)

    Presto Opera (e.g. =12.x) had this feature years ago. Glad that we are slowly catching up to Opera's feature set...

    • Presto Opera (e.g. =12.x) had this feature years ago. Glad that we are slowly catching up to Opera's feature set...

      Opera seriously was the best browser ever.

      It was a crying shame when they decided to become a Chrome skin.

      • I started using Opera after giving up on Netscape 4.0 and stuck with Opera 12 until sometime in 2015 when sadly it became pretty obvious that Presto-based Opera was past it's sell-by date and was truly dead. Actually one of the pain points with Opera 12 towards the end was just how bad slashcode starting making the browser choke.

        Not liking Chrome and not particularly excited with Firefox I started looking for alternatives. I initially dismissed the Chromium-based Opera, but after doing some research it se

  • If they could get away with it. They'd make you listen to their "copy" and buy whatever it is they are selling. And they'd have no moral objection to it.

  • Users accidentally tap/click an ad? Sorry to report but some ads hijack the website and auto-redirect to these scam ads. Then I'm stuck with a popup "you've won a free XYZ" and the back-button doesn't work. And the only way out is to close the tab.

    • by hwolfe ( 531 )

      Accidentally? There are sites that do the redirect without having to click on anything.

  • Dang but I love script blockers.
  • YouTube uses a similar technique, when a new video is opened it actually doesn't reload the page despite that the URL changes. The user might want to go back to continue watching the previous video. So how will Chrome know whether this technique is malicious or not? Please tell me if I'm wrong.

"Engineering without management is art." -- Jeff Johnson

Working...