[ NNSquad ] Re: Speculation, how AT&T can implement "copyright filtering" without wiretapping/dpi...

[Warren Kumari <warren@kumari.net>]

On Jan 28, 2008, at 1:56 PM, Edward Almasy wrote:

> On Jan 28, 2008, at 11:54 AM, Nick Weaver wrote:
> > Thus all the schemes for "video DNA" and "audio DNA" tracking are
> > robust in the arms race, at least with a bit of effort.
>
> I believe you're grossly underestimating the power of even the  
> existing tools for obfuscation, as well as the ingenuity of the  
> programmers involved.
> Encryption is not my field, however I have implemented a few  
> encryption and/or obfuscation routines in my time, as well as a few  
> media identification algorithms, and I'm fairly confident that it  
> will always be easier to come up with new ways to hide digital media  
> DNA than it is to come up with ways to accurately identify that  
> hidden DNA amongst the oceans of data streaming across the 'net.   
> It's difficult enough to accurately automatically identify a media  
> stream when it's *not* obfuscated, given the number of encoding  
> permutations in use.  When someone is actively working to prevent  
> that identification *and* you need to have an identification method  
> that's efficient enough to be run in real time on the quantities of  
> traffic in question, well...

Even with no obfuscation the computational complexity to identify a  
video, audio or picture[0]  is very, very high, even if it is re- 
encoded to the same format -- re-encoding to a different format makes  
this process much harder.

The computational complexity for the sender to obfuscate this is very  
low  (a simple, low cost system would be for the sender to encrypt the  
traffic and scatter the key throughout the file -- this would require  
the receiver to have the whole file before being able to read any of  
it).

Even if the sources could be identified, blocking "just that graph  
using router ACLs," is severely non-trivial, both from a technical[1]  
and an administrative standpoint[2].

The cost to identify the content is large, the cost to block the  
devices is large -- and how long the solution would be viable for is  
unclear, convincing people to shell out lots of cash for something  
that doesn't add to the bottom line (and probably takes away from the  
bottom line[3]), and may only work for a short time is really hard.

W
> Keep in mind that:  A) at least in the case of video or audio, we're  
> not talking about identifying bit-for-bit copies, but rather digital  
> streams encoded using any one of hundreds of scheme and parameter  
> permutations, each of which results in a distinctly different binary  
> stream, and  B) because the obfuscater can count on a human being  
> available to play a part in the de-obfuscation of any content before  
> use, they can take advantage of obfuscation techniques that are  
> impossible (or at least impractical) to wholly implement in content  
> identification software.
>
> ANYWAY, to get back to the original point, the spidered blocking  
> idea certainly has merit, if applied judiciously with due process.   
> Fortunately that due process will likely involve some degree of  
> human judgement, which will mean that possible problem content  
> identification can be far less accurate (and thus far more viable to  
> implement) without inflicting collateral damage on the innocent.
>
> Ed

[0]: Wavelets allow you to identify pictures, even after much  
obfuscation, but a: this doesn't work for video, b: its very costly.
[1]: The cost for an ISP to upgrade routers to support large ACLs (at  
line rate) is huge.
[2]: Taking a feed of things to block is a REALLY REALLY bad idea for  
an ISP -- convincing your CTO that you should place the stability off  
the network in the hands of a third party is really hard  (what  
happens with the third parts messes up and instructs you to block 0/0?  
or 192.5.5.241?)
[3]: If an ISP ACLs off part of their customer base (or blocks access  
from their customer to content), eventually the customer gets unhappy  
and walks.