Whoops! I spoke too soon!

My post did not allow for comments. Let us see if this one does....

Installed Intense Debate commenting system (I hope!)

Time for something new. I heard about Intense Debate on the net@nite podcast, so decided to give it a try.

Further thoughts on peer-to-peer enclosure delivery

The advantage of peer-to-peer enclosure delivery is that the delivery is decentralized. Lower bandwidth costs, and there is no central server bottleneck. But I think this very decentralization is bad for the music industry. The network could more easily be corrupted, so that a legitimate enclosure is replaced with an enclosure filled with copyright protected music/software etc.

If such material appears on a centralized server today, it is easy to for the industry to shut it down. I believe that the industry thinks that peer-to-peer breaks this model.

For example, say that your multiple existing enclosure protocol, and bittorrent is adopted as is by iTunes. There is nothing to stop an unscrupulous podcaster from having the rss include two non matching enclosure: a legitimate conventional non-peer-to-peer file that he claims responsibility for, and and an illegal enclosure that is launched through bittorrent. Then if iTunes then picks up the enclosure via bittorrent , then iTunes can be accused of delivering illegal music. By adding a signature to the rss feed, iTunes would be able to verify the bittorrent delivery, by matching the signature of the received enclosure with the signature of the rss feed that had been served by the originating site.

A music industry watchdog could use the same information to nail the unscrupulous podcaster: If the signature of an illegal enclosure matches the signature published on the originating site (and it would have to to keep iTunes happy) then they have proof of the guilt of the podcaster. iTunes and the industry could then filter out pirate podcasters.

So even though delivery is decentralized, the signature assures that responsibility is still centralized.

Message Digests and Enclosures

Using Message Digests to secure Enclosure and to provide accountability

I have been following with great interest the Podfathers Adam Curry and Dave Winer, so I listened with fascination to Rob Greenlee's, interview Adam on itconversations.com.

A current concern is bandwidth. Presently Podcasts are served from a central server. Popular podcasts would generate large bandwidth, load and data requirements on that server: expensive. A more distributed architecture, whether through mirrors or peer-to-peer file sharing could alleviate the problem.

So I was particularly interested on Adam's take on bittorent as a peer-to-peer file transfer protocol and his belief that it was not secure and not Hollywood-friendly, and thus would not be adopted by Apple's itunes. That got me to thinking. I believe that the entertainment industry has no problems with today's podcasting, is due to its accountability: If the podcast violates copyright, the industry knows precisely who they can go after: the owner of the podcast website where the infringing .mp3 file sits. However, with peer-to-peer file sharing, the file sits in the ether, and the accountability disappears. Now if there was a way to tie the received file back to the originating website, the accountability link is restored and, I believe, this possible objection by the entertainment industry evaporates.

One way of doing this would be to place a message digest of the .mp3, on the originating website. (A Message Digest is a short string calculated from the file that virtually uniquely identifies the file: It is computationally very difficult to come up with a different file that has the same message digest. So if a file that is received (presumably from a different source through peer-to-peer, mirrors, etc.) has its message digest match the one on the originating website, it is certain for all intents and purposes that the file originated there and that it is that websites owner that is responsible for the content. By the same token, if the message digest doesn't match, it is could be that the file has been tampered with.)

The message digest is a very short file, so it is possible for the aggregator to download it directly from the source website without excessive bandwidth requirements. This can be used for security purposes. This would have a benefit for the originator who wishes to collect statistics on how many times the enclosure is downloaded, as the receiving aggregator would check back with the originator to verify the message digest when the enclosure itself is downloaded from another (mirror or peer-to-peer) site.

My First Post

Hi everyone. Just saying hi for now...