3 ms·

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

by yaseer 6y ago

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.

mr_toad 6y ago
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.
- yaseer 6y ago
  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.
  - eyelidlessness 6y ago
    > 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.
    - yaseer 6y ago
      > 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.
      - spiralx 6y ago
        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.
mokus 6y ago
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.

by yaseer 6y ago

mr_toad 6y ago

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.

yaseer 6y ago
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.
- eyelidlessness 6y ago
  > 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.
  - yaseer 6y ago
    > 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.
    - spiralx 6y ago
      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.

mokus 6y ago

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.