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
I’m happy with the current system. I thought it was common knowledge that this was (now) considered intended behaviour.
2 Likes
Crazy idea, but what about runscript(assetId/LuaSourceContainer,environment)? It would look like this if written in Lua:
local function runscript(from,env,...)
local func
if type(from) == "number" then
from = getMainModuleFromAssetId(from) -- error if not found
func = loadstring(from.Source) -- error if parsing error
elseif typeof(from) == "Instance" and from:IsA("LuaSourceContainer") then
func = loadstring(from.Source) -- error if parsing error
else
error("Expected number / Instance")
end
env = env or createDefaultEnvironmentForScript(from)
setfenv(func,env)
return runWithClearCallstack(func,...)
-- getfenv(0) (the thread environment) in func() should also be env
end
The vararg isn’t that necessary, since using ... in the “root” of (module)scripts does nothing now and would be weird if it suddenly did. and we can just make the script/module return a function, or pass variables in the environment
If we don’t add vararg, we can “leave the arguments space” available to add other stuff, e.g. security stuff (like you suggested) when/if it’s implemented. (although since we can specify the environment, we can sandbox it just the way we want it) One example would be a timeout, so we can protect against infinite loops and string.rep("crash",1e99)
this function seems much easier to implement than all the security stuff and API restrictions you mentioned, while it also allows us to do much more, since we can sandbox it just the way we want it
Example of something what this would allow
Just a stupid example that could be fun to implement, but not that useful or so
Have an uncopylocked module for your game that looks like this:
return {
Theme = "Dark";
Keybinds = {
G = "Grenade";
E = "Inventory";
};
}
Have a “Load Settings” GUI where people enter an assetid and this happens:
local settings = runscript(enteredAssetId,{})
settings = merge(settings,DefaultSettings)
Basically allows people to easily load settings. Doesn’t seem that useful for one game, but for scripts that are in a lot of different games (like admins) or if games use the same settings.Keybinds format, it would allow for nice stuff.
and because we just gave an empty environment, they can’t do any damage, except infinite loops or string.rep with a high number. maybe one of those “security options” should be a script timeout
Another example would be adding Instance/Color3/UDim2 to the environment and allow people to create their own UIs (well, take the one from the uncopylocked model and edit it a lot)
just another crazy idea
These crazy ideas for players aside, this feature would actually be quite useful for developers. Apart from being able to relatively safely (sandbox) load external modules, we could also sandbox our own scripts/modules for testing purposes. E.g. disable scripts/modules and manually run with sandboxed environments that keep track of require() calls, DS requests, …
5 Likes
As much as I don’t want this behavior to go away, it’s clearly being abused:
https://www.reddit.com/r/roblox/comments/75owub/psa_remove_kohls_admin_infinite_from_your_game/
Who knows what the chair is for? He can update it with whatever payload he wants and insert it into games since a lot of players own it.
Uhm, talked to Kohl about this one.
First of all, it’s just a normal chair model, unanchored and unwelt at that.
Secondly, it was made for a meme so I don’t really understand how this is a danger?
Lastly, it hasn’t been updated in 2 years and he doesn’t plan on updating it either.
Plus this certainly doesn’t relate to modules being removed, the chair is a model.
Wait, so they actually admitted they abused the trust of their users?
3 Likes
Khol says he isn’t going to do anything malicious. So what?
The chair has everything to do with modules because the marketplace prompt payload was injected into every game his admin script is in via the closed-source module he can edit at his whim. He is literally modifying half of ROBLOX’s games without the creators’ approval. He has also taken steps to avoid creator’s ire by deliberately not displaying the prompt to them. If that doesn’t sound fishy, I have bridges in stock now.
His word that he won’t do anything means absolutely nothing.
2 Likes
Whoa, let’s not start a hate thread here. I already feel like I shouldn’t have asked the question in the first place. But let’s instead see if what occurred makes a legit reason to actually remove the ability to run non-owned modules.
Discuss ideas, not people.
6 Likes