- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 16 Sep 2011 18:22:46 -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>
Sent from my iPhone On Sep 16, 2011, at 3:48 PM, "Mo McRoberts" <mo.mcroberts@bbc.co.uk> wrote: > > 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 Tools can include expensive pieces if hardware, such a digital signal analyzers. > > 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. > This was the point of my example below. > 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. This is not our experience. > >> 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. The point of my examples was to illustrate the difference between attacks that are hard to replicate/distribute and those that are not. freenetflix.com is a hypothetical site offering our service for free. I was only intending to illustrate this difference, not give practical examples. > >> 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. I'm not exactly sure what definition of 'closed system' you're using, so maybe we are talking at crossed purposes. But my point is just that all approaches are not equal: some systems are much harder and take much longer to break and this makes a real difference to their utility. > > 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). Again I'm not sure what kind of close system you imagine here. > >> 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'? For example when a system as a whole, or a Trusted Execution Environment on an otherwise open system, uses hardware features to realize a secure boot feature leading to a secure (non-customer-toptable) OS. A protection system such as PlayReady could be run in such an e > > 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? Such systems exist on pretty much all Internet-capable TVs and BluRay players currently sold in the US, at least, and are bing worked on by several mobile/tablet chipset makers, I believe. ...Mark > > 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 Saturday, 17 September 2011 01:23:59 UTC