Slashdot Mirror

I wrote a short entry on Steam and why online distribution (or a worse alternative) is inevitable for PC games (console too, eventually). I'd love to hear some commentary on it from fellow /.ers.

Also, I've heard many complaints about Steam's bandwidth and whatnot. The solution is simple, and Valve went so far as to hire Bram Cohen, of BitTorrent fame, at one point to work on Steam. (Note the timestamp on this article before complaining I'm outta date :) No clue why it doesn't intelligently swarm yet...

Don

I wrote a short entry on Steam and why online distribution (or a worse alternative) is inevitable for PC games (console too, eventually). I'd love to hear some commentary on it from fellow /.ers.

Also, I've heard many complaints about Steam's bandwidth and whatnot. The solution is simple, and Valve went so far as to hire Bram Cohen, of BitTorrent fame, at one point to work on Steam. (Note the timestamp on this article before complaining I'm outta date :) No clue why it doesn't intelligently swarm yet...

Don

Designing More User-friendly DRM
MightyWords Ex-R&D Manager Don MacAskill talks about the Security Design Behind eMatter

By Don MacAskill
March 7, 2002

I really enjoyed your technical analysis of MightyWords' eMatter security . As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. I was turned on to the article by Brian Scardina, another core engineer on the project, who also agrees with the analysis.

I should note that exposing the eMatter downloads to anyone and everyone was by design: customers were encouraged to email their purchased eMatter documents to friends. Sharing was a core business concept that we tried to foster.

A little background about our decisions and why we made them

As the article mentions, we made a tough decision: lower security in exchange for a better user experience. From the outset, we had a clear set of goals:

1. A user only has to unlock it once. If possible, pre-unlock it for them during the purchase process.
2. Cross-platform (Windows, Mac, and any flavor of Unix we could)
3. Useable across all devices a user possessed - desktops, laptops, and, we hoped, eventually handhelds, no extra purchase required for each device.
4. No additional downloads (plugins, etc)
5. Acrobat 3.01 with JavaScript (not the then-new 5.0 or the myriad of confusing 4.0x releases) as the lowest required version, with at least the ability to inform Acrobat 3.0 users without JavaScript that they needed to upgrade.
6. Users were not only able to print, but were encouraged to do so.
7. No unique/difficult-to-remember IDs that could get lost and prevent a document from opening. Username & password is something everyone understands and remembers.

The end decision, as the article pointed out, was to use Acrobat's built-in JavaScript & Forms capability. It allowed us to answer all of the above goals in a way which allowed everyone, whether technically savvy or not, to easily use the eMatter they had purchased.

A quick answer to the three security points oulined in the article:

* As noted, trying to hide the JavaScript became pointless when Acrobat 5.0 came out. We built and shipped this incarnation of eMatter as Acrobat 5 was in final beta.
* We didn't want to require Acrobat 5 (or even 4, for that matter) to support digital signatures. Harnessing the huge installed base of Acrobat 3.01+ was a key business decision.
* Obfuscating the JavaScript code was on the tasklist for future revisions, but again, our core focus was on usability, rather than security. Security precautions were a secondary concern.

Designing the system

An analogy we used often during development was that of car door locks. A determined thief would be able to get into any car door through numerous means. All car door locks really do is prevent your average everyday person from violating your car's security and stealing your sunglasses. But it doesn't get in the way of your use of the car.

Most DRM implementations these days are so heavy-handed with their security precautions, they prevent even honest users from enjoying their purchases. And the determined, experienced, and techincal people will always be able to break a given DRM if the incentive is there. Most DRMs provide loads of incentive to break them: you can't use them on two or more devices you own, you can't print your purchases, etc.

Maybe if more companies were willing to acknowledge the obvious and just work on car door-type locks, digital distribution of content would really catch on.

Don MacAskill
Ex-R&D Manager,
MightyWords Inc.

More Info

* Sklyarov Examines Security Behind MightyWords eMatter, Planet eBook, February 19, 2002
* onethumb.com

Designing More User-friendly DRM
MightyWords Ex-R&D Manager Don MacAskill talks about the Security Design Behind eMatter

By Don MacAskill
March 7, 2002

I really enjoyed your technical analysis of MightyWords' eMatter security . As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. I was turned on to the article by Brian Scardina, another core engineer on the project, who also agrees with the analysis.

I should note that exposing the eMatter downloads to anyone and everyone was by design: customers were encouraged to email their purchased eMatter documents to friends. Sharing was a core business concept that we tried to foster.

A little background about our decisions and why we made them

As the article mentions, we made a tough decision: lower security in exchange for a better user experience. From the outset, we had a clear set of goals:

1. A user only has to unlock it once. If possible, pre-unlock it for them during the purchase process.
2. Cross-platform (Windows, Mac, and any flavor of Unix we could)
3. Useable across all devices a user possessed - desktops, laptops, and, we hoped, eventually handhelds, no extra purchase required for each device.
4. No additional downloads (plugins, etc)
5. Acrobat 3.01 with JavaScript (not the then-new 5.0 or the myriad of confusing 4.0x releases) as the lowest required version, with at least the ability to inform Acrobat 3.0 users without JavaScript that they needed to upgrade.
6. Users were not only able to print, but were encouraged to do so.
7. No unique/difficult-to-remember IDs that could get lost and prevent a document from opening. Username & password is something everyone understands and remembers.

The end decision, as the article pointed out, was to use Acrobat's built-in JavaScript & Forms capability. It allowed us to answer all of the above goals in a way which allowed everyone, whether technically savvy or not, to easily use the eMatter they had purchased.

A quick answer to the three security points oulined in the article:

* As noted, trying to hide the JavaScript became pointless when Acrobat 5.0 came out. We built and shipped this incarnation of eMatter as Acrobat 5 was in final beta.
* We didn't want to require Acrobat 5 (or even 4, for that matter) to support digital signatures. Harnessing the huge installed base of Acrobat 3.01+ was a key business decision.
* Obfuscating the JavaScript code was on the tasklist for future revisions, but again, our core focus was on usability, rather than security. Security precautions were a secondary concern.

Designing the system

An analogy we used often during development was that of car door locks. A determined thief would be able to get into any car door through numerous means. All car door locks really do is prevent your average everyday person from violating your car's security and stealing your sunglasses. But it doesn't get in the way of your use of the car.

Most DRM implementations these days are so heavy-handed with their security precautions, they prevent even honest users from enjoying their purchases. And the determined, experienced, and techincal people will always be able to break a given DRM if the incentive is there. Most DRMs provide loads of incentive to break them: you can't use them on two or more devices you own, you can't print your purchases, etc.

Maybe if more companies were willing to acknowledge the obvious and just work on car door-type locks, digital distribution of content would really catch on.

Don MacAskill
Ex-R&D Manager,
MightyWords Inc.

More Info

* Sklyarov Examines Security Behind MightyWords eMatter, Planet eBook, February 19, 2002
* onethumb.com

As it turns out, a *very* succesful game developer started in exactly the same way. I wasn't personally involved, though I do have some friends who work there, so this is what I've been told was the situation:

A guy by the name of Tony Goodman had a consulting firm that was doing quite well out in Dallas. They had some strong ties to Microsoft, as I understand it, and did a lot of consulting with regards to their products for businesses. Tony and some of his guys one day decided to make games, and cooked up this great idea.

It became Ensemble Studios, and that game was Age of Empires. They've just recently (in the last month or so) been acquired by Microsoft, and each of their games were run-away million+ unit sellers.

Just like most industries, a lot of initial success is based on who you know. Ensemble had a great idea and a grea team, true, but it was also just as key that they had a strong relationship with Microsoft to begin with. That got them in the door and allowed their great team to strut their stuff.

I'm sure they, as most startup development houses do, created a quickie game concept demo and showed their buddies at Microsoft. Microsoft then decided to pony up an advance to get them to their first milestone and evaluate their progress. Obviously, it went well, so a long-term contract and milestone schedule was established, and a hit was born.

The best advice I can give you is to try to make some contacts in the industry. Game developers are very easy to get to know (and great people), but they often don't have the pull needed to get a fully-funded game off the ground. Game publishers are who you really want to get chummy with, though game developers can probably make the introductions. Coupled with a great demo (and, by extension, team) and a good introduction, you can't go wrong.

Hope that helps!


Don MacAskill
My geek site