4 ms·

Essentially, the choices are not "Standardize DRM descriptions in the w3c process or don't have browsers supporting DRM at the HTML-model level." The choices a

Essentially, the choices are not "Standardize DRM descriptions in the w3c process or don't have browsers supporting DRM at the HTML-model level." The choices are "Standardize DRM descriptions in the w3c process or have an ad-hoc collection of binary blobs, de-facto standards implemented by the dominant browser vendors, and external mobile players." If the w3c doesn't standardize the DRM descriptions, it just pushes the standards a little bit towards irrelevance as the industry interprets silence as damage and routes around it (especially given the current ecosystem where ever-more "web content" is actually vended through mobile apps). This may very well be the principled stand that the w3c should take---it may be correct to curtail themselves to only standardizing things that can be openly implemented. But we should observe that their lack of a hat in this ring isn't going to kill DRM-protected video streams---the owners of the content want that and are willing to pay a LOT of money to be lied to.

nitrogen 11y ago
Last time I checked, EME still results in an ad hoc collection of binary blobs. There's Google, Adobe, Microsoft, and Apple all with competing blobs.
- fixermark 11y ago
  It results in a standard for describing them so that browsers can properly select the right one, or ignore all of them. That's less ad-hoc than the alternatives.
  - nitrogen 11y ago
    But it does very little, if anything, for the open web, and either needs total top to bottom specification for open implementation, or doesn't belong in a web standard.
    - fixermark 11y ago
      That may be true, but it is irrelevant. I don't know why you believe that the technologies under the W3C web standards need be open. The standards themselves need be open (they're published, after all), but the technologies underpinning them? Checking W3C's website, their guidelines for implementations appear to be "W3C issues a call for implementations as part of standardization and welcomes public participation" [https://www.w3.org/participate/implementation https://www.w3.org/participate/implementation]. Nothing in the formal standards process [https://www.w3.org/2005/10/Process-20051014/tr.html https://www.w3.org/2005/10/Process-20051014/tr.html] appears to require all implementations be "open," and that assumption flies in the face of previous legacy standards (<img> when .gif was an accepted file format but still encumbered by patent, the <object> and <embed> standards that specify closed-binary plugins to side-load). While it'd be nice if it worked the way you described, it seems that the standard as currently codified (including one specified "dummy" open reference implementation) is all that is needed.
      - nitrogen 11y ago
        https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Li... (Royalty Free) https://www.w3.org/Consortium/mission#principles https://www.w3.org/Consortium/mission#principles (Web for All, Web on Everything)
nucleardog 11y ago
This is what I don't get about this whole argument... We can either standardize some of the interfaces and bolt the DRM on there, or we can standardize nothing and everyone will do whatever the hell they want because there's too much money riding on DRM being implemented for it to just disappear. I fail to see how standardizing part of the solution instead of none of the solution creates a less interoperable/palatable system.

nitrogen 11y ago

Last time I checked, EME still results in an ad hoc collection of binary blobs. There's Google, Adobe, Microsoft, and Apple all with competing blobs.

fixermark 11y ago
It results in a standard for describing them so that browsers can properly select the right one, or ignore all of them. That's less ad-hoc than the alternatives.
- nitrogen 11y ago
  But it does very little, if anything, for the open web, and either needs total top to bottom specification for open implementation, or doesn't belong in a web standard.
  - fixermark 11y ago
    That may be true, but it is irrelevant. I don't know why you believe that the technologies under the W3C web standards need be open. The standards themselves need be open (they're published, after all), but the technologies underpinning them? Checking W3C's website, their guidelines for implementations appear to be "W3C issues a call for implementations as part of standardization and welcomes public participation" [https://www.w3.org/participate/implementation https://www.w3.org/participate/implementation]. Nothing in the formal standards process [https://www.w3.org/2005/10/Process-20051014/tr.html https://www.w3.org/2005/10/Process-20051014/tr.html] appears to require all implementations be "open," and that assumption flies in the face of previous legacy standards (<img> when .gif was an accepted file format but still encumbered by patent, the <object> and <embed> standards that specify closed-binary plugins to side-load). While it'd be nice if it worked the way you described, it seems that the standard as currently codified (including one specified "dummy" open reference implementation) is all that is needed.
    - nitrogen 11y ago
      https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Li... (Royalty Free) https://www.w3.org/Consortium/mission#principles https://www.w3.org/Consortium/mission#principles (Web for All, Web on Everything)

nucleardog 11y ago

This is what I don't get about this whole argument... We can either standardize some of the interfaces and bolt the DRM on there, or we can standardize nothing and everyone will do whatever the hell they want because there's too much money riding on DRM being implemented for it to just disappear. I fail to see how standardizing part of the solution instead of none of the solution creates a less interoperable/palatable system.