As a Roblox developer, it is currently very difficult to protect source code of my plugins when Roblox installs them onto the person’s machine
I’ve already mentioned how easy it is to steal and reupload plugins on my Twitter account, but I’ll reiterate it here.
All plugins are saved to /{USER_ID}/InstalledPlugins/.... These files do not have the source code of the plugin precompiled or protected at all. The use of the folder is also used to save settings but I’ve stated why that’s a problem as well when it comes to switching between machines.
A bad actor can simply place the RBXM into their workspace, then reupload it to Roblox. This extends to how bad the moderation is when it comes to asset protection but that’s neither here nor there.
The bad actor can also hide malicious code inside the plugin when reuploading it, again, thats for another thread.
The easiest way to protect against this would be to have the model files of each plugin get downloaded from Roblox when Studio starts, instead of having them hard-installed. This has already been proven to be viable as this is what Studio does when TryInstallPlugin() is called.
If Roblox were to address this issue it would improve my development experience as I’d have the peace of mind knowing my paid plugins aren’t being stolen and losing me money.
Security through obscurity is hardly security at all – the only way to truly secure a plugin’s source code would be to have it run on Roblox’s servers. Anything that exists on the client - even just in active memory - should always be assumed to be compromised.
Yeah and as a developer I’d like to know what lua code is being executed by the plugins I have installed, otherwise they could make changes to my experience without me realizing it.
There isn’t really a way to stop locally running Luau script logic from being up for grabs because the code needs to be either shipped to the user, or at least the bytecode so the Luau VM can execute it. You can reverse bytecode to source code and annotate it pretty easily.
Ultimately an attacker will be able to grab your source code and reupload it if they are determined enough, and closing the source has the effect that no power user is going to want to run your plugin anyway, which affects how much you can ask for the plugin. (see above) And when your plugin has a high price, you’re more likely to be targeted by more sophisticated abusers like this.
If you want to make a sustainable business, it’s best to focus on making tools/services that have a centralized component that only your business can manage. (e.g. web-based systems, with a free plugin as a client that interacts with that centralized system to provide some value to the user) Power users can audit the client (the plugin) without you losing any business that way, and you don’t need to worry as much about people cloning the plugin (apart from the abuse vector you mention where they inject malicious code).
Server-sided plugin scripts seem to be the only real solution to plugin security.
I’m not an expert on server costs, but it might be viable to have a small/shared-hosted/low-powered server spin up for every person using Studio. Roblox already offers free servers to play experiences, and the developer community is a small subset of the player community.
I noticed you can’t access Studio while Roblox’s servers are down. If I had to guess, they might already be working on server-sided plugin scripts. I would assume you could still have client-sided LocalScripts for things that are ping-sensitive, but the introduction of server-side logic could make stolen plugins obsolete.
For the issue of knowing what changes a plugin is doing to your place, maybe they’ll have moderation similar to what Apple has for the app store. Developers who write malicious plugins have their license revoked.
For sure! As both a plugin developer and a game developer, I have interests in both knowing what my plugins are doing, but also protecting my own IP (and that of others’ work which I include - this has already caused problems with some collaborations I’ve done)
Ultimately the only real solution I see here is that plugin permissions need to be super beefy before we can consider closing off plugin source code. You should be able to audit and block every single action a plugin takes within your game.