- From: Mo McRoberts <mo.mcroberts@bbc.co.uk>
- Date: Fri, 16 Sep 2011 23:47:59 +0100
- To: Mark Watson <watsonm@netflix.com>
- 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>
On 16 Sep 2011, at 20:20, Mark Watson wrote: > 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. Which all makes sense until: a) those tools are distributed far and wide; or b) you don't need to bother breaking the protection yourself because somebody else (who *does* have the time, expertise and tools) has done it and distributed the content in an unprotected fashion illicitly already. Experience suggests that both of these tend to happen relatively quickly, at which point your threshold for 'determinedness' ends up being relatively low, irrespective of what level it was initially pitched at. > 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", accessible by anyone. The former is a matter of access-control, surely? If so, that's rather separate — and doesn't suffer from the same 'hand the keys over' problems as DRM, and conflating the two isn't necessarily helpful (although both are part of a content protection strategy). The mind boggles at how a sensible access-control system is evaded by a remote device being modified, though — can you elaborate? Not being a Netflix user (not being geographically located in an amenable fashion), I'm unfamiliar with “freenetflix.com”. It doesn't seem to exist now, so I'm assuming a non-technical solution was employed to resolve a non-technical problem. > 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". Within the context of those schemes which don't operate in closed systems, it's very difficult to see the difference beyond a short lead time for those who are both inclined to evade it and have sufficient technical knowledge to look beyond the immediately-available options. If it *is* a closed system then it's pretty moot, as what amounts to a “do not copy” flag is all you need (sure, somebody could get into hardware modifications at this point, but they'd be easier getting it on a PC, or finding somebody else who has done the hard work for them already). > 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. could you clarify 'protection systems… supported by the underlying hardware platform'? what protection systems, beyond those which again boil down to "do not copy” flags which are passed to connected devices, are supported by -any- underlying hardware platform today? 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
Received on Friday, 16 September 2011 22:49:01 UTC