[Bug 27053] Platform Segmentation

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