This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are a range of use cases for communicating license restrictions on page resources to the user as an input into their decision making process when deciding on their use of the resource. For example, to communicate that the user is not licensed to store a copy of a movie for later viewing. One proposal is to add a 'license' attribute to HTML elements that allow a source resource. The attribute value would communicate the associated license terms, and the format would need to be developed. This is a simple addition to HTML that has a good chance of advancing and being standardized and subsumes all far more complex content protection schemes, such as EME, for use cases that involve either: 1. Cases where a user is free to choose or build an open web platform web browser that gives them access to the decoded resource to use as they wish. In these cases content protection schemes are not effective and thus offer not better protection than the proposed license attribute. These case basically cover the current web platform. It might be argued that the content author can detect the web browser implementation and not deliver content to web browsers that give the user access to decoded state, but the web browser is technically able to spoof any other browser so there is no technical basis for such a content protection scheme either. 2. Encumbered web browsers running on a platform with platform level support for access the decoded resource. For example, a proprietary web browser running on a suitably unencumbered FOSS operating system, or a restrictive build of an open source web browser running on a FOSS operating system. Given that there exist unencumbered open source web browsers, these cases (2) are subsumed by the above cases (1) anyway, because the user can simply choose to use a different web browser if necessary to access a resource. However it might be argued that a content distributor could do a deal with an open source web browser vendor with a larger market share to ship with some default restrictions and that this would give some content protection 'friction', and in this case the existence of an ability to access the resource at the operating system level irrespective of the web browsers dilutes any such claims. The matter of secure transport would need to be managed by orthogonal technology, and it seems sensible to separate orthogonal features where possible. Note: all the EME use cases in which the user is not the adversary would be subsumed by a secure transport extension alone and would not need this license attribute extension. With the proposed license attribute extension, plus a separate secure transport extension, the use cases for the EME not already handled by simpler, well defined, and unencumbered extensions, reduces to encumbered DRM systems putting it into clearer perspective and sensibly limiting its scope to better focus development. A license attribute does not have the security and privacy problems inherent in the EME design, so separating out larger classes of uses cases is a big win.
Can you explain how what you are asking for differs from http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works ?
Thank you for the link to the microdata for 'licensing works'. This could well be a better option than adding a new attribute. The use cases for these 'flags' noted in this bug report must be effectively equivalent to broad classes of use cases for the EME specification. It may well be necessary to add some extra flags to the microdata to ensure these are communicated. For example: a flag that communicates a requirement for secure transport (if deemed necessary), a flag that communicates a limitation on rights to store the resource, etc. A registry of these flags might also be useful. Alternatively, there could be a separate registry that maps the 'licensing works' license URL to a set of flags defining restrictions that the UA might choose to communicate to the user, and this could make it unnecessary to have these flags communicated with every 'licensing works' declaration. The flags should allow the web browser to add an extra conformation step for a 'save as' command informing the user that the content author asserts copyright restrictions on storage. It should be possible for parents to configure the web browser that minors use to disable a 'save as' command for resources with declared restrictions on saving. It should be possible for a popular open source web browser to ship with a default that makes the user wait 10 minutes before allowing the saving of a flagged resource so as to give equivalent 'friction' to the EME specification use cases!
Isn't this also already partially covered by the <small> element? "Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements."
This is not directly related to the <small> element. The <small> element may well be used to communicate a message to the user, just as a <p> element may, but neither gives the semantic information needed to address the use cases in this bug report.
I don't get it? You said: "would communicate the associated license terms, and the format would need to be developed." <small> seems perfect for that. It's also backwards compatible with existing user agents. It also avoid issues that "longdesc" has (and it doesn't require a whole new licensing format to be created).
Comparing EME-based solutions with the proposal+secure transport, in cases (1) and (2) in the origin report, EME provides the opportunity to protect the content key and encoded content, wheresas this proposal+secure transport does not. There are a number of attacks which are possible based on access to the keys and/or encoded content. They are therefore not equivalent.
(In reply to comment #5) > I don't get it? You said: > > "would communicate the associated license terms, and the format > would need to be developed." > > <small> seems perfect for that. It's also backwards compatible with existing > user agents. It also avoid issues that "longdesc" has (and it doesn't > require a whole new licensing format to be created). The use cases require declarative flags that can be used as inputs into computer algorithms. For example, 'max-store: 30m', 'secure-transport: true'. It is not immediately clear how the <small> element would communicate this information?
(In reply to comment #6) > Comparing EME-based solutions with the proposal+secure transport, in cases > (1) and (2) in the origin report, EME provides the opportunity to protect > the content key and encoded content, wheresas this proposal+secure transport > does not. The proposed scope of the use cases for this bug only includes those for which: the user is not the threat and could be expected to cooperate with the content author in protecting the content and may well have a compelling reason to do so such as when the content is watermarked; or when an EME/CDM solution does not effectively protect the decoded digital content from the user accessing it. It is not proposed that this handle use cases requiring the platform to effectively restrict the users access to the decoded content. Obviously the EME/CDM solution could handle all these use cases, as could any suitable conduit to a black box. However there are a large range of use cases that can be handled with the proposed solution and it is much simpler and could be well defined and unencumbered. It would appear possible to define the use cases that are in scope in a technical and objective manner. It would be my hope that doing so would allow this class of use cases to be addressed in a professional manner by myself and others. > There are a number of attacks which are possible based on > access to the keys and/or encoded content. They are > therefore not equivalent. The claim is only that for large classes of use cases that the proposal+secure transport is equivalent. Of the class of solutions for which the user can already technically access the decoded stream, does EME/CDM offer any more protection than the proposal+secure transport?
> Of the class of solutions for which the user can already > technically access the decoded stream, does EME/CDM offer > any more protection than the proposal+secure transport? As I said, EME/CDMs offer the possibilility to protect the keys and encoded content, which are different things from the decoded content. I'm not saying any more than this. To some authors, the ability to easily store the decoded content may be 'just as bad' as easy access to the keys or encoded content and so these solutions may be equivalent. To other authors these things may not be equivalent. That is all.
(In reply to comment #9) > > Of the class of solutions for which the user can already > > technically access the decoded stream, does EME/CDM offer > > any more protection than the proposal+secure transport? > > As I said, EME/CDMs offer the possibilility to protect the keys and encoded > content, which are different things from the decoded content. > > I'm not saying any more than this. To some authors, the ability to easily > store the decoded content may be 'just as bad' as easy access to the keys or > encoded content and so these solutions may be equivalent. To other authors > these things may not be equivalent. That is all. Ok, that sounds like a acknowledgment that there are a large class of use cases for which the proposed solution would be equivalent. Perhaps someone else could elaborate on the other set of disputed use cases: authors who want to protect the keys and encoded content even when the user can access the decoded output. What is the threat in these cases? Why can't secure transport alone offer the needed protection? Is the issue here that storing the encoded content plus the key would be preferable to storing the decoded content, perhaps because the key might be easier for the user to protect than a large decoded, or recoded but unencrypted, blob? Perhaps a 'store-securely' flag would address this matter? If we could understand the scope of these use cases then it would be possible to either address them with a simpler solution or declare them out of scope of the proposed solution.
(In reply to comment #10) > (In reply to comment #9) > > > Of the class of solutions for which the user can already > > > technically access the decoded stream, does EME/CDM offer > > > any more protection than the proposal+secure transport? > > > > As I said, EME/CDMs offer the possibilility to protect the keys and encoded > > content, which are different things from the decoded content. > > > > I'm not saying any more than this. To some authors, the ability to easily > > store the decoded content may be 'just as bad' as easy access to the keys or > > encoded content and so these solutions may be equivalent. To other authors > > these things may not be equivalent. That is all. > > Ok, that sounds like a acknowledgment that there are a large > class of use cases for which the proposed solution would be > equivalent. > I did't make any statement about the relative size of the classes of use-case. > Perhaps someone else could elaborate on the other set of > disputed use cases: authors who want to protect the keys and > encoded content even when the user can access the decoded > output. > > What is the threat in these cases? > > Why can't secure transport alone offer the needed protection? It's not for me to elaborate the threat models that are of concern, because those concerns differ from author to author. If you want to learn the details, scope and variety of content protection requirements - for example from studios and others - then you need to talk to them. You're not going to learn that here. Nevertheless, one example is that given easy access to the keys, one could harvest the keys for a whole catalogue and use those to set up a service providing free access to that catalogue, using the service providers own distribution system and any browser. So the situation is very different from individual users saving decoded content files using custom software. Also, re-encoding the entire Netflix catalogue costs us millions of dollars, so access to encoded content is clearly a very different thing from access to decoded content. > > Is the issue here that storing the encoded content plus the > key would be preferable to storing the decoded content, > perhaps because the key might be easier for the user to > protect than a large decoded, or recoded but unencrypted, blob? > > Perhaps a 'store-securely' flag would address this matter? > > If we could understand the scope of these use cases then it > would be possible to either address them with a simpler > solution or declare them out of scope of the proposed > solution. Your statement is true, but if your goal is to design a new content protection system that improves on those already in the market for some class of content then you need to talk directly to your prospective customers.
(In reply to comment #4) > This is not directly related to the <small> element. The <small> element > may well be used to communicate a message to the user, just as a <p> element > may, but neither gives the semantic information needed to address the use > cases in this bug report. I object to introducing a feature that requires the browser to interpret a REL, since that would bring the complexity of managing restrictions out of the CDM into the browser. (But I'd also object to requiring CDMs to interpret a REL. I think decisions that one might imagine a REL to cover should be performed by the server by deciding the either allow or disallow data flows into the CDM given knowledge about what the CDM is designed to hide.) I also object to introducing features that make the scope of DRM potentially broader than video. I request that this bug be WONTFIXed.
(In reply to comment #12) > (In reply to comment #4) > > This is not directly related to the <small> element. The <small> element > > may well be used to communicate a message to the user, just as a <p> element > > may, but neither gives the semantic information needed to address the use > > cases in this bug report. > > I object to introducing a feature that requires the browser to interpret a > REL, since that would bring the complexity of managing restrictions out of > the CDM into the browser. (But I'd also object to requiring CDMs to > interpret a REL. I think decisions that one might imagine a REL to cover > should be performed by the server by deciding the either allow or disallow > data flows into the CDM given knowledge about what the CDM is designed to > hide.) It is not technically possible for the server to have 'knowledge about what the CDM is designed to hide' unless the CDM and platform is already implements strong DRM, and this bug only deals with non-DRM solutions. If the user has control over their computer then they can access the decoded stream without the knowledge of the server and thus it is not possible for the server to control access to content on this basis. Further, it would seem to be far more consistent with the open web development process to document the flags in open and unencumbered specifications rather than deferring to a black box. > I also object to introducing features that make the > scope of DRM potentially broader than video. The scope of solutions for this bug do not include DRM - it specifically deals only with the non-DRM use cases. > I request that this bug be WONTFIXed. Given that the claimed technical basis for objecting to this bug is invalid, and that it is clearly not introducing DRM support, I request that it remain open for further discussion.
An elegant solution to the purported non-DRM use cases of EME was proposed last year: http+aes (http://html5.org/tools/web-apps-tracker?from=7011&to=7012). It was later removed from the spec, because there weren't actually parties interested in solving those non-DRM use cases. That the purported non-DRM use cases of EME are red herring has already been established. EME is really about DRM. If there were parties who really needed those non-DRM use cases addressed, we could revive http+aes. In the meantime, it's unproductive, time-wasting and potentially even more harmful (e.g. inadvertently broadening the scope of DRM) to propose alternative solutions to the purported non-DRM use cases in order to make a point that has already been made. I stand by my request for this bug to be WONTFIXed.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21231#c14 and note there are no indications of implementer interest in this, nor indications of much webdev interest.