W3C home > Mailing lists > Public > public-web-and-tv@w3.org > September 2011

Re: DRM / copy protection Re: Web and TV Accessibility

From: Clarke Stevens <C.Stevens@cablelabs.com>
Date: Fri, 16 Sep 2011 11:27:51 -0600
To: "GAUSMAN, PAUL" <pg2483@att.com>, Mo McRoberts <mo.mcroberts@bbc.co.uk>, Charles McCathieNevile <chaals@opera.com>
CC: "silviapfeiffer1@gmail.com" <silviapfeiffer1@gmail.com>, Robert Pearson <robert.pearson@ami.ca>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <CA98E297.1131B%c.stevens@cablelabs.com>
Yes, this is the general consensus. We need to be able to use DRM and
provide some common parameters, but there is no will to specify any
specific DRM.

This will be the topic of our first MPTF morning session at the F2F
meeting next Thursday.


On 9/16/11 10:53 AM, "GAUSMAN, PAUL" <pg2483@att.com> wrote:

>I think that Web and TV requirements should be agnostic to DRM types and
>accommodating of them, as an option.
>Q me
>-----Original Message-----
>From: public-web-and-tv-request@w3.org
>[mailto:public-web-and-tv-request@w3.org] On Behalf Of Mo McRoberts
>Sent: Friday, September 16, 2011 4:43 AM
>To: Charles McCathieNevile
>Cc: silviapfeiffer1@gmail.com; Robert Pearson; public-web-and-tv@w3.org
>Subject: Re: DRM / copy protection Re: Web and TV Accessibility
>On 16 Sep 2011, at 08:08, Charles McCathieNevile wrote:
>>> Understanding that copyright metadata would be attached to the file,
>>>but that is likely not a concern for someone stealing it.
>> True - although in many cases it *is* sufficient. A surprising amount
>> be achieved with information and goodwill, although it is important to
>> understand the limits...
>I'd be inclined to agree, on the whole.
>Being pragmatic about this, if the aim were to be "a copy-protection
>system that was both freely-implementable yet broadly effective" (which I
>believe it should be - because otherwise, by definition, it's something
>which is in the hands of the few, and so runs counter to the principles
>of the Web and most software which interacts with it), then technical
>measures are not beyond the bounds of possibility - I'd be wary of
>discounting the effectiveness of the mainstream browsers paying attention
>to a "do not copy" flag.
>The nub is that any DRM system, unless it operates within the context of
>a closed system, involves handing both the keys and the content protected
>by those keys to a user who does, as far as the system is concerned, have
>legitimate access to both. If that user subsequently decides to make use
>of the material they've been handed to make illicit copies, and is
>technically able to do so, then they will.
>Much of the work around copy-protection has been predicated upon "we're
>going to use crypto to protect our content, so put as much effort as
>possible into keeping the keys from people we don't want to have them";
>given that (for the difficult cases people put in lots of effort into
>trying to solve) you don't know who you don't want to have the keys until
>after they've already obtained them, this is a logical failure.
>However, if you go back to the basics of what it's actually *for*, but
>accept the reality that in handing somebody both a lock and a key, there
>will be people capable of inserting the key into the lock and turning it,
>then you're left with a problem-space of "how can a copy-protection
>scheme be implemented which puts illicit copying beyond the effort
>threshold of the majority, but still allows the maximum number of
>legitimate users to enjoy the material?". A solution to that of "a
>'please don't copy this' flag which Internet Explorer, Chrome, Opera,
>Firefox, and Safari all honour" satisfies that aim, possibly in
>combination with things like time/session-dependent identifiers and so
>forth. Sure, the really determined individuals will evade it, but that's
>no different to any other scheme.
>Given that, the real question is less about whether the W3C or this group
>in particular would support it, but whether Microsoft, Google, Apple,
>Mozilla and Opera would agree to implement it (and subsequently, whether
>rights-holders could be convinced that it was no worse from their
>perspective than any other mechanism, and permit distributors to make use
>of it).
>Mo McRoberts - Data Analyst - Digital Public Space,
>Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
>Room 7066, BBC Television Centre, London W12 7RJ,
>0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
>This e-mail (and any attachments) is confidential and may contain
>personal views which are not the views of the BBC unless specifically
>If you have received it in error, please delete it from your system.
>Do not use, copy or disclose the information in any way nor act in
>reliance on it and notify the sender immediately.
>Please note that the BBC monitors e-mails sent or received.
>Further communication will signify your consent to this.
Received on Friday, 16 September 2011 17:30:47 UTC

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