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

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.

Received on Friday, 16 September 2011 16:53:37 UTC