faq  code  awards  privacy  slashNET  older stuff  rob's page  preferences  andover.net  submit story  advertising  supporters  past polls  topics  about  jobs  hof Sections 2/7 apache 2/11 askslashdot 1/27 awards 2/11 books 2/12 bsd 2/10 features 2/11 interviews 1/31 radio 2/13 (3) science 2/13 (2) yro Andover.Net AndoverNews Ask Reggie DaveCentral FreeCode Freshmeat	ESR on Quake 1 Open Source Troubles Posted by CmdrTaco on Monday December 27, @11:31AM from the stuff-to-read dept. ESR as chimed in to say his bit on the recent quake problems that popped up following the source release. Its definitely a problem that will happen again and something that needs to be handled. Read what he has to say about it. The following was written by ESR. You know who he is already ;) The case of quake cheats The open-source community got a lump of coal in its Yule 1999 stocking from renowned hacker John Carmack, the genius behind id Software and such games as Castle Wolfenstein, Doom, and the Quake series. Carmack's .plan file noted a problem that has swiftly emerged since the Quake 1 source was released under GPL; it seems that some people have used their ability to modify the Quake client as a mechanism for cheating. This may at first sight seem a trivial issue -- who cares if a few testoterone-pumped teenagers cheat at a shoot-em-up game? But in today's internetworked world, countermeasures against Quake cheating arguably provide an important laboratory model for cases that are decidedly not trivial, such as electronic commerce, securities trading, and banking. The Quake model is made particularly relevant by its open-source connection. Open source advocates (including me) have been making a strong argument over the last two years that open-source software such as Linux and Apache is fundamentally more secure than its closed-source competitors. Cryptographers have long understood that no encryption system can really be considered well-tested until it has been energetically and repeatedly attacked by experts who have full knowledge of the algorithms it uses. Open-source advocates argue that there is nothing special about cryptography but its high stakes -- that, in general, open peer review is the only road to systems which are not merely accidentally secure by obscurity, but robustly secure by design. Carmack, therefore, caused a bit of a flutter on Slashdot when he went on to to suggest that only a pair of closed-source encryption programs could solve the Quake-cheating problem. The problem, as he correctly pointed out, is that asking the open-source client to verify its own correctness won't work; a sufficiently clever cracker could always write a client that would simulate the right kinds of responses and then cheat. A debate ensued, with several people pointing out that trusting the client half of a client-server pair is bad security policy whether the client code is open or closed. Fundamentally, there's no way for the server to be sure it isn't talking to a clever simulation of `correct' behavior. Thus, opening the source to Quake 1 didn't create security problems, it merely exposed one that was already present (and exploitable, and for all anyone knew already secretly exploited) in the design of the game. Carmack weighed in to make clear that the Quake-cheating problem is subtler than many of the debators were assuming. It's not possible for a cheating client to give a player infinite ammunition or life points; the server does not in fact trust the client about these things, and manages them itself. This is correct design; whether or not it's open-source, a bank should not depend on a customer's client software to tell the bank what the cutomer's balance is! Carmack observes that "the [cheating] clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully." The serious "more information" cheats depend on a performance hack. In order to hold down the number of updates of the Quake world it has to pass to the client, the server gives the client information about the location of objects and opponents that the player can't yet see, but might be able to see before the next update. The server then counts on the client not to make those things visible until they "should" be (e.g, until the user gets to a particular location in the maze the client is simulating). A cheating client can reveal an opponent seconds before the player would turn the corner and expose himself to fire. The "more skillfully" cheats substitute the computer's speed and accuracy for tasks that the server and other players expect the player's hands and brain to be performing. Carmack talks about "aim bots" which automatically lock the player's gun onto visible opponents and fire it with inhuman accuracy. And indeed it's hard to see how either of these sorts of cheats can be prevented given an open-source client and no way independent of the client itself to check that the client is honest. Thus Carmack's suggestion of a closed-source Quake-launcher program that would take a checksum of the client binary, communicate with the server to make sure the binary is on an approved list, and then handle communication with the server over a cryptographically-secured channel. Carmack's argument seems watertight. What's wrong with this picture? Are we really looking at a demonstration that closed source is necessary for security? And if not, what can we learn about securing our systems from the Quake case? I think one major lesson is simple. It's this: if you want a really secure system, you can't trade away security to get performance. Quake makes this trade by sending anticipatory information for the client to cache in order to lower its update rate. Carmack read this essay in draft and commented "With a sub-100 msec ping and extremely steady latency, it would be possible to force a synchronous update with no extra information at all, but in the world of 200-400 msec latency [and] low bandwidth modems, it just plain wouldn't work." So it may have been a necessary choice under the constraints for which Quake was designed, but it violates the first rule of good security design: minimum disclosure. When you do that, you should expect to get cracked, whether your client is open or closed -- and, indeed, Carmack himself points out that the see-around-corners cheat can be implemented by a scanner proxy sitting between a closed client and the server and filtering communicatiuons from server to client. Closing the source of the client may obscure the protocol between client and server, but that won't stop a clever cracker with a packet sniffer and too much time on his hands. Carmack confirms that even without the packet sniffer or access to source there are a variety of ways to flush out anticipatory information, ranging from tweaking the gamma and brightness on your screen to banish shadows to hacking your graphics card's device drivers to do transforms of the world model (such as making walls transparent). We're back in familiar territory here; the history of computer security is littered with the metaphorical (and in some cases maybe literal) corpses of people who thought security through obscurity was sufficient. Crackers love that kind of naivete and prey on it ruthlessly. The aim-bot cheat is trickier to prevent. The difference between human and aim-bot actions is measured only in milliseconds of timing. Changing the protocol to stop it from leaking information won't banish aim-bots; it would take the server doing statistical analysis of player action timings to even detect them, and (as Carmack points out) "that is an arms race that will end with skilled human players eventually getting identified as subtle bots." Fortunately, the aim-bot cheat is also much less interesting from a general security point of view. It's hard to imagine anything but a twitch game in which the client user can cheat effectively by altering the millisecond-level timing of command packets. So the real lesson of both cheats may be that a closed-source program like Carmack's hypothetical secured program launcher is indeed a good idea for security -- but only if you're a hyperadrenalized space marine on a shooting spree. (Any computer game at which computers are better than most humans has analogous cheats, some of which aren't even detectable in principle. Carmack observes "correspondence chess has been subverted from its original intent by players using computers." This isn't something security design can fix.) If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers. Open source keeps designers honest. By depriving them of the crutch of obscurity, it forces them towards using methods that are provably secure not only against known attacks but against all possible attacks by an intruder with full knowledge of the system and its source code. This is real security, the kind cryptographers and other professional paranoids respect. It's the kind of security the Linux kernel and the Apache webserver have, and the kind people victimized by the Melissa and Chernobyl viruses and Back Orifice and the latest Microsoft-crack-of-the-week don't have. If you're betting your personal privacy or your business's critical functions on the integrity of software, it's the kind of security you want, too. To recap, the real lessons of the Quake cheats are (a) never trust a client program to be honest, (b) you can't have real security if you trade it away to get performance, (c) real security comes not from obscurity but from minimum disclosure, and most importantly (d) only open source can force designers to use provably secure methods. So, far from being a telling strike against open source, the case of the Quake cheats actually highlights the kinds of biases and subtle design errors that creep into software when it's designed for closed-source distribution and performance at the expense of security. These may be something we can live with in a shoot-em-up, but they're not tolerable in the running gears of the information economy. Avoiding them is, in fact, a good reason for software consumers to demand open source for anything more mission-critical than a Quake game. Eric S. Raymond <  Linus One of Fortune's "People to Watch in 2000" | Interviews: We Have 2! 1st, L0pht Heavy Industries  >	Slashdot Login Nickname: Password: Don't have an account yet? Go Create One. A user account will allow you to customize all these nutty little boxes, tailor the stories you see, as well as remember your comment viewing preferences. Related Links Linux Slashdot .plan file Slashdot Eric S. Raymond the recent quake problems More on Quake Also by CmdrTaco
	This discussion has been archived. No new comments can be posted. Quake1, not Quake3 (Score:2) by D|sturbed on Monday December 27, @11:37AM EST (#3) (User Info) http://lonestar.intcomm.net CmdrTaco, you got it wrong. Quake3's source wasn't GPLed; it was Quake1 you're thinking of. Get fragged @ Lone Star Quake South Texas' premier Quake server http://lonestar.intcomm.net Re:Quake1, not Quake3 (Score:1) by clyons on Monday December 27, @01:04PM EST (#135) (User Info) Either way, it's a problem that is going to have to be addressed. In anybody is interested, a once very popular networked game that had cheating troubles, netrek, solved it by compiling official, or "Blessed" binaries for different platforms. Using RSA encryption, they would encrypt a bunch of different client keys using an encryption algorythm. Upon connection with a server that had client checking enabled, the server would request client verification. I'm sure you could find more detailed information at The Netrek Homepage at www.netrek.org. (Now that's a site I'd like to see slashdotted. It ain't Quake, but you win through "Genocide," or taking over all the enemie's planets. :) ) A vote that is cast according to one's true beliefs is never wasted. Re:Quake1, not Quake3 (Score:2, Informative) by Ghistelwcholm on Monday December 27, @01:25PM EST (#146) (User Info) Actually, netrek didn't solve the problem -- it just made cheating beyond the reach of your standard CS undergrad. You can still cheat at netrek by writing a customized X server, since netrek has to use X to display itself and get input from the user. I used this technique to write a two-mouse netrek client back when my ulnar nerve was all screwed up. It is possible to make protocols with untrusted clients heavily well-defended, as long as you can demand that you execute native code on the target machine, which Quake is able to do. All you have to do is send down to each client a specialized, randomized protocol handler with its own uniquely generated key, mix it up so there are millions of unique protocol handlers, each of which defends itself differently and makes sure it's not being tampered with, and hey presto, it's just way too inconvenient for nearly everyone to screw with it. This isn't possible with netrek because it runs on an infinity of different architectures and tries to be platform independent, but since Q3 only runs on x86 and mac platforms... Re:Quake1, not Quake3 (Score:1) by Cramer (foo@bar.com) on Monday December 27, @04:41PM EST (#241) (User Info) http://do.i.have.to? At the time, it was beyond most grad students as well. Factoring a 128bit number is not that hard in the present computer world. As you point out, there's nothing stopping anyone from creating a netrek client client. (Altho' I'd invest the time in factoring the keys -- all of them :-)) For the record, the verification can (and usually did) happen at any point during game play -- paranoid servers would usually repeat the verification at random intervals. Re:Quake1, not Quake3 (Score:1) by RainBrot on Tuesday December 28, @04:36AM EST (#318) (User Info) Hmm... pretty eager to get that first post, eh? The only Quake 3 mention I see is the "icon" for the article... and if you're going to pick on that, you might also want to mention that Linux isn't a penguin. Maybe the article was edited after posting, but I doubt it. Quake cheating (Score:1) by jormurgandr on Monday December 27, @11:38AM EST (#4) (User Info) I think it's a great idea to open source quake. It allows programmers like myself to learn tricks of game programming from the masters. It's sad that we have people in this world that would take something like open source and use it to cheat in the game. What fun is a game that you know you're going to win anyway? ======= There was never a genius without a tincture of madness. - Aristotle Re:Quake cheating (Score:1) by giuoco (kdavis@geo.no.spam.arizona.edu) on Monday December 27, @11:42AM EST (#7) (User Info) http://www.goodnet.com/~sfritch/ What fun is it? Dominating everyone else. I dont cheat, let alone play q1 anymore, but something about winning a matche makes everyone feel all warm inside, no matter how you got there. Re:Quake cheating (Score:1) by RainbowSix (t@cmu.edu) on Monday December 27, @11:46AM EST (#16) (User Info) http://www.crosswinds.net/~areyoubored You have to look at it from a mental prespective. Say it is fun only the first time to cheat. THen you do it just once more to show your friends. If everybody that could did it, the opponents couldn't tell. Basically, it isn't fun to ALWAYS do it, but once a while, when you are down, it is fun for you. THen everyone else, unsuspecting, is at a disadvantage. --- JavaScript is all that matters Re:Quake cheating (Score:1) by giuoco (kdavis@geo.no.spam.arizona.edu) on Monday December 27, @11:50AM EST (#22) (User Info) http://www.goodnet.com/~sfritch/ You're right. Once in a while is it cool. ESR points (Score:0) by Anonymous Coward on Monday December 27, @12:07PM EST (#67) Why do we listen to this whacked out gun-toting hippie anyway? Re:ESR points (Score:0) by CC (cc@carnagepro.com) on Monday December 27, @01:55PM EST (#168) (User Info) http://carnagepro.com/ Wacked out gun toting asshole ... leave us hippies out of it. CC "Pray arm me further by your reply" Winston Churchill Re:Quake cheating (Score:0) by Anonymous Coward on Monday December 27, @12:13PM EST (#83) just so you know, it was Henry Louis Mencken who actually said: "Freedom of the press is limited to those who own one" Re:Quake cheating (Score:1) by theonetruekeebler (keebler@mindspring.com) on Tuesday December 28, @01:24PM EST (#344) (User Info) http://keebler.home.mindspring.com/ Actually, it was Abbott Joseph Liebling. Cynical enough to be Mencken, though... -- It's never too late to panic. Re:Quake cheating (Score:0) by Anonymous Coward on Monday December 27, @03:25PM EST (#206) What is really sad is to see the attitude being perpetuated which says: because it is open source we should stop trying to find security holes in it. It is the search for imperfections which ultimately leads to perfection. Given enough time, I think you will find that open source methods will solve Quake 1's problems in the long run, even as close source solutions are being proposed in the short term. I understand now (Score:0) by Anonymous Coward on Monday December 27, @11:42AM EST (#5) Oh, it's not a bug. It's a feature. Thanks. Whee-hoo (Score:2, Insightful) by Foogle (foogle@adelphia.net) on Monday December 27, @11:42AM EST (#6) (User Info) This is dumb. Seriously, I kind of expect more from ESR by now, I don't know about the rest of you. Quake => E-Commerce? No way, E-Commerce (Open Sourced or not) has no business providing any sort of control over the process on the client-side. In a decently designed model, everything would be server-side, except what is relevant to the customer. Unfortunately, to do everything server-side in a highly CPU/graphics intensive game like Quake, would cause a huge slowdown. That's the issue here. But until your e-commerce needs to do 1024x768 @ 60 fps, I don't think this is really all that relavent. ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants Re:Whee-hoo (Score:2, Insightful) by lnovak on Monday December 27, @11:51AM EST (#25) (User Info) It seems to me then that you agree with Carmack's point, that the design decisions made to increase performance in a low bandwidth environment, necessarily preclude a secure client. What ESR is addressing is that both Quake and ecommerce clients exist in this same environment, and that when open source principles are applied from the get-go, a secure solution can be provided. Thanks for listening. suffering from pronoia Re:Whee-hoo (Score:1) by dweezil on Tuesday December 28, @12:22PM EST (#342) (User Info) What ESR is addressing is that both Quake and ecommerce clients exist in this same environment, and that when open source principles are applied from the get-go, a secure solution can be provided. ESR's assertion that Quake would be more secure if it had been developed as Open Source really doesn't wash. To get the performance nessecary over slow links requires that you trust the client. This is never secure. Period. No well designed e-Commerce app would ever trust the client; Open or Closed Source. Therefore, the comparison isn't valid. The environments are not the same. ESR's most important point is that opening the source now hasn't created any new cheating opportunities. This is the message that needs to get to the people that think opening the source to Quake has created a new problem. Unfortunately, this message will be obscured by ESR's conclusions. This issue didn't require any new insight; just some facts. He already made that point (Score:2, Informative) by xant on Monday December 27, @11:56AM EST (#35) (User Info) You should consider reading the article before you criticize it. (Who moderated this guy up?) Re:He already made that point (Score:0) by Anonymous Coward on Monday December 27, @12:02PM EST (#56) He wasn't moderated up, his karma lets him post at +2. Re:He already made that point (Score:0) by Anonymous Coward on Monday December 27, @12:06PM EST (#63) No one's karma posts at +2. He was moderated up, and I can understand why. Just because you don't agree with something, doesn't mean it's not interesting. Re:He already made that point (Score:0) by Anonymous Coward on Monday December 27, @12:34PM EST (#109) Funny, mine does. (When I'm not using the "Post Anonymously" button, anyway. Re:He already made that point (Score:0) by Anonymous Coward on Monday December 27, @12:40PM EST (#115) He wasn't moderated up. His web client is cheating! :D h0h0h0h0h0 (Score:0) by Anonymous Coward on Monday December 27, @04:59PM EST (#244) He wasn't moderated up. His web client is cheating! :D *groan* Re:He already made that point (Score:2) by Zigg (matt+slashdot@zigg.com?subject=[SLASHDOT]) on Monday December 27, @12:05PM EST (#62) (User Info) You should consider reading the article before you criticize it. (Who moderated this guy up?) Amen. ESR was lamenting the parallels that will be drawn, like it or not -- and parallels that indeed should be drawn so that folks notice this important dilemma. Let's face it, there was nothing stopping folks from cheating before; open sourcing the client just made it easier for those with less time on their hands. You need to operate in paranoia mode whenever you are designing protocols or server applications. Never trust the client. Trusting the client to supply ``good data'' is what has filled the Web with weak CGIs (and I must note that these appear on both open source and closed source platforms.) Nobody moderated him up, BTW. He has High Karma(TM). "If you continue running Windows, your system may become unstable." - Windows 95 BSOD Re:He already made that point (Score:1) by Foogle (foogle@adelphia.net) on Monday December 27, @12:22PM EST (#96) (User Info) Wow, have I done something to offend you, or are you normally this cranky in the afternoon? ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants Re:Whee-hoo (Score:1) by zyklone (zyklone@hotmail.com) on Monday December 27, @11:59AM EST (#45) (User Info) The Security Model still has to be the same. The similarities between E-Commerce and E-Games are quite many. In the web world you can't assume that everyone is using the same browser you wrote the page for. In the game world you can't expect the client to be the same one you wrote the server for. The Quake protocoll is fundamentally flawed. It reveals information which it expects the client not to disclose. This is a bit like putting passwords in html comments on an E-Commerce site. I can see only 2 solutions to this problem. Either you only accept connections from certain clients or you don't reveal information the client should not have access to. Now stop whining about the fact that ESR,RMS etc are dumb and you are so bright. If you were you would probably be known as FGL. Re:Whee-hoo (Score:1) by Foogle (foogle@adelphia.net) on Monday December 27, @12:08PM EST (#69) (User Info) FGL... Hey, that's not too shabby :) Actually, if I went by my actually initials, I'd be SAR. That doesn't have much of a ring to it. ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants Not exactly (Score:2, Interesting) by IntlHarvester (vcs2600@yahoo.com) on Monday December 27, @12:45PM EST (#121) (User Info) From a technical or 'community' standpoint (think ebay feedback ratings), e-commerce and e-games face a similar security and trust issues. But, the fundamental basis of e-commerce is still several hundred (thousand?) years of laws governing contracts and commercial transactions. If the technical security model breaks (as it has many times on Ebay), the legal security model will jump in, along with various police agencies, courts, lawyers, banks, collection agencies, insurance firms, and so on. When the "e-game" model breaks, there's no real higher power you can beseech. Thus, people are more likely to break the rules, because there are few if any negative consequences. So, while you can put preventative mechanisms in (reputation systems, certificate verification, signed binaries, and so on), it really comes down to the other users, and how much you are willing to trust them. (Think of blackjack -- you might play in Las Vegas where the Casino is supposedly trusted, or you might play your trusted friends, but you would be less likely to go into some random basement and play an illegal game because the deck could be loaded and you have little recourse if it is.) -- Plagiarism is necessary. Progress demands it. Re:Whee-hoo (Score:1) by Judah Diament on Monday December 27, @11:59AM EST (#46) (User Info) http://cs.nyu.edu/diam7644 I don't think ESR meant that there is a clear mapping from Quake to E-commerce. Rather, the point is that Quake teaches us some good security lessons. And if you think that bad security can't be designed into e-commerce just as easily as Quake, you're living in a research lab on the North Pole. Re:Whee-hoo (Score:3, Interesting) by Nimmy (spam@nimlabs.org) on Monday December 27, @12:01PM EST (#52) (User Info) http://www.nimlabs.org I disagree completely. It is true that ESR is making a big stretch, one that many people would think is invalid. And it is true that Quake has little to do with e-commerce per se. But ESR is not actually comparing Quake to e-commerce. He is comparing development methodologies and their outcome. His points (such as "Don't trust a client") apply just as well to E-commerce as they do to Quake. This is why we see very few client-side e-commerce sites (I can't think of any). ESR is not saying very much about the Quake problem. He gives no solutions of further insight into Quake. What he is trying to warn people about is that this is nothing new, that Quake still has a closed-source security method that only now has been opened. One can't expect the magical "Open Source" pixie dust to fix fundemental security flaws. The most important point which ESR makes (or at least hints at) is the crux of the open-source security paradym (sorry, I know people hate that word, but it does fit here): Open Source Makes Security Problems Easier to Find for BOTH GOOD AND EVIL. That last clause is what makes the "debate" between open and closed source security types interesting. Big companies see that it is easier for crackers to break an open source solution and shy away. Open source types see it makes it easier to make a quality product and embrace it. BOTH VIEW ARE CORRECT. That is the crux of the issue, so well demonstrated by Quake. That is not quite ESR's point, but he at least implies it. With this in mind, ESR makes much more sense. Re:Whee-hoo (Score:0) by Anonymous Coward on Monday December 27, @12:11PM EST (#79) it's "paradigm" Re:Whee-hoo (Score:1) by Nimmy (spam@nimlabs.org) on Monday December 27, @12:51PM EST (#128) (User Info) http://www.nimlabs.org > it's "paradigm" Thank you for your correction. My Humblest Apologies, -Nick (PS: I know I can't spell. At this point, I no longer care.) Re:Whee-hoo (Score:0) by Anonymous Coward on Monday December 27, @05:15PM EST (#251) It's "caere" Untrusted Clients Can be secure.. (Score:1) by sysop on Monday December 27, @06:06PM EST (#263) (User Info) Have a look at the X Client Server relationship. The Client Software (Actually the X Server) runs in a high res graphics mode, and cannot do anything on the server that the server doesn't allow it to do. Also look at PGP. Open Sourced code, running on untrusted PC's with Untrusted email clients, yet trusted to be secure. I'm not saying these apply directly to quake, but it suggests to me that the problem is not unsolvable. NETREK (Score:0) by Anonymous Coward on Monday December 27, @11:42AM EST (#8) This is not a new problem! Netrek solved this problem years ago. It was explained in the previous discussion on this, but to be brief: you have 'blessed' binaries which are compiled using some sort of public/private key pair. One aspect of the key is stored in a list on the server side, configurable by the administrators so they can add and remove blessed clients as they desire. Only blessed clients in the given list can use the server. If somebody cracks the key out of a blessed client--a new one is made and the key is removed from the server lists. Simple. Re:NETREK (Score:2) by Foogle (foogle@adelphia.net) on Monday December 27, @11:45AM EST (#11) (User Info) Just out of curiosity, how do you know if someone has cracked the key out of a "blessed" client? When they've broken your e-commerce system and stolen thousands of dollars worth of good from you? ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants Re:NETREK (Score:2, Informative) by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @12:21PM EST (#93) (User Info) This is not a new problem! Netrek solved this problem years ago. It was explained in the previous discussion on this, But as I explained in the previous discussion, Netrek's authentication protocol isn't very Open-Source. It is similar to Carmack's closed-source pair of programs. We just rolled it in to the binary. Sure, it was developed by several people in the development team, and protocols and methods were discussed in the open, but who actually gets that source is controlled. Without it, you have an un-blessed client or a server that doesn't require authentication. And as this message's sibling states, if someone was patient, very patient, enough to break through our 20 levels or so of obfuscation for ONE particular binary, how do we, the Key Maintainers, know that key has been compromised? We don't. Somebody has to notice and cry foul. That particular cracker would be smart to be as quiet and non-obvious as he can since each binary's obfuscation is different. --Carlos V. Re:NETREK (Score:1) by nweaver (nweaver@cs.berkeley.edu) on Monday December 27, @01:00PM EST (#132) (User Info) http://www.cs.berkeley.edu/~nweaver/ The non "open source" parts of the netrek "blessing" authentication were not in the source code, just a secret key stored in the client. There is no closed source nature for that solution, as the secret is not really part of the source code per se, just a compiled in constant Nicholas C Weaver nweaver@cs.berkeley.edu Re:NETREK (Score:1) by Gosub (gosub@spamvac.eaze.net) on Monday December 27, @01:03PM EST (#133) (User Info) While the Netrek solution may work, I still think the only way you can guarantee that an OpenSource network game doesn't have cheating is to use a thin client approach. On the WorldForge Project, we've adopted that stance. If the server holds all the cards, hacking the client doesn't do any good. The reason this could work for us is that the amount of information we'll be sending between the client and server isn't near that of Quake. It doesn't stop someone from taking our server source and modifying it to allow them to cheat, but not everyone will have the resources to run thier own servers. What about a reputation system? A master server that holds Account information for online gaming. That way players could run games that only include people that have earned a reputation for being an honest player? Re:NETREK (Score:2, Interesting) by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @01:30PM EST (#149) (User Info) I still think the only way you can guarantee that an OpenSource network game doesn't have cheating is to use a thin client approach. Well that's essentially how Netrek works. In Netrek, the server handles ALL game mechanics and lays down the law as to what each player and weapon can and can't do as well as doing all the data hiding and deciding exactly what each player can and cannot see. The client is essentially a display engine and a user input packager. However you can still cheat with that. You can make a client that will play the game for you (which is fun in its own right). You can do things like auto-aim, auto-shields, auto-dodge. You can also be an info-borg. An info-borg is a client that displays or makes obvious various game events and states that a good player knows how to look for and/or estimate. Examples include showing everybody's speed and true direction on your display, showing cloaked players on your tactical display, noticing a player with kills orbits a planet, and that planet's army count drops and flagging that player as a carrier, etc. You can probably make it harder by doing some sort of authentication method, or make the players download the client from the server every time they want to play. Its a cat and mouse game. At any rate, I like the existence of borgs on servers that allow them. In college, I used to be involved in running State and National Programming Contests at UTexas' IEEE-CS student branch. Our games were not the standard ACM type (here are 6 programming problems, have at it). What we did was write a game meant for computers to play. What the contestants did was take 8 to 20 hours to write a program that would play the game for them. During the actual elimination tournament, the contestants weren't allowed to touch the computers. It was quite fun for all involved. Dave Taylor (ddt of id, Crack, and Transmeta) founded and ran the first couple of National contests. If you ever get a chance to compete in a contest like that, I highly recommend it. --Carlos V. Re:NETREK (Score:2) by sdt (sdt__AT__gmx.net) on Monday January 03, @03:53PM EST (#354) (User Info) http://www.nofx.org/ Yes, at WorldForge one of the things that I like about the way we're planning it is that any player can run an "NPC client" while he/she is not logged in that follows a script and pretends to be alive normally. We have some pretty good AI folk and it all looks rather promising. This corresponds to the "borgs" that you have been talking about. Join WorldForge - an Opensource Multiplayer RPG! Re:NETREK (Score:1) by pberry (pberry@freestyleinteractive.com) on Monday December 27, @12:48PM EST (#124) (User Info) http://www.freestyleinteractive.com Don't forget to mention that a RSA kay was cracked and a 'borg' client was created. -- Mommy, what's an NT? Re:NETREK (Score:1) by sheldon (sheldon@yuck.net) on Monday December 27, @05:28PM EST (#255) (User Info) http://www.sheldon.visi.com To my knowledge, the only time any RSA keys used in Netrek were actually cracked was when I stumbled across a bug in the key generation program back in 1994 or so. The key generation program was not using a sufficiently random seed, and as a result it really only generated any one of perhaps a couple of thousand key combinations. It was not difficult for me to setup my computer at the time to create several thousand keys, and simply compare them against the known public keys to see if I had a match. In one night I had cracked some 40 client keys. But I made an attempt to report it to all the client maintainers at the time, and after the key generation program was fixed we generated new keys and recompiled the clients. Re:NETREK (Score:1) by clyons on Tuesday December 28, @06:47AM EST (#326) (User Info) Who really cares as long as cheating is out of reach for the common script kiddie? A vote that is cast according to one's true beliefs is never wasted. Re:NETREK (Score:1) by bnenning on Monday December 27, @01:19PM EST (#141) (User Info) http://www.kreative.net/bwn/ I still don't understand how that can work. Couldn't someone get a blessed Netrek client, figure out what it sends to the server to authenticate itself, and then do a replay attack by making their hacked client send the same data? Isn't that just more security through obscurity? Re:NETREK (Score:2, Interesting) by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @01:42PM EST (#155) (User Info) Couldn't someone get a blessed Netrek client, figure out what it sends to the server to authenticate itself, and then do a replay attack It is security through obscurity, but the obscurity is the private half of a client's RSA key. It is a challenge-response type of authentication. On top of that, the challenge is random and both the challenge and response are encrypted. Doing a replay attack would give the response to the wrong challenge. --Carlos V. how netrek really works (Score:2, Informative) by tap on Monday December 27, @03:03PM EST (#200) (User Info) http://staff.washington.edu/xyzzy/ Since no one seems to really know netrek's anti-borg system works, I'll put it down in detail. When a new client binary is created, the person compiling it makes a public/secret RSA key pair. The public key is sent to the keyserver (Carlos V), while the secret key is compiled into the client. The code to create these keys, as well as the client/server (they are the same) routines to do RSA aren't in the client or server source. This is because of export restrictions. Anyone can download the RSA source from a certain FTP server in Europe, which is what I did when I released my netrek client. The RSA source isn't widely distributed, but there isn't anything closed about it. The only thing secret is the secret key, which only the person compiling the client knows. After the client connects to the server, the server sends a cookie of random data to the client. The client sticks the IP address of the _server_ (via getpeername()) in front of the cookie, and encrypts it with the secret RSA key inside the client. The server gets the response, and if it decrypts properly with the client's public key, the client is allowed. There are several weak points to this method. The most obvious, but not the easiest, is to somehow extract the secret key from the client. This was how DVD was cracked, by extracting a secret key from the Xing player. The secret key isn't actually in the client as raw data, rather C code is generated that performs the operations needed to do the RSA encryption with the key. With the C code in front of me, it's not trivial to tell what the key is, figuring it out from the compiled code would be very difficult indeed. Another weak point is binary hacks. The client does NOT perform a binary hash (checksum, CRC, md5, etc.) of any kind, so you can take a hex editor to it at will. There really is no way to stop this; if you put in a checksum, someone can just hack the checksum code. With the complexity of programs like netrek and quake, adding new features with a hex editor is a difficult task. Not as easy as fiddling a few bytes on console systems with a game genie or the like. Netrek does all game mechanics in the server, so "no damage", "infinite ammo", "shoot through walls", cheats just aren't possible. The easiest way to get around this system is a man in the middle attack. You have a real client connect to server via your cheat proxy. The proxy understands the game protocol, and can cheat in a number of ways. For instance, it could allow the normal client to connect to the server and authenticate isself, then pass control over to a fake client. Netrek trys to make this hard by putting the IP address of the server inside the cookie. If the real client thinks the server is at 127.0.0.1 put the server is really at 1.2.3.4, the RSA response will be bad. You can get around this with a dynamic library hack to getpeername() or a kernel level hack for static binaries. Or have a tranparent proxy that can intercept packets. Re:how netrek really works (Score:3, Informative) by John Carmack on Monday December 27, @03:33PM EST (#211) (User Info) Thank you. Lots of people were just waving their hands saying "Netreck solved this years ago" without being specific. As you say, it isn't really a solution. If there were a couple million people playing netrek, there would be cheat proxies for it just like there are for Quake. I think everyone can agree that it just isn't possible to solve the problem completely, you can only make it more difficult, which is exactly what the netrek solution is -- release binaries without the exact source and make it difficult to decypher. John Carmack Moderate this up you jackass! (Score:0) by Anonymous Coward on Monday December 27, @04:32PM EST (#238) Yeah you! Use those points. Re:how netrek really works (Score:1) by Unbeliever (unbelver@us.netrek.org) on Monday December 27, @04:43PM EST (#242) (User Info) Lots of people were just waving their hands saying "Netreck solved this years ago" without being specific. There have also been other messages in the previous story offering other details. If you want more details mail off to vanilla-list@us.netrek.org. It is the list where the current Netrek server development team discuss the server. There are plenty of people there that can answer your questions offline. James Cameron is the current codebase head. Dave Ahn is the current res-rsa code maintainer. I can get you the res-rsa crypt key if you can prove to me you're a US citizen using the code for netrek, etc. --Carlos V. Re:how netrek really works (Score:1) by sheldon (sheldon@yuck.net) on Monday December 27, @05:23PM EST (#254) (User Info) http://www.sheldon.visi.com It is a difficult question to ponder. If you can solve the man in the middle attack I think it is somewhat workable. There is likely some method of doing this using information specific to the client computer as part of the encrypted key. Such as the IP address, etc. The difficulty there lies in trying to play from behind a firewall. Another comment... just to clarify, the exact source is not released because it is actually generated during the build based on the input parameter of the RSA private key. Really the full source is easily available, and anybody can compile a client, it's just that you need a RSA key that has been accepted by the servers to be useful. Oh, and it's correctly spelled Netrek! :) The only solution is social (Score:1) by ziegler on Monday December 27, @06:12PM EST (#264) (User Info) As a programmer, I understand the difficulty, if not impossibility, of finding a techical solution to this problem. However, I don't feel a techical solution is needed. I think making some servers "Cheat Servers" will solve the majority of the problem. As a programmer, I like the idea of making a "cyborg" client which is a combination bot + user. I think I could add a new aspect to the game. If you were to use these clients on a normal server, you would be cheating. If, instead, you have "Cheat Servers" where this kind of play is accepted, then there is no longer a problem. Admittedly, there will people who cheat on the normal servers, but that's why you have "kick." Most people will play by the rules. Just my $0.02, - Sam Re:how netrek really works (Score:0) by Anonymous Coward on Monday December 27, @07:32PM EST (#280) I think the only solution is to require that players are trusted. When you try to play a game you authenticate yourself. Even with a signed binary, you can watch the processes data to see where opponents are. You'd have to obscure the run-time data to stop this (it would be fairly easy to crack for someone with a few days to spare), and this will require a really good OO design to keep out the bugs. As said, their is no solution if the client is trusted in any way. Your trusted closed-source proxy must even perform the rendering to stop altered clients from recognising where the opponents are, and aiming. -- Tristan Wibberley Netrek is different from Quake in many ways... (Score:1) by sheldon (sheldon@yuck.net) on Monday December 27, @05:37PM EST (#256) (User Info) http://www.sheldon.visi.com I think a large aspect of this, which does actually go back to Mr. Raymond's comment on trading performance for security, is that Netrek is designed in such a way that all the game logic is stored on the server. The client only displays what the server offers it, no additional information is available for it's use. Essentially, even though the Netrek clients have been blessed and trusted in some manner, in reality they aren't trusted at all. The server does not provide sufficient ability to the client to even allow it to cheat. What we regard as cheating in the Netrek community is using computer based crutches to supplement your lack of skill. That could be auto-aim, or displaying cloaked ships, etc. This game architecture obviously came about due to the open source nature of the game. It's rare that I actually agree with Eric Raymond on anything, so I think this must be an amazing realignment of the planets and stars. :) But as someone else pointed out in another article, the computerized players are not much better than the best human players, and in many aspects of the game are worse. And this my friends is an example of why Netrek is a superior game to Quake. :) Seriously, Netrek has depth to the game, it's not just about who has the fastest trigger finger. In some cases not firing at an opponent is a smart move, and a large part of learning the game is understanding such strategies. We call it 'clue'. Quake wasn't originally written for the internet (Score:3, Interesting) by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @11:44AM EST (#9) (User Info) Quake was written for single player and for multiplayer over a lan like doom. When internet play became an issue and quake's inability to do it well, especially for modem connections, quakeworld was written. Keep in mind that Quake wasn't designed with internet play in mind. It was hacked in afterwards. Not strictly true... (Score:1) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @12:23PM EST (#97) (User Info) Quake was designed with the Internet in mind from the beginning, but Carmack underestimated the effect of modem latency. His infamous plan update went something like, "well, I have a T1 to my house, so I didn't realize how bad modems were." or words to that effect. :) --- Judge all, but be prepared to be judged by all. Re:Not strictly true... (Score:1) by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:51PM EST (#127) (User Info) Ohh yes, I do remember this quote. However I do believe that my original statement is true. Originally multiplayer quake was just between clients before quakeworld and dedicated servers came about. I started playing quake online after quakeworld had come out. I guess what I'm really trying to say is that multiplayer was secondary to single player when quake was being developed. Re:Not strictly true... (Score:0) by Anonymous Coward on Monday December 27, @02:30PM EST (#182) Dedicated servers were a part of Quake before QuakeWorld. Quake WAS designed as an Internet game and in fact "NetQuake" as it's now referred to (as opposed to QuakeWorld) is still played by many people over the Internet. QuakeWorld, however, with its "client-side prediction", was a big leap ahead in terms of gameplay for those with slower connections. Re:Not strictly true... (Score:0) by Anonymous Coward on Monday December 27, @02:30PM EST (#183) FWIW, I was playing Quake Shareware on the net the day it was released... Re:Not strictly true... (Score:1) by Defiler on Monday December 27, @02:49PM EST (#195) (User Info) Quake shipped with a dedicated server mode. You're mis-remembering. QuakeWorld introduced such things as client-file CRC checking, and client-side prediction. Re:Not strictly true... (Score:2) by Otto on Tuesday December 28, @09:17AM EST (#335) (User Info) http://slashdot.org/comments.pl?sid=Otto Ohh yes, I do remember this quote. However I do believe that my original statement is true. Originally multiplayer quake was just between clients before quakeworld and dedicated servers came about. I started playing quake online after quakeworld had come out. I guess what I'm really trying to say is that multiplayer was secondary to single player when quake was being developed. Now that's hardly a fair statement. Internet multiplayer was the main point of the game in fact. Quake world was developed "to test new ideas in internet multiplayer capabilities". That's it. Nothing more. Quake could do servers and dedicated servers from the beginning (Although the dedicated server was a separate executable). Ahh back in the day.. John always hated talking to people to get feedback because he never really thought of security issues on his own, you see. I recall the reply he gave when someone suggested making a skin the same texture as the wall so as to not be seen. He replied, "I really wish you hadn't brought that up." Anyway, the idea of bots was created by someone when the game was still under development, in alt.games.quake. I participated quite a bit in that discussion. Our idea was essentially to create a bot using the networking code. The proxy bot didn't occur to us, nor did we know that the "quakescript" language was powerful enough to do it. We thought, hey, why not just write a program that reads the network protocol, and can compete on the server? Simple, no? Anyway, then it evolved into ideas of putting different bots against each other, to see who had the best bot. Anyway, the Stooge bot came out later, and it was essentially what we were thinking of, except that it did no navigation, requiring a human to do that. Also, we had thought that the server was more robust in not allowing players to break the rules of the world (rapid firing, instant precision spins, etc). Essentially, Carmack relied too much on the client for the integrity of the game. Not that that's terrible, I would have probably done the same, because it made the game faster and therefore better. But it also opened up that door to cheating. Oh well. --- "Never underestimate the power of human stupidity." - Lazarus Long Right (Score:1) by Yebyen (yebyen@adelphia.net) on Monday December 27, @11:44AM EST (#10) (User Info) http://home.adelphia.net/~yebyen/ Once again, ESR astounds me by coming up with a viewpoint I didn't know I agree'd with. Closed source is just as hackable as open source, it just protects itself by luck. Peer review has always been, is now, and may always be the best way to make something totally flawless, or at least come as close as possible. Damn the man [page] Re:Right (Score:1) by sracer9 (sracer9@my-*no*deja*spam*.com) on Monday December 27, @12:25PM EST (#100) (User Info) My thoughts exactly. It's a scary thought to think how many *more* vulnerabilities might be in win9x/nt *if* only we had the source to look at. When development models are closed, the general public *assumes* that the developer plugged up all the holes. When source is released, however, *everyone* can see the holes and plug them up - thereby eliminating (or at least minimizing) security concerns. Re:You can't be serious (Score:2, Informative) by KaosDG on Monday December 27, @12:25PM EST (#98) (User Info) http://www.condemned.net Uhm, coming from an old binary hacker, Closed source *is* as hackable as Open Source... Once you understand the Architecture of the system you're running on, and get to know it's Assembly language, you can modify *ANY* binary to do what you like. Hence the numerous dongle cracks / reg key bypassers that are out there for many Closed source programs. (I remember ads for dongle's calling them "uncrackable") With open source, you have to look into the source code and try to determine what this particular algorithm does... then you have to know how to re-work the algorithm (or determine the ramifications of removing that part completely) to get it to do what you want. With a closed source binary all you have to do is run a traceable debugger on the binary, and then you get down to the nitty gritty of what's happening. It can be as simple as inserting (in x86 terms) a JMP statement or a NOP... "Fuzzy Wuzzy was a bear, Fuzzy Wuzzy had no hair... Fuzzy Wuzzy wasn't fuzzy was he?" Re:You can't be serious (Score:0) by Anonymous Coward on Monday December 27, @02:00PM EST (#169) Closed source has the potential to be as hackable as open source, however on the average it is not. Most people don't want to spend their time wading through assembly code to figure out what is going on in a game as complex as Quake. That explains why this problem has just come to light. I agree, over time an open source solution becomes pretty darn secure. However, by keeping source code closed, it makes it MUCH harder to hack it. I guarantee you, the average hacker/programmer does not know assembly language, and as time goes on, and software/computers become more complex, they wont care to learn it either. The problem with open source, is there will always be ways to hack/crack a system. I think it helps developers put security in the front of their mind, however it is not the end-all solution to security. It's a tradeoff. Easier to hack vs. Developers increasing the priority of security issues. Didn't I say that (Score:0) by Anonymous Coward on Monday December 27, @03:29PM EST (#207) Seriously. Read the whole post before you hit the keyboard. Of course closed source is hackable. But not by an Joe who just fell off the turnip truck. Open Source on the other hand..... Geeess. open souce - Give 'em a map and then get pissed that they found a way... Re:You can't be serious (Score:0) by Anonymous Coward on Monday December 27, @02:09PM EST (#172) You should ask Bill Gates to unclench his buttocks, so you can pull your head out. God, MS plants piss me off. Re:You can't be serious (Score:0) by Anonymous Coward on Monday December 27, @02:32PM EST (#185) Put down the crackpipe - just because someone is pro-MS on a particular topic does not make them a "plant". Lay off the X-files for a while, huh? Yes, I'm an MS Plant (Score:0) by Anonymous Coward on Monday December 27, @03:31PM EST (#208) Yes, I am an MS plant. Gees. A bit too much of the x-files there crackhead. Mmmm. Why is it that Open Source/Linux advocates loose creadibility. Oh yes, it's because they open their mouths.. If you have an arguement fine, but otherwise shutup. Saw this coming (Score:1) by Sludge (sludge@SPAMREMOVE.atdot.org) on Monday December 27, @11:45AM EST (#13) (User Info) As a long-time Quake player who knows the inner workings of Quake quite well, I saw this coming. In fact, I posted a request for an 'ask slashdot' a bit under a year ago about this topic, but it never got posted on the webpage. Guess I should have written Quake for it to have been valid. I wonder if this was foreseen by ID before the code was released. ( I say ID because Carmack gives credit to others for doing the grunt work of making the code releasable. ) If so, the protocol should have been modified or ripped out of the clients that were OSS until someone DID take these security measures, at which time ID would re-release the real source tree. If someone does make this cheating verification software, I recommend that they make it more open ended than for just Quake. I think this sets a precedent for Open Sourcing network games, and if a solution is readily waiting, people will be more open to open their code. Michael Labbe (not the pedophile) Re:Saw this coming (Score:0) by Anonymous Coward on Monday December 27, @12:09PM EST (#70) A few years back I had the idea of a Quake Mod which would put a little radar thing up on your screen. The server sends the client sound info, and it must specify how loud and what direction it is comming from. It wouldnt be hard to create a simple radar system to keep track of exactly where sounds were comming from, especially with foot steps implemented in Q2/Q3. All due respect . . . (Score:2, Interesting) by gnarphlager on Monday December 27, @11:46AM EST (#14) (User Info) . . . but wasn't this what everyone else was saying the other day? I mean, it's good that it's coming from someone respectable in the Open Source world (oh, hush Stallman ;-), and predictably it seems written to use a trivial(?) example to serve as evangelitical text to the non-believers. But at any rate, is this the place for it? I know I weigh Slashdot discussion (-inanities of course) almost as much as words from a "spokesman" for the community. I agree with what he says, but I'd have thought us discussing it would be all the swaying we need. I don't need top-level affirmation that what I believe is right. I personally think (and hope ESR does too) that this is the sort of thing you post to a non-community news source. Let's face it, a good percentage of Slashdot readers are Open Source people. No need to preach to the converted. It's a great parable for the benefits of Open Source, but we know all that already. Oh, and is this affecting Q3 too? I thought it was just relevant in Q1 (the game with the open source). I don't know; I'm a Drakan player ;-) Re:All due respect . . . (Score:0) by Anonymous Coward on Monday December 27, @01:37PM EST (#151) Well, the obvious answer is that this article was a troll for reporters who couldn't be bothered to read the first post marked '5 Insightful' on the original discussion. You have to give them a well known name so they can reprint it for all the clueless reading the Wall Street Journal. I wish I were kidding. That's what I said yesterday! (Score:1) by Anonymous Coward on Monday December 27, @11:46AM EST (#15) My thoughts exactly ESR! Who really cares if Q1 clients are bastardized? The more important issue is can a malice-proof Quake client be created entirely in open source? I think it can and like I said yesterday the solution will have far reaching implications for secure networking. Re:That's what I said yesterday! (Score:1) by Foogle (foogle@adelphia.net) on Monday December 27, @11:49AM EST (#21) (User Info) Is is just me or is "far reaching implications for secure networking" a pre-fab, pointy-haired phrase? ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants Re:That's what I said yesterday! (Score:2) by phil reed (phillipcreed@yahoo.com) on Monday December 27, @11:58AM EST (#44) (User Info) Only if you consider network security a pointy haired boss issue. ...phil "For a list of the ways which technology has failed to improve our quality of life, press 3." Re:That's what I said yesterday! (Score:1) by Foogle (foogle@adelphia.net) on Monday December 27, @12:10PM EST (#76) (User Info) no, no, I have no problem with the subject or the content. It's just the phrase that got me :) ----------- "You can't shake the Devil's hand and say you're only kidding." - They Might Be Giants ESR bright ideas appear once again! (Score:1) by papo (papo@uninet.com.br) on Monday December 27, @11:47AM EST (#17) (User Info) He is right showing the problem is an exchange between performance and security. But we must think if we want Quake's server to become slower, creating a lesser quality game in the network, or if we mantain the same characteristics on the server and let some hackers take the advantage out of it when coding the client(I think they deserved it. It's not anyone who can do this type of hacks!). Of course that softwares who are used in systems who need more security(like web servers, financial systems, etc.) must surely trade performance for a better protection against clever client coders. "Learning, learning, learning - that is the secret of jewish survival" -- Ahad A'Ham Re:ESR bright ideas appear once again! (Score:1) by Dfiant on Monday December 27, @01:52PM EST (#164) (User Info) http://dft.hypermart.net It may not be anyone who can make Quake client cracks, but anyone can certainly distribute them for others to use...therein lies the problem. =) Re:ESR bright ideas appear once again! (Score:1) by gregm on Monday December 27, @11:05PM EST (#297) (User Info) Not only *can* they distribute the hacks, they are forced to by the GPL :) OS has it's place, that's for sure, but net games may not be the place. Nitpicks (Score:5, Insightful) by CrusadeR (crusader@linuxgames.com) on Monday December 27, @11:47AM EST (#18) (User Info) http://www.linuxgames.com Some issues with this article: A) This is the Quake 1 source Rob, not Quake 3 :) B) ESR states: If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers. I fail to see how if Quake had been open source software from the beginning, how the situation would be any different. Quake is a fast action game that is often played over connections with high latency, the dependency on "millisecond packet timing" is inherent to the game itself due to how quickly entities manuever in the game world. Similarly, trying to build aim bot detection into the server from the beginning, as you suggested, would run into the same wall its hitting now: some players have enough skill that some form of statistical analysis would conclude they are using an aiming proxy. :wq Re:Nitpicks (Score:1) by Mao (pingshun_c@yahoo.com) on Monday December 27, @02:33PM EST (#186) (User Info) Yea, i can follow most of what ESR said, except the part about having quake open-sourced way in the beginning. And i think a lot of posts on this forum will be directed at that. Perhaps it would be better if ESR give an example of how that can be a solution. Otherwise i don;t see how on e can avoid that infamous Turing test problem. Re:Nitpicks (Score:0) by Anonymous Coward on Monday December 27, @06:22PM EST (#266) "Turing test problem"??? Do you suspect that ESR is a computer masquerading as a human? Re:Nitpicks (Score:4, Insightful) by WNight (wnight@rocketmail.com) on Monday December 27, @02:55PM EST (#197) (User Info) Designing Quake in open source wouldn't solve the problem of writing aim bots. Aim bots take that knowledge the play has, or could easily have (by looking behind them) and acting upon it. But, designing Quake as open source, and seeing how easy a hack like making players show through walls, for instance, would be could be expected to lead to different design choices. Quake uses the PVS and PHS (potentially visible/hearable sets. The PVS is the list of all 'areas' visible from the player's location, and the PHS is the PVS and all PVSes...) for knowing when to send information about one player to the next. In some fairly connected levels, the PHS is *huge* and the client knows where the other players are far in advance. This could be changed to use an algorithm to determine the quickest route for both entities to take before being visible to each other, and if that's under the update delay (ie, likely to happen before the next upate) then the information would be sent. Otherwise, it wouldn't. Thus, cheaters would have a much smaller window of opportunity. One other 'bug' is that if the player models are replaces with a big pointy model, where each axis has a big arrow, you can see these arrows far ahead of the actual player, even through walls and floors (in the other player is in your PHS). Writing the code, in many spots, to generate errors if the models were above a certain maximum reasonable size, and if they passed through world brushes, would make this a non-trivial hack, unlike now where you load the models into an editor, add a couple of points, and boom, can see people through walls. The skin, the image that wraps around the wireframe, can be altered. A white skin naturally shows up better in shadows than a dark one. In Quake some colors are 'full bright', meaning that they 'emit light'... A skin made up on these literally is visible in complete darkness. If they changed the renderer to not use these drawing modes for characters skins, this would eliminate this easy for of cheating. A skilled programmer could add this in, but it would take a lot more work than simply opening up MS Paint and flood-filling a PCX... Also, the design of the basic game could change a little. Quake 1 had few instant-hit weapons. The shotgun and the lightning gun are the only ones. Bots of course favor instant-hit weapons because they don't have to predict the enemy's movements, they simply line up the crosshairs and fire. The shotgun isn't a big deal because it's fairly low damage and the spread makes it less effective at medium or long range. The lightning gun is a Quake1 bot's favorite weapon. Knowing this, they could have designed the game to reduce the effectiveness of the lightning gun in such a way. Perhaps it's heavy and induces some movement lag on the character, preventing instant-turn shot... These are many ways the game could have been changed to prevent there from being a perfect weapon for the bots. And really, the lightning gun, and later the railgun, are no-brainer guns. All it takes are reflexes and a fast computer/vid card. Other weapons take thought, to predict the enemy movements, something a bot isn't good at. There are *many* design changes they could have, and pretty well, would have to have made, if Quake 1 was designed with open source in mind. Re:Nitpicks (Score:1) by C=64 on Monday December 27, @04:25PM EST (#234) (User Info) Quake uses the PVS and PHS (potentially visible/hearable sets. The PVS is the list of all 'areas' visible from the player's location, and the PHS is the PVS and all PVSes...) for knowing when to send information about one player to the next. In some fairly connected levels, the PHS is *huge* and the client knows where the other players are far in advance. This could be changed to use an algorithm to determine the quickest route for both entities to take before being visible to each other, and if that's under the update delay (ie, likely to happen before the next update) then the information would be sent. Otherwise, it wouldn't. Thus, cheaters would have a much smaller window of opportunity. I might be inferring this incorrectly, but it sounds like your saying using the PHS at all is a bad thing. If that's the case, all I can say is NOT using the PHS is a BAD thing. It's a TREMENDOUS speed up, keeping the server from having to do a massive amount of expensive tests per player at *ever-single-moment*. And, this still won't help in the repetitively specified "around the corner" cheat, would it? It was because of ingenious and quite frankly vital tricks like these that Quake performs so, SO well compared to the rest of the FPS pack (remember Unreal?). One other 'bug' is that if the player models are replaces with a big pointy model, where each axis has a big arrow, you can see these arrows far ahead of the actual player, even through walls and floors (in the other player is in your PHS). Writing the code, in many spots, to generate errors if the models were above a certain maximum reasonable size, and if they passed through world brushes, would make this a non-trivial hack, unlike now where you load the models into an editor, add a couple of points, and boom, can see people through walls. Polygon accurate collision detection == expensive. Isn't that what would be required to see if a model passes through world brushes? Also, won't enforcing an arbitrary size limit reign in on the amazing amount of flexibility purposely built into the engine in the first place? The skin, the image that wraps around the wireframe, can be altered. A white skin naturally shows up better in shadows than a dark one. In Quake some colors are 'full bright', meaning that they 'emit light'... A skin made up on these literally is visible in complete darkness. If they changed the renderer to not use these drawing modes for characters skins, this would eliminate this easy for of cheating. A skilled programmer could add this in, but it would take a lot more work than simply opening up MS Paint and flood-filling a PCX... Again, isn't this cutting back on the flexibility of the engine? Lets say I want to make a mod that's a crawler though a mine shaft, with glowing lights on the players helmets. Or maybe I'm making a mod in a fantasy setting, with a few fantasy models, like beasts with sinister glowing eyes, or glowing pixies. The Quake engine was made flexible for a reason! Also, the design of the basic game could change a little. Quake 1 had few instant-hit weapons. The shotgun and the lightning gun are the only ones. Bots of course favor instant-hit weapons because they don't have to predict the enemy's movements, they simply line up the crosshairs and fire. The shotgun isn't a big deal because it's fairly low damage and the spread makes it less effective at medium or long range. The lightning gun is a Quake1 bot's favorite weapon. Knowing this, they could have designed the game to reduce the effectiveness of the lightning gun in such a way. So, we are now required to compromise gameplay to make sure folks don't cheat. Boy, it's almost like this ain't a game anymore! Are we also required to put code in a restriction for mods including anything like this? I hate to have to say it, but don't you think (and I'm not referring to you specifically Nitpicks), considering how much effort they put in, and flat-out AMAZING things the good folks at id did, they would have *considered* doing some of these? I'm sure they've tried to make it as secure as they can, given the restrictions of real-time, low bandwidth use and engine flexibility But every suggestion I've been hearing that id "should have put in" is a definite step away from those 2 overriding design goals. One of the reasons quake is so gash-darn fun is because of all the stuff folks have been able to do with it to make it fun! I love the grapple hook, I love the mods folks make (especially some of the absolutely fabulous total conversions), I love the responsiveness... To have taken these out when the game was created (assuming that the open-source community would have implemented these things that have been suggested) would have really taken away from the game. And there's a reason we all care so much about Quake's source code and player cheats; We all love the game SO much. Just my 2 cents... Re:Nitpicks (Score:2) by WNight (wnight@rocketmail.com) on Tuesday December 28, @02:26AM EST (#310) (User Info) [...] limit reign in on the amazing amount of flexibility purposely built into the engine in the first place? Sure, and they didn't implement skeletal animation, which reduced the number of mods. And they didn't implement specular highlights, or accurate sound reverb, or a million other things. These all limit the flexability of the engine, but none of these lacks ruined the game. A lack of fullbright colors could be more accurately represented with light generation, if it was *needed* in a mod anyway. Changes in Quake mean that the new game wouldn't be exactly like Quake, but that's not a bad thing. Quake wasn't exactly like doom, yet still rocked. Quake isn't gospel, and changes to it aren't heresy. I might be inferring this incorrectly, but it sounds like your saying using the PHS at all is a bad thing. If that's the case, all I can say is NOT using the PHS is a BAD thing. It's a TREMENDOUS speed up [...] Yes, using the PHS is a speed up. It's a kludge. Imperfect results, but close enough for government work, and results in a speed increase. But, if they had thought about the Stooge bots, and ZBots of the future, they might have decided that a bit of speed was a good trade for less chance to cheat. Having a more accurate PHS and PVS, to determine when sounds and enemy models are sent would save network traffic, and would drastically reduce the chance of cheating. With a large PVS, someone can be directly opposite you on a wall, like in the Q1 start map by the inital start spot. The location of their model will be sent to you even if you've got a wall between you, because you're in the same PVS leaf. This would happen in a long hallway too, where clients seperated by 10 seconds of running could be 'visible' to each other, through the walls. Not only is this a waste of bandwidth, but it gives the cheater ample time to identify their enemy's movement. If models were sent only when they could possibly be seen, you'd have a flicker of warning before the enemy ran around the wall, if you were cheating, but you wouldn't have the seconds of warning you often have. Recording the shortest distance between all portals visible to each other, like a mini-vis table, would speed distance calculation. Do a search from the player, to the nearest portal, to the one next closest to the enemy, etc, to the enemy. If the shortest distance is N units, send model info. Certain bizarre rooms, with millions of pillars for instance, would play havok with these, but they already kill performance for vis reasons... This isn't a perfect solution, and it just what I came up with in a few minutes. I'm sure Carmack, with testing could come up with something better, if cheating prevention was higher on their list of priorities. Yes, the game is incredible. But it was made with goals other than being cheat resistant. Yes, all ideas mentioned would limit either speed or flexability to a degree. But, have you ever heard "One time, Under Budget, Error Free - pick two"? Everything involves tradeoffs. They didn't make some because their priorities were different than they are now. Re:Nitpicks (Score:0) by Anonymous Coward on Monday December 27, @06:21PM EST (#265) aim bots were a problem before the open sourcing. I've played people using zbot on Quake2 (which is obviously not yet open sourced) and they will fire a rocket as you run down a hall, so it meets you the millisecond you become visible (implying the too much info bug too). This was all done using quake mod dlls. The only cheat I've seen so far that pretty much requires (well, it could be done on a binary, but it would be VERY difficult) open source client is the "show enemy as a circle if they're not visible" trick. Re:Nitpicks (Score:0) by Anonymous Coward on Tuesday December 28, @02:08AM EST (#309) The only thing reducing instant-hit weapons or adding client statistical analysis would do is add a few hours to the design time of a cheat. :) Besides, most of the good quake 2 proxies already handled 'slow' weapons like the rocket launcher with unbelievable skill (aiming at the feet of the predicted player location given rocket speed, etc). The best of them even parsed the level so they wouldn't shoot walls! Remember, these were all for a closed-source game. ;) Re:Nitpicks (Score:2) by WNight (wnight@rocketmail.com) on Tuesday December 28, @02:44AM EST (#315) (User Info) Parsing the BSP is fairly simple. I mean, the specs for the format are published, and the format makes sense, it was picked for ease of use and speed, not obscurity. (Worst comes to work, run a Q2 bot with a side-by-side mod that simply exists to do traceline calls between the bot and it's victim, using the actual Q2 engine itself.) Shooting at feet and such is trivial. If the weapon is the RL, aim lower... What's hard is using area-denying weapons to herd players. Spam a few grens in an area, not to hit the enemy, but to keep them from running there. Then work them towards a spot you can hit them from a distance by shooting around them, gradually narrowing the net, forcing them to move to the shrinking safe area or take damage. I've never seen a bot handle this well on either end. They don't understand delayed gratification. They don't understand trying to miss when you have a low chance of hitting, because of a much higher chance later. Similarly, they are easily trapped, not realizing some splash now is better than being herded into lava later. Movement analysis is fairly easy. To figure out how the enemy moves around and shoot them. What is hard to being able to do clever things instead of making impossible shots. Re:Nitpicks (Score:2) by WNight (wnight@rocketmail.com) on Tuesday December 28, @02:38AM EST (#314) (User Info) As soon as they hire me, to do what is immediately obvious to anyone smarter than a troll. If id was going for cheat-proof, they'd have done this long ago. They're not, they're going for other goals, and making some tradeoffs. Two people can both be right and come up with different answers, if they ask slightly different questions. Id's priorities are not the same as when they first wrote the game, and are not the same as mine would be, were I to tinked with the source now. The way I see it (Score:0) by Anonymous Coward on Monday December 27, @05:57PM EST (#258) Quake was designed and implemented by experts in the feild. Surely if they had even considered security to that extent, they would have seen the holes. Fact is, even if it was open sourced from the beginning...how likely is it that people would have thought of these holes when several *experts* did not? Fact is, its just a fucking game. Who, in designing a game, is going to sit there and think of all the ways an assmonkey could possibly cheat? Its supposed to be fun for the person playing, so if they enjoy cheating....fuck it, let em. Isn't that why so many games are built with cheats included?? At any rate, I think it is likely that had those holes been seen by someone who was looking at the opensourced code, it is a high probability they would have been ignored. The cost to filling them would outway the playability...which is the highest priority in game design, not security. If your building some sort of money exchanging program, of course you are going to plug all holes, no matter what the cost in bandwidth is. But for a game, common, this isn't fort nox here, and shouldn't be. In my oppinion, it would not have mattered in the slightest. jik- Quake 1 src no lump of coal (Score:2, Interesting) by poopie on Monday December 27, @11:48AM EST (#19) (User Info) I think ESR's calling the release of Q1 src a lump of coal in hacker's stockings is a bit extreme. Even the ensuing debate over multi-user game/world security models is very significant for future development. Now that Q1 src is opensourced, what's to stop those of us who are so unhappy with the network play model from re-implementing it?? If we can come up with a better, faster, tighter, cross-platform, secure model for network gameplay, I'm sure that many game developers would be interested in adopting it. so, let's start designing and implementing the new protocols for networked online worlds! Thanks to John Carmack for the Q1 src which has fueled so much thought about gaming, AI, virtual communities, new user interfaces.... and much more. ... and thanks for the linux port when all the other game companies were writing to Windows only. Re:Quake 1 src no lump of coal (Score:1) by UnclPedro (aaron at semo dot net) on Monday December 27, @12:00PM EST (#50) (User Info) I think he was saying that the lump of coal was not the source itself, but rather the closed solution Carmack proposed to fix the cheating problems. ------ Bara för att du är så fenomenalt jävla duktig och aldrig stavar fel jävla AC. Yeah. Re:Quake 1 src no lump of coal (Score:1) by ESR (esr@thyrsus.com) on Monday December 27, @12:18PM EST (#85) (User Info) http://www.tuxedo.org/~esr/ UnclPedro is correct. -- >>esr>> Protocols for online worlds (Score:2) by Bryce (bryce@neptune.net) on Monday December 27, @01:45PM EST (#157) (User Info) http://www.worldforge.org Even the ensuing debate over multi-user game/world security models is very significant for future development. If we can come up with a better, faster, tighter, cross-platform, secure model for network gameplay, I'm sure that many game developers would be interested in adopting it. so, let's start designing and implementing the new protocols for networked online worlds! A number of game development projects have been working at exactly this; it might be worthwhile for those interested in working on such a protocol to see what's already in the pipeline. Freetrek and Netspace both have just recently started development on 3D protocols for space-flight. WarForge, Phoenix, Lycadican, Cyphesis, and Belchfire are all using WorldForge's "Atlas" 3D RPG protocol (libatlas2 was just completed last week). Join WorldForge (www.worldforge.org) Re:Quake 1 src no lump of coal (Score:1) by seyed (seyed@kmpinternet.com) on Monday December 27, @01:51PM EST (#163) (User Info) http://www.kmpinternet.com I think ESR's calling the release of Q1 src a lump of coal in hacker's stockings is a bit extreme. I think ESR was referring to the .plan file from Mr. Carmack calling for a closed source solution to the cheating problem. "Everybody's Got Something to Hide Except for me and my monkey" - The Beatles "If you're not part of the solution, you're part of the problem" - Dr. M. L. Nice handwave (Score:5, Insightful) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @11:49AM EST (#20) (User Info) Fortunately, the aim-bot cheat is also much less interesting from a general security point of view. It's hard to imagine anything but a twitch game in which the client user can cheat effectively by altering the millisecond-level timing of command packets. So the real lesson of both cheats may be that a closed-source program like Carmack's hypothetical secured program launcher is indeed a good idea for security -- but only if you're a hyperadrenalized space marine on a shooting spree. Uh, with all due respect, THAT IS THE MAJOR PROBLEM!! You in essense admit that this problem is unsolvable, then go on to say that it's really not a problem that anyone that's important (to you) cares about. Well, trivializing the problem by mocking quake fans doesn't make the problem go away, and it doesn't change the fact that open source has made the problem infinitely worse. Then, of course, you go on to conclude that open source is the ultimate answer (while giving no evidence). ESR, normally I'm with you, but this essay was major smoke and mirrors. --- Judge all, but be prepared to be judged by all. Re:Nice handwave (Score:1) by lnovak on Monday December 27, @12:00PM EST (#48) (User Info) Perhaps, in the highly constrained environment that is the Quake universe, there is no way to distinguish between a human and computer player. I believe a Dr. Turing proposed a test to do just that. suffering from pronoia hmm... (Score:1) by ph43drus (EATph43drus@WITHAhomeSPORK.com) on Monday December 27, @01:23PM EST (#142) (User Info) http://24.5.73.229 Ok, so we throw out a couple of conversational tidbits, and get fragged as a responce? Jeff Wasting Time is an important part of living. Re:hmm... (Score:1) by lnovak on Tuesday December 28, @08:31AM EST (#330) (User Info) I'm not sure what to make of your reply. While I admit my post lacks the depth of the usual slashdot entry and as my partner likes to say, "I get what I deserve", my point was that distinguishing between human and machine players is a problem independent of the development philosophy and will only get more difficult in the future. BTW, I have a friend who likes to eat with a spork though his name is Fred. suffering from pronoia Re:Nice handwave (Score:1) by billybob jr (bodell.no.spam@ihatespam.purdue.edu) on Monday December 27, @12:11PM EST (#77) (User Info) In Carmack's plan he doesn't specify what kinds of cheating have been used since it was open sourced. Or what kind they are afraid of. Is the open source client more vunerable to aim bot type cheating? Or is it just more vulnerable in general? Re:Nice handwave (Score:2, Informative) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @12:20PM EST (#91) (User Info) Aimbots have already been written even for the closed source version via a shell program that sits between Quake and TCP/IP. Obviously that program was a lot harder to create than a simple hack to the source code to create auto-aiming. --- Judge all, but be prepared to be judged by all. Re:Nice handwave (Score:2, Insightful) by Sloppy (sloppy@spam^H^H^H^Hrt66.com) on Monday December 27, @12:18PM EST (#86) (User Info) trivializing the problem by mocking quake fans doesn't make the problem go away, and it doesn't change the fact that open source has made the problem infinitely worse. The unsolvable problem of aimbots is not a direct consequence of Open Source. An aimbot is possible with closed source too; it's just harder (but still possible) to implement. If anything thinks that the closed source "solution" will really protect them from cheaters, then perhaps they deserve a little mockery. How do you know that open source has made the problem worse? People could have been using aimbot cheats all along, without your knowledge. At least now, the problem is exposed. Then, of course, you go on to conclude that open source is the ultimate answer (while giving no evidence). Did you read the same article that I did? ESR does give a good argument that Open Source is the answer. His argument is that if Quake had been originally developed with the understanding that security-through-obscurity would fail (instead of this simply being realized after it's too late), then the protocol would disclose less information to the clients. If Quake had been Open Source from the beginning, then the "more information" cheats never would have been possible. I think this is a substantial and compelling point, hardly "smoke and mirrors." --- Have a Sloppy night! Re:Nice handwave (Score:1) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @12:33PM EST (#107) (User Info) If the program had been open source from the beginning, absolutely nothing would be different. The protocol is designed the way it was to make a "twitch"-style game possible over high-latency Internet connections. It's not as if Carmack while smoking his crack pipe suddenly thought "I think I'll give tons of control to the clients"! Open Source development won't magically make latency go away. The only difference if it had been Open Source from the beginning is that the Quake phenomenon may never have gotten started, because cheating would have been so easy. --- Judge all, but be prepared to be judged by all. Re:Nice handwave (Score:2, Informative) by funaho on Monday December 27, @02:15PM EST (#175) (User Info) http://www.jurai.org/~funaho/ Not only is the aimbot possible without open source but I have a friend who did it a couple years ago. It wasn't much fun to play against a guy who could kill you with an axe without taking a single point of damage himself. :) (it _was_ neat to watch though; the bot would let you run in a circle around the victim faster than they could aim, all while hitting them with the axe. It also did auto-aim, did motion prediction so it could fire ahead of players, and even knew how to aim at the wall in front of a player with a rocket so they got explosion damage while the bot switched to another weapon and hit 'em with that too) Re:Nice handwave (Score:1) by otomo_1001 on Monday December 27, @02:43PM EST (#191) (User Info) Sweet swirling onion rings that sounds cool. Who was this guy and will he open source this? (I have no plans of using it but the code behind it sounds extremely interesting) -If I had a good quote, It'd go here. -me COOL! (Score:0) by Anonymous Coward on Monday December 27, @08:35PM EST (#288) Sounds like another wanker taking a break from masturbating. Why cheat? It is fun without cheating. Only fucking asshole cunt lusers cheat. ESR hits home once again (Score:2) by Johan Jonasson (johanjonasson@usa.net) on Monday December 27, @11:51AM EST (#23) (User Info) I first thought, who the hell cares about a bunch of punks cheating in a shoot-em-up? For me, when I first heard it about it I thought, hey, let them cheat, it's not relevant to the Open Source community anyway. ESR proves me wrong. Again. He sees things that would normally escape the naked eye. I guess that's why he's our No.1 spokesman, right? - JoJo Support anti-Spam legislation. Join CAUCE. Re:ESR hits home once again (Score:1) by rapett0 on Monday December 27, @03:47PM EST (#218) (User Info) http://sac.uky.edu/~rapett0 Can we please take some of these Linux people off their collective high horses? I mean really, why is that every single move the community makes requires the pleasing of an acronym (ie ESR). Nothing against him, he has done a good job, but the release of the Quake source doesn't have a damn thing to do with him, and everything in the article has already been thought of or talked about for obvious reasons. Lets spend less time on beurocracy and more on coding! Re:ESR hits home once again (Score:1) by sql*kitten on Wednesday December 29, @04:12AM EST (#348) (User Info) http://www.kitten.org.uk/ FACT: Carmack is one of the most talented coders in the world today. FACT: ESR has written a few trivial pieces of sortware, but mostly, he just talks. Open Source: Choice of the Cheater's Generation (Score:0) by Anonymous Coward on Monday December 27, @11:51AM EST (#24) Forget generation X, now there's the open source cheater's generation! Finally, the lie of open source is being exposed for what it is. The real truth will come once the open source bubble bursts, and I can't wait till it does. Re:Open Source: Choice of the Cheater's Generation (Score:0) by Anonymous Coward on Monday December 27, @12:01PM EST (#53) I'm sure you and Bill Gates will be masturbating furiously to Britney Spears pics together until that time comes. Can't say i envy you Re:Open Source: Choice of the Cheater's Generation (Score:0) by Anonymous Coward on Monday December 27, @12:02PM EST (#57) Well bud, it looks like you don't have to wait too much longer. That bitch is about to burst! Re:Open Source: Choice of the Cheater's Generation (Score:1) by Judah Diament on Monday December 27, @12:06PM EST (#64) (User Info) http://cs.nyu.edu/diam7644 was that meant to sound like a kid in kindergarten or first grade? If you want to argue a point, prove what you're saying or keep quite!! Re:Open Source: Choice of the Cheater's Generation (Score:0) by Anonymous Coward on Monday December 27, @12:06PM EST (#66) Rot in hell M$ intern. What do they pay you to post on /. all day? Cuz I need a job and I'm good at trolling. If you know reply to this with a contact. I can telecommute so I can work from home. Here's a similar problem from the vlsi cad world (Score:5, Interesting) by taniwha on Monday December 27, @11:53AM EST (#26) (User Info) http://www.taniwha.com/nospam.jpg People want to be able to distribute encrypted IP (chip designs) to customers for simulation. There are a couple of reasons for this - IP providers want to protect their product - and they want to protect themselves from liability should the customer change the source and then blow a lot of money on building a bogus chip. Traditionally this problem has been handled in a closed source world with a public key/private key sort of setup with the private key (for decryption) and encryption algorithm embedded in the compiler binary somewhere. This leaves the IP provider's product at the mercy of the vendor of the CAD tool A few years back this all fell apart for Verilog, a popular simulation compiler, for various reasons the language runtime is extensible, it was also interpreted - this left a version of the compiler which contained symbols. An anonymous poster to comp.lang.verilog pointed out how to write a gdb script that set a breakpoint in 'yylex' and extracted the decrypted token from IP. All hell broke loose .... eveyone who'd ever sent encrypted IP to customers was now open to the world... So - back to the topic - does anyone have any idea how one can do this sort of thing in an Open Source world - send people secret stuff to be used by an OS program without giving away the secret? Given that the only schemes I've seen to do this rely on security-by-obscurity (as above) I suspect it just can't be done. Re:Here's a similar problem from the vlsi cad worl (Score:1) by Nimmy (spam@nimlabs.org) on Monday December 27, @12:10PM EST (#75) (User Info) http://www.nimlabs.org Of course. Public-key Crypto. Much like the ssh install, first time you run the progam, a public key is created for you. When you want to tranfer files, a connection is established (maybe even over ssh), public keys are exchanged, and off you go. The are excellent open source programs to do this already (OpenSSH, GnuPG, etc). The wheel has been invented, now its time to use it! (The even easier solution is not build it into the CAD program, just have people mail files securly with GnuPG/PGP. Why make CAD programmers deal with encryption, its not their baliwick!). Re:Here's a similar problem from the vlsi cad worl (Score:2, Informative) by taniwha on Monday December 27, @12:26PM EST (#101) (User Info) http://www.taniwha.com/nospam.jpg The even easier solution is not build it into the CAD program, just have people mail files securly with GnuPG/PGP. Why make CAD programmers deal with encryption, its not their baliwick! Ah - but remember the premise - the end-customer must not be able see the secret information - it's purely for use with a tool that sees the encrypted file and performs some action on it that in itself does not reveal the secret to the end customer Re:Here's a similar problem... (Score:3, Interesting) by WNight (wnight@rocketmail.com) on Monday December 27, @03:03PM EST (#199) (User Info) And, there's the problem. An untrustable system being expected to run a trusted program. It's theoretically impossible, even given perfect implementation. If they want this to work, they'd need to sell black-box PCs, which exist for this purpose only, and can be passed an encrypted file, decrypt it, check for bugs, and return a 'yes' or 'error in area x,y'... The system doesn't need to be, and in fact, shouldn't be, closed source. It just has to be designed in such a way that any tampering with it will render it unoperable before it's opened to the point where data can be read off of it. Nothing is 100%, so they'd need to set a target budget, like the model that is simply encased in black plastic is rated to take $100k to break, the model shipped in plastic, in a safe, guarded by the marines, is estimate to take $5M to break, etc. But the machine can't be modifiable by anyone 'untrusted' at any point. All modification need to be done by the trusted vendor of the product, who one expects to be bonded and insured, etc etc.. Only then can trusted programs be run on the system and be expected to be safe. Re:Here's a similar problem... (Score:1) by cnflctd (bolivar_smith.LeFt@TeStIcLe.yahoo.com) on Monday December 27, @04:23PM EST (#232) (User Info) There is an extra cost beyond the price of making lots of black box PCs, and convincing all your possible customers to put up with the inconvenience. While you're doing it, your competitor sends out his unprotected design for zero cost, the customers review it on their generic PCs, and Mr. Paranoid gets locked out of the market. What will your VC think of that business plan. :) Re:Here's a similar problem... (Score:2) by WNight (wnight@rocketmail.com) on Tuesday December 28, @02:35AM EST (#312) (User Info) They'll think you're incapable of reading the posts you reply to. The idea is that trusted computers, for limited applications *can* exist, provided all work done to them is done by a trusted company with trusted employees. You can send data to Bob, to get it processed, without Alice intercepting it, you can also keep Bob from actually viewing the data, he just supplies the black-boxes need to process it. You still need two trusted parties, but they don't have to be the two main parties, as long as one client is using a trusted and secure client. I doubt you'd sell many of these, but if data-havens ever become possible, it might happen. Ditto with a lot of off-site checking on stuff like circuits. Re:Here's a similar problem...maybe not impossible (Score:0) by Anonymous Coward on Monday December 27, @05:42PM EST (#257) "And, there's the problem. An untrustable system being expected to run a trusted program. It's theoretically impossible, even given perfect implementation." Maybe not, if you exclude chip tampering. See "Athlon KxSec ..." for reductio ad chip-um of the black box idea. With commercial protection motivations it could conceivably happen. Re:Here's a similar problem...maybe not impossible (Score:2) by WNight (wnight@rocketmail.com) on Tuesday December 28, @02:31AM EST (#311) (User Info) Sure. In this case, the chip is the black box, with extra stuff tacked on, at low levels. I still have doubts though... If the chip doesn't do onboard public key crypto, fast enough to swap banks of ram in and out, then this can't work. It'll only work if the only data outside of the trusted area is encrypted. It could happen, but it's simply shrinking the trusted part from the whole computer to the CPU, making the CPU do the authentication at every step, instead of making it do the work once as it loads the info into the computer. Wrong. (Score:1) by Convergence (convergence@hypercube.res.cmu.edu) on Monday December 27, @07:03PM EST (#275) (User Info) There are some ideas for how to pull this off.. Th e idea is to embed the 'real' calculation within a much larger 'outer' calculation such that operations in the 'outer' calculation gradually perform operations for the 'inner' calculation. The outer calculation is a cryptographic mask hiding the 'real' inner calculation. Its all theoretical and stuff, but it is possible. Maybe in 20 years it will be doable with only a factor of 1000 slowdown.. Convergence Re:Wrong. (Score:1) by tomk (tomk@dev.null) on Tuesday December 28, @09:06AM EST (#333) (User Info) http://www.citrix.com The idea is to embed the 'real' calculation within a much larger 'outer' calculation such that operations in the 'outer' calculation gradually perform operations for the 'inner' calculation. The outer calculation is a cryptographic mask hiding the 'real' inner calculation. I am interesting in hearing more about what you've described here. Do you have any links to info on this topic? Thanks! -TomK Re:Here's a similar problem from the vlsi cad worl (Score:2, Insightful) by Rei on Monday December 27, @12:13PM EST (#81) (User Info) http://www.theonion.com I've actually been working on this concept in my spare time, and I came across the answer: It can't be done in software. Period. It needs hardware. What is needed is part of the kernel implemented in hardware. You have to have something along the lines of ram that is physically locked and cannot be accessed by even the (software) kernel - only by itself; or, a plug-in card which simulates such an effect. In both cases there will also need to be a hardware implementation of public key encryption, wherein any software can read the public key and no software can read the private key. The process would basicly consist of the client and the server sending the other an encrypted checksum binary, which can only be run by the process it is sending to, in its privileged memory space, encrypted with the public key of the other. The hardware device decrypts the binary and runs it (with read-only access to the memory space, almost all other access cut off, to avoid a major system security risk), re-encrypts the packet with the sender's public key and its own private key, and then returns it to be sent. This way, both the client and server can be guaranteed that the checksum program they sent was actually run honestly and the data returned is truly from the program. And, as the loaded program is unable to be accessed by anything but itself, no program can modify it after it has been started. There are a few other details I have omitted (such as being able to query to make sure the program is in such a memory space), but this is the basics of it. I went over every angle of doing it in software, and there is no other possible way that doesn't involve the fatally flawed "security through obscurity". If anyone thinks I am in error, please let me know, I'll be glad to discuss it with you. - Rei (spurius@earthling.net) P.S. - there is a moral consideration of such hardware. It makes it possible to have software that is physically un-pirateable, if done correctly. Just so you know. A woman's place is in the house... and the Senate. Re:Here's a similar problem from the vlsi cad worl (Score:1) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @12:25PM EST (#99) (User Info) Forgive me if I'm misunderstanding you, but aren't you just moving the obscurity to hardware? After all, anything that can be processed in hardware can be processed in software (only slower). --- Judge all, but be prepared to be judged by all. see the reply below (Score:1) by Rei on Monday December 27, @07:02PM EST (#274) (User Info) http://www.theonion.com See the reply below for more details. When you get that scanning, tunneling electron microscope, let me know. There is a big difference between hardware and software, namely the incredible level of detail modern chips are printed on, and the fact that their complexity is constantly increasing. Yes, it is physically possible that a hacker might have access to such a device and weeks to spend pouring over the millions and millions of transistors on it. But the odds are better that a wheel of cheese will fall out of the sky and crush the entire DOJ team prosecuting Microsoft. - Rei A woman's place is in the house... and the Senate. Re:Here's a similar problem from the vlsi cad worl (Score:0) by Anonymous Coward on Tuesday December 28, @05:59AM EST (#325) PGP doesn't do its job because it's obscure. You can read the code. But it can keep a secret "obscure" for you if you give it a public key and your secret to put through its process, assuming you have a valid copy being executed. By the same token, it ought to be possible to have an open hardware implementation of the same sort of thing, pared down to essentials. What you want is to send code/data to a processor "for its eyes only," and have it be able to process it "in private." Or in some cases all of it may not need to be encrypted, as with a signed piece of open code+data. It may be sufficient to know for sure that your snippet of open code did execute to completion. If the processor can decrypt and/or verify a signature and execute privately, what gets executed can presumably create a signed return value containing the result. The OS handling the messages once in main memory can pass them or not, but it can't fake them, because it doesn't know the private key. A post the other day floated similar ideas to discussion here. Maybe the "KxSec" is for real? If you were willing to expand the black box to include some larger private memory in a sealed brick, perhaps you could run whole applications that way. Even with the new transistors, how much could you put on the same chip? Just more obscure ..... (Score:1) by taniwha on Monday December 27, @12:35PM EST (#111) (User Info) http://www.taniwha.com/nospam.jpg I still remember accidentally wandering into a room full of people 10 years back with photo-micrographs spread out on a table trying to find hidden registers in a VGA controller .... You are just making it more obscure .... and raising the bar for people who want to break it. BTW you should read up on 'skipjack' proposed by the NSA a while back - it also had 'tamper proof' packaging - which to my mind really means 'costs more to break' Re:Just more obscure ..... (Score:1) by Rei on Monday December 27, @06:58PM EST (#272) (User Info) http://www.theonion.com Yeah... anyone with a scanning, tunneling electron microscope that is ;) Get serious, all ;) There is still the rare lone hacker who sauters their motherboard, but noone, noone messes with modern cpus. The wires are just too tiny. - Rei A woman's place is in the house... and the Senate. Re:Just more obscure ..... (Score:1) by taniwha on Monday December 27, @10:54PM EST (#296) (User Info) http://www.taniwha.com/nospam.jpg I bet the NSA does this twice before breakfast .... seriously though It's decidedly doable with enough die to work from - just etch your way down, take photos - keep at it 'till you think you have all the layers then apply some form of pattern matching to extract the transistors (much harder for something where the keys are stored in some form of charge storage BTW) Thoughts (Score:2) by Hard_Code on Monday December 27, @12:50PM EST (#126) (User Info) So then public key cryptography is used where the keys are stored in hardware. This means either that each piece of hardware has to be different because each has a separate key ingrained in hardware somewhere, which will be totally impractical to manufacture, /or/ that the key is stored in ROM, which, although it is harder, is still accessible. Also the hardware would have to entirely take over the CPU...this means the addition of a super-monitor level that can only be activated by hardware, over and above the software-level monitor state (kernel). If this is done, how is authentication achieved to allow the hardware to do this? Can any piece of hardware do this? If so, then the crypto hardware is compromised. If not, yet another scheme must be invented to authenticate the crypto hardware, which may lead back to manufacturing individual CPUs to recognize a certain key, which is again impractical. If there is no hardware-level monitor, what is stopping a rogue kernel from just dumping memory? I think this may end up a philosophical question. If I give somebody something, I must /trust/ them. If I don't trust them, I can't give them something sensitive. Now, all sorts of "trust proxies" can be put in place, but it will eventually resolve to me trusting somebody. And the only secure endpoint is somebody's brain. So there will always need to be a brain-brain trust. Hardware and software just proxies it for us. Jazilla.org - the Java Mozilla Attn spammers Re:Thoughts (Score:1) by Rei on Monday December 27, @07:15PM EST (#277) (User Info) http://www.theonion.com As to your first part about mass-manufacturing hardware with slight variations (i.e. a key) being difficult/expensive, all intel and intel clone x86 chips, from the name brand to the cheapest, is made like this (since 386 I believe) with a unique identifier on-chip (remember the big privacy scandal recently where they were talking about pushing it up to 64 bit and using it to trace a person on the net?). It is indeed not infeasable. As to your second point, hardware can and does entirely take over the cpu. You seem unaware of the power of the cards you stick in your computer. The point about the hardware needing to call this is incorrect - lets say we're talking about the client authenticating the server here. The client will not proceed until it gets a properly encrypted packet with the right data inside that says the checksum is good. So, if the server doesn't tell the hardware to do its thing, the client will never authorize the server. To be a server at all, it will *have* to have the hardware work. It cannot encrypt an "OK" packet itself. As to your question, "how is authentication achieved to allow the hardware to do this", this is a misunderstanding. A card, or a specialized motherboard or chip, does not need to "ask" anyone or anything for permission to take over the cpu (correct me if I'm wrong, people). And since the process's ram is "locked out", there is no way for the kernel to dump its memory. I already thought of all of this. If anyone can find a flaw in this scheme, please let me know. The big problem I see is: who will sell these devices? Who stands to make a profit from them? A woman's place is in the house... and the Senate. Re:Thoughts (Score:0) by Anonymous Coward on Tuesday December 28, @04:47AM EST (#320) Did you read theAthlon KxSec hoax thing the other day? Re:Here's a similar problem from the vlsi cad worl (Score:0) by Anonymous Coward on Monday December 27, @03:48PM EST (#220) What is to stop someone from simply writing a kernel module to pretend that it has this 'mythical' piece of hardware? Re:Here's a similar problem from the vlsi cad worl (Score:0) by Anonymous Coward on Monday December 27, @04:28PM EST (#235) The private key, of course. No ticky, no shirty Re:Here's a similar problem from the vlsi cad worl (Score:1) by _peter (peter_loe@yahoo.com) on Monday December 27, @06:45PM EST (#268) (User Info) Capability-based security is what you need. See Eros. It's GPL'd. Re:Here's a similar problem from the vlsi cad worl (Score:1) by bogado on Tuesday December 28, @09:09AM EST (#334) (User Info) Such device already exists. There are simetric encription smart cards that have the capacity of creating/storing a pair of public/private key and is only possible to read the public one from the outside-world. Unfortunaly some of those were already cracked by the use of high-precision measuraments (I don't know exactly what was being measured) of the device to read the private key. Those cards also have a protection against brute force, if you open them up they would blow them self up. :-) -- "take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes" []'s Victor Bogado da Silva Lins Re:Here's a similar problem from the vlsi cad worl (Score:1) by toast0 (toast@dont.spam.me.ruka.org) on Monday December 27, @01:24PM EST (#143) (User Info) http://ruka.org/~toast I think there is esentially no real way to do that, if you want to run the software on a client's computer..... if you run the software on your server, and display it on the client's computer, then its possible to protect the data from the client hope thats somewhat helpful What do you get when you mix FreeBSD and linux? A daemonic penguin who has just fed on the souls of a bunch of herring. Re:Here's a similar problem from the vlsi cad worl (Score:1) by taniwha on Monday December 27, @02:30PM EST (#184) (User Info) http://www.taniwha.com/nospam.jpg yeah - I agree - this is really my point I think that there are classes of applications that can't be addressed by Open Source at all (even though I'm a big OS advocate),in this case because their security depends (however weakly) on transformations that take place in a compiled binary that is hard to reverse engineer Re:Here's a similar problem from the vlsi cad worl (Score:0) by Anonymous Coward on Monday December 27, @03:20PM EST (#205) Your point is that there are applications that can never be implemented. To a determined hacker obscurity only delays the inevitable. I CAN reverse a binary. Re:Here's a similar problem from the vlsi cad worl (Score:2) by Gleef (gleef@capital.net) on Monday December 27, @04:01PM EST (#226) (User Info) about:mozilla taniwha wrote: really my point I think that there are classes of applications that can't be addressed by Open Source at all This application cannot safely be addressed by Closed Source software easier, as in the orignal example. It is impossible to make something secure from the user, but accessible to the user's local CPU. The only safe solution is to never give the information to the local machine at all. This solution will work at least as well with Open Source software as it will with Closed. Never fall into the fallacy that Closed Source software allows Security through Obscurity to work, it never will work in a security critical environment. ---- Open mind, insert foot. Re:Here's a similar problem from the vlsi cad worl (Score:2) by sjames (sjames@nospam.gdex.net) on Monday December 27, @05:07PM EST (#246) (User Info) http://www.members.gdex.net/sjames Closed source is no better. The end user can allways run the closed source on a fast emulator that logs everything the software does. That can also be done in hardware. Back in the Apple ][ days, a cracker's favorite tool was a 'bus rider' which could dump a log ef everything it saw on the bus. From that, it was just a matter of following the thread of execution, and dumping out a binary image of the loaded software. Later software got a little more cleaver, but never got to the point of actually making copying impossable. Given the nature of the problem, it never will. Any process environment can be simulated. Re:Here's a similar problem from the vlsi cad worl (Score:2) by bhurt (bhurt@visi.com) on Monday December 27, @01:37PM EST (#152) (User Info) One would think that, should the IP designer actually get hauled into court they'd be able to at least say "we built the chip and it worked", if not actually be able to prove that the client changed the design. But there are problems that encryption, or any technology, can solve- if I can get it in plaintext at anypoint, I can break the encryption and change things to my hearts content (or copy things, as the record and movie companies are learning the hardway). Even hardware doesn't help- poke around on http://www.counterpane.com/ for some possibilities for breaking hardware-based encryption. Leaving the debug symbols in the code (or the unprotected keys, as happened with DVD recently) just makes the reverse engineer's job easier. A suggestion for quake players: have reputation servers. This is not a perfect solution (can the reputation servers be hacked?), but it does give you a _social_ mechanism to discourage cheating. And it's the best you can do. If you can run it, you can copy it (Score:2) by Gleef (gleef@capital.net) on Monday December 27, @03:55PM EST (#223) (User Info) about:mozilla Plain and simple, if your computer can read data well enough to do something with it, you can read & copy it. This is an old maxim of computing, goes at least back to the Apple ][ days, and it's still just as true. As in your example, closing the source does not make the system any more secure in the long run, someone motivated enough can figure out how to read it, copy it, whatever they want to do with it. There is no way to safely send a customer something that their computer will be able to read but not the customer. The answer for companies who want to give customers this sort of access is simple, don't send it. Improvements in network bandwidth allow the vendor to set up a black box on the internet. Customers would be able to log on to the black box, and access the simulation with no access to the data used to create the simulation. They just will see the interface. ---- Open mind, insert foot. It cannot be done. (Score:1) by Squeamish Ossifrage (eanderso@usa.net) on Tuesday December 28, @12:05AM EST (#302) (User Info) http://systemslogic.com/people/eric There is a simple truth behind all of this: You cannot give someone data and also not give them that data. It's the lesson of MP3 and DVD. It's why copy protection doesn't work. It's the root of the Quake problem, Diablo hacks, and the CAD issue. Once someone has data, they can store it, copy it, modify it, retransmit it and sell it. There is no technological remedy to this. The only way to control what happens to data is to control (or at least approve) all the hardware and software that will ever come into contact with it. With physical media, nothing can stop me from picking it up and carrying it somewhat unintended. Over the network, noone can know who's sniffing. There is no possible way to be sure I haven't modified my hardware or software to mimic an approved configuration, but behave otherwise. It is inherently, provably, not technologically possible. End of story. If there is an acceptable level of failure, such as with piracy, one can use legal means to discourage unauthorised behaviour. Where the gains are high, and the risks unimportant, as with Quake, you can trust the client, and hope it doesn't result in excessive problems. But when a single failure is unacceptable - as with important commercial data - the answer is simply don't do it. Know that any data you give someone may end up public knowlege, and do not give anyone more data than you trust them with. If you misplace your trust, that is a human error with no technical solution. Aimbot problem (Score:2) by color of static (smasters@ieee.org) on Monday December 27, @11:54AM EST (#28) (User Info) I've been thinking a lot of how to make an aimbot impratical. It reall boils down to limiting the control responses (movement of the players) and increasing the external stimulous to the system. If the movement was limited to what a star player should be expected to do, then maybe we could design the response to external disruptions (being hit) such that they would throw a classic linear control system off enough to make it non competitive. This is an inverse control theory problem. Find a settling time and characteristic for classical control systems that makes the aimbot suck. Then change the game enough to make sure this happens. If the cheater then wants to use a non linear control system, or some really good linear multivariable control system let them develop it. With the right plant to design for this could be made into something that if someone implemented the program for it I'd be willing to let them use it just from the impressivness of the work. Re:Aimbot problem (Score:2) by phil reed (phillipcreed@yahoo.com) on Monday December 27, @12:02PM EST (#55) (User Info) It reall boils down to limiting the control responses (movement of the players) and increasing the external stimulous to the system. If the movement was limited to what a star player should be expected to do, then maybe we could design the response to external disruptions (being hit) such that they would throw a classic linear control system off enough to make it non competitive. And I'd edit my client to disregard all those external stimuli. If the entire environment depends on the reaction of a client, and I get to control what that client does, then saying "we'll make the client do this" won't work because I'll make the client do something else. The fix has to be external to the client. ...phil "For a list of the ways which technology has failed to improve our quality of life, press 3." Re:Aimbot problem (Score:2) by color of static (smasters@ieee.org) on Monday December 27, @12:13PM EST (#82) (User Info) The client can't control anything like that. Basically the laws of physics have to be implemented on the server, or the game play will look like something from "The Matrix". Re:Aimbot problem (Score:1) by rhk (rhk-nospam@newimage.com) on Monday December 27, @01:55PM EST (#167) (User Info) http://www.newimage.com/~rhk Actually, it might be a better solution to give the client slightly inaccurate information. Another possibility is that the server side introduce small random errors into the data that the client passes. Either way would simulate the slight inaccuracy of the scope on the weapon, or perhaps jitter in the player's arm. "First Post" filter (Score:0, Offtopic) by SiliconShaman on Monday December 27, @11:54AM EST (#29) (User Info) Maybe the coders could add a filter that automatically would automatically throw away any "first post" worthless crap. peace favor your sword We had the version of Quake that ESR refers to... (Score:3, Informative) by Binestar on Monday December 27, @11:55AM EST (#30) (User Info) It was the original Netquake v1.06. You know, with no client-side prediction and lag on your movements. The trade offs that John Carmack and crew made were made to make the gameplay better, not to make it so you can't cheat. I for one would rather risk the remote chance that I would be playing against someone who rewrote part of the code to cheat, than play with a 250ms delay to all of my input on the game again. One thing that isn't really taken into account in all the stories are that most quake servers (Mine included) have a steady base of regular players, and that player base pretty much stays the same. We are all good friends who play and wouldn't play with cheat things like that and if they did we would know shortly after they started because they would get instantly better than they were the day before. Improvments like that don't happen in games like this. I would say that ESR doesn't play quake much, and just wants to get his jabs in to give the closed source development sceme a blacker eye than it already has. Re:We had the version of Quake that ESR refers to. (Score:1) by law (lawrence@no-spam.otak-k.com) on Monday December 27, @12:21PM EST (#94) (User Info) http://www.otak-k.com/~lawrence/ I totaly agree, I have had ringers come in to what was a friendly game, and everyone quit. If they where cheeting or just better I do not know nor care. Regular players have good days or bad, worlds they like and don't. Systematic and regular domination does not happen. Quake for me is a community of regular players with their own style and failings. I do not think a cheater would be wellcome, and probably very easy to pick out. "Think of it as evolution in action." Re:We had the version of Quake that ESR refers to. (Score:1) by BigTom (tom@novikings.lynch-fm.demon.co.uk) on Tuesday December 28, @09:37AM EST (#338) (User Info) Surely your kind of group will benefit most from Open Source. You don't have to worry about cheats so you can get all the benefits Open Source debugging without having to worry about people exploiting it. Rgds. Tom "It's not what you know that kills you, it's the things you know that ain't so." - Mr. Tompkins This could happen even if Quake remained closed (Score:1, Insightful) by jsm (james@jmarshall.com) on Monday December 27, @11:55AM EST (#31) (User Info) http://www.jmarshall.com If Quake was a real-world commerce application, with a financial incentive for cheating, this would have happened long before the source was opened up. People, perhaps companies, would have long ago reverse-engineered the client and communication protocols to take advantage of these cheats. ESR is right when he says the problem is in the program design, and has nothing to do with open source. If you need reliable security, use proven security tools like encryption, not security through obscurity. Re:This could happen even if Quake remained closed (Score:1) by Billings on Tuesday December 28, @03:29AM EST (#316) (User Info) Yeah, it happened before, definitely. But because the source was closed, it did slow the cheaters down. Cheating happened, but it was *relatively* rare, and you rarely had games ruined by it. Administrators could also fight most of the cheating with various commands that the majority of cheaters hadn't wisened up to. However, what open sourcing did was make it extremely easy. More complex cheats are easily enabled, just open up the source. So you have plenty more cheaters. Also, if Quake was a real-world commerce application, with real-world motivation to break into it, Carmack would've just taken a 250ms hit and made it that much more secure - or whatever it takes. Security wasn't #1 priority here, speed of graphics and connection was. And as for the essay... this statement: "Avoiding them [design errors] is, in fact, a good reason for software consumers to demand open source for anything more mission-critical than a Quake game." If the community really does want to mainstream Linux (which I doubt, the minute you do you'll most all complain about it, and you damned well know it because you already are), a Quake game is pretty mission-critical. :) But not only that, but you belittle the importance of the game. The fact is that you just admitted that open source won't work here, and the impression you give is that that doesn't matter because it's just a game. How can a large company justify placing their hands in Linux and open source when Carmack can't trust a simple computer game with open source? Although the two uses are obviously completely different and irrelevent to each other, the gut association is that open source isn't good enough even for a game. But anyways. Just to qualify what I say so I don't get intellectually butchered, I realize that Linux!=Open source. However, Linux is the flagship of open source and the two are tightly linked whether you like it or not. Something profound. Re:This could happen even if Quake remained closed (Score:0) by Anonymous Coward on Tuesday December 28, @08:53PM EST (#347) Also, if Quake was a real-world commerce application, with real-world motivation to break into it, Carmack would've just taken a 250ms hit and made it that much more secure - or whatever it takes. Security wasn't #1 priority here, speed of graphics and connection was. I think that's what the original poster was saying, just as ESR was. Quake not being secure is not an indicator of other open source not being secure, because the design priorities were different. As for Carmack taking a 250ms hit, I was trying to figure out what unit of weight a "ms" was. ;) Re:This could happen even if Quake remained closed (Score:0) by Anonymous Coward on Tuesday December 28, @05:50AM EST (#324) Yes, and in fact this did happen. All cheats which are "made possible" by the source code have been done already. Most of them (aiming proxies, various data file hacks to alter visibility of objects in the game world) are almost as old as Quake itself. Virtually everything which has NOT been done already is impossible from the client side, since it's entirely the domain of the server. These "security deficiencies" are necessarily designed into the game, and could not be otherwise without ruining its playability over the internet--without which, there would be little point in worrying about security anyway. "If Quake was a real-world commerce application, with a financial incentive for cheating, this would have happened long before the source was opened up. People, perhaps companies, would have long ago reverse-engineered the client and communication protocols to take advantage of these cheats. " Quake BotScript? (Score:1) by spRed (spred+slashdot@geocities.com) on Monday December 27, @11:55AM EST (#32) (User Info) ESR almost touches on an interesting point, that bots can win because they use all the available info passed to the client, and not just the stuff that is then passed on to the human player. Why not put hooks into the Quake client code for players to create their own bots? Make hooks for all the available info, and then play will change from who has the fastest fingers to who has the best bot. You work around the problem that someone has more info than another (you could call the early warning of other players 'radar' for theme) and turn the game back into a close fought competition. Experienced coders could compile their own clients that gather info from the code hooks, and a benevolent coder could build a scripting package that uses the same hooks for the less technical crowd. If you can't outlaw cheating, make those the rules. -Red GeekySig ? Perhaps : PerhapsNot I'm already working on a CS/ss bot APT (Score:1) by Mongoose (stu7440@no.spam.westga.edu) on Monday December 27, @12:56PM EST (#129) (User Info) http://www.westga.edu/~stu7440 Go over to BotShop to keep up with the progress. I'm looking to support every version of quake with my own net code for the AI. Re:Quake BotScript? (Score:2) by J Story on Monday December 27, @02:19PM EST (#180) (User Info) This sounds very interesting. Like it or not, advances in armament change how war is waged. Bots are like Gatling guns against bows and arrows. People might decry how each new weapon or defence sullies the "honour" of combat, but victory favours the bigger guns. In Real Life, Stealth bombers, AWACS, Satellite Imaging and Cruise missiles make you a World Power -- not a cheater. As I understand it, the modern Army is working to equip its soldier with whatever is needed to coordinate and execute a mission and return alive. You want a fat defense contract? Make an aimbot for the army. I think that if, rather than being suppressed, bots were embraced, you might well see a shift from the immediate tactics of taking out the enemy in the next room towards strategic warfare. (Imagine the Slashdot Slashers in a virtual campaign against the West Point Bedwetters!) BotQuake (Score:1) by Shadox Tsurien on Monday December 27, @06:02PM EST (#260) (User Info) Why don't they let you take bots into quake? The same reason they don't let you drive cars in a marathon. The thing is, Quake is not a real world application, but a game. Letting someone use a bot in quake is like letting them take a machete into a boxing ring... it's just not right. On the other hand, I would like to see a mod or recompilation that lets you do this. It sounds like a good idea, but I don't want unwary players to be subjected to it. well, yes, but. (Score:2, Insightful) by Kaht (orbitz~at~mail~dot~igormud~dot~org) on Monday December 27, @11:56AM EST (#33) (User Info) http://www.satpal.tsx.org This is a nice little essay on why the people who wrote Quake were stupid, but it provides no solutions or even suggestions at where a solution may lie. You can say "So, in future, let's do this instead of this" but that doesn't help the problem at hand. The problem at hand is, idiots are screwing around on Quake. h3o - better than caffeine. Hacker Game -- Best Kung Foo (Score:1, Interesting) by Anonymous Coward on Monday December 27, @11:56AM EST (#34) I am not a huge quake fan, but i thought it would be pretty cool if they had quake games hosted just for hacked clients. so if someone comes up with a client that can see through walls, you have to come up with a hack which makes you invisible. then someone comes up with a hack which makes you see invisible players. if someone creates a hack that gives them impenetrable armor, than someone else has to come up with a hack that can destroy that armor. who it would a 3D hack-fest to see who has the best kung-fu. instead of a game that you win by purely being able to aim and shoot faster than others, have it where those with the best programming skills win. Re:Hacker Game -- Best Kung Foo (Score:1) by eh (maxburke at home dot com) on Monday December 27, @12:04PM EST (#60) (User Info) Guy, before opening your mouth, it's best to do some research. Download Quake, play with it, and see just how wrong this point of view is. Playing Quake is like playing any other sport, each person is supposed to begin on a level playing field so it's a persons true skill that sets them apart from everyone else. It's a hard game to master which is the point of why aimbot cheating and eye model hack cheating is wrong. If you want a game of the best programming skills, there are plenty of games out there that allow you to write your own robots in C and allow them to do battle against other people. The point of Quake is so the average person can have fun and the point of releasing the Quake source is to allow new technologies to make their way into the engine that the programmers didn't have the time or the interest to implement earlier. Re:Hacker Game -- Best Kung Foo (Score:0) by Anonymous Coward on Monday December 27, @12:19PM EST (#88) Why can't i open up my mouth? all i said that it would be cool to have a hacker-only quake server running somewhere, where hackers can try to beat other hackers where there are no rules. i never said it work, nor did i ever say this is the direction quake should go to, nor did i say this is the way quake should be played. i just thought it would be interesting to use the quake source code for a game based purely on hacking. did i say something to offend the purity and holiness of a true Quake master? i have played quake before, so don't assume that i haven't. i am just not a huge gaming fan. there good for when i need to blow off steam after work, but it's not something i spend a lot of time doing. i am not spreading lies, i am not spreading FUD, i am not belittling anyone or their ideas. so i think i will open my mouth as much as i want. this is a forum where people share ideas, whether you agree with them or not. so if you have a problem people posting ideas you disagree with, perhaps you should seek a different forum. Sure dude. (Score:0) by Skyshadow on Monday December 27, @12:19PM EST (#90) (User Info) Yeah. Look, maybe you should consider getting some more experience with computers than watching a couple of the 'Lone Gunman' episodes of the X-Files. Here: I'll win your "Kung Foo" match. I delete the functions which count off damage and replace them with new functions which basically affirm "Health = 250". I compile and run this modified client in my machine. There. Now I can't be hurt, no matter what incredible feat of programming someone else does. My client isn't capable of subtracting health. Boy, this is fun. ---- In my school, being smart is exactly like being radioactive. Re:Sure dude. (Score:0) by Anonymous Coward on Monday December 27, @12:34PM EST (#110) what makes you think i do not have a lot of experience with computers? i am an extremely experience programming. i just had an idea for perhaps a new twist on game playing using quake as the source. why do you have to be so fucking condescending? usually people like that need to put others down to make themselves feel big, to make for their inadequecies. would it have been anymore difficult to say in a nice way," That really wouldn't work because of this, this, etc..." instead of opening with an insult. as a community, i thought we were suppose to help one another. but i guess there are always those who have to prove something..... No stupid (Score:0) by Anonymous Coward on Monday December 27, @12:41PM EST (#116) Quake doesn't work that way. All accounting *IS* on the server. The only things cheats can give you is superhuman reactions and/or the ability to see therough walls. Taking your own advice. (Score:0) by Anonymous Coward on Monday December 27, @01:14PM EST (#139) you should the previous post ("No Stupid"), and then learn more about computers before you post your idiotic comments. maybe you've watched "Hackers" or "The Net" to much. Relax!! (Score:0) by Anonymous Coward on Monday December 27, @12:27PM EST (#102) My God!!! You guys are acting like the original poster asked everyone to do something horribly immoral. Perhaps he/she doesn't have much experience with Quake. So instead of being a bunch of arrogant assholes, maybe post some information in a positive manner so he/she could learn something. But than again, why should you? I am sure you guys are the master of everything, and never came up with a stupid or undoable idea in your life. I know what you are going to say, "He/She should have done his homework." I really doubt if someone is going to download the source, look through it, try it out, and then post his/her idea. but that time it would days from now, and the story will have been long forgotten. All that work just because someone thought they had a cool or interesting idea about a game? Stop active so fscking 31337. Re:Relax!! (Score:0) by Anonymous Coward on Monday December 27, @02:43PM EST (#190) I agree - not to mention I think it would a fairly inventive way to let crackers do their thing in an environment that would be *tailored* for them. Changing.. (Score:0) by Anonymous Coward on Monday December 27, @05:12PM EST (#250) ..times. First of all good post. I have said a couple of stupid thing in my time. Fortunatly, during my 'newbie' computer period (1982) Everybody in the community would tell why something wouldn't/didn't work they I thought it should.But now, everytime you post something anywhere, a bunch of jackass's have to tell you how stupid you are. I feel sorry for kids entering the field now. I can't imagine become interested in a community that is becoming as hostile as this one. Re:Hacker Game -- Best Kung Foo (Score:0) by Anonymous Coward on Tuesday December 28, @05:47AM EST (#323) "I am not a huge quake fan, but i thought it would be pretty cool if they had quake games hosted just for hacked clients." Would be amusing for about 5 minutes probably... "so if someone comes up with a client that can see through walls" Done years ago. The primary way is to replace the map files with ones having the walls removed (wholly or partly). Another similar option is to replace the player models with ones that have huge rods sticking through them, so they stick through walls. Making players glow also can do this, since the engine doesn't cull dynamic lights on back faces (they show through walls). ", you have to come up with a hack which makes you invisible." Impossible, as this is wholly the server's domain. (You can't tell the server you have the ring of invisibility, you can only tell it you ran over the ring of invisibility to pick it up, and to do that you need to have been adjacent to the ring of invisibility anyway, since the server controls the rules of physics--the player only makes REQUESTS to move, and the ring of invisibility had to be ther for you to pick up.) "then someone comes up with a hack which makes you see invisible players." Done years ago. The easiest way is to replace the "eyes" model with the regular player model. (QuakeWorld now checksums for this, but that could be bypassed, plus many other things can cause the "nonstandard player/eyes model detected" message, so everyone ignores it anyway.) "if someone creates a hack that gives them impenetrable armor," Again, wholly the domain of the server; you'd need to hack the server to accomplish this, not the client. "than someone else has to come up with a hack that can destroy that armor." Ditto. "who it would a 3D hack-fest to see who has the best kung-fu. instead of a game that you win by purely being able to aim and shoot faster than others, have it where those with the best programming skills win." Again, the only things which really could be changed from the client side even with the source code are the same things that have been done from the beginning. Client-side "aim bots" (actually proxies inserted between client and server) have been around almost as long as Quake, as have the various "pak file" (data file) hacks to enable the player to see more than they should. I doubt anything done with the source would give any greater advantage than such hacks. Aim bots were actually made much easier due to freely available information--the specs for the "demo" format (for recordings of game action that can be played back later) were known, and this is basically the same as the network information. This allowed such crackers to insert an "aiming proxy" between client and server. QuakeWorld releases typcially had more and more anti-bot code and checksum code to ensure data integrity, but of course it never takes long for someone to bypass that. In neiter case does a solution exist that still leaves the game playable over the internet (and if you're not playing on the internet, such security doesn't matter much), hence the basic designs which permitted these cracks in the first place was never changed, other than efforts to make such cheating a bit more difficult and wipe out each cheat as it came along. I can't see the source release changing any of this, other than that for a while the "kiddies" will be playing with cheats more than usual. Open source would change nothing. (Score:2, Insightful) by Adversary on Monday December 27, @11:56AM EST (#36) (User Info) "If Quake had been designed to be open-source from the beginning..." ...it would have changed nothing. To make Quake secure, you would not be able to trust the client. To make Quake playable over modems, you have to trust the client (lack of bandwidth and latency issues). Adversary Open the source, close it, print it up and wallpaper your cubicle with it. Its still not feasable to have the server do all the work. So surprise, it won't be secure. Re:Open source would change nothing. (Score:0) by Anonymous Coward on Monday December 27, @12:11PM EST (#78) Actually, Quake would have been renamed "Crash", like all the open source software I've seen and used to date. Real problem. (Score:1) by Zurk (zurk@SPAMSUCKSgeocities.com) on Monday December 27, @11:56AM EST (#38) (User Info) This just highlights the real problem - Running untrusted client side code is still an area of theoretical CS. its still being worked on and other than forcing the clients to do only minimal things and using authentication/encryption, there is very little that can be done. and yes, i know there are workarounds around that too. I'd like to point out that interplay's star trek multiplayer which is closed source was hacked so efficiently and throughly that cheats cropped up at the rate of nearly 5 a *day* -- proving that closed source is just as fallible. Hell - i did some of the hacking myself (just use excel to change values for starships in the text file - dead easy) and was running cheat only server games for a while. No big deal (Score:2) by bkeeler (bruce@gridpoint.com.nospam) on Monday December 27, @11:57AM EST (#39) (User Info) There's nothing inherently wrong with bots. After all, that's what you're playing against when you play the single-player version. They're only annoying when they pretend that they're human. It seems to me that the thing that was most widely praised about half-life was the creative AI players. It will be fun to see what people can come up with for Quake. Could make Quake 1 worth playing again. You need a license to have a dog, but any idiot can have a child. Re:No big deal (Score:2) by slim (slim@ladle.demon.co.uk) on Wednesday December 29, @08:49AM EST (#352) (User Info) http://www.ladle.demon.co.uk A lot of the work Id did with bots for Q3 was trying to give them human-like weaknesses. It's easy to write a 'bot which will tear through the level killing everything with 100% accuracy. It's a lot harder to make them play like a real person (and a lot more fun to play against) -- Beware the Mem e Virus crack.quake.g.pl (Score:1, Troll) by Jikes (jikes@myrealbox.SPAM.com) on Monday December 27, @11:58AM EST (#41) (User Info) (song tuneof="spam spam spam spam" title="Things Quake's/QW's networking implementation was designed to deal with, in descending order") Ping lag latency noise Dropped packets loss loss accuracy sampling rate issues Ping lag latency noise Fun lag latency noise dropped packets noise noise ping lag latency noise security buy a ferrari marry the receptionist (/song) Moral: Quake is not a mission-critical-eCommerce -iEnabled-Me.Personal-Electronic-FinanceSecure.com kind of thing. It's a game. It's a game that has a player community that consists of 60% people who love the game, and 40% qu4k3 k1dz. They are irrelevant as their penises are tiny. (the k1dz penises, not the true players) This article is a rehash of plans and posts with a not-technically-sophisticated-enough explanation that doesn't fully describe the complexity of the situation and the target audience consists of people who are bored at work and will read any goddamn thing that floats across the web. I hereby piss on someone else's well-intentioned, well-written and well-executed effort to explain things to people. I am now just mutilating whitespace. My job is so boring. I have seven win peecees at my disposal that break a lot. They can't be fixed. Noone wants to fix them. There is no money or interest in fixing them. Yet I am paid to watch them. Someone end my empty horribly empty life. I am a total twat with no life. Kill me. Moderate me. Please. mabye it's just me (Score:2) by asad (leo1@well.com.NOSPAM) on Monday December 27, @11:58AM EST (#42) (User Info) but ESR didn't add anything new to the discussion it just looked like the comments that were already posted under Q1 release and then rehashed. I think everyone agrees that security through obscurity is a bad idea but as Carmack explains in the world of modems you don't really have a choice, you need the performance to sell games. Now if some e-commerce site decided to do this then I would be worried but this is just a game we are talking about. I could see if e-bay had released their source code and people had decided to hack it so that they could cheat but this is just silly. Vidi, vici, veni. (I saw, I conquered, I came) Re:mabye it's just me (Score:2, Interesting) by ranton (ranton@uti.com) on Monday December 27, @12:20PM EST (#92) (User Info) What do you mean just a game? Games control the computer industry. They are the single thing that is driving computer hardware to new levels of power and efficiency. And since when is security through obscurity a bad idea? Without obscurity every single possible type of security could be broken. All you can hope for is to keep the protocols hidden for as long as possible. What's Important to Carmack is Unimportant to ESR (Score:2) by humphrm (rm-f@linuxstart.com) on Monday December 27, @12:00PM EST (#47) (User Info) http://www.famille.org/mikehd.html Before we all get up in arms about what JC said about closed-source client/agents and ESR's response, let's keep something in mind: what's important to ESR and the Open Source world is, in this very case, different than what's important to Carmack. Don't forget, it was Carmack who made the decision to move away from FPS's and into Arena, which is clearly an Internet-gaming gamble. So now the issue with cheats in Q1 probably doesn't affect his plans *today*, but what about later? Could the techniques developed in Q1 hacks become tomorrow's monsters that keep "everyone" from playing Arena online? That's gotta worry JC, I would think. That problem would adversely affect the (so far) enthusiastic yet also reserved acceptance of the gaming community to the changes in Arena. So this is a problem that Carmack must now solve, it along with it's closed-source baggage that caused the problem to begin with. Is this our problem? Should we care? I think ESR's saying, "I'm an open source advocate, and I will remain one. John Carmack's problems are his own." That's my read on it. The Real World (Score:3, Insightful) by SheldonYoung on Monday December 27, @12:02PM EST (#54) (User Info) http://www.gofcs.com There is no way to make software that runs on the client side totally secure. It is always possible to hack the client to your advantage because it runs on your computer, and you can fiddle the bits in your computer any way you want. No matter what kind of proxy or checksummed client they use it'll be hackable because it's runnable. It's the same reason that copy-protection, secure audio formats and DVD can all be cracked... at some point code has to be executed that the user can change. Even if Carmack does as ESR suggests and only send full world updates, that will not prevent a proxy that jumps every time a rocket is fired at your feet or any number of other subtle helpers. The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again. I didn't say it would be easy, just the only way to make it truly secure. Re:The Real World, Quake, and ESR's article. (Score:2, Insightful) by Sketch on Monday December 27, @01:04PM EST (#134) (User Info) http://openverse.org/ "The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again." I think you are right, that is what we will see eventually. But it won't be until the average person has cable, DSL, or some other high-bandwidth, low-latency connection to the net that it will be technically feasible. But with the average player trapped behind a modem, the kind of tricks Carmack used are necessary for the game to be playable. ESR mentioned Carmack's reply in his article, but did not comment on it, and appeared to pass it off as unimportant because the design should have been "done right" in the first place. Obviously, ESR has never played Quake on a modem against players on low latency connections. :) My other comment on the article was that there were no direct statement of ESR's point. From reading the comments here, it seems many people got entirely different meanings out of it. Pretty poorly written, IMHO. Quake! http://lonestar.intcomm.net Chat! http://openverse.org Re:It'll take a LOT more than a cable modem.. (Score:2, Insightful) by Defiler on Monday December 27, @02:55PM EST (#198) (User Info) 1024x768, 32bit color, 60fps.. (By the time this is feasible, you can expect MUCH higher resolutions and frame-rates than this.) Since I wouldn't tolerate any lossy compression on my Quake3 video signal, that requires 1440Mbits/sec. That's 960 T1s per user.. For a decent game of CTF, the server would have to be a large cluster of powerful workstations, and have more bandwidth than the entire east coast of the U.S. Re:It'll take a LOT more than a cable modem.. (Score:2) by SheldonYoung on Monday December 27, @04:19PM EST (#230) (User Info) http://www.gofcs.com Yes, it would. Bandwidth is definitely the limiting factor, and in fact is the reason Carmack went with the "insecure" design. Something like streaming MPEG can probably cut the bandwidth by a factor of 100 without any notificable effects. Only 9.6 T1s per user then :-). And if that's the case, a pair of 400kb/s just might do it. Not that far off, when you think about it. Re:The Real World (Score:2) by Gleef (gleef@capital.net) on Monday December 27, @04:21PM EST (#231) (User Info) about:mozilla SheldonYoung wrote: The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again. You can safely run some of the code on the client, and you can do 3D. The client would collect user input (keyboard/mouse/joystick/etc), and send it to the server. The server would do all the calculation as to what the new game state is. The server would then send to the client only the information the player is allowed to have. The client would then do the 3D rendering of that info, the sound construction and mixing, etc. The server properly limiting the info will prevent the looking around the corner problem. The server doing the input processing will minimize the aimbot problem. You couldn't get the extreme aimbots that Quake has seen (since before being Freed), but you could still get things like "snap to target" mouse motion, or crosshairs that take target motion into account. Aimbots would work no better than an excellent player, rather than making the player superhuman. As ESR said, the most successful Open Source games would have to be designed with client modification in mind. Quake wasn't, which is why these deficiencies seem so blatant. ---- Open mind, insert foot. Re:The Real World (Score:2) by SheldonYoung on Monday December 27, @08:44PM EST (#289) (User Info) http://www.gofcs.com The problem is that you can do cheating in the 3D rendering part - spikes pertruding from the model so you see the player through walls, for example. Re:The Real World (Score:2) by Gleef (gleef@capital.net) on Monday December 27, @09:42PM EST (#294) (User Info) about:mozilla In Quake, yes. In a game designed with proper distrust of the client, the server shouldn't send any info that couldn't otherwise be seen. ---- Open mind, insert foot. Re:The Real World (Score:2) by SheldonYoung on Tuesday December 28, @01:35AM EST (#308) (User Info) http://www.gofcs.com Carmack is (of course) correct when he says you have to send some data a little before it can be seen, or else client-side prediction won't work. Imagine player A is *just* around the corner from player B, who is on a slower connection. Player A will then be able to see B before B sees A. We need to compromise.... (Score:1) by skrew (skrew@I_SLAY_SPAMMERS.email.com) on Monday December 27, @07:53PM EST (#282) (User Info) ftp.porn.org The only solution might be to run all the code on the server. Yes, really. Imagine the client side just being a 2D graphical dumb terminal just drawing frames from the server. It can't be 3D because it would be hackable at the driver-level again. Carmack has already talked about this, this was his original ideal development model (dumb client). But real world problems caused it to be discarded. The latency and bandwith requirements for a dumb client are not able to be provided in this day and age. Hence, the QW compromise was born. Something like that needs to be done now, all this talk of making 100% secure systems etc is moot really, we just need to keep hacking up Quake as its always been done... My other modem is a multihomed OC256 comeon people, read the hole eric story before po (Score:0) by Anonymous Coward on Monday December 27, @12:03PM EST (#58) You imature slashdotters just don't get it!! ESR said if quake 1 was open source from the beginning problems like this would not have happened. The speed would STILL have been there, the security would have been there and even better. It would have gone thought rounds and rounds of peer review. Clients would not have the ability to cheat no matter how good the programmer was. Open sourcing software that has been closed source from it's birth is the flaw. Now implimenting a quick open or closed source security fix would slow down the game. I am hopeful the collective minds of the open source community will solve this. As more and more people want to open up once closed source this will beceome and even more important issue. Why retreat? (Score:2) by pwagle on Monday December 27, @12:04PM EST (#59) (User Info) We want open source, and we want security. Switching back to closed-source isn't going to solve anything. Quake is a game. We can try bunches of things, since we can afford to blow it. What do we do when serious programs need similar protection and we can't afford to fail? With a game, we don't have to get it right the first time! We can try things and incrementally evolve the correct solution. Different people will have different pieces of the puzzle, and enter in at different points in time. I propose that what you really want for Quake is to see the source your opponent is using. So you want authentication and revocation. Some cheats will be cool, and evolve the client. Some cheats will be stupid and/or pointless, and you will want to revoke them. One possible approach is to have people register their sources to trusted authentication servers which will hand them back authenticated binaries whose signatures quake servers can accept or deny. If I think someone is cheating, then I can go look at their sources. And perhaps have some sort of voting scheme where some clients are declared "stupid cheats" and their access to quake servers denied. My idea needs work, but it's a good starting point. I'm trying to stay brief, so am not going into a lot of detail. Open souce or not? (Score:0) by Anonymous Coward on Monday December 27, @12:04PM EST (#61) I definitely think Carmack had the right intentions and open source IS indeed the way to go. It's just that maybe releasing THIS particular souce was a little premature. I believe most people are good at heart, but there are always a few bad apples to a barrel that spoils things for everyone else. So what is the solution? I have no idea, except maybe waiting until Quake and other games of the like get so out of date that releasing the source would be like Apple Adventure to Everquest. Well, I just hope this doesn't discourage other companies from trying to do the same for their products. I am certain that there are ways to solve this current problem. Just a little more time is needed to think of a solution. Imagine if (unlikely) Microsoft released their source. The bugs and code would be exploited to no end. But I'm sure that having it open sourced would be better than MS trying to fix them all on their own. It *IS* a game (Score:1) by mr on Monday December 27, @12:06PM EST (#65) (User Info) It seems everyone is forgetting that this *IS* just a game. Something you do for entertainment. Now, if some people find creating an auto-aming robot, or even a fully AI player entertaining, then fine. (after you have killed so many mobs, so many ways, writing a program to do it can be entertaining) And if you find aiming by hand to be entertaining, fine. No one says you have to play with Bender, the auto-gunning robot. Or Tinny-Timmy, the manual-aimer. Go play with people who agree to paly the same way you do. The mud community has for years had issues with bots or response-enhanced scripted players. In the end, rather than create an ulcer for yourself over these issues, its better to just remember: It *IS* a game. If it was said on slashdot, it MUST be true! Re:It *IS* a game (Score:0) by Anonymous Coward on Monday December 27, @03:45PM EST (#215) Yes, it is a game. But gaming is an industry. JC must be feeling awfully bad. If this gets out to the public at large this could have an awful backlash on gaming. Here's why. There an annual conference called, no less, Game Developer Conference. Their goal is to "make games the dominant entertainment platform of the 21st century." This won't happen if the public finds out that its easy to cheat. Where's the sportmanship and integrity of games? And, then, if they find out that Open Source makes it easy to cheat, they won't play open source games. Gee, this will probably be a hot discussion at the conference in March. ESR doesn't understand how sensitive an issue this is. Who cares about Quake? What about day-trading bots (Score:2, Interesting) by NateTG on Monday December 27, @12:07PM EST (#68) (User Info) I suppose that creating a day-trading bot that gives the user massive advatages in terms of spotting good stock would be bad? Think of it - all your adrenaline slurping marine buddies sitting at a bank of computers send rapid-fire orders for stock. Seizing companies left and right, leveraging your ammuntion supplies... Now, is this cheating or good buiness (Assuming it works) -- I'm quite sure that if anyone ever gets any good at it there's some masssive repercussions to be had, either SEC sanctions or stock market crashes. Of coure if you had that sort of day-trading client would you use it over the normal one? Of course there's more security on the server side for day-trading, but the same issues are relevant there. I suppose we ought to be thankful that Quake doesn't actually have massive effects on our economy, and that hakers are leery of dealing with money things because the penalties for getting caught are larger. Re:Who cares about Quake? What about day-trading b (Score:0) by Anonymous Coward on Monday December 27, @12:19PM EST (#89) Slightly off topic, but the company I work for makes quite a bit of money by using 'bots to decide on stock/option/future trades to make. It's been doing it for over a decade, and is nothing new in the industry. also, day traders == fools to most of the people in the know around here (in a bull market they get short term wins, but forget the long term or when the market gets bearish). Re:Who cares about Quake? What about day-trading b (Score:0) by Anonymous Coward on Monday December 27, @12:45PM EST (#122) With all due respect, this doesn't make any sense when transferred to an environment like the stock market. Quake, as I am sure you are aware, has a set of predictable rules that govern success. Running a client to enhance speed and accuracy to enhance success is only possible once you have these rules and are experiencing success. In the short-term, there are no "rules" to "winning" in the stock market. Sure, there are ways to increase the odds in your favor, but in the end, it is a crap shoot. Either your pick wins or it doesn't, and it is much more likely that you will lose, trading in the short-term, than win -- go take a look at the success rate of day traders to see a case in point. The linked article states - after conducting some exploratory research: "All trading in the accounts was analyzed and evaluated (4,093 trades in 26 accounts). Seventy percent of the accounts lost money and were traded in a manner that realized a 100% Risk of Ruin (loss of all funds)." While 26 accounts is not a representative sample, I think you will find that many (read at least more than 50%) day traders are losing money. The only thing automating this process would accomplish is increased efficiency in their ability to lose cash. Breathe easy. The implications of Quake 1's GPL isn't going to end the world as we know it. Although I do feel fine. ...but performance is critical! (Score:2) by Skyshadow on Monday December 27, @12:09PM EST (#72) (User Info) Here's the long and the short of it: Quake could be made secure through more reliance on the server and less on the client, but to do so would destroy the game by slowing the whole process down to an unplayable level. Carmack's right; the only realistic solution at this time is to keep at least part of the verification module closed-source. Why is this such a problem? Who the hell cares if there's some obscure part of the code you can't get at? Why would this be worth sacrificing decent game play? Look, if you don't like the closed source stuff, go ahead and play without it and contend with all those Z-bot asswipes who get a kick out of ruining the fun for everyone else. Me, I'll take the closed-source module that Carmack's offering and actually enjoy the game. ---- In my school, being smart is exactly like being radioactive. Re:...but performance is critical! (Score:1) by Sloppy (sloppy@spam^H^H^H^Hrt66.com) on Monday December 27, @12:32PM EST (#106) (User Info) Carmack's right; the only realistic solution at this time is to keep at least part of the verification module closed-source. The problem with that "solution" is that it doesn't solve anything. Binaries can still be cracked and modified; people have been doing it for decades. Look, if you don't like the closed source stuff, go ahead and play without it and contend with all those Z-bot asswipes who get a kick out of ruining the fun for everyone else. Me, I'll take the closed-source module that Carmack's offering and actually enjoy the game. You will still be vulnerable to the asswipes. The difference is that you'll have a false sense of security, and be left wondering, "How did he do that? I thought cheating was impossible." --- Have a Sloppy night! Re:...but performance is critical! (Score:0) by Anonymous Coward on Tuesday December 28, @01:31AM EST (#307) The problem with that "solution" is that it doesn't solve anything. Binaries can still be cracked and modified; people have been doing it for decades. You will still be vulnerable to the asswipes. The difference is that you'll have a false sense of security, and be left wondering, "How did he do that? I thought cheating was impossible." In theory you are 100% right, but pratically the closed-source-loader seems like a very good solution to me. There are several anti-cracking tricks that would made it very time consuming task to hack the loader. The only "real" solution is a dump client, that is impossible because of latency problems. So is there a better solution than the closed-source-loader? This argument has been hashed out before (Score:4, Interesting) by jd on Monday December 27, @12:09PM EST (#73) (User Info) And the conclusions were much the same. That time, it was with cheating on Netrek. (Script Kiddies seem more interested in big numbers than learning skills.) The solution there was to distribue the source as Open Source, but only allow "blessed" binaries to connect to "blessed" servers. This hasn't been fool-proof. Plenty of people have cracked Netrek's security, and whilst it's good at keeping the drearier riff-raff out, all that really does is give you a better class of riff-raff. It doesn't solve anything. How, then, to prevent cheating? That depends on how much the client does, and what counts as cheating. The server can always prevent cheating, with anything under it's direct management, by simply controlling throughput. No more than N operations per unit of time effectively prevents souped-up clients with super-human reflexed, for example. Controlled throughput also gives you much better Quality Control, as you can effectively ensure that no connection suffers undue lag at your end. As for anything else, this calls for the ability to access points in the code by address. If you can do that, then the server can call routines to check for validity in a way that can't easily be bypassed by simply rigging the checks. Re:This argument has been hashed out before (Score:1) by ClarkEvans on Monday December 27, @04:31PM EST (#236) (User Info) I think PKI offers a neet solution. If you need to "cache" information on the client for performance, do so. Just send it encrypted. Then, on a need-to-know basis, send the keys. This way you get the best of both worlds. Ahem, this is KINDA SILLY. (Score:1) by Shanoyu (shanoyu@gamehacker.com) on Monday December 27, @12:12PM EST (#80) (User Info) http://www.gamehacker.com/misc/ What needs to be done is to create two closed source programs that act as executable loaders / verifiers and communication proxies for the client and server. These would need to be produced for each platform the game runs on. Some modifications will need to be done to the open source code to allow it to (optionally) communicate with these proxies. Two closed source programs in addition to the q1 source. They are not closing the q1 source. (First Myth Debunked) Verification programs should not be open source. Espically if you are not making any money on the program anymore (for instance if you are working on say, q3.) and you have roughly six or seven hours a month to spend on the project. (Which is why they GPL'ed it.) This is the defination of an insane frenzy. People don't even read the stories now. Drives me crazy. So hence I remind everyone the first rule of positive posting: Read the story first (doi doi doi). The Second rule is: Put yourself in the shoes of the woozle. (Woozle; as in kill the woozle, for instance putting yourself in Carmack's shoes, or Amazons, etc.) NOTE: If you seriously have a problem with this, NOTHING is stopping programmers from editing the source in such a way that the two closed source proggies would not be necessary, and the game could still be cheat-free. I honestly don't see Why everyone is opposed to this bandaid fix until open source itself can fix the problem. Unless of course the code is too big and we run into whatever the law is that says, "The Bigger the code, the fewer people want to _start_ work on the monster.". Frustrated. -[ World domination - rains.net ]- -[ misc.txt, karma for a new generation ]- Can Someone Explain This to Me? (Score:2, Interesting) by Roofus (roofus@phiwho dot com) on Monday December 27, @12:17PM EST (#84) (User Info) http://phiwho.com c) real security comes not from obscurity but from minimum disclosure. -= PhiWho.com =- College life with all the freaks and alcohol. Moderate UP => Can Someone Explain This to Me? (Score:1) by SLOfuse (criminalize_spam@nd.telemarketing) on Monday December 27, @01:30PM EST (#148) (User Info) Good point! Let's hear ESR's explanation of this. What's the difference between "obscurity" and "minimum disclosure"? Boycott boycotting. Buy everything! Re:Moderate UP => Can Someone Explain This to Me? (Score:2, Informative) by drew (cattand at charlie.cns.iit.edu) on Monday December 27, @02:48PM EST (#194) (User Info) http://www.iit.edu/~cattand well, im not going to go into it too deep, but at least in reference to this situation: obscurity in this case is giving the client the positions of all of the players in the game, and trusting the client to only display to the player the other players that can be seen from his current viewpoint, leaving the rest of the players obscured. minimum disclosure would be only telling the client where are the other players that the player can see from his current viewpoint. this way, the client/player can't cheat because the cient doesn't know any more about the positions of the other players than the current player is supposed to. in general, obscurity means leaving extra data that could be used to cheat hidden somewhere in the protocol. the programmers are trusting that they are hiding the information well enough that the players won't be able to find it. of course once the source is released, this "hiding" is no longer good enough, because cheaters can just look at the source and see where it is hidden. minimum disclosure means only giving out as much information as anyone needs to know. there is no extra information hidden in the protocol for cheaters to find or use to their advantage. Re:Moderate UP => Can Someone Explain This to Me? (Score:2) by rcw-work (rcw@d.e.b.i.a.n.org.without.dots) on Monday December 27, @04:44PM EST (#243) (User Info) Another example: Obscurity: NetBIOS hidden shares being transmitted in share lists and hidden on the client end. Minimum disclosure: NetBIOS hidden shares having never been transmitted to the client at all. (NetBIOS uses the former technique) Re:Can Someone Explain This to Me? (Score:1, Informative) by Anonymous Coward on Monday December 27, @01:48PM EST (#161) It's written in hyperbole. That seems to be ESR's native tongue. In english, it means security does not derive from encryption or obfuscation, but from minimum transfer of information. To make it clearer through an example, the most secure method of voice communication would be to be mute. Re:Can Someone Explain This to Me? (Score:1) by TrentC (trentc@dev.null) on Monday December 27, @02:46PM EST (#192) (User Info) http://members.xoom.com/_XOOM/trentc/index.html c) real security comes not from obscurity but from minimum disclosure. While amusing from a sentence-parsing standpoint, I think the point is: Real security comes not from concealing information about your security algorithms or methods, but from presenting the fewest possible points of attack. Jay (= Re:Can Someone Explain This to Me? (Score:2) by Inoshiro on Monday December 27, @03:48PM EST (#219) (User Info) http://www.thock.com/Dylan/ c) real security comes not from obscurity but from minimum disclosure. Obscurity: I'm not going to tell you anything about me, because I might have a flaw. Minimum discloser: I'm not going to tell you anything about me, because you don't need the info. The difference is very, very slight. Here's a better example: Rather than do something silly, like broadcast everyone's info the client so it can "desynch" from the server, I'll just give you a few bits and do more managment on the server side. Disclosing less of your opponents' states. --- Internet Explorer (n): Another bug, that is, a feature that can't be turned off, in Windows.  See also: monopoly. Re:Can Someone Explain This to Me? (Score:1) by Talonius (grindslave@excite.com) on Monday December 27, @06:06PM EST (#262) (User Info) Perhaps this can be better phrased along the lines of "Knowing it can be done is half the battle." Knowing the inner processes of anything provides you with an edge into breaking into the system, or cheating, or whatever you're doing, because it helps you *giggle* "drill down" to the information you need by offering known information. T. Brian M. Schkerke, MCSE, MCP+I bschkerke@-nospam-excite.com Re:Can Someone Explain This to Me? (Score:2) by slim (slim@ladle.demon.co.uk) on Wednesday December 29, @08:45AM EST (#351) (User Info) http://www.ladle.demon.co.uk Here's security by obscurity: You ask a database "what is my salary?" Database client (unknown to you) asks the server "Please send me everyone's salary, and this one person's ID number" Server does what it's told. Client uses your ID number to decide which salary to report back to you. Because it is not documented that the server sends the whole lot, you're expected not to realised, so as long as you don't poke around, your boss's salary remains a secret. Minimum disclosure means that you are *never* given more information than you are allowed or require. -- Beware the Mem e Virus Opening up vs. developing openly (Score:1) by Lalo Martins on Monday December 27, @12:18PM EST (#87) (User Info) http://www.linuxcenter.com.br/lalo/eng.html So, in general, the lesson we learn here (and by "here" I probably mean the last 2 years) is that opening up some sources is not the same as developing it in the open. (And I won't start on open vs. Free here; I prefer Free, but I'm dealing with open in this line of thinking, because this doesn't really depend on freeness). A lot of code was opened up in the past 2 years that was originally developed "in the dark". Starting from Mozilla. All of them (except the ones to which nobody really paid any attention) suffered from a similar problem: as soon as the code was out, chaos started, on account of all the crud that crept in due to the closed development. As ESR wisely points out, it's the open development proccess that does the magic; developers tend to think in different ways when they know people will be reading the source. This way leads to real power. On the other hand, developing in the dark, with no prospects of ever opening the source up, and then later opening it, leads to embarassment and insecurity. as Q1, Mozilla and others kindly proved us. And of course, leads to months of reimplementation (witness Mozilla/Gecko and QuakeForge). So in short: it's cool that companies are seeing some light and opening up code. But it will be REALLY cool only when they see the whole light and start developing in the open to begin with. And here I pause to cheer the people behind AbiWord, XDBM, Conglomerate and other company-owned, yet openly-developed-from-start (or almost) projects. Re:Opening up vs. developing openly (Score:0) by Anonymous Coward on Monday December 27, @03:32PM EST (#210) What you suggest is why there haven't been any cool open source games developed yet. It has to be done by a talented team of commercial experts. Why? 1) They know how to innovate. If OSS, knew how to innovate you would have seen games much better than Quake by now. Where are they? 2) They know how to market. Linux would be no where now if it didn't have marketing muscle, which it does. But the OSS community, in general, is too wide-spread for this to be a success in all it's software. Only Apache and Linux are the two glory boys. What's really strange about this is, and I'll bet you, most of the people who do OSS development have at one time or another in their careers tried to write a game or two. But were they able to make a living off of it? No. You need a team of commercial experts for this. Open source is not the way, as time will tell. Stopping AimBots - a possible solution. (Score:4, Interesting) by SuperKendall (kgelner@bigfoot.com) on Monday December 27, @12:28PM EST (#103) (User Info) I think ESR has got it wrong, the AimBot is by far a much worse problem than a player being able to see around corners - a good player essentially can tell where people are anyway based on sound cues or knowing how far behind him someone was. It might give a slight advantage, but not the godlike ability to clean out a room that an AimBot gives. However, I thought of a possible solution - one way to stop AimBots might be for the server to send a few "fake" players to the client with either transparent skins, or embedded in the walls, or perhaps randomly "clone" the user just behind himself every now and then. A real player would never see these "shadows" but an AimBot would fire at these pahntom targets and that could trigger the server to shut him down. As an added bonus, an AimBot set to use the rocket launcher firing at a fake target a foot away would bring a little justice to the bot user. ---> Kendall Wouldn't work (Score:1) by Tim Behrendsen (tim {at} behrendsen {dot} com) on Monday December 27, @12:40PM EST (#114) (User Info) If the client is (not) displaying the "shadow warriors", then the client knows they are shadow warriors. The Aimbot can just look at the skin to see if it's transparent, for example. The Aimbot is going to know everything a human player knows, only more. --- Judge all, but be prepared to be judged by all. Re:Wouldn't work (well, maybe it would) (Score:1) by Edward Kmett (harmless@junk.mich.com) on Monday December 27, @01:42PM EST (#156) (User Info) http://www.bloodshed.com/ Actually its not all that unreasonable of a solution, if you gave the server a tighter PVS than the client and sent things that were technically within the client's PVS but not likely to become visible you could cause a reasonable amount of confusion to the bot, on the other hand, if the bot has a reasonably simple bit of logic not allowing it to attempt to shoot through walls that won't help much, except to keep bots from leading people around corners. Also, if you miss a packet or two and that 'phantom' winds up visible, it would be really disorienting to the player using the current protocols. The only really nice thing about this proposed partial fix is it could be done on a server with no client side changes. Madness takes its toll. Please have exact change. Remove the junk to email me. Re:Stopping AimBots - a possible solution. (Score:2, Informative) by Anonynous Coward on Monday December 27, @12:42PM EST (#117) (User Info) I think ESR has got it wrong, the AimBot is by far a much worse problem than a player being able to see around corners - a good player essentially can tell where people are anyway based on sound cues or knowing how far behind him someone was. It might give a slight advantage, but not the godlike ability to clean out a room that an AimBot gives. Agreed! In fact, the ability to support 3D-sound footsteps REQUIRE you to have (at least approximate) positional information on people who may be around corners or otherwise out of side. This isn't really an issue with Quake, since it doesn't use footsteps, but Quake2, Quake3, UT, etc... Your aimbot solution is interesting but it'll still require some "fuzzy" logic as users will often shoot randomly to throw off enemies, or just because (due to their timing or hearing of footsteps) expect an enemy to be coming. They might accidentally hit one of these "phantoms". Causing undue splash damage (if they are close) and/or marking these non-cheaters as cheaters. Re:Stopping AimBots - a possible solution. (Score:1) by BigD42 (mahrt@cis.ohio.state.edu) on Monday December 27, @02:37PM EST (#188) (User Info) http://bigdbase.dynip.com I don't think the goal of "phantom" characters is to reveal cheaters as much as it is to take the edge away from people using the AimBots. The point of the cheat is to enhance (dramatically) aiming accuracy. How can this be acccomplished if it tries to shoot at nonexistant characters. --- Linux... a college project gone horribly right Re:Stopping AimBots - a possible solution. (Score:2) by Hard_Code on Monday December 27, @03:36PM EST (#213) (User Info) Yes, that is a good idea... Can inanimate objects be labeled "enemy"? Could the whole level be labeled "enemy"? Intelligent AimBots could of course attempt to detect between "real" enemies and "phantom" enemies, but that would reqiure their complexity to go up and their performance down. It's just an arms race...but if it can be made sufficiently annoying then perhaps people won't try it. Then again, this will kill off client-side bots too. Jazilla.org - the Java Mozilla Attn spammers Re:Stopping AimBots - a possible solution. (Score:0, Redundant) by sammy baby on Monday December 27, @09:36PM EST (#293) (User Info) The problem is that at some level, the client has to know that a character is nonexistent, especially if it's doing any client-side prediction at all. (Quake 1 didn't, but the subsequent QuakeWorld did, as did Q2 and pretty much every game that followed.) Remember, the bot is actually part of the client, so you can't pass the bot any information that you wouldn't want to pass a client anyway. If you send a message to a client saying that there's a player there, you have to be prepared for it to shoot. What are you going to do if it hits - label it a bot and kick it out? What if it was just a random shot? Re:Stopping AimBots - a possible solution. (Score:1) by SuperKendall (kgelner@bigfoot.com) on Monday December 27, @11:05PM EST (#298) (User Info) But if the "phantom" player is not visible by the rules of the game - invisible skin, out of the way, out of direct view, then it doesn't matter if you hit them or not - it would definatley appear to the client bot you were aiming for someone real but a normal player would never actually see these fake players. For instance, a phantom player walking along the bottom of a lava pit wuld not be normally fired on but a bot would try and kill it (probably). Since the server code to manage this would presumably be open as well it might be possible to write a client that could detect a tell-tale trait to weed out these fakes - but at least you culd update the server with fixes and updates to eliminate bot clients without the normal clients having to upgrade all the time as well. ---> Kendall A reply to some of the issues raised in replies... (Score:2) by SuperKendall (kgelner@bigfoot.com) on Monday December 27, @04:34PM EST (#239) (User Info) I agree about the possibility of splash damage to somene who "accidentally" hit one of the phantoms, but that's why you'd only place them "just" behind the person so they couldn't hit them - no other players would have that phantom sent to their client so it wouldn't matter. The only problem then would be it might act as a shield, at least as far as the client was concerned - but I had thought that the two clients told the server if someone got hit, and it would decide the final outcome (or it might not work that way at all!! I make no claims to having looked over the code). I am agreed that perhaps placing a phantom right behind the user might have too many issues to work out, but it is only one of many pssible placements. As for the transparent skins being detected by the bots and worked around - perhaps that would be possible, but if you threw enough variable ways that could happen (phantoms just behind a pillar, phantoms embedded in a window, normal skinned phantoms in a pit of lava, phantoms with "preditor" skins of the wall benhind them [perminent invisibility], etc.) that it might make it very hard to write an AutoBot client - or at least a client that wouldn't have enough direct hits on phantoms to trigger the server that something was amiss (I agree that accidentaly firing a shot at a few of the phantoms shouldn't trigger a cheat detector). ---> Kendall Re:Stopping AimBots - a possible solution. (Score:1) by thantos on Monday December 27, @08:26PM EST (#287) (User Info) This is actually a pretty keen solution, but it would only work until 2nd Gen AimBots came along which check the locations and textures of targets before firing; that check can be made near instantaneous, certainly within ping time, and as such would have no net effect overall. But its still a very keen idea. :) I think the NetTrek solution is about the best compromise to be reached in this situation; if you don't want hacked clients running on your server, make it require a crypto challenge/response from a target client based on its CRC. Yeah, it can be hacked all to pieces, but at least its more than notionally difficult. OK, I admit, I'm more than notionally curious about the idea of implimenting Bots for Quake; its a fine genre for the field of development. -- Riding the Winds of Fires Lit in Ancient Days Re:Stopping AimBots - a possible solution. (Score:2) by SurfsUp (surfsup@domain.com) on Monday December 27, @11:23PM EST (#299) (User Info) A real player would never see these "shadows" but an AimBot would fire at these pahntom targets and that could trigger the server to shut him down. Better, reduce his shot damage to zero. Then let him slowly suffer. -- I built The Lizard today - did you?? Re:Stopping AimBots - a possible solution. (Score:2, Interesting) by LarsG on Tuesday December 28, @08:27AM EST (#329) (User Info) ..which is only a temporary solution until the bot writers check for these things. The result is an arms race between bots and servers trying to detect them. Which can be fun for a while, until you suddenly discover that you use more time adding protection hacks to your server than you use playing the game. It is a lot better to do a redesign that limits the knowledge of the client. But, as has already been explained, that would be hard to do for Quake without killing performance. Re:Stopping AimBots - a possible solution. (Score:2, Insightful) by Otto on Tuesday December 28, @09:02AM EST (#331) (User Info) http://slashdot.org/comments.pl?sid=Otto However, I thought of a possible solution - one way to stop AimBots might be for the server to send a few "fake" players to the client with either transparent skins, or embedded in the walls, or perhaps randomly "clone" the user just behind himself every now and then. A real player would never see these "shadows" but an AimBot would fire at these pahntom targets and that could trigger the server to shut him down. Good idea, but not going far enough. Here's a fairly simple way to detect aimbots... From the server, send a packet that says to a client "there's a guy right behind you". Not a fake guy, make it real. The guy doesn't really have to exist.. The server keeps track of things like that, so as long as the server knows it's fake, no biggie. Plus, the server doesn't broadcast one message to all clients, it's quite easy for the server to send "there's a guy right behind you" only to the guy that has the guy right behind him. Since it's right behind him, he'll never see it. Since other clients aren't told about it, they'll never see it. But that pesky bot will see it and fire away. Two things can happen then. The server can detect that this guy keeps flipping 180 degrees to fire on the guy he's not supposed to be able to see, and kick/ban him, OR, you can watch this idiot flip back and forth and laugh until he goes away. There is a possibility of a normal player seeing the fake guy, if he's lagged a bit and makes a fast turn. So, i suggest only telling the client that the player is there every so often.. just inserting the player into a packet once in a while to see if the guy fires at it very fast. That way, the chance of someone spinning around and seeing the fake guy is minimal, but the bot will be fast enough to fire at it. One other possibility.. Put the fake guy UNDER the real guy, half in the floor.. Then the bot will fire at the ground directly under the player, possibiliy splash damaging the hell out of him. --- "Never underestimate the power of human stupidity." - Lazarus Long Re:Stopping AimBots - a possible solution. (Score:2) by Raphael (quinet@NOSPAM-gamers.org) on Monday January 10, @09:53AM EST (#355) (User Info) http://www.gamers.org/~quinet/ Here's a fairly simple way to detect aimbots... From the server, send a packet that says to a client "there's a guy right behind you". Not a fake guy, make it real. The guy doesn't really have to exist.. The server keeps track of things like that, so as long as the server knows it's fake, no biggie. Plus, the server doesn't broadcast one message to all clients, it's quite easy for the server to send "there's a guy right behind you" only to the guy that has the guy right behind him. Since it's right behind him, he'll never see it. Since other clients aren't told about it, they'll never see it. But that pesky bot will see it and fire away. Good idea. But as others have pointed out, this could lead to another generation of bots, which would not shoot at these dummy fake targets so that the server would not detect that they are bots. Here are a few examples of things that a clever bot could do to check if a target is valid or bogus: If the target has a fully transparent skin, it is bogus. If the target is stuck inside a wall, it is bogus (requires BSP tests). If the target is on the other side of a wall and is not moving, do not shoot: it may be a fake or a real player, but in any case it is not moving so we should not shoot at it yet. If the target is behind you (let's say between -150 and +150 degrees) and it has never been seen before and it is not shooting at you, then do not shoot. But turn around from time to time to check if this could be a real player. If the target is behind and it has been identified before as a real player, then flip 180 degrees and shoot. If the target is moving in a way that would be impossible even with movement prediction/correction (e.g. a player that is constantly behind you even if you do some fast spins) then it is bogus. In all other cases, shoot. This could probably be refined a bit, but as you can see it would be possible to create a bot that tries to fool the server-side aimbot detection schemes. But... there is still one thing that could be done to detect the bots, and maybe that could make the aimbots much less useful: instead of inserting bogus players into the walls or immediately behind or under the bot, put them in another hallway that is part of the PVS. Make the dummy run like if it was about to be visible a few milliseconds later. And make it disappear just when the bot would expect it to be visible. This has to be timed right in order to ensure that the dummy does not become visible even if there is some network lag, but I think that it would be nice to have something like this to detect the aimbots. So if the bot shoots at the location where the invisible player would have entered the room, then mark it as a bot and the problem is solved (ban the cheater). If the bot does not shoot, then the problem is also solved because that bot will only shoot at visible targets. Besides that, I think that two of the best solutions mentioned in the other replies to this article are: Reputation servers. If you want to play, you have to be registered. If you are marked as being a cheater, most servers will ban you. Signed clients and servers. Everyone can use and modify the source code of the clients and servers, but from time to time there are some "official" releases of the client and server that are digitally signed and contain some challenge-response mechanism. The signed servers have an option to accept only signed clients, so that nobody can cheat on these servers. Of course both of these solutions can be abused too, but it is more difficult. You could register multiple players and move to another one when one is marked as a cheater, but it would be difficult to go very far with that. Also, a clever hacker could break the challenge-response mechanism in the signed client and create a hacked client that gives the same responses as the official one, but that would take time (hopefully longer than the time between releases). No system is perfect and nobody has an infinite amount of time to spend on making the games more secure. But some solutions can make cheating difficult, especially if the cheat is obsoleted by a new release. -Raphael How? (Score:2, Insightful) by Anonynous Coward on Monday December 27, @12:29PM EST (#104) (User Info) How can so many slashdotters miss the point so completely? Comparing Quake to E-Commerce is just silly to begin with. Quake wasn't written to be a secure platform for anything, its a freaking game for christssake. Cheating in Quake will always be possible. I'm pretty sick of reading posts on these two threads where someone who doesn't even recognize the problem is trying to offer solutions. BY FAR the most troublesome cheat you can do with any Quake, open source or not, is use an Aimbot. You CANT STOP aimbots with any fancy autorization system. YOU CAN'T. NOT EVER. You can only obsecure protocols. Even if you coded algorithms on the server that detected "bot-like movement", a coder could just make his bot algorithm differ from what the server considers BOT-LIKE. This would be even easier if the server source was open source as well! Hell, you could even write a proxy bot that doesn't move the crosshair aim for you, it just shoots when it can draw a ray between your gun origin and an enemy. In this way, all the bot does is pull the trigger when you sweeep your railgun across an enemy. Try detecting that on the server. Its impossible. All you can do is use some half-baked fuzzy logic that says "Well Player-X is too good, he must be a BOT!". Which is not security at all. Even without source to the client open source of other system components can cause problems...NVidia/3dfx have open source OpenGL drivers under Linux? Cool .. why not write a program which sits between the mouse driver and the opengl driver, takes information from both and use that to cheat? Harder than hacking open source client, but still entirely possible. This whole issue doesn't speak badly of Open Source, nor does it (as many people here think) speak badly of how Quake was implemented. Its just the way things are. If someone wants to try to create a "secure client/server" chess system that someone sitting next to Big Blue running his chess program can't cheat at, please get back to us when you figure out how. The serious Quake cheats are in the same category as this, and just can't be solved without using some security through obsecurity. Re:How? (Score:1) by ppanon (ppanon@home.NOSPAM.com) on Monday December 27, @01:54PM EST (#166) (User Info) Yeah but the general public doesn't have enough understanding of computer systems to understand this. It is potential ammunition for FUD by Microsoft in trying to discredit Open Source approaches. What Eric and others are trying to do is educate the general public so they don't start thinking exactly that a Quake vulnerability == Open Source application vulnerabilities. It's food for lurking reporters who don't know any better. Don't get all hot under the collar; if you're not part of the target audience, let them read it and move on... Then again it does mean that it isn't news for geeks, but geekisms for newsies :-) I Agree... ESR Misses the Point completely (Score:0) by Anonymous Coward on Tuesday December 28, @01:22AM EST (#306) The POINT of "twitch" FPS gaming is just that.. it's twitch based, and requires millisecond accurate packet timing. This is a REQUIREMENT. Quake would be a BORING ASS game if movement was sampled in anything less than milliseconds. ESR is missing the point completely when he suggests that Aim Bots might have been eliminated had Quake been developed in an open-source fashion from the start. I disagree. The nature of the game places several hard constraints on the design of the game system, some of which cannot be solved simply by peer review. Open Source Commercial Games? (Score:1) by semiriot (lo_rez_semiriot@hotmail.com) on Monday December 27, @12:30PM EST (#105) (User Info) http://www.jive-turkey.com Will we ever see open source commercial games in the mainstream? Not any time soon. Where would the financial incentive be if you were going to release a game, and give away the source for it? Assuming you had a good product, you'd end up competing with a bunch of other companies, each with their own distrubution of your game. RedHat Quake, Suse Quake...no..somehow I just don't see this happening. Has ESR taken into consideration that id is in the game business to...gasp...make money? Open Source is fine, but sometimes I wonder if we're delusional to think that it can solve any software problem. I mean, if my steak isn't cooked well enough, I just send it back to the chef. I don't pass it around to all my chef-buddies to see if they can cook it better. sunny fish melon jelly balling the jack at the meat wagon now Re:Open Source Commercial Games? (Score:1) by whoop on Monday December 27, @01:33PM EST (#150) (User Info) You could always make a single player game. Open up the game code, and sell your levels/storyline/etc. If it's good enough, people will buy. There are still plenty of people that just don't care about playing multiplayer. Half Life made a lot of noise because it had a decent single player story. It would be interesting to survey all these games, Half Life, Unreal, etc and see how they handle the issue. Do they all rely on the client to be honest like this on net games? Re:Open Source Commercial Games? (Score:1) by Edward Kmett (harmless@junk.mich.com) on Monday December 27, @01:47PM EST (#159) (User Info) http://www.bloodshed.com/ Each of the games mentioned use a PVS or a derivative thereof for visibility determination. A PVS is not a perfect set, so there will still be some splash into the non-visible area. The client remains vulnerable to the same proliferation of aimbots, driver hacks and the ability to see around corners that has plagued Quake 1 since its inception. Madness takes its toll. Please have exact change. Remove the junk to email me. Re:Open Source Commercial Games? (Score:0) by Anonymous Coward on Monday December 27, @03:18PM EST (#204) The approach you mention is used heavily in the shareware industry: You could always make a single player game. ... and sell your levels/storyline/etc. If it's good enough, people will buy. My concern is that Open Source for games is going to put the little guy out of business. The little guy who creates shareware in his spare time with the hopes of one day it developing into a full time business. This dream has materialized for a number of shareware developers and my concern is that open source is going to put the shareware guys out of business--pronto! ESR fails to mention other cheats (Score:0) by Anonymous Coward on Monday December 27, @12:33PM EST (#108) He mentions aim-bots, but as I understand it, much of the game's behavior is determined by the client side, so in a hacked client, the aim-bot would be one of the more subtle cheats possible. Worse ones could be the ability to pass/see through walls, teleport instantly anywhere on a map, get additional health/armor/weapons/ammo, fly, and probably any number of other hacks. Adding code to detect aim-bots would be like installing a sump-pump in your basement when there's a 15-foot flood on its way. The core of the problem is that the client side has all this control (a requirement in light of performance/bandwidth demands) which makes it inherently insecure. ESR is wrong, though, to dismiss this issue as one of "millisecond packet times" only relevant to twitch gamers. Surely there are other client-server situations that call for (or would benefit from) more client-side control? Is there any way to create a truly trusted client in an open-source environment? The best solution here would be to find a completely open-source solution. Re:ESR fails to mention other cheats (Score:1) by Anonynous Coward on Monday December 27, @12:47PM EST (#123) (User Info) Please go read up on how Quake's client/server model works before you post here again, because your assumptions are all entirely wrong. AIMBOTing is the most DAMAGING hack of all. Because all of the rest that you mentioned can't happen. Re:ESR fails to mention other cheats (Score:1) by Anonynous Coward on Monday December 27, @12:48PM EST (#125) (User Info) Please go read up on how Quake's client/server model works before you post here again, because your assumptions are all entirely wrong. AIMBOTing is the most DAMAGING hack of all. Because all of the rest that you mentioned can't happen unless the SERVER is hacked code. Re:ESR fails to mention other cheats (Score:0) by Anonymous Coward on Tuesday December 28, @05:19AM EST (#322) "He mentions aim-bots, but as I understand it, much of the game's behavior is determined by the client side, so in a hacked client, the aim-bot would be one of the more subtle cheats possible. Worse ones could be the ability to pass/see through walls, teleport instantly anywhere on a map, get additional health/armor/weapons/ammo, fly, and probably any number of other hacks." No, actually most of the game is controlled by the server. The client can see some objects that should be out of sight, and controls aiming, as well as sending requests to move. But the player still can't disobey the laws of physics (as defined by the game server) or rules of the game, nor can it use any of the cheats that are disabled in multiplayer mode (fly, god, etc.). So aim bots are the only "behavioral" change possible from the client side, with various other cheats possible to give extra information (seeing through walls, making all enemy players, including invisible ones, glow or have "rods" that show through walls, etc.) But flying, teleporting, giving extra health, etc. would all require hacking the server (to change the rules of the game). But detecting aim bots IS quite difficult. They can be designed to be quite subtle, and with on/off toggles, decent players can cover them up quite effectively, so they're VERY difficult to distinguish from sometimes-inspired human aiming. There has been a lot of convtoversy of this with professionalg gaming and accusations of cheating, where examination of the demo playback of the game (even from the "cheater's" point of view) is indeterminate. A Launcher program will not suffice. (Score:2, Interesting) by victim on Monday December 27, @12:38PM EST (#112) (User Info) http://www.federated.com/~jim The fatal problem of a launcher program is that everything required to perform the client checks is included in the launcher and hence available for reverse engineering. This is directly analogous to the DVD software decoder problem. If the binary is available, the algorithm and all the keys are available. Having, shall we say, "studied", my share of copy protection schemes I can attest that very little of a binary must actually be understood to coerce it into changing its answer. And just so its all out on the table, here's my roadmap for launcher breakers. Please note that none of this has been tried, I just dashed this list off with 2 minutes thought. Use strace, if they use exec* to start the program, then patch exec to substitute your unclean program after the clean one is verified. (I'm thinking a preloaded library here, kernel patching is ok too.) Pick a library or system call used in the client after it has been verified. Subvert it to replace the current executable but keep the file descriptors to the master loader open for use. Disassemble the loader. Go to a nice quiet place and start reading, commenting, reassembling, and testing. Once you get the knack its surpisingly easy. While one of the most enjoyable experience to be had with a computer this is slower and should be the last resort. You will only need to do this if they have implemented from scratch their own loader, and they will rot in OS version compatability h*ll until users become disgusted with thier software. Note: any apparent confessions in the above post were merely a "youthful indiscretion" and have certainly passed the appropriate statue of limitations. Re:A Launcher program will not suffice. (Score:1) by matso on Tuesday December 28, @01:10AM EST (#305) (User Info) The fatal problem of a launcher program is that everything required to perform the client checks is included in the launcher and hence available for reverse engineering. This could be made more difficult by using one-time launcher programs - ie, a new launcher would be generated for every connection to every server, using templates, crypto keys and a launcher program generator. Cracking one launcher program wouldn't help directly because it can't be used for new connections anyhow - unless you could figure out the generator/template combo and reverse engineer the crypto key/code out of the loader binary fast enough to take over the connection. The real fatal problem is that at one time or the other the loader have to trust the environment the loader is running in, and as you point out, that's the easier attack anyhow. Opening Source for Windows (Score:2, Insightful) by musique (lafleurh_over-at_worldnetMysteryMeat.attSucks.net) on Monday December 27, @12:39PM EST (#113) (User Info) If the security model of closed source fails, it will not fail immediately. The next security model will take time to crack next. In the end the latency of closed source security for software being cracked will have a given time, say 3-5 months average. If software relies on closed source for security and it is made open, such as the opening of Quake, then all of the security weaknesses can in essence be exploited simultaneously. Software that is from the beginning open is inherently more secure than closed source software given the source code. So, the question becomes what effect would opening Windows source code have on Windows security? There have been so many back doors found in the past six months that I can only imagine that a metric ton of them would be found. Since the Justice department sees open source Windows as an option to cure the Microsoft monopoly, couldn't this be counter productive for average Windows users--ill equipped to install software, much less a patch--in the short term? Are (potential) long term benefits of this worth the short term cost? ESR, just stick to counting your fscking millions (Score:1, Insightful) by Anonymous Coward on Monday December 27, @12:43PM EST (#118) I specifically recall seeing ESR at a local appearance where he was asked if games should be open sourced. His answer was an emphatic *NO*, and he explained why. I don't recall all of his explanation, but basically he whittled down all of the logical reasons to have a game open sourced, stating that the benefits would be minimal. For more info, I'm sure (if cornered) ESR would have no choice but to re-explain this stance. Furthermore, I thought that one of the great things about open sourcing software was that holes could be plugged. Rather than discussing plugging holes, all I see people doing here is bitching about how this open sourced Quake I offering isn't as plug-and-play as some would have wished. Have open source advocates gone full swing in the other direction and decided that things like Quake I need to be fully cooked right off the FTP site? If so, and nobody is planning on doing any work with the sources, I have to ask: WHY THE FSCK SHOULD ANYONE BOTHER OPENING SOURCE CODE?? Whiners... Stop bitching, grab GCC, and FIX it. Otherwise, get out of the way and let closed source software stay closed. (Yes, I'm an open source advocate. I'm disgusted with what open source advocacy is becoming, though: a bunch of me-too kiddies who don't have the first clue what open sourced software is all about. Kind of a Linux-One thing but from a user standpoint. Get real.) Re:ESR, just stick to counting your fscking millio (Score:0) by Anonymous Coward on Monday December 27, @07:43PM EST (#281) I thought it was obvious that this article is simply a pre-emptive rebuttal against the inevitable FUD that will shortly appear. The FUD that will say "The Quake model would be secure for your enterprise transaction needs as long as your protocols and software is Microsoft(TM) Closed-Source(TM) certified". The article states that the Quake model is not secure in any form so that the FUD doesn't get realised - It does not argue that games should be open-source and written securely, just that enterprise solutions should be written better anyway. -- Tristan Wibberley ESR is less and less credible by the second (Score:1) by Dan Guisinger on Monday December 27, @12:43PM EST (#119) (User Info) To make Quake run on slow networks and modems it had to make trade offs...saying these wouldn't have existed if open source is bullshit. People would have just taken advantage of it earlier on. What really irks me is he just try's to push open source for everything. Its his own agenda. He is famous, he likes the attention. Multiplayer games should NOT be open source for this reason. Think about it, even if you let the server decide everything, you still need to send actions (Move forward, etc) to the server....this can be sent the wrong way, so with a minimal client you still could crack the game. Whats the advantage of closed source? Easier to PREVENT major hacking and cheating groups. So what if one person hacks it? Its a lot better than the hundreds if not thousands doing it right now. ESR should pull his head out of his ass and realize or atleast tell his faithful followers that not everything is nessecarly a good thing to open up, or if so, maybe the Quake graphics engine should have been all.... Way to thank John Carmack (Score:0) by Anonymous Coward on Monday December 27, @07:14PM EST (#276) John Carmack releases source code, and Eric Raymond rewards him by using what Carmack did out of necessity, to make the game playable, as an example of the problems of closed-source, while not being anything Carmack could have done anything about. That's no way to treat a person who's as pro-open-source as John Carmack, & has opened his own code as much as is reasonable. It amounts to misusing Carmack's generosity. I hope Eric Raymond isn't starting to get one-track minded like Richard Stallman (as useful as that has been). Re:ESR is less and less *relevant* by the second (Score:0) by Anonymous Coward on Monday December 27, @07:56PM EST (#284) If ESR rants in Slashdot, and everyone ignores it, does it make a sound? Face facts, ESR. Your glory days are gone. Stick to the Dictionary. Even the playing field...(?) (Score:0) by Anonymous Coward on Monday December 27, @12:45PM EST (#120) If its such a problem, why not just make the bots part of the client. The incentive to create them will just go away. This is basically making the bots akin to the 'reboot' UN*X program some systems had way back... A few comments (Score:0) by Anonymous Coward on Monday December 27, @12:56PM EST (#130) 1. The aimbot issue is irrelevant to a discussion of security for business purposes. For example, nobody who is selling products online will care if the order is placed manually or by a bot so long as the order and billing information are valid. 2. Selecting closed source or open source as your development method does not alter physical constraints; what Carmack and Raymond both say indicates that even if Quake had been developed as open source software it still would need to send some information in advance in order to attain acceptable speed. 3. A business application differs from a networked game. Everyone playing the game has access to both the client and server programs and can modify them, whereas a business has its server software on its own system where nobody can mess with it (unless they manage to break into that system), so even if the source code is widely available there is still a measure of security. 4. The consequences of breaking security on systems implementing commercial transactions are far more serious than those of someone cheating on a game. So it seems to me that the analogy between games and online business muddies the waters rather than clarifying security issues. Mentioning issues unrelated to the main topic of discussion (see comment 1 above) adds to the confusion. --- Brian Security through obfuscation... (Score:4, Interesting) by David A. Madore (david.madore@ens.fr) on Monday December 27, @12:57PM EST (#131) (User Info) http://www.eleves.ens.fr:8080/home/madore/ ...is just something that has never worked, will never work, and cannot work. Every now and then someone tries to use it (the DVD Consortium for example), arguing that ``yes, in general security through obfuscation is bad, but in this particular case it will work''; wrongo: it always fails. This is made abundantly clear in Bruce Schneier's famous book on cryptography. This is not an open source vs. proprietary software problem, it is a disclosed source vs. obfuscation problem. This is not an ethical issue, it is a completely practical one, and it seems that the lesson needs to be learned one more time. Carmack's suggested closed-source binary loader can be spoofed much more easily than by using a proxy. Indeed, it contains an obvious race condition: how is the loader to check that the program hasn't been altered between the time it is checksumed and the time it is run? A simple ptrace() should do the trick for that, and, in fact, anything invented along similar lines. As another poster pointed out, what we need is to have Quake clients act as simple 2D rendering clients. But that means the server would have to perform all the 3D calculations and that is hopeless. We want the client to perform the calculations without being able to spoof them; so the problem amounts to the following: (``Computing in `hostile environment' ''). You are given a powerful computer and you want to use it to perform a computation. However, you cannot trust the computer. You want to perform the computation in such a way that the computer should be (a) unable to fool you (i.e. give a wrong answer and make you think it is the right answer), and (b) unable to learn anything from the computation (in the Quake case, learn more than the final, 2D, result). The computer can refuse to carry out the computation, of course, and you cannot prevent this, but it cannot make you think it carried out the computation whereas in fact it is fooling you. This is a purely theoretical problem, and it has been studied. A cryptologist told me (but was unable to give a reference, unfortunately) that the problem is solved in the theoretical sense: computation in hostile environment is possible (using strong crypto). This makes it theoretically possible to have a solution to the problem using just one secret key, stored on the server and everything else being disclosed (basically: the server sends the encrypted computation to the client, the client performs the computation without knowing what it is calculating, sends it back to the server, the server verifies that the computation was correctly carried out, and sends the decrypted result to the client). Unfortunately, this solution is completely unpractical (the bandwidth required is simply too large). So, the Right Thing fails. IMHO, this is not, however, an excuse to do the Wrong Thing. If the problem has no solution, then the problem is not a problem! Re:Security through obfuscation... (Score:1) by osmanb on Monday December 27, @03:53PM EST (#222) (User Info) So, the Right Thing fails. IMHO, this is not, however, an excuse to do the Wrong Thing. If the problem has no solution, then the problem is not a problem! You've GOT to be kidding? Please, tell me you're joking. Or, go tell every computer scientist writing heuristics to NP-complete problems to find a new job. We can't solve TSP (at least not doing the "RightThing") so we should just forget about it? We can't write a good multiplayer game using OpenSource so we shouldn't write the game period? I'm really sorry, but what are you smoking? And where can I get some? I'm not advocating closed-source solutions, but doing the WrongThing may be the only way to fix this. We have to accept that until computing power and networks enable the "RightThing," some other solution should be used. As other people have pointed out, this is not national security we're dealing with, nor billions of international dollars. People can cheat at an old game. The lessons can be learned by the private sector for "more important" applications. -Brian Re:Security through obfuscation... (Score:2) by David A. Madore (david.madore@ens.fr) on Tuesday December 28, @09:58AM EST (#339) (User Info) http://www.eleves.ens.fr:8080/home/madore/ Ha, ha, only serious. Yes, I was saying that in a tong-in-cheek way. For example: the basic problem is that people are dishonest. The Wrong solution is to use passwords and such; the Right Thing would be to make everyone perfect. But I am not Richard Stallman to continue using 'rms' or the empty string as a password because that is the Right Thing. I use passwords even though they are the Wrong Thing. So, obviously, I can only be joking when I make this claim. Still, it should at least make yourself wonder if there isn't a better way to deter people from cheating, like, try to persuade them that it isn't fun and that it spoils others' pleasure, or ban them if they are caught at it. Or some such thing. I'm not saying it will work, but I think it should at least be considered before jumping to solutions like are being proposed. In any case, the essential point is that a binary loader just makes it slightly more difficult to cheat. I'm sure someone can easily come up with an (open source?) program that will spoof the loader in a systematic way. (As I pointed out, all it takes is a ptrace().) ``Never let your sense of morals prevent you from doing what is right.'' -- Salvor Hardin Silk Purse from a Sows Ear is just manipulation. (Score:1) by Cvandal on Monday December 27, @01:07PM EST (#136) (User Info) Interesting thing about coal, you put enough pressure on it for long enough, and you get diamonds. Re:Silk Purse from a Sows Ear is just manipulation (Score:0) by Anonymous Coward on Monday December 27, @02:10PM EST (#173) To quote Dilbert: "Pressure makes garbage more compact!" The Art of War (Score:2, Insightful) by csfenton on Monday December 27, @01:07PM EST (#137) (User Info) I am heavily involved in e-commerce. ESR points are valid and well made. However, I think the issue can be taken into another venue which is not far from Quake: "The Art of War", Sun Tzu. Cheating is exactly what you want to achieve in a war using any means possible to achieve them: limited disclosure, deception, technology, etc. The issue is the same that ESR makes regarding open source; if you know all the cheating that goes on prior to, and in the midst of a battle, it …changes the behavior of developers. Which may then change the game, because the rules (requirements) are no longer the same. E-commerce communities must war/defend against any entity, hostile or otherwise, that would encroach on the territory established for commerce. So many comments, so little time….. "There is nothing new. Everything is just smaller, faster, and cheaper, with more layers of the protocol stack at no additional cost." csfenton Re:The Art of War (Score:1) by rhk (rhk-nospam@newimage.com) on Monday December 27, @02:05PM EST (#171) (User Info) http://www.newimage.com/~rhk Good point. For example, if someone makes an aim-enhancing cheat, someone else might make a shot-dodging cheat, which cancel's it out. As long as everyone has the cheats, it's still a fair field. Re:The Art of War (Score:1) by skrew (skrew@I_SLAY_SPAMMERS.email.com) on Monday December 27, @08:10PM EST (#286) (User Info) ftp.porn.org In a conceptual sense, what you are saying is true...but in the contextual instance of Quake, thats unworkable...if the counter cheat to aim bots is that you can dodge shots, whats the point of playing? The whole point is to shoot your opponenets...I definitely disagree that making the cheats "part of the game" is a bad direction to take... All we need is aim bot proxy detection... maybe there could be things like, if the server detects a proxy client, then the proxy client spawns with less health than the other clients? My other modem is a multihomed OC256 And you people wanted to open the Windows source? (Score:4, Interesting) by Tony Hammitt (tSPAMhammitt@kc.rr.com) on Monday December 27, @01:10PM EST (#138) (User Info) Guess what would happen if the windows source code suddenly became open? All kinds of cracks would appear. We've just proven it. They open the source for Quake1, and within days, there's people out there playing cheat clients. It wouldn't take even hours for the world's windoze boxes to all be cracked if they opened the source code. Anyone depending on windoze would simply be out of business. You can't go from 'security' through obscurity to open source. That is the main problem. All of this other stuff about the details of how people cheat when it happens are not the core issue. The core issue is that the development model cannot change from closed to open source without exposing all of the security flaws. Suddenly there are thousands of eyes looking at the code for weaknesses where before there were only dozens (who were mainly interested in functionality, not security. Why should they care; it's closed source?) So, how do we fix it? We could develop games entirely open source. Who's going to pay for that? People don't buy support contracts for games; they rarely buy the manuals. We could try to convince Carmack to release the code in stages. Release the server code first to get all of the bugs and cracks worked out. Then release the clients after most of the hacks have been anticipated. This is still suboptimal, with optimality being the unlikely open-source case. Anyone have any better ideas? Yes, I know, there are plenty of open source projects. They usually only have a dozen developers at most. I doubt they would pass a security audit. I know most open source net games are crackable, I've done it myself. Maybe in the future they will give the code a security audit before they release it. They're doing this as a publicity stunt anyway, they might as well get the most out of it. Re:And you people wanted to open the Windows sourc (Score:1) by EAVY (slashdot-nospam@eavy.eavy.de) on Monday December 27, @03:47PM EST (#217) (User Info) http://eavy.net/ So, how do we fix it? We could develop games entirely open source. Who's going to pay for that? People don't buy support contracts for games; they rarely buy the manuals. How about differentiating between the Engine and the Game? The engine should be open but the game's content (graphics, sounds, etc.) could be paid for! The engine itself is small compared to the rest, it could be easily downloaded, but if the contents are huge (bigger than a DVD) it's well worth buying it. The engine would be like the Operating System, definitely Open Source, and the contents could be free or proprietary. This would give open source developers an advantage, a free engine, a great toy. And the engine itself, improved by hackers world-wide, would benefit the content producers and game creators as well. A Win:Win situation... -- Eavy (: Linux Is Not UniX :) Re:And you people wanted to open the Windows sourc (Score:1) by Otto on Tuesday December 28, @09:06AM EST (#332) (User Info) http://slashdot.org/comments.pl?sid=Otto How about differentiating between the Engine and the Game? The engine should be open but the game's content (graphics, sounds, etc.) could be paid for! To a certain extent, this is how id has been doing it anyway.. Not releasing the source, but the engine freely. Check ftp.idsoftware.com... You can download the linux version of the engine for the quake games quite easily. All you have to do is plug in the pak files (art, sound, levels) and the game works. --- "Never underestimate the power of human stupidity." - Lazarus Long Re:And you people wanted to open the Windows sourc (Score:2) by iCEBaLM (icebalm@[NOSPAM]bigfoot.com) on Monday December 27, @03:57PM EST (#224) (User Info) http://www.lucid.dyndns.org Guess what would happen if the windows source code suddenly became open? All kinds of cracks would appear. We've just proven it. This might start to sound like flamebair but I don't particularly think this is a Bad Thing(tm). There is no shortage of Windows cracks/hacks/"security" subversions/DoS attack programs, etc as it is now, a few million more wouldn't hurt so bad, MS would just sell everyone a service pack for $59.95. More people might wake up to how crappy MS software is and demand better instead of just putting up with it as they seem to be. Not to mention it might force MS to write better code in the future, but I doubt it. I mean think about it for a second, if MS coded the best OS in the world now, free of bugs, rock solid stable, secure as the US Federal Reserves in NYC, what would they sell next? Its part of the corporate business model to make sure they still have a product later, something Open Source doesn't suffer from. It'd be a huge wake up call, thats for sure. Something MS desperately needs if you ask me. -- iCEBaLM Re:And you people wanted to open the Windows sourc (Score:1) by D. Taylor (davidt-sd@xfiles.nildram.spam.co.uk) on Sunday January 02, @03:01PM EST (#353) (User Info) Wrong: it has nothing to do with Windows. Quake breaks as open source, because people can change the rules of the game, and cheat. Windows, well, who cares if people make their own box crackable? changing windows wouldn't make other boxes less secure. The fact that opening the source exposes current bugs is different, and is *good* -- once the bug is discovered, a fix is usually available instantly (nearly) on bugtraq. -- David Taylor davidt-sd@xfiles.nildram.spam.co.uk [To e-mail me: s/\.spam//] How about the netcode in "Starsiege Tribes?" (Score:1) by Kit Lo on Monday December 27, @01:15PM EST (#140) (User Info) http://www.ultinet.net/~kitlo/ I know Tribes does not have its source code published under the GPL, but how does the Tribes engine work out the "who's the nearest player" information sent from the server to the client? -- "The stone that the builder refused, shall be the head cornerstone." -- Mark 12:10 Cheating for what gain? (Score:2) by jelwell on Monday December 27, @01:25PM EST (#145) (User Info) This whole quake cheating thing is a non issue. People have been cheating in mutli-player games since day 1. Whether they've been closed source or open source. I remember people cheating in Doom for god's sake. But who cares? Everyone quickly learns who the cheaters are and refuses to play with them. Issue Resolved. Whenever you play multi player games that let the clients decide the outcomes there will be cheating. Diablo was a good example of this. There were cheats that allowed you to kill a player while in town - something that wasn't supposed to happen. There were ways to create magical items that didn't exist. None of this mattered. Blizzard handled this easily by saying you shouldn't trust anyone. And it was so true. If you play with your friends you'll never have to deal with cheating anyways. If you want to play with random people then you need to learn to make friends and associations that will prevent cheaters from playing with you. On the other hand, I hear Ultima online and Everquest are good code bases for cheatless systems. From what I understand the client only displays the world and allows users to send known commands back to the server which can be checked server side against the user's character which is only stored on the server and not allowed to be modified by the client. Joseph Elwell. It's not Cheating, It's Open Source! (Score:0) by Anonymous Coward on Monday December 27, @04:07PM EST (#228) Before there was open source, there was closed source software which the cheaters cracked. Now that the source is open there are more cheaters. But since the source is open, the cheaters really aren't cheating. Who cares about cheating? The gaming industry cares about cheating. JC must be feelin' awfully bad about this one. Who cares about cheating? Games developers care about cheating. Who'll want to play their games if it's so easy to cheat. Once upon a time, games were about skill and good sportsmanship. Now games, including athletic ones, are about drugs that give you a competitive advantage. Or, in this case, how many ways you can alter the source to give you a competitive advantage. The world has gone totally to pot! And, yes, highly talented people, many who don't "fit in" in conventional environments, the talented ones like JC actually find a niche and make their living by creating games. I'm sure most of the people who've posted on slashdot, as well as most of the people who are open source developers have attempted at least a time or two to make a game. Did the game become popular and take them out of their humdrum lives. NO! It takes a special person, it takes a team, that is market-driven to make great computer games. It takes innovation. And, there's no innovation in open source, only duplication. The lesson to be learned . . . (Score:1) by palutke (palutkek@asme.org) on Monday December 27, @01:37PM EST (#153) (User Info) . . . is that programs that are designed with closed source or protocol as part of the security scheme aren't likely to hold up well (without major changes) once they're open sourced. (Sorry if I double posted this, I suck) -- 'Hey Look! It's not my fault; It's some guy named "General Protection."' - Ratbert OT: Now a new game (Score:1) by dsweet on Monday December 27, @01:46PM EST (#158) (User Info) OpenSource security issues aside, it sounds like it would be very cool to play Quake against people who have hacked at the source code (as long as I have, too). The game would be "Who hacks the best Quake client?" rather than a simple shoot-em-up video game. It would certainly offer a new type of challenge. Dave http://www.chaos.umd.edu/~dsweet The bigger picture (Score:1) by gilga_mesh on Monday December 27, @01:47PM EST (#160) (User Info) There will always be people who can hack any game (quake, starcraft, diablo, us banking system). Given a reasonable amount of security (ie, more than any game out there, but not 100% secure), the number of people who can (and who actually will) undetectably hack the game is very small. Add to this that most talented hackers are also responsible hackers, and that they probably get a bigger kick out of making the hack than using the hack, and the problem is almost nonexistent. So what if a few people test out an aimbot in quake 9, or for that matter if they steal a few million from the banking system (hey, if they pull it off undetected, they deserve the $$). The problem is not that these people hack the game, it's that they make their work available to everyone (further evidence that they are not interested in using the hack. If they want to benefit from it, why give it away to everyone??). The multitudes of people who download the hack and use it irresponsibly are the problem. The Diablo fiasco (bearing in mind that the diablo hack was *very* easy. However, had there been encryption and other safeguards, it would have been difficult enough that only a small percentage of people could have done it) illustrates this point. The problem wasn't that one guy hacked the game and got some gold, it was that the hack got distributed, and anyone download a patch and got free gold. Anyway, the point to all this is that it is useless (and unnecessary) to stop hacking. With a *reasonable* amount of security, only a few people will be able to hack the game. Their impact on the game will be minimal. Instead, we need to go after the people that download the hacks. If we get rid of them, the problem goes away. So rather than waste time trying to make a hack proof system, we need to waste time trying to stop hack proliferation. So, how can we detect known hacks? And what do we do to the users? (easy on a persistent online game, just ban the account. What about games like sc and quake? blacklist? ban ip?) Aimbots (Score:1) by magi (magi@removethis.iki.fi) on Monday December 27, @01:49PM EST (#162) (User Info) http://www.iki.fi/magi/ I made a quick web search for +quake +"aim bot", and received for example the following address: http://go.to/aimbots/ They are proxies that sit between the closed-source client and the closed-source server. Yeh, there seems to be aimbots for Quake 1, 2 and 3, plus QuakeWorld. (They seem to be for Wincrap, and if they are .exe distributions, as they probably are, they very probably carry a horde of viruses too...so I wouldn't recommend trying them out...) I've been playing all the ID games, and done fairly well, EXCEPT in last year with the Quake2. For example, I am camping in the perfect place with my trigger-finger ready, and suddenly I'm blown to pieces with a railgun by someone whom I didn't even have time to see. Or I'm running, making evasive actions, and someone again blows me dead with a railgun from the other side of a hall. Repeatedly. And I can't hit almost anyone with the railgun. Maybe the Q2 players are just inhumanely good, I don't know. Also, some people run unnaturally fast (yeh, I've heard there's such a crack too). I guess making "aimbot detectors" isn't possible. Once you know what the criteria are, you can make a bot that circumvents the criteria somehow, and makes the player look just like a f*king good player. Nevertheless, I agree with the fact that closed-source software *slows down* finding obvious holes, and prevents it quite well if the application is such that no one bothers to crack it. But, if one can make megabucks of money with it, or get better score in a game, or get high status as a cracker, you can bet that it'll be cracked in a week... Re:Aimbots (Score:0) by Anonymous Coward on Monday December 27, @03:06PM EST (#202) ---They seem to be for Wincrap--- Sheesh - if you're going to do the childish "rename Windows" thing, at least try to show some imagination. Re:Aimbots (Score:0) by Anonymous Coward on Monday December 27, @04:15PM EST (#229) .... But, if one can make megabucks of money with it, or get better score in a game, or get high status as a cracker, you can bet that it'll be cracked in a week... If you're doing it for the money, you're addicted. If you're doing it for ego-boo, you're addicted. I strikes me as strange that no one has mentioned that games are an addiction that ruins the lives of thousands of people each year. Also, because the source is freely available and free to be tampered with, no one has even mentioned how much dishonesty this breeds. Games are supposed to be about skill, integrity and good sportsmanship, whatever happened to that? Sigh! ESR your missing the oppertunity.. (Score:2) by Weezul (gt5079c@prism.gatech.edu) on Monday December 27, @01:52PM EST (#165) (User Info) http://havoc.gtf.org/weasel ..to point out somne real advantages of open source game protocols. Specifically, human evolution via improved computer interfaces! We should not be doiing things to discurage these ``cheats'' we should be doing things to incurage structuring and sharing them. The aim-bots are a peerfect example of a good cheat.. as they consist of using a computer to improve a humans performance. Shure they take a little bit of the skill out of the game, but they give the human more time to think about stratagy and the importent things that only a human can do. I am a great fan of StarCraft/WarCraft/CC/etc. but the truth is these games have crap for a user interface. Who wants to spend all their time commanding individual units to attack specific targets during the conflict. Yet, this is what the game rewards. The truth is the only way to fix these games is an easy to use scripting langauge. Video games are a great oppertunity for human computer interactions research.. and the mechinism for this research is to write the tools to allow people to easily make the computer do more of the work. Scripts and bots are the pefect opertunity to help illiminate mindless repetitive action in video games and let us focus on the imprortent part of the game.. stratagy. Jeff BTW> I know some moron who only read the first paragraph ofthis post is going to reply about how unfair it is to be able to see arround corners in quake. Clearly, protocol based cheats like that are NOT what I am talking about here. I pretty much agree with ESR on protocol based cheats.. and I accept the possible need for blessed clients untill ping times are faster. It might even be reasonable to have blessed clients which shared your scripts with your opponent. Campus crusade for Cthulhu -- it found me. A partial solution (Score:0) by Anonymous Coward on Monday December 27, @02:00PM EST (#170) Most cheaters won't mess around with their kernel. We can build security of some sort into the kernel, like a library function that checksums a file and sends that checksum, encrypted with public key encryption. This won't stop serious cheaters, but it will stop casual cheaters. It's still a completely open source solution. Another possibility is the Net-trek like blessing system, with an auto-bless util, that allows servers to create clients that are blessed by them. The blessing would be done on a binary level, and would involve automatic obfusication: shr eax, 8 becomes ror eax, 8 and eax, 0xFFFFFF This could become arbitrarily complex, and there would be a strong incentive for hackers (in the RMS sense) to try and create better obfusication algorithms. It would be a contest, but it just might be a contest that players could win. -Dave Turner, AC of convinience pre-made/signed binaries - a solution? (Score:1) by Coventry (Coventry@netscape.net) on Monday December 27, @02:13PM EST (#174) (User Info) What about keeping the source for the game itself open source, but create a module in the source that handles encrypting and decrypting data sent back and forth between the server using an internally stored and signed key. The admin of Quake server foo would compile thier server And Client using thier own pair of key pairs (one pair for upstream, one for down), and distribute said binaries on thier website. Thus, to play quake on the foo server, you would need to foo quake binary, whose source is open, but whose key is not. Then the whole issue becomes one of convience (who wants to download 50 binaries for 50 diffrent servers?) and the strength of the encryption used. Of course, signed server binaries and clients wouldnt be limited to use on one server machine, quake world, for example, could with a reasonably sized encryption key, use the same binary for all of thier quake servers, and thus to play on any quake world server you would only need to make one download of the quake world client... of course, quake world could publish the source of thier client and server if they modified it, but they just wouldnt include thier key pairs in the source... Thus, we mix the power of open source for the development process, and the power of public key encryption with internal signed keys, by using distributed binaries for actual play. of course, it could always be a compile option to use the encryption (it would slow things down) - but if you dont have the proper keys in your binary, you cant play on anyone`s server(s). Of course, this also stops aim-bots, but it leaves several things that are hard to deal with: - Server admins would need to either be able to make thier own binaries on all platforms they wanted to support (how many people actually have a linux box, a bsd, a win9x, a winNT, and a mac, all with compile tools just laying around?), or purchase/obtain pre-compiled binaries from a trusted source. - Anyone who did have the tools, or only wanted to support one or two platforms, could compile cheats into thier own clients at the same time that they created the clients to be distributed to the public... or sell 'upgrades' to the standard clients that included the proper keys for thier server And cheats... - Players would need to download several sets of binaries if they are active deathmatch players - wasting time and bandwith... Anyone else have an idea that is a open source solution...??? man is machine Distributed.net has the same problem (Score:2, Interesting) by Paul Lamere (lamere@nospam.speakeasy.org) on Monday December 27, @02:16PM EST (#176) (User Info) Distributed.net has a similar problem with keeping a hostile client from supplying bad results. There solution is basically the same as Carmacks: keep some bits of the code private. Here is what they say: Why is distributed.net still not completely open-source with all parts of its source code? Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate. Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such. The source code available from this page is really all of the algorithmic code that would be of interest. The only code that is not present is the file-access and network socket code, which is not terribly interesting (nor pleasant to try to comprehend). The computational cores and platform-specific optimizations included in this package is what you would want to look at if you are interested in how the client works, or how you can increase the speed of the client for your processor. Rules of the game (Score:1) by BeerBaron (beerbaron at duff brew dot com) on Monday December 27, @02:16PM EST (#177) (User Info) Doesn't this simply change the rules of the game? Where playing "fair" is simply a matter of trust (as it always has been in real life)? Now, the object, for example, would be to create DodgeBots or movement randomizers (ie the user moves normally, but the computer constantly computes an odd path) to combat the AimBots. Or checks to see if the shot is, for example, rail shot, then you are 200 health suddenly. Back in my Side/Side fighter days, there were all sorts of "ultimate fighting techniques" that some people would learn. A skilled person doing this would be considered in "bad form". So what. Ego was built on doing it in "good form". A real skilled person learned techniques to combat the "cheats". It's all part of the game. As for parallels to real world...the performance vs security issue is prime. You want security AND performance, you wait until the software can give you both and not rely on kludgy solutions (closed security, obfuscated protocols). The BeerBaron Well, let's see where we are. (Score:1) by Animats on Monday December 27, @02:17PM EST (#178) (User Info) First, Carmack's closed-source verifier proposal won't work now. The verifier could be reverse-engineered, and the publicity the issue has received insures that somebody competent will do so for notority. So that's no good. Second, cheats really have to be divided into two types - breaking the rules of the game world, and providing additional assistance to the player. Quake is reasonably well protected against type-one cheats, because it's server-centric. Only type-one cheats are game-killers. It's worth noting, incidentally, that even if you have to make some key decisions like "did bullet hit player" in the client for latency reasons, you can check them in the server later and detect cheating without hurting latency. The TEN people (Total Entertainment Network, a defunct low-latency Internet for gamers killed by cheap bandwidth) did that. So type-one cheating is preventable, even in games more distributed than Quake. Look up the Byzantine generals problem for a theoretical analysis. Quake's particular problem is that some information known to the client is supposed to be hidden from the player. The client needs that data before the player does for latency reasons. So a type-one cheat the involves "peeking" at client data is possible. There's no obvious technical solution to this problem, and it impacts game design. One solution is to provide a "scanner" window to all players showing the hidden information. This changes the game, but puts all players on an even footing. Third, trying to prevent all type-two cheats is fundamentally hopeless. Even if the game server sent out video streams, a screen-scraper and image-processing program, like Agre's classic Pengi (which played Pengo) could act as an aiming 'bot. So you can't keep a good 'bot down. Fourth, only in recreational software is type-two cheating an issue; no one objects if I have massive computer power helping me on eTrade. So this is strictly a gamer issue; it doesn't affect E-commerce. So the problems raised by open-source Quake can, with difficulty, be solved, and the issue doesn't affect non-game open-source software. ESR is out of his field, and completely wrong. (Score:2, Insightful) by kbonin on Monday December 27, @02:18PM EST (#179) (User Info) I written this sort of code for a living for 10 years, and ESR doesn't even come close to understanding the technical issues involved. Instead, he's taken snippets from recent posts and built upon them yet another pulput for "open source will save you". His assumptions and solutions are flawed. Even Carmack's comments are predicated on yet another assumption - an environment of primarily statically loaded entities. Even through the use of extensive preprocessing and highly efficient resource management, it can take hundreds (or thousands) of milliseconds to load and initialize geometry before it comes into view. Quake can avoid this with small level size, low entity count, large memory footprint, local large disk or CD cache, and long level setup time. If VR applications are to move past the common set of constraints Quake imposes (which are completely acceptable for its genre of gameplay), then more issues are introduced. Very large worlds running across many distributed servers, clients utilizing continuous level of detail and realtime streaming preloading make it possible to wander around infinite sized worlds and never have to wait for a "loading" screen to interrupt the "suspension of disbeleif" so important in games. ESR's simple "fix" breaks this. If you want to prevent information cheating, you have code at the servers which examine user actions and determine if they appear to be acting on more information than they should have according to the game policies and the distributed master clock. This works for people shooting at targets on their way around corners, as well as aim bots. Simple heuristics can filter out false positives, such as lucky shots. Use digital certificates for robust user authentication with a difficult to automate "create new user" system and you've raised the price for cheating. Cheaters can be locked out, or even better, placed into games with each other seperate from the non-cheating players. I agree that Open Source is the way to go - security by obscurity is why most systems calling themselves "secure" are laughable to those who work in the field. But it is not a magic bullet. ESR's lessons: (a)Never trust a client program to be honest - This is absolutely correct, and I'd add that servers shouldn't be trusted to be honest either - clients should watch servers, and servers should watch each other. (b) you can't have real security if you trade it away to get performance, - I agree with this truism. (c) real security comes not from obscurity but from minimum disclosure, No, real security also comes from protecting information and actively monitoring for compromises. Minimum disclosure only works in a small subset of security models. If I hide a spreadsheet column that is too sensitive, and that column is needed, then no work will get done with that spreadsheet even if the client is open source. (d) only open source can force designers to use provably secure methods. I hate to berate open source, but I must, as this comment is the pulpit speaking. I would argue that "peer review" has worked just fine in many situations - the NSA has done quite well providing strong ciphers for its clients (by this I mean the ones it cares about actually protecting) without open source. Open source is a superset of classical "peer review" in this regards. There are some interesting lessons in this source base release. I hate to see them abused as a pulpit for incorrect information, especially when it hits near home (I run an open source massively distributed VR project). If anyone wants to learn more about the few hundred other cool technical problems in online VR, a recent book ("Networked Virtual Environments" ISBN 0-201-325577-8) provides a great overview, its the first I've seen that was written by people who knew what they were talking about. Re:ESR is out of his field, and completely wrong. (Score:1) by ESR (esr@thyrsus.com) on Monday December 27, @03:31PM EST (#209) (User Info) http://www.tuxedo.org/~esr/ We're not as far apart as you think. I actually talked about threat monitoring in the essay, though I didn't include it in my recap. I accept your criticism of point (c) as a friendly amendment and have changed the Web version of the essay accordingly. On point (d), we will have to agree to disagree. Situations in which small-group peer review of closed source works are so rare that they make a perversely bad guide to development practice. I think I'm a moderator now. If I have the capability when I finish this reply, I'm going to moderate you up. -- >>esr>> Re:ESR is out of his field, and completely wrong. (Score:1) by Artie FM (mcoatesDONTSPAMME@flashmail.com) on Monday December 27, @06:02PM EST (#259) (User Info) http://www.home.go/~kitchen/refrigerator/get40OZ/twistCap/drinkit/AHHHHHHHH You can not moderate an article you posted to. You will just waste your moderation pts. Re:ESR is out of his field, and completely wrong. (Score:1) by kbonin on Monday December 27, @06:59PM EST (#273) (User Info) I do agree that we have similar views on some of the problems and their solutions, and I know my bias against broad statements is asserting itself, but I think that you are pushing open source as a solution when it only gets us halfway there. Also, my comments on information hiding weren't meant to ignore your comments on thread monitoring, only to insist that information hiding is only a solution for a narrow subset of the problem space. Threat monitoring scales far better with application scope and threat models. (Even in the real world.) Point (d) is interesting. r/e peer review, I've worked at and with companies that took both extremes of peer review - some companies view it as important, others a rubber stamp political process. In a commercial environment that must protect its IP to survive, peer review may be the only acceptable option using internal resources. People like myself have been hired to review alledgedly secure systems, and if the consultant actually knows what the heck their doing, then it can work. OTOH, most of my clients didn't want to hear the truth - I won't miss that sideline... :) I also must disagree that open source alone can "force designers to use provably secure methods" - I've seen bad designers in commercial and open source systems, and often open source teams are pressed to get systems up and running quickly (lest another team finish that segment first). I've seen bad design principles here in as many varied ways. I would argue that the greatest strength of Open Source r/e security is in its ability to (a) expose security problems before they are exploited, and (b) allow those problems to be corrected by anyone with the skillset, without waiting for the original developers to get around to it. I would additionally stipulate that the skillset involved in designing {foo} software does not necessarily also mean those designers have the skillset needed to do a very good job in making it secure. Most of my peers consider security to be that "boring", "tedious", "annoying" thing that forces them to memorize "stupid" passwords. Open source design paradigms may help bring security experts and software designers together, but I think the general statement "only open source can force designers to use provably secure methods" is wrong because so few programmers even know what "provably secure methods" are. In fact, I could argue that there are very few "provably secure methods", if any. There are some cryptographic methods with expired patents that may provide tools, but few programmers know how to use them properly. Even smart software tamper detection can be defeated with various trivial attacks. I know that most of my peers in security agree with the assertion that any software calling itself secure should receive the scope of review possible with open source. I think that my problem, as some others who read your essay, was the implied assertion that using the open source process will make your software secure. Unless the initial open source team includes a real security expert, it probably wont be. And judging from the posts on BugTraq, it rarely is. Why not fix it? (Score:1) by archmedes5 (archmedes5@hotmail.com) on Monday December 27, @02:29PM EST (#181) (User Info) I'm sorry if I sound näive, but if it's such a problem, why not rewrite the source for the server and the client in order to eliminate the possibility of this problem occuring, then posting the binary for both win32 and linux clients, and eliminate the possibility of older clients from connecting. If it's open source it can be changed and fixed. "You can't take away peoples right to be assholes", Simon Phoenix in Demolition Man. Let's do this the way Doom is done... (Score:1) by talonyx (mikes@carney.vancouver.bc.ca) on Monday December 27, @02:33PM EST (#187) (User Info) http://talonyx.cjb.net/ Doom got opensourced (and more recently, GPL'd). Instead of a freeforall of people grabbing copies of Doom-source and editing them so they could cheat, groups formed (like DosDoom, Doom Legacy, and TeamTNT [who existed before the release of the source]) and they made their own "source ports". Each port offers it's own features, and most are compatible with the others over a LAN (with IPX or TCP/IP) or over the Internet usng a program called DoomServ. I'm not sure about the security of it, but there hasn't been anything posted about the source ports letting people cheat... Why? Well, it becuase people who play the game simply download the latest version of their favourite port and play it. If they don't like it, they go get another port. And if they want to develop Doom further, they either join a source-port project that exists already, or use, one as a code base. If their port lets them cheat, it won't get hosted on the large Doom sites (like Doomworld). Sure, people can still find and use cheatable versions, and make DoomServ clients for it, but why go to that much work so that you can beat people at a game? People who you don't even know? And especially, people who will notcie within the first 5 minutes of gameplay that you aren't getting hurt by their rockets and you can fly. Conclusion: People should start "source port" (please come up with a better name) projects, and define strict sets of rules for your projects. Client side cheating will Always be possible simply becuase of the way the game works. But if people simply download an open-source client and use it, without modifying it, we should be fine. I think I've said just about everything. Note: most, if not all, of these "source ports" are open-source and probably GPL'd. Lots of them have Linux versions, too. Go get some! Doom is a great game... and you haven't played it till you've played DoomGL with the Eternal Doom levels (get them at TeamTNT). "Justice pleases me always." (Che Guavara) proposal (Score:1) by pavel on Monday December 27, @02:38PM EST (#189) (User Info) I think the first problem can be solved by encrypting non-visible data on the server site before sending it to the client. When it become visible server just can send a key to the client. Second problem can be solved on the server site by allowing client to disapear for the couple of seconds or possibility to ask a server to produce a large number of triangles covering player. It will makes this auto-targering much more difficult to implement. Server can also produce more dynamic environment (moving walls, doors, elevators and so on...) plus do not give client enouth information about objects in the shadow preventing from possibility to distinguish monsters, human friends and human enemies. Security needs to be *designed* in. (Score:1) by cananian (cananian@alumni.princeton.edu) on Monday December 27, @02:47PM EST (#193) (User Info) http://lesser-magoo.lcs.mit.edu/ ESR is viewing life through increasingly narrow blinders these days. The real problem is *security design*. When you design a protocol, you must have in mind a particular threat model and some cost factors. When Quake was designed, single-player single-machine play was what was in mind. QuakeWorld hacked in network support, but security was obviously not a huge priority -- it's a *game* not a *bank*, for pete's sake -- so just enough protection was added to keep 99% of the script kiddies from cheating. Besides, there were some major performance constraints on the hardware; anything else would have been overkill given the threat model. *OBVIOUSLY* open source brings with it a different threat model, a stricter and tighter one. The quake situation just proves that it is *very difficult* to retrofit security into a design. The protocol must be designed from the get-go with your security goals in mind. (I will hand-wave at the 'Jabber' open source chat client as another example of a protocol that was designed without security in mind. 'Open source' has little to do with it.) The standard for e-commerce apps should be set much higher than that for a first-person shooter like quake, and I agree with ESR that "security through obscurity" should *never* be considered adequate when Real Money is on the line. But there are many ways other than full source disclosure to banish security through obscurity: open standards, for example, or publishing full details on wire protocols. I don't necessarily need to give out my implementation to promote confidence in my design, and indeed, if my design is truely secure, details of the protocol should be all that is required to convince me of the fact. [Note that in some cases -- for example, NIST's digital signature standard -- there are subtle protocol insecurities that might prompt me to take a look at the implementation to ensure that these gaps aren't exposed in practice; but in most cases protocol details are enough.] The bottom-line is: computing with insecure clients *is* possible, as are "dumb client" approaches which concentrate the security in the server. Perhaps neither of these are applicable to the tight performance constraints of networked gaming. That simply means that the client *must* be trusted in some way -- which means we need to integrate authentication capabilities and Web Of Trust stuff like, say, PGP has to implement that trust. This has very little to do with "Open Source", littler still to do with Free Software, and everything to do with practical security engineering. Bruce Schneier would be qualified to comment on the issues. ESR is not. Okay... So Tell Me This... (Score:0) by zonker (bobjones@spamkillsgaywhalesforjesusmy-dejanews.com) on Monday December 27, @02:54PM EST (#196) (User Info) http://members.xoom.com/zonk3r Okay, so tell me how you go about making any sort of money on a game that is written solely Open Source? ESR talks about how you design from the start Open Source, but if you do that, then all your neato engine stuffs are out in the open, able to be studied and stolen bye your competitors. The gaming industry is fueled by companies with people like Carmack, people that can code a fast pixel pushing 3D engine that oozes realism. If you give away your goods to everyone from the start, and people study your code, your competitors are going to be able to catch up that much faster to you. If I were designing a game and I had some bright ideas to make the engine faster, or do some amazing things never seen before, I surely wouldn't give out the goods until I've gotten some recognition for it, and made $money$ on it. I guess the money making argument is similar to Microsoft Open Sourcing their code and then feeling they are unable to sell their product because too many people would 'pirate' their software. I dunno, what do you think? I also don't like the tone ESR takes on id, scolding him for releasing the game as it is, and chastising him for the design decisions he made. He did what needed to be done, and may have made compromises for performance. That is how game engine creators squeeze more fps and features out of a computer, by making compromises. It is design and use of the compromise that makes engine designers the game gods they are. I'm sure if Carmack were designing firewalls his compromises would have been different. id released the source in good faith to the Open Source community because they have made their money and gotten the recognition they desired. They have given us the source code to a great game as a gift. Be thankful, instead of a jerk... / k.d / earth trickle / Monkeys vs. Robots Films / *rm spamkillsgaywhalesforjesus to email me* Re:Okay... So Tell Me This... (Score:0) by Anonymous Coward on Monday December 27, @06:54PM EST (#269) Zonker, It's the old "you're to blame, I'll take no responsibility for Open Source" trick that ESR is playing here. He knows that open source encourages cheating, particularly, games cheating. So he concocts some rubbish of an explanation and then decides, OK, now I'll reverse the flow and blame Carmack. Most of us, can see through this nonsense. Carmack is right to close the source, and if he and id have any sense, they will. There really is no such thing as fair competition under open source, you just have a lot of copying what others who are innovative and creative have done. What's really going on here. 'Cheating' (whatever) (Score:1) by Coleco on Monday December 27, @03:05PM EST (#201) (User Info) I think what we have here is a case of people bitching about cheating. In contrast to actual cheating, which I doubt in the case of the release of the quake 1 code is really widespread problem. Cheating is a lot less of problem than people think. Yes, aimbots exist. Yes, hacks of various sorts exist for quakeworld. However, there also exists people with seemingly inhuman skill. Open forum, in depth bitch-fests about the 'problem' of cheating based on unsubstantiated fluff really just creates more problems then it solves. This is because it creates fodder for accusations and finger pointing when someone feels that the only way said player can beat them is by cheating. Some people have this mentality that one can not reach a certain skill level without using cheats of various sorts. Anyone who was any good at quake has run into situations of being accused of cheating at various times. What happens is that as soon as someone discovers that people can cheat the first thought that enters their mind when they are getting beaten is "that person is cheating". 'People cheat' is just a lame excuse. I remember one occasion of being accused of somehow 'cheating' in quake 3. My lightning gun was 'too good'. Basically what that comes down to is ego motivated whining and pouting. I've come across a number of hacks and bots for quakeworld and for the most part, the map and model hacks don't help a whole lot, and someone using a bot is pretty obvious. There is always resorting to specing someone you think is cheating or asking them for a demo, etc... And this is really moot anyway because everyone should understand that very few people cheat and chances are that if some guy is ass kicking your ass, he's just kicking your ass. Some of us have been playing FPSs for a long time and derive some sort of satisfaction from actually being good, without any help at all. And considering that really the only reward to playing is self satisfaction I don't think cheating will ever be a huge problem. I can think of one very amusing occasion where a fairly well know player was being beaten badly by someone who was using a bot. But that person was using the bot for the comic value and it _was_ very funny. Other then that bots get boring pretty darn quick. I mean running around pressing a button while the computer aims for you isn't exactly fun, and it only help for some weapons anyway. In any case, if the middle echelons of mediocre quakers think that everyone who is good must cheat then the danger is that those people will start cheating under the premise that they believe that they are leveling the playing field. So really what all you people should do stop your lame hypothetical speculation on how it may be possible to cheat when having no proof of particular individuals cheating at all. Slashdotters thinking like PHBs (Score:2, Insightful) by JabberWokky on Monday December 27, @03:14PM EST (#203) (User Info) http://www.timewarp.org After reading though the replies, it seems to me that most people are thinking like those really annoying bosses who assume anything can be done with the resources at hand. Assuming you work (or worked) in IT, you've probably gotten a bogus request from sombody who means well, but dosen't understand current capabilities. They want to print metal foil with their inkjet printer, but they don't want to buy a new printer, or they want you to make it so that somebody can read a database but not write to it, when it's a flat file format accessed with a closed source client.... and do it now, before they get back from lunch. Both of these can be addressed given enough money (in the first case) or time (in the second case), but a condition of doing each is that you don't have the time or money. I'm not familiar with Quake code beyond what appeared in this forum, but it seems that the problem could easily be solved just by requiring each player to be on a LAN or have a T1 minimum. Simple solution, eh?... But it won't work - because I don't think *anyone* is willing to pay for a T1 just so they can play Quake. So you have to adjust the paramaters... but Quake can't be coded to be a fun, responsive game without enough low-latency bandwidth. PHB says: "I don't care. Make it work over a 33.6 modem connection with security". Smart coder says: "You can have server-side security, or make it work over a 33.6 modem, but not both". Guru coder states the solution: "I can make it fun for 33.6 users, and make it step up to a secure connection for people with less than 120ms ping times. Ask Carl in the art department for two little icon that tell the user if they are running a cheat-proof game or not, and tell Emily in docs that she's going to have to figure out how to explain this 'feature' to the users". The problem is there if it is open source or not (although the solution is easier to find if you have 13,000 people thinking about it)... the problem is in the specs and assumptions. -- Evan Looking for solution: open generated closed code (Score:1) by magi (magi@removethis.iki.fi) on Monday December 27, @03:36PM EST (#212) (User Info) http://www.iki.fi/magi/ I'm not sure if this is really a good solution, but... The client needs to have a checksum checker or something, right? And the client can't be given the opportunity to checksum itself, but it must be done by a closed-source binary code, right? Ok... Solution: the server generates the executable that checks the client, encrypts it, and sends it to the client. The checker decrypts itself, checks the client, and sends a secured message back to the server. This could happen in perhaps one to ten seconds, so the client isn't really able to fuss much with the checker. And the checker's source would be open. This is just a quick thought, so I'm not really sure if this would work or be secure. But perhaps it could be a starting point for a solution. The idea is that, if "closed source" is evil, why let evil people code it? Why not make a code-generator (for example with encryption) that is open-source, but generates closed-source code. But, this solution of course brings another security problem: the "checker" could be a troyan. Thus, it has to run in a virtual machine. I'm not sure what kind of code this "Quake C" generates, but if it's opcode runnable in a VM, then the checker could be safe in that way. (Another solution to the troyan might be using trusted Quake signature servers. Safe as long as the trusted servers really are safe...) But, perhaps the client could have a hacked VM and let the checker see wrong code segment, and actually run on another. This gets very complicated now, and I'm not any longer at all sure if this can be solved. *shrug* Or perhaps the checker could run all the time. Perhaps it could copy the client into a data segment, and require it to run from there, and make some modifications to it. Perhaps it could fulfill some crucial function in the communication that can't be circumvented (such as encryption). Or download the entire client... OR SOMETHING! How about a closed compiler? (Score:1) by cr0sh on Tuesday December 28, @11:09AM EST (#340) (User Info) What if, after downloading the source, the user had to snail mail for the compiler? This compiler would only be a binary only distribution, and the information obtained from the address/name would be used as a way of creating a checksum that would be added to the compiler, so that every time the compiler was used to compile Quake (or any other source), the checksum would be added into the Quake executable. Quake could still be compiled by non-signing compilers (like gcc), but only the signed versions of the Quake client would be allowed to participate on the servers. Those caught cheating would be banned (via the signature). The only way to get another signature would be to supply a different address to get another executable of the compiler (base the signature just off the address, name, city, state (don't use apartment number, or zip) so that the user would have to move or have cooperation of his neighbors to get a new compiler). I don't think this would eliminate the problem, but it might help (there would maybe have to be a way for the users to authenticate the servers as well - maybe via a similar mechanism?)... Cr0sh the F0ckers! Digitally signed binaries (Score:1) by philg (phil_groce@cmcsmart.com) on Monday December 27, @03:37PM EST (#214) (User Info) Why not use binary builds of the executable files digitally signed by the builders, and have the servers check the signatures against a trusted certifying authority? Someone suggested this in the first article, and it still seems like a sensible solution. You can muck around in the source code all you want, even enhance it -- but when it comes time to play, the server enforces a standard set of binaries to play on. If someone comes up with a serious gee-whiz enhancement, s/he releases the source, but also a binary patch to a "reputable" build. Hopefully, s/he also sends the patch (as source) to the project issuing the build, so it can be rolled into their project. There are a few technical issues left open -- building a binary from which to divine a patch seems challenging, for instance. But pirates and trainer-builders have been doing this sort of thing for years. Opening the source doesn't mean everyone gcc's their own copy of the game. Use this encryption thing we talk about so often on here, and only play using trusted binaries. It should solve things to everyone's satisfaction. phil Re:Digitally signed binaries (Score:2) by Jamie Zawinski (jwz@jwz.org) on Monday December 27, @05:17PM EST (#252) (User Info) http://www.jwz.org/ Why not use binary builds of the executable files digitally signed by the builders, and have the servers check the signatures against a trusted certifying authority? Because signing binaries doesn't work. (Not for this problem.) How does the server know what the signature of the client-side binary is? Because the client told it. Carmack's suggestion of using a loader to checksum the binaries, rather than having them checksum themselves, also doesn't work: that just adds another level of indirection and changes the problem from "hack the client" to "hack the loader." This stuff is easy. People have been cracking harder copy-protection than this for years. And in fully closed-source environments. Like I said yesterday, When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender. To oversimplify: you can know who I am, but you can't know that I'm telling you the truth. Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using. This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption. Ranked play? (Score:1) by kenro on Monday December 27, @03:46PM EST (#216) (User Info) Wouldn't ranked play (aprox. equally matched opponents) solve the problem? You'd need a centralized server to hold rankings for each CD-key. If someone cheats they get bumped up to a higher rank until they no longer have an advantage. The very top rank might be called Bot Hell. :) The only way for a cheater to reset their rank is to buy another copy of the game (which helps other players a little by funding the next version). This can't be solved with technology alone... (Score:1) by tietokone-olmi (at-my-home-page-dummy) on Monday December 27, @03:58PM EST (#225) (User Info) http://www.pp.htv.fi/~ksandstr/ Did you really expect to just plonk a dedicated quake server on your computer and have it automatically prevent cheating and other nasty stuff? What this situation really needs are, like in the MUD world, active server deities or wizards. When a confirmed cheater is found, normal players just rat about him/her to the wizard, maybe vote to temporarily ban him, and the wizard can banish people permanently if that is really needed. Possibly add a mandatory registration with the server to be able to play, which will probably cut down on the amount of cheaters by itself. Of course, the cheaters could just re-register after having their score table zeroed out or removed altogether, but that kind of thing can be reduced by setting a "waiting period" before the registration becomes effective, for certain IP ranges. How patient is the average power-hungry script kiddie? Probably less patient than the server owner, who can keep increasing the waiting period until the kiddie in question loses interest. If nothing else, this will at least let the honest players keep slaughtering each other until the kiddy returns. If you ask me, the problem of power-hungry script kiddies can't be solved effectively with technology alone. More power to the $DEITIES, on the other hand... No .sig to see here. Move along, citizen. This is a question of community more than security (Score:1) by Deven (deven@ties.org) on Monday December 27, @04:04PM EST (#227) (User Info) http://www.ties.org/deven/ Especially when it comes to aim-bots, it's difficult to guarantee that a player isn't cheating. Statistical analysis might be useful for finding suspicious patterns, but any detection can be spoofed, and truly skilled players might look like aim-bots. (However, a real player might have more realistic hit accuracy and standard deviations -- if the accuracy is too consistent, this may be suspicious.) The real solution, of course, is community. If honest players refuse to play with cheaters, then the cheaters can't ruin the game. Authentication of players would be necessary, and a community could have procedures to eject cheaters when identified. Calculated statistics from the server could help to identify suspects, and leave it to the community to ascertain whether the suspect is a cheater or a highly-skilled player. Chances are that highly-skilled players won't be easily ejected as cheaters, and there's always the possibility of such a player proving his/her skill by playing in the physical presence of a trusted community member using a trusted client... Deven "Simple things should be simple, and complex things should be possible." Statistical analysis of cheats and CRYPTONOMICON (Score:1) by NZheretic on Tuesday December 28, @11:44AM EST (#341) (User Info) Author Neal Stevenson perfectly described this situation in his novel CRYPTONOMICON about WWII enigma Ultra Magic intelligentence cheats. quoted but uncapped "no action is to be taken on infomation herein reported , regardless of temporary advantage, if suh action might have the effect of reveling the existance of the source to the enemy" "If the Nips keep getting ambushed -- if they keep finding their own ambushes spoiled -- if their merchant ships happen to cross paths with American subs more often than pure probablitity would suggest -- how long until they figure it out?" (Without the allies cheating would they have lost WWII ? ) Stop Playing Games! (Score:0) by Anonymous Coward on Monday December 27, @04:25PM EST (#233) This is the only solution. As long as people keep playing games with the source code, they'll be cheating and abuse. Everyone knows that computers games cause violent impulsive and irrational behavior. And, now we're seeing how open source promotes dishonest behavior. This concerns me. Why can't people stop playing games, and start playing the games honestly. I know... (Score:1) by Enahs (bigdork@NOSPAM.siu.edu) on Monday December 27, @04:38PM EST (#240) (User Info) http://come.to/cuthulu Make Q1 non-free again, just like the GNUstep icons. Wha...a GNU project non-free? Nah.... -------------------------------------------- Everyone is entitled to my opinion. Irrelevant (Score:1, Interesting) by Anonymous Coward on Monday December 27, @05:08PM EST (#247) Yet more irrelevant bilge gushes forth from the mouth of the self-appointed prophet of the Church of Opensourceology. Nobody cares about the blindingly obvious implications of the Quake problem in the world of e-commerce -- no similar problems exist in that area. The issue is cheating in Quake, and ESR, despite all his words, has spectacularly failed to address that. The conclusion stands: a closed source program is the only useful countermeasure. ESR states 'If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered'. Roughly translated, this says 'If Quake had been designed to be open-source from the beginning, it would have been unplayable over the Internet for the majority of users'. Great - a triumph for OSS, then. What a talented advocate Mr Raymond is. If Eric Raymond had ever written anything more challenging than a mail forwarding utility, maybe he'd have something worthwhile to say about this issue. Of course he hasn't, but having little of value to say hasn't stopped him holding forth in the past, so why would he stop now? When your life is devoted to spouting dogmatic drivel about programming, rather than actually doing any real programming, can you really be expected to know what you're talking about? Player Responsibility (Score:1) by evil_deceiver (mcoffeyatjusticedotloyoladotedu) on Monday December 27, @05:11PM EST (#248) (User Info) http://justice.loyola.edu/~mcoffey/ >> (Any computer game at which computers are better than most humans has analogous cheats, some of which aren't even detectable in principle. Carmack observes "correspondence chess has been subverted from its original intent by players using computers." This isn't something security design can fix.) << This comment touches on what's really the most important thing to think about in playing games online or off, which is, do you trust your opponents? People cheat at Quake and at correspondence chess the same way they cheat at poker. Coding an aim bot is no different than hiding an ace up your sleeve, and when you play against dishonest opponents, you should expect either. The ultimate solution is not to try to force players not to cheat, but simply for honest players not to play against cheaters. Then the cheaters can play against the other cheaters, and see how they like it. ++++++++++[>++++++++++<-]>+ .<++++[>++++<-]>+.<+++ +[>---<-]>-.+++.[-]++++++++++. Am I nuts? or could it be this easy? (Score:2, Insightful) by Anonymous Coward on Monday December 27, @05:11PM EST (#249) Here's my go at a solution that leaves everything open-source: The basic premise is that the server would compile (and download) a unique "client binary" for each user that wishses to play (as they join)...that client would be signed and incorporate semi-random events like: "send me the magic number after every 4th frag" and the client would be time-limited (would expire/not be serviced by the server at the end of every map, etc) Yes, it's not completely secure, but assuming you have enough bandwidth and CPU power to compile and download such clients, it would make hacking such clients pointless. It seems to me the nature & quickness of a game of Quake and an online e-transaction represent the same kind of thing.....by forcing the hostile client to download a new "client executable" every time they want to play/pay and embedding checks within it along with tight time limitations, you can pretty much solve the problem and leave the baseline code open source....yes, the server ops will have their "secret code" they never disclose....and this leads to the question of trusting the server ops.... Which can be solved by taking the model one level up....the server ops create their server source with their own flavor of client security and then they submit them to a trusted organization (id software). Id inspects the code (to be sure there are no server-side cheats built-in) and then their system compiles the server code (with a similar kind of signing/magic number checks like the client code) and ships it to the server ops just like the server ships clients to the users....with embedded checks and time-limitations. At that point, you could log onto id's site and view the "server list" and see which servers are currently authenticated. People could still run "unauthenticated" servers but you would be taking your chances if you played on them. Doesn't this seem workable? (well, maybe in a few years when bandwidth is a bit wider for everyone, but, hey, it's viable under the right conditions isn't it?) The point being that the "client" changes after every map/transaction and by the time you hack the client, the game/transaction is over/voided making the hacking effort moot. Yes, server ops would have to change their client "security" often so that people couldn't analyze previously downloaded clients and build cracks for them, but with sufficient randomness built into the client binaries, I think you could nearly eliminate the cheating problem...and leave everything open source. Security through obscurity *does* work (Score:2) by Ian Bicking (bickiia@earlham.edu) on Monday December 27, @06:38PM EST (#267) (User Info) http://www.cs.earlham.edu/~bickiia At least if you don't ask too much of it. As we all know, nearly all encryption works with hard algorithms -- something that takes a prohibitively long time to break. But people somehow think that "prohibitively" must mean a thousand years or something. I think this is because people become too narrowly focused on certain kinds of security. Quake doesn't matter that much. Cheating on Quake won't make anyone rich, and the feeling of power you might get is pretty pathetic really. All the security in Quake has to stand up to is a few years of not very hard attempts to break it. That is, in a few years Quake won't be so exciting and people won't care too much, and until then cracking Quake can only be a hobby anyway. Foreign operatives and the NSA couldn't give a damn. In this situation security through obscurity is enough. And it has worked fairly well up to now -- not perfectly, but well enough. It might not have been as hard to disassemble Quake or make a proxie as it would be to break a key, but it has been hard enough. ESR is being dumb when he says that client caching is bad. He's being a total blockhead. Quake isn't an eCommerce application. It's a game. Speed and quality of play are the most important aspects, not security. And when the two conflicted, quality of play won -- as it should have. Re:Security through obscurity *does* work (Score:2) by slim (slim@ladle.demon.co.uk) on Wednesday December 29, @08:27AM EST (#350) (User Info) http://www.ladle.demon.co.uk I didn't get the impression that ESR was criticising the Quake implementation. No -- what he was doing was responding to those who would claim "look, freeing Quake made it easier to hack -- therefore free SSL implementations (or whatever) must be easier to hack than the proprietary equivalent". That's a point that needed refuting, and ESR had a fair crack at doing so. -- Beware the Mem e Virus Open source ideal from this point of view? No. (Score:2) by khaladan (khaladan@netscape.net) on Monday December 27, @06:58PM EST (#270) (User Info) Unfortunately open source games are not ideal from a gamer's point of view. The arguments of open source possibly improving quality and decreasing development time do not hold up against how easier it becomes to cheat -- and that's what gamers care more about, when it comes to multiplayer. Seeing an opponent around the corner through cheating indeed could be eliminated, with a performance hit. This would have (probably) been done if the game had its sources available from the beginning, but... Other cheats would not be detectable. The idea of detecting auto-aimers is truly ludicrous. With all the variable lag added in, the uncertainty grows to unacceptable levels. There is not a way to 100% be sure that a person is cheating via auto-aiming. I believe that it would be incorrect 75% of the time, with good players it would be incorrect all of the time. The idea shouldn't even be argued over -- simply not feasible. If a method of attempting to detect autoaimers was developed then the auto-aiming cheaters would simply add in a few more milliseconds before they targeted the enemy. This wouldn't be detectable at all, certainly not with the variable lag added in, and cheaters could go even farther by adding variable times before targeting the enemy. Simply not possible to detect this. Other undetectable cheats will be developed, dodging bullets by moving and/or jumping, automatically walking to pick up needed items, others that I can't think of. Possibly undetectable bots will be created if interest holds long enough. The basic fact is that source available or not, cheating exists, distrust exists between players. With source available, that cheating and mistrust escalates, regardless if the protocol relentlessly follows a fake vision of security. Open source is not the solution to everything. Also, shame on you ESR for describing the Quake 1 source release as a lump of coal. How much experience do you have playing Quake, or more importantly writing networked games? Or anything for that matter -- show me the code. Your recent writings are not helpful. Go hack on Quake 1 yourself and show us what you mean -- through action. khaladan Lumps of coal (Score:2) by slim (slim@ladle.demon.co.uk) on Wednesday December 29, @08:24AM EST (#349) (User Info) http://www.ladle.demon.co.uk "Also, shame on you ESR for describing the Quake 1 source release as a lump of coal." I don't think you've understood Eric's turn of phrase. In parts of Western culture (Scottish? Not sure.. I'm a Welshman, so we have different traditions) there is a tradition of bringing a lump of coal through the front door on New Year's Day -- it's supposed to bring good luck for the year ahead. Eric is describing the Quake source as a welcome gift. I'm sure he'd be the first to welcome something which simulates an arsenal of high-powered weapons... He'll be eagerly awaiting "Defend your homestead against the commies" when it's released :) -- Beware the Mem e Virus Why not Armbots? (Score:1) by pdp8 on Monday December 27, @06:58PM EST (#271) (User Info) Disclaimer : I am not good enough to play quake on the net, so I don't really have any idea what I am talking about Something I have wanted to play with for a long time is systems that get the most of human-computer partnerships (see deep blue). One way to explore this area would be to encourage people to build things like armbots into their Quake clients. After all why do you want to get good at something that the computer will always be better at? Humans should do what they are good, and computers should do what they are good at - the trick is building the system so the computer and the human can work together. If the computer can aim better than I great, let see what the game is like if everyone is using armbots. What strategies are effective now? Are some armbots more effective than others? What are other good forms of computer enhancement? Send in the cyborgs! Sure it won't be Quake any more, but that does not mean it will necessarily be any less interesting (does’t mean it won’t be less ether….) This post and $3.00 will get you a cup of coffee. Quake cheating - nothing new (Score:1) by turnstep on Monday December 27, @07:30PM EST (#278) (User Info) http://www.turnstep.com As the essay points out, there are many ways to cheat at Quake - open source just makes them easier to do, in some ways. My favorite trick is copying some of the object's over each other, such as replacing the "invisible" eyeballs with a Shambler. Since the eyes have no animation to them like a Shambleer does, an invisible player appears as a very strange moving Shambler. :) There are lots of others. I don't use them when playing other people; I have more fun designing levels anyway. I have a problem with this essay (Score:2) by Capt Dan (BobDean150@excite.com) on Monday December 27, @07:31PM EST (#279) (User Info) http://sourceforge.net/project/index.php?form_grp=846 I am actually a little bit insulted that the Quake release was used as an excuse for ESR to wave the "Open SOurce will eventually solve everything including world hunger" flag. (yes, I do participate in open source development regularly.) The concept that the quake cheats would not have occured if the development had been open source is an interesting one: If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers. BUT. The problem here is not the developers Nor is it aimbots. It's because of bots that we have Quake III Arena today. The issue is that people abused the source code for completely selfish reasons. These people were not developers of the software. Making the project open source from the begining will not change the behavior of cheaters. If quake had been designed to run securely on T1 lines and handle transaction rollbacks I could see spending the time to write a 4-5 page article explaining why it's security model has issues. But Quake is an old game A game designed to run on Pentium 90's and 14.4 modems. It's like having a doctoral disertaion panel to grade a sophmore's CS project. (just talkin' about the security model here, not the entire game). This is more of an "Oops. Sorry. We'll fix it next time" deal. i'll stop now before I manage to get myself in a big time flame war, cause man am I upset right now. "You want to kiss the sky? Better learn how to kneel." - U2 "It was like trying to herd cats..." - Robert A. Heinlein "Quack?" - a duck The sky isn't falling! (Score:1) by pingbak on Monday December 27, @07:54PM EST (#283) (User Info) http://www.cs.ucla.edu/~scottm/ Look, guys, the solution is pretty obvious, and no, the sky isn't falling on open source. In a rational economy, all participants work towards their own self interest. That's why a small level of cheating is tolerated but egregious acts of cheating eventually get wiped out (unless you're La Cosa Nostra, but that's another story.) Who in their right mind would want to play against a known cheater if they've been outed? It's something that old command-line news readers have: A kill file. It doesn't take long to discover an aim-bot. If I have a kill file, I can choose to (a) ignore the cheater, (b) refuse to connect to the server that lets him play. The main requirement is that each Quaker player identify himself/herself. Names can be faked and new aliases crafted -- but once outed, again, it's into the kill file. Alternatively, Quake could generate a signature for itself that it exchanges with the server. Again, this could be damaged and faked, but make the effort sufficiently high to do this, and one takes the incentive out of it. Even better is the QBL (Quake Black Hole) [My appologies to Paul Vixie.] This requires a mod to the server and the server d/l's a list of persona non grata periodically. Your name or signature in the QBL? Tough! It seems to work pretty well to combat e-mail spam... I know, this requires infrastructure, but what solutions to problems doesn't? -scooter A New Form of Quake (Score:1) by kaniff (saberswin@prophetnetworks.net) on Monday December 27, @08:04PM EST (#285) (User Info) considering all these problems with security and bandwidth, giving and taking between honesty and playability. I have a suggestion to id for how to design Quake 4. Make it turn based. :) Like a roleplaying game. With dice rolls and everything! I'm sure all the dice rolls could be server side without lag. Something to chew on. kaniff. Zen Master of the Air Guitar. You can't fix the cheating problems. Here's why. (Score:1) by Ricardo Casals on Monday December 27, @08:47PM EST (#290) (User Info) You just can't. Even if your server has a detailed client checker that checks the Quake I executable from top to bottom with checksums or whatever. Why? First of all this removes performance (Hello, ESR? We NEED this with 28.8 and 56k modems man!). Second and foremost, nobody would be able to play with a client that has been modified for the purposes of making the game easyer or cooler for the player (and not to cheat. Next is the fact that even if there is a server that checks the checksums of the Quake client, hello?! A good programmer would still just minimize their "fake" Quake client they used for recognition and load their real client which will let them cheat on top of the existin fake client. GRR! ;o) yeah ... i'm going to have to go ahead and not put a .sig here, alright? ... yeah ... This is about people and policy, not code (Score:1) by Stinking Pig on Monday December 27, @09:03PM EST (#291) (User Info) http://home.pacbell.net/ljcoates Stopping people from cheating is like stopping people from looking at pr0n, downloading warez, or win-nuking their neighbors while at work. You might be able to stop this week's attack or misuse of choice, but you won't be able to stop next week's until well after your first detection of it, which will be well after it first happens. As the person trying to prevent this from happening, you're in a Catch-22 which resembles Heisenberg's Uncertainty Principle: The harder you try to detect misuse, the more detection countermeasures will be used. In other words, if you treat your community (users, gamers, &c) like children, they'll act like children. Children with patience and a hefty knowledge of computing and the Internet, if you're unlucky. I think opensourcing of old games is fantastic, and companies like id should (please!) keep doing it. Take no measures to prevent cheating, and the community will take its own measures. These measures may be technological, such as writing code to detect the use of cheats and disconnect the cheater. But the effective and final measures will be social, and as old as gaming -- I won't play with you if you're going to cheat. SP -- Pushy punk pork prole Quake vrs Real Life (Score:1) by MikeFM (root@orgyblood.net) on Monday December 27, @09:20PM EST (#292) (User Info) IMO all this has done is made Quake more like real life. Now the end user has the ability to invent new smart weapons. Now it can get really interesting. Myself I'm thinking of a game where there are tons of bots mixed in with the players and they are hooked to neural nets and can communicate to each other in teams to plan attacks. It could be quite awesome. As an AI programmer I love bots. Naivete at it's finest. (Score:0) by Anonymous Coward on Monday December 27, @10:30PM EST (#295) ...If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning... What naivete! Security is an illusion (Score:2, Insightful) by gregm on Monday December 27, @11:37PM EST (#300) (User Info) Computer security is just like a contract, a door lock, or a security system... all can be beaten if there's enough determination and/or money and/or time. Most of us lock our homes with a pidly little pot-metal thing that does what exactly? The alternative is to put in an expensive security systems that can, of course, be beaten as well. The hassle of paying for that fancy security system, swiping my card/whatever, etc. isn't worth it to me. If I want to play a net game with you I'm going to have to trust you a bit. If I'm going to enter into a contract with you then I'm also going to have to trust you a bit. If I invite you into my home to see my stuff then I'm also going to have to trust you a bit. (sounds like security through obscurity huh :) The task of creating a reasonably secure environment to play Q1 using 33.6 modems isn't worth the effort if it's even possible IMHO. If Q1 had been constructed by OS from the ground up more time would have been spent patching it than playing it as a new hack would've come out weekly. The "final" OS product may have been more secure and robust than the current Q1 version but it would have been much more painful for the players along the way. Obscurity doesn't work but it does slow things down a bit. the Quake 1 players had a couple of good hack-free years playing Q1 because ID didn't make it too easy. ID opened Q1 up and all the hacks that were held back by obscurity flooded in. Just my 2 cents Grow up! (Score:1) by EEEthan (emh26@columbia.edu) on Monday December 27, @11:41PM EST (#301) (User Info) Ok, a couple of things: 1) People have had the ability to cheat long before the code was opened. It seems that a bunch of people just renewed their interest in cheating because they had access to the code...some coders had a field day. That's not such a bad thing. The knowledge of how to make code that cheats in quake is actually a good thing: people will see it, and people will learn how to fight it. It's an evolution. And another thing: even though people COULD cheat, a surprisingly low number fo people do. It's actually not as fun. I know...I have rcon passwords on some servers, and I can do what I want. I can kick people so I can win the map, or whatever...sometimes I do. But it just isn't as good as when I actually DO kick everyone's ass. Cheating leaves me with a bad taste in my mouth. Quake isn't about winning: it's about being in real competition with people who love the game as much as you do. I just don't see the cheaters being a long-term problem. When I play quake1, I'm going to be playing with people who don't cheat. 2)I think this problem is endemic AND important. Even if performance isn't critical for many applications now, it will be. Things will be 3d, and at some point, milliseconds will matter for almost every application. It's going to be very important that applications can communicate securely and quickly...clients are going to have to do as much work as possible, without creating security problems. Perhaps the situation isn't as simple as a 'lump of coal,' or a gift...perhaps this has showed the community a complex situation which was inevitable. I think that this problem is part of Open Source's growing up...if gaming will ever go OS, this problem must be solved. The community has to prove that it can own+maintain valuable software, like Quake's source code. It's going to become a situation which occurs more and more frequently...and people are going to want to know that they can open their code and have a reasonable solution to keep everything secure. This is an important evolutionary step. I think that the ID model is a great example: they release the code of their games, because others can maintain code better than they might while working on new projects. This might be a very good default model for other types of software as well...but only if the community can come up with reasonable and effective solutions. And I suggest that a big part of this will not be in the code...it will be in the way people treat it. Cheating is a kind of electronic crime...and it may come to be that it's as easy as it it to commit a crime in the real world. People are going to have to learn to act responsibly online as well. It's an important part of the growing-up process. The integration of online realities into mainstream culture will not be completely painless...there will be lawlessness, and many problems. But it will be worthwhile. We should just appreciate that we live in the wild west era of the internet...Quake is the game that lets us be Billy the Kid. It's all about being faster and better than your opponent...people will do a lot for this. Including cheat...but cheaters don't get respect. There may be some ways to cheat, almost undetectably, and have just enough of an edge to win, without having people notice. But that's a skill just like any other. I would imagine there will be some people who do that, and do it well, the real Billy the Kid's out there...it's all part of a universe that's expanding and becoming more complex. And we're just going to have to deal with it, one day, frag, and line of code at at time. FWIW (Score:2) by GFD on Tuesday December 28, @12:28AM EST (#303) (User Info) The solution to this problem as it stands is to expect cheating by clients and try and detect it. There are two approaches to doing this. Firstly, the server would create 'signiture' types of situations that would be normally very hard to get a hit under normal situations. A person would be allowed (say) to be lucky once but get bounced if he got too lucky. Secondly, the server could look for players that are just too good. Yes a hacked client could get smart and introduce errors to mask aimboting, etc. but that would be fine. Enough errors and a person is back to relatively normal skill levels. Probably a combination of the two would be good enough. A person meeting certain statistical signatures would start to be passed bogus situations in combination with real ones to see how the client reacts. Gnubots (Score:0) by Anonymous Coward on Tuesday December 28, @12:39AM EST (#304) From a hacker point of view it is nice that people would be doing all this code just to get better and better clients... the thing is that sometime the clients will get so perfect that they won't need human interaction and then they will start to program bots, in a bot war, each one with more AI than the other... It is funny 42nd post! A Question of Speed (Score:1) by nsonneveld (sonneveld@hotmail.com) on Tuesday December 28, @02:37AM EST (#313) (User Info) Well sure, why not have all the calculations on the server side with a plain 3D renderer client? I'm sure that Quake could have been designed to include every single security precaution known to man. The problem is that it would be too slow to even bother and the graphics would be shoddy with people popping in and out of the game universe, so security through obfuscation is probably the best way to do it. I believe that ESR hasn't even played Quake once. If he had he would realise that Quake isn't some slow text-based game but a fast paced 3D game. Some security precautions can be implemented but the network performance shouldn't have to be sacrificed, at least not until everybody has thrown away their 56k modems. - Nick "the real lessons of the Quake cheats" (Score:1) by evil_deceiver (mcoffeyatjusticedotloyoladotedu) on Tuesday December 28, @03:50AM EST (#317) (User Info) http://justice.loyola.edu/~mcoffey/ >> To recap, the real lessons of the Quake cheats are (a) never trust a client program to be honest, . . . which is good advice whether your source is open or closed . . . >> (b) you can't have real security if you trade it away to get performance, . . . which is logically equivalent to saying "you can't have real security if you give up your real security". . . >> (c) real security comes not from obscurity but from minimum disclosure, . . . and minimum disclosure is itself a type of obscurity. The information that the server knows but refrains from disclosing to the client is what's obscure, and it may be hard to get that information, but not impossible. For example, the client might lie about where the player is, send projections of where the player could be to scout ahead, pretend not to have received packets while still showing the player the information contained therein . . . etc.; you get the idea. >> and most importantly (d) only open source can force designers to use provably secure methods. Agreed. ++++++++++[>++++++++++<-]>+ .<++++[>++++<-]>+.<+++ +[>---<-]>-.+++.[-]++++++++++. Are players willing to play with cheaters? (Score:0) by Anonymous Coward on Tuesday December 28, @04:45AM EST (#319) I remember as a kid playing the the family pet. My parents were right, if the pet didn't win at least once in a while it would stop playing. Does the same thing hold true for cheating in computer games? Are you willing to initiate a game with someone you don't trust who may be cheating? If you play against a cheater are you likely to play that person again? Obscurity vs. disclosure - just a sliding scale (Score:1) by tc on Tuesday December 28, @05:14AM EST (#321) (User Info) The fundamental measure of security is "how hard is this to break?", expressed in terms of how long it takes to compromise given X resources. The reason why we think security through obscurity is bad is because, by this metric, it takes very little time to break. With security through obscurity you're not up against the combinatorics of a secure key, but merely have the time taken to disassemble, reverse engineer, or otherwise unobscure the protocol. What's worse is that, unlike security residing in a key, once you've broken an obscured protocol once, you can usually use the same solution again and again for other instances of the same protocol. Security through obscurity therefore gives you some small fixed 'amount' of security, which is insufficient to repel a concerted attack, and is dwarfed by the security provided by a disclosed system where the security resides in some set of keys. However, the Quake problem presents us with a challenge. There doesn't appear to be a disclosed protocol which deals with the problem (at least, none has been suggested). In other words, the 'amount' of security provided by a disclosed solution in this case is zero. We then have to look at other options. Surveying the field, it looks like obscurity is the only proposed mechansim that provides a non-zero amount of security. We should feel uneasy about this, but that shouldn't prevent us from making the pragmatic decision. If you're writing a multiplayer game, and need security against cheating, you may have to rely on obscurity. To suggest otherwise, without proposing a disclosed solution which works in practice, is IMHO irrational zealotry. Idea (don't bother flaming me) (Score:1) by LordLobo (lordlobo@voyager.net) on Tuesday December 28, @07:54AM EST (#327) (User Info) Consider: The Q1/QW clients bins are about 470K a peice. Even Q3 weighs in at 870k. What if the 'client' downloaded the binary from the server, then removed it when you disconnect? You're probably wondering whats to stop someone from keeping binarys or trying to spoof the program into using your cheat bin instead of the legitimate one. Well, I'm not sure, but it's just and idea. ------------------------ LordLobo - Because I can I have the solution! (Score:1) by Sq (mnalis-sd@voyager.hr) on Tuesday December 28, @08:09AM EST (#328) (User Info) You put whole game in server, and make clients "dumb" X-terminals! Well, it will need some improvements on bandwidth in most cases, but after that, it is ideal solution! Why is it that software designers are too Leet? (Score:1) by Lumpy (spamsucks.timgray@lambdanet.com) on Tuesday December 28, @09:22AM EST (#336) (User Info) http://www.lambdanet.com Let's see.... nettrek has been open source from day 1 nettrek servers can run with the option of only accepting "blessed" clients. these pre-compiled client programs (binary only) have cut down the cheaters quite a bit... but nothing can stop a true hacker.. look at quake 2 and 3! I know for a fact that there are some out there hacked to do auto aiming and even just acting like a deathbot. Kudos for making quake 1 as open source. For-shames for those pissing and moaning about kiddies playing with their new toy. only a retarted kid will use a toy as intended, the rest of us mental cases try and plug the race car set directly into a car battery! ----- I can be bribed! But only with technology. ----- Closed Source may not be the answer (Score:0) by Anonymous Coward on Tuesday December 28, @09:24AM EST (#337) Anyone who has played the game Ultima Online can tell you that closed source is not the (total) solution to this problem. There exists a program called UO Extreme which adds features to the UO client. On several occasions Origin has attempted to defeat this cheat program by altering the client's encryption algorythm. On each occasion the encryption was cracked within days. Quake Robot wars. Quakemon - got to blat them all! (Score:1) by NZheretic on Tuesday December 28, @12:34PM EST (#343) (User Info) Give the script kiddies something new to put their talents too. Let them waste their time by fighting each other and make money from them at the same time. Get them to design/customise totally autonomous quakebots so they can upload the bot source to servers/gyms which is then compilied and run to battle other robots. Organise server providers into multilevel leagues pools with the top of the league possiblily becoming professional ( WWF of cyber space ? ) Make money by selling advertising space inserted into the enviroments of resulting battles that can be displayed on quake like clients Open source would not have helped (Score:1) by Kenneth L. Hamer on Tuesday December 28, @02:38PM EST (#345) (User Info) Open source is not a solution to everything. ESR states that if Quake has been an open source project it would not have any security problems. That's a load of bunk, to put it mildly. Sometimes the design criteria for a program make one trade off between multiple desireable traits. In the case of Quake (and other latency-sentitive online games) a critical design point is that the games have as little percieved latency as possible. So the clients are expected to do some processing beyond what the actual user is allowed to see. Sometimes, in the real world, no perfect solution is available. So you have to weigh your options and make the best decision you can. circular arguements don't work (Score:0) by Anonymous Coward on Tuesday December 28, @03:43PM EST (#346) to say that quake had it's problems because it wasn't open source, and that if it had started out open source it wouldn't have them is obsurd. "If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers." now i understand trying to promote open source, but the above comments from your article are rediculous. Open source doesn't mean that a magic secure protocal and implimentation would have been invented that would allow smooth gameplay for modem users without caching any information they didn't need at any given time. And bot recognition? That's been a useless feature from the beginning anyways and would have been a complete waste of time to implement. Every detection simply gets bypassed within hours of being implemented. Re:OpenSource Doesn't work (Score:0) by Anonymous Coward on Monday December 27, @11:53AM EST (#27) Yeah, if you repeat that to yourself long enough you'll start believing it too! Open Source does work, maybe not for you, but it does work (Linux). Re:OpenSource Doesn't work (Score:2) by phil reed (phillipcreed@yahoo.com) on Monday December 27, @11:56AM EST (#37) (User Info) How is this proof? That people corrupt the intent of the software? Fooey. That happens regardless of the source being open or closed. One example: AOHell appeared, corrupting the security model of AOL, despite the closed-source distribution environment of AOL. Closed source doesn't prevent bad people from doing bad things. ...phil "For a list of the ways which technology has failed to improve our quality of life, press 3." Re:OpenSource Doesn't work (Score:1) by Judah Diament on Monday December 27, @12:01PM EST (#51) (User Info) http://cs.nyu.edu/diam7644 how about proving what you're saying instead of making sweeping declaratiosn without backing them up? Re:OpenSource Doesn't work (Score:2) by MikeBabcock (mikebabcock@pobox.com) on Monday December 27, @12:09PM EST (#71) (User Info) http://www.linuxsupportline.com/~pgp/ I'll reply to this probably seconds before you get moderated as a Troll, but that's ok. Open Source works just fine. It worked before people wanted an alternative to MS and it will work when MS isn't an issue any more. Open Source is a "Good Idea" in most cases, if not all. The entire Patent office is an Open Source system -- without the freedom to use the ideas. If you just want to be a Troll, no evidence will convince you; the point is, some of us disagree with good reason. - Michael T. Babcock <homepage> - PGP Key 0xC2F837FD

		There's no such thing as a free lunch. -- Milton Friendman
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2000 Andover.Net.