I would like to add some additional context on this decision.
Currently modules can do anything that a regular game script can do:
Access data stores
Teleport players to other games
Send HTTP requests to any domain (if the game allows HTTP requests)
Log player chat messages
Long term, we are going to implement a solution where plugins/scripts can be given granular access in order to sandbox games from malicious code they may import. However, this solution requires significant effort and it would be impossible for us to deliver it until late next year at the earliest.
We are not saying we will never support closed source modules, but that the current risk is simply too high to allow.
Without coming off as accusatory, in the meantime what would you suggest people who sell products or use modules to hide sensitive information do? It’s obviously a bad idea to include sensitive information like API keys in a place that other people can access, but at the moment there’s no real alternative.
If you are exposing a service through web APIs, I recommend doing what most products do: have developers create API keys and use those to authenticate against your service. Make sure to have throttling and other protections in place to prevent abuse.
If you are providing some sort of anti-cheat service or something that requires the code run on the game server but not be accessible to anyone, unfortunately that use case is no longer supported.
Alrighty. That’s disappointing to hear, though it’s understandable. Will that use case be supported once closed source modules are re-allowed in the future, or is it too early to tell?
Can you tell me if I would still be able to do this (given the module is located in my inventory, rather than on the group)? If not, I’d like to adjust things as soon as possible.
The issue is, I use this module for both a group game and a non-group game. The group and the other game are both held by me. I just hope there will be a way for me to handle this without having to duplicate the module and update both versions every time I want to adjust it.
Unfortunately we do not yet have a solution for that. You will have to duplicate the module.
Early next year we are working on a solution so that you can share assets with specific creators/games. This would allow you to use a single module across games that are owned by different creators. Expect more information about this in the coming months.
So as per my original question, modules published to group assets can be used by the games that are also published to that group, without having the source code viewable by others?
Just realized that I have around 10 private modules used in both of my games, three of them being required by another one of them. Looks like I’ll have to copy all of them and edit the named one to require the correct copy of the other modules per game. Maintaining this will be a pain.
Sooo … my solution is just being thrown under the water? It’s the same path you’ve guys have taken before, and it provides a much better means than removing the feature until the company can do what you’ve discussed regarding granular control. If it comes down to it, I guess it’ll actually happen, but you’re only encouraging the bots/those who wish to protect their source until such solution to build encrypted VMs. Then we’re back to the same problem: inexperienced developers still at risk of not understanding what the code does and utilizing the bad malicious plugins/scripts. Why can’t this even be considered? Yes, you’ll have prompts to ignore/allow the module, but it still WARNS the developer of the risks each and every time? What’s so bad about this vs not having it at all?
I am excited beyond compare.
Backdoors, hidden stuff in admin scripts, and all sorts of crazy stuff ends here and now. I am completely ready for this. In my eyes, if you’re worried about copy-cats and clones of your private module script, then don’t make it public to begin with. If it’s going to be a free model, there’s going to be copiers.
What you state as an alternative will ultimately lead to the same grimey situation we are currently in (backdoors, malicious scripts hidden inside other scripts). I feel this is a good change, despite some drawbacks we have to overcome.
We considered adding a setting to allow third party modules. Ultimately we decided against it because it is simply too dangerous to let developers put third party unsandboxed, unauditable code in games on our platform. We are not willing to take this risk.
We are aware that this change alone is not adequate to address malicious code. We are taking other actions to mitigate abuse, which you will hear more about in the coming months.