Maybe a feature in SpongePowered is to send installed mods to the client. If a client does not have a mod, loop through the jar contents, check to make sure it is a mod, and then install it to the client, and when the client leaves, uninstall it. Or maybe have a list of certain supported mods in order to prevent malicious viruses from being transmitted? I don’t know, just thought it would be cool. Or is there a way to inject code into the player’s jar so it can render the mods and everything.
3 Likes
Have you read that?
Will you be able to send mods from the server to the client?
The general consensus is against this due to security concerns.
Minecraft’s API does not plan to send mods (with executable code) to the client either.
3 Likes
Reviewing takes a lot of time, so it is unlikely that we will go forward with this. Not to mention, the Forge team is really adamant against it.
Java has sandboxing facilities but
- I am not sure that Java’s sandbox is that secure.
- We may screw it up ourselves pretty badly.
5 Likes
Literally every security bug I’ve seen with java is with regards to sandboxing / web applets.
Not to say that other bugs exist - they certainly do - but they are vastly outnumbered by the untrusted code vulnerabilities.
Maybe see my idea as well:
I already did something like this with nashorn at work. It was more a proof of concept then anything else, but it worked pretty well.
I was locking the script out, by letting it do nothing except some calculations. No print() nothing
Then i added piece by piece the needed functionality.
it would be possible to do that in reverse. “Just” deny everything that could be used for malicious stuff and allow them via Android based permission system. Since you can convert Java to JavaScript, it would be a possibility.
I will fight for some kind of “just join and play with more than vanilla stuff”.
I would do that as a seperate mod, cause it won’t get integrated i think. But it would be neat to have some support within the API.
Sending mods to clients could easy become an issue if a server owner decided it would be a good idea to inject malware into a player’s client or computer, depending on how it is coded.
1 Like
Thats why i had the idea to restrict these mods (clientside) with some kind of Android permission system.
Under Android an app just crashes right away if it doesn’t have the needed permissions.
3 Likes
Why not you just build your own sandbox? I don’t think it would be that hard… Force the developers to only use their mod folder as the directory the mod can write to and disable execution of programs…
2 Likes
@Ekranos @BlizzardFye
In my post it clearly says,
This system would presume that mod authors will grant others distribution rights to their mods. Most mod authors do not permit distribution unless permission is granted to the mod pack author, and even then there may be caveats. As good as something like this sounds it may not be too practical.
Google built their own entire Java virtual machine.
Here we are using Oracle’s or OpenJDK’s.
1 Like
We can’t simply build our own JVM and my idea still works with every JVM that supports scripting. In case the there is no scripting, we could provide some fallback mechanism with an own implemented scriptengine (or is nashorn / rhino free to use?).
The idea behind this whole thing with JavaScript is simply the reason, that we can sandbox kinda easy. We can block the reference to (Java.type and Java.extends) and then there is no way to get classes to get network classes for example.
If the user accepts that this mod want to use the network, then we provide it globally via reference.
In the beginning this whole thing would be restricted like hell, but when it gets more mature, it will be a pretty good thing i guess.
Do you really think that’d work out? I feel like some day some genius might come around and find a workaround. I dont think this is totally safe, do you?
Nothing is totally safe. You can break out a VM with some kind of ease as well. Still alot of people use it for isolation. Big hosting companies running servers for you in a VM. Apache isn’t totally safe as well. Nothing is totally safe.
We could do it as an opt-in feature. You have to manually activate it. Maybe we could provide some kind of settings where you can choose who do you trust like in NoScript. And provide as well as NoScript a whitelist with trusted servers.
So you can choose between “Use always”, “Only trusted servers”, “Ask before”, “Deactivated”.
Or maybe we deny executable code on the clientside and do it like Spout did and provide as much as we can without the possibility to execute code on clientside which is sent by the server. But still have some kind of mod on clientside which is loading all the textures, blocks, gui, ui etc.
The thing is just that it would be so great to something like this included in the client. Just a few people used Spout, because they had to download it seperate.
3 Likes
Another idea all together is that the player can do one of two things when installing client-side mods required on a server:
1: On join give the player a list of mods to download themselves, along with a link to the website the mod is stored on. The player can then decide if this is a legitimate mod themselves.
2: Use a custom modpack down loader that has been effective in the past.
This is something that I personally wouldn’t really want. If something like this was done, it would have to be strictly controlled with some form of client side permissions system, I believe that there was a permissions mod for client side addons at one point, although I never tried to use this addon before before.
I think having ample (idiot proof) instructions for a few main launchers like AT or MultiMC or something should suffice. Individual servers can obviously create things for their own users, however, I think it gets tough legally and logistically when lots of people can use (and abuse) this sort of system.
I like the novelty and utility of the suggestion, but I think the expressed opinion thus far is pretty accurate IMHO.
Nashorn is Java 8+. Rhino is super slow, especially the one bundled with Java.
I am also not sure how easy it is to secure either Rhino or Nashorn. They may depend on Java sandboxing.
We may be able to provide a client mod that lets server do extra things, and that is also the plan for Mojang’s API.
1 Like
You could make a custom scripting language (for example based on lua or javascript) that simply doesn’t provide methods/functions/interfaces for stuff like file system access or execution of external files. It would be really limited, but at least allow for some simple modding.
Just a thought: The main issue here is security. What if there was some kind of an official central repository for mods? The server owner could select what mods they want to use, and then when the client connects, it simply goes to the repository and gets the mods. This would hopefully eliminate the problem of the server sending executable code.
It would be kind of a cross between Feed the Beast and the bukkit plugins page. Of course if a mod author doesn’t want their mod in the repository it doesn’t have to be…
Just throwing out an idea in the hopes of sparking some thought.
EDIT: I forgot about the fact that some mods need to be configured correctly to work together on a server (sometimes). I’ll think about it.
1 Like