- From: cobaco <cobaco@freemen.be>
- Date: Tue, 08 Oct 2013 16:04:36 +0200
- To: public-restrictedmedia@w3.org
On 2013-10-07 08:21 Mark Watson wrote: > Honestly, many of us feel that EME is just a technical refactoring of > functionality *already present on the web*. > > I still find it hard to fathom why such a technical refactoring of existing > functionality is the cause of such ire. To implement playing EME content you need to be able to implemente the client- side CDM being used to protect that content. Since it's quite clear that those CDM's are going to be black boxes (since as mentioned earlier on the list, you can't stop someone from making a copy if they can create a player)... that introduces an 'only blessed developers can create a fully functional implementation'-problem. The W3C has a patent policy that acknowledges that as a problem and takes steps to prevent it happening. Black box CDM's introduce the same problem but incomprehensibly this time the W3C is apperently OK with that. This makes no logical sense, and consequently it makes us feel betrayed, it makes us think that W3C sold out and is no longer interested in maintaining genuine open standards and saveguarding the level playing field that follows from them. The industry demanding this is business as usual, What gets people upset is the W3C caving to that demand and creating standards with a de-facto "only blessed developers allowed"-policy. That's just not OK for an open standards group. > You should bear in mind that in practice server-side individual > watermarking probably wouldn't scale. figuring out how to make that scale is the industries problem, it's likely gonna be expensive, that's just the tradeoff to requiring that kind of control over massive traffic-streams > Our server guys resist even looking at the bytes as they flow from disk to > NIC. It would be a big change to the design and economics of content > delivery to do individual watermarking server-side. You can do the > watermarking client-side, but then you have the same requirements for robust > non-user-modifiable code. there's always the option of not entering the arms race of attempted artificial scarcity, accepting the basic non-scarce nature of digital goods, and competing on the basis of service and convenience instead of control. No matter what you do DRM is always going to add hassle and inconvienence, that's just the nature of the beast -- Cheers
Received on Tuesday, 8 October 2013 14:03:57 UTC