Extension rejected for code obfuscation

[Vitali K]

Hello,

I wrote a message to support in response to a message received about the rejected extension. But I'm not sure if my message will be read. 

I submitted the extension for moderation the first time. It was rejected because several Javascript files were obfuscated. I agreed with that and wrote an explanation message. I accepted it because it really was. I fixed the extension and sent it back for review. And I got the same message again that I was using code obfuscation. But I'm not using it anymore. 

If I'm not mistaken, I've read before about cases when moderators received previous version of the extension for moderation rather than a new one. Perhaps this is my case because in the last submitted version I did not use obfuscation at all.

Can someone help me solve this issue?

The extension id is ebbilkbochjjalheallpnblfdhkfjjmp

Regards,

Vitali

[Vitali K]

I just don't have any ideas anymore.

I've sent the extension to check three times. After the first time, I received a message that my code was obfuscated. I agree with that and so I corrected the code. I just stopped using obfuscation.

I used it in the following form 

myFunctioName1 => iiiiiii

myFunctioName2 => iliiiii

myFunctioName3 => iiliiii

After the second and third rejections, I sent two messages asking to indicate what the moderator didn't like.

Today I received a message with the same reason for rejection. But the answer in bold indicates "must not obfuscate code". And they wrote that minification is possible, but not obfuscation.

But guys, I stopped using obfuscation right after the first message about it. I use three third-party library files. For example, JQuery. But these files are not obfuscated. They are minified. 

I believe that the moderator is mistaken in his decision. But how can I prove something, if I have the simplest code and I don’t get a message in which file the moderator saw obfuscation? It'd be great if I was given a piece of code with obfuscation.

I would be happy to provide any further details if needed.

Regards,

Vitali

[Vitali K]

I explained in each Javascript file why the moderator is wrong and asked to indicate what exactly is not clear or what exactly they do not like. Again, I received only a vague answer. The answer states that minification is allowed. Interestingly, it is this kind of minification that used libraries use. 

Even jQuery site (https://jquery.com/download/) states that their code is only compressed. This is consistent with minification requirements here https://developers.google.com/speed/docs/insights/MinifyResources. There are examples and the library code is fully consistent with these examples. 

It’s just amazing how moderators can remove the extension and not give reasons. This is some kind of self-government and permissiveness. Is it allowed to do so?

I already have suspicions. Why did I receive a message on June 1 asking me to change something in the extension? Why wasn't the reason indicated at all? My extension is just one of the 180,000 others. Why did I receive this message? I have 4 to 5 thousand extension installations. Is the extension very noticeable? Not. Then why?

[Vitali K]

The last few versions that I submitted were rejected. I wrote more than five messages to support through various forms for communication. It seems there were seven of them. When rejecting an extension, I got a vague response twice without any clear reason for rejecting. At the same time, each time I submitted the extension for moderation, I wrote more and more detailed comments in Javascript files why the moderator is wrong. There I asked to indicate exactly where the moderator finds obfuscation. I did not receive answers to my questions. The moderator rejected the extension each time.

But today, about two hours ago, I received a message stating that my extension was checked again. At this point, the latest version of the extension has already been rejected. Nevertheless, I received a message that the decision on my extension has been reviewed and it will be published in 30 minutes. At the moment, the extension has already been published.
Since this happened, I have to write about it. The issue was resolved positively for me.
I asked about the reason for rejecting those versions that have now been approved. So far I have not received a response. I understand that too little time has passed and my question might not even have been read. Maybe I'll get the response later.

I would like to believe that this all is due to an internal error when the moderator receives an old version for verification instead of a new one. But I cannot say this with accuracy. This is just my guess.

Regards,

Vitali

[Aleksey]

Hi

I'd suggest replacing jquery with uncompressed version (from https://code.jquery.com/jquery/)

At least I had no issues with original uncompressed versions. Won't hurt

Also, I experienced rejection because I used atob function. It's a kinda marker of obfuscation for CWS automatic control.

Aleksey

[Vitali K]

Hi Aleksey,

Thank you for your advice. I don't use atob in my code. I will check if atob is used in libraries code.

Yeah, I guess I'll use uncompressed version of jQuery in the future versions of the extension. I don't see an issue with the compressed version. This code is not obfuscated. Nevertheless, I will follow your advice. Thank you.

Vitali

[Alexander Shutau]

There is a reason to reject obfuscated libraries (of course telling a proper reason). I analyzed several malicious copies of my extension, and I would say it is very easy to hide a malware and trick reviewers. See more info here https://darkreader.org/blog/attention/

[Simeon Vincent]

Hey Vitali,

For a little context, the team that handles replies to rejection emails can't go into much detail about the reason for rejection. We're working to change that, but it's an unfortunate reality of our current team structure. As such, you most likely won't get direct answers to the questions you've posed in your emails. Luckily, though, I'm a bit more flexible in what I can share.

I dug into the most recent rejection and found the offending bit of code that was considered obfuscation. At the moment your URL handing is a bit unconventional; you declare dsub, dhost, and dtld at the top of your popup.js script, then proceed to re-combine them in your fp function by assigning them to a variable called dn (which is unused). While I wouldn't consider this obfuscation, I can see the reviewer's point of view here; there's little reason to do this than making it harder for someone reading the source to understand the logic. That said, this feels overzealous to me and if you were still being rejected I'd open an issue with the review team to reassess this verdict. 

You don't need to use the uncompressed version of jQuery. Minification is allowed and popular libraries like jQuery should be easy to verify as safe. Let me know if you have any other questions and I'll do my best to follow up.

Cheers,

Simeon - @dotproto
Developer Advocate for Chrome Extensions  

[Vitali K]

Hi Simeon,

Thank you for looking at my request and thank you very much for detailed comments. 

 

the team that handles replies to rejection emails can't go into much detail about the reason for rejection.

 

This is surprising to me. In this case, support messages are of little use. I see that you yourself understand this. If I can vote somewhere for a change in structure, I would do it. I think many extension developers would do this, but of course I cannot say for everyone.

However, it's clear to me now that I shouldn't blame Chrome Web Store employees for their bad attitude towards extension developers. It's the division structure that's to blame. If the situation repeats, now I will definitely not react so much negatively to the employees.

I dug into the most recent rejection and found the offending bit of code that was considered obfuscation. At the moment your URL handing is a bit unconventional; you declare dsub, dhost, and dtld at the top of your popup.js script, then proceed to re-combine them in your fp function by assigning them to a variable called dn (which is unused). While I wouldn't consider this obfuscation, I can see the reviewer's point of view here; there's little reason to do this than making it harder for someone reading the source to understand the logic. That said, this feels overzealous to me and if you were still being rejected I'd open an issue with the review team to reassess this verdict. 

Honestly, it’s very surprising for me why the moderator saw something bad right here. I certainly did not expect this.

I will explain.

dsub, dhost and dtld stands for domainsub, domainhost and domaintld. In the code, I just use a shorter version. I never would have thought that this could cause suspicion.

fp stands for findproduct. This is also an abbreviated name that is more convenient for my brain to use. Strictly speaking, your minification rules allow this. I was told about this several times. 

Please note that minification is allowed in the following forms:

• Removal of whitespace, newlines, code comments, and block delimiters

• Shortening of variable and function names

What concerns unused dn variable.

Here is a piece of code before removing comments in it along with console.log() lines.

var dn = dhost+'.'+dtld;
console.log('dn - '+dn); 

I use this variable just for more convenient output to the console during debugging. I never would have thought that this could be perceived as a desire to confuse the moderator. But since you paid attention to it, I will remove this variable. Thanks.

Thanks for the clarification with such libraries like jQuery. I thought that it was these libraries that the moderator did not like. But now I am calm.

My extension has already been published. But I will take into account all your comments in new versions. Thank you!

Best regards,

Vitali

[JeffW.]

hi Simeon and others,

I'm about to submit an extension. 

Does the Chrome team see uglifying code as obfuscation? Or is it seen as a form of minifying?

Debates on the net seem to differ about this.

I'm using https://www.npmjs.com/package/uglify-es

If I use this lib, would it be okay to add compress and/or mangle as options?

Thanks in advance!

[Kent Brewster]

I don't understand why you're using this tool, unless it's to make your code harder to read?

--Kent

> --
> You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/da1ca732-24e8-4a62-935c-8080ad68140en%40chromium.org.

[JeffW.]

Two reasons:

1. I don't want anyone to clone my extension.

2. I'm using a self-implemented payment/upgrade system, so the extension is free but users can upgrade.

It would be quite easy to change the code to switch to the upgraded mode if the code is easy to read and change,

e.g. this.userService.user.isVerified = false > true;

[Kent Brewster]

You're going to want to handle all of that outside the extension, which is essentially an open-source product. Any suffiently motivated person will be able to run a tool like jsbeautifier on your code and figure it out, even if you do get it past review.

--Kent

[Jeff Winder]

Thanks Kent.

I'm aware that someone persistent could always reverse the code, just want to make it a bit harder.

So my question still stands :-)

