Hacker News Reader

Comment by yaseer | Hacker News Reader

We have been in this position ourselves - I really do empathise and live with the same fear.

The removal process ought not be automated, unless it's a serious violation that can be detected algorithmically with high confidence.

The algorithms detecting violations are clearly buggy as hell. Our take down also made little sense, and we had to resort to support, which is itself a nightmare. There are numerous similar stories a Google search away.

Extensions are growing to be a fundamental part of the browsing experience- Google ought to invest more into improving the ecosystem.

Scaling the human review process should protect both users and developers.

View on HN

As an extension user I feel that false positives are far less damaging than false negatives. I’d rather go without an extension than take the risk of something stealing my passwords.

I agree.

It appears the algorithms are crude by Google's standards.

If I were a determined malicious actor, bypassing a crude algorithm seems like a low bar to clear.

In contrast, if I knew a human were reviewing things, and if perhaps submitting extensions required the same business verification process iOS development does... the bar for a malicious actor is a lot higher.

> It appears the algorithms are crude by Google's standards.

I’m not Google but I’m not sure if I agree here (though I agree with you and the parent comment generally). It’s extremely uncommon, lodash notwithstanding, for JS code to have a dense set of regex partials full of Unicode escapes, even with modern build tools. It’s a lot more common for malicious scripts.

Determining which is which would require a level of static analysis of dynamic code that, if Google had it, they’d be showing it off in hot new build tools. They’re just making the somewhat reasonable assumption that it smells bad, and overreacting.

And if they were to whitelist known popular libraries there’d be an uproar about playing favorites and excluding some extension which uses, idk, xregexp, to improve accessibility.

> It’s extremely uncommon, lodash notwithstanding, for JS code to have a dense set of regex partials full of Unicode escapes, even with modern build tools. It’s a lot more common for malicious scripts.

A very good point, I hadn't looked at it that way. It makes me wonder why lodash would need this kind of construct.

My guess is string case conversion functions, of which Lodash has quite a few, and parsing the micro-templates it has built-in. The case conversion regexes are likely defined in one place.

The entire model many large web companies use of automating moderation and support to extreme degrees is, I feel, fundamentally wrong. I wonder what the ratios of customers to support staff look like for all these multi-billion user platform companies.

Reply on news.ycombinator.com