How I recorded user behaviour on my competitor’s websites • Hacker News Board

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

#261

Post by rapind » Thu, Aug 23, 2018, 2:51 PM UTC

_bxg1 wrote: post #253

dejanseo wrote: post #251

Earlier quoted context omitted.

Google? When I brought a serious issue up in 2012 https://dejanseo.com.au/hijack/ Google never fixed it: In summary, I can take any of your (or anyone else's content) pass more pagerank to it than the original page and then I become the original page. Not only that but all your inbound links now count towards my site and I can see your links in Search Console of my domain. This is something link graph theory refers t…

I can't speak to that particular exploit, but no matter what you always go to the vendor privately first. Period. If they are uncooperative you can then go public. Not before.

I'm not sure how to respond to your comment (for the record I didn't downvote you). The free market point was obvious to me, but I'll elaborate.

When he chose to expose this bug, either he wasn't aware of an alternative (so called responsible private disclosure) or that alternative just wasn't appealing enough. Since we're dealing with a company that generates income (indirectly) through the product, they risk financial consequences from this sort of exposure. It follows that doing more to incentivize and generate awareness of their disclosure policy would reduce their risk which would have a financial impact. It's up to them to decide how much to money / effort / resources to spend on reducing that risk.

My stance is that public shunning doesn't solve the problem of releasing buggy software. I'm actually a Google fanboy, but (to me) they could do better. Instead we get "The site is completely removed from their index without any notification." Maybe we need to elevate browser security to the level of Space Shuttle safety? Obviously that costs more and takes longer, slowing innovation, but IMO the market should determine that.

TLDR; The idea that the individual is responsible for exposing a companies bugs is completely absurd to me. I'll respect you having a different opinion on it.

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

#262

Post by UncleMeat » Thu, Aug 23, 2018, 2:53 PM UTC

dorgo wrote: post #100

snaky wrote: post #82

Earlier quoted context omitted.

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

I think noindex is nice to have but not neccessary for this trick. The only solution is to fix the back-button bug/vulnerability in Chrome.

That's not even a solution.

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.

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

#263

Post by jwilk » Thu, Aug 23, 2018, 3:01 PM UTC

btasovac wrote: post #236

jwilk wrote: post #78

Earlier quoted context omitted.

IME, most parts of GitHub work fine without JS enabled. (Though sometimes I have to disable CSS to get my hands on some forms…) This is unlike major competitors (GitLab, Bitbucket), which are completely broken.

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. [1] - here https://gitlab.com/gitlab-org/gitlab-ce/issues/36754 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues/43436

Ironically, you have to enable JS to see comments for these issues…

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

#264

Post by brlewis » Thu, Aug 23, 2018, 3:03 PM UTC

dejanseo wrote: post #241

S-E-P wrote: post #230

Earlier quoted context omitted.

For what it's worth, I love reading about this stuff, though I specialize in InfoSec so this sort of thing is actually pretty common in our communities. You would have definitely had a much easier time with them than you are right now. But for what it's worth, this will blow over soon enough, the internet does not have the greatest memory (unless you actually did something horrendous, which you didn't)

I hope so, and I also hope Chrome gets a fix for this.

I read the article, but still don't get what's Chrome-specific about this vulnerability, or what a good fix would look like.

My reply to someone who proposed making the back button always go to the previous URL: https://news.ycombinator.com/item?id=17826406

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

#265

Post by detaro » Thu, Aug 23, 2018, 3:03 PM UTC

jwilk wrote: post #263

btasovac wrote: post #236

Earlier quoted context omitted.

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. [1] - here https://gitlab.com/gitlab-org/gitlab-ce/issues/36754 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues/43436

Ironically, you have to enable JS to see comments for these issues…

Not really ironic, it tells you what the answer in those comments was

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

#266

Post by graeme » Thu, Aug 23, 2018, 3:09 PM UTC

baddox wrote: post #108

graeme wrote: post #33

Earlier quoted context omitted.

This is somewhat risky, no? It's a clear case of copyright theft, and would be trivial to sue unless they hit everything behind cutouts to the extent they weren't traceable. One would think the owner of the cloned site would notice lower traffic, search, and notice the ad scam. This strategy sounds like it would take months to execute before the competing site died, if not longer. Am I missing something? I've read lo…

It’s never trivial to sue.

No, but in a case with a clear paper trail it wouldn't be hard to send a very clearly worded cease and desist showing exactly what damages are expected and how easy it is to prove.

Depending on the size of the company would also be possible to raise a big PR fuss, get on top of Hacker News, etc.

Plus there is DMCA takedown, google's tools, etc. Those are trivial to use.

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

#267

Post by rellui » Thu, Aug 23, 2018, 3:15 PM UTC

wiether wrote: post #73

aquarin wrote: post #10

It seems my habbit to open google links in new tabs with right click have more meaning now. I initialy used this to avoid referal information.

Doesn't change the referer but avoid you falling in that current trap. Anyway, using a new tab for each new website you visit is the way to go I think.

Maybe it's a good trade off for this to become default behavior in browsers (in the background unseen by users).

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

#268

Post by C4stor » Thu, Aug 23, 2018, 3:18 PM UTC

_bxg1 wrote: post #252

dejanseo wrote: post #244

Earlier quoted context omitted.

Trying to be objective and understand my own motivations here. Obviously I didn't do anything out of malice. But yes, I could have told Google directly about the problem, but then I'd have no cool story to publish on my blog. At the end of the day, that's what it boils down to. Now that I got too much attention from it, I regret all of it.

"I could have told Google directly about the problem, but then I'd have no cool story to publish on my blog" First of all, you definitely would. Standard practice is 1) report the bug privately, 2) wait for a fix, 3) get the go-ahead to publish your report and take credit publicly. That's how it always works; that's how security researchers build their reputations and careers. I guess you just weren't aware of that.…

I fail to see how dejanseo put the people at risk. Exposing how a tool is dangerous and poorly conceived isn't the same as conceiving a dangerous tool.

In this case, Google put millions of people at risk, and dejanseo actually contributed saving them.

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

#269

Post by cryptonector » Thu, Aug 23, 2018, 3:21 PM UTC

dejanseo wrote: post #182

GedByrne wrote: post #159

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…

Thank you. I'm not having a good time at the moment. Anyway, the basis of my test hypothesis is that people are easily fooled by URL both by HTTPS and brand recognition (e.g. subdomain) so I conducted a survey which revealed the very real problem: https://dejanseo.com.au/trust/ Raw data: https://dejanseo.com.au/wp-content/uploads/2017/04/survey-te...

Did we not have enough evidence already that this is true??!

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

#270

Post by deckar01 » Thu, Aug 23, 2018, 3:36 PM UTC

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…

As a person who has wasted a lot of time trying to convince Google that a vulnerability is worth fixing, I have no sympathy for them finding out about a vulnerability via a public disclosure like this. They probably would have spent weeks/months failing to understand the implications of the vulnerability only to have the report closed with an auto generated response about phishing not being considered a vulnerability. Keep thinking like an attacker and sharing your findings. It is the best way we can make software more secure.