Op vr 7 aug. 2020 om 19:05 schreef Kent Brewster <ke...@pinterest.com>:

[Deco]

The entire point of Chrome not allowing obfuscation is so that potential malware developers are not able to mislead the reviewers, or deceive them - this applies to any form of code "uglifying", or otherwise. Your code has to be understandable, and interpretable by the CWS team - including within it's public builds.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFLSVxfxDs1N_%3D30YYzz1c%2B_TpBfGJey30eSBfVzaJ65HGTUug%40mail.gmail.com.

[Nigel Stratton]

I read too many accounts of people copying extensions and selling them with no regard for the author. Which is why I took the core engine of my extension out of Chrome and into an Azure function. slow but protected. Azure gives me the ability to run my own licensing as well.

[Kent Brewster]

This (and similar solutions) is the right answer. I wish everyone within the sound of my voice would submit non-obfuscated code with comments intact, to better the average review response time for everyone else.

--Kent

[JeffW.]

I like that idea of cloud functions too, looking at it now, thanks ;-)

[Hr Gwea]

On Monday, August 10, 2020 at 1:38:14 PM UTC-4, Kent Brewster wrote:

I wish everyone within the sound of my voice would submit non-obfuscated code with comments intact, to better the average review response time for everyone else.

From my own experience of review times, I can tell that code minification doesn't have a significant impact in how long the review takes.

An extension of mine contains about 18K lines of javascript. Then, after a pass through Closure Compiler, the result is 360 KB of meaningless code.

This extension is usually reviewed and approved in about 12 hours (always less than a day). And it requests the <all_urls> permission, so it's manually reviewed for sure.

And it's not possible that the reviewer is doing a file-diff comparison against the previous version so as to review only what's different, because our build system also randomizes file order, which results in completely different minified code each time.

Last year, on the other hand, when the extension contained significantly less code, the review times were significantly longer.

[JeffW.]

Just an update, happy to see my extension has been approved within two days after submitting it. I minified the code and uglified (compressed & mangled with an npm module called uglify-es) one file containing some core code.