5 ms·

"Open standards" are about documenting interfaces in such a way as that any person could develop a compatible implementation, nothing more. There is already a

by jiggy2011 13y ago

"Open standards" are about documenting interfaces in such a way as that any person could develop a compatible implementation, nothing more. There is already a massive amount of proprietary tech running the web. From internet explorer to the secret algorithms used by google. Pretending that the web is some hippy utopia is not accurate. This proposal simply describes a standard protocol for a DRM system to be able to talk to a web browser. If you don't want to use it, simply choose a browser that ships with it disabled or disable it yourself. You're not going to lose access to your favorite sites because of this. The sites that would want to do this are already implementing paywalls or existing DRM systems.

josteink 13y ago
There is already a massive amount of proprietary tech running the web. From internet explorer to the secret algorithms used by google. Pretending that the web is some hippy utopia is not accurate. That's a bogus argument and misses the point completely. That you have closed source systems deployed on the open web is completely OK. That you have closed sourced browsers interpeting markeup is also completely OK. As long as the markup and code produced and published is compliant to the open standards we have all agreed upon. Because then anyone with the specification can interact with that content. That means that anyone, of any size, can sit down and implement a fully valid and compliant web-browser. This latest proposal from W3C means an end to that. Having the HTML specification will not be enough to create software able to render all the content on the web. Your browser will need to be "sanctioned" and "supported" by the DRM-vendors in order to work on the web. New platforms (FirefoxOS, Tizen, etc), new browsers, any new players at all and all open source endeavours are effectively shut out from this new web the W3C is drafting. That is unacceptable. This is a disastrous departure from any former W3C specification and directly in opposition to the W3C's own mission statement. We are only left to guess what sort of corruption has lead to W3C sinking this low. Whatever happened to allow this rot, a new consortium seems like a good way to solve it.
- jiggy2011 13y ago
  Not at all, your browser does not need to be sanctioned. Anybody can build a browser that speaks HTTP and can send HTML pages around. There is no mandate that you integrate DRM to be standards compliant, it's perfectly valid to write a browser that simply says "no" to any requests to perform DRM functions. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... You can simply implement a "clear key" system which does not require any CDM.
  - belorn 13y ago
    That misses the point. While anybody can built partial web-browsers, they can't build competitive alternatives to those sanctioned by DRM-vendors. Just speaking HTTP and partially parsing HTML pages does not a web-browser make.
    - jiggy2011 13y ago
      Yes, you can. You are free to support whichever content protection systems you want to support. The only DRM mechanism which is part of the standard is clearkey which is DRM in the same way that SSL is DRM, i.e not at all. https://news.ycombinator.com/item?id=5791579 https://news.ycombinator.com/item?id=5791579
      - josteink 13y ago
        You mean you are free to implement a second class citizen on this new, closed down and Hollywood-driven web. Yeah. That sounds really sexy. That sounds like the pinnacle of achievements for open standards.
        jiggy2011 13y ago
        Hollywood does not have jurisdiction over the majority of web. They cannot force you to use DRM.
        13y ago
