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.
