Saturday, August 10. 2013
One funny thing about SSL and TLS, as regards mail delivery, is that in general mail servers don't talk to each other encrypted. Using SSL/TLS from your mail client (or web browser, and from web server to mail server) to the mail server protects your password, but when mail is relayed from that server to the destination server1, it's done in the clear - the whole email gets passed over the Internet completely readable.
Hell, your web browser connection to Facebook or G+ may be secure, but those notification emails about everything going on? Yeah, that is all sent over the Internet in plaintext. Constantly.
Unfortunately, the fix for this is about as popular as OpenPGP. One part is to encrypt all the traffic, but of course the only way to do that properly is to know the public key on the other end, and trust it. That's where public key infrastructure comes into play, and certificate authorities that establish a chain of trust that leads your software to say "ok, that public key really is for www.google.com." That public key infrastructure has been subverted before, and it could definitely be subverted again (whether by hackers or by government agents with court-issued secret letters).
If you pretend for a minute that SMTP isn't a problem (after all, if it were being constantly monitored, why would anyone go talk to Lavabit about getting messages off of their servers?), you could probably do something better with mail storage, where the server knows a public key for each local recipient and encrypts plainext messages in a standard way (OpenPGP, S/MIME) so that any reasonably smart mail client that has the private key can decrypt it. The server could even sign the message, and then the user could get some feedback about whether the message was really secure (signed by the sender) or simply stored in a secure way (signed by the server).
Then you get to webmail. Where does the private key get stored for webmail, a terrible thing to which many people have nonetheless become addicted? Well, if you go down the same road as Lavabit, you encrypt that private key with the user's password, and decrypt things on the user's behalf on your server, presenting the user with a normal (unencrypted) view of their mail. There are two big problems with that approach. One is that, obviously, Lavabit shut down because that kind of security still leaves everything sitting on the server.
The other is pretty closely related: Lavabit didn't have to shut down. They could have modified their server to not encrypt a given user's messages, and decrypted that user's messages the next time they logged in. The user would never see a change in behavior, no indication that things had stopped being secure. With the approach above, requiring the user to run software to decrypt the messages themselves, there's never going to be any doubt.
All of that still ignores SMTP, though. If people - real numbers of people, or at least real numbers of the people being targeted - start finding ways to keep their mail storage secure, the next obvious step is to subvert the delivery. And there, the only real secure way to send a message is for the sender to encrypt and sign it, and let the recipient (and only the recipient) decrypt and verify the signature. Nothing else gives the relevant users the proper feedback on what's going on.
1. I'm oversimplifying a lot here, pretending that one piece of software comprises a "mail server," ignoring relays, and so on.
Friday, April 5. 2013
Regarding the ethics of naming and shaming, Dr. Stemwedel wrote an interesting analysis over at Scientific American. My own personal take is this: naming and shaming is a tool mostly for seeking justice. It seems most widely used when other, better avenues, are not available. It can be used to help bring about equality by publicizing the misdeeds that otherwise wouldn't be judged fairly in courts, it can also be a tool to further oppress people rightfully protected by the courts.
When folks like myself who enjoy a lot of privilege in the industry and in society try to insist that naming and shaming should never happen, we are also insisting that people with relatively few recourses be kept that way. However, it's still just a tool. We can choose to help build a society and an industry where these are moot points. To borrow someone else's analogy, we need to get rid of the cat food factory awaiting minorities and women (among others) who try to join the supposed meritocracy of the tech industry. A lot of people think the game industry, as a mostly-microcosm of the tech industry, is full of weird people and total acceptance of 'different.' I'd say that's true as long as your basic similarities start off with being white and male.
Note: comments are still open, and still subject to post facto moderation, on this post as any other. If conversations around the 'Net are any indication, I'm going to have to be a bit more active in that regard on this post than usual. Don't try to spew filth and hatred on my site.
Friday, July 6. 2012
I'm not sure how much point there is, though. I finally got around to updating my bio here, to clarify that I'm not working on games; I walked away from KingsIsle and games in February of this year, and am much happier now.
Friday, July 8. 2011
Who is doing the hard work, and who is swooping in at the last minute to enjoy the ill-gotten fruit of another's labor? Here's a little snippet from University of Wales, Newport's description of the Computer Games Design - BA (Honors) degree:
When you graduate from the course you are fully prepared as a creative practitioner who can really make a difference. Roles range from the traditional art positions of character and environment design concept to model, rigging and animation to level design and project management for computer games design.
Frankly, that looks very much like the university is suggesting that students will come out of the program ready for a career; one where the student can make a difference, develop games independently, etc. Academia is trying to sell students on degrees for the marketable, useful skills imparted over the course of earning the degree, and then refusing to be accountable to either the industries targeted, or the graduated student who discovers too late that they are not actually prepared for a job.
The other funny thing about this rant is the disconnect between the criticisms he perceives as being leveled at games education ("By turns it’s either too many or too few games, not enough programming, etc") and his defense (arguing that academia is not about "fitting the loyalty chips in the necks of serfs bound for indentured servitude at the nearest Triple-A studio")1. Are the only people criticizing game development curricula at those AAA studios? Is that really their main interest in game development programs? Or is there actually a disconnect between the education offered in these programs, the promises they make, and the students coming out?
The group of people in this scenario that seem to have no accountability - that try to avoid taking responsibility for their actions - are the universities. The students certainly pay their way, the game developers are left still struggling to find, develop, or explain how someone embarks on this career path and develops along it... but the universities, well, they've got tuition and they've got another batch of students and if anyone says "you treated that last batch of students wrong" - the response is
We aren’t training sweatshops. We don’t teach skills, we teach people. Now bog off and let us do our job!
1. I'm being a bit loose with the quote; however, I think I'm accurately portraying his stance in the article, and it's really the best imagery in the article.