Comment by miomyosky | Hacker News Reader

Comment by miomyosky | Hacker News Reader

Parent Full thread

Thanks for the really useful tip to look into Chrome's debug log.

First of all we see that this so called phishing detection filter's code is found at http://src.chromium.org/svn/trunk/src/chrome/renderer/safe_b...

Second, this code and the logic it employs is really bull.

The world wide web is not a kiddie playground especially for a browser, and especially for a plugin whose's job is to detect phishing. The way Chrome's anti-phishing works is to use several foolish measures that mean nothing in the real world and then 'punish' and push websites into oblivion when someone crosses these arbitrary sets of rules.

The way the plugin appears to work is to look at various things * The type of URL (IP vs domainname, number of subdomains, size of the subdomain names, the strings in the Path URL) * Whether the page contains form data * Whether the page contains password input box * Whether the page contains checkboxes/radio boxes * Whether the page text contains some terms (in this case 'connexion') * Whether page has links/images to other domains

and so on.

None of these are ANY indication of phishing behavior and if this set of quackery based logic is what we see from Google Chrome, where else can we go to really feel safe and protected?

As much as I can understand you being upset that Chrome shows a warning for your site, I don't think that the approach they are using is unreasonable.

I'd take bets that those criteria show a correlation to phishy sites. Especially if you combine those metrics together.

Is it perfect? No. Does it produce false positives? Yes. Is it beneficial on average? I think so.

PS: Since you have found the relevant file in the open source project (or 'kiddie playground' - as you like to call it), why don't you supply a superior implementation with less "foolish" measures?

You are trivializing the underlying issue here. If the same thing happened in a physical world it will be a high profile public defamation case.

Browser is the window through people sees the world. That’s the reality we live in. In our target market, Google chrome holds 40% market share. Because of its stupid categorization, in one stroke Google harmed our reputation and the reputation of companies we serve. It is not a simple browser compatibility issue. Google chrome is telling the world our software is phishing software while we are not. What is the recourse here?

We don’t care what Chrome’s algorithms are. But the results are not factual and it harms our business. "One cannot escape saying hey that is our algorithm. We don’t do evil…" Remember.

Believe me, I am empathetic to the pain this is causing you. I can understand the anger you are feeling.

But I don't think that I am trivializing things. The fact is, that phishing sites are causing a real pain (as in millions of dollars lost by the victims, hundreds of thousands of computers becoming zombies, etc). All major browsers are trying to mitigate these risks by implementing phishing & malware filters. None of these implementations are perfect (you probably know a bit or two about bugs in software development).

But on average these filters have a positive ROI - especially for the target market (which is Joe WebUser and sadly NOT your company - or mine for that matter). The costs of a false positive ("I'll go & find that information on another site") far outweigh the costs of a false negative ("I put my login+password into this legitimate looking website and now I can no longer access PayPal").

My point is that with an browser (similar to an OS), they cannot take things lightly and flag things left and right based on "heuristics". With great power comes great responsibility.

My point is that if you are going to design a system to identify bad websites it better be fail safe otherwise it is going to cause a lot of hurt.

The message shown in the browser for a phishing warning is the same as when a website has an invalid SSL certificate. The first is vaguely accurate, the latter is 100% accurate and no one is going to argue if the warning is needed. Both show the mind chilling warning no sane user will click through.

I am more interested in removing the phishing filter than in writing a phishing filter.

Anyways, with a 'closed' server component also in the mix, what option is there to provide any implementation.

IMHO, I think that doing things for the 'benefit of most' will lead to eroded freedoms for all over time.

PS: 'Supply a better implementation' is not an answer to writing poor code and hoisting on the world.

@hiddenfeatures

Yes. Lets apply this everywhere. Lets electrocute folks based on "heuristics" because there are no other way to find out "bad guys".

It is nice to act as an arbiter and spout philosophy isn't it?

