Minetest: CSM: Allowing a server to protect itself against clients running client-provided clientmods

[paramat]

I just wanted to check if this already done, or planned, or possible. If not possible i am seriously concerned.

Client-provided clientmods that cannot be prevented by a server creates a huge potential for irritating low-level troublemakers and cheaters on a server, and makes trouble much easier to cause. There are already clientmods being distributed on the forum and servers can do nothing to protect themselves.

Before now you would have to hack a client, now it's as easy as installing a mod. Server admin are already driven crazy by irritating client behaviour and now it will get much worse.

I am not asking for removing the ability to use client-provided clientmods, just a way for a server to prevent any connected clients from doing so, or not allowing clients using client-provided client mods from connecting.

Arguing that 'it is already possible with a hacked client' is no argument, it should not be made easier, and not supported and encouraged by the distribution of clientmods that servers cannot protect themselves against.

I seem to remember someone, maybe sofar, discussing this and getting the assurance that such an ability as i request would be added. Has it been? WIll it be? Why has it not been? @sofar was this you and what is your opinion?

/////////////

Here's a specific example of how this will ruin a survival server ..

The oredetect clientmod already in use effectively makes the world transparent around a player to a certain distance, any node can be detected and its co-ordinates displayed.
The server cannot prevent this or even know which clients are using it.
Some say the range is limited, however the valuable ores from gold to diamond are only separated by 13-17 nodes, so a detection radius half of this is enough to detect almost all valuable ores around a player.

Players with high standards who don't want to cheat in survival will not use the mod, but then will suspect other players are using it and are gaining an advantage, this makes them feel frustrated.
Players with moderate standards will see the advantage other players have and will be tempted to use the mod, the more players that use it the more pressure there is for the rest to use it.
Players with low standards will use the mod to cheat, and therefore gain an advantage over other players and are rewarded for their low standards.

The whole concept of MT is that 'you can't effectively see through solid objects', but now an unknown set of players can do this, and the server cannot choose, police or detect this in any way. This creates an atmosphere of anarchy, cheating, frustration, suspicion and mistrust, with the worst players having an advantage and being rewarded, having fun, while the server is ruined for everyone else.

I have read the arguments that CSM is harmless because it can only read map and not write to it, however i have explained above how this alone can ruin a survival server.

///////////////

For some servers unregulated client-provided clientmods is not an issue so let them, but at least allow servers to decide and protect themselves. MT has always been about the server providing and controlling anything of significance, and servers have always been able to protect themselves and police what happens.

If it is not possible to add the abililty i request then the only thing to do is to not allow client-provided clientmods at all, as i understand it CSM was originally intended to be server-provided mods only, for very good reason.
CSM will then still bring many benefits and server admin will add the reasonable clientmods that players want, but at least it is in a controlled way, it is known what is provided to all players and no-one can gain a secret advantage over anyone else.

@celeron55 please could you consider this issue?

[raymoo]

My ideal solution would be the removal completely of the loading of client-provided client mods, and only allow server-provided client mods.

Otherwise I would support making API functions less useful for cheating. For example, node searches only returning nodes that are in the player's line of sight.

[nerzhul]

@raymoo sorry but removal completely the client side loading is not a solution, better solution would be to control API, we can add rate limit on some calls, or when server sent mods are loaded forbid (if possible) some calls from pure client mods and allow them from sent mods ?

[nerzhul]

another solution would be to make server sending a blacklist of functions which cannot be used on the server or a function group strategy (for example: disallowing map getters, disallowing client formspecs...), this means client installed mods should verify if they are allowed to use some features

[paramat]

removal completely the client side loading is not a solution

Actually, it is a complete solution, what you mean is you don't like the idea.
However i'm not necessarily asking for this.

we can add rate limit on some calls

That's useless, less rapid cheating is still cheating.

Your other suggestions seem potentially good. Many clientside abilities can be considered harmless and can remain unregulated.

The discussions about CSM i have read suggested that there would be the ability as i request here, and i remember someone, possibly @sofar, concerned about this being assured there would be, so what happened? Why isn't this already done or planned?
The original intention was server-sent clientmods only, so how did this get reversed?

Until now i have stayed out of CSM discussion, i prefer to keep out of as much as possible to lessen my workload, and i trusted you would do the right thing, but now i see this huge issue and i am very concerned, more than any issue i can remember, and server admin and moderators should be too.

[ghost]

I love how devs start tyo think about CSM like playsers and server owners do 😄

I hope all of this will lead to more secure and reliable server/client interaction in the future.

[red-001]

ahh good old security by obscurity

[MisterXtreme]

I think Nerzul meant that basically instead of filtering out all, or select mods on requests (not hard to rename a mod), you would be able to have a server side setting, that would allow you to disable the functions that would allow something like oredetect to work, correct me if I'm wrong.

[raymoo]

@red-001 We're not hiding anything, players can look at the source code if they want. Putting limits just increases the barrier to cheating. CSM provides an environment where you don't need to recompile every time you add a new cheat, which makes it easy for random people to take cheat mods distributed by other people and use them. Nobody has ever tried to distribute modular cheats before CSM, though some people have distributed clients with certain cheats compiled in.

This is why I favor just removing client-loading of client mods. People who want to revive client-loaded CSM for cheating would have to either recode CSM or port it from an earlier version, requiring more work than just removing a few lines that restrict the CSM API. Somebody other than official Minetest will have to standardize and maintain the client-provided CSM interface. With "CSM with limits", you can just remove the checks and have a fully-featured CSM system ready for cheating.

I'm glad you had fun dropping a buzzword, though.

[MisterXtreme]

CSM can be used for cheating, and does lower the barrier a lot, but there are many advantages too it as well, such as.

• Ambient music that won't bring the server to It's knees

• Mods that allow you to see things such as block name/desc, status, etc

• More full featured minimap, without bugging the server

• Many, many other things.

[raymoo]

These could be provided by the server, and it might be better that way since the last two of those could be considered cheats by some servers (reveals information that would be hard to get without the client mods). I never said I was against CSM, just client-provided client mods.

The reason I prefer removing the capability to load local mods at all is because otherwise it's too easy to remove the anti-CSM checks from the code. I do recognize that it limits what functionality can be provided by client-loaded client mods, but for me the main value of CSM has always been that the server can provide code to run on the client.

I have seen people suggest that client-loaded CSM is important for UI customization, but what realistic use cases are there that actually require Lua scripting, as opposed to some static format?

[red-001]

horrifying now players can see the location of blocks that they are not suppose to, it's not as if a few lines of c++ code could achieve the same thing.

[nerzhul]

@paramat i think i will remove some mapgen parts as they are not optimal, it's exactly what you propose here: not a solution, just easy solution, i think i can also remove all network code as you can spoof another player peer_id easily and bug himself server side.

[raymoo]

@red-001 I don't know why you're acting like everybody ignored the fact that clients can be modified without CSM. CSM just makes it easier, and makes it so that you do not have to recompile for every cheat you want to use. It especially makes it easy to pick and choose cheats provided by other people. I already said all of this though, so maybe you are ignoring the fact that people have already tried to address the criticism that players could modify their client anyway.

Or maybe you didn't ignore it and thought that a clever-looking remark would be a more effective way to argue?

EDIT: @paramat also addressed client modification in the OP, so don't pretend like everyone arguing for limits was completely ignorant that people can recompile code.

[paramat]

XtremeHacker no-one is doubting the usefullness of CSM.

horrifying now players can see the location of blocks that they are not suppose to, it's not as if a few lines of c++ code could achieve the same thing

This ridiculous argument is being used in a few places, i know a hacked server can do the same, the issue is officially supporting cheating and making it as easy as possible.
Just because a few people can hack a client does not mean we can give up on tryiing to avoid bad behaviour on servers.

