Another follow-up to my thinking experiment about Sun’s Open Source DRM effort — Cory Doctorow in BoingBoing, reacting on a ZDNet blog entry:
[…] The gimmick is that Sun’s technology has to be run as signed code on trusted computing hardware, which means that while you can see the code, you can’t change it, improve it, or build on it.
Once you have code you can’t modify on hardware you can’t access, “open source” can’t be meaningfully used to describe a project. […]
Sun’s project doesn’t subvert DRM, it subverts open source. It complies — barely — with the letter of older OSS definitions, while gutting their spirit. […]
In other words, DReaM is absolutely not as “open” as Sun claims it to be. This doesn’t come as a surprise, though – an “open” DRM architecture is simply impossible.
Sun’s DRM plans are in the news again. A quick overview:
During the last couple of weeks, Sun has released the DReaM source code and related specs. Note that the dev space mentions “Updates to VLC for DreaMCAS Client”. I suppose they’re talking about the VLC player.
On March 21, Sun has organized an Open Media Commons workshop – interestingly, its press release features a quote by Lawrence Lessig:
“In a world where DRM has become ubiquitous, we need to ensure that the ecology for creativity is bolstered, not stifled, by technology. We applaud Sun’s efforts to rally the community around the development of open-source, royalty-free DRM standards that support “fair use” and that don’t block the development of Creative Commons ideals.”
Two days later, Lessig posted this on his blog:
[S]ome confuse praise for better DRM with praise for DRM. So let me be as clear as possible here (though saying the same thing I’ve always said): We should be building a DRM-free world. […] But just as one can hate the Sonny Bono Act, but think, if there’s a Sonny Bono Act, there should also be a Public Domain Enhancement Act, so too can one hate DRM, but think that if there’s DRM, it should be at least as Sun is saying it should be.
I still don’t understand how an Open Source DRM can possibly work – posted a comment about that on Lessig’s blog.
And apparently, I’m not alone – from a comment on a related Slashdot article:
As a separate issue, how would an Open Source DRM system work? If I’m able to decrypt a file once, I’m able to save it in an unencumbered format. It’s fundamentally different than encryption; PGP, for example, isn’t designed to prevent you from posting every email you get to a web page. Current schemes assume that the recipient of the keys can be trusted to use them for only the intended purpose. This seems to be based on an assumption that a hacker can’t see the code or key (because they’re using a microcontroller that has a hardware Code Protect feature), that a network protocol can’t be emulated (for cases where a key must be retrieved from a server), or that it’s too much of a pain to bother (presumably what Windows Media and Fairplay must do). These are all essentially security through obscurity, and I don’t see how that can work in an Open Source environment.
Also: a Wired article with a silly title, Reasons to Love Open-Source DRM, featuring an even sillier quote/statement:
As [Tom] Jacobs [= project lead of the Open Media Commons] pointed out to me, it was once necessary to code web pages for multiple browsers, before standards were put in place that allowed them to be coded only once. If Sun’s DReaM comes true, the same could happen for protected music.
On January 1st, Danah Boyd wrote an interesting entry about teenagers’ ephemeral online profiles. A quote:
Teens are not dreaming of portability (like so many adults i meet). They are happy to make new accounts on new sites; they enjoy building out profiles. (Part of this could be that they have a lot more time on their hands.) The idea of taking MySpace material to Facebook when they transition is completely foreign. They’re going to a new site, they want to start over.
This got me thinking — can this idea also be applied on Japanese teenagers and their mobile download behavior? Could it be, for instance, that the importance of content portability between different devices is overstated, and that most people don’t really care about whether the stuff they download to their phone is DRMed or not? Maybe the mobile ringtones/-tunes, wallpapers, screensavers, menus, games and apps (almost all of them DRMed) that people download are perceived as a sort of throwaway personalization building blocks, and not so much as “purchased media” one ought to be able to play on different devices. This would mean that every time you buy a new phone, you start all over again collecting the right music, graphics, etc. — rebuilding your mobile identity(*), if you will. And yes, that is exactly what most Japanese cell phone owners seem to be doing with every new phone they own.
I would like to point out that the paragraphs above don’t change my stance towards DRM (I still think it’s a bad idea) — I am only searching for an explanation of the ever rising mobile downloads, and Japanese customers’ apparent indifference towards mobile DRM and its impact on cross-device portability (let alone on fair use, etc).
What do you think? Thoughts, additions?
(*) The difference with a profile on a social networking site is of course that the mobile identity building mentioned above isn’t really visible to the outside world (except for people seeing your mobile phone screen). However, judging from the number of digital and real world keitai mods that are available nowadays, I think it’s safe to say that purchasing GUI enhancements, wallpapers, ringtones, etc. is more about personal customization and mobile identity, than about building a full-fledged media library (as you’d do on your computer).
I’ve moved my blog from the hard-to-remember akira.arts.kuleuven.ac.be/andreas/blog/ to a new location with a snappy URI: chosaq.net is Chosaq’s new home. Links to the old site (incl. Atom/RSS feed subscriptions) should be redirected to the according chosaq.net pages
, but at this point the akira server is down, resulting in 404 errors—and less people finding this site. This should be fixed soon though.
My new host is DreamHost, which I have been using for over a year for a Subversion mirror of my HD and for some other smaller projects. (If you want to sign up for Dreamhost’s amazing L1 plan with one-year pre-payment, use the promo code CHOSAQ and pay 70$ instead of 119.40$ for the first year! And yes, I’ll also get a cut if you sign up ;-) )
And of course, a big tip of the hat to Hans Coppens, who has graciously offered to host the various incarnations of my site on the Japanese Studies server since 1999. Time flies.
Back in August, Sun announced it would start with an open source DRM project, confusingly dubbed “Open Media Commons”. The EFF’s Cory Doctorow and Donna Wentworth both pointed out the logical impossibility of the OSS+DRM combo. An interesting quote from Cory’s follow-up post about the issue:
Crypto isn’t about algorithms. Crypto is about threat-models. The threat model for SSL is a third-party eavesdropper. The threat model for DRM is that the intended recipient of the cleartext will gain long-term access to the cleartext.
In the meantime, the Open Media Commons website has gone live (that is, I hadn’t seen it until yesterday), featuring a press release paper about Sun’s own “open standards-based DRM solution”, called DReaM. I had a look at the document, but didn’t quite get what they’re at. Section 1.8 “Security through obscurity” states:
Historically, proprietary end-to-end architectures have relied upon obscurity to avoid being cracked. Such systems are based upon a false foundation of security promises. Such systems have been cracked and will continue to be breached.
That’s correct, but how can Sun’s DRM be any different? The problem with DRM is that it’s built around flawed threat model (cfr. Doctorow) – in any DRM system, recipient Bob and hacker Mallory are one and the same person, making DRM fundamentally different from SSL (although Sun doesn’t seem to think so). In other words, the only way to “secure” a DRM system is by obscuring how you descramble the encoded signal to a more enjoyable form – an approach that, as we know, is prone to hacking.
Applying this on DReaM’s alleged open source aspect, the conclusion is simple: if security can only happen through obscurity, open sourcing the project becomes an impossibility.
Note 1: Prof. Lenz believes open source DRM is possible, but I don’t agree: excluding people who contribute DRM-defeating code to the project may be easy, but nothing (except the law, maybe) stops them from using the project’s source code for creating their own circumvention tools. In other words, you can create an open source DRM, but it will be meaningless, as it will be hacked even faster than closed source DRM systems.
Note 2: as if the words “open” and “commons” aren’t confusing enough (we’re talking about DRM here!), the Open Media Commons frontpage’s “related links” section also links to Creative Commons, making it feel like an affiliate project or something (which I’m sure it’s not). Disturbing.