This is an interesting yet disturbing case of blackhat SEO and phishing, where the site owner hijacks the back button and sends visitors to fake sites where he can observe their behaviour.
FTA:
Here’s what I did:
1. User lands on my page (referrer: google)
2. When they hit “back” button in Chrome, JS sends them to my copy of SERP
3. Click on any competitor takes them to my mirror of competitor’s site (noindex)
4. Now I generate heatmaps, scrollmaps, records screen interactions and typing.
I'm curious how many visitors did this. In my very limited sample set of myself and friends / work colleagues, we all use middle click to open a result in a new tab.
The vast majority of regular users I've seen go back and forth between search and search results. Heck, I do it from time to time. Most users are extremely "inefficient" by geek standards.
Interesting. Thanks for that. Sometimes we can get so caught up in our own tech-bubble that we don't really notice the usage patterns of the average user. So it's often nice to have a reminder like this.
> Most users are extremely "inefficient" by geek standards.
How is that inefficient? I use both interchangeably and I don't see how it's any less efficient than opening a new tab and then having to close it if it's not what you want, or having to close useless tabs if the first one is all you need... On my Macbook, I just swipe right and I'm back at the search results.
The Internet works just fine without JavaScript: DNS, FTP, SSH, SMTP, NNTP — none of them have ever required JavaScript. Indeed, HTTP works just fine without JavaScript. HTTP pages perform better without it.
Granted, many broken and ill-programmed HTTP pages aren't useful without JavaScript. That's no an indication of how useful it is, but rather an indication of how poorly-skilled those webmasters are.
Then there are web apps; they indeed don't work properly without JavaScript. Fortunately, there just aren't that many important web apps. To be honest, I can't think of one web app that I regularly use, other than Google Meet.
Your distinction between web pages and web apps is entirely arbitrary. Many web pages use JS in such a way that interacting with them without JS is a lesser, if not broken, experience.
Yeah I know, personally I prefer to use paper, way safer. I plan to just do the full TCP request by hand using the ethernet wire, morse-code-like, next./s
Sure increasing the functionalities increase the risk, it doesn't means the risk isn't worth it or isn't mitigable. Worst case, he fake your back button.. it's not that bad seriously. Google will probably try back buttons and different similar situation now on their engine and deal with theses cases one by one.
>Most of the modern web is unusable with javascript disabled
This isn't wrong - but it assumes most of the modern web is worth using. Most of the modern web isn't worth browsing, and every site I've ever come across that is worth reading works just fine without Javascript. I'll continue to browse the internet with Javascript disabled-by-default. It's a surprisingly good filter.
With that being said - while this is "another reason" it is as minor of a reason as it gets...
But it is, are you really going to ignore reading some huge breakthrough in physics because the site uses react? Also in many situations there's absolutely no other choice. Government sites, e-stores, banking.
And then there's the buildup of recorded urls. Private browsing is somewhat less useful when your scipt blocker whitelist is full of porn sites.
I use it for security in specific browsers but happily admit it's not an actual solution for normal people. Adding another 3 clicks, then another 2 for the inline JavaScript contained within after reload makes the internet incredibly annoying to use.
>dding another 3 clicks, then another 2 for the inline JavaScript contained within after reload makes the internet incredibly annoying to use.
Yes, it is annoying. It reminds me each time how annoying websites are which use Javascript for things which could be done without. And it lets me search for alternatives or just abandon such websites.
> how annoying websites are which use Javascript for things which could be done without
A good example of sites which use JavaScript for things they don’t really need are those GP mentions: ‘government sites, e-stores, banking.’
Government sites: the vast majority of government sites are simply informative text. There’s absolutely no need for me to grant the government permission execute code on my computer (which is what JavaScript does) in order to read the minutes of the latest council meeting. Even when interactivity is needed (e.g. an online tax-payment system), HTML forms (the sort we’ve had for over two decades) are a perfectly good solution for ‘enter information in a box and submit it.’ JavaScript can definitely lead to more attractive, more usable solutions — but it’s completely optional. Government sites are a great example of something which should work for anyone, even someone using an old BeOS box on the other end of a modem connexion running over a bit of wet string.
E-stores: there’s simply no need for JavaScript to display pictures & descriptive text of goods in an attractive fashion. There’s simply no need for JavaScript to give me a form to enter my credit card information & mailing address. Again, JavaScript can make the experience better, but it is also a privacy and security risk. I seem to recall that Amazon made quite a lot of money before JavaScript was a thing; I imagine it could continue to do so.
Banking: there’s no need for my bank to execute code on my computer to send me a statement of my accounts, nor to give me a form to pay bills or send money. Indeed, in my experience JavaScript just makes things worse, because instead of downloading a single HTML document from my bank’s servers I get to download dozens of trackers and bugs, as well as the code necessary to hit multiple APIs and stitch the page together out of its parts on my own desktop.
I think I read something yesterday, here or elsewhere, about how client-side JavaScript really took off at the same time as server-side Ruby was a big thing, with the implication that the reason was that Ruby was so slow that websites had to offload as much computation as possible. I don’t know, now, if that was actually the case, but I do know that it’s 2018 and my desktop experience is slower than it was in 1998, thanks to JavaScript.
The thing that concerns me is it's easy to wrap a JS API or unreference it if I know it's abused for ads/tracking. I don't know of good ways to go about tracking based on pointer events or scrolling.
I'd put more research into generating fake events or limiting them for an untrusted site, so mouse behavior can't be used for "where are they looking" analysis.
Hello everyone, GitLabber here! We had a similar issue about this [1], and we raised another one when deciding to further clarify our documentation regarding this question [2]. You can find out more about our motives behind this decision there.
Completely disabling Javascript isn't feasible, but you can use uMatrix or NoScript with all scripts blocked by default, and only whitelist ones on sites/domains that you trust.
Exactly. I've been browsing script-free for twenty years. It used to be a real pain switching on and off, until Opera introduced easy by-site settings. But then, back in the day most sites were perfectly servicable without any scripting whatsoever. And these days, uMatrix makes it all a snap.
> A good website give you the ability to move without this button.
I disagree, fairly strongly. Re-implementing behavior that the user already has in their client is at best superfluous, and at worst very confusing.
> It's like Android VS iOS. The first one has a back button, the other don't.
iOS apps implement history as part of their UI because iOS doesn't have provision for one in the default UI. This is changing, as gestures become more and more common. I don't think I've actually used a "back button" on my iPhone in months. I pretty much take its presence as communicating that it's possible to go back, not as a means to do so.
So, the browser extension indicating (with big red fonts) that this site is noindex could be a simplest solution?
For not power users who don't know about any extensions that would be not so easy though. If that function will appear in Chrome enabled by default, that would raise questions about Google motives, obviously.
Maybe restrict the history API to the same-origin-policy? Javascript could/should be allowed to manipulate browser-history only for the same domain. Just an idea.
That’s already the case! The history API only supports the current origin. From MDN:
> The new URL does not need to be absolute; if it's relative, it's resolved relative to the current URL. The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception. This parameter is optional; if it isn't specified, it's set to the document's current URL.
The exploit in this article clones the appearance of Google results and competitor websites but leaves the user on the exploiter’s domain, so users who are savvy enough to notice the URL wouldn’t be fooled.
Why should anything be able to change the behaviour of the back button? If I click back it should take me back to the previous URL. If it breaks your one page 200MB JavaScript masterpiece then tough luck, come up with your own navigation.
Suppose we did what you said, and the back button only ever took you back to the previous URL.
I could still make a JS app that, on your first interaction with the page, moved you forward from https://example.com/ to https://example.com/#home. Then it sets a variable such that when you go back to https://example.com/ it shows a fake SERP. This is not an easy problem to solve.
This exploit uses the history API, which allows JavaScript to change the URL in the browser URL bar to another URL with the same origin without actually causing a new full page request. The same-origin policy has always been in place, because it would obviously be a huge vulnerability to allow any web page to pretend to be a different website.
Changing window.location is different: it allows you to change the browser URL bar to any URL (including google.com, etc.), but it actually causes the browser to do a normal page load of the new URL, just like if the user had clicked a link to the new URL. Thus there is no spoofing vulnerability exposed by the window.location feature.
User clicks on your site. You redirect to a fake search page and then redirect to your page after setting a cookie. Now back button sends them to the fake search results.
Independent of anything else, allowing the back button to take you back to a page that redirected you previously is bad UI. It is almost never the desired behavior.
? Sure, you can just call the URL directly in browser. Which other way do you mean?
The problem is not to end up at "noindex site" (btw: noindex is not a neccessary part of this scheme). The problem is to end up at "noindex site" thinking that the "noindex site" is a competitor site. And I don't see how such deception is possible without the backbutton-bug.
> The problem is to end up at "noindex site" thinking that the "noindex site" is a competitor site
And there is no solution for that, it seems. The solution for the problem <red in address line>'hey, that's noindex site!'</red> is obvious and simple.
> And I don't see how such deception is possible without the backbutton-bug
You told it yourself - 'you can just call the URL directly in browser'. And there are many ways and scenarios how that clicking on a link could happen.
FTA:
Here’s what I did:
1. User lands on my page (referrer: google)
2. When they hit “back” button in Chrome, JS sends them to my copy of SERP
3. Click on any competitor takes them to my mirror of competitor’s site (noindex)
4. Now I generate heatmaps, scrollmaps, records screen interactions and typing.