I’m all for that. I feel like it shouldn’t be too difficult to implement a proper permissions system if Roblox prioritizes it.
It wouldn’t need to be a general purpose system either, just constraints to powerful services (such as HttpService, MarketplaceService, TeleportService, DataStoreService) for which developers can whitelist certain actions that modules are allowed to take with them.
The important thing is that updates to modules aren’t applied automatically. They need to specify what permissions they would like to have whitelisted so the developer can approve them for each update.
Exactly. None of us would be upset if we were given a viable alternative beforehand. Instead they’re yanking away a valuable feature from everyone, when not everyone is guilty of abusing it. That’s the root of the problem, and it’s why this thread has exploded into debates and petitions.
My issue with your statement is that once private modules are removed, the problem that you’ve highlighted doesn’t change at all. Public modules can still be updated without the developer needing to update or approve the changes.
I think the level of ignorance towards service providers on Roblox is unfair.
This pretty much hits the ball out of the park. If we had an alternative with permissions available after the removal, that would solve my problems at the very least. I’m willing to license access to my code to serious developers who want to perform audits and compatibility, but I want to have this control. Without a form of Private Modules, this makes it extremely difficult to enforce.
Indeed. For this reason, I would go so far as to say that even public modules that aren’t owned by the developer should not be requireable.
In source control, there’s a concept called “vendoring”, in which the dependencies of a piece of software are included directly in the source. This means, when a dependency changes, it is up to the developer of the software to ensure the changes propagate. Thankfully, version control systems make reviewing changes much easier.
This idea actually manifested itself in Roblox with the now-defunct Sets feature. When an asset was updated, a Set including the asset would still use the old version until the owner of the Set explicitly updated it. This concept is also present in the new Packages feature. There’s even a feature to compare changes to scripts. In fact, I think Packages will make external-requiring obsolete.
In the next few months we will be adding support for using and updating third party packages in your games. The updates will be entirely controlled by the developer. Once that is done, we will revisit the entire concept of modules.
In general, I agree that referencing mutable content in a non-versioned way (which is what modules allow) is an bad idea. It is especially bad if you do not own the code.
I am seeing a lot of complaints about Roblox removing features without replacement. Most of the time we do provide alternatives, but in the rare case that we remove a feature without replacement, we usually give rationale. For example, with the sets feature, we explained that the feature incurred significant maintenance cost and we would have had to redirect development effort towards maintaining sets instead of working on new features. Practically speaking, this means that features like Cross Server Messaging, which is slated for beta release before March, would have had to be delayed. We decided that we would rather spend our time on a new feature that most developers will take advantage of rather than an existing feature that few developers used.
In the case of third party closed source modules, we want to provide a replacement in the form of packages with granular access permissions for scripts. However, releasing such a system will not occur until late 2019 at the earliest given the complexity involved in building an access permission system. We had to make the difficult choice of either removing third party closed source modules or waiting potentially years for a replacement. We opted to remove the feature because of the risk it poses to our platform and the unlikelihood that a replacement can be delivered in the near future.
My overall point is this: if you think Roblox should never remove features without replacement, I would like you to question that assumption. We are trying to do the best thing for our developers and sometimes that requires making the tough call to drop features.
That may be true for newer developers coming into the platform. But I’m not sure I know of any knowledgeable developers that randomly add third party content without at least looking into the source a bit. I know you guys want to appeal to the entire spectrum of developers on the platform, but that shouldn’t mean you punish others because other people don’t know how to use the system.
We have no definite plans to do this. If you want this to happen, the best thing to do is post a feature request with your specific use case. This will help us better understand what sort of sandboxing we would need to provide to make this a reality.
I’m fine with closed source third party modules going, but now that public ones may go I’m concerned. It’s important for users without development experience who use certain models to be able to insert them with ease, and not have to enable any form of auto updating themselves. This allows a lot more users to easily receive updates on the models they take.
My question is, will the packages auto update without any interaction from the user putting it in their place?
I would personally not want that to be the default/only option, you really don’t want to give people the ability to dynamically update content that affects your game, and if you think you do then this should be an opt-in per-package. Even if there is no option to auto-update, if the API is rich enough, you could probably define a plugin that auto-updates certain packages when you load up Studio.
I wouldn’t want anything auto updating in a game of mine because I’m capable of managing things myself. My worry is users who aren’t capable of that, those who would benefit from things just being auto updated on default. Users who use Roblox primarily to socialize with their friends, making places for fun to hang out with friends in rather than full-fledged games with lots of development experience behind them.
This would be better, but the best case scenario for users like this is auto updates where they don’t even need to open studio. For these users, auto updating wouldn’t pose any more of a risk than already malicious models, and I’m not concerned about anything being open source or closed source since I already planned to make things open source.
This argument definitely goes both ways and I’m not sure which side is the strongest. Yes, it means users don’t need to update the packages themselves, but if something suddenly breaks in their games because of a package update (i.e. one that is actually buggy, or just not taking backwards compatibility into account), they may not be capable of fixing it either because of the lack of experience/skill. I agree that there should be an option to auto-update in general though.
I know this thread has died down, but I wanted to bring up another big flaw that I’ve noticed with this band-aid fix:
I know this change was made to stop the mass amount of backdoors that have been appearing on Roblox. However, this fix still allows modules that are simply made public to work. Most game owners who don’t know a lot about how modules work will not look at these loader scripts as suspicious, and because after the change all backdoor modules will simply be made public, backdoors will continue to be an issue.
As I and many others have suggested, we should have 1) a property that you MUST enable yourself in order to load any modules that are not an already present object in-game (ID-based modules) and 2) put a warn in the Developer Console that tells when ANY module is inserted (Along the lines of “Module [id] has been loaded into the game”). This allows developers to see exactly what modules are being placed in their game, if they want ID-based modules at all, and is probably our best bet at combatting backdoors.
I’ve also seen other people say that we should allow Private Modules but restrict their accessibility to the Server. I think this change is fine, but I along with others use Private Modules extensively to whitelist a sold product to other people. If a lot of the API is restricted, these modules would be practically useless.
As I previously said before, most game owners won’t see this post and won’t know that there will be any change and won’t know that there is potentially a malicious script being loaded into their game. Therefore, when the change rolls around, all the exploiters have to do is make the module public and they can continue their shenanigans.
Someone came to me saying a user remotely updated their game to break. I helped him track down the module responsible, and it turns out it was public. Other developers in this thread have proposed obfuscation to protect their code from copiers, and it seems we weren’t alone in this line of thinking.
Forcing modules to be public may not stop the malicious users from creating backdoors. They will change tactics in response to this. Just thought I should share this with you all so we know what to look for. Because your average user probably won’t…
EDIT: And this was a very simple example of obfuscation. You could solve it by changing “require” to “print”. Imagine if someone truly wanted to encrypt their source…
