Hacker News new | ask | show | jobs
by markshepard 4739 days ago
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.

1 comments

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