I am very much against client side dlls for security reasons. Server side
dlls are bad enough, but I really don't want average users downloading
unknown dlls to play the latest add ons.
John Carmack
The Client Side DLL was one of the very first suggestions made. It is also the first to be "officially" rejected. Read here for the technical side of things, and a detailed list of advantages gained by both id Software and us. A prime example is Java in Q3.
Case closed? Maybe. I am going to try to convince you that "Security first" as dicussed here (Client Side DLL) is in fact "Security only", and a Bad Thing.
Within the Q3 Suggestion process, this is one very special case in that it raises a political rather then a technical concern. It was also checked early with id, as a fairly large number of other proposals would have been adressed with this single, rather straightforward change. The ultimate decision will have some impact on the overall outcome of our Q3 Suggestion process - a lot of things are just very difficult and time consuming without a Client Side DLL.
Because it raises a fundamental question. I do not agree with John Carmack, and maintain that it is not id's job or duty to protect us from our on stupidity, because:
In other words, I do not want to be protected against my own will. Given the choice between freedom at risk vs. security w/o options, I will clearly prefer the freedom of choice. I am entitled to pick my own risks, am I not?
Microsoft is not liable for virus exploits of the Word macro mechanisms, or the bootsector features in DOS. I fail to see that id Software could be held liable. I do see that Activision support might suffer from additional load.
Related example: overclocking your hardware. If the company says: "You should not, Warranty will be void, don't ask Support", fine. If they are saying "If you do, no higher then 58MHz", even better.
I have said this before: a client DLL is no different from a server DLL for all practical purposes. Reality is: most people do a lot of single player or makeshift LAN, they run mods locally (if at all), downloading Game DLL's that are modified. People that are serious into multiplayer do offline training, with bots, on a LAN, or just moving through the map, memorizing locations, all of them using a local DLL.
A Client DLL increases the amount of security risk, but vastly so? It sure does not change the quality of risks.
DOOM had a disclaimer display when loading PWADs. Q2, with a Game DLL that is used in single player locally, is completely lacking such a Scare Screen. That settles liability, and raises awareness, which has been neglected in Q2 - but would be perfectly sufficient for Q3.
Why am I bitching about "Security only"? Because if affects the entire game industry, and future games. Game companies have switched back and forth between properietary scripting languages and DLL's for this reason, wasting time and energy.
Java will solve this, you say? Well, the client DLL decision also forecasts some things about Trinity and client downloadable Java. If the same level of security concerns is applied, the Java code on the client will not be able to read/write local files etc. If we have browser-style Options to enable Java at various security levels, how is that fundamentally different from the DLL load disable mechanism I described above?
Okay, so maybe you can't read/write locally in Trinity. So what?
The really Bad Thing about all this is that John Carmack decided to treat network bandwidth for security. Take the "server can put anything on the client screen" example. For security reasons, the server maintains the screen layout for each client, sends data not available in local files, etc. We get stuffimage for raw data. We do not get autodownload. We get configurable HUD, but the player can't customize it and store preferences locally? Or has to enter them manually in a userinfo?
John Carmack pointed out that the Q3 design decisions are based on the fact that 3D graphics hardware has improved a lot since the Quake renderer was designed, but the Internet/modem constraints for networking have not changed at all.
"Security only" simply gets a a lot of stuff moved from the client to the server and back for security reasons only, eating into the already scarce bandwidth. It pollutes the design - and it means less toys for us. Setting a precedence for the gaming industry at large, it is simply the wrong decision.
Submitted 980420, revised 980429, revised 980430, comments to bk@gamers.org.