[Bug 26683] Replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26683

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #2 from Mark Watson <watsonm@netflix.com> ---
The generalized requirement is to allow the CDM to provide 'routing hints' with
the message. I don't think constraining the hint to a message type is
sufficient.

We should be clear that the application is still responsible for sending the
request to a valid server, but the choice of server may depend on information
from the CDM.

CDMs have an open free-form channel to applications in the form of the
keymessage. Restricting this 'routing hint' channel will only push people to
work around that restriction. It's arbitrary and ineffective.

I can think of at least ways that an application could ensure it connects only
to valid servers, even if the routing hint from the CDM is not authenticated:
- the application may have a list of valid servers from which it can choose,
based on the hint
- the application may have access to a trusted service which maps hints to
valid server URLs

I can also think of various ways in which the routing hint from the CDM could
be authenticated:
- it could itself be a signed object, such as a JWS, which the application can
validate using WebCrypto
- it could be a known property of the keysystem that it exposes only
authenticated hints
- it could be assumed that if all information provided to the CDM is
authenticated then the information emerging from it is too (for example if the
only information passed in was passed in by the application directly over the
Media Source Extension).

I don't think we should bless or require any particular approach, but we could
include some of these in our security considerations.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 4 September 2014 01:12:58 UTC