The goal seems to be to reduce the spread of DRM. I'm cool with that. However, I'm not sure that these actions will do anything at all to reduce the usage of DRM. My reasoning there is that those who want to use DRM are not going to accept any alternative that is not DRMd. So in order to stop spread of DRM, keeping DRM non-standardized would have to prevent others from adopting DRM.

So the ultimate question for me is: who's going to start using DRM that's not already? I think this set is zero. Adding standardization of DRM won't close up any more content that wasn't closed before, IMHO.

However, by not standardizing, we lock out all sorts of non-mainstream clients form accessing content. Now that Flash is going to disappear entirely, that means no access to all sorts of content on Linux, unless it's standardized.

So I see something to gain, and nothing to lose by standardizing DRM. I'm making assumptions to arrive at that conclusion, but I believe that they're no worse than the ones that Cory Doctorow is making here. It's just weird to see myself diverging from the EFF on this, and on T-mobile, and other things.

Consider what happened when Apple refused to allow Flash on their platform; that certainly accelerated the decline of Flash, or at least forced the development of Apple-specific approaches for that platform.

So what would happen if Chrome and Firefox had stood together in solidarity and said "no"? I don't think the answer would have been a mass exodus to IE; for that matter, what if IE had gone along with it? (Edge already bans plugins.)

Google has been a prime supporter of DRM on the web. They bought Widevine a few years ago which is a DRM provider and pushed for inclusion of DRM in the W3C.

It's basically Mozilla vs. the rest, just like it happened with patent encumbered H.264 and Mozilla was left holding the bag.

Given that Google has been one of the biggest voices in favour of EME, that seems rather unlikely.

The unstated assumption here is that DRM that isn't a standard won't be built into a browser.

That's not the assumption (because DRM already existed in the browser before it became a web standard - remember Silverlight?).

But it's much less work for the entities providing the DRM when EME provides a common standard for them to work with. This lowers the pain (for them) of using DRM, which makes it harder to provide enough pressure on them to stop DRM.

