Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I recorded user behaviour on my competitor’s websites

dejanseo.com.au

Post reply on HN
Print view View original

281–290 of 329 posts

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

#281

Post by joshuamorton »

hermitdev wrote: post #274
_bxg1 wrote: post #254

Earlier quoted context omitted.

I believe they did remove the green lock from https sites to avoid implying trustworthiness. And removing the back button API is something Google can't decide on their own; it has to go through the standards process.

> I believe they did remove the green lock from https sites to avoid implying trustworthiness. Nope. I'm on build 68.0.3440.106, the latest public stable build and as I'm writing this comment, little green lock and "Secure" right next to https://news.ycombinator.com .

Its a process. The green lock will be eventually removed, and instead of the "LOCK Secure" you see now, you'll see nothing, and http-only sites will be "Unsecure". This you can already see if you go to a non-https site like neverssl.com. There's a "Not Secure" banner in white.

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

#282

Post by AndrewKemendo »

SquareWheel wrote: post #195
_gok2 wrote: post #188

Earlier quoted context omitted.

Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue. I reported this to google several years ago, and it was never addressed.

>Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue. Sure, I agree. But what does it have to do with the parent comment's claim? I've read much of the discussions involving the early push for HTTPS, and the developers involved were very fastidious.

The point is that google should be penalizing sites that do that in search results, or at least in chrome with some kind of browser recognition - as the OP states in the article.

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

#283

Post by joshuamorton »

chatmasta wrote: post #209

Somewhat related, Google AMP is also destroying the ability for users to trust URLs. In fact it’s kind of the inverse problem; the URL bar says google.com when the user expects to be on another website. I wouldn’t be surprised if observing the AMP pattern subconsciously made users less suspicious of the trick in OP. It’s also a bit rich to see all the outrage here and deranking by google, since hijacking/proxying to…

As far as I know, site owners essentially have to opt-in to AMP by restricting themselves to a subset of not-exactly-standard web design methods (and may need to explicitly opt-in, I forget).

So I don't see a way to call AMP hijacking, since its done with developer permission.

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

#284

Post by AndrewKemendo »

3eto wrote: post #170
dejanseo wrote: post #54

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…

You did good by publishing this. I've seen that you're updating your blog post based on what people are saying here, you don't have to do that, you don't have to answer to people attacking you on a forum. What you have exposed has the potential to affect a large number of Google users and unfortunately the community has chosen to attack you over attacking Google. Which could say a lot about the state of the community…

you don't have to answer to people attacking you on a forum

Maybe you don't feel like you have to, but I can tell you from experience, that when an entire community of your peers piles on to you, there is a significant emotional response that you're being rejected. That's just my personal experience, but it seems pretty common to want to respond when those you respect and work with (or might work with) respond negatively to your work.

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

#285

Post by Ajedi32 »

yashap wrote: post #278
Ajedi32 wrote: post #248

Surprisingly few comments about the actual attack mechanism here. IMO discussion of whether the author's PoC was ethical is interesting but far less important than the question about how to handle the actual vulnerability; this kind of attack could be used for far more damaging things than just recording user behavior. (Such as phishing.) IMO "get rid of the browser history API" (as the article author recommends) isn…

Another possibility - if the referring page is a different domain, overriding back is ineffective (the browser just does a “real” back in these cases).

I don't understand. Are you suggesting that if you arrive at a site from Google, the history API should just not work?

For example, let's say a user arrives at a single-page application from Google, and clicks a link on that page to get more information. The site adds a history entry with pushState, but doesn't reload the entire page. Are you saying that in this case, when the user clicks back they should get sent back to Google instead of to the site's home page? If so, that seems like rather unexpected behavior. And if not, isn't the attack still viable?

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

#287

Post by mrguyorama »

nothrabannosir wrote: post #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 system…

I never noticed this but now that you point it out it's really nifty!

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

#288

Post by cheeze »

chatmasta wrote: post #209

Somewhat related, Google AMP is also destroying the ability for users to trust URLs. In fact it’s kind of the inverse problem; the URL bar says google.com when the user expects to be on another website. I wouldn’t be surprised if observing the AMP pattern subconsciously made users less suspicious of the trick in OP. It’s also a bit rich to see all the outrage here and deranking by google, since hijacking/proxying to…

Wouldn't be a hn thread without someone mentioning how AMP is literally the worst thing ever.

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

#289

Post by samirm »

Ajedi32 wrote: post #248

Surprisingly few comments about the actual attack mechanism here. IMO discussion of whether the author's PoC was ethical is interesting but far less important than the question about how to handle the actual vulnerability; this kind of attack could be used for far more damaging things than just recording user behavior. (Such as phishing.) IMO "get rid of the browser history API" (as the article author recommends) isn…

Changing the UI in case of a different domain is genius, would really help in enforcing the principle of least astonishment. However I don't think the up arrow symbol would work since it already has a meaning in traditional file browsers to indicate going up a directory.

I can suggest a back arrow behind a no way sign instead, but perhaps it should be something totally different.

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

#290

Post by Spivak »

Ajedi32 wrote: post #248

Surprisingly few comments about the actual attack mechanism here. IMO discussion of whether the author's PoC was ethical is interesting but far less important than the question about how to handle the actual vulnerability; this kind of attack could be used for far more damaging things than just recording user behavior. (Such as phishing.) IMO "get rid of the browser history API" (as the article author recommends) isn…

I think getting rid of the history API is really the only way to do this since it lets pages escape the browser chrome. No code from a page should affect the behavior of the chrome elements. It's always ends up being used maliciously.
Post reply on HN