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.
- 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
Best of luck building plugins, and happy Bubbling
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 clarification.
Nice, @keith will be happy.
It is a pity that I might lose the #1 source of learning material: other’s people easily-readable code.
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.
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.
Thanks! One quick follow-up (sorry to be such a nag)…
Does “obfuscation” include the method names (which have been easily discoverable with Chrome dev tools)?
And if so, are the method names obfuscated even if the code is not?
The external method name won’t be obfuscated, but method names inside the primary function will be. Would this cause any problems?
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.
Only occurs when checking “obfuscate plugin”, publishes fine otherwise.
No idea if this is just on my end/internet:
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 just private messaged you, I’ll investigate asap
Unfortunately, there’s no way to do this today. We’ll consider your feedback, let me know if you have any other suggestions as you test this out.
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.
@weswas @starnapp thanks for flagging. I’ve identified the issue, we’re releasing a fix.
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?
Gently reminding that MIT license and the other open source licenses are different from public domain.
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.