...I plan to. I'm sort of casually boycotting DVD now. Unless "consumers" (I hate that term; I prefer the term "individuals") indicate to these industry consortiums that they aren't going to pay up if the restrictions are too annoying (as they did with DIVX), we'll be stuck with these sorts of things.
Unfortunately, people are going to see the much higher quality, and get suckered right in. (Much in the way I expect that most slashdot geeks have DVD players now because of the much higher quality, even if they are bothered by the legal assaults on DeCSS.) (And the general public probably doesn't even know about the assaults on DeCSS; if they do, they probably have the misconception that it's a piracy issue.)
For the server(s) to authorize character changes to a signed, client-stored character, they would have to perform an expensive public-key-encryption step for every change. Hardware crypto coprocessors notwithstanding, this is infeasible.
Naah, no need. Just set up a session key and use fast conventional cryptography for one gaming session. I mean, heck, it works swimmingly well for SSH, so why not for a game?
Note that the server has to "muck" with the character in order for one to play the game. So, while you make perfect sense, if your server goes untrusted on you, you are still screwed, no matter where the character data is stored. (For example you could log in, do the authentication dance, and then have character killed by a hacker and downloaded back to the client.)
Yes, you're right. There's not much you can do about that. However, in that case, they have to hack the server and set up a hacked server in its place. Right now, all they have to do is convince the properly running server that you are the one who gets to access this juicy character data that's sitting there on the server. That's almost certainly an easier hack than setting up a "false" server, especially if the authentication is done both ways.
(Recent discussions about flaws in the security model of SSH probably become relevant at this point.)
Your computer at home or at your office is certainly less secure than any server at, say, Microsoft, Red Hat, or Sun -- you depend on security through obscurity to hope that it doesn't get attacked. They don't.
The fact that computers at home depend on security through obscurity is a flaw in how home computers are configured nowadays. This is particularly a problem with Linux, where many distributions come out of the box running mail servers, web servers, at servers, etc. They should come running *no* servers. Somebody who needs that stuff will know how to turn it on. Most home computers should run few or no servers. At that point, you aren't just depending on security through obscurity; there's no way in to the computer! Obviously, this isn't exactly true, since you can use soemthing trojan-like, such as the spate of E-mail viruses out there, but that's yet another flaw in how home computers are configured.
However, for sake of argument, I will accept your assertion that the Microsoft, RedHat, Sun, etc. servers are safer than your home computer, for the simple reason that the companies have paid security people watching the network, and your computer is running a stupidly open distribution of your OS that leaves lots of holes. In this case, yes, it probably is more secure to have your data on the central server than at home-- for *one user*. But we aren't talking one user. We're talking lots and lots of users. If Microsoft has thousands or hundreds of thousands of users' data online on the server, it becomes a very tempting target. A cracker who gets in there and wreaks havoc can destroy or meddle with the files of huge numbers of users at once. He's unlikely to do that to all of the client machines one by one. (On the other hand, he might be likely to write an E-mail virus that will take the drudgery out of going from client to client for him.)
For some people, who would be targets of distruntled crackers, it might be worth it to hire security people to watch your computer-- and maybe that means putting your data on a Microsoft/Sun/RedHat server. But what this means to the rest of us, whom the crackers don't give a flyer about, is that now we've got our data sitting on the same place where the target has their data sitting. The analogy isn't to driving a car versus riding a plane, but is to driving a car and minding your own business versus trying to cut off a couple of people who are having a gun battle on the freeway.
All of this aside, for the common user, it may well be more secure to have his data on a central server. Not just from hackers, but from your own goofs (disk crashes, accidental deletions-- the server may well have backups that can rescue you). But for somebody who knows how to back up his data, and actually does it regularly, you can have more peace of mind knowing that you did your backups right rather than having to trust that the people who run the server did.
rknop: Except for saving disk space (reducing the amount of server-side data that must be stored while the client is disconnected), what problems would storing a hash of the character data instead of the whole data solve? If someone hasn't hacked your server, they can't change the server-side character data. If someone has read/write access to your server, then they can read your hash function, calculate a hash of their own altered character data, then write that new hash. It would make altering a character more tedious, but not more difficult.
Use public key cryptography, and encrypt things both ways, with your client's key and the server's key. In fact, you don't even need to store *anything* server side, which means that there's nothing server-side for crackers to modify in order to steal your character. (That was my mistake the first time around, thinking that any hash would need to be stored server side.) If the server has imprinted a digital signature on your character with its private key, and you're using crypto where faking that signature is hard (much as faking a digital signature with somebody else's private key in PGP is hard), then when you come back with a character, and the server sees that its private key checks out the digital signature, it knows that it's a legitimate character. If the server only signs characters it has approved, and only accepts characters with its digital signature, then you can keep control of your character data, *and* the server can be sure that only legitimate characters are coming back into the game.
Yes, there are ways around this too. Hack the server, steal its private key, and set up a man-in-the-middle sort of thing to modify incoming character data as people connect thereafter. This is more involved than just getting read/write access to the server, however. Without getting that server's private key, you can't change or replace other people's character data the way you can now, because that data isn't there on the server.
You can't store anything client side, because you cannot trust the clients. It doesn't matter how much encryption or checksums you have on the client - the bad guys have all the code on the client, and can reverse engineer it down to the metal if they have to. They can write proxies that pretend to be properly checksummed, and behind the scenes are doing whatever they want.
You have all of the code to PGP (or GPG). You can reverse engineer it all you want. Are you able to easily change a digitally signed message and still have the digital signature check out? No. Hence, if done right, why would a game client be able to change a character and have a decently implemented checksum come out right the next time you try to use the character on the server?
I'm certainly not advocating storing things client side and relying on security through obscurity! I'm advocating reasonable authentication, but not putting all the eggs in one basket, storing all the characters out there on a single server wehre anybody can get to it.
I'm also not saying that the client code is the code that should authorize any changes to the character. That should be done from the server side, yes. What I'm saying is that the character *data* should be stored on the client side, not in a central server location, but it should be done in such a way that the server can authenticate the data and verify that it is in fact a character it had approved before.
Your post shows a complete lack of awareness of the history here--I think you are trolling.
I'm not trolling at all. And, yes, I'm unaware of the history. And, no, you didn't understand what I said. Obviously, the client-side character in D1 was implemented poorly, from what you say. Obviously the D2 server-side character was implemented poorly, from the original news story. From just that alone, it's not obvious that one or the other is better. But I still believe that a client-stored character is safer.
Obviously, yes, it's really easy to have data stored on the clients in a manner that makes it too easy to cheat. Think it through; what I was in fact proposing was a checksum which uses public key cryptography to authenticate itself. It's not that big deal to make a private/public key; it can be an internal part of the program, and the user never has to know it is happening. All the keys can be stored internally to the client data. I don't see why this is overkill for a game, any more than getting the fastest CPU out there is overkill for a game. It's just using technology to help enhance the gameplay.
Basically, the server could authenticate the character exactly the same way that you authenticate digitally signed PGP messages. Digitally signed PGP messages store a checksum. The message can go anywhere, but people can check that the message fits the checksum. This isn't just obfuscation at all.
Changes to the character have to be approved by the server, but the characters then don't need to be *stored* on the server. The server just needs information to be sure that when a character comes back, it's an approved character. Digital signatures with decent public key cryptography serve this need to a T.
If the character data is on the server, then people who hack the server can muck with it. It probably could be done better, again using some sort of public-key cryptography. However, if the character data is on the client side, then somebody has to hack your client to screw with your character. Yes, it can happen, but it's less likely that we'll see the kind of wholesale hacking we're seeing here. If the server has decent autentication of the client's character, then that prevents you from cheating by modifying your character offline and coming in with an upgraded character.
I think that calling this Apocalypse for loss of game characters may be a bit alarmist.... However, there are lessons to be learned here for people doing actual *work* on the internet.
The basic flaw here is that the characters are all stored on the server. I don't care how good your crypto is, one day somebody will find a bug and figure out how to exploit it.
The damage may be mitigated if Blizzard had good backups. One can only hope.
However, the hack would have been made a lot harder in the first place if the characters were *not* stored server side. Store them client side, with a checksum stored server side to prevent client side cheating. Yeah, somebody may still figure out how to delete your server-side checksum, but they won't be able to muck with your data as much that way. And, if you use public key crypto, the "checksum" stored server side may be something that never needs to get sent anywhere but the server, making the thing intrinsically harder to hack.
There is a serious lesson here for systems like.NET. No matter how good the people running the server assert that their security is, you're asking for trouble by storing your data on a centralized server rather than on your own machine. I for one plan never fully to go to what is being touted as "the next platform". Some stuff I'll keep on servers, but I'm going to keep local backups on my *own* machine (and my own tapes), and I'm going to keep the documents I care more about on my own machine. Then I only have to worry about the security of just my machine, not some central server that's designed to be accessed by many people from many places.
Actually, I'm not so sure that the idea of server side characters is a good one. What would be better is client-side characters, with server side checksums (using a strong checksum like md5) to prevent client-side cheating. That model would have prevented the sort of meddling we're seeing here.
I hope that the world also makes the connection between what happened here and the propsects for systems like.NET. Store all my documents on a central server, however, well it claims to be protected? No thank you!
The predicted Y2K bugs could have been a technical catastrophe, but we would have gotten through it.
Instead, during Y2K, we watched as the DMCA gook affect, as the DeCSS ruling came down on the side of ignorance, as the number and stupidity of software patents filed continued to accelerate, as UCITA continued to make its way towards state legislatures across the country.
The real Y2K bugs were legal and sociological, and were assaults on individual freedom of expression. They were far more scary than the crashed-computer scenarios that two-digit dates could have caused.
To be sure, there were some bright points too-- e.g. the end of the RSA patent, the stay of execution on Europe's implementation of software patents. All in all, though, there were many more steps back than steps forward.
Of course it's fine to voluntarily boycott such controlled content, but what do you do when it's the only content available? I've been told repeatedly that VHS is on its way out in favor of DVD, and there does seem to be a gradual trend in this direction at the local Blockbuster. (After all, excepting the copy protection scam^H^H^H^Hscheme, DVD's are clearly superior to analog videotape.) So as soon as you want to use anything at all that relies on this dubious technology you will fold up, buy the software and the compliant hardware and grumble while it does its thing. And you will lose that content when you buy a new PC or hard drive -- unless you get the hack for it.
We are all sheep. We all know that slashdotters and the like have effectively no voice in the world-- that we are either portrayed as whiny losers who whine to each other on Slashdot (there's a whole lot of truth to this) or renegade hackers who have nothing but damage to others' rights on their agenda (there's very little truth in this). But with DVD's we aren't even using what little voice we have. Indeed, the technophilic nature of the sort of people that are drawn to slashdot probably means that a higher percentage of them than the common public have DVD players.
What we *should* be doing is boycotting the DVD standard, and loudly. Some of the few respected speakers among the techno-nerd crowd from which slashdot draws its audience should be echoing these boycotts. The message should be, we're not interested in a format that has a central patented control (i.e. DVDCCA) on the very format. We will boycott it until manufacturers and content providers come up with another format not so encumbered-- and buy *that*. Market forces could clearly win out here, but all of us techno-geeks are too drooling in awe of the capabilities of DVDs that we've just jumped lemming-like over the cliff rather than have the willpower to take whatever insigificant steps we could to harenss those market forces.
Market forces killed DIVX. The manufacturers are getting more canny, though. With DVIX, it was obvious to every consumer that they were getting a bum deal. Now, the manufacturers are getting better at slipping things in, things that only techno-geeks notice, which they can then use to provide DVIX-like controls on the hardware and software that everybody already has bought. There will not be market forces against it until the computer illiterate notice what they're losing, and by then it may well be too late.
(What's happening is that the massive entities who control distribution in the analog world are trying to enact legislation and such that will allow them to continue the same sorts of controls on the digital world. In the analog world, they were a little more natural. Joe Average making a copy of content would degrade it in quality; only the big entites had the resources necessary to really provide quality content. In the digital world, this is not true; anybody can make full quality copies. What should really happen is that as the digital world takes over, there should be a paradigm shift, and whole new models of distribution should come in. (Much as the very presence of recording technologies introduced new paradigms.) However, the people who have all the power in the analog world don't want it. But it really is unnatural, and eventually something that really uses digital technology to its full effect will take over and send the analog power brokers the way of the dinosauar. It will happen. Unfortunately, I fear it may take 50 or 100 years (pessimistically speaking), and those of us who live in the interem will have to suffer for it. Especially since those few who understand the issues don't do anything about it, but either just whine to each other (as I am doing now) or give up and buy tainted technology (as all of you have done with your DVDs).)
...Third, at least my version of tera-term with ttssh, stores the key the first time you connect, and will warn you if that key ever changes in a future session....
You make good points. And, yes, for these reasons, SSH will continue to be much more secure than FTP or Telnet. However, as I understood the point of the stories pointing out the flaws in SSH, they work around these sorts of protections. It's not a technical break (the way that sniffing a telnet password is). It's a social engineering break. Sure, SSH clients warn you if a host key has changed. However, most users when faced with the warning question "Host ID has changed, connect anyway?" will just say "Yes" and go onward. Even if only a small fraction of users do this, it might be enough to make it worth it to crackers getting passwords. And, I predict that much more than a small fraction of users will do this without thinking.
Remember, users don't like *any* hassle at all. I have hard time convincing people to use SSH in the first place because they think ftp is so much more convenient, and because they don't have graphical sftp/scp clients on their Macs/PCs/whatever. This mentality is not a mentality that will proceed with caution when warned that a host ID has changed.
Additionally, if this is the first time you're connecting to a site with SSH, a man-in-the-middle can send you their spoofed host key, and you will never know the difference. Again, I don't expect this to happen very often, but a *lot* of people are connecting to sites all over the net.
So, yes, we shouldn't be alarmist, and it's stupid to say it's the end of SSH since SSH is still more secure and harder to break than telnet. But we should also be realistic about the flaws in SSH, and the fact that the breaks mentioned here are not breaks of the protocol per se, but social engineering breaks based on reasonable assumptions about the laziness of users.
Why is it the end of a monopoly on high-end space imaging if you still have to get a license from the US government to sell it?
(After all, people get licenses for Windows all the time, and presumably would continue to even if MacOS, Linux, Solaris, and all the rest dissapearaed.)
Wouldn't it be really fun if they sued everybody who reproduced their bugs...
Don't laugh. The DMCA (law of the land) and UCITA (possible law of the land in at least a couple of states) make it at least in principle possible for Microsoft to sue anybody who just mentions their bugs, never mind reproduces them.
If you are installing Mozilla on a multi-user operating system such as Linux, Unix, or Windows 2000, you should install it separately in the user directory of each user who plans to use Mozilla.
Forget it, I'm not even going to try this. The last thing I want to have to do is have a HUGE program installed once for every user on the machine. Sure, at home, I'm mostly the only user, but not entirely. And at work, we can't afford that kind of disk space in everyone's home directories.
Why is it so hard to get a Mozilla with SSL working with a true multiuser install? I mean, hell, Quake 3 has a true multiuser install nowadays. Older browsers never had trouble with it. I like what I've seen of Mozilla, but I'm not going to consider it a viable option until the thing works on my Unix system like a Unix piece of software, not like a hacked-over piece of Windows 95 or MacOS 7 software.
There is yet another perspective to consider... we can all think of a recent election somewhere in Europe where the loser tried to claim that the election results showing him to be the loser were invalid.
Consider: after two or three recounts, the loser continues to be the loser, and yet continues to argue that the results as tabulated are not valid and require further recounts. Lawyers on the side of the loser are trying to invalidated many overseas ballots cast by members servering in the country's military. The loser claims to be clearly the people's choice, even though he only leads the popular election by a couple of hundred thousand out of one hundred million votes (probably within the popular election's margin of error, if you count up the ballots thrown out not just in Palm Beach county, but all the other counties).
I'm not trying to say that the Democrats are corrupt here; I'm just playing Devil's Advocate to balance the discussion. You gave lots of examples why the Republicans are stealing the election, but there are plenty of examples on both sides that can easily be interpreted as corruption.
(Snip the part about the military tending to be more violent, and hence more likely to intimidate wives into voting the way they want them to.)
My question is, will the Democrats use this to call into question the moral legitemacy of Bush's victory?
I would most certainly hope not! That would be a disaster of epic proportions. Go back and read what you wrote, and what you are suggesting we consider. You are suggesting that we consider that some people's votes are more "morally legitimate" than others-- that some people might have a better "right" to vote because they have taken some morally approved path for choosing whom they vote for.
You don't really have to go to far from there to get to deciding that all votes not cast for Nader are not "morally legitimate" because they represent votes by people who were influenced and bamboozled by environmental polluters... or that all votes not cast for Browne represent votes by those cowed by totalitarians, and hence are not morally legitimate in a "free country."
Let's not get into elitists arguments of deciding who is smart enough, or morally legitimate enough, to vote. If you're going to do that, then you shouldn't even pretend to have a democracy where the people choose the leaders. If the legitimacy of your vote is going to be based on one set of ideological criterea, just appoint somebody with the right ideology as dictator.
Lawmakers today passed a law prohibiting the use of automobiles, those recently invented "horseless carriages" which allow convenient travel overland, within city limits. While recognizing their unparalleled utility for travel between communities, lawmakers passed this law in order to protect the investments of buggy whip manufacturers. "Buggy whip manufacturers are an important sector of our economy," one congressman was quoted as saying. "It is essential and fair that we protect the investment and business of those corporations by limiting this technology which stands to undermine their very business, and, hence, our very way of life."
OK, 47 days sounds reasonable for actually writing code, but debugging it is work!! I've heard it said that programmers spend 10% of the time writing code and 90% debugging it. That's perhaps too extreme, but some bugs can certainly be hard to swat.
I agree fully. Indeed, when I'm "programming", I'm spending more of the time debugging and cleaning things up than I do when I'm first writing the code. I don't even distinguish between the two when I say what I'm doing. Debugging is such an integral part of getting something working that I consider it all part of the same thing.
When we talk about when a writer is "writing", do we just count the first draft? Take out the time when he presses the "delete" key? Take out the time reading, proofreading, and rewriting? All of that is considered part of writing. Why is debugging not considered part of programming?
...because it gives the user a false sense of security.
The actual encryption algorithm itself here may be fine; I don't know, I can't get the Securedelivery.com site to load. (Not a good sign.) But, as Bruce Schneider is fond of pointing out, it's not just the algorithm, but how it's used. Others here have already noted two problems: one, it's Yahoo's key, so you have to trust them to keep it secure. Two, the message already travels unencrypted to Yahoo, and even Yahoo agrees it's not end-to-end encryption.
So what, you say. It's more encrypted than Yahoo mail was before, so why not use it? The danger is that the public, who, together with politicans, have demonstrated a startling ability not to understand technology and encryption issues, may start touting this as the solution. A real solution (to the technological aspects, anwyay) is to have end to end encryption, with open source tools that at least in principle can be verified to have no back doors, and with your own personal keys you make yourself. Naturally, this makes the folks who run Carnivore unhappy, becuase they can't just go to Yahoo and demand keys. So, probably having given up the battle to competely outlaw encryption, they stand to benefit greatly from systems such as Yahoo's. The public might potentially be convinced that this is as good as encrypting your mail yourself. Indeed, many seem to have trust in huge companies (as is evidenced by the fact that the FUD attacks against Linux ("who will you sue?") took so long to go away), and may think that having Yahoo do it all for you is better.
I'd rather see it done right than implemented poorly in a way that might catch on.
A schoolteacher wants to show a small portion movie in school. A hypothetical protocol for a movie format has, as a condition of its licensing, the requirement that adverisements before the movie *cannot* be skipped. If anticircumvention technologies are illegal, the schoolteacher then cannot show the movie without first showing the ads.
(Aside: Would the mute button and turning off the monitor for the first part of class be considered a circumvention technology? Even if not, it's not a terribly satisfactory solution.)
Say, you own a Linux machine, and want to play a DVD you have legally purchased....
Although the current technology doesn't have this, consider a DVD set up with a "pay-per-view" lock. You purchase a movie, and then must buy a "key" that lets you watch it a fixed number of times. The company you purchased the movie from goes out of business. If nobody can circumvent the technology, they can't legally watch that disc ever again. Even if you say "so what, the consumer got what he paid for," libraries and archivists are in the same boat.
In any event, if I use @Home's SMTP server, I have two problems. One, regardless of how I set up my clients, half of the other clients out there will respond to my @Home address, which is *not* where I want to receive my mail. Using my own SMTP server, I can set the thing up so that it looks like it came from wherever, and I will then get replies where I want them (pobox.com) and people who add my address to their addressbook will add the right one (pobox.com, *not* home.com).
The second problem is that with @Home's mail servers, I would have no confidence using their SMTP mail servers that my mail was actually getting out with any degree of reliability....
In any event, I haven't had any problem using my own computer's SMTP. If push really came to shove, I might pay pobox the extra money to be able to use their SMTP servers.
(The other SMTP available is the one for the ISP where I really receive my E-mail, and which hosts my website. This is sonic.net, a *great* ISP for anybody in the right parts of Northern California. I still use it as my emergency backup dilaup, though naturally I don't dial in to it much given the cable modem. However, I can't use their SMTP servers from my @Home account, because they have the anti-spam "we won't send mail not from sonic.net" policies in place.)
Yes, I know this is a tangental point to the article, but...
For a permanent E-mail address, consider a forwarding service, e.g. pobox.com. That's what I use. It's not free, but it's only something like $15/year. The advantage of this is that you can keep the same E-mail address always (or at least for as long as pobox.com survives), even as you move between accounts. If your free hotmail or yahoo account starts to go south, get one somewhere else... and just point your pobox.com forwarding address at the new one.
pobox.com seems to be pretty reliable; I don't think I've lost any E-mail. With few exceptions, every POP/SMTP/mail server I've used has had trouble at one time or another. (We're not even going to talk about @home.) Forwarding services are a little easier to get right. Since I have the freedom to point my "same" E-mail address at any mail server I want, I can achieve greater stability without always having to tell people to change my E-mail addres....
(I also use my own computer's sendmail to *send* mail, instead of an external SMTP server. Hey, why not? It's not like I have sendmail running, I just give it a one-time invocation. I've set it up so that the From address is my pobox.com address.)
I've never quite figured out people who are opposed to software patents. Sure, they can be abused (like Amazon's "one-click" patent), but is that any reason to throw the baby out with the bathwater?...
But we should not get into a situation where big government tries to assume too much power and attempts to strangle business. How much blood has been spilled by oppressive government in the last century? This is precisely what we do not need.
The problem here is that the bathwater is so amazingly fouled that you can't save the baby anyway. Throw them both out before more babies get poisoned.
See, you've got it backwards. Software patents as they exist today are "big government," and big government is supplying tools (blunt instruments, more like) that allow big business to oppress the little guy. It's the patent office and the courts which are providing the means for the abuse here! Those who want to get rid of software patents are arguing for less government regulation! The big companies are the only ones who can afford the lawyers to perform the patent searches and court battles to either fight their patents, fight stupid patents, or figure out which patents need to be licensed before they can ship something.
A lot of the big companies that "made" today's strong high tech economy came out of nowhere in the last couple of decades. The software patent system is just allowing them to entrench themselves so that tomorrows innovative new companies will be choked off at birth (poisoned in that fouled bathwater).
If both the patent office and the culprit corporations had proved that they could play reasonably with software patents, then fine. They have amply proved that they cannot. So, the system should go out. The corporations who abused it so should figure out their own way to protect their intellectual property. If we throw the patents out, hopefully they'll learn something about taking too much unfair advantage of whatever system they come up with.
Software and business model patents choke and stifle innovation. Too many of the patents out there have nothing to do with the billions of dollars of R&D investment that you mention. They mostly have to do with somebody being first to the pole with a relatively trivial idea (even if they weren't the first to come up with it or use it). All somebody has to do is create a medicore implementation of the idea, and then sue and license anybody else who tries to use it. Never mind somebody making a better mousetrap, if the whole concept of trapping mice has been patented.
Slashdot Mirror
...I plan to. I'm sort of casually boycotting DVD now. Unless "consumers" (I hate that term; I prefer the term "individuals") indicate to these industry consortiums that they aren't going to pay up if the restrictions are too annoying (as they did with DIVX), we'll be stuck with these sorts of things.
Unfortunately, people are going to see the much higher quality, and get suckered right in. (Much in the way I expect that most slashdot geeks have DVD players now because of the much higher quality, even if they are bothered by the legal assaults on DeCSS.) (And the general public probably doesn't even know about the assaults on DeCSS; if they do, they probably have the misconception that it's a piracy issue.)
-Rob
For the server(s) to authorize character changes to a signed, client-stored character, they would have to perform an expensive public-key-encryption step for every change. Hardware crypto coprocessors notwithstanding, this is infeasible.
Naah, no need. Just set up a session key and use fast conventional cryptography for one gaming session. I mean, heck, it works swimmingly well for SSH, so why not for a game?
-Rob
Note that the server has to "muck" with the character in order for one to play the game. So, while you make perfect sense, if your server goes untrusted on you, you are still screwed, no matter where the character data is stored. (For example you could log in, do the authentication dance, and then have character killed by a hacker and downloaded back to the client.)
Yes, you're right. There's not much you can do about that. However, in that case, they have to hack the server and set up a hacked server in its place. Right now, all they have to do is convince the properly running server that you are the one who gets to access this juicy character data that's sitting there on the server. That's almost certainly an easier hack than setting up a "false" server, especially if the authentication is done both ways.
(Recent discussions about flaws in the security model of SSH probably become relevant at this point.)
-Rob
Your computer at home or at your office is certainly less secure than any server at, say, Microsoft, Red Hat, or Sun -- you depend on security through obscurity to hope that it doesn't get attacked. They don't.
The fact that computers at home depend on security through obscurity is a flaw in how home computers are configured nowadays. This is particularly a problem with Linux, where many distributions come out of the box running mail servers, web servers, at servers, etc. They should come running *no* servers. Somebody who needs that stuff will know how to turn it on. Most home computers should run few or no servers. At that point, you aren't just depending on security through obscurity; there's no way in to the computer! Obviously, this isn't exactly true, since you can use soemthing trojan-like, such as the spate of E-mail viruses out there, but that's yet another flaw in how home computers are configured.
However, for sake of argument, I will accept your assertion that the Microsoft, RedHat, Sun, etc. servers are safer than your home computer, for the simple reason that the companies have paid security people watching the network, and your computer is running a stupidly open distribution of your OS that leaves lots of holes. In this case, yes, it probably is more secure to have your data on the central server than at home-- for *one user*. But we aren't talking one user. We're talking lots and lots of users. If Microsoft has thousands or hundreds of thousands of users' data online on the server, it becomes a very tempting target. A cracker who gets in there and wreaks havoc can destroy or meddle with the files of huge numbers of users at once. He's unlikely to do that to all of the client machines one by one. (On the other hand, he might be likely to write an E-mail virus that will take the drudgery out of going from client to client for him.)
For some people, who would be targets of distruntled crackers, it might be worth it to hire security people to watch your computer-- and maybe that means putting your data on a Microsoft/Sun/RedHat server. But what this means to the rest of us, whom the crackers don't give a flyer about, is that now we've got our data sitting on the same place where the target has their data sitting. The analogy isn't to driving a car versus riding a plane, but is to driving a car and minding your own business versus trying to cut off a couple of people who are having a gun battle on the freeway.
All of this aside, for the common user, it may well be more secure to have his data on a central server. Not just from hackers, but from your own goofs (disk crashes, accidental deletions-- the server may well have backups that can rescue you). But for somebody who knows how to back up his data, and actually does it regularly, you can have more peace of mind knowing that you did your backups right rather than having to trust that the people who run the server did.
-Rob
rknop: Except for saving disk space (reducing the amount of server-side data that must be stored while the client is disconnected), what problems would storing a hash of the character data instead of the whole data solve? If someone hasn't hacked your server, they can't change the server-side character data. If someone has read/write access to your server, then they can read your hash function, calculate a hash of their own altered character data, then write that new hash. It would make altering a character more tedious, but not more difficult.
Use public key cryptography, and encrypt things both ways, with your client's key and the server's key. In fact, you don't even need to store *anything* server side, which means that there's nothing server-side for crackers to modify in order to steal your character. (That was my mistake the first time around, thinking that any hash would need to be stored server side.) If the server has imprinted a digital signature on your character with its private key, and you're using crypto where faking that signature is hard (much as faking a digital signature with somebody else's private key in PGP is hard), then when you come back with a character, and the server sees that its private key checks out the digital signature, it knows that it's a legitimate character. If the server only signs characters it has approved, and only accepts characters with its digital signature, then you can keep control of your character data, *and* the server can be sure that only legitimate characters are coming back into the game.
Yes, there are ways around this too. Hack the server, steal its private key, and set up a man-in-the-middle sort of thing to modify incoming character data as people connect thereafter. This is more involved than just getting read/write access to the server, however. Without getting that server's private key, you can't change or replace other people's character data the way you can now, because that data isn't there on the server.
-Rob
You can't store anything client side, because you cannot trust the clients. It doesn't matter how much encryption or checksums you have on the client - the bad guys have all the code on the client, and can reverse engineer it down to the metal if they have to. They can write proxies that pretend to be properly checksummed, and behind the scenes are doing whatever they want.
You have all of the code to PGP (or GPG). You can reverse engineer it all you want. Are you able to easily change a digitally signed message and still have the digital signature check out? No. Hence, if done right, why would a game client be able to change a character and have a decently implemented checksum come out right the next time you try to use the character on the server?
I'm certainly not advocating storing things client side and relying on security through obscurity! I'm advocating reasonable authentication, but not putting all the eggs in one basket, storing all the characters out there on a single server wehre anybody can get to it.
I'm also not saying that the client code is the code that should authorize any changes to the character. That should be done from the server side, yes. What I'm saying is that the character *data* should be stored on the client side, not in a central server location, but it should be done in such a way that the server can authenticate the data and verify that it is in fact a character it had approved before.
-Rob
Your post shows a complete lack of awareness of the history here--I think you are trolling.
I'm not trolling at all. And, yes, I'm unaware of the history. And, no, you didn't understand what I said. Obviously, the client-side character in D1 was implemented poorly, from what you say. Obviously the D2 server-side character was implemented poorly, from the original news story. From just that alone, it's not obvious that one or the other is better. But I still believe that a client-stored character is safer.
Obviously, yes, it's really easy to have data stored on the clients in a manner that makes it too easy to cheat. Think it through; what I was in fact proposing was a checksum which uses public key cryptography to authenticate itself. It's not that big deal to make a private/public key; it can be an internal part of the program, and the user never has to know it is happening. All the keys can be stored internally to the client data. I don't see why this is overkill for a game, any more than getting the fastest CPU out there is overkill for a game. It's just using technology to help enhance the gameplay.
Basically, the server could authenticate the character exactly the same way that you authenticate digitally signed PGP messages. Digitally signed PGP messages store a checksum. The message can go anywhere, but people can check that the message fits the checksum. This isn't just obfuscation at all.
Changes to the character have to be approved by the server, but the characters then don't need to be *stored* on the server. The server just needs information to be sure that when a character comes back, it's an approved character. Digital signatures with decent public key cryptography serve this need to a T.
If the character data is on the server, then people who hack the server can muck with it. It probably could be done better, again using some sort of public-key cryptography. However, if the character data is on the client side, then somebody has to hack your client to screw with your character. Yes, it can happen, but it's less likely that we'll see the kind of wholesale hacking we're seeing here. If the server has decent autentication of the client's character, then that prevents you from cheating by modifying your character offline and coming in with an upgraded character.
-Rob
I think that calling this Apocalypse for loss of game characters may be a bit alarmist.... However, there are lessons to be learned here for people doing actual *work* on the internet.
The basic flaw here is that the characters are all stored on the server. I don't care how good your crypto is, one day somebody will find a bug and figure out how to exploit it.
The damage may be mitigated if Blizzard had good backups. One can only hope.
However, the hack would have been made a lot harder in the first place if the characters were *not* stored server side. Store them client side, with a checksum stored server side to prevent client side cheating. Yeah, somebody may still figure out how to delete your server-side checksum, but they won't be able to muck with your data as much that way. And, if you use public key crypto, the "checksum" stored server side may be something that never needs to get sent anywhere but the server, making the thing intrinsically harder to hack.
There is a serious lesson here for systems like .NET. No matter how good the people running the server assert that their security is, you're asking for trouble by storing your data on a centralized server rather than on your own machine. I for one plan never fully to go to what is being touted as "the next platform". Some stuff I'll keep on servers, but I'm going to keep local backups on my *own* machine (and my own tapes), and I'm going to keep the documents I care more about on my own machine. Then I only have to worry about the security of just my machine, not some central server that's designed to be accessed by many people from many places.
-Rob
Actually, I'm not so sure that the idea of server side characters is a good one. What would be better is client-side characters, with server side checksums (using a strong checksum like md5) to prevent client-side cheating. That model would have prevented the sort of meddling we're seeing here.
I hope that the world also makes the connection between what happened here and the propsects for systems like .NET. Store all my documents on a central server, however, well it claims to be protected? No thank you!
-Rob
The predicted Y2K bugs could have been a technical catastrophe, but we would have gotten through it.
Instead, during Y2K, we watched as the DMCA gook affect, as the DeCSS ruling came down on the side of ignorance, as the number and stupidity of software patents filed continued to accelerate, as UCITA continued to make its way towards state legislatures across the country.
The real Y2K bugs were legal and sociological, and were assaults on individual freedom of expression. They were far more scary than the crashed-computer scenarios that two-digit dates could have caused.
To be sure, there were some bright points too-- e.g. the end of the RSA patent, the stay of execution on Europe's implementation of software patents. All in all, though, there were many more steps back than steps forward.
-Rob
It should read "Microsoft a National Security Threat".
-Rob
Of course it's fine to voluntarily boycott such controlled content, but what do you do when it's the only content available? I've been told repeatedly that VHS is on its way out in favor of DVD, and there does seem to be a gradual trend in this direction at the local Blockbuster. (After all, excepting the copy protection scam^H^H^H^Hscheme, DVD's are clearly superior to analog videotape.) So as soon as you want to use anything at all that relies on this dubious technology you will fold up, buy the software and the compliant hardware and grumble while it does its thing. And you will lose that content when you buy a new PC or hard drive -- unless you get the hack for it.
We are all sheep. We all know that slashdotters and the like have effectively no voice in the world-- that we are either portrayed as whiny losers who whine to each other on Slashdot (there's a whole lot of truth to this) or renegade hackers who have nothing but damage to others' rights on their agenda (there's very little truth in this). But with DVD's we aren't even using what little voice we have. Indeed, the technophilic nature of the sort of people that are drawn to slashdot probably means that a higher percentage of them than the common public have DVD players.
What we *should* be doing is boycotting the DVD standard, and loudly. Some of the few respected speakers among the techno-nerd crowd from which slashdot draws its audience should be echoing these boycotts. The message should be, we're not interested in a format that has a central patented control (i.e. DVDCCA) on the very format. We will boycott it until manufacturers and content providers come up with another format not so encumbered-- and buy *that*. Market forces could clearly win out here, but all of us techno-geeks are too drooling in awe of the capabilities of DVDs that we've just jumped lemming-like over the cliff rather than have the willpower to take whatever insigificant steps we could to harenss those market forces.
Market forces killed DIVX. The manufacturers are getting more canny, though. With DVIX, it was obvious to every consumer that they were getting a bum deal. Now, the manufacturers are getting better at slipping things in, things that only techno-geeks notice, which they can then use to provide DVIX-like controls on the hardware and software that everybody already has bought. There will not be market forces against it until the computer illiterate notice what they're losing, and by then it may well be too late.
(What's happening is that the massive entities who control distribution in the analog world are trying to enact legislation and such that will allow them to continue the same sorts of controls on the digital world. In the analog world, they were a little more natural. Joe Average making a copy of content would degrade it in quality; only the big entites had the resources necessary to really provide quality content. In the digital world, this is not true; anybody can make full quality copies. What should really happen is that as the digital world takes over, there should be a paradigm shift, and whole new models of distribution should come in. (Much as the very presence of recording technologies introduced new paradigms.) However, the people who have all the power in the analog world don't want it. But it really is unnatural, and eventually something that really uses digital technology to its full effect will take over and send the analog power brokers the way of the dinosauar. It will happen. Unfortunately, I fear it may take 50 or 100 years (pessimistically speaking), and those of us who live in the interem will have to suffer for it. Especially since those few who understand the issues don't do anything about it, but either just whine to each other (as I am doing now) or give up and buy tainted technology (as all of you have done with your DVDs).)
-Rob
You make good points. And, yes, for these reasons, SSH will continue to be much more secure than FTP or Telnet. However, as I understood the point of the stories pointing out the flaws in SSH, they work around these sorts of protections. It's not a technical break (the way that sniffing a telnet password is). It's a social engineering break. Sure, SSH clients warn you if a host key has changed. However, most users when faced with the warning question "Host ID has changed, connect anyway?" will just say "Yes" and go onward. Even if only a small fraction of users do this, it might be enough to make it worth it to crackers getting passwords. And, I predict that much more than a small fraction of users will do this without thinking.
Remember, users don't like *any* hassle at all. I have hard time convincing people to use SSH in the first place because they think ftp is so much more convenient, and because they don't have graphical sftp/scp clients on their Macs/PCs/whatever. This mentality is not a mentality that will proceed with caution when warned that a host ID has changed.
Additionally, if this is the first time you're connecting to a site with SSH, a man-in-the-middle can send you their spoofed host key, and you will never know the difference. Again, I don't expect this to happen very often, but a *lot* of people are connecting to sites all over the net.
So, yes, we shouldn't be alarmist, and it's stupid to say it's the end of SSH since SSH is still more secure and harder to break than telnet. But we should also be realistic about the flaws in SSH, and the fact that the breaks mentioned here are not breaks of the protocol per se, but social engineering breaks based on reasonable assumptions about the laziness of users.
-Rob
Why is it the end of a monopoly on high-end space imaging if you still have to get a license from the US government to sell it?
(After all, people get licenses for Windows all the time, and presumably would continue to even if MacOS, Linux, Solaris, and all the rest dissapearaed.)
-Rob
copyright, or better yet, patent their bugs.
Wouldn't it be really fun if they sued everybody who reproduced their bugs...
Don't laugh. The DMCA (law of the land) and UCITA (possible law of the land in at least a couple of states) make it at least in principle possible for Microsoft to sue anybody who just mentions their bugs, never mind reproduces them.
-Rob
From the release notes:
If you are installing Mozilla on a multi-user operating system such as Linux, Unix, or Windows 2000, you should install it separately in the user directory of each user who plans to use Mozilla.
Forget it, I'm not even going to try this. The last thing I want to have to do is have a HUGE program installed once for every user on the machine. Sure, at home, I'm mostly the only user, but not entirely. And at work, we can't afford that kind of disk space in everyone's home directories.
Why is it so hard to get a Mozilla with SSL working with a true multiuser install? I mean, hell, Quake 3 has a true multiuser install nowadays. Older browsers never had trouble with it. I like what I've seen of Mozilla, but I'm not going to consider it a viable option until the thing works on my Unix system like a Unix piece of software, not like a hacked-over piece of Windows 95 or MacOS 7 software.
-Rob
There is yet another perspective to consider... we can all think of a recent election somewhere in Europe where the loser tried to claim that the election results showing him to be the loser were invalid.
Consider: after two or three recounts, the loser continues to be the loser, and yet continues to argue that the results as tabulated are not valid and require further recounts. Lawyers on the side of the loser are trying to invalidated many overseas ballots cast by members servering in the country's military. The loser claims to be clearly the people's choice, even though he only leads the popular election by a couple of hundred thousand out of one hundred million votes (probably within the popular election's margin of error, if you count up the ballots thrown out not just in Palm Beach county, but all the other counties).
I'm not trying to say that the Democrats are corrupt here; I'm just playing Devil's Advocate to balance the discussion. You gave lots of examples why the Republicans are stealing the election, but there are plenty of examples on both sides that can easily be interpreted as corruption.
-Rob
(Snip the part about the military tending to be more violent, and hence more likely to intimidate wives into voting the way they want them to.)
My question is, will the Democrats use this to call into question the moral legitemacy of Bush's victory?
I would most certainly hope not! That would be a disaster of epic proportions. Go back and read what you wrote, and what you are suggesting we consider. You are suggesting that we consider that some people's votes are more "morally legitimate" than others-- that some people might have a better "right" to vote because they have taken some morally approved path for choosing whom they vote for.
You don't really have to go to far from there to get to deciding that all votes not cast for Nader are not "morally legitimate" because they represent votes by people who were influenced and bamboozled by environmental polluters... or that all votes not cast for Browne represent votes by those cowed by totalitarians, and hence are not morally legitimate in a "free country."
Let's not get into elitists arguments of deciding who is smart enough, or morally legitimate enough, to vote. If you're going to do that, then you shouldn't even pretend to have a democracy where the people choose the leaders. If the legitimacy of your vote is going to be based on one set of ideological criterea, just appoint somebody with the right ideology as dictator.
-Rob
From earlier this century...
Lawmakers today passed a law prohibiting the use of automobiles, those recently invented "horseless carriages" which allow convenient travel overland, within city limits. While recognizing their unparalleled utility for travel between communities, lawmakers passed this law in order to protect the investments of buggy whip manufacturers. "Buggy whip manufacturers are an important sector of our economy," one congressman was quoted as saying. "It is essential and fair that we protect the investment and business of those corporations by limiting this technology which stands to undermine their very business, and, hence, our very way of life."
-Rob
OK, 47 days sounds reasonable for actually writing code, but debugging it is work!! I've heard it said that programmers spend 10% of the time writing code and 90% debugging it. That's perhaps too extreme, but some bugs can certainly be hard to swat.
I agree fully. Indeed, when I'm "programming", I'm spending more of the time debugging and cleaning things up than I do when I'm first writing the code. I don't even distinguish between the two when I say what I'm doing. Debugging is such an integral part of getting something working that I consider it all part of the same thing.
When we talk about when a writer is "writing", do we just count the first draft? Take out the time when he presses the "delete" key? Take out the time reading, proofreading, and rewriting? All of that is considered part of writing. Why is debugging not considered part of programming?
-Rob
...because it gives the user a false sense of security.
The actual encryption algorithm itself here may be fine; I don't know, I can't get the Securedelivery.com site to load. (Not a good sign.) But, as Bruce Schneider is fond of pointing out, it's not just the algorithm, but how it's used. Others here have already noted two problems: one, it's Yahoo's key, so you have to trust them to keep it secure. Two, the message already travels unencrypted to Yahoo, and even Yahoo agrees it's not end-to-end encryption.
So what, you say. It's more encrypted than Yahoo mail was before, so why not use it? The danger is that the public, who, together with politicans, have demonstrated a startling ability not to understand technology and encryption issues, may start touting this as the solution. A real solution (to the technological aspects, anwyay) is to have end to end encryption, with open source tools that at least in principle can be verified to have no back doors, and with your own personal keys you make yourself. Naturally, this makes the folks who run Carnivore unhappy, becuase they can't just go to Yahoo and demand keys. So, probably having given up the battle to competely outlaw encryption, they stand to benefit greatly from systems such as Yahoo's. The public might potentially be convinced that this is as good as encrypting your mail yourself. Indeed, many seem to have trust in huge companies (as is evidenced by the fact that the FUD attacks against Linux ("who will you sue?") took so long to go away), and may think that having Yahoo do it all for you is better.
I'd rather see it done right than implemented poorly in a way that might catch on.
-Rob
A schoolteacher wants to show a small portion movie in school. A hypothetical protocol for a movie format has, as a condition of its licensing, the requirement that adverisements before the movie *cannot* be skipped. If anticircumvention technologies are illegal, the schoolteacher then cannot show the movie without first showing the ads.
(Aside: Would the mute button and turning off the monitor for the first part of class be considered a circumvention technology? Even if not, it's not a terribly satisfactory solution.)
Say, you own a Linux machine, and want to play a DVD you have legally purchased....
Although the current technology doesn't have this, consider a DVD set up with a "pay-per-view" lock. You purchase a movie, and then must buy a "key" that lets you watch it a fixed number of times. The company you purchased the movie from goes out of business. If nobody can circumvent the technology, they can't legally watch that disc ever again. Even if you say "so what, the consumer got what he paid for," libraries and archivists are in the same boat.
-Rob
I've got a cable modem, so it isn't a dialup....
In any event, if I use @Home's SMTP server, I have two problems. One, regardless of how I set up my clients, half of the other clients out there will respond to my @Home address, which is *not* where I want to receive my mail. Using my own SMTP server, I can set the thing up so that it looks like it came from wherever, and I will then get replies where I want them (pobox.com) and people who add my address to their addressbook will add the right one (pobox.com, *not* home.com).
The second problem is that with @Home's mail servers, I would have no confidence using their SMTP mail servers that my mail was actually getting out with any degree of reliability....
In any event, I haven't had any problem using my own computer's SMTP. If push really came to shove, I might pay pobox the extra money to be able to use their SMTP servers.
(The other SMTP available is the one for the ISP where I really receive my E-mail, and which hosts my website. This is sonic.net, a *great* ISP for anybody in the right parts of Northern California. I still use it as my emergency backup dilaup, though naturally I don't dial in to it much given the cable modem. However, I can't use their SMTP servers from my @Home account, because they have the anti-spam "we won't send mail not from sonic.net" policies in place.)
-Rob
Yes, I know this is a tangental point to the article, but...
For a permanent E-mail address, consider a forwarding service, e.g. pobox.com. That's what I use. It's not free, but it's only something like $15/year. The advantage of this is that you can keep the same E-mail address always (or at least for as long as pobox.com survives), even as you move between accounts. If your free hotmail or yahoo account starts to go south, get one somewhere else... and just point your pobox.com forwarding address at the new one.
pobox.com seems to be pretty reliable; I don't think I've lost any E-mail. With few exceptions, every POP/SMTP/mail server I've used has had trouble at one time or another. (We're not even going to talk about @home.) Forwarding services are a little easier to get right. Since I have the freedom to point my "same" E-mail address at any mail server I want, I can achieve greater stability without always having to tell people to change my E-mail addres....
(I also use my own computer's sendmail to *send* mail, instead of an external SMTP server. Hey, why not? It's not like I have sendmail running, I just give it a one-time invocation. I've set it up so that the From address is my pobox.com address.)
-Rob
I've never quite figured out people who are opposed to software patents. Sure, they can be abused (like Amazon's "one-click" patent), but is that any reason to throw the baby out with the bathwater?...
But we should not get into a situation where big government tries to assume too much power and attempts to strangle business. How much blood has been spilled by oppressive government in the last century? This is precisely what we do not need.
The problem here is that the bathwater is so amazingly fouled that you can't save the baby anyway. Throw them both out before more babies get poisoned.
See, you've got it backwards. Software patents as they exist today are "big government," and big government is supplying tools (blunt instruments, more like) that allow big business to oppress the little guy. It's the patent office and the courts which are providing the means for the abuse here! Those who want to get rid of software patents are arguing for less government regulation! The big companies are the only ones who can afford the lawyers to perform the patent searches and court battles to either fight their patents, fight stupid patents, or figure out which patents need to be licensed before they can ship something.
A lot of the big companies that "made" today's strong high tech economy came out of nowhere in the last couple of decades. The software patent system is just allowing them to entrench themselves so that tomorrows innovative new companies will be choked off at birth (poisoned in that fouled bathwater).
If both the patent office and the culprit corporations had proved that they could play reasonably with software patents, then fine. They have amply proved that they cannot. So, the system should go out. The corporations who abused it so should figure out their own way to protect their intellectual property. If we throw the patents out, hopefully they'll learn something about taking too much unfair advantage of whatever system they come up with.
Software and business model patents choke and stifle innovation. Too many of the patents out there have nothing to do with the billions of dollars of R&D investment that you mention. They mostly have to do with somebody being first to the pole with a relatively trivial idea (even if they weren't the first to come up with it or use it). All somebody has to do is create a medicore implementation of the idea, and then sue and license anybody else who tries to use it. Never mind somebody making a better mousetrap, if the whole concept of trapping mice has been patented.
-Rob