You Can't Destroy the Village to Save It: W3C vs. DRM, Round Two

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.

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

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.

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.

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.)

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

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.

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.

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.

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.

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

Too late to edit though.