3 plus ones
Shared publicly•View activity
- Where's the minus one button when you need it.Jan 25, 2013
- Hmm, I said, who could have proposed this? Oh (see list of editors). That in turn led me to this:
“Unethical” HTML video copy protection proposal draws criticism from W3C reps
http://ars.to/WX3uQnJan 25, 2013
- I thought this was a joke.Jan 25, 2013
- I haven't read through the spec yet, but unless they've done something ground-breaking, this won't change a thing - other than make browsers more complicated.
At some point the bits/bytes are converted to photons, they get recorded using a digital video camera, and uploaded to Mega or The Pirate Bay with no DRM. It's like the editors of the spec have completely forgotten about the previous decade of failed DRM attempts.Jan 25, 2013
- I had to go look up the Seinfeld episode where Elaine discovers Bizarro World.Jan 25, 2013
- Saying that the EME proposal is "putting DRM into HTML5" is thoroughly inaccurate and misleading.
In fact, the EME proposal explicitly states that it is not defining a DRM system. It would create a common API for HTML5 applications to interact with a DRM, but a DRM is also explicitly not required.
Saying that the proposal doesn't meet its goal of reducing piracy on the web when that isn't the proposal's goal is nothing more than a strawman, and it has no place in a frank technical discussion. Furthermore, the point of the proposal wasn't to invent a new DRM system, so building a critique of the proposal based on that incorrect assumption is not a productive activity.
I think the problem (both here and on the HTMLWG list) is that too many people who haven't fully read, digested and understood the proposal are too quick to label it as a "broken/evil DRM proposal" when it so clearly isn't.Jan 28, 2013
- as I've stated on the HTML WG mailing list and elsewhere, I don't think the "DRM in HTML5" moniker it's inaccurate or misleading at all. I stand by my statement that the EME proposal is putting DRM into HTML5. I think the spec spends a great deal of time weasel wording around the concept of 'protection' vs. just coming out and saying that it's a DRM plugin architecture.
While the proposal states that it is not defining a DRM plugin system, that is by far the primary purpose of the specification. While DRM isn't explicitly required, that is what is going to use the EME specification. I haven't seen a single non-DRM use case for EME that can't be done with the Web stack we have today.
I never said DRM is evil, as it is just a technology and it's the use of the technology that is evil/good/whatever. You're projecting other people's opinions onto what I'm saying and losing my message in the churn.
The bottom line is that the proposal is about DRM. I make no value judgement on that. I've built DRM systems. I know that you can't often get content from content companies without them. However, to pretend that the spec is about 'protection' and not 'DRM' comes across as very disingenuous.
I read the spec, multiple times, and digested it. I think the parts of it that are broken can probably be fixed or removed. I don't think the specification is evil. I think the specification doesn't clearly state what the goal of the specification is, the ClearKey mechanism is a really bad feature to make an implementation requirement, it could lead to some really nasty CDM management complexity for browsers in the future, and spends a great deal of time weasel wording around the DRM issue.
If the spec was built on this theme: "The Web Platform needs to provide a DRM solution for content companies who refuse to go DRM-free. The Web Platform is competing against Flash and Silverlight. If we don't do this, then content companies will use the more error-prone-stack of proprietary plugins such as Flash or Silverlight to accomplish their goals. This is the lesser of two evils." ... then I'd be a bit more okay with the spec. However, it doesn't do this and supporters of the specification keep repeating that this isn't about DRM when it clearly is about DRM.Jan 29, 2013