HN Explorer

Ask HN: Google Chrome heuristic warnings pose threat to our business

100 points by Filecloud ↗ HN
Many businesses use our Enterprise File Sharing Product called FileCloud (http://www.tonido.com/filecloud). Think of it as a self-hosted alternative to Dropbox. With the latest Chrome update, the browser is showing phishing warning (http://patch.codelathe.com/foruser/phish_1.jpg) with our installations. The warning is not based on the domain and it appears in our different customer installations. It has to be heuristic based because it generates warning even on a debug/local webpage. The chrome browser heuristically decides our login page as a phishing page and gives the wrong warning. We are trying to find if there are any published "guidelines" as to legitimate web pages should NOT be doing to trigger these? Either there should be clear methods to resolve these warnings or Chrome should avoid doing this blanket-so-called-protection racket. Because of Google’s missteps, our reputation as well as customer reputation got a hit. We have spent countless hours in our resources to see what is going on and all thing points to heuristic decision making by Chrome browser. There is no way to contact Google Chrome team to resolve this issue. We have lost few large deals. Now all our support team is pretty much focused on this issue and fielding queries from our customers. Since our UI code (Developed in GWT) is common between our Enterprise and Consumer product (Tonido), if we this error start appearing in our consumer version (half a million users) it is an EXISTENTIAL RISK to our company that we have built over 5 years. We have 2 questions. 1. How to get in touch with Chrome team and solve the issue? 2. Are there any legal avenues or precedence to force Google to take action and claim compensation for lost business? Please provide us with your suggestions. P.S: It is happening to our software today. It may happen to your products tomorrow.

84 comments

[ 3.6 ms ] story [ 154 ms ] thread
fotcorn
Have you tried to produce a minimal version of the software to show the problem? If not do it now and post it on the Google Chrome Bug tracker: http://code.google.com/p/chromium/issues/list

Other contact forms: Mailing Lists: http://www.chromium.org/developers/discussion-groups IRC Channel: http://dev.chromium.org/developers/irc

gcb0
That failing, get money for them blocking a competitor.

before downvoting, take the time to explain how this would be different from old good Google suing Microsoft just for not making their product use Google easier than it already allowed.

jsun
this is HN, you can't get downvoted:)
emhart
I'm assuming some people are downvoting you to help disprove your point, but to be clear, once you've reached a karma threshold you can downvote.
[deleted]
(comment deleted)
gcb0
YOU can't downvote because you don't have enough "karma"

and i'm getting downvoted alright, and without any attempt at fulling my request, no less

retube
Hmm that sucks. All I can suggest is you systematically remove content from the page until the error stops - this way perhaps you can identify the offending content (or combination of content which aggregates to an "offence")
Filecloud
There is no offending content here. We are not a SaaS company and we dont host content. We provide shrink ware software to other companies which they use to host content.
rallison
The person you are responding to is not talking about user-uploaded content.
hitchhiker999
You may also be interested in this article: https://medium.com/surveillance-state/32ba2b38c219
Filecloud
Yeap. That summarizes our issue.

The next step for us is to hire PR and go public. We are spending 1500$ per month on google adwords now.

May be use that money to get some legal help. In a physical world it is a clear public defamation case.

ccleve
Get a lawyer. Send a demand letter to Google's corporate counsel that they stop falsely identifying your software as dangerous. Fax, FedEx, and email it. If they don't respond in 24 hours, have your lawyer file an emergency injunction in federal court.

Google's failure to respond to issues like this is appalling, and it's probably going to take a lawsuit and public embarrassment to get them to stop being evil.

toddmorey
External dependencies on that page? Anything being pulled from a domain that might have made the list? It might not be specific to your page, it might be on a JS library you are including.
tjohns
This was precisely my thought. If it's happening even on a local staging server, it's highly likely that this is being caused by a third-party dependency somewhere in your site. I'd start by looking at any JS libraries you're loading.
blauwbilgorgel
Report an incorrect phishing warning at http://www.google.com/safebrowsing/report_error/ .

  If you received a phishing warning but believe that this is
  actually a legitimate page, please complete the form below 
  to report the error to Google. Information about your 
  report will be maintained in accordance with Google's 
  privacy policy.
Try posting a thread on the Google forums and decribe the false positive in neutral terms: http://productforums.google.com/forum/#!forum/chrome

Use Google Webmaster Tools for your product site and check for issues: https://www.google.com/webmasters/tools/home?hl=en

Try to come up with a reason why this may not be a false positive. Perhaps you have trademark issues? etc.

More info:

http://blog.chromium.org/2008/11/understanding-phishing-and-... This includes the URL of the website you are visiting, as well as the URL of any included resources (such as included JavaScript or Adobe Flash movies)

https://support.google.com/chrome/answer/99020

https://www.usenix.org/legacy/event/hotbots07/tech/full_pape... [pdf] The Ghost In The Browser. Analysis of Web-based Malware (a paper to make this post interesting to others)

Filecloud
Unfortunately we have done all that. It is not a domain issue or safe browsing issue. The best analogy here is let us say lot of customers run a default drupal or joomla site under their domain and Google chrome show these sites as phishing site.
blauwbilgorgel
Please host the HTML source of a page that throws a warning somewhere. And mention the version of Chrome that gave the warning ( chrome://chrome/ ). Also can you post the thread on the Google forums with a proper bug report? I can't find it.
markshepard
Try http://dev1.codelathe.com

Shows up now with Chrome v27.0.1453.116

cbr
I'm on v28, and I don't see a malware warning on that page.
jcase
Same version, no warning. Edit: Oops, had yet to read that it's now temporarily whitelisted by google.
smtddr
Hey there, I actually worked for a "competitor" of yours at one time in my career. We had a very similar problem, turned out that one of our users shared(probably unknowingly) a file containing malware and probably posted it to their twitter or facebook(we had that feature built-in at the time). This URL was caught by a very popular anti-virus company, which posted it on their site. I guess the software phones-home to get all copies out there in sync. So for awhile, anyone with this anti-virus software would get blocked on our site's homepage for malware and/or phishing attempt. My somewhat-educated guess would be that a costumer of yours has hosted something that Google(or whatever Google uses to get its info) considers shady. Our solution was first to contact the company to get delisted, then I think we ended up changing domains for the sharing stuff. Similar to dropbox's dl.dropbox.com for any sharing stuff. Or maybe we did some kind of URL-shortener. But somehow, a change to the URL's domain of anything that hosted user-generated content was the solution to the problem, AFAIK.
Filecloud
Hi,

Our software is little different. It is a self-hosted software. It is hosted by our customers under different domain names in their infrastructure. So it is not the same domain or URL.

For Example:

Customer 1: fileshare.abcplumbing.com

Customer 2: dataanywhere.peterlawfirm.com

Thats the real problem here. It affects our customer installations under different domains. To some extent, we are fine if google is blocking one domain because somebody in the domain is sharing malware. The issue here is different.

smtddr
Ah, we did have a feature sorta-kinda like that too... if you had your own domain you login on our webUI, enter in your own domain and if no other user had it, you'd get it. Then, you add a CNAME record pointing to us and we'd do certain things when we received the request depending on settings the customer provided during the domain-name setup. I think we used the Referrer in the request-headers. So I could point portal.mypersonaldomain.com -> CNAME -> whateverIchoose.yourcompetitor.com and get a custom page, kinda. If we had a customer use a domain that CNAME pointed to us and had a history of questionable content, I wonder if Google would follow the CNAME direct to see where it's going and incorrectly(or correctly?!) decided bad stuff is happening, thus marking the CNAME target as bad. Just my random'ish guess. Hope you find the issue soon.
Filecloud
We are not a SaaS or PaaS business. The software itself is hosted by the end customer in thier infrastructure.

The warning appears even in local IP/debug page.

smtddr
Oh! Sorry, I missed that part. So even things like http://192.168.1.19/mystuff makes Google Chrome scream? That's crazy. I can't imagine what would cause that. Wish I could help :( ...but looking forward to a blog explaining how this happened later!
grey-area
Have you tried deleting things from your page till you work out what causes the warning? Just start with a static copy of you page, and gradually delete elements till you find the culprit. It shouldn't take long to go through through the elements of the page and work it out if this is some sort of heuristic triggered by some element on your page and not based on the domain.

Another thing it could be is if you fetch any assets at all from your domain, and the domain is blacklisted, that causes the warning regardless of the page where it is hosted.

Filecloud
Yeap. we are doing exactly as you said. Hopefully we can find out.
btilly
Is it possible that you have a security hole, and malware authors have started actively taking advantage of it? If Google recognized that, your page could be a good signature for malware that they haven't detected yet, and you could get automatically blocked because of it.

This is, of course, just a random guess to throw into your brainstorm.

alternize
i'm not seeing the phishing warning when visiting the url from the screenshot using chrome v29.0.1547.0 dev-m.

maybe you caught a malware on your computer. did you try from different machines?

blauwbilgorgel
No warning on 28.0.1500.63 m and 30.0.1552.0 canary either.
Filecloud
We have checked with one of the latest beta builds. In that build it didn't show the warning. It happens with the live chrome version. The issue is much more complex.
coverband
On a Mac with current Chrome (Version 27.0.1453.116) hitting your sample dev URL, I don't get any errors at all...
tteam
This specific instance in the screenshot has been fixed (this is the second time). Basically, in this specific instance if the "Login" button is changed to localize to a specific keyword "Connexion" as part of french translation, it shows up. No other keyword triggers it.. and no way to find out what the heck chrome wants.

It is like playing proverbial whack-a-mole. Every update of chrome can potentially change their "heuristic" that thinks it has "found" a phishing attack.. and we have to scramble to see what the heck caused it and fix it.

This would be funny if it wasn't so detrimental to a business. I will get the dev to recreate this on dev1 and post it.

markshepard
It shows up now on Version 27.0.1453.116
[deleted]
(comment deleted)
pyvek
I opened http://dev1.codelathe.com/ui/core/index.html (URL in your screenshot) in Chrome (latest) but I'm not getting any phishing warning.
driverdan
Same here, latest Chrome 28 beta.
vigneshv_psg
Same here. I'm in Chrome 28 beta.
Filecloud
The issue is much more complex. It appears in the latest live production version. if any of you are part of Google chrome team we can show you.
[deleted]
(comment deleted)
ctz
I opened the same URL and did get a phishing warning. Version 27.0.1453.116 m on Windows 7 x64.
markshepard
It has now been patched to throw the error. It shows up now on Version 27.0.1453.116
mjcohen
No warning with Version 27.0.1453.110
jhgaylor
I just followed that link in Chrome Version 27.0.1453.116 and did encounter a phishing warning.
moepstar
No warning on OS X with Chrome 27.0.1453.116
markshepard
It is because this domain has been added to whitelist which is now overriding it

[5760:1799:0701/150256:VERBOSE2:phishing_classifier_delegate.cc(211)] Phishy verdict = 1 score = 0.548927

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(447)] Feature extraction done (success:1) for URL: http://dev1.codelathe.com/ui/core/index.html. Start sending client phishing request.

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(415)] Received server phishing verdict for URL:http://dev1.codelathe.com/ui/core/index.html is_phishing:0

