- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 10 May 2013 13:39:41 -0700
- To: "B. Ross Ashley" <brashley46@tfnet.ca>
- Cc: public-html-media@w3.org
- Message-ID: <CAEnTvdB6cM_vFqdAEaG8NPEm5op+y=DZfRej4p+MEm_m=+5PEw@mail.gmail.com>
On Fri, May 10, 2013 at 8:10 AM, B. Ross Ashley <brashley46@tfnet.ca> wrote: > On 13-05-10 10:25 AM, Mark Watson wrote: > > [Moving to public-html-media] > > Sent from my iPhone > > On May 10, 2013, at 6:21 AM, Casey Callaghan <caseyc37@gmail.com> wrote: > > Having a look over the documentation on EME (encrypted media > extensions), I find the following: > > > The user should not be restricted from accessing content for which legal > rights have been obtained. > > (source: https://dvcs.w3.org/hg/webtv/raw-file/tip/mpreq/cpreq.html) > > I also find the following statement in the First Working Public Draft ( > https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html > ): > > > Support simple decryption without the need for DRM servers, etc. > > This is a necessary corollary of the previously quoted statement; if > servers are needed to view legally purchased content (even if only to > obtain decryption keys), then the legally purchased content will be > unavailable if and while said servers are down. > > However, as soon as secure decryption is discussed, I find that a DRM > server begins to form a vital part of the process. I have no doubt that > many content providers will accept only the most secure decryption methods > for their content; this leads to well-known problems should the content > provider's servers ever go offline. > > This can be mitigated, to some degree, with multiply redundant servers or > cloud computing. However, these solutions may be expensive and are unlikely > to be kept running when it would be unprofitable to do so (for example, > when the sales of a given piece of media have ended; possibly after an > interval after that ending). This could also be impractical for smaller > content providers, without large budgets. > > Therefore, in order to resolve this, I would like to propose for > consideration the following idea (based on the serverless encryption scheme > for Bitcoin): > > - that, when a user purchases legal access to a given piece of media, a > message (signed with the content provider's private key) must be sent to > all clients informing them of this purchase; > - that all clients may (and are indeed encouraged to) keep a record of > all such messages from all providers; > - that any client, in possession of both the signed message from the > content provider (verified by means of the content provider's public key) > giving a given user legal permission to view certain media, and the data > required to decrypt that media (either the CDM or the key obtained from the > same content provider), may provide either the CDM, or the key, or both to > the user on authorised request. > - that any client which does so must inform the content provider's server > and all other clients of such access, if the key is limited in any way. > > In this way, a DRM server going offline does not prevent a user from > viewing content to which they purchased a valid license before the server > went offline. This appears to be a necessary consequence of the stated aims > of this standard. > > > You are making an assumption that the legal rights purchased are > perpetual and independent of the continued operation of the service from > which they are purchased. > > This may not be true in all cases and indeed may never be true for > exactly the reasons you give above. > > For example, in the case of Netflix, the legal right to watch the > content extends for only 8 hours or until the Netflix client application is > closed, whichever is sooner. After that the right must be requested again > and this is only possible if Netflix servers are still operating and you > are still a subscriber. > > I would agree that the mechanism above is an interesting concept for > perpetual, service-independent rights, but support for this case is not one > of our requirements (as discussed in the bug titled 'EME depends on servers > with a finite life' - I don't have the number to hand). > > ...Mark > > Casey > > So: if, as a content provider, one wishes to sell, rather than lease > access to, a copy of one's own work, one cannot depend on this scheme to > protect one's rights, as one's right to sell rather than lease is not > provided for at all ... > If you wish to sell a perpetual right to use a piece of content that is later independent of the operation of any particular infrastructure, then as John pointed out, you can use EME to deliver a perpetual license and then have the license stored by the user, with the content. As far as I can see, the only reason you would need to go back to the license servers every time (as Casey assumed), for content where you have been sold ongoing rights, is to check and re-check that the device is authorized. Which you only need to do if that authorization status might change (i.e. device revocation). So, what is not supported by EME is the ability to revoke devices, combined with the idea of a perpetual license which provides continuing access after the service goes offline. I would hazard that reconciling these two things is extremely difficult. Perhaps Casey's idea is on the path, but I think it would be extremely complex to levitate a sufficiently trusted distributed network, such that it would reliably check device authorization and only skip that part in the case that the original service really is no longer extant. So, perpetual, service-independent licenses stored at the client are supported and re-checking device authorization on every playback is supported, but not both together. ...Mark > > -- > B. Ross Ashley > registered Linux user 548111 > >
Received on Friday, 10 May 2013 20:40:13 UTC