Chris Sherlock has filed a bug against Firefox in Mozilla's bugzilla bug-tracker, entitled "Pledge never to implement HTML5 DRM." It's an interesting way of using the open/transparent development protest to allow Web developers to voice their opinion on the World Wide Web's terrible, awful decision to standardize DRM for browsers. As the W3C's overseer for HTML5 has written, the only reason for DRM in HTML5 is to prevent legal innovation, not to stop piracy.

Here's the bad news: the World Wide Web Consortium is going ahead with its plan to add DRM to HTML5, setting the stage for browsers that are designed to disobey their owners and to keep secrets from them so they can't be forced to do as they're told. Here's the (much) worse news: the decision to go forward with the project of standardizing DRM for the Web came from Tim Berners-Lee himself, who seems to have bought into the lie that Hollywood will abandon the Web and move somewhere else (AOL?) if they don't get to redesign the open Internet to suit their latest profit-maximization scheme.

Danny O'Brien from the Electronic Frontier Foundation explains the wrangle at the W3C and predicts that, now that it's kosher to contemplate locking up browsers against their owners, we'll see every kind of control-freakery come out of the woodwork, from flags that prevent "View Source" to restricting embedded fonts to preventing image downloading to Javascript that you can't save and run offline. Indeed, some of this stuff is already underway at W3C, spurred into existence by a huge shift in the Web from open platform to a place where DRM-hobbled browsers are "in-scope" for the WC3.

I've written before here about the move to get the World Wide Web consortium (W3C) to cram digital rights management (DRM) into the next version of HTML, called HTML5. This week, EFF filed a formal objection with the group, setting out some of the risks to the open Web from standardizing DRM in the Web's core technical specs.
Now, writing in the Guardian, W3C staffer Dr Harry Halpin makes an important, well-thought-through case for keeping DRM out of the HTML5 standard. Haplin's got an invaluable insider view of the "crisis of representation" that let a few giant companies shift the most open, most vital standards body involved with the Web into the position of standardizing ways to have your computer and browser take control away from you, and to set the stage for a ban on free and open source software in Web browsers and computers.

The most important part is what you can do to help shift the direction of the W3C back towards the open Web:

The Advisory Committee of the W3C is composed of companies as well as universities and non-profits. If your employer is a W3C member, now is the time to open the discussion internally with your management. Questions over whether DRM should be part of the HTML Working Group or part of another Working Group - or outside of W3C entirely! - are dealt with in the review of charters by Advisory Committee representatives. It's at this level that the EFF objected to EME in HTML. If your organisation is not a member, your organisation can join the W3C. W3C membership fees have been adapted to organisations large and small, for-profit and non-profit, start-ups, and for organisations in developing countries.

If you work for a W3C member, now is the time to join the HTML Working Group. The HTML Working Group are working through the technical details of Encrypted Media Extensions in the HTML Working Group Media Task Force. Also, the HTML WG has a very liberal Invited Expert policy to allow participation by those domain experts who don't work for W3C member organisations. Questions and objections that go beyond the technical content and charter are generally considered out of scope.

Questions that go beyond technically working on EME should be aimed at the Restricted Media Community Group, which anyone can join. Unlike Working Groups, W3C Community Groups provide a forum for discussion but do not themselves publish standards. Disappointingly, so far the discussion has been pretty weak, but this Community Group is monitored by many people deeply involved in the DRM debates.

Also, W3C Working Groups such as the HTML Working Group take technical comments from anyone on the entire web. Public comments can be made by ordinary users; the Working Group must formally address these comments if the comment is within the scope of the charter and done before the standard is complete. That means you can in public comment on EME or any other standard like the cryptographic primitives as pursued by the Web Cryptography Working Group, which can be used to exchange private messages between human rights activists as well as be part of Netflix's plan to switch to HTML5.

My latest Guardian column is "What I wish Tim Berners-Lee understood about DRM," a response to the Web inventor's remarks about DRM during the Q&A at his SXSW talk last week.

Additionally, all DRM licence agreements come with a set of "robustness" rules that require manufacturers to design their equipment so that owners can't see what they're doing or modify them. That's to prevent device owners from reconfiguring their property to do forbidden things ("save to disk"), or ignore mandatory things ("check for regions").

Adding DRM to the HTML standard will have far-reaching effects that are incompatible with the W3C's most important policies, and with Berners-Lee's deeply held principles.

For example, the W3C has led the world's standards bodies in insisting that its standards are not encumbered by patents. Where W3C members hold patents that cover some part of a standard, they must promise to license them to all comers without burdensome conditions. But DRM requires patents or other licensable elements, for the sole purpose of adding burdensome conditions to browsers.

The first of these conditions – "robustness" against end-user modification – is a blanket ban on all free/open source software (free/open source software, by definition, can be modified by its users). That means that the two most popular browser technologies on the Web – WebKit (used in Chrome and Safari) and Gecko (used in Firefox and related browsers) – would be legally prohibited from implementing whatever "standard" the W3C emerges.