Live data from Hacker News

How I recorded user behaviour on my competitor’s websites

dejanseo.com.au

171–180 of 329 posts

Re: How I recorded user behaviour on my competitor’s websites

#171

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…

Not sure what you read, i read about a guy who was aware of it and handled it good enough.

Re: How I recorded user behaviour on my competitor’s websites

#172
post #115
post #85

Earlier 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.

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.

Re: How I recorded user behaviour on my competitor’s websites

#173
post #130

Earlier 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.

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.

Re: How I recorded user behaviour on my competitor’s websites

#174
For context: Firefox greys out anything that is not the "real" domain, which remains black. So:

google.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

#175
post #168

Why 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.

That would require storing where they came from as well as waiting for--or forcing--them to visit at least one more page on the attacker's site. So it'd still make backjacking harder.

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

#176
post #58

Hi 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.

I guess you don't put locks on your home because you have a 'dont come in' sign on the door right?

Re: How I recorded user behaviour on my competitor’s websites

#177

Earlier 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.

Copyright infringement is a civil case in almost any jurisdiction, not a criminal case.

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

#178

I’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…

So you are implying that HTTPS made this attack easier or more impactful?

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

#179

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

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.
Post reply on HN