grey-area
Do you have an example page where this happens, like a demo login page? If so it'd be a good idea to post it as at the moment there's no way for us to see what you see and no way for people to help you work out what is wrong.
mgevans
I just ran into this with some pages in our product as well. If you run Chrome with '--enable-logging --v=2' the chrome_debug.log will contain messages from the phishing classifier (search for 'phishing_classifier'). I was able to tweak the wording on the page to drop the score below 0.5, but there are other features that may be causing your problem.

You may need to restart the browser between edits, as it seems to cache the classifier results by URL. It also skips classification for hosts with private IPs, I had to jump through some hoops to test.

Terretta
For offering a concrete self-help approach among a sea of speculation, and sharing that text on the page changes classification score -- I hope you get upvoted more.
markshepard
Very nice! This will actually be very helpful in tracking this. Thank you.
markshepard
Here is the output snippet. Basically some "algorithm" thinks it has found phishyness with some score above 0.5 and flags it. No clue as to what caused it (We know that it can be triggered by simply changing the name of the "Login" button to "Connexion"!!

Must be nice to dream up some "algorithm" and push it out.. sigh

[5570:1799:0701/133949:VERBOSE1:client_side_detection_host.cc(221)] Instruct renderer to start phishing detection for URL: http://dev1.codelathe.com/ui/core/index.html [5579:1799:0701/133949:VERBOSE2:phishing_classifier_delegate.cc(238)] Not starting classification, no Scorer created. [5579:1799:0701/133950:VERBOSE2:phishing_classifier_delegate.cc(238)] Not starting classification, no Scorer created. [5570:1799:0701/133954:VERBOSE2:client_side_detection_service.cc(255)] Sending phishing model to RenderProcessHost @0x7aa18a00 [5570:1799:0701/133954:VERBOSE2:client_side_detection_service.cc(255)] Sending phishing model to RenderProcessHost @0x8043d620 [5579:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(283)] Starting classification for http://dev1.codelathe.com/ui/core/index.html [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlTld=com = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageImgOtherDomainFreq = 0 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlOtherHostToken=dev1 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=html = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageLinkDomain=tonido.com = 1 [5574:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(275)] Not starting classification, last url from browser is , last finished load is chrome-extension://jpjpnpmbddbjkfaccnmhnkdgjideieim/background.html [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=core = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=password = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasTextInputs = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageExternalLinksFreq = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasPswdInputs = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageSecureLinksFreq = 0 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=connexion = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlDomain=codelathe = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=index = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=account = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasForms = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageNumScriptTags>1 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageNumScriptTags>6 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(211)] Phishy verdict = 1 score = 0.548927 [5570:1799:0701/133954:VERBOSE2:client_side_detection_host.cc(447)] Feature extraction done (success:1) for URL: http://dev1.codelathe.com/ui/core/index.html. Start sending client phishing request. [5570:1799:0701/133954:VERBOSE2:client_side_detection_host.cc(415)] Received server phishing verdict for URL:http://dev1.codelathe.com/ui/core/index.html is_phishing:1 [5570:1...

alternize
most probably "connexion" in relation to "password" was used in an unrelated (english?) phishing attempt.

mixing different languages might be bad. try changing all the page text (and corresponding content-language header) to the localized language instead of just changing the submit button. maybe this have the classifier use the contextual meaning of "connexion".

miomyosky
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?

hiddenfeatures
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?

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

hiddenfeatures
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").

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

markshepard
@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.

mayanksinghal
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.
markshepard
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.

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

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

mayanksinghal
> even bury the whole issue from getting any traction.

Wasn't your site explicitly whitelisted?

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

markshepard
@alternize

That, precisely is the issue. We can only speculate as to what might be good or bad. There is no way to really know is correct (and infact why is it even the business of a browser to determine that). In a lot of situation, it is not something the product gets to decide. For example, this got triggered when a customer added translations to the application (which changes that button).

.

alternize
translation implies "other language". instead of still defining the page as being english, why not trying to define the page's language to the language the customer (allegedly) translated into?

in your case, non-translated "Account" and "Password" texts in a french corpus are most probably much much more common than a wrongly-translated french "Connexion" in an english corpus...

that said, i do not know if chrome is really considering the language or not, but i certainly would hope so. :)