EME Standardized the Plugin err "extension" API. It in no way standardizes DRM. The Stardardization is around the way Javascript will be used to call inside HTML5 the browsers CDM (content decryption module" which is a plugin by another name.

There are currently 3 competing technologies, with more to come, that are incompatible with FOSS, incompatible with open systems

For Chrome Browsers there is Google Widevine CDM

For MS Browsers there is MS PlayReady

For Firefox there is Adobe Video CDM (which is basiclly the video playback part of Flash)

This is the problem with EME, Netflix, Google, and Microsoft have been masterful at their marketing of this to people that should be able to see past the bullshit

EME/CDM is still a binary browser plugin, Sure we "eliminate" flash and the need for a "3rd party" plugin, but in many ways that it worse, Before we had a standard Plugin API that allowed non-supported browser to make use of Flash, so there where many many many browser that could call the 3rd party flash application to make use of that content. Now those browsers are completely locked out. You will only be able to Access content on the Big 2, Chrome and IE, and maybe Firefox is they finalize their agreement with Adobe to bring in a Binary Blob into the Firefox Browser

I do not call that a "WIN" for interoperablity.

Indeed. Standardizing an unethical practice sounds like a very bad idea.

This is patently false. From 2003 to 2009 music sold on the most popular online store, iTunes, contained DRM. Due to competitive pressure from Amazon's DRM-free store, Apple also dropped their DRM. It once seemed impossible that the major labels' digital music would be sold without DRM, but now that is the norm. Content industries can and have changed their minds on DRM when consumers force them to.

http://macdailynews.com/2007/02/06/apple_ceo_steve_jobs_post...

The relevant part is: "The third alternative is to abolish DRMs entirely. Imagine a world where every online store sells DRM-free music encoded in open licensable formats. In such a world, any player can play music purchased from any store, and any store can sell music which is playable on all players. This is clearly the best alternative for consumers, and Apple would embrace it in a heartbeat. If the big four music companies would license Apple their music without the requirement that it be protected with a DRM, we would switch to selling only DRM-free music on our iTunes store. Every iPod ever made will play this DRM-free music."

However, it's also worth noting that the music industry is the only major content industry where this has been achieved.

If anything, things are going the other way with video content. There have been stories this week about Netflix cracking down on those who are circumventing region locking using VPNs. It seems big name shows are increasingly being offered via proprietary pay-per-view systems run by their production organisations, and centralised libraries like Netflix are either not carrying the material or dropping content they used to offer. We still have different release dates for movies in theatres in different countries, and for films and TV shows on DVD/Blu-ray. A recent trend seems to be for US TV shows not to release new seasons on Blu-ray at all here in the UK, so you can buy the lower quality version on DVD or you have to sign up for yet another online service to watch in HD, assuming you even have access to such a service from where you live. All of these measures are overtly consumer-hostile, but there is little the consumer who enjoys TV and movies can do if the entire industry moves that way (short of resorting to illegal channels and risking the consequences, which obviously is what a lot of people do in practice).

The software industry is similarly screwed up. We've gone from buying a copy of something and being able to use it, to buying a copy but needing remote activation, to buying a copy but needing varying degrees of ongoing online access to continue using it, to not even being able to buy a copy and merely renting. Personally I draw the line before I get that far, and refuse to pay for any important software unless I can reasonably expect it to continue working indefinitely. Even then, my businesses have been screwed repeatedly by varying degrees of ongoing online access or cutting off support, and slightly surprisingly, the most expensive professional software is by far the worst for this and for fixing the mess is something goes wrong.

I really hope that before too long the law starts to reflect the real relationships with modern technologies, where the original vendor who would traditionally be the main second party in a purchase contract is effectively just providing an introduction to the real other party, which is the organisation that makes the software/service and is (or isn't) going to provide ongoing support and/or retain ongoing control over it. I also hope that smaller, disruptive software businesses who are starting to take on industry heavyweights can demonstrate that money talks and enough customers are willing to vote with their wallets for less one-sided arrangements. But for now, the possibility that industry heavyweights like Microsoft, Adobe and Autodesk are going to give up their vice-like grips built on DRM and related technologies seems more remote than ever, and all of them are pushing hard in the opposite direction.

At least in public, Netflix has claimed that they don't want DRM themselves, and would remove it if they could, but that their content providers require it.

The dance doesn't match the music.

Video games are a major industry where there was significant pushback from DRM thanks to sellers like GOG. There are still many games with DRM, but the portion that don't use DRM has increased significantly.

However, the anti-censorship instinct of the internet will eventually drive all of these forms media to an open distribution model.

EDIT: Which, to the larger point -- DRM is two things, a content play and a platform play. Standardizing DRM is one way to limit the power of platform holders over content providers. Eliminating DRM is another. Deciding whether standardizing DRM is a lesser evil than leaving DRM up to platform holders is a question of who do you fear more, the content owners or the platform owners.

Half the problem is EME doesn't even attempt to standardise DRM in any real way: it just provides a JS API to deal with DRM'd content, decrypted by some "module" which interfaces with the browser in an undefined way (and in every case except Firefox, does so by bundled with no possibility of any other modules being installed).

They merely accepted a JS API for launching non-standard proprietary DRM Content Decryption Modules. API of these modules is deliberately undefined and left to be browser-specific.

It's just as standard and interoperable as using W3C's <object> to launch Flash.

It's just not true. Lots of people are pushed only weakly towards one side or the other. Making it easier to go one way and harder to go the other way will influence where people in the middle end up.

However, does EME allow encryption of javascript? I thought it was just for playback elements in <video> and <audio>? Searching a bit, I can't find evidence that executable javascript could be encrypted.

https://bugzilla.mozilla.org/show_bug.cgi?id=923590

Flash is only disappearing because of Web DRM. The situation gets worse for Linux users. Instead of installing the Flash plugin and seeing DRM content through it, now DRM only works if you are using Google Chrome because it's the only browser with Hollywood-approved DRM scheme.

As for users of FreeBSD and other less popular OSes, well Google Chrome doesn't have a build for you, so you lose this content completely.

Netflix and such need Chrome to play videos because of DRM. Well, let me see: Netflix doesn't cache any videos, so if I want to watch something more than once, it's smarter to download it unencumbered.

And then it gets to the point that pirating most of your content makes sense again. If you're going to be a scofflaw, might as well go all the way, and get the good experience from it.

That is simply not true. Flash was on the way out with or with out EME, Chrome and IE was already doing it. With out EME they still would have moved forward with their implementations of Widevine and PlayReady respectively.

Netflix would have still switch to it, and Chrome on Linux would have still played Netflix.

EME did not result in "Content coming to Linux" and there is no guarantee it will continue.

It will be up to the individual CDM makers, in this case google, if they want to continue to include the binary blob on Linux. No different than Flash. If google chooses tomorrow to remove widevine from Chrome on Linux, there goes your Netflix and any future "HTML5 EME" enabled websites

Further many other "HTML5" Browsers can not play this content because the binary blob required is not there... making it non-interoperable with any true FOSS gnu/linux operating system. Firefox has to pay Adobe for a CDM Plugin under pressure from their less than idealist users...

"HTML5" as a standard should mean anyone implementing the spec is able to see all content built on the spec. Sadly with the inclusion of EME sites like Netflix can claim to be "HTML5" compliant while still preventing every FOSS HTML5 browser from viewing any content.

That is not a WIN for Standardization, or a WIN for interoperablity

The way to deal with them is by not accepting them in return, and only using alternatives. Losing money bites, and they can quickly straighten their crooked ways out of fear for competition. That's the only method that works for curing DRM disease.

I think standards bodies operate most efficiently when they provide a bit of choice. If some browser writers want to implement DRM in their browsers I would rather it be standardized than not. Simply because the W3C doesn't standardize it does not mean it will not be implemented in browsers. It's not like W3C standards are binding legal documents.

From TFA: Much of the "Web" is disappearing into apps and into the big companies' walled gardens. If it is to be relevant in the decades to come, it must do everything it can to keep the Web open as an alternative to those walled gardens.

Then remove a reason for the web to disappear into walled gardens and allow the W3C to standardize DRM. Not providing ways for everyone to serve up their content via the web will only accelerate movement to other mediums.

I like the idea of the non-agression covenant. But the obvious problem with it is that implementers of EME don't have to sign it. It looks like it only covers those who participate at the W3C. It's a rather strange legal concept, and possibly unenforceable, but I'll leave it at that.

Of course they will. The big media companies like to posture and pretend they're going to take their ball and go home, but the customers hold all the power in this relationship. It's not like they are going to leave money on the table by sticking to dying platforms out of a religious devotion to DRM, they just think they can have their cake and eat it too by bluffing.

Regardless of what W3C decides, Chrome won't drop Netflix support, and Netflix for now seems to be hell-bent on having total legal control over which devices are allowed to play their content.

[1] https://w3c.github.io/encrypted-media/

This is a bold statement, but one that I'm surprised to find myself agreeing with. I suppose now it's a matter of figuring out what should replace the W3C; things are only going to move faster.

A decade ago, if I wanted to look up how something in say HTML or CSS worked, I'd probably go straight to the W3C site and just read the spec. Today, my first ports of call are places like MDN, caniuse.com, or sometimes places like the Babel documentation or kangax's ES6 compatibility table.

I can't remember the last time I read anything on the W3C site. I do find myself there now and then, but sadly, it is simply irrelevant to most of my daily web development work. What matters in a world with ever-moving goalposts is what browsers can actually do right now, which today basically means which of the evergreen browsers have support currently, which of their LTS releases also have support, and what the situation with IE and possibly older mobile browsers is, as validated by actual testing in each case.

I really wish this weren't the case, because the lack of standardisation and vast numbers of browser idiosyncrasies makes development much more onerous and less reliable than it should be. But the W3C just couldn't keep up, and for now the browser developers seem to be mostly ignoring it as a result.

Pretty much the only thing the W3C was working on that affected web developers a decade ago was CSS 2.1 and a couple of CSS 3 modules (Backgrounds & Borders and Selectors come to mind but nothing much else).

Yes, admittedly, it's still more-or-less just CSS work that actually happens at the W3C (with increasingly large amounts of work happening at the WHATWG covering the majority of the rest of the platform, HTML and DOM especially), but the number of CSS modules being worked on is vast, and the quality of the specifications is far greater than it was a decade ago.

As for:

> I really wish this weren't the case, because the lack of standardisation and vast numbers of browser idiosyncrasies makes development much more onerous and less reliable than it should be. But the W3C just couldn't keep up, and for now the browser developers seem to be mostly ignoring it as a result.

Per above, the quality of specifications is far greater than it was a decade ago, and it is (despite the perception of many) still the case that specifications are most of the time always nearly-complete before anyone ships anything (typically the incomplete parts are the bizarre edge-cases that no web developer is likely to ever run into, but there is a real attempt to avoid undefined behaviour), and there's definitely more involvement across the various standards orgs from all browser developers than there was a decade ago, W3C included.

The increasing number of browser "idiosyncrasies" is mostly a result of ever-increasing complexities in implementations (partly down to the increasing complexity and size of the web platform, partly down to new features being retrofitted into implementations that weren't originally designed to do anything like the new feature, and partly down to lack of a good shared, between all vendors, testsuite for CSS).

I am remain hopeful that we're moving towards somewhere better when it comes to interoperability across browsers. web-platform-tests (https://github.com/w3c/web-platform-tests) has got us a good, high-quality test suite for the platform minus CSS, and is run by most but not yet all browsers on a daily basis (and I think it's realistic to hope that by the end of 2016 it'll be run by all browsers on a daily basis, and that for many it will be the place they write tests, hence test suites will basically become shared rather than done separately with different coverage holes for bugs to slip through). csswg-test (https://github.com/w3c/csswg-test) is slowly starting to move towards a point where it'll be as widely run as web-platform-tests (please don't make me think about this too much, I'm finally making progress there, making the same arguments as five years ago but now with the evidence from web-platform-tests that it actually works).

And finally:

> I can't remember the last time I read anything on the W3C site. I do find myself there now and then, but sadly, it is simply irrelevant to most of my daily web development work. What matters in a world with ever-moving goalposts is what browsers can actually do right now, which today basically means which of the evergreen browsers have support currently, which of their LTS releases also have support, and what the situation with IE and possibly older mobile browsers is, as validated by actual testing in each case.

Really that makes it sound like half the problem is the fact that the spec documents give no informative data about what browsers support what features. There's definitely been talk about trying to do something better here, but it's a hard problem: you need some way to gauge support and quality of implementation, across all browsers and across all features. I think there's mostly agreement that caniuse is actually too coarse to really be put anywhere near a spec (because specs are rarely implemented as atomic units—there's normally different statuses for different sections), and that just grabbing test suite results isn't that useful either (because you can fail large numbers of tests due to obscure bugs, or because you've only implemented the awkward 20% not the easy 80%, so you're actually closer to shipping complete support than someone who supports the easy 80%).

(As a disclaimer: I've been around the W3C and WHATWG for quite a while (coming up to a decade), have been employed/contracted for several browser vendors, and was one of the early pushers to get high-quality test suites shared across all browsers.)

As a professional, I truly wish this weren't the case, but as a professional, my job is to make a working site, not necessarily a standards compliant one. All too frequently, it is still not possible to do both at the same time, either because browsers don't implement W3C recommendations consistently, or because of the poor quality of implementation you alluded to yourself, or because even when browsers did provide a useful implementation yesterday someone broke it in an update last night and today I'm rewriting something a different way because platinum support customers started calling first thing this morning and get a same day response not a 6 week one.

"Of course I understand that it's the update we just rolled out to our corporate standard browser that broke your standards-compliant and otherwise normally functioning site," said no customer ever. :-)

https://www.w3.org/TR/encrypted-media/

driven by Google, Microsoft and Netflix.

In other words, if the W3C fought back against DRM, we might not have EME today. But, Google and Microsoft won and DRM was added to the web.

Instead, by winning at the W3C, Google and Microsoft made DRM's victory as official as possible.

I wonder how much of a deterrent that is. W3C needs Google/Microsoft/Apple more than they need W3C. The content producers aren't even members of W3C I don't think. I guess it would be companies that create the encryption plugins like Adobe that could theoretically sue people under the DMCA. I just don't see how the W3C could even function without the biggest players at the table.

Similarly, either you will accept backdoored encryption or you will be automatically considered a terrorist and singled out for LE scrutiny.

Also, I don't expect Mozilla to do anything useful, given they went along with it so easily. But then, I haven't expected anything much of Mozilla in a long while.

The W3C is in a somewhat awkward place, really. To some degree, the W3C is beholden to its member organisations, and if they want to do something it frequently happens. That said, it's easier to refuse to work on something than to work on something the majority of members don't want (HTML comes to mind there!).

> Also, I don't expect Mozilla to do anything useful, given they went along with it so easily. But then, I haven't expected anything much of Mozilla in a long while.

I think people vastly overestimate how much influence Mozilla actually has. Look at how long Mozilla held out against H.264, and all that did was cause them to lose marketshare (because plenty of HTML video simply wouldn't play in Firefox) with no affect on the web as a platform.

The HTML5 video situation is a bit complicated, too, as H.264 was simply better across the board: standardization, quality, speed, tooling, hardware support, etc. There was only one reason to choose WebM and that was the belief that it might not be covered by patents, which mote optimistism than something you could be rely on.

That point really needs to be fought in the next generation or two where you aren't waiting until the contest is over before getting started.

DRM uses cryptographic methods, but I've never heard of a use case where a user chose a DRM product rather than a more straight forward cryptographic product to protect themselves.

Full disk encryption is a better tool for protecting yourself than SecuROM. In fact using SecuROM may well leave you more vulnerable to attack due to it's hacky obfuscation methods.

>DRM /often/ uses cryptographic methods [...]

Too late to edit though.

I am not confusing DRM with cryptography. See the cousin comments in this thread.

Full disk encryption is a better tool for protecting yourself than SecuROM.

Doesn't help when you have to share data with companies and governments, and the information ends up on someone else's disk.

FDE was an example among a vast array of encryption products. Attacking an non-comprehensive example as non-comprehensive isn't very enlightening. I still fail to see which DRM product you are suggesting is the proper tool for this situation. Even further, cryptography and careful allocation of trust seem to be a better solution than DRM for disseminating sensitive information since DRM is generally only a barrier, and not robust against concerted attack.

That is to say, if you are disseminating information to untrustworthy sources via DRM, then in the great majority of cases, you can consider the information compromised. Most DRMed content is copyable with as simple a solution as recording your screen. Even HDCP can be defeated with a simple camcorder.

I am and always was talking about the abstract concept of trusted execution. As of yet, there is no environment which is trustworthy from a technical or a political standpoint.

Today's society's attitudes towards DRM are like what one would expect from the world of Orwell's 1984 towards cameras. We've only experienced a certain tool's use for oppression, so people's brains have turned off and they can't imagine the implications of the same tool being in the hands of the masses.

I was more thinking that those organisations who do process medical records on your behalf -- your doctor, hospital, etc. -- could and should take steps to prevent the often very large number of staff they have from accessing an individual's records without proper authorisation. This would limit the ability for anything sensitive to be accessed by anyone without a reasonable clinical need for it or to be readily transferred to other systems, as well as creating a robust audit trail of access to sensitive data as well.

And that sort of thing is what I'm talking about. There are numerous applications where someone has a legitimate need to access certain data under certain conditions and for certain purposes, yet that same person does not need and should not have the ability to do other things with the same data.

And if you think that's not useful, I would remind you that a very substantial proportion of all white collar crime is based on inside jobs.

But that's not DRM! That's regular access control! The whole idea behind DRM is to control what users who are allowed to access the content can do with it.

Otherwise, even UNIX file permissions would be DRM.

The technologies that let someone access the data from their PC at the hospital but not, for example, save a copy to a USB stick, are much closer to what others use for DRM purposes.

Edit: if it is for some reason necessary, it's actually easy to allow. Have separate "import" computers set up with accessible USB ports and write-only access to the system.

Also, we seem to have latched onto medical records somewhere along the line, but please remember my original point was much more general. These technologies are relevant anywhere you have a need for access to sensitive information but also a need to control how that information can be used: finance, corporate R&D, obviously defence and security related fields, criminal justice, and the list goes on.

As for the more general point, that's fair, but people keep bringing up things that are not DRM as examples, or use cases where DRM is not a good solution.

I think my original idea of individuals applying DRM to their own medical records is a way better example of how DRM could potentially be useful to protect privacy and give people control of their own information.

But more problematic is that you're forgetting about the analogue loophole. As long as I can take a photo of your crappy email, you only have the illusion of safety. Add to that the fact that currently there is no such thing as unbreakable DRM, mostly because it's a fundamentally flawed concept that can't work. DRM is security theater at best.

> having such control over one's medical records would be desirable

One thing that always bothered me is that programmers have the arrogance to think that technology can fix a broken society. Given that DRM is a broken concept, it wouldn't stop global adversaries like the NSA from mining your medical records. And then when your insurance company demands whatever records they want to do however they please, including selling that data to the highest bidder, threatening to reject your contract or claim, good luck explaining them about DRM and control.

No, DRM as a concept is broken. The whole idea rests on giving someone the encrypted content and the key to decrypted, while obfuscating the way the two are combined in a machine the user controls.

That's why most DRM has been broken, often mere days after release, despite the many millions buried in its development.

DRM for documents is more about preventing sensitive data from escaping than it is securing communications between parties. The analog loophole always exists, mind you, so it still only makes life more difficult - but it does prevent mass transmission to a large extent.