4 ms·
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 t
by 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 agoMy 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.