- From: <bugzilla@jessica.w3.org>
- Date: Sat, 09 Mar 2013 13:23:36 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21231 Bug ID: 21231 Summary: License descriptor attribute Classification: Unclassified Product: HTML WG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: HTML5 spec Assignee: dave.null@w3.org Reporter: fredandw@live.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-admin@w3.org, public-html-wg-issue-tracking@w3.org 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Saturday, 9 March 2013 13:23:41 UTC