We’re launching a new feature for plugin developers that will allow you to obfuscate your plugin code when publishing your plugin. This is an exciting new option that will provide developers publishing sensitive, client-facing code with a layer of protection.
We’re also going to, by default, minify all plugin code. This will cause slight performance improvements and hide developers’ comments and variable names from the public.
To obfuscate your plugin, simply publish a new plugin version like usual and mark the “Obfuscate client-facing code” checkbox.
Please note:
Obfuscation may make your plugin less performant
All plugins and plugin versions published before today will maintain their unmodified format
Open-source plugins will still have their source code available at the “see plugin code” button
Thanks, Leon. Eager to give it a go! A couple questions…
Is there an increased chance of any issues if we publish already-minified code with the obfuscation option enabled? (My tooling automatically uses Terser when I “compile” my code. I can disable it, of course, but would like to know if I should.)
Can you confirm whether the window.do_not_minify_plugin flag is still functional or not? (I suspect not.)
Thanks for the questions! Your already-minified code should work just fine. We’ll minify it again with Terser so it may be redundant, but that shouldn’t cause any issues.
The window.do_not_minify_plugin flag has not been functional for a long time, since the minification scheme it affected has not worked for a while. Would a flag like this for the new scheme be helpful to you?
The source code will still be available for open source plugins, so don’t worry! We’re only minifying and obfuscating the published code that is sent to apps.
I’ll have to give it a try and see, but if I understand what you’re saying, then YES.
It’s been drop-dead simple to duplicate plugins because of that. I have no idea how widespread the phenomenon is, but “plugin theft” has definitely occurred a number of times. (I’ve even seen a forum post by someone advertising they can duplicate any plugin for a fee!)
Needless to say, that impacts the bottom line of both the plugin dev and Bubble.
I’ll post back once I determined if the issue I’m concerned about still exists.
If I’m understanding you correctly, this is a problem that plugin obfuscation can’t really solve. Obfuscated code still needs to function, so someone can copy paste an action into a private plugin, sure. But someone will only be able to steal that exact functionality, which will be in an obfuscated, unreadable state. This will also make blatant piracy easier to detect on our end.
All client-facing code on the internet is generally public domain, but one of the best protections one can put in place is obfuscation.
It was a poor choice of words on my part. By “method names”, I really meant “identifiers” which are readily discoverable client-side and correspond to the names of plugin methods - e.g. “Initialize”, “Update”, etc.
Surely there’s a way to eliminate, randomize, or obfuscate those identifiers.
I’m trying to publish a new version of my plugin without obfuscating, and it looks like I always stay on the same version (I also don’t have the option to choose if it’s a major or minor update anymore) so I can’t upgrade to the new version of my plugin in the editor.
Well, I’ll be happy if it works properly. Haven’t had a chance to test this auto minification yet. Good to see that feature come back, though. Hopefully this gets maintained better than the google compiler version did. (And terser is what I use for manual minification already.)
@leon.maksin I assume you’ve considered this but what happens with variables set on the instance or window objects? For instance, if I set a function at instance.data.function, will that still be able to be referenced across other actions on the element?
From my own tests with obfuscation, everything works just fine even if all the code is obfuscated. States/Events/Custom functions all are working well.
