W3C moves to finalize DRM standardization, reclassifies suing security researchers as a feature, not a bug


#1

Originally published at: http://boingboing.net/2017/03/21/we-cant-handle-the-truth.html


#2

Seems that having a single option/group serving as gatekeepers for browser standards is problematic. I get that the point here is to make a standard so having competing ones isn’t helpful, but then again you run into problems like what we’re currently seeing. This just reeks of corruption and shady dealing to me.


#3

but the W3C is much more transparent than, say, the ITU - and the latter tries quite often to get a bigger role in web standards.

and take a look at WHATWG, the second org publishing standards for the web


#4

Looks like it’s time to find a country or two where doing research is legal and move security work there. Once it’s published of course there’s no legal ground for keeping it secret; patents don’t apply, copyright doesn’t apply, trademark really doesn’t apply, and it can’t be a trade secret if the publisher is not under a duty of confidentiality.

At least as long as something resembling free speech and press still hold. No guarantees.


#5

The Ars Technica article makes it pretty clear the purpose behind EME is to keep any and all DRM out of the browser codebase and simply provide an interface to whatever mechanism the protected media requires. That way the chances of the browser (or anyone researching vulnerabilities in it) being involved in any kind of legal or technical DRM issue is slim to none. EME doesn’t handle rights management, decryption, decoding, anything that actually makes it DRM. All it does is handle key/license exchange and passes the encrypted media to the plugin. You might as well say HTTPS and SSL is DRM if you’re going to say EME is DRM.

The headline is inaccurate on both of the points it makes:

  • EME is not a DRM standard. It’s an API standard for interfacing with multiple proprietary DRM systems.
  • Any research into a DRM system that could potentially run afoul of the DMCA and lead to a lawsuit wouldn’t involve EME or the browser.

Every time Cory posts something about the W3C, it’s the same EFF echo chamber. Literally the exact same pages from the EFF, all linking to each other with no outside sources, every single time… and the non-EFF article offered at the end as new information always seems to contradict the EFF’s analysis!


#6

It isn’t a single entity per se, it is a consortium of many of the industries leading companies and experts, and hence reflects the will of larger industry over any one individual.

The entire point of any standard is to have a single agreed upon reference so that you don’t have a zillion fragmented implimentations. The W3C is literally what makes the web work and usable. They have done and continue to do a tremendous amount of good.

I get that the EFF wants DRM to go away altogether, but the W3C isn’t standardizing DRM, nor does the EME standard include any DRM. DRM is still imlimented via propritary binary blobs from the respective vendors (same as it always has been), the only difference is…

What EME Does:

  1. standardizes the discovery method, meaning that it is easier to find and use new third party blobs.
  2. it implements the decoding in a much safer container then the previous full browser plugin method, protecting web users security and privacy in a way that wasn’t possible before.

What EME Does NOT Do:

  1. Change the historical separation between third party DRM decryption and the browser that has always existed.
  2. Standardize the thrid party decryption blobs, it only standardizes their discovery.
  3. Include any 3rd party DRM into the browser.

That is 100% correct. This is the W3Cs statement as well.


#7

Sadly, Cory has decided that telling the truth is far less important than pursuing a quixotic campaign against DRM and against anyone who cooperates with or interacts with DRM peddlers, or in any way acknowledges that DRM is not going to go away anytime soon.


#8

As someone from W3C, and because they’re not included in the blog post, some neutral info on the Best Practices are at: https://www.w3.org/2017/01/GVDP-factsheet.html and the best practices themselves https://www.w3.org/TeamSubmission/2017/SUBM-sdbp-20170302/

The Best Practices are currently a W3C Team Submission and at this stage they are voluntary. However, they could become mandatory for all specs at W3C if members (including EFF via Cory, acting as their Advisory Committee Representative) advocate and get consensus on any changes needed to better help support researchers in security, privacy and accessibility.

If the Best Practices are ignored or misrepresented, they WILL only ever be voluntary and unhelpful. If no one signs up to make them better, without member support, they will never make get to the Recommendation process. EME had members willing to put in hard work over years to make that specification happen - through all the different stages of approval. For this proposal to protect Security Researchers to truly help, we need experts and member advocates to make them better, to point out what’s needed and to do the hard work of signing up to support and promote them though the W3C process where they could become binding on not just one but all W3C specs (like the Patent Policy).

However, as of today, even though people have said that that the suggested Best Practices are insufficient, there has been no action at all in the official W3C channels — where the effort could make the most impact — to answer questionnaires, sign up, comment, get others to agree or offer corrections to make them better.

W3C are asking its members and experts to do the work to help researchers by taking an idea and making it better and our AC reps to use using our process to get it through the recommendations track.


#9

It’s a bit of a Japanese pachinko situation though, isn’t it?

We can’t give you money for winning at pachinko, silly, gambling is illegal in Japan!

However, if you buy this lovely token and take a short walk around the block to our completely unaffiliated kiosk, I hear that my friend will buy the token off of you.

We’re not putting DRM in browsers at all, we’re just providing an API where if anyone were to happen to want to put DRM in a browser, now they can easily hook it up.


#10

Considering the current situation is “here’s the key to the coin box, take the tokens you paid for but please don’t rob us” I’d say that is an improvement.


#11

Unless you’re in Japan (I believe) it is legal everywhere.


#12

The DRM is already there in Flash, Silverlight, etc. How exactly is this making the situation worse?

How it makes it better was already covered in a comment above.


#13

It’s a legitimacy thing mostly. If it’s in Silverlight and in Flash then you can get away with saying that’s not really how the web is supposed to work. Once it’s an actual W3C standard which the standards body expects you to implement, well now DRM is an official, sanctioned part of the web.


#14

This topic was automatically closed after 5 days. New replies are no longer allowed.