W3C home > Mailing lists > Public > public-html-media@w3.org > July 2014

Re: Request for feedback on EME Use Cases

From: Wayne Borean <wborean@gmail.com>
Date: Wed, 30 Jul 2014 22:52:47 -0400
Message-ID: <CAHMQTqZF5sratotA1qx_eah_8s5YheBdesSERNzciaWtLCu3PA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Joe Steele <steele@adobe.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Why? You already have to have a key system in place. All this requires is
expanding it from corporate use, to private use.

In simple terms, you'd be issuing a lot more keys.


On Tue, Jul 29, 2014 at 11:49 AM, Mark Watson <watsonm@netflix.com> wrote:

> I'm not sure I follow exactly how such a scheme would work, but in the
> context of EME, any such scheme would be a feature of a keysystem, since it
> is the keysystem that makes the decision as to whether the content can be
> decrypted or not. We don't define keysystem features, though we do
> constrain them somewhat, in the EME specification. So it would seem the
> space is there, technically, for someone to implement your scheme if they
> chose to do so, but the problem is more of a market / political one that we
> are not in a position to solve in our work in W3C.
> ...Mark
> On Mon, Jul 28, 2014 at 9:15 PM, Wayne Borean <wborean@gmail.com> wrote:
>> Joe,
>> I worked as a programmer, a long time ago. There is a way to implement my
>> idea.
>> You'd have to issue a key to anyone who is on file with Collections
>> Canada <http://www.collectionscanada.gc.ca/index-e.html>, and the
>> American equivalent, which would allow them to take down any infringing
>> content, no matter who posted it. If the poster wished it back up, they
>> would have to file suit in the courts over the rights.
>> The problem is, that unless a government agency, or a separate entity not
>> affiliated with any of those companies was set up to run the system, it
>> could be bypassed. Oh, and the costs of a key would have to be affordable
>> for independents.
>> Wayne
>> On Mon, Jul 28, 2014 at 12:58 PM, Joe Steele <steele@adobe.com> wrote:
>>> Hi Wayne,
>>> Thanks for the clarification. Now I understand what you are asking. The
>>> author control problem you are describing for individual creators is
>>> roughly the same problem that studios have today, where they are copyright
>>> holders for content being distributed via file-sharing networks without
>>> their consent.
>>> This standard should make it easier in the long run for content to be
>>> distributed, but it does not provide the content owners any new controls
>>> over how their content is distributed. It provides an explicit mechanism
>>> for one type of control (encryption and key acquisition) and it allows for
>>> providing additional types of control (e.g. output protection). If an
>>> individual creator wanted to publish their content and protect it from
>>> infringing uses by any of the big companies you mention, they could
>>> leverage the protections this standard describes also.
>>> It sounds like you would like to see a mechanism for individual authors
>>> to exercise additional control (TBD) over how content is distributed. If
>>> you have a mechanism to propose, I am sure the group would consider it. Or
>>> if you could describe the use case in more detail (especially how it
>>> differs from the general problem studios have) that might be useful.
>>> Joe
>>> On Jul 24, 2014, at 2:06 PM, Wayne Borean <wborean@gmail.com> wrote:
>>> Joe,
>>> Yes, it has to do with what I said back in 2013. Sorry for not following
>>> up with it then, I've been having some health issues, and have been (up
>>> till two weeks ago) living on morphine. Yes, I was quite stoned. Legally
>>> too :)
>>> Author Control is what the WIPO Internet Treaties
>>> <http://www.wipo.int/treaties/en/ip/wct/> are all about. Specifically
>>> I'm talking about Item 6, Part 1:
>>>  *Article 6*
>>> *Right of Distribution*
>>> (1) Authors of literary and artistic works shall enjoy the exclusive
>>> right of authorizing the making available to the public of the original and
>>> copies of their works through sale or other transfer of ownership.
>>> (2) Nothing in this Treaty shall affect the freedom of Contracting
>>> Parties to determine the conditions, if any, under which the exhaustion of
>>> the right in paragraph (1)
>>> <http://www.wipo.int/treaties/en/text.jsp?file_id=295166#P63_6990>applies
>>> after the first sale or other transfer of ownership of the original or a
>>> copy of the work with the authorization of the author.5
>>> <http://www.wipo.int/treaties/en/text.jsp?file_id=295166#P65_7506>
>>>  Now I haven't been posting, but I have read a lot of the posts over
>>> the last year or so. I didn't see any section of the standard which allows
>>> the author to control distribution. Say I want to cut distribution - how do
>>> I do it?
>>> There are a variety of reasons I'm bringing this up. I know a bunch of
>>> people who've had problems with the distributors. One found his music on
>>> iTunes, which he had not given permission for, and was unable to get Apple
>>> to remove it. His response, which was to release the music for free on his
>>> website, since he wasn't getting paid, was interesting, but probably futile
>>> because most people are used to buying from iTunes/Amazon/etc., and
>>> probably wouldn't normally visit his site.
>>> This is just one example - there are a variety of others, some of which
>>> have lead to amazing court battles. From the artist's point of view,
>>> control is a huge issue, and from my current understanding of the standard,
>>> you are not addressing this. If someone steals your creation, you want to
>>> be able to take action to get it offline now, rather than five years and
>>> possibly millions of dollars in legal fees later.
>>> I know this may not please a lot of people, but a lot of us consider
>>> Apple, Microsoft, Adobe, Amazon, the RIAA members, the MPAA members, the
>>> big book companies, etc. to be the enemy in this. The standard does nothing
>>> to help us. In fact, it may make things worse
>>> Wayne
Received on Thursday, 31 July 2014 02:53:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:04 UTC