Date: Tue, 28 Jan 2014 22:08:43 -0800
From: [email protected]
...
But, can you explain the advantage of the restriction in your proposal that the
target device not support a full UA ? How much of the web platform has to be
missing from the target device for it to obtain that advantage ?
Many of the advantages are noted in the wiki proposal and most would be
compromised if the target device were a web browser, and many advantages would
become more compromised by the device being less constrained and more
customizable.
The target device or app is not a web platform, it is a limited DRM Internet
connected media player. It would be expected to use some http protocols to
communicate with the server, so that it could also be implemented in an EME
capable web browser. It would not expose a JS interpreter, or the DOM, would
not load or present HTML content, and it would have a well defined protocol
that could be sand-boxed effectively. It would be required to operate without
contact with a web browser.
The proposal is intended to give the user the option to isolate the protected
media player from the web page and user agent.
For the purpose of discussion, consider a remote-EME implementation that
forwards EME API calls to a remote device This would have some characteristics
of the proposal: the remote application need not be a web browser, and it gives
the user the option of separation. However this would still be objectionable,
not limited to: the DRM protocols are still being routed through the web
browser; and the open web is still being tainted by DRM APIs.
An open web has significant benefits for the user, and it was never necessary
to add the EME API to meet the use case of viewing protected content.
Sure, UAs can - and some have - implement content protection "under the covers"
of the <video> element, without ever exposing any additional API to the web
page. The UA silently contacts the license server identified in the content
using a proprietary DRM protocol. This is much worse from a security and
privacy perspective than EME.
There are a few separate issues conflated here:
1. A method used to distinguish protected content by the <video> element affect
security and privacy.
The proposal only requires the web browser to detect content to be redirected,
and passes the URL to a separate device or app. This is a well defined
declarative mechanism that the user can easily control - the best standard for
user security and privacy.
2. 'The UA silently contacts the license server identified in the content'
The proposed media player would only contact the server as requested, and the
user can sandbox the device's communication to restrict it to only contacting
the server identified in the content. The proposal supports a market for the
media player so that a user can choose one from a reputable vendor. A much
better outcome for security and privacy than the EME.
3. 'using a proprietary DRM protocol'
The proposal defines the http protocol used to contact the server. This is
much better for security and privacy than the EME API which leaves this
undefined.
The proposal is defined to be implementable by a user chosen media player web
app on an EME capable web browser. What exactly is 'much worse from a security
and privacy perspective than the EME'?
The EME proponents have still not disclosed their requirements
Yes, we have. The requirement is to integrate HTML <video> with existing
content protection systems so that users of protected content services can also
enjoy the many and varied benefits of web technologies. Ideally, we would also
avoid a separate "install" step and enable use of hardware decoding.
Last week the requirement was to 'add an EME API'. We are having to extract
the requirements and use cases from the proponents though a slow and ongoing
process while you continue to advance your proposal. On many occasions the
proponents have bluntly refused to engage in a process to better define the
requirements.
The 'many and varied benefits of web technology' is a PR statement, not even
close to a technical requirement. It is impossible to technically evaluate any
proposal on this basis.
What exactly are the requirements and use cases of the EME API?
* Let set A be all the capabilities of a web browser with EME API.
* Let set B be all the capabilities that this proposal enables, a separate web
browser and limited DRM media player.
What is the difference?
* It is certainly not the capability to view DRM protected big-budget movies.
Both proposals support this.
* It is certainly not the 'many and varied benefits of web technology' because
both proposal support this. This proposal just separates the DRM device or app
from the web browser - the user still has a web browser to benefit from the
'many and varied benefits of web technology'. Many of us dispute that DRM is
compatible with web technology.
Please, please, tell us what are the requirements and use cases for the EME API?
Then let me amend the proposal to narrow this set even further.
- it surely is not for viewing big budget movies. We can look at the
differences between this proposal and the EME to take a guess, but it hardly
seems to be justified or to benefit the user.
So what are the requirements that justify continuing to advance the EME?
When I have a better understanding of your proposal, we can evaluate the
differences.
It seems well enough defined to evaluate the differences. You have asked how
much of the web browser can be included in the media player and the answer is
'as little as possible' and 'it is not a web browser'. Do you have any other
questions?
cheers
Fred