magicalist
According to this[1], the classifier is intentionally obfuscated to prevent reverse engineering, so I don't know how far you're going to get with the log beyond just knowing your score (and the score can change if they change the model, which may explain why some people aren't seeing a problem (I see no phishing warning in Chrome dev channel, for instance)).

Since it looks like it's a model trained offline on known phishing sites, unfortunately I think your best bet is tweaking until you fall under the threshold and (if you're feeling magnanimous) filing a bug on Chrome with an example of how the current model is flawed (though if the page is working in dev channel, something may already have been fixed).

That sucks, sorry :(

[1] https://code.google.com/p/chromium/codesearch#chromium/src/c...

fotcorn
Better format: http://pastebin.com/1NE2Tud8

Can you remove the "core" part of the url? => UrlPathToken=core = 1

You could try another file extensions for the page (don't now if this is possible with gwt). => UrlPathToken=html = 1

The "powered by" link seems also problematic => PageLinkDomain=tonido.com = 1

markshepard
Interesting! I guess most phishing guys have this on their URL and in their page. Therefore it MUST mean that every page with those keys are phishing... just great.

Chrome user$ grep phish chrome_debug.log | grep -e "UrlPath" -e "PageTerm"

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=html = 1

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=core = 1

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=password = 1

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=connexion = 1

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=index = 1

[5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=account = 1

Filecloud
A request to YC mods. It seems like this post is getting flagged. This issue is really a big risk for our startup and we will appreciate if you allow the post to get the visibility it deserves.
markshepard
While I think chrome having strong anti fraud protection built in is nice, the fact that there is no way to understand what constitutes "correct behavior" and no clear way to get clarification is appalling.

It is essentially engineering how things should be developed, which still could be tolerable if there are guidelines.

If an average user sees a red page indicating risk to a page, then that site/page is essentially killed.

daave
I work at Google but not on this product.. so I escalated your issue to the team that works on the anti-phishing classifier. They're looking into it now, and put you on a temporary whitelist in the mean time (should take effect within 30 mins).
miomyosky
It would be nice if the antiphishing filter also gave some good way for web developers to figure out why this happened and what to do to correct this.
packetslave
This is harder to do than you'd think, without also giving the bad guys a cookbook for "here's how to avoid detection"
Filecloud
Thank you so much. Much appreciated. We will be more than happy to provide additional information or even access to the server if needed.
Filecloud
Just one more thing. Since our product is self-hosted by our customers under their own domain, white listing just our development domain is unlikely to help our cause.
ISL
In fact, whitelisting would tend to hurt your debugging efforts.
markshepard
The whitelisting already active for this domain now.

Trace showing server overriding the "Phishyness" verdict of the client

[5760:1799:0701/150256:VERBOSE2:phishing_classifier_delegate.cc(211)] Phishy verdict = 1 score = 0.548927

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(447)] Feature extraction done (success:1) for URL: http://dev1.codelathe.com/ui/core/index.html. Start sending client phishing request.

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(415)] Received server phishing verdict for URL:http://dev1.codelathe.com/ui/core/index.html is_phishing:0

daave
I believe they actually whitelisted/disabled the part of the classifier that is affecting your site(s) more-generally, so it should be working across all domains. That said I know very little about the internals of that system.

I'm sure they will contact you via regular customer support channels (ie. not HN) if they need any more info to debug the problem.

[dead] minm
Wondering. what kind of phishing score Google chrome phishing classifier will allocate for pages with Google Ad words? Any idea?