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

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

From: Charles McCathieNevile <chaals@opera.com>
Date: Sun, 18 Sep 2011 14:41:08 +0200
To: "GAUSMAN, PAUL" <pg2483@att.com>, "Mo McRoberts" <mo.mcroberts@bbc.co.uk>, "Clarke Stevens" <C.Stevens@cablelabs.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: <op.v1z76uvgwxe0ny@localhost>
On Fri, 16 Sep 2011 19:27:51 +0200, Clarke Stevens  
<C.Stevens@cablelabs.com> wrote:

> 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.

Indeed, I think there is a general understanding that any system which  
requires a particular specific DRM will be a problem.

cheers

> This will be the topic of our first MPTF morning session at the F2F
> meeting next Thursday.
>
> -Clarke
>
> 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.
>>
>> Thanks!
>> -Paul
>>
>> 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
>>> can
>>> 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).
>>
>> M.
>>
>> --
>> 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
>>
>>
>> http://www.bbc.co.uk/
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> 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.
>> 					
>>
>>


-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Sunday, 18 September 2011 12:41:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 18 September 2011 12:41:55 GMT