Future versions of the open-source Firefox browser will include closed-source digital rights management (DRM) from Adobe, the Mozilla project’s chief technology officer, Andreas Gal, announced on Wednesday.
The purpose is to support commercial video streams. But this is a radical, disheartening development in the history of the organisation, long held out as a beacon for the open, free spirit of the web as a tool for liberation.
As Gal’s blogpost makes clear, this move was done without much enthusiasm, out of a fear that Firefox (Mozilla’s flagship product and by far the most popular free/open browser in the world) was being sidelined by Apple, Google and Microsoft’s inclusion of proprietary technology to support Netflix and other DRM-encumbered videos in their browsers.
In my long-running discussions with Mozilla’s most senior management over this issue, they’ve been clear in their belief that their userbase – and relevance to the internet – will dwindle unless they add support for viewing Hollywood movies in their browser. Not just Hollywood; the BBC has been one of the major “rights holder” voices calling for the addition of DRM to the web.
This shift is part of a change in the way that browsers work in general. Since the early days of the Netscape browser, third-party plug-ins have been a common way to extend browser functionality. Users who wanted to watch DRM-restricted video could install proprietary plugins such as Microsoft’s Silverlight or Adobe’s Flash.
The plug-in architecture is a security nightmare, and a source of numerous breaches through which buggy or malicious code was able to reach into users’ computers and compromise them. Now that browsers run in computers that we carry around in our pockets, connected to microphones and video cameras, and manage everything from our finance to our thermostats, abolishing plug-ins was an inevitable and welcome step.
Plugged back in
However, in the absence of plug-ins, the proprietary browser companies have privately negotiated with Netflix to add DRM. This shift to private negotiations – instead of industry-wide standards – spooked the World Wide Web Consortium (W3C) and its founder, web inventor Tim Berners-Lee, into a controversial plan to add DRM to HTML5, the next-generation web standard.
The W3C’s solution is baroque: it is specifying something called “encrypted media extensions” through which the browser creates a “sandbox” within which a “content decryption module” (CDM) operates, receiving scrambled video, descrambling it and passing it out of the sandbox for display.
At times, the W3C has insisted that this isn’t really DRM – it’s a thing that can be used for DRM. The fact that it was conceived in order to respond to demand for DRM from companies that insist on DRM for their business-models, and that its deployment and use is entirely concerned with DRM, makes this a pretty thin excuse.
The fear of irrelevance that drove Mozilla to add DRM is a microcosm of the fear of irrelevance that drove the W3C to standardise DRM. By the same token, Mozilla’s roundabout description of its DRM plan also echoes some of the W3C’s not-really-DRM claims.
Mozilla says it isn’t providing DRM; it’s providing a fully open utility that automatically fetches and installs DRM from Adobe’s servers. I am unconvinced that there is a meaningful distinction between “installing DRM” and “installing code that installs DRM”.
Still, Mozilla has taken some admirable pains to minimise the harms from its DRM. The open sandbox in which Adobe’s software operates very strictly limits the DRM’s access to the computer’s other processes and systems. This is crucial, because the Adobe module is not only closed source, it is also protected by controversial global laws that threaten security researchers who publish information about its security flaws.
These laws – the US Digital Millennium Copyright Act, the European EUCD, Canada’s C-11 and so on – prohibit revealing information that can be used to weaken DRM, and previous security researchers who disclosed information about vulnerabilities in DRM have been threatened and prosecuted.
This created a chilling effect on the publication of vulnerabilities in DRM, even where these put users at risk from hackers. For example, when word got out that Sony BMG had infected millions of computers with an illegal rootkit to stop (legal) audio CD ripping, security researchers stepped forward to disclose that they’d known about the rootkit but had been afraid to say anything about it.
This gap between discovery and disclosure allowed the Sony rootkit to become a global pandemic that infected hundreds of thousands of US military and government networks. Virus writers used the Sony rootkit to cloak their own software and attack vulnerable systems.
The inclusion of Adobe’s DRM in Firefox means that Mozilla will be putting millions of its users in a position where they are running code whose bugs are illegal to report. So it’s very important that this code be as isolated as possible.
By open-sourcing the sandbox that limits the Adobe software’s access to the system, Mozilla is making it auditable and verifiable. This is a much better deal than users will get out of any of the rival browsers, like Safari, Chrome and Internet Explorer, and it is a meaningful and substantial difference.
Unhappy turn
It’s clear that Mozilla isn’t happy about this turn of events, and in our conversations, people there characterised it as something they’d been driven to by the entertainment companies and the complicity of the commercial browser vendors, who have enthusiastically sold out their users’ integrity and security.
Mitchell Baker, the executive chairwoman of the Mozilla Foundation and Mozilla Corporation, told me that “this is not a happy day for the web” and “it’s not in line with the values that we’re trying to build. This does not match our value set.”
But both she and Gal were adamant that they felt that they had no choice but to add DRM if they were going to continue Mozilla’s overall mission of keeping the web free and open.
I am sceptical about this claim. I don't doubt that it’s sincerely made, but I found the case for it weak. When I pressed Gal for evidence that without Netflix Firefox users would switch away, he cited the huge volume of internet traffic generated by Netflix streams.
There's no question that Netflix video and other video streams account for an appreciable slice of the internet’s overall traffic. But video streams are also the bulkiest files to transfer. That video streams use a lot of bytes isn't a surprise.
When a charitable nonprofit like Mozilla makes a shift as substantial as this one – installing closed-source software designed to treat computer users as untrusted adversaries – you’d expect there to be a data-driven research story behind it, meticulously documenting the proposition that without DRM irrelevance is inevitable. The large number of bytes being shifted by Netflix is a poor proxy for that detailed picture.
There are other ways in which Mozilla’s DRM is better for user freedom than its commercial competitors’. While the commercial browsers’ DRM assigns unique identifiers to users that can be used to spy on viewing habits across multiple video providers and sessions, the Mozilla DRM uses different identifiers for different services.
And unlike the commercial browsers’ DRM, the Mozilla implementation does not intentionally leak any information about the user’s system or its configuration to video services.
The Mozilla DRM is a very neat illustration of the difference between “free” and “open”, a distinction that often seems abstract to the point of meaninglessness for most people.
Mozilla’s open-source sandbox can be examined and compiled by users who have access to its source code. It is fully transparent and “open” to them.
But if users modify the sandbox in any way – if they add new features or improvements to it – the Adobe plug-in can detect the alteration and it will refuse to pass any more decoded video. The Mozilla sandbox comes with total openness, but without any of the freedoms that the free software movement cherishes.
How the Adobe module validates the sandbox is a mystery – a proprietary technique whose workings are illegal to report, thanks to the same laws that ban reporting vulnerabilities in DRM.
I was surprised to learn that there was a GNU/Linux version of Adobe’s module that will work with Firefox on systems running Ubuntu, Red Hat and related operating systems.
This seems unlikely to work very well: whatever techniques the module is using to assure itself that the sandbox is behaving as expected ultimately depend on it asking the operating system questions about the sandbox (“is the sandbox running as a process that can’t access the hard drive?”).
A user who can modify her operating system can easily get it to lie to the Adobe software – we do this all the time, such as when a cheap digital recorder pretends to be a mass storage device to your computer so that it can access its stored recordings.
The Mozilla Project has been one of the internet’s most hopeful success stories, and the people who do Mozilla’s good works have been personal heroes of mine for more than a decade.
The decision to produce systems that treat internet users as untrusted adversaries to be controlled by their computers was clearly taken out of a sense of desperation and inevitability.
It’s clear that Mozilla plans to do everything it can to mitigate the harms from its DRM strategy and to attempt to reverse the trend that brought it to this pass.
Like many of Mozilla’s longtime supporters, I hold it to a high standard. It is not a for-profit. It’s a social enterprise with a mission to empower and free its users.
I understand that Apple, Microsoft and Google are for-profit entities that have demonstrated repeatedly that their profitability trumps their customers’ rights, and I fault them for this. But it’s not unreasonable to hold mission-driven nonprofits to a higher standard than their commercial counterparts.
Mozilla says it’s doing everything it can to reduce the harm from what it sees as an inevitable decision. As a Mozilla supporter, contributor and user, I want it to do more. Here are some practical things that Mozilla can do to help:
1 Protect security researchers
Mozilla has demonstrated that it has some negotiating leverage with Adobe – after all, it was able to fend off the demand for details of users’ systems to be leaked to video companies.
It should demand that Adobe give it a covenant not to sue or threaten developers who report vulnerabilities in the Adobe decoder. Adobe does not need to give up the right to sue people who release cracks for their DRM or competing products in order to do this.
In an era in which vulnerabilities are leveraged to expose users to identity theft, sexual exploitation and government surveillance, no one should fear legal reprisal for warning people about flaws in the software they use.
Mozilla’s competitors don't offer this protection to developers. They should. Mozilla can shame them for not doing so, and be the leader we want it to be.
2 Educate users
Mozilla has a brilliant, far-reaching technology literacy programme that teaches users how to be makers and programmers and how to be safe and private on the Web.
Mozilla should develop a curriculum about the way that DRM undermines security by making vulnerability reporting illegal and treating users as hostile adversaries.
And it should teach would-be makers that DRM only allows you to be a passive viewer and not a tinkerer, because if you change the “open” decoder, it stops working.
3 Research and publish the case for DRM
With both the W3C and Mozilla ready to add DRM in order to preserve their relevance in the face of Netflix, Hulu, BBC iPlayer and Amazon Video, we need some actual data on how users view these service and to what precise extent the lack of in-built DRM support is enough to drive away users.
If Mozilla wants its supporters to accept that irrelevance was the inevitable alternative to DRM, it should have the data to back that up. We can use that data to inform anti-DRM strategies.
4 Formulate and articulate a DRM policy
There are lots of industries that want the W3C to standardise DRM for them, too.
The ebook people have asked for a W3C standard to lock up formatted text – basically, webpages – and I wouldn't be surprised to see paywall sites and others converging on this.
Gal told me he didn’t think that users would accept DRM for text in the same way that they’ve accepted DRM for video, pointing out that most text is not DRMed.
However, nearly all the video on the web today is DRM-free – YouTube users alone post 96 hours’ worth of DRM-free video every minute.
It’s only a small slice of “premium” video that is locked up with DRM, in the same way that only a small slice of text – commercial books, paywalled newspapers – would likely be DRMed if the ebook people get their W3C DRM.
The promulgation of DRM video on the web is the beginning, not the end. If Mozilla wants long-term support from its stakeholders, it can’t make decisions about future DRM fights on an ad hoc basis.
We need a statement of principles that explains when DRM is the right answer – it’s certainly a debate I’d relish participating in.
Mozilla won’t comment on whether its forthcoming Firefox OS for mobile devices will be born with DRM, and that's an ominous sign for those of us who were hoping for a free/open alternative to the existing mobile infrastructure, which is basically a global surveillance system that allows us to make the occasional phone call.
Like many of Mozilla’s supporters – and like many of the Mozillans I know and respect – I am devastated by this turn of events. The free and open web needs an entity like Mozilla to stand on principle, especially when the commercial internet world so manifestly stands on nothing but profits.
I fully accept that Baker and Gal have taken this decision reluctantly and unhappily. I disagree with their rationale, but I understand it. And I accept that they have gone to enormous lengths to devise a DRM with as few harms as possible.
But there is more that Mozilla can do, and should do, even if they’re wrong that DRM is the only way – and especially if they’re right.
Comments (…)
Sign in or create your Guardian account to join the discussion