DRM in HTML5

Many people have doubts regarding how can possibly be an issue of having DRM on HTML, the foundation language of the entire web. One person in particular had the doubt of "how can it be possible that DRM (closed by its nature) is inserted into a standard?"

I have replied to her about it (in Portuguese), but I think that, with some adaptations and a translation, this text might also have a wider use for those of you trying to understand HTML, standards and DRM. Oh, and don't forget, click on the image in the right to sign a petition against DRM on HTML.

The "short answer"

You should attend to the Document Freedom Day 2013 celebration event nearer to you: they're happening starting today until April all around the world. There, I'm sure, there will be people knowing and willing to explain to you any questions regarding open standards in general and the "DRM in HTML" issue in particular.

The "long answer"

A standard should be considered open if it complies with a number of requisites. Here's the list (taken from this page, that explains each point better):

An Open Standard refers to a format or protocol that is:

• Subject to full public assessment and use without constraints in a manner equally available to all parties;
• Without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;
• Free from legal or technical clauses that limit its utilisation by any party or in any business model;
• Managed and further developed independently of any single supplier in a process open to the equal participation of competitors and third parties;
• Available in multiple complete implementations by competing suppliers, or as a complete implementation equally available to all parties.

Unfortunately not every format is an open standard, or, in other words, doesn't comply with the previous points. If the proposal to have DRM on HTML5 is accepted, HTML will stop being an open standard, since it will stop complying with the second requirement of the list.

In more detail: the proposal on the table is called EME (Encrypted Media Extensions). An HTML document can include EMEs, and the specification of EME enables the website to require a certain "Content Decryption Module" (CDM). And here lies the problem: CDMs aren't standards (much less open standards!) and the EME specification doesn't include or refer to any specification of any CDM. In other words: the definition of open standard we just saw isn't complied, because to implement HTML5 we have to implement EME, which has to accept any CDM, which isn't a standard and so we cannot implement.