If you really do think that there is no other better way then I guess there is no more point arguing about this.

Or let everything go through until and unless we are 100% certain that it shouldn't. Like, if someone is pointing a gun at you, do not duck because there is a chance he/she will miss. Because you know, exaggeration is truly a great tactic to convince other stakeholders.

Even though this looks like a troll attempt, lets try this.

The problem is 1. No clarity on what constitutes a problem. 2. No way to officially contact to clear up a problem

resulting in possible irreparable loss of business.

So, if you insist on interesting and orthogonal "analogies".. please carry on.

I was NOT trolling. I was pointing out that (A) Exaggeration is not a great debating tactic, in your case it was a clear slippery slope argument (B) It will not help in convincing the other stakeholders into being empathetic with your situation because you equated them to mindless psychopaths.

> So, if you insist on interesting and orthogonal "analogies".. please carry on. If it was not clear, I was trying to describe a possible issue with you "lets apply this everywhere" argument.

The two arguments you just put forward, are nowhere close to what you said in the comment I replied to. Yes, there are issues with the current implementation of it, which is very similar to how spam detection/prevention systems work at the moment. Yes, there can be improvements to it. There can be improvements to everything. Yes there is high chance of false negatives in the current system, but this is a problem where false positives can be just as disastrous. If we cannot agree with that, then do not think it is worth continuing this discussion.

Now if you check the top comment on the thread, I believe the communication channels have already been set. They did not work for you as promptly as you would want them to, that's a different issue. But there definitely exists an official contact to clear up the problem - your colleague seems to be aware of it. The lack of clarity of the reasons has been marked as intentional and has been discussed elsewhere on the thread.

It was poor of me to use snark instead of clearly stating my stance, but the stupidity of analogy that you are blaming me for, is not much different from what I was trying to mock.

I agree (and have posted in this very thread) that having controls for detecting spam/fraud is good. Also, I have posted that the primary problem is, no way to either a) avoid this problem by adhering to some guidelines b) no way to directly contact the developer to figure out the problem to resolve it.

Every update to the browser can potentially change the model that affects a large number of the users and the only way to figure out the problem is using some sort of trial and error method.

This would have been fine if the product in question is a niche product or a exotic browser. But the fact of the matter is, with Chrome (being one of the dominant browser) and Google being the product owner, the reach of Google's opinion is far reaching and can easily destroy a product (akin to killing a person based on some assumption).

Also note that, the "communication channels" listed earlier were completely useless for this type of problem where the client side is throwing the error (Not related to a specific domain or even url included in the page).

Understand that, being a commercial product, ALL possible methods were tried (obviously) to resolve it by using those methods and could not resolve it. You can see that, this specific instance gets triggered by simply having a button with the name "Connexion" instead of "Login" (purely detected by backtracking the changes).

So the frustration is not meant to belittle Google's effort at combating spam/fraud but to point out the effect of such wide ranging blanket solutions.

While "Collateral damage" is a very nice way to de-sanitize and make things palatable for all parties involved except those getting to be the "Collateral damage".

At the end of the day, I am sure folks understand that Google being Google can do what they want and probably even bury the whole issue from getting any traction.

> even bury the whole issue from getting any traction.

Wasn't your site explicitly whitelisted?

Yes. I believe it has been added to a temp whitelist. But it is not clear if is domain based or somekind of signature based. If it is domain based, then whitelisting is not useful (This is hosted on various domains as noted by others). If it is signature based, it will be more effective (though the signature will change as the server code changes and since there is no idea what gets into the signature, there is no way to avoid).

Also, dev1.codelathe.com was re-setup specifically to trigger the warning (It was determined that if the login button has the keyword "Connexion", it was pushing the phishing score past 0.5)

The main thing is, if there is a clear way to contact the team responsible for this to resolve such issues, that will be the best way for anyone with similar problem and at this point there is no such avenue.

Reply on news.ycombinator.com