- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Wed, 19 Feb 2014 12:12:32 +0200
- To: public-webcrypto-comments@w3.org
On Thu, Oct 24, 2013 at 2:11 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote: >> The video provider's site establishes a secure >> communication channel between the video >> provider's page on the TV and the video >> provider's servers, proving to the servers >> that Ryan's TV is indeed one of those that >> meets the security requirements by use of >> the cryptographic key and identifier >> pre-provisioned on the TV. > > It seems to me that this is the bread and butter of EME Key Systems. > Since Netflix uses EME anyway, why is there a need to duplicate this > via the Web Crypto API? To expand on this: When playback of a video is about to start, it is clearly the responsibility of an EME Key System to ensure that the video doesn't play unless the "security" (which I take mean DRM robustness) requirements are met. It is weird to suggest that this would also be a use case for the Web Crypto API--especially when Netflix is behind both the EME proposal and the Key Wrap proposal. To the extent different CDMs have different levels of robustness, in order to provide a good experience, it is reasonable to be able to query the robustness level in advance of playback in order to not offer content to the user unless the user's current browsing setup is actually able to proceed to playback. Still, it seems to me that this should be handled via the EME Key System. Experience indicates that the best way to check if a browser is able to do something to try to do it. Having the browser tell you what it supports separately from trying to do it doesn't work. Developers make mistakes or have incentives to make they software lie. E.g. the DOM hasFeature() method was a miserable failure. Therefore, it seems like the wrong design to try to correlate pre-provisioned Web Crypto keys with the robustness level of an EME CDM. Furthermore, it seems particularly wrong to do this using service-specific keys, since it is obvious that multiple services that aren't known in advance will want to query the robustness level. It seems to me that to query the level of CDM robustness in the way that is analogous with the way if feature querying that has been proven to work on the Web is to create a hidden <video> element, load an as short as possible video encrypted and packaged the same way as the actual content on the service into the <video> element and calling .play() on it to provoke an EME message that presumably contains proof of possession of pre-provisioned CDM-scoped keys and, therefore, could be used to make the sort of inferences that the Key Wrap drafts suggests be made from service-specific pre-provisioned keys. Where does this line of thinking go wrong in a way that the Key Wrap proposal would fix? -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Wednesday, 19 February 2014 10:13:00 UTC