[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #5 from Henri Sivonen <hsivonen@iki.fi> ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Retaining some keys allow for better performance and usability. Every key
> > > acquisition has a cost, both to the user (representing either user time
> > > spent or delay to first playback)
> > 
> > Isn't this best solved by letting the video start with a few seconds of
> > unencrypted content even though the keys are declared up front so that
> > playback can start during the key acquisition.
> 
> [steele] This would be a good solution for the initial startup delay.
> However this is not in compliance with long term business agreements some
> content publishers have for how their content is protected for distribution.
> In practice I have found most publishers cannot use this technique
> currently.

It's pretty sad that content licensors are *so* user-hostile. As if it mattered
if opening credits have DRM or not of the rest of the title does. :-(

> On the client side, the cost can be very expensive for platforms which use
> obfuscated software to do the cryptographic operations. On the order of
> seconds

Wow. I had no idea the impact of obfuscation was so bad. Thanks. Since AES
decrypt has to work in real time, I take it that operations with asymmetric
keys are more obfuscated than the AES decryptor or the codec?

> Now consider if keys can be cached. The application can cache a
> "subscription key" days ahead of time which is used to open the keys for the
> actual event.

The concept of a "subscription key" isn't in EME, though, and the way to invoke
CDM operations in a EME world is to attempt to play an encrypted track. How
would the acquisition of the subscription key actually work with EME? Would the
user have to navigate to the site days ahead of time and have the site
programmatically play a trivial video file in order to do something that
triggers EME and gives the CDM the opportunity to talk with the server and
change its state?

> The event streams can be encrypted with unique keys which are
> decrypt-able with the "subscription key" and embedded in the content stream.

Is this an interoperable CENC feature, or are we now talking about a DRM
scheme-specific feature that would defeat the CENC-based interoperability story
on EME?

> In DRM systems which
> support a hierarchy of keys and the keys are acquired in stages (for example
> from different servers) it is useful to be able to retain the intermediate
> keys between sessions to avoid the costs I outlined above where possible.

Is the idea that intermediate keys are used with a less obfuscated copy of the
crypto code than the key embedded in CDM itself?

> > > Some keys may only be required for a particular piece of content, but you
> > > don't want to have to pay the cost of acquisition again just because you
> > > have put your machine to sleep briefly. 
> > 
> > Why is this unwanted? Web apps like Gmail ping a server all the time. OTOH,
> > Netflix's player times out when paused even if the computer is awake.
> 
> [steele] As I mentioned above - this can introduce a delay of seconds or
> more on the client end. 

Actually: Why wouldn't the keys just stay in RAM during sleep if the browser
and CDM process(es) don't terminate?

> > > And in some cases it may not be convenient to reacquire the key, for example
> > > if the key can only be acquired in a private environment but the content is
> > > available to key holders in public environments.
> > 
> > I have trouble seeing what sort of movie streaming service would work like
> > this.
> 
> [steele] Imagine a developer for a movie streaming service trying to debug
> their player. They will need to test under various network conditions (say
> at your local Starbucks). However they do not want to expose their
> pre-production key servers to the open Internet. As a developer of these
> players - I run into this issue on a daily basis.

In that case, all the rest of the preproduction service would need to be
exposed to the Internet anyway as far as firewalls go. However, it could be
behind login. Since with EME user identification isn't a DRM concern but a
general Web app concern, the Web app could control whether messages are
forwarded to the preproduction key server based on whether the login belongs to
a developer. Since EME unifies how login works with how login works on the Web
in general, it seems to me that it would make the most sense to control
developer access to preproduction key servers exactly the same way as developer
access to preproduction versions of the rest of the components of the service
is controlled.

> Or to give a different
> example, what about a corporate video server streaming confidential content
> (e.g. a company meeting). The key acquisition phase might have to be
> completed within the corporate firewall but the playback could continue
> outside the firewall since the content itself is protected.

I think the W3C should reject EME spec adjustments motivated by intranet use
cases. If the W3C does EME at all, I think it should only be done as an
exceptional spec in response to the exceptional market power that the major
Hollywood studios wield. If intranet-motivated use cases were acknowledged,
then the precedent would be set in a way that would open the door to adding DRM
to all sorts of other media that companies might use to store confidential data
even if those forms of media aren't associated with the exceptional market
power of the major Hollywood studios and then video DRM would be an exception
anymore.

(Besides, DRM doesn't "protect" against an employee playing a corporate video
somewhere where an unauthorized person can overhear the soundtrack, so DRM
isn't a particularly appropriate mechanism for guarding corporate secrets
anyway.)

> Having said that -- that is not the main problem I am hoping to address. It
> is the performance and usability issues I raised above. 

OK.

> [steele] If the main concern here is the adding of a separate class of
> cookie-like data (as opposed to storing any data),

The point is that any stored data is cookie-like data. From the point of view
of someone examining the user's computing device, the stored data can serve as
evidence that the user has visited a given Web site. From the point of view of
a server, the stored data serves as evidence that the user has been seen before
(if it didn't, the data would be useless for optimizing the flow). The latter
concern is of course moot with services like Netflix that require login anyway
but would be privacy-relevant in the case of services that don't require login.

Another privacy issue is that the CDM is Hollywood's agent on the users
computer and the user may not trust the CDM. The browser is the user's agent
and, therefore, the piece of software that the user trusts. Therefore, from the
users perspective, it would be prudent if the user's agent kept Hollywood's
agent in a sandbox that prevented Hollywood's agent accessing the user's disk
or network directly. EME is the mechanism for providing browser-mediated (and
Web app-mediated) networking for the CDM, but since EME doesn't logically
require CDM access to persistent storage providing browser-mediated access to
persistent storage is additional complexity from the browser perspective.

Even without sandboxing, the ability of the browser to instruct the CDM to
clear data related to a given site broadens the interface between the browser
and the CDM from what's logically minimally necessary. (Though it might be a
drop in a bucket in the big picture.)

> I would say this is not a
> firm requirement. However this has a clear benefit for the user, because it
> make it less likely they will shoot themselves in the foot by clearing this
> data inadvertently. 

If the user tells the browser "Forget about example.com" and the CDM's
example.com-related records aren't deleted, that would be a notable violation
of the user's privacy expectations.

> I don't see the privacy concern here if this data is handled like web
> application data is today, segregated by domain and subject to CORS
> restrictions. Please articulate why you think this has privacy implications. 

Unless there is the added complexity of a mechanism that allows CDM-stored data
to be deleted together with other traces that a site might have left in the
browser, a person examining the user's computer can use CDM-stored data as
evidence of sites visited and servers can use CDM-stored data as evidence of a
prior visit.

The easiest way to avoid this problem would be not to store anything
persistently. However, crypto operations in the CDM alone taking multiple
seconds does indeed put the user experience trade-off in a different light if
storing a service-specific intermediate key would substantially speed up
subsequent content key acquisitions form the same site and might justify the
complexity of having a mechanism for clearing the data that integrates with the
other data clearing mechanisms in the browser.

> I think adding restrictions here (above what normal web app applications are
> subject) would only result in a worse user experience and no additional
> privacy.

If the CDM-stored data is cleared together with the other storage mechanisms
offered to sites, there's no new privacy issue. If not, there is.

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

Received on Friday, 24 May 2013 09:11:43 UTC