|
OK, you're right. If I don't trust the person, indeed I won't use the person's shard. But I think a point has been missed. Security matters in all parts of the system.
How many machines hosting UU servers were broken into? I don't know the answer, but I am aware of at least three incidents. In UU, a cracked server was relatively harmless for the player. Now think about code, whether it is the client executable, or Python, being downloaded to the player's computer from the server. Would you want to be running code from a compromised server?
The server operator checking the code up front is very important but it cannot be the only defense; it does not protect anyone if the client isn't getting what the person running the server intends. So client security matters even if the server operator and age creators are all trustworthy people. As I said, security also depends on being able to verify you actually received what was checked, tested, and accepted. At some point you have to trust people, but you shouldn't trust servers, they are computers and are incapable of being trustworthy.
I think it's a bit of a shame that people seem to think of security as some kind of struggle between client security and server security. Why are they at odds? Why would anyone feel the need to say, "I want server security at the cost of client security" or vice versa? The concern should be securing the whole system.
Until now, people have talked about addressing server security in various different ways, but the client is always left to fend for itself. If you don't think client security is worth anything, fine. But don't block those of us who do want client security. It is actually not difficult from the server's point of view to provide the necessary functionality for securing the client, and client security does not preclude the server from being able to control what the client runs under normal usage.
Under any kind of actual attack, your plan to force players to use your client, libraries, Python, whatever, does not even work. In the end, you cannot control what your attacker runs on his computer. All you can do is make sure normal users are using the right stuff, and you can make it more and more difficult for an attacker, but you cannot stop him that way. The only way that truly works to achieve server security is to validate all input from the client.
Once you accept that you cannot force an attacker to use your client, then you can actually set up the whole system in a way that provides the server control over what non-attackers are using while also providing what is necessary for client security instead of making it impossible. What is wrong with that goal?
It's perfectly fine for the server to expect a certain client, and to arrange for checks for it. What is not perfectly fine is denying me the ability to choose a client and code that I know is safe. So long as a server operator refuses to let me obtain a client and Python code in a way that verifies it is what he and I both intended me to have, that operator is denying me the ability to be safe, without gaining any true security himself. If you want to go that route, I won't visit your shard. However, it doesn't have to be that way for everyone. Let the rest of us secure our clients in peace.
- a'moaca'
|
Login
FAQ
Search
