- From: <bugzilla@jessica.w3.org>
- Date: Fri, 24 Oct 2014 09:32:31 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27055 --- Comment #13 from Henri Sivonen <hsivonen@hsivonen.fi> --- (In reply to Sergey Konstantinov from comment #12) > > I think a design which explicitly required license restrictions to be matched > > to product restrictions for the purpose of user interaction would be a very > > bad design. > > First of all, "license" is a legal term. If we say that "license" in EME > spec doesn't match actual licensing agreement (at least in its technical > part) and it's impossible or undesirable to setup such coupling -- then we > should stop calling it "license". EME talks about "license" as a DRM term of the art. It may be an unfortunate term of the art, but I don't think the TAG gets to decide it doesn't exist. > In second, this coupling in some form must be implemented by content vendors > since they must somehow adjust DRM system settings to reflect EULA terms. Consider a ToS that says "You may watch any movie available via this service as many times as you like while your subscription is valid. Your subscription is renewed in one-month increments." and has a DRM-level "license" that says "you may use this key for a single playback within one hour". It follows that the JavaScript program needs to obtain a new DRM-level "license" at least hourly and also any time the user seeks the video backwards (since the CDM isn't allowed by the DRM-level license to decode the content twice). Why do you think it's useful to surface this implementation detail to the user if the user-facing experience is that they get to use the service for longer than an hour (until they cancel the subscription) and they get to seek backwards? (In reply to Sergey Konstantinov from comment #8) > I want know what *exactly* I've bought. I think the problem is that you assume that EME involves you "buying" something. The purchase use case is not the use case driving EME, though EME doesn't take technical steps to absolutely foil that use case. (I wouldn't object to the TAG issuing a warning about the dangers of attempts to use EME for purchase-to-"own" scenarios where the users are supposed to manage "purchased" files.) The use case driving EME is (subscription) streaming. The crux of how subscription streaming addresses the conflict between DRM and users buying something is not to remove the appearance of permanent purchase to own and to be overt about the ability to play content being ephemeral (for the duration of the subscription; streaming rental just becomes a very short subscription to a particular title) and there being no pretense of the user getting to hold onto anything they've "bought". -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 24 October 2014 09:32:32 UTC