- From: <bugzilla@jessica.w3.org>
- Date: Thu, 23 Oct 2014 18:15:40 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27053 Domenic Denicola <domenic@domenicdenicola.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |domenic@domenicdenicola.com --- Comment #7 from Domenic Denicola <domenic@domenicdenicola.com> --- > Are there specific aspects of the current design which you think do preclude these outcomes and so should be changed ? What are they ? One big issue with the current design and spec text is probably the "Key System-specific" messages and response formats. However, more important are the implications of this (as demonstrated by existing implementations): - Applications cannot receive or send messages to a CDM unless they have a key system-specific server. - As we understand it, all such servers require agreements/licensing/NDA. - Each additional key system an application wants to support requires a new such agreement and server. - Inconsistent feature sets mean there is also additional work to integrate such servers. The last two items increase the cost of and discourage support for more clients, which is bad for the web platform (and doesn't meet the normal bar for web platform features, as discussed at more length in the full spec review). --- Possible change requests (but, as Sergey said, we would be happy with anything that addresses these issues): - It should be possible for anyone to (write a server to) communicate with the CDM. - Corollary: It should be possible for anyone to verify the trustworthiness of the CDM. - The message and response formats should be defined, both to facilitate the above and to facilitate security checks by the user agent. If these requests were satisfied, the second and third bullet in comment #0 would be addressed because a new browser/key system could implement the formats and provide a way to verify trustworthiness. Applications would then need to decide whether to trust such clients, but at least they would have an option (and not need to integrate yet another server). --- One recent step in the direction of the principles of comment #0 was executed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093. Indeed, the work done to discourage proprietary initData formats and encourage a standard one seems like an ideal pattern to follow and extend to messages and response formats. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 23 October 2014 18:15:41 UTC