I agree with EchoReaper, Removing this because it’s ‘unsafe’ for the user is ridiculous… It’s their own choice to use it or not.
1 Like
Private modules are a valid form of IP enforcement for shared content and happen to be the only one that’s available to us. I can’t imagine a situation in which disabling this bug/feature would directly benefit developers, and doing so will probably break stuff.
Preventing third parties from requiring your module has its own, distinct use cases for private content, e.g. copy-protecting proprietary games.
I don’t see any reason why these behaviors can’t be implemented separately. They’re not mutually exclusive.
One useful way to go about this would be to remove the ability to require unowned modules named PrivateModule, and to not touch the MainModule system.
It’s nonconstructive to argue that a feature should be disabled simply because it can be used incorrectly despite having valid use cases.
Just my 2c
7 Likes
There isn’t a problem with protecting IP, the problem lies in that the user has 0 control over when things update, even if not malicious, a change may break a game by renaming a function or something similar. To have a game that has no stability is stupid and none of you should ever condone such behaviour. The solution is proper versioning so I can require version X of module Y.
To say to not remove it because you can choose not to use them is like saying we should just legalise all drugs because you choose to use them. Private modules are like sticking your hand in a bag of drugs and candy and hoping you get candy every time, when the owner of the bag can swap candy for drugs once you’ve taken candy from the bag
“Hey, I can just require the version he didn’t shut off and I’ll be well on my way, screw that guy.”
The problem is very real and I’ve made similar experiences before ModuleScripts were a thing. The only reason this hasn’t happened to me recently is because I haven’t taken on very many development tasks for people.
But EchoReaper’s post is exactly the kind of dick move that the change is to prevent. If you have any sort of trust with your client, they would be happy to pay first before receiving the product, as is the case with a good number of software sold. Company demos product, client goes ‘Oooo, shiny, me likey’, customer gives money, you give product. You do exactly the same in any high street retailer.
If your client doesn’t trust you enough to pay beforehand then you clearly dont have a good repertoire with your client. I have never had a client unwilling to pay beforehand if I demo the product to them.
Just take a look at the [leftpad incident] (How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript • The Register) to see what changing code that people rely on can do, would you want the same for Roblox?
Sure, the trade can go well and for most clients it does, but you know very well that there will be shoplifters who try to take your stuff without ever intending to ever pay for it in the first place. Sure, it may be seen as a “dick move” to disable a module that a client has refused to pay for, but it’s analog to the police response to someone shoplifting. Yes, it could be considered a “dick move” to lock someone up for stealing a bunch of stuff, but it’s a necessary evil acting not only as protection for retailers but also as a deterrent for those considering theft for themselves.
Also, yes, there’s always the risk of a widely used module being shut down or broken by the creator, but it’s unlikely to happen here. Sure, changes to the module may break certain things but that’s something developers on ROBLOX are already used to (updates to the platform always have a chance of breaking something). You would think that someone capable of creating a module that is so widely used would have no incentive to simply shut it down, or to introduce changes so intrusive that they break everything that’s using it. After all, they’re happy when their code finds a use.
In the leftpad incident you linked, the only reason the developer chose to distribute his code himself rather than doing so through a distributor was because that distributor took ownership of his work and changed its name. I’m fairly certain publishers of modules on ROBLOX won’t have a motive to do something similar.
3 Likes
@ScrapYard
The current system would not even require a naming system, it already works properly with modules that are not named MainModule. Only modules named MainModule can be required by other users.
to all:
The MainModule system for allowing the use of code without sharing its source is a boon to roblox as it allows easy updating of systems across games without forcing creators to make the code open source. Before, there was zero middle ground: you either did not share it or you shared it with everybody. Removal of the MainModule system would negatively affect Apocalypse Rising, for example: it uses the MainModule system to share Google analytics between published and testing versions.
The MainModule system poses security risks because people can update the module with malicious code or remove the ability for the module to function. The very same systems that allow abuse are the ones that are enabling builders and scripters to share their work with more people as well as making it harder for developers to work on their own games that span multiple accounts, as with Apocalypse Rising. Removal of the MainModule system would be detrimental to the roblox community as a whole.
4 Likes
Oh, neat. So absolutely nothing needs changing.
I’ve seen too many instances of API developers treating their users like children by removing useful functionality in exchange for a false sense of security (e.g. all of Java).
Also, I can’t picture the demographic that is able to require remote modules and develop games with them, but at the same time doesn’t implicitly understand that running unknown 3rd party code is risky. That’s maybe like 2 people ever
4 Likes
With roblox’s scope I think there are a lot of people who don’t understand the risks. For example, khols/epix/whateverhe’scallednow admin scripts have no warning that there are modules in it or anything, and people who don’t understand how scripting works will have zero idea, and since admin scripts are seen as admin-as-a-service, they are inserted without understanding the ramifications.
I don’t think modules have much of an effect in that kind of case because the people who use his admin would just as unknowingly insert a public sourced script into their game that used InsertService to insert the latest version of whatever he wanted the admin to insert.
2 Likes
Sorry about my username,I had to switch to an alt because my main account was hacked and I couldn’t risk keeping my dev account on it, anyways…
Please do not remove this ability, you guys don’t understand how much this helps me create models without users re-distributing my hardly worked on model. I currently have a model with 23k+ sales and if this ability is removed, will completely break it.
1 Like
Please don’t. You can share code with others, without giving away the source.
3 Likes
Has the ablity to require non-owned ModuleScripts been removed or can we still do it?
I haven’t gotten any complaints about Nexus Admin. Think it is still working.
3 Likes
And hopefully it’ll stay this way.
3 Likes
Hate to be a necrobumper, but this is ridiculous.
If I make a ModuleScript model private, I should at least be given the option to tell Roblox that I don’t want the code to be able to load into a game that I don’t own.
I didn’t realize this “feature” was a thing. My game’s framework could be loaded into another person’s game remotely and I had no idea. I thought my model was safe because it was never put on sale in the first place.
I get that some of you guys want to keep your module code private while still allowing people to use your module, but surely there must be a more discrete way we can go about with this, right?
7 Likes
I wouldn’t mind a type of “PrivateModule” type system, with the setting being based on the name of the module. MainModule would be public (thus backwards compatible), PrivateModule would be private (the desired private behavior), and anything else wouldn’t do anything.
6 Likes
If I remember correctly, loading modules you don’t own only works if the module is called MainModule (not the model name, the ModuleScript’s name). You should be safe as long as you give it a different name.
I’m hoping the MainModule system won’t get removed.
They have to be named MainModule to be required by ID though. Otherwise they have to be inserted and OP’s code has to be changed (but again, less of an impact than the large base of existing code that’d have to be changed if this was removed)
2 Likes
Yes there are several issues here. On one hand, you might want to share a module but not the code. On another hand, you might want to prevent your place from loading any code not owned by your place. There is also a possible desire to get a specific version of an asset vs the most up to date version.
It might also be desirable to have restrictions on what API could be used within a modulescript that you do not control. For example, SavePlace, InsertService, DataStores, HttpService, etc… could be restricted. Even access to workspace/Players could be something that could be restricted in math-only modules. It may also be desirable to consider a modulescript similar to a networked client where the modulescript can construct objects in a special container and then trigger an event.
Restricting access to httpservice, require/insertservice, and a few other APIs prevent a script from phoning-home to determine if they should break, assuming a specific version is forced.
These topics may come up next year during the planned efforts to improve filtering enabled.
6 Likes