W3C home > Mailing lists > Public > public-html-admin@w3.org > March 2013

[Bug 21231] New: License descriptor attribute

From: <bugzilla@jessica.w3.org>
Date: Sat, 09 Mar 2013 13:23:36 +0000
To: public-html-admin@w3.org
Message-ID: <bug-21231-2495@http.www.w3.org/Bugs/Public/>
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 on the CC list for the bug.
Received on Saturday, 9 March 2013 13:23:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:22 UTC