"Starting today, Chrome Web Store will no longer allow extensions with obfuscated code...Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed"
I have a Chrome extension that uses Webpack to convert TypeScript to JavaScript which then uses UglifyJS to minify it. If I submit only the minified code, is this compliant?
On Firefox the reviewer took my source code, inc package.json, and ran it through the exact same version of my dependencies and then did a checksum of the output against what I submitted. The reviewer also read my source code and reviewed all dependencies.
It was a pain to get through but doing good things for your users takes effort.
Is it correct that Firefox makes your extension live in a short time after you upload it as long as you pass some automated checks? But it can get taken down if it fails the review performed by a human later?
Yes, they're not banning minified code, only obfuscated code. Read a bit further:
> Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed
It's not clear to me where the line between obfuscation and minification is here. Minification is a form of obfuscation. Transpilation and minification also make code significantly harder to review compared to the original code so I'm not following the rational behind this.
Minification is typically referred to "the minimum amount of code changes needed to make code as small as possible".
Obfuscation is more like the maximum amount of code changes possible while keeping semantics.
Writing an unminifier is pretty feasible and the only real trouble with reading the resulting code is the meaningless variable names. Writing a deobfuscator is intentionally hard.
Why "minimum amount of code changes"? I would have thought the goal of minification would be to make the code as small as possible even if it requires a lot of changes.
> Writing an unminifier is pretty feasible and the only real trouble with reading the resulting code is the meaningless variable names.
Reviewing code with meaningless variable names is still several orders of magnitude harder than reviewing the original code though. I agree code though an obfuscater is another step up however.
A minifier will not make changes that are not required. In fact a lot of the more obscure changes can still be easily detected by code and reversed. Eg most minifiers will turn
if(hello) {
alert("hi");
}
into
hello&&alert("hi");
That seems cryptic to the untrained reader. But you can probably imagine writing an unminifier that can detect that the result of that expression is not assigned to anything and that the && is only used for lazy evaluation. This means that you could restore the original "if". Now note that the only reason you can do this is because minifiers follow this same pattern all the time. Every if with a small body is minified in this same way. Unminifiers know the patterns that minifiers use and reverse them where possible. It's pretty fun to do actually.
An obfuscator, on the other side, will try to vary the patterns by which code is changed as much as possible, and as randomly as possible. Depending on a random seed, the same if might be turned into
var b=52,w="toString",h=History;
(((hello==(b-51))||(!b))&&(()=>alert(h[w].call(h).substr(9,2)))())
This is a lot harder to turn back into that if, and essentially impossible for reviewers to follow. A good static analysis tool could probably do some flow analysis and derive that hello is checked for truthiness, the !b check is superfluous and the function expression is immediately invoked, and still restore that if. But real decent obfuscators can do similar static analysis and have access to much more data, by definition (especially if the input code is typed). Eg it would use existing variables in scope that it knows are truthy/falsy/etc and needlessly add them to checks (maybe even bring them into scope from elsewhere). The more code you have, the better you can obfuscate it. Writing a good obfuscator is hard (writing a shitty one is peanuts and a lot of fun), but writing a useful deobfuscator that can handle non-shitty obfuscators is nearly impossible.
> Reviewing code with meaningless variable names is still several orders of magnitude harder than reviewing the original code though.
Automated checking tools don't really care about human-friendly user functions' names. They will however check for calls to dangerous APIs (eg: XMLHttpRequest(url), eval(stuff) ) and some dangerous patterns (eg: background actions unprompted by the user ).
>Why "minimum amount of code changes"? I would have thought the goal of minification would be to make the code as small as possible even if it requires a lot of changes.
You're agreeing. Minification makes things as small as possible. No one said otherwise. The "minimum amount of code changes" could very well be "a lot of changes".
The difference is whether your goal is to make the code impossible to reverse engineer, or if you're just trying to reduce the size or improve the performance of the final deliverable.
The blog post explicitly calls out all of the following techniques as acceptable, for example:
> * Removal of whitespace, newlines, code comments, and block delimiters
I read the post but seeing as the penalty for not following the guidelines is your extension being removed from the store and not all minifiers work the same way I thought some clarification would help.
I have a Chrome extension that uses Webpack to convert TypeScript to JavaScript which then uses UglifyJS to minify it. If I submit only the minified code, is this compliant?