For those of you litigating or investigating the investigative work of MediaSentry, we have made available online the MediaSentry exhibits that were used at the October, 2007, trial in Capitol Records v. Thomas, along with the report of the RIAA's "exert", Dr. Doug Jacobson, which recites that he relied upon these materials.
The new trial is scheduled to commence March 9, 2009.
Exhibit 6 (alleged screen shot)
Exhibit 7 ("system log")
Exhibit 8 ("user log" compressed)
Exhibit 9 ("user log")
Exhibit 10 ("download data")
Exhibit 11 ("trace route")
Exhibit 13 ("IM Log")
Jacobson report
Commentary & discussion:
p2pnet.net
Keywords: lawyer digital copyright law online internet law legal download upload peer to peer p2p file sharing filesharing music movies indie independent label freeculture creative commons pop/rock artists riaa independent mp3 cd favorite songs intellectual property portable music player
11 comments:
Well, since that outrageous verdict isn't valid anymore, I guess my comment is just anecdotal, but non the less:
OK, knowing a little bit about *.txt files and nearly nothing about your rules of evidence; Where I in place of the judge that gets such "evidence" I would put the provider of it behind bars for tampering with evidence.
Text files that are printed month/years after the alleged date that they were allegedly automaticly created by this "higly secret proprietary Media Sentry Black Box thingy" and that even bear the full name of the defendant, that is stuff that clearly shows that these files were "Jacobson"ed a.k.a. doctored by hand from a human being with knowledge and information that was NOT available to MediaSentry at the time the "detection of an individual" allegedly took place!
Lets hope the next judge who gets such "evidence" has basic understanding of computer generated textfiles/printouts and demands to see the forensicly sound stored original created files as evidence or hits the Plaintiffs hard for what appears to me -without any knowledge about your FRE though- as criminal activity of fabricating "fake" evidence!
I agree with you Alter Fritz, the "evidence" has been clearly altered. Under the "Best Evidence" rule, only the original un-edited items should have been permitted.
Since some of the items have the name of the defendant, they clearly have been altered from their original form. Clearly they would have NOT had this name on the date it was created, and therefore should have been rejected.
On the Packet logs, they edited the IP address that they were operating from. This is clearly improper, and should have resulted in that item being rejected. If they were attempting to claim a "Trade Secret" on the IP address they were operating on, they should have filed the original under seal, then provided a redacted one as well. However it is likely they did not do this because it is unlikely a Court would allow them to claim an IP address as a trade secret. Even if it was a trade secret, the Defense experts should have been given access to this data under an NDA, as it is needed to evaluate the evidence.
Even funnier is the Traceroute printout provides the missing IP address (0r at least the Gateway of the subnet they were operating from), so they gave the "secret" away anyway.... LOL
This shows the investigation machine was operating from a machine physically located in the State of California. Since MediaSentry is a Maryland company, this seems strange unless they were employing unlicensed investigators in California.
California appears to have strict rules regarding PI's. I found this quote regarding their rules:
"California's Private Investigator Act (“PIA”)(1) prohibits private investigators from committing "any act constituting dishonesty or fraud."(2)The court of appeal in Wayne v. Bureau of Private Investigators and Adjusters(3) broadly applied this prohibition."
The entire proceedure of MediaSentry appears to be at minimum to be dishonest. So during re-trial, the Defendants need to find out who their licensed investigator in California was in this case and turn the evidence over to the Bureau so their license can be suspended. If in fact that person is not licensed, I assume this would be a criminal act.
The site for regulation of PI's in California is www.bsis.ca.gov. Maryland is NOT on their reciprocity list.
Albert
MediaSentry collected a lot of stuff for only having a minor roll in the litigation process and being able to do what any user of the P2P network can do as they claim. I wonder if MediaSentry signed a user agreement with KaZaA before they joined the network?
24) I will testify that, based on the examination of the hard drive supplied by defendant that the songs and album art stored on the hard drive where copied from a high speed digital device like a hard drive on…….
25) I will testify that, based on the examination of the hard drive supplied by the defendant that the songs were not ripped from a music CD using window media player directly on to the hard drive supplied by the defendant.
Notice 24 and 25 together, of course they where not ripped from CD directly to this hard drive. They where transferred from another hard drive. What is he not saying is that they where never ripped from a music CD.
Most of the files in Jacobson Exhibit B are in WMA format. This is not a very popular format among file shares and is the default format for ripping from Media Player. The file names are also consistent with Media Players default Rip Settings. The AlbumArt is also using the filename and format used by Media Player.
21) I will testify that, based on the interrogatory of Jammie Thomas that the MAC address of the cable modem owned by Jammie Thomas…….
Did Jammie own her own cable modem or did she lease it like most people do?
There is also a software error in the user log. The UserLog.txt says “Total Video: 1” there is at least three that I counted the user log. I am only
Someone who knows the fast track protocol needs to review an original copy (not a PDF) of the Downloaded Data log. The packet capture cannot be reconstructed in this format. We need the originals with the binary intact.
I can only add more of what the previous commentors have to say. It's pretty certain that the screen capture program (whichever one that was used) did not produce a 66 page pdf file. I would think that they need to produce an exact digital copy of the original file for it to be used in court.
Ignore the “I am only” then blank line in my post.
Even in the longshot case that the defendant downloaded music in WMA format (ha!), if he owned the CDs, there's a substantial fair use concern there.
I only hope Jamie's attorney whips these people like the dogs they are!
The tracert appears to originate in Ohio, not California.
Kip Patterson
It seems that the pdf server got /.
I can't get to it. But, I did get a chance to look at systemlog.txt and userlog.txt(compressed) and I have some serious concerns/questions about them.
first off systemlog.txt what exactly created this file? What software, what is it a log of?
There's information about a handshake, for each file supposedly.
1) there's way less than 1000+ entries in this log
2) the handshake information is useless, it claims to have a handshake, but it doesn't say with what or whom. There's no IP information on the handshake. Those 'might' be machine addresses, but I don't think so. Sadly the server crashed and I can't look at them right now.
3) userlog.txt looks like it 'might' be a badly cobbled together directory listing. But it's not clear. It's certainly way smaller than the supposed 1000+ files. And yet, it conveniently has a kazaaen.exe file in there.
4) where exactly is this userlog.txt file from, how was it obtained, what piece of software created it?
If I could see the other files, I would have more holes to blow in their case.
Media Sentry needs to be questioned on their practices if said practices are going to be used as evidence in a court of law.
Someone needs to look and question them about their SENT Packet/Received packet time delays.
The very first song: Janet Jackson - Come Back to me.mp3
SENT PACKET: 2/21/2005 11:09:01 PM EST
Received Packet: 2/21/2005 11:09:01 PM EST
That';s identical timing, no time delay at all? No network lag? From California to Minesotta?
The next song, has the EXACT same timestamp, down to the second.
11:09:01 PM for both sent and received.
The 3rd song. Journey - Dont' Stop Believin'.mp3
SENT packet of 2/21/2005 11:09:02 PM EST (1 second later)
But then no received packet at all.
Then there's another sent packet at 11:14:07 PM
and another at 11:14:10
and yet another at 11:19:12, 11:24:18, 11:29:35, 11:34:42. 11:40:28, 11:41:06, 11:41:59, 11:42;37.
Finally a received packet at 11:42:41 PM EST
Why do the first 2 songs reply /immediately/ with no time delay at all, and then the 3rd song, seems to require 10 sent packets, before getting a received packet, some 28 minutes after the original.
The 4th song, is basically the samething. Though it gets a received Packet before the 3rd song. at 11:29:36, after 6 sent packets.
The 5th song, Building a Mystery
Has sent/received packets of the exact same time: 11:09:01
Song 6: Say my nane
Sent Packet 11:09:01 PM
Recieved Packet: 11:09:15 PM
If this was a log file, being created automatically by a computer, I would expect to see all the sent/received to be chronological, and not grouped by song (that's awfully convenient)
If they're claiming they were able to download the entire song in 0 seconds? Or, if this is just a list of what's available for download.
Add to that the obiviously edited aspects of the IP addresses and user name. And it's just highly suspicious
Post a Comment