What Will They Think of Next?
 

Meanwhile, over at the RIAA, the boys down in the anti-piracy lab are hard at work :eke:

This strategy is doomed from the start...if you did happen to d/l a spoof, you'd delete it - end of story. :uu:

Hmmmm
 

Spoofing........sorta has a ring of familiarity to it, doesn't it?

:f: you Hillary & Co.

as usual, they're fixated on suppressing the symptoms (people downloading free music off the Net) rather than the disease (record companies overcharging, and overcharging for an outdated delivery system at that).

from article
u r right knife. and we always get our songs. the hassle of downloading is part of the pleasure of seeing if u can get a good quality, whole song.
the hunt is on!!!

:f: to them

:beer: to u, knife

in the article, they used Sheryl Crow's Soak Up The Sun as an example - so I figured I'd download it just to see how hard it was....

...and I got 5 good copies in about 5 minutes.

But it's interesting how they would have to execute this strategy...set up multiple user accounts on the P2P networks, with multiple libraries, with hard drives full of spoofs. The article reads like this stuff gets into the P2P networks and runs wild, but I don't see it happening like that. I would think, in most cases, the spoof would get no further than the first time it is d/l'd by any given user.


I think I'll join you in that beer, Nanook
:W:

When did they start the spoofing? I've had the Album (C'mon C'mon) since early April... :PO:

I already ended up with a spoofed file. Right before audioglaxy stopped sharing I wasn trying to get No Doubt's Hella Good, well the first one I got was a 4 minute long continuous loop of the chorus. I found the real song when my searching came up with "real version - No Doubt - Hella Good"

It still is dumb to try and spoof the song though.

This is bad news for the more open networks as it suggests the labels will also employ other more effective technological measures to deter pirates.

One things I've being worried about for a few months now is the potential for injecting garbage data into a multi-source download. Someone, either a concern rightsholder or a malicious user, could make a client that claims to be a source for a file, then sends out random data. The result would be an mp3 with noise and seek errors. I haven't been able to think of a good way to protect against this.

The receiving client would automatically detect such a spoof when calculating hash number for the received file and comparing it to the one being requested. If hashing is applied to partial chunks as well (which is needed anyway if incomplete files are utilized as sources for multisourced downloads), the integrity of the data can be safeguarded at a lower level.

The above measures still leave the problem of 'original fakes' - deceptively named junk files fed into the network. Open networks without verifiable peer identities and trust relationships will remain vulnerable to bad original data even if the problem can be partially adressed by publishing hash numbers for good rips.

- tg ;)

Cuckoo Eggs:MAD:

re hashing and avoiding duds/spoofs/garbage
is anyone here participating in Bitzi?

It seems to be a client/protocol-independent hashing system, with submissions of verified files by users. Not sure how it works really.

How low is this level going to be. If it's too high, then there's a good chance that the rogue source will have contributed to that chunk and the entire chunk will have to be thrown away. On the other hand, if the level is small, a large amount of hash data has to be sent.

Never mind, I started doing the math and it's not as bad as I thought.

Say you have an X byte file. If you download in 10,000 byte (hundreth of a megabyte) chunks from each source, then there will be X/10,000 chunks to verify. Assuming a 32 bit = 4 byte hash for each chunk, that's X/100,000*4 bytes worth of hash information. So, hash information will make up only X/10,000*4/X=.04% of the total download, which is a trivial amount, even if it has to be retrieved for each source.

Creating fakes for music files is kind of a wasted effort in my opinion. For the most part mp3's download relatively fast. It can be a pain for 56k users, but they are still relatively fast compared to movies and software. Also since broadband users can download mp3's quickly, they can easily figure out which ones are real and which are fake, which in turn tells others which ones are fake and which ones are real by simply sharing it. The mp3 files that are shared by many users tend to be correct. If not with that many sources it takes me about a minute or less to download and see if it's real or not.

glad u can do the math...i can't (i don't dispute your figures..i am just envious of them) my mind has a difficult time grasping such abstract concepts. :) :W: <insert :envious: smiley here>

I don't see what the problem is.
The article mentions billboard pop, so they're trying to stop people getting the same stuff they're labelling as 'tasteful' while stuffing it down the average consumer's throat till it's coming out of his ears.

:fm:

Good maths, Scyth. :tu:

Your calculation demonstrates how just a small stream of extra hash information can give us safe multisourced downloads from partially completed files. That is just about as good as it can get at the file transfer level and makes possible fast cascade-like distribution of huge files.

It is enough that there is a single source with the complete original file to calculate the hash numbers for all data chunks included. With that information available the potential downloaders can start searching for the content itself and - as soon as some content becomes available - form a cascade of simultaneously downloading and uploading nodes.

In case of large files the hash numbers themselves could be packed into separate, sharable metaobjects verified by their own hash numbers. For example a 650 MB movie would produce 65.000 10 kB data chunks and with 4 byte hash size this would be approximately 65.000 x 4 = 260 kB of hash data - enough to justify a separate, multisourcable object.

eDonkey must use some sort of chunk hashing mechanism and I also remember reading recently about a Gnutella client experimenting with similar technology.

- tg ;)