In other words, with an example: I make a website, and put there a media object (video, for instance) using EME, and I specify in the HTML document that the EME object needs the CDM module (which is a form of DRM) called "OneTwoThree". Now, if you want to see that website, you need a web browser that knows how to undertand HTML5 and EME (both possible since there's the specification), and the browser then needs to get the CDM called "OneTwoThree" (imagine it as being a browser plugin, not unlike Flash) and use it to play the video. The problems are obvious now: what if the CDM only exists for one specific Operating System? What if the CDM isn't free? You know... the thypical problems of a non-open standard format.

The broken Web

I have several computers, almost all of the time I'm using one (or several) or three: an HP laptop that with a 1024x768 resolution, the EEE PC 701 with a 800x480 resolution, and finally my BlackBerry 8100 and its way smaller screen. I use them to do everything I use computers for, including surfing the web. The experience is far from perfect, and here are some reasons why:

The web is about content, not displays

Please stop that really old mantra of "nobody uses 1024x768 anymore". I've been listening to that for a while, even if the biggest resolution I have on this three devices is exactly that one. Also, the argument isn't new: I remember at least the "nobody uses 640x480" and the "nobody uses 600x800" arguments, and I'm pretty sure that the thing didn't start there, but in other arguments like "nobody sees only 80 columns anymore". The biggest mistake here isn't to think that nobody uses 1024 while I still do. Nor trying to predict the smallest resolution out there. The mistake here is that the web is about content, not displays. Regardless of what you might think or want, a website is meant to be read by whoever crosses with it, using whatever device he's using. Your website must be visible, readable and usable by every device, with every resolution. It's not hard, and it doesn't mean you should ditch planning your website layout and make it into your CSS files. On the contrary, it means that you should treat content as content and put it in the document layer, presentation as presentation and put it in the presentation layer. But it also means that your presentation can't be made in a "if users are reading this in a 1024 screen", or "if users are reading this in a mobile device", but instead, "if users are reading a paragraph", "if users are reading a caption"...

One Web

Like I said in the previous item, your website should be platform-agnostic. But that doesn't only mean that I should read your website well in every resolution, it means that I should be able to read your website with every browser, in every device. One web, several ways of reaching it. So, remember this next time you're thinking about making a mobile version of your website: if you're planning on do it, you already did it wrong. See, your website should be readable everywhere. That means that if your website is well made, I can read it well in my mobile device without the need of going to a mobile version of it. On the other hand, if you're making me go to another website -- a mobile version -- you're not only stopping me of seeing the website I want to see, giving me a trimmed-down version of the real thing, you're actually making me see another webiste, with all the implications that might have. Remember, if your website doesn't look good in a mobile device in the first place, you already did something wrong...

The Web is The Web

The Web is The Web: nothing more. It's made of standards, composed by a set of documents written in a certain language. You have HTML, XHTML, CSS, Javascript, several formats for images and other objects... and that's it. The Web is just that. The web isn't made of "plugins" or "third-party applications". The web is made to be seen by a browser - any browser. So remember: if you have, for instance, flash in your website, the content must be 100% acessible by a browser without a Flash plugin. I'm serious: it's not my fault if I can't see your website in my mobile phone just because it full of flash. You chose to use a plugin that isn't available to every browser, in every platform, so you have to give an alternative for those visiting your website without that plugin. Oh, and spare me that "you don't have flash, get it here" messages, because you're just making me doing a couple of steps and going to another website where they'll tell me "your platform isn't supported". It's not my fault as a web user, and it's not their fault as a plugin provider: it's your fault as a content publisher.

What else?

There are tons of other things in the web that makes it as broken as it nowadays is. But for now, please think about this three. I bet that with those solved, my web experience would get a lot better.

The Beauty in Standards

( HTML + CSS + DOM and JavaScript ) = beauty web

Never mixup any of those layers... Never do stuff like
<a href="javascript:...">
or
<a href="#" onclick="...">

Now, with Ajax... You should use "Hijax", his recently created buzword. It's basicly adding one more layer to the "old" HTML+CSS+DOM&JS model, making it Hijax = HTML -> CSS -> DOM + JS -> Ajax. Basicly, you hijack the requests and use AJAX...

OK, now he said for the first time something I don't agree (twice in a row): first he said that something that fallpits in the definition of "web chat" (he was talking about Meebo or any web IM) can't degrade gracefully (meaning that you couldn't do a chat app without AJAX). Not only I disagree, I can even give an example: HCL uses Aardvark, which means that if you are AJAX-enabled you do it AJAX-style, but if you're not AJAX-enabled you'll still be able to use it. Second, he said that in those cases people should use something like Flash... But if you do it you're excluding people then you're doing something broken (as he said himself).

...

OK, I said it on the microphone. He basicly agrees with me, but gives me another example: video-editing. The thing is... if you're doing that kind of app, why do it an webapp? It's useless as an webapp! Is it the "you don't need to install or update" thingie? 'cause if it is, you can actually do it without using a web browser.

Bug 245609 – Mozilla not getting certificate issuer from Authority Information Access CA Issuers

Some people alerted me on a "bug bounty" for Firefox (even if the issue is with Mozilla Core and not on Firefox): the Portuguese Ministry of Justice will pay a 1000 Euro reward for those who fix this "bug". What's the catch?

Well, first of all, this is not a bug. It is correctly tagged as a RESOLVED as INVALID enhancement, and it is. It could be, if anyone cares to do so, a VALID enhancement, simply by changing the context: something like "there's nothing that can happen wrong if we emulate the behaviour of the other browsers, and it would be better for users", explained, would suffice.

Now, the problem is that the message that announces the bounty says:

But somehow that doesnt seem enough to justify the problem.
First because it seems really stupid for Firefox not to
implement something that all other browsers implement and just
saying "lets wait till the standard is clear".
Second because its not a solution if you just say "reconfigure
the server and make sure that the intermediate certificate is
served". The other browsers dont need that.
Third because even if you install the certificates locally
in your browser, the problem continues. It seems to be
related to a possible problem with comparisons of fields
encoded in UTF-8 in one certificate and encoded in quoted
printable in others.

Well, if you're trying to convince those who maintain a piece of software that they should implement an enhancement, you shouldn't start by calling the actual behaviour as "really stupid", specially when that behaviour is RFC compliant, thus not a bug. Then, the problem, as described in the bug page, isnt that "the standard isn't clear": if you actually read the RFC's, you'll see that the https server has the obligation to send a complete certificate chain.

Now, IMHO the target should be "have the issue properly solved", so, since the issue is that, by RFC, the https server must do something that isn't doing nowadays, then having a "bug bounty" over Firefox isn't helping. If the target is to have Firefox with the same behaviour as the other browsers, then it would be nice to have a proper enhancement request submitted and aprooved, and only after that a "patch bounty" for an implementation of the solution. I could do some more work on this issue - heck, I could even go after that bounty. Presented the way it is, I'm just not interested: seems to me that the solution proposed is ignoring the fact that the target website is broken since it is not complying with the standards involved. Supporting a broken web by changing the behaviour of one web browser is plain blindness, specially because you can't garantee that (1) every browser acts the same way, and (2) in five years you have a major browser out there that implements everything well but still does not support broken cert chains.


Useful links:
http://www.ietf.org/rfc/rfc2246.txt;
http://www.ietf.org/rfc/rfc2459.txt;
http://www.ietf.org/rfc/rfc3280.txt;
http://www.ietf.org/rfc/rfc4346.txt;
http://tools.ietf.org/id/draft-ietf-tls-ssl-version3-00;
http://www.ietf.org/html.charters/tls-charter.html.


From RFC 4346:

certificate_list
   This is a sequence (chain) of X.509v3 certificates.  The sender's
   certificate must come first in the list.  Each following
   certificate must directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority may optionally be omitted from the chain,
   under the assumption that the remote end must already possess it
   in order to validate it in any case.