How many players know how to hack a client? very very few, and hacked clients would not be allowed on the forum, but now you are officially supporting and encouraging secretive cheating and the mods are being distributed in the forum, and we can do nothing about it because on some servers such an ability may be acceptable.

Remember i am not attacking CSM or even the ability to have client-provided clientmods, just a way for servers to protect themselves if they wish, and they will want to once client behaviour becomes much worse due to these clientmods.

i think i will remove some mapgen parts as they are not optimal, it's exactly what you propose here

No, please don't misrepresent me, above i write that your suggestions have potential, because they would identify the problematic abilities without restricting the harmless ones. And please don't use ridiculous analogies, deal with everything issue by issue.

Come on guys i know you are intelligent and above stupid arguments like this, there's no need to be so defensive.

[VanessaE]

By all means, yes, a server should be able to protect itself in every way possible from malicious CSM mods. Or as I put it on IRC, "in a word? absofuckinglutely."

[paramat]

Support from Ezhh, tenplus1, ExeterDad and VanessaE, all respected server owners (sorry if others are also server owners and i am unaware).

[red-001]

@raymoo no just removing restrictions on CSM mods would be just as hard/easy as making a far faster/better cheat using C++. I don't have anything against allowing servers to restrict certain functions from being used by CSM mods, e.g. find_nodes_in_area

[VanessaE]

Meanwhile, regarding the notion of disabling the client-loading of CSM mods... @nerzhul hinted at the idea, maybe what's needed is to make the client-side API super strict, but only for mods that were loaded directly by the client.

Any mod that's sent by the server should have access to the full CSM API, whatever it might be when that day comes.

[VanessaE]

There's a secondary problem with that idea, though: clients made from dev builds up to and including the latest release would naturally not obey, so those clients need to somehow be kicked off.

This would probably be best done by making some minor network protocol change right before such restrictions go into effect, bumping the network version accordingly, and making strict protocol checking default to 'enabled' on the server.

[raymoo]

@red-001 I am talking about the difficulty from the typical end-user of a cheat, who might not have the skill or motivation to write their own cheat. Everything below assumes that the player is not going to write their own cheat code.

With (unlimited) CSM:

• They have to download the cheat mod(s) and put it in their clientmods directory

With limited client-provided CSM:

• They have to remove a couple lines and recompile the client, or else get such a recompiled client from somebody else.
• They have to download the cheat mod(s) and put it in their clientmods directory

With no client-provided CSM:

• They are forced to download somebody else's sketchy cheat client (I doubt this will stop cheaters though)
• They need to somehow combine (git merge, copy paste, etc.) the codebases of multiple cheat clients if they want the features of all of them
• They need to recompile every time they add / remove a cheat.

There is also a fourth possibility I touched on before, that someone could make a cheat platform that recreates what CSM does right now. This would make it as simple as it is now, except that they have to download an unofficial client. The developer of the client would need to either port current CSM to the newer version that doesn't have client-provided clientmods (more likely), or else code their own CSM (less likely). I feel that such a fork would be less well-maintained, but maybe it would gain traction. But removing client-provided CSM would make it harder to develop such a client, just as it makes it harder to use other people's cheats without CSM.

EDIT: Also thank you for addressing my argument instead of ignoring it.

[raymoo]

Sort of unrelated to what I have been arguing, but for ore detection specifically, I believe it would be possible to make a fairly good server-sided way of hiding ores right now with mods, and server-sided ore hiding would be the best solution if it could be done efficiently in core since it would prevent even modified clients from finding ores, except for ones that the server deems "visible" to the player.

[red-001]

You are over estimating how hard it is to get x-ray, ~3-6 lines of c++ code would be enough to get x-ray, you could just modify the node definitions the server sends, no advance graphics related work or anything just basic data manipulation someone could easily make a patch/diff for that and distribute it.

[sfan5]

You don't seem to get it.

No matter how few lines this is in C++, recompiling (even modifying) the Minetest code is a high enough hurdle for the average player to justify this. Making use of game-breaking cheats as easy as installing mods is not a good idea and will result in more widespread cheating.

[VanessaE]

@red-001, for a coder, sure that's trivial, but for an average user, they wouldn't know how to even open the code in a text editor, let alone modify or compile it. Installing a mod, however, is pretty basic stuff that most users could figure out in just a few minutes.

[raymoo]

@red-001
What CSM gives is the ability to easily use different cheats together, not using one particular cheat.

@sfan5 @VanessaE
For that class of user, simply limiting CSM is enough because that also requires recompilation to get around. But removing client loading of clientmods also makes it harder for the class of users that can mechanically enter commands into the terminal.

[red-001]

@sfan5 @VanessaE I'm arguing for limiting non-server supplied CSM mods, instead of removing client supplied mods.

[nerzhul]

yeah, i'm for limiting CSM API based on a server profile sent to client (allowing node fetching, allowing formspecs, etc). Feature based CSM mods controlled by server, it's better than disallowing a mod by name which is easy to bypass

[MisterXtreme]

