[Bug 24025] Add optional configuration parameter to MediaKeys constructor

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

Henri Sivonen <hsivonen@hsivonen.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsivonen@hsivonen.fi

--- Comment #3 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to David Dorwin from comment #0)
> robustness options,

Do you envision these to be Key System-specific or do you envision
standardizing a cross-Key System robustness taxonomy. AFAICT, EME has tried to
avoid the latter, but you say "We should enable/encourage use of consistent
configuration values across key systems."

> offline,

What kind of offline cases do you have in mind? From the user perspective,
EME's non-lock-in story is that since EME is always streaming, it doesn't
matter if the user watches one Netflix stream using Widevine on Chrome OS and
the next stream using PlayReady on Windows 8.1--the user can make that
transition, since there are no retained files tied to the first-used DRM
keeping the user locked into the first-used DRM.

The same lock-in mitigation applies to browser vendors, too, in case a browser
vendor wishes to be able to migrate from supporting one Key System to
supporting another, since there's no need to keep supporting
previously-obtained legacy files.

"Offline" in the sense of "sales" breaks that story, because if the user holds
onto the DRMed files over a long period of time, the user is locked into the
DRM used at the time the user obtained the files. So supporting that sort of
offline seems harmful.

"Offline" in the sense of "rental" where the JS app manages the data (i.e. the
user doesn't get to move a rented movie from a device to anthore) or caching
subscription content could be accomplished using a generic offlining mechanism
such as NavigationController as long as the Key System supports expressing a
time-limited license as a single EME response message that the JS can store
into IndexedDB or similar and push to the EME API later. So supporting this
kind of offline should not involve changes to EME assuming a Key System with
the described characteristic.

> server certificates used to protect user identifiers, etc.

Can you, please, elaborate on this? What's being protected against what/whom?

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

Received on Tuesday, 10 December 2013 13:15:31 UTC