Probably not. It’s to protect vulnerable users from scams.
2 Likes
Please keep the thread on the topic of the security implications of removing third party closed source modules / use cases of third party closed source modules.
8 Likes
It would also be nice if people wouldn’t keep sending the same arguments back and forward. There’s no reason to repeat what’s been said. It feels like there’s 50 posts worth of content in the 200+ posts the thread currently has. That’s a lot of wasted read time.
1 Like
Can confirm: I helped arrange a meeting between Squirrel and the Admins, to ensure that Terabyte Service didn’t violate the rules or allow centres to endanger users in any way.
Which brings us back to the point we’re trying to make: this update is punishing the rule-followers just to stop the rule-breakers. And as Squirrel pointed out earlier, there are ways for these rule-breakers to continue their shenanigans even without private modules. So what does this really accomplish…?
19 Likes
This argument isn’t really well thought through.
If you want to hide code from users maliciously, you didn’t even need private modules and still don’t - you can obfuscate and virtualise code to the point of no return, unsandboxed and in these cases Roblox staff can’t audit these modules themselves.
Roblox is essentially forcing both genuine and malicious users to do these things - it’s a massive pain and also doesn’t really hinder the effect of exploiters just running their own equivalents of private modules that are even more cryptic and far more difficult to find (you can’t just audit for “require” across scripts).
I see why Roblox did this - but you can’t argue this won’t hurt a massive number of legitimate paid services and systems just because you aren’t aware of all the cases where it is used legitimately (where I work, it’s used a LOT of the time)
14 Likes
For paid scripts/services you have two competing philosophies. On one hand, you have a service where you are selling access to a product, which is what most people here seem to be doing. On the other hand, you have a service where you sell the product itself. Both are equally valid, but with an open source language like Lua it’s impossible to fully do either. That’s why private modules are so important.
Private modules have the inherent issue of not having any signatures or identifying features though. The most you can do is check who owns them. We all know this.
While it’s technically reductionist to argue that private modules are nothing but security holes, that’s what they are. I’m not dismissing any of the people with genuine use cases. I’m more suggesting that there are other ways to do most things that private modules are used for and they’re better choices regardless. The examples I gave were just the ones that I’ve seen that appear to not be doable securely without private or extremely obsfucated code.
1 Like
Wow.
I would be more concerned about the number of signatures if they were being made by actual game owners using the feature, but for them to put it in game for any user to just vote on without any auditing from the developers using the system is just… the icing on the cake really.
It’s LITERALLY a demonstration of why Roblox wants to remove this feature. The fact that someone can update a private module and have it instantly apply to any new servers using that module, without the developer needing to update and approve what changes it makes first… this is beyond unreasonable.
36 Likes
I can agree with these points you state, and how this is such a big security issue. I totally get it.
However, the biggest problem for me has to be Roblox’s constant urge of removing useful systems for security without giving an alternative in a reasonable time frame.
In my opinion, this situation should HELP the development of a new system, and urge that a better concept is created and worked on to ensure that the problems with “Closed Source Modules” are completely ironed out. Yes, obviously this is allegedly happening in the future, but that doesn’t help those currently affected.
Removing systems people have eagerly worked on just makes me feel like some of the work I am doing now might be expendable. However, if I am provided alternatives it would make me feel secure about continuing development.
14 Likes
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.
8 Likes
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.
14 Likes
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.
8 Likes
Fair enough. I think public modules need to be fixed up as well.
2 Likes
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.
9 Likes
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.
10 Likes
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.
15 Likes
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.
37 Likes
Will packages allow closed-source code distribution?
11 Likes
Can modules which are uploaded to a group assets page still be required for that group’s places?
1 Like
Since the owners are the same, the answer should be yes.
2 Likes
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.
3 Likes