PDA

View Full Version : P2P Spy Article


View Full Version : P2P Spy Article


Kooperman
September 11th, 2003, 03:16 AM
Teamwork brings P2P spying app closer


By John Borland
Staff Writer, CNET News.com
September 10, 2003, 5:23 PM PT


For much of the last year, the University of Wyoming and a company called Audible Magic tested technology that looked inside students' file swaps for copyrighted music, with an eye toward ultimately blocking the transfer of such material.
The job turned out to be harder than Audible Magic expected. On Wednesday, the company said it had given up on part of its network-spying technology and had instead teamed up with an established network-security company. The identify-and-block product still will be offered, but it will now be a joint venture between Audible Magic and security company Palisade Systems, the companies said.

"We recognized that we would have challenges trying to work with the type of bandwidth we were looking for, (such as) inside an ISP," said Audible Magic Chief Executive Vance Ikezoye.




The product is one of the most ambitious among those being designed to rein in unauthorized trades of copyrighted works online, and it carries with it some of the most potentially serious privacy concerns. Most other services, such as Packeteer, work by blocking or controlling the amount of bandwidth available to file-trading applications, rather than by looking inside the transmissions themselves.

Audible Magic's own technology specializes in identifying songs by their digital "fingerprints," or acoustic characteristics.

But combined with Palisade's network-security technology, it could become a powerful monitoring tool for network administrators or copyright holders. The joint product is designed to intercept all traffic on a network, make a copy of it, and then make a running examination of that copy for items such as Kazaa or Gnutella traffic.

When it finds digital packets originating from file-swapping software packages, it will compare the contents against Audible Magic's database of fingerprints. If it finds a match to a copyrighted song, it will stop the transmission of a song in progress, even if some of the file has already been transferred.

"The nice thing about content--if you've only got half of a song, it's worthless," Ikezoye said. "I think in general it's about a third of the way in that we ID and block" an average song.

Analysts say the product is likely to be well received by universities and companies. Internet service providers, which are typically protective of their subscribers' privacy, might be a more difficult sell, however.

"I don't think Comcast or Verizon would voluntarily put this kind of monitoring in place," said Forrester Research analyst Josh Bernoff. "Users would consider it intrusive."

CaptainMorgan
September 11th, 2003, 06:10 AM
Originally posted by Kooperman
When it finds digital packets originating from file-swapping software packages, it will compare the contents against Audible Magic's database of fingerprints. If it finds a match to a copyrighted song, it will stop the transmission of a song in progress, even if some of the file has already been transferred.

Interesting. Mathmatically futile. See Oxymoron thread.

triniti
September 11th, 2003, 10:16 PM
well kazaa hashes the first 300k of any file in theory a movie and an mp3 could have the same finger print, i have seen first hand results of this, so what if it is kazaa/altnet(paid content) material with a hash footprint that they are killing? Anyway just in general a crappy idea...Good luck Audible. EDIT: Not to mention the F#$%ing resources it would take to load up a huge database of hashes and compare millions of them to every passing sequence of packets.... Like I said crappy idea....

jonnymnemonic
September 12th, 2003, 12:30 AM
Comparing hashes isn't that bad - any industrial strength database could do that kind of comparison in less than a second. In fact, a fast Oracle server could probably handle thousands of comparisons a second.

But digital fingerprints are much more complicated than mere file hashes. Changing the data stream in ANY way will change a good hash. But (for example) reducing the volume or increasing the bass on a song will not change its fingerprint. However, a fingerprint has to involve an audio stream that endures for some significant amount of time. I doubt it's possible to effectively digitally fingerprint Stairway To Heaven with any 5-second slice of the stream and if it IS, then that song alone would have quite a few fingerprints that would identify it, which wouldn't make things easier.

The CPU resources for digital fingerprint analysis on any scale would be enormous. I mean, a really truly vast amount of CPU power. It would be extremely expensive to do that, privacy concerns aside. And the fingerprints HAVE to involve audio streams with durations of significant length because there ARE legal fair uses for sampling. You can't embed Stairway To Heaven in its entirety in a song, but if you make a parody of it (or whatever), it's okay to embed a small portion of it.

Who's going to want to dedicate a massive CPU farm to doing this? I'd be surprised if they get many, if any, customers.

eivioolla
September 12th, 2003, 12:38 AM
Encryption anyone? Especially HTTPS so they can't even differentiate the traffic from any secure web traffic.

CaptainMorgan
September 12th, 2003, 07:35 AM
Originally posted by jonnymnemonic
The CPU resources for digital fingerprint analysis on any scale would be enormous. I mean, a really truly vast amount of CPU power.

What I am really saying is it is even harder than that. Na Na Na...

Given any fingerprinting technology, be it a hash or otherwise.
Now given any ONE file of any size and length.

The total number of fingerprints that CAN be said to match that file is equal to the total number of fingerprints/hashes in your system. This holds for all fingerprinting systems. Even if the number of possible fingerprints is infinite.

How could this be true? Easy, the total number of ways to encode any file is EVEN MORE infinite. (fingerprints are intended to be easily comparable summaries of non-infinite length) Really, the number of POSSIBLE ways to encode any particular file is a REALLY big infinity.

It is not even computationally intractable. It is plane impossible.