- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 29 Feb 2012 10:27:40 +0200
- To: Mark Watson <watsonm@netflix.com>
- Cc: "<public-html@w3.org>" <public-html@w3.org>
On Tue, Feb 28, 2012 at 12:35 AM, Mark Watson <watsonm@netflix.com> wrote: > These are obviously fairly general statements - the proposal doesn't prescribe a model for where CDMs will come from and we appreciate opinions and ideas on that topic. Without knowing the nature of the CDMs, the impact of the proposal can't be evaluated. It can't even be evaluated if the proposal proposes a sensible API without having a good idea of what kind of things CDMs would be. But let's take a step back from CDMs and try to understand the motivating requirements better. So far, the requirements from the content provider point of view that I've seen are: * Decrypted data must not be available to JavaScript * Speedbump to deter users from saving decrypted content * Hiding content from untrusted CDNs that host the content * Hiding content from eavesdroppers when the content is served over HTTP without SSL/TLS (I also saw that there are unbounded requirements that can't be enumerated for all content providers in general, but I hope it's possible to gain a better understanding of the requirements of Netflix in particular later on. After all, there must be some process that lead to Netflix deciding to use whatever DRM Netflix now uses in various cases.) >From the browser point of view (well, open source browser at least), some obvious requirements are: * The system is fully specified and doesn't involve any implementation-side secrets * The system can be implemented by anyone and in Open Source software * The system doesn't require browsers to interface with 3rd-party black boxes that the browser vendors don't control (i.e. it should be possible to have a fully-functional fully open source implementation of the interoperable Web platform including all the supporting software in the style of B2G and Chromium OS.) Here's a description of a straw feature that I believe meets all the above requirements. Would this system be adequate for Netflix to serve movies to a browser that implements this feature? If not, why not specifically? (The main purpose of this exercise is to gain better understanding of the requirements. This isn't an offer to implement this straw feature.) - - This feature adds a decryption layer to the browser's HTTP stack and an API for initializing decryption keys from a different origin. Also, the Same Origin Policy is extended to block obvious access to decrypted data from JavaScript. The browser maintains a key storage that holds tuple of key, sha1(key), origin of key, list of authorized origins and time to live. There's a JavaScript API navigator.addKey(keyUrl, arrayOfAuthorizedOrigins, timeToLiveSeconds, doneCallback). keyUrl is a URL of the same origin as the caller of the API. The payload retrieved from the URL is key material to be added to the key storage. arrayOfAuthorizedOrigins is an array of origins serialized as strings that are authorized to serve content to be decrypted using the key. (This is a privacy mechinism against other origins probing the key store in case an untrusted CDN has leaked key hashes. More on hashes later.) timeToLiveSeconds is the number of seconds after which the browser purges this keystore entry. doneCallback is a JavaScript function that the browser calls after it has retrieved and processed keyUrl. Upon success, a single argument true is passed. Upon failure, a single argument false is passed. (Note: The key material is not exposed to JS.) The browser generates an id for the key by hashing the key material with SHA-1. Origin of key is set to the origin of the caller of the API which has to be the same as the origin of keyUrl. When an HTTP response includes the response header Content-Encoding: AES256, the processing happens as follows (if any step fails, treat as like other HTTP errors): The HTTP implementation gets the value of another response header called Key-SHA1 and base64-decodes it. Then, the browser's key storage is searched for a key whose sha1(key) entry matches this value and whose list of authorized origins containst the origin of the HTTP response and decrypts the response payload using AES256 using the located key as the decryption key. The decrypted payload is exposed to the other parts of the browser as having origin E(origin of key). Origins of the type E(Origin) have the following properties: * A resource of origin E(Origin) can be included as embedded content (<img>, <video>, <audio>) in (and only in) a document whose origin is Origin. * For the purpose of JavaScript access to the data of the resource (be it raw bytes or pixel data), E(Origin) is considered to be different-origin with every origin including the origin(s) representing the authority of browser extensions. * Browsers disable the "Save As..." context menu for embedded content whose origin is of the form E(Origin) When the layer above the HTTP layer request the HTTP stack to perform a range request on a Content-Encoding: AES256 resource, the HTTP stack must extend the range such that the range consists of full AES256 blocks in both directions. (The lack of block chaining is deliberate so that seeking is possible.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 29 February 2012 08:28:12 UTC