- From: <bugzilla@jessica.w3.org>
- Date: Tue, 10 Dec 2013 16:31:05 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025 --- Comment #4 from Mark Watson <watsonm@netflix.com> --- Hi Henri, The issue of "lock in", either for browser or user, is really a function of a service that doesn't support multiple DRMs. It's not specific to offline - you could have lock-in with a subscription streaming service too. It's obviously more severe with 'ownership' models because the timeframe is 'in perpetuity'. EME can't prevent this. What we are doing is defining an architecture that makes it easier for services to support multiple DRMs, in the hope that services will therefore find it easier not to lock in their customers in this way. That's all. This bug is about quite practical concerns. As much as we wish to harmonize, the features and operation of different DRMs can be quite different. CDMs can have different modes offering different levels of robustness, for example, where starting the CDM in a more robust mode might take longer than in a less robust mode. If the application can provide information about the required mode, the longer startup can be avoided for applications that do not need the more robust mode. The server certificates point refers to the idea that a CDM may wish to encrypt its messages to the server using a server public key. One approach is to do a round trip to the server to ask it for its public key. But if this information could be provided by the application, it would save a round trip. I think the assumption with this mechanism is that it should be entirely for optional optimizations. Keysystems should always support a default mode of operation where no such information is supplied. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 10 December 2013 16:31:07 UTC