(In reply to Sergey Konstantinov from comment #0)
> The possibility of proprietary/encrypted license formats to decieve the user
> exposes a potential attack vector. 

You presumably do not mean "deceive". Could you clarify what you mean and provide more detail on the potential attacks ?

> The user agent should be able to read
> license the response and present that information to the user.

A solution in which the UA should present information about every license received to the user is completely broken. We need a way to address this issue without user interaction.

As far as I understand, DRM systems have sophisticated license permissions, such as: allowing local caching; allowing replays; limited license duration; etc. It's quite possible that content providers will have different prices for different licenses.

So, we can imagine some malicious service which sells or re-sells content under limited license to end-user, pretending that license is more capacious than it really is; or some content provider which just "forgot" to mention some severe restrictions.

(In reply to Sergey Konstantinov from comment #2)
> As far as I understand, DRM systems have sophisticated license permissions,
> such as: allowing local caching; allowing replays; limited license duration;
> etc. It's quite possible that content providers will have different prices
> for different licenses.
> 
> So, we can imagine some malicious service which sells or re-sells content
> under limited license to end-user, pretending that license is more capacious
> than it really is; or some content provider which just "forgot" to mention
> some severe restrictions.

I see. Rather than a requirement for the UA to interpret the license directly, I think your suggestion is that exposing the restrictions to be applied by the CDM to the User Agent (and then to the user) would mitigate this form of fraud ?

I don't think reliable detection of fraud this way is practicable or even very useful. The most this could provide would be earlier detection of the fraud i.e. when the license is provided rather than when the user attempts to exercise a right they have paid for and is denied. After that, the user has only the usual remedies for fraud.

As to practicability, it is not at all obvious how one would distinguish fraud from legitimate cases where the license restrictions differ from the product restrictions. For example, in streaming services it is likely that a new license is granted each time the content is streamed, so then there is no connection between license restrictions and product restrictions.

For download cases, one could imagine that a new license is required for each device on which the content is to be played, so then the 'single device' license restriction legitimately differs from the 'multi device' product. Whilst the product may contain a right to view the content in perpetuity, this may still be conditioned on obtaining a new restricted-lifetime license every so often.

Finally, sites may use complex combinations of licenses with differing restrictions in order to deliver the end product to users. For example to show previews, trailers or to speed the startup of playback. Exposing this complexity to users is not unlikely to be useful.

I think discussing this as "fraud" is taking the wrong approach. We're mostly interested in the user getting this extra transparency into what permissions they are granted.

You may be right that this is not useful to the majority of users---in the same way the majority of users do not actually click the lock icon in their address bar and inspect their SSL certificate---but it's important that the capability is present.

(In reply to Domenic Denicola from comment #4)
> I think discussing this as "fraud" is taking the wrong approach. We're
> mostly interested in the user getting this extra transparency into what
> permissions they are granted.
> 
> You may be right that this is not useful to the majority of users---in the
> same way the majority of users do not actually click the lock icon in their
> address bar and inspect their SSL certificate---but it's important that the
> capability is present.

Again, the relationship between the restrictions in the license and the restrictions of the product that has been purchased are not straightforward, so it is not clear to me that exposing this information would be useful even to that minority who are interested. In fact, often it might be quite mis-leading.

Users can easily judge whether the restrictions being applied match the restrictions advertised, just as they can judge whether the content or the content quality matches what was advertised.

It would be like surfacing the bitrate of the first few seconds of the video so that the user can check that they are really getting HD. It just doesn't work because there are many reasons why that bitrate could be less than normal HD bitrates: maybe the first few seconds are mostly blank screens / titles, maybe the first few seconds aren't actually HD because they contain some logo / interstitial but the actual content is HD etc.

While we can debate such use cases, the ability for the user agent to understand and parse messages to the CDM (e.g. licenses) would allow the user agent to validate (and possibly sanitize) data passed to update() before passing it to the CDM as is currently done for the initData passed to generateRequest() (bug 26838).

(In reply to David Dorwin from comment #6)
> While we can debate such use cases, the ability for the user agent to
> understand and parse messages to the CDM (e.g. licenses) would allow the
> user agent to validate (and possibly sanitize) data passed to update()
> before passing it to the CDM as is currently done for the initData passed to
> generateRequest() (bug 26838).

That is a separate issue from the one raised in this bug.

This bug is about giving the UA visibility of the restrictions applied by the CDM. 

There are at least two possible ways this could be done: one way would be to have the UA interpret the license, but another way would be to have the CDM expose the details of the restrictions to the UA. Both are possible in the existing EME architecture and are implementation matters between the UA and CDM. But as I've argued this is not particularly useful to anyone.

Equally, there is nothing in the EME specification which would prevent the UA from validating / sanitizing license messages if the UA implementors felt that was necessary and the messages themselves were amenable to such validation.

> But as I've argued this is not particularly useful to anyone.

As a regular Web user I personally am very interested in this feature. If I pay money for encrypted and uncontrollable content, I want know what *exactly* I've bought. Situations when consumers misunderstand license terms and consider themselves decieved are quite common in a DRM world ([1], [2]), why bring them into Web?

--
[1] http://thomashawk.com/2006/02/hbos-harrasment-of-pvr-owners.html
[2] https://gigaom.com/2011/06/08/apple-icloud-drm/

(In reply to Sergey Konstantinov from comment #8)
> > But as I've argued this is not particularly useful to anyone.
> 
> As a regular Web user I personally am very interested in this feature. If I
> pay money for encrypted and uncontrollable content, I want know what
> *exactly* I've bought. 

The license doesn't tell you that. Please read my comments above.

> Situations when consumers misunderstand license terms
> and consider themselves decieved are quite common in a DRM world ([1], [2]),
> why bring them into Web?

I've not intention of doing so. But what you propose does not solve anything.

> 
> --
> [1] http://thomashawk.com/2006/02/hbos-harrasment-of-pvr-owners.html
> [2] https://gigaom.com/2011/06/08/apple-icloud-drm/

> The license doesn't tell you that. Please read my comments above.

> As to practicability, it is not at all obvious how one would distinguish fraud from legitimate cases where the license restrictions differ from the product restrictions. For example, in streaming services it is likely that a new license is granted each time the content is streamed, so then there is no connection between license restrictions and product restrictions.

> For download cases, one could imagine that a new license is required for each device on which the content is to be played, so then the 'single device' license restriction legitimately differs from the 'multi device' product. Whilst the product may contain a right to view the content in perpetuity, this may still be conditioned on obtaining a new restricted-lifetime license every so often.

This sounds to me just like "current implementations are badly designed". I see no technical problem in developing appropriate license design which explicitly tells user that this "session" license applies only to current session / device. That's still very important to consumer, especially when we talk about different license terms for different devices. Probably we also should think about some kind of two-step licenses - some standardized "master" license describing product restrictions and device- and keysystem-specific "session" licenses derived from master.

(In reply to Sergey Konstantinov from comment #10)
> > The license doesn't tell you that. Please read my comments above.
> 
> > As to practicability, it is not at all obvious how one would distinguish fraud from legitimate cases where the license restrictions differ from the product restrictions. For example, in streaming services it is likely that a new license is granted each time the content is streamed, so then there is no connection between license restrictions and product restrictions.
> 
> > For download cases, one could imagine that a new license is required for each device on which the content is to be played, so then the 'single device' license restriction legitimately differs from the 'multi device' product. Whilst the product may contain a right to view the content in perpetuity, this may still be conditioned on obtaining a new restricted-lifetime license every so often.
> 
> This sounds to me just like "current implementations are badly designed". I
> see no technical problem in developing appropriate license design which
> explicitly tells user that this "session" license applies only to current
> session / device.

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. It would preclude a number of use-cases that we are very interested in and generally restrict innovation. These are two very different things, architecturally, and should not be technically coupled.

The same principle applies if the coupling is 'scoped' (e.g. to a session as you suggest) and such scoping makes the user presentation aspect much more confusing.

> That's still very important to consumer, especially when
> we talk about different license terms for different devices. Probably we
> also should think about some kind of two-step licenses - some standardized
> "master" license describing product restrictions and device- and
> keysystem-specific "session" licenses derived from master.

So, this would decouple the two. The you're talking about some kind of standard rights-expression language. Probably such things exist. This might be more in the realm of teh Semantic Web work.

But then I don't see the advantage of having a machine-readable version of the rights, rather than natural language text presented to the user.

> 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".

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. So right now every content vendor has its own algorithm or policy to translate product license to technical license(s).

As I noted before, this coupling is frequently done badly thus being a constant source of problems and misunderstanding between vendors and consumers. Now we are bringing this problem into the Web, adding (a) potentially infinite number of applications using EME and doing common mistakes, (b) UA as additional potential failure point, (c) interoperability requirement which multiplies number of keysystems supported by each site. In my opinion we have no other choice but standardize technical license formats and their relations to product license.

> But then I don't see the advantage of having a machine-readable version of 
> the rights, rather than natural language text presented to the user.

First of all, I've never seen product license written in "natural language". Quite opposite, EULAs are extremely hard to read even if you are experienced user.

In second, one of the main problems we are trying to solve here is possible fraud when webapp lies about actual technical restrictions.

(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".

(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".

I mean "license" in the technical sense as used in the DRM context: a data object that contains content keys and information about the technical restrictions to be applied.

> 
> > But then I don't see the advantage of having a machine-readable version of 
> > the rights, rather than natural language text presented to the user.
> 
> First of all, I've never seen product license written in "natural language".
> Quite opposite, EULAs are extremely hard to read even if you are experienced
> user.

That's an entirely different issue and anyway, what I suggested is that having a *readable* natural language presentation of the restrictions would be more useful than a machine-readable one and furthermore does not constrain the restrictions to be only those embodied in the rights expression language.

> 
> In second, one of the main problems we are trying to solve here is possible
> fraud when webapp lies about actual technical restrictions.

> 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?

Because in such system user obviously cannot cache video to watch it offline or using poor internet connection. It breaks several important use cases like watching film in a tube or airplane. I as Web user *do* want to know about these *technical* restrictions.

To summarize the discussion: EME brings in a Web inability to manage content; restrictions brought by EME (like you need to reinstate license each time you seek video backwards) are enigmatic even to experienced user leading to possible misunderstandings between consumers, content vendors, browser makers, and DRM system makers. Furthermore we could imagine fraud scenarios exploiting this inability.

We understand that "product" licenses are quite different from "technical" ones, but we are talking about *technical* restrictions since *technical* restrictions are annoying people most. Though I'm proposing to standardize both.

Hi,

I have a blog which is not ranking high in search results. I want to rank the blog higher in search results. Here is the blog:

http://dealingsonnet.tumblr.com/

Any suggestions?

Thanks.

Some points from telcon discussion[1]:

  * Our goal is not to formalize every possible legal term or restriction: we
    are seeking a way to define what *CDM* can possible do. Our concern is about
    «black-hole»-like piece of third-party software installed on user device
    following some instructions sent through the Web.

  * Defining in the spec some rules what CDMs must or must not do is
    better than nothing, though I'd prefer to have a standardized white list of
    such actions and a mechanism of checking what instructions were really sent
    by content provider to CDM.

  * Most obvious cases which should be regulated in my opinion are:
    * terms for caching and pre-caching video frames;
    * terms for replaying content;
    * terms for using content offline;
    * operations requiring internet connection.

--
[1] http://www.w3.org/2014/12/02-html-media-minutes.html

(In reply to Sergey Konstantinov from comment #17)
> Some points from telcon discussion[1]:
> 
>   * Our goal is not to formalize every possible legal term or restriction: we
>     are seeking a way to define what *CDM* can possible do. Our concern is
> about
>     «black-hole»-like piece of third-party software installed on user device
>     following some instructions sent through the Web.

The primary way we address this concern is that the CDM is not a "black hole", as you call it, but very much a known quantity to the UA. The CDM is also quite constrained in what it is responsible for (see below). This is a significant difference from <object>.

In the case of IE, Safari and Chrome, the CDM is provided by the UA vendor themselves. For Firefox it is validated to be the expected code from Adobe and Firefox have considerable insight into what that is / does.

We can discuss what "known quantity" means here. Adobe suggested at TPAC that there could be a requirement for (perhaps 3rd party) source code review.

It's possible that in future some UA vendor introduces a capability to interact with additional 3rd party CDMs. Our specification should be clear that in this scenario we expect the same level of UA oversight as in the initial implementations mentioned above.

> 
>   * Defining in the spec some rules what CDMs must or must not do is
>     better than nothing, though I'd prefer to have a standardized white list
> of
>     such actions and a mechanism of checking what instructions were really
> sent
>     by content provider to CDM.
> 
>   * Most obvious cases which should be regulated in my opinion are:
>     * terms for caching and pre-caching video frames;

The CDM has no control or visibility of caching or storage of encrypted media performed by the UA or application. The CDM decrypts, decodes and possibly renders the media at playback time.

>     * terms for replaying content;
>     * terms for using content offline;

The CDM likely does not generally know whether the device is online or offline (the CDM may not access the network directly for playback-specific operations). So, the primary issue is whether the license is still valid at the time of playback.

We already expose an "expiration" time to the application, but there could be other properties of the license which make it not so useful for offline playback. 

>     * operations requiring internet connection.

The specification is clear that direct network access by the CDM is restricted to origin-independent initialization (e.g. individualization).

> 
> --
> [1] http://www.w3.org/2014/12/02-html-media-minutes.html

(In reply to Mark Watson from comment #18)
> The CDM has no control or visibility of caching or storage of encrypted
> media performed by the UA or application. The CDM decrypts, decodes and
> possibly renders the media at playback time.

Yes, it is. But UA and/or webapp may cache encrypted frames, and they
should be able to know if CDM rejects those frames.

> 
> >     * terms for replaying content;
> >     * terms for using content offline;
> 
> The CDM likely does not generally know whether the device is online or
> offline (the CDM may not access the network directly for playback-specific
> operations). So, the primary issue is whether the license is still valid at
> the time of playback.
> 
> We already expose an "expiration" time to the application, but there could
> be other properties of the license which make it not so useful for offline
> playback. 

Another obvious case is a possibility to purge cache via license response.
I'd prefer this sort of behavior to be somehow formalized.

> 
> >     * operations requiring internet connection.
> 
> The specification is clear that direct network access by the CDM is
> restricted to origin-independent initialization (e.g. individualization).
> 

Okay, let me say it another way: we need to understand cases when CDM may reject
to render content. One case is license expiration, but there are others.
For example, in #13 Henry mentioned that seeking backwards needs new license
to be somehow obtained.

(In reply to Sergey Konstantinov from comment #19)
> (In reply to Mark Watson from comment #18)
> > The CDM has no control or visibility of caching or storage of encrypted
> > media performed by the UA or application. The CDM decrypts, decodes and
> > possibly renders the media at playback time.
> 
> Yes, it is. But UA and/or webapp may cache encrypted frames, and they
> should be able to know if CDM rejects those frames.
> 
> > 
> > >     * terms for replaying content;
> > >     * terms for using content offline;
> > 
> > The CDM likely does not generally know whether the device is online or
> > offline (the CDM may not access the network directly for playback-specific
> > operations). So, the primary issue is whether the license is still valid at
> > the time of playback.
> > 
> > We already expose an "expiration" time to the application, but there could
> > be other properties of the license which make it not so useful for offline
> > playback. 
> 
> Another obvious case is a possibility to purge cache via license response.
> I'd prefer this sort of behavior to be somehow formalized.
> 
> > 
> > >     * operations requiring internet connection.
> > 
> > The specification is clear that direct network access by the CDM is
> > restricted to origin-independent initialization (e.g. individualization).
> > 
> 
> Okay, let me say it another way: we need to understand cases when CDM may
> reject
> to render content. One case is license expiration, but there are others.
> For example, in #13 Henry mentioned that seeking backwards needs new license
> to be somehow obtained.

Henri did say that, but I don't think that kind of restriction can be implemented with EME, at least not reliably.

Timestamps are in the clear in CENC files. If the CDM performs decrypt+decode, it's not necessary for the CDM to be given the timestamps of the frames in any form it could understand. If the CDM is given timestamps, there's nothing to stop the UA ensuing they are monotonic even when the user seeks backwards.

Still, given the variety of ways that the technical license could differ from the product terms in the online case I still don't see how this can be made practical and intelligible to users.

I do see that for the particular case of offline playback, things may be more tractable. For offline, you know that you have got only what you have got in terms of license permissions. 

It might be interesting to explore ways that the restrictions associated with licenses intended for offline use could be exposed. One way is through the (offline version) of the web application, but perhaps there are limits on what can be done that way ? For example, it might be nice to get a reminder if an offline license is about to expire.

Of course, offline case is more interesting (and more problematic). There is
a huge effort to make webapps work offline and to bring reliable storages into
the Web, and, in my opinion, EME spec should be designed keeping that in mind.

(In reply to Sergey Konstantinov from comment #21)
> Of course, offline case is more interesting (and more problematic). There is
> a huge effort to make webapps work offline and to bring reliable storages
> into
> the Web, and, in my opinion, EME spec should be designed keeping that in
> mind.

Offline where the site manages the offlining e.g. with the help of Service Workers and offline where the user manages video files on a file system using Finder/Nautilus/Windows Explorer are *very* different. I think we should avoid scope creep to cater to the latter case, because DRM in the latter case leads to more user unhappiness and more vendor lock-in than DRM in the former case.

Moved to EME GitHub and marked as VNext:
https://github.com/w3c/encrypted-media/issues/194 

/paulc