[Bug 24082] Several issues discussed in the TF point to the need for defined extensibility points in EME

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

Joe Steele <steele@adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #12 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #11)
> (In reply to Joe Steele from comment #10)
> > (In reply to Joe Steele from comment #8)
> > > * Support for application data 
> > > It would be very helpful to be able to add custom data from the application
> > > that could then be signed by the CDM as part of the key request. 
> > 
> > This is still an issue. It can (and will if not if addressed in the spec) be
> > implemented by applications via modifying the initData passed to the CDM to
> > contain the additional information desired or by browsers supporting
> > non-standard additional parameters to the createSession/generateRequest
> > methods. Neither of these seems to add to interoperability. 
> 
> This would be an inappropriate misuse of the EME APIs, be an abuse of
> initData, and NOT be spec-compliant. Allowing such data to be passed via
> some proprietary key system protocols would itself inhibit interoperability.
> See comment #5.

I don't agree that this is non-compliant, although I think it is not in the
spirit of the spec and would certainly be non-interoperable. 

The definition of Initialization Data [1] and generateRequest [2] does not
preclude this usage. There is some non-normative text that talks about
"sanitizing" the initialization data, but as we have previously discussed the
current definition of initialization data for CENC [3] as including "protection
system specific headers" means that this data often cannot be sanitized by the
user agent even if such a thing were desirable. 

[1]
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#initialization-data
[2]
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#widl-MediaKeySession-generateRequest-Promise-void--DOMString-initDataType-ArrayBuffer-ArrayBufferView-initData
[3]
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/cenc-format.html#init-data

> 
> More generally, it is concerning to (again [1]) see you imply implementation
> of non-standard APIs or behavior should the spec process not have a specific
> outcome.

Regarding non-standard APIs -- 

I was referring to the API support that Microsoft currently has for passing in
additional information that was mentioned in comment 0.

Regarding non-standard behavior -- 

I am trying to point out common (in my experience) usage patterns for
plugin-based protected content players that should be implementable for native
browser playback. Based on the feedback from Microsoft, it would seem that my
experience is common beyond our players.

It is reasonable to say that developers will try to build work-arounds when the
available services do not solve their problem. If enough people use the
work-arounds, service implementors take the hint and start building explicit
support. If people find that it is easy to avoid the problem altogether without
a work-around, the work-arounds die out naturally. This is how we make
progress. 

Adobe does not own a browser. We have to work within the environment that is
provided to us. Within those constraints we are trying to provide services our
developers want, rather than tell them to change the way they currently work.
We would prefer to work with browser implementors rather than at cross purposes
in this. 

> 
> > (In reply to David Dorwin from comment #9)
> > > In addition to interoperability, such unvetted extensions may also
> > > compromise the security and privacy properties of the spec. Likewise,
> > > supporting such extensions would make it difficult to reason about such
> > > properties.
> > 
> > This is veering into the secure origin discussion in bug 26332. The channel
> > between the application and the CDM already exists. Adding additional data
> > from the same source to the channel does not change the security calculus.
> > We are just talking about the semantics of how it gets added, not whether it
> > can be added at all. 
> 
> To clarify, my comment was general and did not apply to any specific
> extension(s).
> 
> This was a general statement about unspecified or non-normative
> functionality making such analysis and specification difficult, if not
> impossible. This is not necessarily related to the secure origin bug; it
> could also affect the user agent (i.e. origin considerations).
> 
> > > I believe we have sufficient points to extend the standardized feature set
> > > in the future if necessary. For example, SessionType and
> > > MediaKeySystemOptions.
> > 
> > I think we are getting closer. But this issue still exists. It can be worked
> > around as I mentioned above, but I don't think that what I described is the
> > right solution. The right solution is to either eliminate the need for this
> > extension or have explicit support for it.
> 
> If you think there is a missing feature, we should discuss it (in a
> different thread) rather than just allowing or implementing proprietary
> extensions. However, I believe this specific feature has already been
> discussed multiple times.

This bug/thread was opened specifically to discuss this issue as far as I can
tell. Yes - it has been discussed multiple times, but at no time has a
resolution been reached as far as I can tell. 

> [1] http://www.w3.org/2014/08/26-html-media-minutes.html#item08

There may be some confusion here - your link points to a conversation about
loadSession. The main thrust of this bug is whether the application should have
a standard way to pass additional data either with the initData when the
session is created (my proposal) or when the MediaKeys object is created
(Microsoft's implementation).

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

Received on Friday, 17 October 2014 00:12:59 UTC