- beeneto 13y ago
  The proposal is to have a standard for a way the browser communicates with non-standards compliant DRM encumbered (essentially encrypted) video. Anyone is still free to write a client which consumes the standards-compliant parts of the page, but will be unable to consume the non-standards compliant DRM encrypted video. In this way, it is similar to existing non-standards compliant web plugins like flash. For a long time nobody could just sit down and write a client which consumed flash animations (they were bound by the flash license, which prohibited mobile flash runtimes for example). I don't agree with this inclustion by the w3c myself, but your argument isn't a powerful argument against it. My objections to it revolve around the w3c overstepping their responsibility (why is it THEIR job to cater to one specific plugin family - is it being driven by political pressure), the futility of its inclusion (they expect an open source implementation, which probably isn't possible for this kind of technology), and the self contradictory statements in the original w3c announcement. PS. Calling an argument bogus and leaving it at that isn't helpful. If you see flaws in an argument you have to identify them point by point.
belorn 13y ago
> Pretending that the web is some hippy utopia is not accurate. A typical example of when a comment deserve a downvote. Calling the refusal of adding DRM to an open standard, a standard that is about a network of cooperating nodes that any standard compliant software can parse, is not an hippy utopia. > The sites that would want to do this are already implementing paywalls or existing DRM systems. The methods used by such systems are very limited. The same web functionality that DRM wants are the exact same ones constantly being limited to reduce malware. Even flash, which wants to allow arbitrary code are being phased out in favor of more precise html 5 functionality. DRM in the standard would be a direct step backward and open up more maleware, more arbitrary code execution, and more control by third-party of the computation of users devices.
- jiggy2011 13y ago
  It seems that those making the most noise over this haven't spent the requisite 2 minutes reading the actual proposal. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... From the abstract: "This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline." "The "org.w3.clearkey" Key System indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is required. "
  - belorn 13y ago
    Such API will encourage more DRM to be access through the browser, which in turn lets malware exploit such vectors in similar way that Java applets, active X and flash has been plagued by remote code exploits. The amount of money and greif caused by such malware is very high, and was a major incentive for moving to HTML 5. The draft in question would rather move so we had 10-20 more such lovely (in)secure plugins all being accessed through the API provided by the standard. But you can believe that anyone objecting to that just hasn't read the draft if that makes your life easier.
pornel 13y ago
EME doesn't describe an interoperable standard. It's only a tiny JS interface for invoking proprietary, deliberately unspecified CDM plug-ins (that are protected by DMCA, so you can't use them even if you knew how). It's as if you wrote spec for `<object classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000'/>` tag and said Silverlight is now a W3C Recommendation. That's even a step back from Silverlight today, because at least it has de-facto NPAPI standard interface that CDMs don't.
- gsnedders 13y ago
  Beyond that, it doesn't even define the plugin API side of it, only the JS side. Defining the plugin API would make the proposal less bad (!= good) as then at least the plugins wouldn't be browser specific (though I suspect quickly enough a de-facto standard will appear) I mean, at least something like NPAPI is (somewhat) documented, so that one can support all NPAPI plugins in any browser (say, Flash, Silverlight on OS X, etc.), even if what the plugins do themselves it totally undocumented…

josteink 13y ago

There is already a massive amount of proprietary tech running the web. From internet explorer to the secret algorithms used by google. Pretending that the web is some hippy utopia is not accurate. That's a bogus argument and misses the point completely. That you have closed source systems deployed on the open web is completely OK. That you have closed sourced browsers interpeting markeup is also completely OK. As long as the markup and code produced and published is compliant to the open standards we have all agreed upon. Because then anyone with the specification can interact with that content. That means that anyone, of any size, can sit down and implement a fully valid and compliant web-browser. This latest proposal from W3C means an end to that. Having the HTML specification will not be enough to create software able to render all the content on the web. Your browser will need to be "sanctioned" and "supported" by the DRM-vendors in order to work on the web. New platforms (FirefoxOS, Tizen, etc), new browsers, any new players at all and all open source endeavours are effectively shut out from this new web the W3C is drafting. That is unacceptable. This is a disastrous departure from any former W3C specification and directly in opposition to the W3C's own mission statement. We are only left to guess what sort of corruption has lead to W3C sinking this low. Whatever happened to allow this rot, a new consortium seems like a good way to solve it.

jiggy2011 13y ago
Not at all, your browser does not need to be sanctioned. Anybody can build a browser that speaks HTTP and can send HTML pages around. There is no mandate that you integrate DRM to be standards compliant, it's perfectly valid to write a browser that simply says "no" to any requests to perform DRM functions. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... You can simply implement a "clear key" system which does not require any CDM.
- belorn 13y ago
  That misses the point. While anybody can built partial web-browsers, they can't build competitive alternatives to those sanctioned by DRM-vendors. Just speaking HTTP and partially parsing HTML pages does not a web-browser make.
  - jiggy2011 13y ago
    Yes, you can. You are free to support whichever content protection systems you want to support. The only DRM mechanism which is part of the standard is clearkey which is DRM in the same way that SSL is DRM, i.e not at all. https://news.ycombinator.com/item?id=5791579 https://news.ycombinator.com/item?id=5791579
    - josteink 13y ago
      You mean you are free to implement a second class citizen on this new, closed down and Hollywood-driven web. Yeah. That sounds really sexy. That sounds like the pinnacle of achievements for open standards.
      - jiggy2011 13y ago
        Hollywood does not have jurisdiction over the majority of web. They cannot force you to use DRM.
        13y ago
beeneto 13y ago
The proposal is to have a standard for a way the browser communicates with non-standards compliant DRM encumbered (essentially encrypted) video. Anyone is still free to write a client which consumes the standards-compliant parts of the page, but will be unable to consume the non-standards compliant DRM encrypted video. In this way, it is similar to existing non-standards compliant web plugins like flash. For a long time nobody could just sit down and write a client which consumed flash animations (they were bound by the flash license, which prohibited mobile flash runtimes for example). I don't agree with this inclustion by the w3c myself, but your argument isn't a powerful argument against it. My objections to it revolve around the w3c overstepping their responsibility (why is it THEIR job to cater to one specific plugin family - is it being driven by political pressure), the futility of its inclusion (they expect an open source implementation, which probably isn't possible for this kind of technology), and the self contradictory statements in the original w3c announcement. PS. Calling an argument bogus and leaving it at that isn't helpful. If you see flaws in an argument you have to identify them point by point.

belorn 13y ago

> Pretending that the web is some hippy utopia is not accurate. A typical example of when a comment deserve a downvote. Calling the refusal of adding DRM to an open standard, a standard that is about a network of cooperating nodes that any standard compliant software can parse, is not an hippy utopia. > The sites that would want to do this are already implementing paywalls or existing DRM systems. The methods used by such systems are very limited. The same web functionality that DRM wants are the exact same ones constantly being limited to reduce malware. Even flash, which wants to allow arbitrary code are being phased out in favor of more precise html 5 functionality. DRM in the standard would be a direct step backward and open up more maleware, more arbitrary code execution, and more control by third-party of the computation of users devices.

jiggy2011 13y ago
It seems that those making the most noise over this haven't spent the requisite 2 minutes reading the actual proposal. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... From the abstract: "This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline." "The "org.w3.clearkey" Key System indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is required. "
- belorn 13y ago
  Such API will encourage more DRM to be access through the browser, which in turn lets malware exploit such vectors in similar way that Java applets, active X and flash has been plagued by remote code exploits. The amount of money and greif caused by such malware is very high, and was a major incentive for moving to HTML 5. The draft in question would rather move so we had 10-20 more such lovely (in)secure plugins all being accessed through the API provided by the standard. But you can believe that anyone objecting to that just hasn't read the draft if that makes your life easier.

pornel 13y ago

EME doesn't describe an interoperable standard. It's only a tiny JS interface for invoking proprietary, deliberately unspecified CDM plug-ins (that are protected by DMCA, so you can't use them even if you knew how). It's as if you wrote spec for `<object classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000'/>` tag and said Silverlight is now a W3C Recommendation. That's even a step back from Silverlight today, because at least it has de-facto NPAPI standard interface that CDMs don't.

gsnedders 13y ago
Beyond that, it doesn't even define the plugin API side of it, only the JS side. Defining the plugin API would make the proposal less bad (!= good) as then at least the plugins wouldn't be browser specific (though I suspect quickly enough a de-facto standard will appear) I mean, at least something like NPAPI is (somewhat) documented, so that one can support all NPAPI plugins in any browser (say, Flash, Silverlight on OS X, etc.), even if what the plugins do themselves it totally undocumented…