What's concerning is that the post author seems not to see the problem with trying to sit on both sides of the fence at once. As others have said, the way this was done is likely to be against numerous laws in most major jurisdictions. If you wish to do this as a PoC then simply put a notice up on the page that initiates it and use dummy "competitor" content, so you've got some semblance of user content/transparency…
How I recorded user behaviour on my competitor’s websites
171–180 of 329 posts
Re: How I recorded user behaviour on my competitor’s websites
#172Earlier quoted context omitted.
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.
Re: How I recorded user behaviour on my competitor’s websites
#173Earlier quoted context omitted.
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.
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.
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.
Re: How I recorded user behaviour on my competitor’s websites
#174google.com.fakesite.io/foobar
becomes:
(grey "google.com.")(black "fakesite.com")(grey "/foobar")
This makes it at least a little more obvious you're not on Google.
Although that's still a tricky one for non technical users to protect against. Aside from EV, I can't immediately think of anything else a browser could systematically do to guard against this, to be honest. Blacklists etc, but that's very unsatisfying.
It's a pretty old problem, to be fair. I remember almost being phished this way myself back on Myspace, were it not for Firefox's blacklists catching the form submission.
Domain names being little endian has been one of the most expensive web sec mistakes in history.
Re: How I recorded user behaviour on my competitor’s websites
#175Why do browsers allow changing the back button history before the visitor arrived at the domain? Seems like a subtle cross origin attack if that is truly what's happening.
Most people are just going to hit back until it looks like they're at the right site, so I don't think you'd have to change the previous history, just add your own entry after the one for the site they came from.
Maybe pages that immediately redirect on first arrival should also not count toward back history.
Now a more perfect solution would require browsers snapshot where the user cane from then block or warn about pages at the destination that look too similar. Though that seems unnecessarily complex for most users.
Re: How I recorded user behaviour on my competitor’s websites
#176Hi everyone! I did this. It was just a random cool idea I wanted to try. It worked a little too well and I quickly moved it to a disposable site to test if the page will get penalised by Google. I got busy with other things and forgot about it. When I bumped into it again I decided to write about it, for two reasons: 1) To me it's hard to believe that Chrome would allow for this to happen in the first place and 2) th…
Copying someone elses site and tricking their users to use your copy is a copyright violation and fraud. Nothing cool about it.
Re: How I recorded user behaviour on my competitor’s websites
#177Earlier quoted context omitted.
Your statement is far too broad and lacks context. Where is this a violation and where is it considered fraud? There must be some countries where this isn't the case or at least where the article and non-commercial use of the technique are considered to be mitigating circumstances. Also, who doesn't find it cool? You don't seem to be saying that what is described in the article isn't cool, you seem to be making a bro…
He copied Google's SERP page, AND copied all of his competitors websites. That's definitely copyright infringement, you'd be livid if you were a competitor, and as a user you'd be pretty annoyed. It's still an interesting hack, so good to see it being talked about. But it is not ethical and definitely illegal in almost any jurisdiction.
The USA is a notable exception, perhaps due to the vested interests with deep pockets.
Re: How I recorded user behaviour on my competitor’s websites
#178I’d like to defend this guy. What he is doing is testing the trust mechanism. If he went to Google and said ‘I think the trust mechanism is broken’ Google would say: ‘We know, that’s why we are pushing to move everyone to https.’ ‘That isn’t enough. The padlock on the https page gives users a false sense of security.’ ‘We don’t agree with that. Where’s your data?’ Google wouldn’t have accepted this. They have pushed…
I don't buy it. This same attack would work the same with or without HTTPS having existed, and the only reason it wouldn't work as well in practice is because HTTPS is a baseline of security.
It's like saying that airbags cause people to trust unsafe cars. An HTTP only site is a red flag now, but HTTPS just means it won't be instantly considered untrustworthy.
HTTPS has massive benefits, and Google is already starting to "deprecate" the green padlock (IIRCthey have plans for HTTPS to be "normal" with no green padlock and HTTP to be marked as "unsafe").
Re: How I recorded user behaviour on my competitor’s websites
#179Earlier quoted context omitted.
That's a reasonable course of action until you need to use the internet for pretty much anything .
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 ar…