(Continuing on Nerzul's last comment)
And a less nuclear solution then just removing CSM, as removing CSM, would be sad, and locking mods being loaded by having the server handle it seems to defeat part of the purpose of CSM, It's _client_ side.

[MisterXtreme]

Also, there are X-ray texture packs, should we cut out all texture pack support?
I don't mean to needle, but a texture pack is easier then a CSM to use, and harder to stop.
Also, is there a way to actually stop X-ray from working at a low level?
Then we wouldn't have to worry about C++ hackers either.

Just some points to ponder.

[raymoo]

@XtremeHacker Ore-hiding on the server side would prevent x-ray packs from finding hidden ore.

[red-001]

I mean you can hide ore on the server-side but that's just asking for a lot of lag. Even removing client-sided chat prediction is noticeable on further away servers/laggier servers.

[raymoo]

@red-001 I feel like it might not be so bad if you make some assumptions of what ore is worth hiding and when, but I think I am getting off-topic from this issue.

[red-001]

I though a bit more about the "disabling client-side mod loading" idea and realized it's basically identical or worse depending on how you implement it security wise compare to just restricting mods since someone could always just added their code to builtin, no need to recompile or anything like that.

[raymoo]

@red-001 I didn't think of that, I guess that is less inconvenient that recompiling the engine. It would still be less convenient to have to modify builtin for each cheat you want to add, though.

[nerzhul]

@red-001 it's why if we want restriction we should have feature based blacklist in core.

[ghost]

Regarding CSM there should not be blacklist but a whitelist.

[nerzhul]

no. there are too many calls and server should not block random calls , just a defined set of features which can be useful to block for gameplay and unmaintained server can have deprecated whitelists which make CSM experience horrible.

[ghost]

and unmaintained server can have deprecated whitelists which make CSM experience horrible

and unmaintained server

unmaintained

And why exactly should anyone care about servers no-one cares about?

Instead of developing stuff for edge cases it would be better to create a rock solid, stable, reliable CSM system that is allowed to execute special things only instead of allowing arbitrary calls and waiting for a blacklist update with the next release leaving a security hole unpatched for a couple of months.

[celeron55]

I 100% agree with @sfan5 on this.

The barriers to cheating we've had until CSM are fine. As long as cheating requires C++ changes, we're pretty much where we've always been. Current CSM is bad.

The design of Minetest is to give all possible control to servers.

[nerzhul]

what is don't understand is why nobody complains or/and tried to fix this before release as the feature is in core since 1 or 2 months.

[ghost]

CSM security and servers protecting against CSM was discussed and criticized over and over again in multiple forum threads and GitHub issues. Other than now back then none of the most influential devs cared so it was not worked on it until now.

[ExeterDad]

That is correct. I started asking questions as soon as oredetect was released.
https://forum.minetest.net/viewtopic.php?t=17046#p258985
Then there was debate in the thread, and all the while "the wonders of CSM" was all we heard about instead of what server owners could do to block alarming CSM mods.

[nerzhul]

i started #5930

[Wuzzy2]

Lol, now that this feature is in official release, NOW you are starting to seriously discuss “possible downsides”? OMG.

Stop accusing us of not caring about this feature before release. I started to ask questions in the forum as soon as October 2016 (!):
https://forum.minetest.net/viewtopic.php?f=3&t=15803

In 2016, I was already skeptical. Quote from November 2016:

I also opine that client-sided scripting should not be introduced lightly, because this would be a major design change. I would also say that the modding community should have a say in this.

and

I would be glad if some core dev could step up here and maybe tell us more about the idea. Maybe I have an incorrect understanding of the idea (not much is known about it). Maybe someone already has a more specific design or something. That would be interesting to know.

Sadly, this thread was ignored or simply not seen by core devs. :-(

Later I opened a poll:
https://forum.minetest.net/viewtopic.php?f=47&t=17074

Much later I posted in the new client mods forum, but it was already too late at this point, I guess. My point is, there was definitely discussion long before this feature was even implemented.

But I hope you can understand that I am just a little bit pissed off right now. :D

---

Now for my thoughts today:
I doubt the claims that client-sided modding is really _that_ useful in the first place. You cite examples such as:

Ambient music that won't bring the server to It's knees

Mods that allow you to see things such as block name/desc, status, etc

More full featured minimap, without bugging the server

Many, many other things.

All of this sounds like it could be done just by improving the C++ code and the network protocol. These are all very basic features. I have yet to see any compelling use case for client-sided modding, one that would be impossible or just too painful and/or senseless to do in C++, and which does not involve cheating.

Also, all these cool features are only available to those who actually bother installing the client mods in the first place. That's bad usability, I don't like that users have to download tons of mods first to get core features such as ambient sounds/music. It's bad enough that the default subgame is incomplete _by design_, now it seems this “principle” is applied to Minetest, too. :-(

But the other thing I don't really like about this is that with client-sided modding, the only thing you did is to move the responsibility to implement core features to the moding community. But the actual problems client-sided modding claims to solve are not actually solved yet. The more and more responsibility you move to the modder, the “dumber” the engine becomes. I don't like this direction.

I fail to see the real benefits of client-sided modding since I ever heard of this idea, and I was skeptical. Now thanks to paramat's post, I definitely see the downsides of client-sided modding now. Now I'm opposed, as I only see downsides, but no compelling upside.

It is kind of ironic that the first ever clientmod is oredetect, a massive cheating tool. :D

And I agree with paramat. The point is not that cheating was possible before, the point is now that with this feature, cheating can be seen as an officially-sanctioned and supported feature. This is the completely wrong message.

[nerzhul]

@Wuzzy2 don't forget github is the main platform to discuss about dev with IRC if you are not on them it's more difficult for us.

For the point you mention, install tons of mods to have a decent experience i hope this will never happen, the CSM is not intended to defer all features or client core to API, it's extension to current core, we will never remove those features from core , or move them to builtin if justified (minetest client should never be a Lua game, but a real engine with high levle API). Talking for myself i don't want modders to do our work, but modders can extend current client (which doesn't move very fast) and some mods can permit to see new interesting features, meaning new API to implement with new extension model etc... CSM or SSM should have this model, mods to extend, we take interesting commonly used features enhance and permit your to extend another time (i talk in my name here)

Actually CSM is a preview it's not the final, it just offer basic interactions with env & formspecs, it permits to reduce lag for example by having some pure client side formspec (for example craftguide), this permit to remove the lag and CPU usage on servers. A craft guide with SSM means on each button click you wait for server to update, with CSM you use already known data and it's very fast because we don't use server

To conclude, i agree with you somes are doing a nice streisand effect by complaining publicly about this on all communication vectors which can only trigger more cheat.

[Wuzzy2]

@Wuzzy2 don't forget github is the main platform to discuss about dev with IRC if you are not on them it's more difficult for us.

Well, maybe I did not know at the time that core devs mostly ignore the forums. :-( I think it is more or less an open secret? :D But even then:

What I criticize here is that you apparently did not actively consult the modding community beforehand. You're not the only hard-working developers around here. :-) What's the point of adding an API when it won't be largely accepted by the community at the end?
If I see correctly, this feature was largely developed without consultation of the modding community. There was not a single announcement in the forums, even by now. Even now I do not really understand all of is. The “official documentation” is very incomplete. Now if you say it's only a preview, that does not make it better. I still do not know where this feature is supposed to be heading to.

And it was obvious from the start that this feature will be a big change. How on Earth could you not at ask the modding community for input beforehand? :-(

A craft guide with SSM means on each button click you wait for server to update, with CSM you use already known data and it's very fast because we don't use server

First of all, I consider a crafting guide to be a core feature, because if you don't know the recipes, the game is unplayable as you can't even get a torch or pickaxe.
Second, this still requires the user to install this mod manually before joining the server. I also don't really understand how a single client mod should work across multiple subgames in multiple servers which may have very different crafting systems. Such a mod would either just work with particular servers (to keep it simple), which means the user has to install multiple of these mods, or it would try to cover all possible use cases and be very bloated. Neither solution does not sound very good to me. This idea doesn't seem to be very well thought through.

To conclude, i agree with you somes are doing a nice streisand effect by complaining publicly about this on all communication vectors which can only trigger more cheat.

Oh come on! Give me a break. Now you are accusing me of motivating cheaters? It was not me who introduced client-sided modding or the oredetect mod. The cheating capability of oredetect is obvious, you do not need Streisand. Had those never been implemented, we would not have this discussion.

[nerzhul]

@Wuzzy2 like all core devs and many of us in community we are all doing that on free time and we don't have a community management process which permit to report needs and bugs from forum. When CSM appeared we added CSM part on forum, i go to there sometimes but not many times as minetest is not my only project.
The CSM part was managed over some months, first we started with no real calls, and we added more and more calls, @bigfoot547 and @red-001 are the main contributors with me. We discussed about CSM on IRC because it's easier to discuss about that, and each implemented feature was a PR discussed by some core devs and some community members, especially on minetest-hub, but some community problems tend to have limited sane communication in project due to a problem with some people on IRC (outside of MT coreteam).

For the craft guide it depend on the gameplay, you can make minetest a hardcore game when you should discover recipes like some RPG :)

And no i don't talk about you, you are moderated, i talk about some other people.

EDIT: now we should find solutions for enhancing it, as we always said, CSM in 0.4.16 is experimental and can move. We are working on solutions to reduce node scans but solutions requires some consensus between dev and community members. if you want to participate and be informed actively, just join #minetest-hub on freenode

[Desour]

It is kind of ironic that the first ever clientmod is oredetect, a massive cheating tool. :D

Actually the first csm was csm-inspect.
I never thought that something like get_node_near would ever be added. But as it was, I couldn't hold me back making a csm using it. I think, maybe I thought that when it's seen that this function is cheaty, it will be removed again, but (happily?) no.

[stujones11]

The oredetect mod does nothing that could not already be done (possibly better) using a custom texture pack, I really do not understand why so much fuss is being made over that and the formspec problems were mostly down to sloppy mods. IMO current CSM merely provides a level playing field for everyone, however, I do agree that future additions to CSM need to be more carefully thought through and discussed with server ops.

[ghost]

The oredetect mod does nothing that could not already be done (possibly better) using a custom texture pack

Prove that statement.

[MisterXtreme]

https://forum.minetest.net/viewtopic.php?f=4&t=17688
Easy

[ghost]

Okay, and this shows WHAT exactly? Except darkness and the outlines of nodes that are exposed to air and are in theoretical sight?

[MisterXtreme]

You can see ore outlines in the screenshot, to the left, upper middle, lower middle, etc.

[ghost]

Okay, it does not tell me anything about the node and I probably was there already. Usually it looks like this.

For the first screenshot I turned around and looked up and down until I found an angle where something is visible at all.

[Ezhh]

A cheat being possible one way doesn't mean it's fine to make it possible another way.

[stujones11]

A cheat being possible one way doesn't mean it's fine to make it possible another way.

To me it seems pointless preventing it one way when it is so easily doable another way, unless of course you also make it possible for servers to block client-side texture packs.

[paramat]

sfan5 i don't think a feature blacklist is a good idea
what if someone wants to use an ambience CSM mod? wouldn't work without get_node

That's just too bad, ambience mods are somehting that should be provided by the server, because they strongly determine the atmosphere of a world. Having each client choosing it's own ambience mod is weird and unnecessary.

sfan5 e.g. only allow get_node (+ related funcs) withhin player interaction range and only for nodes that have a non-solid neighbor

That's no solution, being able to 'see' through solid objects to a distance of 4 nodes is also cheating and is just as bad.

red-NaN I would suggest only limiting functions for getting large numbers of nodes
get_node is too slow to be useful for cheating
at least not in any useful way I can think of

Wrong, it's fairly fast for a small radius, possibly faster than bulk node data, and a small radius detection (4 nodes) is still cheating and changes the whole concept of a game where there are solid objects you cannot see through.

All node getters need to be disableable by the server.

[paramat]

XtremeHacker

And a less nuclear solution then just removing CSM, as removing CSM, would be sad, and locking mods being loaded by having the server handle it seems to defeat part of the purpose of CSM, It's client side.

No-one is suggesting removing all CSM.
'clientside' does not mean client-provided clientmods, the original intention of CSM was server-provided clientmods only. 'clientside' means a mod running clientside.

[paramat]

nerzhul

what is don't understand is why nobody complains or/and tried to fix this before release as the feature is in core since 1 or 2 months.

I read discussions about this and was not worried because i got the impression that either:

1. Client provided clientmods were not going to be allowed at all (personally i still wish this was the case).
2. The server still has the option of absolute control over allowing clients to provide mods.

I stopped following development because i trusted those working on it. Then at some point stuff went off the rails.

[Wuzzy2]

@paramat: I agree (3 posts ago), but how? This sounds like the issue lies much deeper here.

The cheats just presented here all fall into the same category: Information gathering.
They display information to the player which the player is not supposed to see. But it is possible anyway because the client knows the information.
Basically, the whole cheat relies on the fact that the client already knows it. So all the cheater needs to do is to extract the information (which he/she already has, technically).

The obvious solution to these type of cheats is that the server gives fewer information to the client in the first place. This is definitely possible to some extent (see metadata hiding), but I fear if we go this path, this probably creates a whole bunch of other problems in the long run; I guess it makes client prediction much harder, and the network protocol is doomed to be less efficient as well.

So even without client-sided modding, we still have X-ray texture packs which are almost criminally easy to use. :D That of course is not an excuse for enabling the same thing via client scripting. Two wrongs don't equal one right.

Well, I suddenly realized that the problem outlined by paramat is not easy, there's no easy solution. :-(

[bigfoot547]

I think that this issue should be renamed as the server is not being attacked per se, thus it requites nonprotection. If this gets implimented, that is when I tell my client to ignore the server packet telling me what to do.

[paramat]

stujones11

To me it seems pointless preventing it one way when it is so easily doable another way, unless of course you also make it possible for servers to block client-side texture packs.

That may be necessary too.
EDIT: Sorry, not necessary, see below.

[paramat]

I write 'protect' to only refer to clientmods that introduce cheats or anything that harms a server.

If this gets implimented, that is when I tell my client to ignore the server packet telling me what to do.

Then you will become a hacker that disrespects servers, no-one will respect you.

[bigfoot547]

no-one will respect you.

That's not _my_ problem.

[red-001]

disallowing client-side mod loading is not technically feasible as I outlined before. We will just end up with a lose-lose situation for everyone.

[red-001]

stujones11

To me it seems pointless preventing it one way when it is so easily doable another way, >>unless of course you also make it possible for servers to block client-side texture packs.

That may be necessary too.

Don't be ridicules, we haven't removed chat yet, even through you can use it to spam, etc

[bigfoot547]

Don't give him any ideas! :smile:

[paramat]

That's not my problem.

It might be if you are banned from servers and treated as a troublemaking hacker.

That may be necessary too.

Sorry, that was not a good suggestion, and not really needed. I have tested the xray texture pack and it is not partcularly useful, and we can address this by dealing with the ability to make the sky bright underground.

When a player has no priviledges they can still enable 'fly' and 'noclip' to make the sky bright underground (this may have to be changed), this enables seeing caves and only the ores that are bordering air, not ores buried in stone. The ores bordering air would likely be found anyway when exploring the caves. So xray texture packs are not a big issue and not as powerful as an ore detection mod.

So now you can't use the argument that there's no point in avoiding cheating because it's possible already. Also, that argument is about one clientmod only, this issue is about clientmods in general and the many clientmods that will appear using various ways to cheat or disrespect a server.

[raymoo]

@bigfoot547 I'm guessing you already remove movement priv checks so that you can noclip around anyone's server?

[paramat]

I opened #5939 to deal with bright skybox underground which allows cheating with an x-ray texture pack. This issue actually came up before in https://github.com/minetest/minetest/pull/4646#issuecomment-254308732
Bright skybox enables cheating with a normal texture pack too so needs addressing.

[stujones11]

I am glad the x-ray texture packs turn out to be less powerful than I thought, TBH, I have not tried either method and my statements were mostly based on screenshots and things I have read in the past. Personally I have no objection to servers being able to disallow client-mods either partially or completely, however, this will never stop dedicated cheaters.

[bigfoot547]

I'm guessing you already remove movement priv checks so that you can noclip around anyone's server?

I may have made a hacked client, but I don't use it, except for on my own servers. Wait, who are you to call me out, @raymoo?! I'm not the only one who does this, anyway.

[raymoo]

If CSM blocking of some kind gets in, disabling it is the same cheatiness as disabling movement privilege checks.

I think using it on your own server would be fine, that might even be a good feature suggestion (player-specific restrictions).

[Ezhh]

So I've now had people spamming chat with autoresponders, and people intentionally obscuring their chat by typing in black... Locating ore more easily is just one of the issues.

[paramat]

I suspect this will be such a big issue we will need a point release after this is sorted out.
Any client-provided clientmod that affects chat on a server in any way needs to be a 'flavour' that is blockable.

[raymoo]

Spam and chat color though can be enforced by the server.

[nerzhul]

See #5930 for flavours, we should find a good flavour model for node and mapblock reading

[ExeterDad]

Chat colors are used serverside on our server to show when a player is mentioned, also when PM'd. This was our solution to assist people to catch chat directed to them before it zips by. As our chat moves very fast. But now that CSM color chat is "injected" for all to see, it's more confusing than before. I don't like that my chat logs are not readable as the color strings encapsulating every single letter of the rainbow chat is present. Chat logs are important clues in debugging or knowing what goes on.
I'm frustrated that when all the "pro CSM" folks were talking about all the benefits of CSM, and promising that CSM would not send anything to the server, they didn't consider that chat was indeed sending to the server and and indeed changing the experience of my players and I can't find a way around it currently.
There are many players that for whatever reason can not upgrade Minetest and have clients old enough that they can't handle the escapes needed for color. I got around that with the server side colors by giving them a checkbox so they can see formatted or unformulated text. Not a problem as the chat was filtered and resent out by me. But now since my settings don't work with CSM, my players see garbage.
I know I'm sniveling about something that doesn't seem like a big issue. But I pay the bills for the server. It's time spent from my family. It's the commitment to my players. And I want control.

[red-001]

@ExeterDad #5948, I'm planning to fix the issue with colour codes being sent to old clients soon. It should have never been implemented in that way.

[ExeterDad]

@red-001 I'm glad you are able to improve your mod. But that's because you can, and will I'm sure. But how's that going to help us server owners against players that aren't using your mod? The point is... anyone can do what they want with whatever mod they decide to write or download on my server. And I can't do a damn thing about it.

[red-001]

@ExeterDad the PR I referenced adds a way to make minetest remove colours from incoming messages something that will directly break my mod and any clone of it if the server owner wants to. It also removes colour codes before logging the messages in-case some server owners want to allow users to use colours. And finally old clients being sent colour codes is an issue with minetest and not any mod and should be trivial to fix. I see it as a bug since it breaks backwards compatibility for no good reason.

[ExeterDad]

@red-001 I was editing my last response as you posted. I noticed your fix was not with your mod, but serverside. My apologies.
Thank you :)

[red-001]

@ExeterDad are you by any chance the owner of the "Hometown" server? If some it might be of interest to you that there is a way to check the client protocol version now and so you can replace the "fix chat" checkbox with just checking that. Sorry for hijacking the topic.

[octacian]

Well, couldn't the issue with oredetect caused by find_node_near be best solved by limiting the nodes that it can detect to those in line_of_sight? Implementing something like that would IMO be a better fix than just outright allowing the server to entirely prevent features like that, though I wouldn't complain if both options were available.

And when it comes to all the chat colours, the best solution for this is to allow the server to strip colours from chat either on_chat_message or via a setting.

[rubenwardy]

CSM's send_chat_message should be removed. I don't see any usecase for it that wouldn't be better implemented using communication channels, which the server can control.

However, the server should validate chat messages when it receives them to remove any colors, which I understand has now been worked on. The server should ultimately be in control, and should validate client packets.

I agree with celeron55 in that the current CSM is bad. The only use of CSM should be client-side prediction for server side mods, and audiovisual effects such as allowing server mods to make nicer GUIs, etc. Client provided scripts are a misfeature.

For me, Minetest is about the subgames. The power of Minetest is being able to make your own game, as a collective experience. Clients shouldn't be able to change the gameplay.

[red-001]

sending chatcommands? that seems like a pretty valid usecase.

[rubenwardy]

sending chatcommands? that seems like a pretty valid usecase.

How can that be used for client side prediction, or for audiovisual effects? If a server mod wanted to make a fancy GUI for kicking players, they would also make a channel to let the mod communicate back

[raymoo]

You could use it to implement chat macros. Like .slap c55 => singleplayer slaps c55

[mnh48]

^ agree with above, things like...

.afk [reason] ==> /me is now afk [for reason]
.exit [#] [reason] ==> /me is exiting [in # minutes] [for reason]

[Ezhh]

Though such a thing could have valid uses, it could also be used as an easy way to spam.

[bigfoot547]

@Ezhh how?
To spam, all you have todo is hold a key down for 10 seconds in the F10 chat terminal, send, then spam up and enter.

[Ezhh]

The spam that bothers me isn't just holding a key down, and quite honestly I'd rather they need to type it instead of being able to set it up on commands.

[MisterXtreme]

Anti spam mods server side, that prevent the client from sending large amounts of text, at least, that should be possible.

[nerzhul]

There is already antispam in core for server side, it's just... not documented, my bad.
Look at https://github.com/minetest/minetest/blob/master/src/defaultsettings.cpp#L304

[paramat]

Related issue #5974

[paramat]

Well, couldn't the issue with oredetect caused by find_node_near be best solved by limiting the nodes that it can detect to those in line_of_sight?

Seems pointless as you would see it, or if you don't, it's still a cheat because you can then find ores hiding in darkness. Also complex to code and intensive.

[paramat]

CSM's send_chat_message should be removed.

The spam that bothers me isn't just holding a key down, and quite honestly I'd rather they need to type it instead of being able to set it up on commands.

'send_chat_message' needs to be added to those functions considered potentially harmful, so included in the flavours PR as something disableable.
Example mod https://forum.minetest.net/viewtopic.php?f=53&t=17827 [Clientmod] say automatically hi to everybody [hi]
Automated-chat mods will be used and will be irritating on a server, even if they do not trigger the flood protections. Weird bot talk can be irritating without flooding, if a player tries to flood at least they have to actually type.

[paramat]

'send_chat_message' needs to be added to those functions considered potentially harmful, so included in the flavours PR as something disableable.

Sorry, this is already in the PR.

[LazyJ]

I don't like the idea of server provided CSMs. Why should I trust the server isn't sending a CSM to do stuff to my computer through my Minetest client? It's like the WorldEdit incident of a few weeks ago, only the reverse.

I remember reading a dev saying that the benefits of CSM outweigh the risks. That indicates the devs were already aware of risks and still went through with releasing CSM. MT 0.4.16 is released as a "stable" release yet nerzul says CSM isn't stable yet? Then why release CSM in a so-called "stable" release?

As yet, the benefits of CSM have only been described in vague, theoretical terms and are currently non-existent while the cheating and annoying CSMs were among the first CSMs to be made and are exacerbating long-standing problems (x-ray, spamming).

The potential audiovisual benefits seem to be things that should be settings that can be toggled in the client like the clouds, fanciness of leaves, smooth lighting, etc. Clients already download the sounds and images from the server, why not let the clients determine what of those to use and to what degree? Settings like "Full", "Basic", "None" for sounds and visual effects. The burden would still be taken off of the server and put on to the client with the player having the choice of balancing eye and ear candy with performance. If players want to hear custom sounds, then the ability to load custom sound packs, audio companions to texture packs, should have been added to MT instead of CSM.

CSMs were to take some of the burden off of the server, but now server-ops, modders, and devs who are conscious of the problems CSMs pose, have to come up with methods and mods to counter CSM, causing extra burdens put on the servers and the maintainers of such counter mods - like hiding ores from the client until exposed to the air or yet another set of procedures and/or mods for blocking or pacing the chat of spammers.

[raymoo]

@LazyJ The CSMs that were meant to take a burden off the server are server-provided ones, not client-provided ones. All of the problems people are complaining about right now are due to client-provided CSMs (and anyway server-provided CSM doesn't exist to complain about yet).

The WorldEdit incident was due to giving bad access to an unsandboxed Lua environment. There are other mods like Mesecons that give players a restricted Lua environment to run their code in, and there have been no security incidents with it that I know of, at least since its current sandboxed environment. Server-provided CSMs would have to run in such a restricted environment.

I do not like client-provided CSMs very much, but I believe server-provided CSMs would be very good in several areas. I will try to be specific and concrete, and give examples to avoid the vagueness you have experienced.

• Custom mod UI: If server-provided code can run on the client, then the server can create user interfaces with custom behaviors, rather than being limited to whatever is coded in the engine (currently formspecs and items). For example, you might want to code "spell selection" UI where you hold your mouse and drag it in some direction to select whatever spell icon is in that direction. Without CSM, this would require special engine code implementing this kind of selector. With CSM, the engine would just need to provide a way for server-provided client mods to get the mouse position, draw HUD elements, and deactivate the mousegrab used in normal non-formspec control
• Responsive mod UI: Currently any player actions need go through the server to have any response on the client, except digging and building prediction. If a formspec has to go through several parts of a menu before having any effect, a mod could do everything until the effectful action client-side, and then send a message to the server when it should be executed. An example could be a "pet designer" dialog, where you can design a pet's appearance and qualities through a bunch of menus. Without CSM, every step of design has to go through the server, slowing the player down in case of large lag and unnecessarily consuming bandwidth. With CSM, messages only need to be sent to the server when the player wants to spawn a pet.
  
  
  
  • An example in the other direction is the animation of a magic bar, such as in the mana mod. Without CSM, the server currently needs to send an HUD update for every tick of the mana for a smooth animation. With CSM, the server could send the client updates less frequently and the client code could interpolate the bar length.
  
  
• Key input: This is sort of part of the last two points. In case we want keyboard input, or maybe some Android-compatible abstraction over keyboard input, it would be expensive to send all key events to the server or constantly send key state updates like is currently done with player control bits. Client-side handling of key events would mean messages only get sent to the server when something is actually an action, and that action needs the server to do something.

UI is where I feel the benefits of CSM are the strongest. There might be some other useful areas though:

• Entity movement prediction: You could make it possible for mods to define a custom movement model for particular entities, using Lua to step the simulation. For instance, you could write code that moves minecarts on the client side along rails, so that it does not fly off the rails when the server is lagging. This would need some way to communicate updates to the minecart's state from the server to the client, though
• Player movement: You could have non-laggy code that affects players movement. For example, you could accelerate players in flowing liquid in the direction of the flow.

[nerzhul]

for the entity movement & prediction it's not a CSM issue, ti's a protocol/entity issue, entity should send to client what is their next movement action instead of sending raw movement vectors, permitting each client to correctly handle event.
For example: entity:move_to(x,y,z)

[Wuzzy2]

I oppose the very idea of “server-provided scripts”. I can not trust the server not to send me malware which the client then blindly and happily executes without warning. It would be terrible if a player could catch malware just for visiting the “wrong” server.
And not too happy with the “just sandbox it” argument either. Minetest still has access to the full Lua scripting engine. If there is a bug in the sandbox which allows a script to break free of the sandbox, the sandboxing is worthless. This is not a theoretical risk, it frequently happened in other software that the sandbox was made worthless by a bug.

I agree that current UI and entity prediction it obviously inefficient because it talks with the server too much. But I doubt that client-scripting is the only possible solution to that problem. Nerzhul already explained that for entities.

[red-001]

So to make it clear you are against allowing player-provided scripts to be able to do anything useful but also against allowing servers to provide the scripts.

[Wuzzy2]

Server-provided client scripts: Opposed.
Client-provided client scripts: More or less opposed, at least in the way it is implemented right now and the use cases for this are dubious and none of the problems listed so far sounds like it could be only be solved by scripting.

But to client scripts in general, I am also not very happy with the direction in general. It really doesn't look like the silver bullet many people claim it to be. I try to avoid the complexity to explode. Less code is good. I don't like the tendency of moving the responsibility to implement core features to the modders.

[nerzhul]

maybe server provided script should use a minetest "mod store" server ask client to download some mods from modstore which are referenced and known, reviewable by community.

[raymoo]

Well nothing needs scripts to be solved, you can just implement everything that would have been a mod in the engine.

[VanessaE]

I am vehemently opposed to client-side mods that actually interact with the server. If the mod merely reacts to stuff the server's telling it, and not sending any kind of events back to the server (even chat messages), that's fine.

Server-provided CSM mods, I absolutely support, and they're literally no different than javascript being sent by a website. Just because browsers have a tendency to make stupid decisions regarding what an incoming script can do on the client machine, doesn't mean Minetest has to make the same mistakes.

[rubenwardy]

I agree, the only way a client mod should send events is using mod channels which a server has absolute control over.

However, CSM being able to submit formspecs has been good IMO - it has exposed lots of security holes with formspec validation, and is making mods more secure. As an API however, not sure how warranted it is

[red-001]

@rubenwardy CSM does not summit formspecs to the server, it uses the local formspec handler that's also used by the pause/escape menu. The fact that inventories can be modified should be seen as a bug and not a feature or at most an unintended feature since it happened only because no-one realized that inventory actions are not sent through the formspec handler like you would expect but through some other system.

[nerzhul]

yeah local formspec are... purely local but it permits to send formspec events to server yes, and when the CSM will be fairly complete server owner should think server is a API receptacle and formspec should run mainly on clients to have the best user experience. I rage many times on unified_inventory formspec which is slow due to big lua code on each click which is affected by server lag

[rubenwardy]

It can show formspecs which are then submitted to the server, so has the same affect

[nerzhul]

yes, it's like it's done in every correct game like world of warcraft, starcraft, path of exile and more. Server should be an api endpoint not run the GUI

[paramat]

In #5930 "[WIP] [CSM] Add flavour limits controlled by server"
The restrictions are currently disabled by default, so i have -1'd, what are other's opinions on that?
I'm concerned about the continuing resistance to doing what obviously needs to be done, this is how we got into this mess in the first place.

[nerzhul]

if you -1 my pr it's because you don't support the feature added with the PR. If you want it to be merged and an option modified, just use the review process else stop that or i will stop to try finding good solutions and consensus for everyone.

[paramat]

No a -1 means 'i disapprove of the PR as it is', it's a common usage of -1.

[nerzhul]

then just use the review process and comment code like every review do and stop -1 the pr, please.

[paramat]

if you -1 my pr it's because you don't support the feature added with the PR.

Not necessarily, -1s are often used by devs to say 'i disapprove the implementation as it curretly is', they do not mean 'this feature should not be merged in any implementation'.

I am using the review process.
I'm commenting in the thread instead of a line comment, this is common and acceptable. However i will add a line comment.

[paramat]

An issue and request first opened in #5974 see that issue for previous discussion

//////////////////////

As i understand it, some functions are essential for CSM to work, in the following i am not referring to these.
I propose that the CSM 'flavours' restrictions allow all (non-essential) CSM functions to be disabled even if they are currently not considered potentially harmful to a server, the restrictions PR currently does not seem to do this.

1. It's not easy to judge which functions are potentially harmful to a server. In the future it is likely that a function currently considered harmless will be used in a way we didn't forsee. In this situation a server will have no way to avoid the disruption and would have to wait for a PR that adds that function to those considered potentially harmful, this would take a few days.
2. Some CSM functions that are genuinely harmless towards the server still change the player's experience. Occasionally a server may wish that the players have a similar experience or not use harmless CSM for other reasons. I expect this will rarely be done though.

[tenplus1]

Disable CSM (all flavours) by default and also provide a server side setting to disable completely.

[paramat]

5797 '[CSM] Add function to set the FOV of the local player' is related and currently has no restrictions. We already have a zoom priviledge for good reason, and #5797 will need some kind of restriction.

We are wondering whether it is best to restrict using the existing zoom priviledge or using the CSM flavours PR?
Altering FOV allows a telescope type view of distant world that shows details that would not normally be visible.

[Ezhh]

For FOV:
If I don't want players to have zoom functionality , I'd rather only need to worry about it in one place, so a priv seems to make most sense, but I don't know if others will agree. or if there is a good argument to do it differently.

I am curious why CSM needs to be able to set FOV at all as well. (This isn't a "please don't add it", as such, but since some of these CSM PRs don't have descriptions or state their purpose/use cases, it can be a bit hard to see the point, and makes seeing only negatives much easier).

[paramat]

The FOV PR now limits the range of normal FOV to a minimum of 30, so the zoom priviledge will still be needed to switch to zoom FOV to gain an advantage. So now that PR doesn't need any additional restrictions.

[Elinvention]

I think Minetest should become more like web browsers/web servers... https://github.com/minetest/minetest/pull/3391#issuecomment-168313861. The server tells the client what to do, but the client may act differently. There are two reasons for this: the client tries to cheat or the server sent a malware. So, they don't trust each other.

Now go crash your pc with this js (if your driver is dumb like mine): https://www.khronos.org/registry/webgl/conformance-suites/1.0.0/extra/lots-of-polys-example.html 😄

[red-001]

of course the client can't trust the code that has been sent to it. The main issue is that even if we remove functions that could be used to attack the client there is still the risk of someone finding an exploit in the lua interpreter or the luajit compiler itself.

[mnh48]

Now go crash your pc with this js (if your driver is dumb like mine): https://www.khronos.org/registry/webgl/conformance-suites/1.0.0/extra/lots-of-polys-example.html 😄

so the js only can crash pc? I only get this on my phone:

---

On-topic:
I would suggest enable CSM (essentials only) by default instead of what TenPlus1 suggested to disable all CSM... but still, provide a server side setting to disable completely, disable in certain flavours or enable all flavours.

[JustinLaw64]

An analogy could be a web browser and server. The browser assumes the server may be malicious or uncooperative and the server assumes the browser could be malicious or uncooperative.

A web browser may have an ad blocker in place, which as the name says, blocks advertisements. This is one sort of uncooperative client, as it prevents the people running the site from earning money. Some websites may counter this by checking to see if the ads are there, if they aren't, they won't allow the client to see the content until the ads are unblocked.

Also, let's say a web-page accepts an ID of a forum, and the server concatenates this inside of an SQL command. If a check or conversion to integer is not in place, an attacker may exploit this concatenation to add more SQL commands. Perhaps to delete every post and topic inside a forum.

A server also may attempt to exploit a vulnerability in the browser to execute a payload that infects the computer, although I know very little on this side of things.

The point being, a server should not assume it has total control over a client and likewise, as this proposal functions merely as a deterrent. Maybe the deterrent is enough to scare away most people as they generally do not know how to compile c++ code, and a deterrent enough for me too as I hate running code intended to hack, from unknown people. However, just one hacking person can still ruin a server for everybody.

[Elinvention]

so the js only can crash pc?

@MuhdNurHidayat there are many examples: https://encrypted.google.com/search?hl=it&q=webgl+hard+freeze.

---

Let me say that in other words. One day, someone will be very very bored. That day he/she/it will take Minetest source code (remember it's open source, you can't hide "secrets" as they do on proprietary games), remove stupid protections from source code, release on GitHub and wait for havoc... wait you have already done that yourselves! Now he/she/it just needs a repo with some reverted commit...

What you can do is hardening the server where you can, not sending informations to client that it shouldn't know, some simple detections (I think there are already some of these)...

Unfortunately it seems the more you try to enforce anti-cheat, the more it becomes unpractical. You can't be sure no one is cheating without making the game unplayable. This discussion might be relevant: https://www.gamedev.net/forums/topic/368086-open-source-and-anti-cheat/.

[paramat]

CSM seems like a Pandora's Box, i somewhat feel like it should never have been opened. But it seems unreasonable to ask for it to be removed completely, so it seems an unclosable box. We just have to be very careful, add as many protections as possible, and maintain server's absolute power.

One problem is that server-provided clientmods seems the best usage, but that has security issues and it is still unsure whether this will ever happen.

With client-provided clientmods, the cheat issues mean that some functions will need to be restricted, but those same functions are often the ones which make CSM the most useful (like detecting nearby nodes for an ambience mod). We can assume that most servers will disable everything that can be restricted, or if they do not they will be forced to due to the cheating.

But then the harmless CSM functions that are left seem to be client-only things that could be provided in engine code. I haven't seen any harmless client-provided clientmods that seem to justify CSM, that is, justify considering the problems caused.

(Offtopic: Elinvention i like your avatar, looks to me like an alien with a degree).

[nerzhul]

@paramat it's why we should advance step by step, restricting current mods is the priority. Server sent mods can only happen if this case is solved

[ghost]

But it seems unreasonable to ask for it to be removed completely […]

Remove it completely and then re-think, re-code and re-add it as a proper implementation with maximum security. It’s not too late yet.

[JustinLaw64]

I'm not sure. Which is easier? Putting a watchdog on the client or putting a watchdog on the server? Besides, modern Minetest clients already know where everything is within a certain range. They just generally don't show the player. It's like one giving a lock-box that is, well, locked to his neighbor who is a stranger to him. He intends to give him a key upon fulfilling a certain condition, but he's hacked the lock instead to get inside.

[paramat]

My last comment was a little too negative.

I'm not sure removing and rethinking will make it better, the issues seem inherent to CSM and not a case of the implementation. The actual issues seem to be that the restrictions are being added late, and that the only way to stop old clients avoiding the restrictions is to break compatibility, which is what 0.5 or our next point release will do.

[paramat]

This is interesting. I see that CSM is a major feature in the dev TODO list, and has it's own page http://dev.minetest.net/Client_scripting_plans
The general design section is as follows, and has no mention of client-provided clientmods, it describes server-provided clientmods only:

////////////

" General design

The language will be plaintext lua (no bytecode, as it's insecure and against the open source nature of minetest). There won't be any restrictions on mod licenses though.

The general design should be much like the Web browser-JavaScript relationship. During the connection, the server sends all code that should be executed to the client, which runs it inside a locked down sandbox. Unlike with server mods, there will be no way (without changing C++ source code) to execute code outside of that sandbox.

Unlike with Web browsers, Lua code should run in a separate thread. Also, to be completely separate, it shouldn't share the Lua environment with the mainmenu Lua (to forestall intra-environment exploits).

Base execution setup

Every server mod can have a directory "client" whose content will be sent to the client upon connection. After all files have been recieved, the client executes an "init.lua" file for every of those mods.

To emphase the short-lived-ness of the code, the client shouldn't give any access to the filesystem. This implies that all lua files should be held in memory. There can be caches (even permanent ones, like with the texture cache), but lua code shouldn't be abled to "just access the filesystem", not even subdirectories."

/////////////

How close is our implementation to this? Especially:
"Lua code should run in a separate thread. Also, to be completely separate, it shouldn't share the Lua environment with the mainmenu Lua (to forestall intra-environment exploits)."

Perhaps this shows that client-provided clientmods were never planned, maybe due to the issues they cause?
@celeron55 any thoughts on this?

[Wuzzy2]

There won't be any restrictions on mod licenses though.

The general design should be much like the Web browser-JavaScript relationship. During the connection, the server sends all code that should be executed to the client, which runs it inside a locked down sandbox.

Add 1 and 1 together and this means users end up “accidentally” with proprietary code simply because they connected to random servers. And worst of all: Users may not even be aware of this.
This is not good.

If this happens, I jump ship. I think this is unacceptable for a free software project. If a free software attempts to “sneak in” proprietary code, its a very questionable practice. We have to be dead serious about the user freedom, otherwise the whole premise of this project is dead.

[rubenwardy]

The client should download the mods from an mod store, for security reasons.
The users should get a warning if the server requests that they use proprietary mods, and have to opt-in to using them.

[ghost]

First the disaster with releasing a version without any proper CSM security, and now the plans for CSM say that server owners are legally allowed to add proprietary blobs that are executed by the client without the use not even knowing?

Wow. First I thought adding a giant security hole on purpose was just devs being routine-blinded. But now as they add blinking giant billboards leading the way on how to spread potential malware … holy fucking fuck please stop ruining Minetest.

[JustinLaw64]

How about requiring that mods sent to the client have a LICENSE file in them and caching them in the same way that textures are cached?

That way a guest can get to the code being sent from the server.

Nevermind. cache/media looks like a pile of encrypted names without any meaningful identification whatsoever.

_(deleted some comments to remove multiple comments in a row ~rubenwardy)_

[rubenwardy]

First the disaster with releasing a version without any proper CSM security, and now the plans for CSM say that server owners are legally allowed to add proprietary blobs that are executed by the client without the use not even knowing?

No where did we say that we'd force users to download proprietary code

Wow. First I thought adding a giant security hole on purpose was just devs being routine-blinded. But now as they add blinking giant billboards leading the way on how to spread potential malware … holy fucking fuck please stop ruining Minetest.

It's hardly a _giant_ security hole

Nevermind. cache/media looks like a pile of encrypted names without any meaningful identification whatsoever.

They're hashes, not sure what they're based on though

[nerzhul]

@rubenwardy it's hash of the content or filename if i remember
@dsohler i don't know about proprietary blobs but it's not CSM philosophy and how i designed it. The dev page is quite old and we never looked at this page to make this happen. CSM run on a separate luastack from mainmenu but not thread, there is not sense to decouple it from client thread atm

[Wuzzy2]

I am very skeptical of allowing Minetest to run arbitrary code from potentially untrusted 3rd party sources. You can play in sandboxes all you like, only one serious bug in the sandbox is enough and you have a nice 0day. :-)
I think the “opt out of proprietary code” idea is just a lame excuse. For me, “opt out” means its proprietary by default. Ummmm … nope!
Second, it sends the completely wrong message. We are indirectly supporting people who want to distribute their proprietary blobs by making their stuff dangerously convenient to access via the server list. Why do these kind of people deserve any support from us?
Third, this completely destroys the current model of trust:
Currently, you can be relatively certain that running Minetest and playing on any server that you run without security risks or some random 3rd party blobs. But with this change it will no longer be true. Any server could be a potential “trap”
Because the JavaScript analogy came up quite often: Well, I think the Web sucks, we should not draw inspiration from it. :D Also: https://www.gnu.org/philosophy/javascript-trap.html

You can write warnings, send LICENSE files, create sandboxes and make “opt out” checkboxes all you like, at the end of the day, proprietary blobs will start spreading. I don't like this.

Ultimately, this begs the question why you want to explicitly allow for proprietary code in the first place. What's the benefit of that? Doesn't this very idea go against everything what Minetest stands for?

[rubenwardy]

I think the “opt out of proprietary code” idea is just a lame excuse. For me, “opt out” means its proprietary by default. Ummmm … nope!

Bad phrasing on my behalf, I meant opt in. It definitely should not be default. And it isn't a lame excuse at all.

[Wuzzy2]

So … you are OK with servers distributing proprietary code to clients?
Why?

Why do you want to support people who develop proprietary software?

[rubenwardy]

Minetest doesn't disallow proprietary mods. The majority of our users use Minetest with proprietary code, and they don't care. The reason that celeron55 choose a LGPL license over a GPL one was to be slightly friendlier to proprietary software, ie: getting companies involved is good for development (although we haven't seen this, and as a game I doubt we will)

Let's not impose our morals on others when it's personal choice

So … you are OK with servers distributing proprietary code to clients?

Yes, as long as the user is notified

Why do you want to support people who develop proprietary software?

I develop proprietary software for a living

[JustinLaw64]

Minetest people have been able to use proprietary textures for a while; As in the case of TestBDcraft. The License link seems to be broken, but the FAQ says the pack can't be mirrored.

With Minetest being LGPL. I'd think it's okay for one to make a proprietary sub-game as long as he uses other mods that are permissive and make their own mods.

[red-001]

why are we talking about proprietary blobs when it has already been well established that CSM doesn't and wouldn't allow bytecode to be executed as it is impossible to efficiently sandbox.

[JustinLaw64]

I think "whether or not Minetest should allow proprietary CSM mods" should be moved into another thread. As this thread is about "whether or not a Minetest client should be programmed to disallow user-provided CSM mods if the server so requests."

[ghost]

Minetest people have been able to use proprietary textures for a while

Because proprietary bitmap graphics are the same thing as arbitrary binary code being executed without the user being able to analyze what the code does before the client executes it.

[ExeterDad]

So if my server sends out a ambiance mod to be run locally and efficiently that is unique to our gameplay, it would be considered proprietary and frowned upon?
If all files are in plain text and our server can be proven to be malicious, then we deserved to be blacklisted and shunned for being so openly stupid.
I thought the whole purpose (at least it's what the brochure said) was to offload select tasks to the client to increase performance and make gameplay a more enjoyable experience?

[JustinLaw64]

Yes I do think server owners can send implicitly restricted copyrighted textures to clients as long as they made them on their own.

Because proprietary bitmap graphics are the same thing as arbitrary binary code being executed without the user being able to analyze what the code does before the client executes it.

They're photos, PNGs of all things. Does it make a difference if it came from your computer, or from an infected server?

[shimmark]

If Minetest servers can tell clients not to run user-provided mods, the users cannot replace the mods by modified versions. This has the same effects as tivoization; the user has to modify the client to run a modified version of the mods. Users are likely to want to customize or add functionality to the inventories and other interfaces implemented by client-side mods, so they are likely to actually want to do this. They shouldn't have to modify and recompile their client to do so.

The client should obey the user even when the user is trying to cheat or do things (other examples are blocking ads and torrenting copyrighted content) that the server administrator doesn't want. This doesn't mean that there aren't other (better) ways to prevent cheating because, conversely, the server should obey the server administrator and not trust commands sent by clients. The commands are already verified in serverpackethandler.cpp to make sure players aren't placing or digging nodes from too far away, moving faster than is supposed to be possible, interacting while dead, and so on.

This issue thread is about making the clients obey the server administrator's wishes in order to make cheating less convenient. Security through inconvenience works, to some limited extent. That modified clients exist isn't a valid argument for not making cheating inconvenient, but it is an example of the fact that the extent to which security through inconvenience works is limited. The actually-sound argument for not making cheating inconvenient is that it has disadvantages that outweigh the advantages: making it inconvenient to cheat in this case requires also making it inconvenient (requiring a fork and recompiling of the client) for the user to modify server-provided mods, which is exercising one of the four freedoms, or provide other mods. It is not necessary or useful to make clients obey the server administrator's wishes about client-side mods if countermeasures to protect the server are implemented on the server, under the control of the server administrator, rather than being implemented on the client.

@red-001 The mods are proprietary if they do not have a license that allows users to redistribute them, even if the source code is sent to the client.

[kilbith]

[blah blah blah] We are indirectly supporting people who want to distribute their proprietary blobs by making their stuff dangerously convenient to access via the server list. [blah blah blah]

It is quite revealing to see the word "dangerous" associated so fast with the word "proprietary" in the same sentence... For me you are a typical highly-opinionated FLOSS nuts who favorize the ideology above the pragmatism. Proprietary softwares run pacemakers and robots in space, did you know?

Also, like rubenwardy, I do code proprietary softwares for a living. And I much prefer a competitive proprietary software than a sucky free software.

[red-001]

@dsohler why the ** are you talking about binary code?

[red-001]

This issue has gotten massively offtopic, I suggest opening a new issue about your "binary blobs" whatever you mean by that.

[Wuzzy2]

To clarify: It started when rubenwardy suggested it's okay to let servers directly distribute proprietary code:

The users should get a warning if the server requests that they use proprietary mods, and have to opt-in to using them.

This is my last comment about this in this issue. Discussion should continue in a different issue, I agree.

[paramat]

Yeah that dev page is old and is not the plan for current CSM, and many MT devs have a strong FOSS attitude, so don't worry too much about proprietary stuff mentioned there.
My point was actually that CSM is not following that plan, in terms of client- versus server-provided mods.

I'm a little concerned that page was not looked at when designing current CSM, and it's clear that celeron55 and other devs who were considering working on CSM intended the server to have as much control as possible. So i'm concerned about how CSM has deviated from what was intended and has therefore caused the issues this thread is about. I feel there needs to be some change of direction to something closer to what celeron55 and others intended.

See #5930 for the proposed restrictions, consideration and input is appreciated.

[VanessaE]

Why are you guys even mentioning binary blobs? Minetest can't run them anyway if you have mod security turned on, or if you use LuaJIT, so that's like 99% of all Minetest installs by now.

As for proprietary code (whether source-available or not), come ON, just DEAL with it already! No one outside of the geek community cares if a program has a proprietary license, they just care if the program works properly.

[elinor-s]

I care. People outside of the geek community don't because they don't know about these issues, not because they have thoughtfully considered them and determined that software freedom isn't important. The users who do know about software freedom and are fine with running proprietary software anyway can toggle an opt-in setting, I'm sure.

[red-001]

you are welcome to not play on servers that don't follow your ideology. And can we please stop taking this issue offtopic?

[nerzhul]

license is not a CSM issue we don't care, we want to limit client API from server it's far from licensing issue

[paramat]

5930 merged.