- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 16 Sep 2011 12:20:38 -0700
- To: Mo McRoberts <mo.mcroberts@bbc.co.uk>
- CC: Charles McCathieNevile <chaals@opera.com>, "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: <722BF828-8C85-454A-A62F-A79B8A796C97@netflix.com>
On Sep 16, 2011, at 1:42 AM, Mo McRoberts wrote: 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. There is a spectrum of "really determined individuals" with more or less expertise and access to more or less expensive and specialized tools. Robustness rules for content protection systems go into quite some detail about the expertise and tools required to evade them. Also, there is more than one kind of "evasion". A hack which, for example, allowed one person to watch Netflix without paying on a device with a complex hardware modification is very different from a hack which enabled someone to create "freenetflix.com<http://freenetflix.com>", accessible by anyone. So whilst the "do not copy" flag may have some utility (unlike the "evil bit" - http://tools.ietf.org/html/rfc3514), it is not "no different to any other scheme". It takes rights-holders a long time to become convinced about any given system, so our first step should be understanding how the web platform can expose hooks for whatever protection systems happen to be supported by the underlying hardware platform. Just as whatever graphics card a device has is available to web pages through WebGL, there should be a way to access the capabilities of embedded protection systems. ...Mark 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 19:21:18 UTC