Tuesday, August 12, 2008

Practice tip: Take MediaSentry's deposition

In view of the growing number of investigations into MediaSentry's unlicensed investigations, and the false and contradictory statements its lawyer and RIAA are giving to law enforcement agencies, this would be an excellent time to take MediaSentry's deposition, and find out where the truth lies.

See, e.g.

MediaSentry's statements in Michigan administrative case contradicted by prior statements in UMG v. Lindor

MediaSentry lawyers write to State Police, saying MediaSentry doesn't need a license,

RIAA files more papers opposing motion to quash in Boston, admits MS got 'cease & desist' letter, argues 'making available' violates Copyright Act, and

RIAA protests Oregon AG's request for discovery into RIAA 'investigatory' practices.

8/13/08, 7:50 PM EST
Be sure to look at the comments section of this post, as people are starting to weigh in with suggested questions to use at MediaSentry's depositions. Here are the interrogatories the Oregon Attorney General wanted answered.

[Ed. note. I was trying to do just that in UMG v. Lindor, but the RIAA asked for permission to drop its case. -R.B.]

Commentary & discussion:


Keywords: 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


Scott said...

"...this would be an excellent time to take MediaSentry's deposition, and find out where the truth lies."

Or perhaps where the lies lie.

Alter_Fritz said...

Ray asked Where the "truth lies"

That one is easy too!

Arnold Schwarzenegger and Jamie Lee Curtis as Harry and Helen Tasker in True Lies. Made 1994 by Lightstorm Entertainment


David Donahue said...

Something I'd be sure to ask Media Sentry is how they synchronize the clock of their detection server with the clock on the Target ISP's DHCP server. Without them matching closely false identifications can easily take place.

Another thing I'd love to ask them regards how and who set up and runs their detection server. If this server device is to be legally treated like a tape recorder, video camera or radar gun then only the people who built, setup and maintain it can testify to it's accurate calibration.

Also, who is the individual who was running this device when the detections occurred? Are they a licensed private investigator in the state where the detection took place? Did this person actually download music from the IP they detected offering torrents? Is that whole songs or just data fragments? What percentage of the song was downloaded? Were there others offering the same torrent for downloading? Who were they? Why are they not named codefendants in this suit? If a normal bittorent user were to download the song what percentage of it would have come from the defendant vs. these other unnamed individuals?

Regarding expert vs. fact witness testimony from Media Sentry: Is the person giving this deposition the person who was running the detection server at the time of the alleged infringement? Are the detection server logs and case file the personal notes of the deposee or are they notes of someone else? Who? Why are they not giving this deposition? Is the deposee testifying to facts he has personal knowledge of or is he making conclusions as an expert? Is he an expert in ISP network operations and DHCP server systems administration? Is he an expert in the bittorent protocol and software client? is he an expert in MS own detection software (if yes, how does it work in detail)? Is the fact he is testifying to is that the report and file says "x" and not a detection he had any personal knowledge of? (note: anyone can testify to this if handed the report & file). Can the deposee testify that the data in the logs was not modified since the detection? How is the detection server's log database secured against data modification by viruses, worms and hackers? If this database were used for financial transactions would they still consider this sufficient protection? Do their data security and development standards meet the legally mandated ISO 27001 standards? Why did they use a lesser data security methodology? How does he know, by personal knowledge, that their database and log files were not compromised and changed before the print off of the logs took place? Who at Media Sentry has sufficient administrative access to the log database to change its files and content? Would an audit record have been made of any potential log data modification? Does that same individual have the ability to change / eliminate these audit records? Does the deposee have personal knowledge that such a data modification audit doesn’t and hasn’t existed?
With the kind of fluff I'd heard coming from Media Sentry, any good deposition should tear their facts and methodology to little tiny threads. If the questions asked in the deposition don’t require a significant percentage of Media Sentry’s Development, QA, Operations and networking teams to answer them, you’re not trying hard enough.

Ray Beckerman said...

Good comment, david, very good comment.

Anyone else got some good ideas for MediaSentry's deposition?

Anonymous said...

Let me get my 2 cents in:

If SafeNet/MediaSentry is using custom software on the KaZaA network to track down users sharing files on the FastTrack system, how did they create this software to ensure that they are getting the results they believe they are getting?

Did SN/MS reverse-engineer the KaZaA client and/or protocol in violation of applicable laws? If so, who did the actual reverse-engineering work, and where? (We need to know this in order to question how valid the investigation software actually is.)

If you are using the regular KaZaA client, which version(s)? How do you know that the KaZaA client you used faithfully reports the source of the download, as opposed, for example, that the data received by you traveled through one or more SuperNodes, proxies, routers, or other devices that may affect the IP address on its way to you?

If you have the KaZaA source code, how did you get it? How do you know it's valid?

What are the known flaws in your system? What ways can your system be evaded, which may reveal flaws in your methodologies?

Did you know what state the detected computer resided in at the time you were invading it to gather evidence? Do you have a valid state-issued Investigator's license for that state? Do you have a state-issued Investigator's license for the state you were in when you performed this investigation? Do you have any state-issued Investigator's license(s) at all?

Because it's easy to use Internet services available to the public to identify the state, and often the county and even zip code of an IP address, did you take the simple step of determining the likely physical location of the computer you were invading while you were invading it? If not, why not? If you did, why did you continue once you realized you were not authorized to investigate in that state?

How do you select your targets to gather data on? What role does the KaZaA user's name play in this process?

Do you listen to every file you download? What is your expertise to know if the file you've copied is a valid copyrighted work? What is your response if the file your download is "damaged" in any regard?

How do you prevent multi-sourced downloads?

Have you ever altered any piece of data, including rearranging or reformatting it, to create a more positive outcome for your employer?

Have you ever had lost or scrambled data on your computer, including hard drive crashes?

Can you verify, especially if you're using commercial KaZaA clients, that included adware/spyware hasn't affected your results? How can you verify this?

Have you ever used "illegal" or "unlicensed" software in any of your investigations?

Have you ever used "illegal" IP addresses in the course of your investigations? Illegal IP addresses are any IP address not registered to your company or you personally.

How do you coordinate your efforts with other companies (e.g. Media Defender, Big Champagne et. al.) also involved in investigating, measuring, spoofing, detecting, or otherwise interdicting P2P filesharing?

Can you provide an image copy of every hard drive used in this investigation for forensic analysis by the Defense? (Note: Your are on notice not to destroy any evidence that may be subpoenaed during this investigation of your methods.)

What is your education to perform this task?

Please produce all source code used by all programs in your investigations of my client.


Ray Beckerman said...

Good one, anonymous XxX.

Anonymous said...

David, they probably avoid torrent like the plague because there's so little information, and only parts of files, exchanging hands.

Ray, to follow up on David, then.

1. What kind of security does MediaSentry have on its own machines? If its machines are compromised, its data is unreliable.

2. How many times has MediaSentry been told that the IP address they were looking for was not used at the time of the alleged file sharing? This is a known error rate in their process.

3. How does MediaSentry know if a wireless router is used? If are router is using NAT, all traffic from behind it will have the same IP. When can MediaSentry even tell this is happening?

4. If MediaSentry is pursuing a KaZaA user and using KaZaA itself to download the files and check authenticity, is there a chance that MediaSentry will simply mis-click and download the file from someone else sometimes? What safeguards are in place to detect this?

5. Is MediaSentry violating KaZaA's terms of service? If so, pay attention to cases mentioned at http://virtuallyblind.com/2008/07/14/blizzard-wins-sj-mdy/ and http://www.secureworks.com/research/blog/index.php/2008/07/02/false-positives-in-the-legal-system/ Maybe you can do something interesting with them.

6. What client is MediaSentry using? KaZaA itself? On Windows XP or Vista?

7. What packet sniffing software is MediaSentry using? How do they know that the packets they sniff correspond do the files they're downloading using MediaSentry?

8. How can MediaSentry tell if a song belongs to the RIAA? Do they have just one version (the album release, say) that they pursue, leaving live versions alone?

9. Who does the downloading? Does that person take screenshots of the uploaders' shared files? At the time of the downloading?

10. Are the people doing identification tasks multitasking? If so, how often do they produce screenshots that are later discovered to be labelled incorrectly (i.e., for the wrong person)?

11. How can MediaSentry explain its requests for names of IP address users that didn't exist at the times indicated by MediaSentry? This suggests a fundamental breakdown in MediaSentry's processes.

12. How does MediaSentry synchronize its computers to a standard time server? Does MediaSentry do this? How often?

13. How does MediaSentry distinguish between songs a person ripped from their own CDs and ones the person downloaded?

14. What degrees does MediaSentry hold? What education in computer security?

15. If a router is used with NAT and people behind it use the same KaZaA username, can the RIAA tell them apart?


P.S. I have a question not for MediaSentry. If I own a CD and download a song from it instead of ripping the CD because I'm lazy, is my download legal? Is there precedent?

XTX said...

I would want to know if criminal background checks had been performed on all of the people working with the data at MS.

Ray Beckerman said...

All riggghhhhhttttttt.......

now we're rollin'.

On behalf of all the defendants' lawyers out there...thank you. This is going to be fun.

Ray Beckerman said...

Here are the interrogatories the Oregon Attorney General wanted answered.

Justin Olbrantz (Quantam) said...

Hmm. I'll have to put some thought into this, if I can be muster the effort. While some of the suggestions are good, many of them come off sounding like a fishing expedition. In general, I'd say pick a handful of questions that are most likely to provide troublesome (for the RIAA) information.

Albert said...


A few thoughts on topics to cover:

I would especially pound on the "No such Address" items, including deposing everyone who was preparing ANY notes in regard to this case. This is a very weak item in their case, as there should never be a case where an unused IP address is identified. Since the connections are made via TCP, it proves a device at the other end responded, and the address could not have been spoofed.

Looking over the traceroute captures (if any, and if not WHY) might reveal errors in transposing digits or otherwise mis-reporting the IP addresses.

If automatic capture software is used, it would be expected to work the same way each time. However I strongly suspect these cases are NOT done automatically, but under the direction of a human operator, as the process is likely too diverse to automate. The multitasking aspect has already been covered, and conducting more than one investigation at a time could lead to mixing up the results between the cases. Also, the actual operator needs to be examined, as only that person has direct knowledge of the facts.

Another important question is the TOTAL amount of time that was actually used on a given case. Due to limited upstream bandwidth in most cases it takes 100-200 or more seconds per song to download. The beginning and end time for all downloads need to be examined and compaired to the expected time based on the available upstream bandwidth. This is because the "normal" mode for most p2p clients is to grab small pieces of each file from the many available sources. If the file came down faster than the physical limits of the upstream of the victim, it proves the entire file was NOT entirely downloaded from the victim, and that the other suppliers of data on the downloads should have been joined as co-defendants. (Of course the fact the plaintiff may not be able to detect more than one ip at a time makes this a bit hard). Pin them down in this case as to the number of bytes total that was downloaded from the target, as opposed to any other device. If the target only supplied say 5% of the bytes, they should be only able to collect 5% of the damages at most, and the fact they cannot identify the others is not the target's problem.

Also, if the observation was made for only a few minutes/hours how can a statement of continuing infringement be made based on that limited observation.

Because of the extended time for each download, this is the reason that the clients are likely overlapped. They should not be able to collect for any more files than they can prove were downloaded. Also, the number of files would have to be limited by the available bandwidth and the total time of observation.

As an example, if MS observed a target for 30 minutes total, and their upstream bandwidth limits them to 1 file per 3 minutes, they cannot claim more than 10 songs during the observation period. My guess is in most of these cases, they did not observe long enough for more than a handful of files to be transferred.

Question them on their connection to the internet as well. I suspect they use VPN's to other locations to hide, as many P2P users block known MS ip addresses. Logs of all devices using the connection and their bandwidth comsumption is important to the case, as this might also limit their download speed.

Once you get the information from MS, you may then need to ask questions of the Network Admin of the ISP in question. Questions on if the traceroute actually matched the design of the network, and the means of time server sync would be questions to ask. You might also may be able to use this person if they have had the "no ip found" problem to explain the problems with MS's case. MS should have traceroutes even for the bad IP cases, since until the ISP responds, MS would not know which is good and which is bad.

Lots of questions on where the investigations took place, including states where they VPN'ed or tunneled to or from would provide lots of evidence for those going after them for unlicensed investigation. It would also identify other states where they communicated thru, but were not licensed in.

Also, questions on what efforts were made to identify during the investigation what state the targets are in.


Anonymous said...


You misunderstand the situation. We're brainstorming suggestions for a *deposition*. Of course one might expect MediaSentry to have good answers for most of these questions. But if nobody asks, even obvious mistakes will be missed.

Secret methods are often flawed in secret ways.


Sebastien said...

The source code question is very good. You can use the MpAA vs Google (I forgot which actual company it is) request againt them. After all, if it's alright for them to ask for source code, it should be acceptable for them to turn over source code. Afterall, why is their method of detecting infringers "proprietary and a trade secret" it's being used as evidence in Federal Court.

Anonymous said...

Also, don't forget to ask how many false positives on file names have shown up. P2P filenames are often wrong about the group, and even the song, that they allege to contain. The RIAA is big on wanting to include a listing of an entire share directory found with the implication that every filename listed is "proof" of a copyrighted work being distributed. Those files may be no such thing (which is why they probably angle so hard to get the hard drive image).

Additionally, listed files may be incomplete for any of a variety of reasons. Is it infringement to share an incomplete file?

Also, what do you do if the directory name isn't \Share, but something otherwise more personal and private that doesn't seem to blatantly announce distribution?


Alter_Fritz said...

and remember dear university lawyers:

plain copies or even copies of printouts do not count, since that kind of processing/handling of the evidence files does not preserve evidence! (see the RIAA argument in Howell)

So ask for the original HDDs (resp. forensicly sound bitidentical copies produced by a licensed lawenforcement agent knowledgeable in creating forensicly sound evidence images of digital evidence) that MediaSentry is using/has used in the computers with which they allegedly detected the copyrighinfringements allegedly commited by your students!

Ray Beckerman said...

This in from Slashdot's "Nefarious Wheel":

I see no significant error in how the disjunct between TCP-IP address and MAC (Media Access Control) is presented.

However, there is a new trend in technology that adds a further layer of indirection, and that's the trend toward "virtualisation", or the use of Virtual Servers within the context of a hosted PC operating system. These are products such as Microsoft's Virtual Server or VMWare equivalent "appliances" such as the Dekki Wiki appliance, Sun's Virtual Box, Citrix' XEN server and other similar implementations.

An operating system is, at the core, just another program. These virtual server products run an instance of another operating system inside a window, as a separate entity. They're relatively straightforward to use, as in it takes no special expertise to implement, and thus are pretty much accessible -- often at no charge -- to anyone with a modicum of computer savvy.

Where this gets interesting in terms of relating IP addresses to MAC addresses is that the MAC address is no longer associated with a specific piece of hardware, as was the case in the past. If you're running more than one instance of a virtual server (the other PC in the corner of my desk is an example, running several technical Wikis simultaneously) then each virtual server instance requires its own MAC address to run its simulated network address card. This means one machine might have several independent MAC addresses simultaneously. Not only that, but since the MAC address is dynamically generated, there is no guarantee that the MAC address one virtual instance presents will be retained from one system reboot to another.

To further complicate things, there is nothing wrong with one of these server instances running it's own IP registration service, e.g. a DHCP (Dynamic Host Configuration Protocol) server, BOOTP (the legacy Unix equivalent) and serving up addresses to any PC wanting to associate itself to the Internet.

In fact, in many commercial installations there are many Windows servers sharing the same piece of hardware. Further, which piece of hardware a particular operating system instance may run on can change dynamically due to load balancing operations (ref Microsoft's recently-released product, their "System Center Virtual Machine Manager" product.

This is mainstream technology now. In my professional role I see (and specify) some fairly large server farms based on this technology, and can categorically state that the identification of a MAC address, formerly used to identify an individual machine by its IP address, is no longer definitive.

Hope this is of some use. I think you'll find this fairly easy to corroborate.

TRMcDougle said...

Oregon AG interrogatory 6 asked about documents referring to the IP adress in question. This is a good point to consider since some of the information may serve to indicate innocence rather than guilt and I doubt it would then be used in the court cases! (For instance a different Kazaa username on the same IP address, in a short time frame, or even interleaved, which would suggest an open accesss point or NAT.)

Anonymous said...

- Did MediaSentry download all songs from the same username/IP address pair?
- Did MediaSentry ever see that IP address with a different username? Did it even look?
- Did MediaSentry ever see that username with a different IP address? Did it even look?


Ray Beckerman said...

david donahue wrote:

"-Where are the actual song files you allegedly downloaded from the defendant's PC?
(note: the defendant needs a hard disk image of the MS PC system that downloaded this for forensic analysis and verification).

-Did you compare the song files taken from the defendant's PC with the files that you personally downloaded from the suspected file sharer PC?
-Were they byte for byte identical?
-If there any any differences in any of the files what leads you to think that you have actually identified the right defendant's PC?

(Practice tip: Media Sentry should have to submit to the court a copy of the allegedly downloaded song files BEFORE the plaintiffs have access to the disk image of the Defendant's PC and also the defendant's experts should be able to compare these files and validate they are the same).

-What safeguards are in place to prevent mixing up the song files on your Media Sentry Download PC and the files taken from the defendant's PC?
-Who at Media Sentry has access to bypass these safeguards? (Tip: The defense would need to validate that these individuals could and did not do so).
-Did you find CD ripping software on the defendant's PC?

-Using this software, did you rip a copy of the original CD's possessed by the defendant to generate file version of the songs?
-Are these files identical to either the files found on the Defendant’s PC image and/or the files allegedly downloaded from the Suspected file sharing PC? (note: even if they are the same it does not nessesarily mean that the defendant shared them).

If they have actually identified the correct defendant, actually downloaded files and handled them properly with required safegards, these questions should pose little difficulty for Media Sentry.

Heh heh heh - They're toast..."

Anonymous said...


First of all, emphasise the "chain of custody" issue in deposing MdS people. They went into this planning to litigate, so they should observe the highest standard of evidence collection and preservation.

Then there's the ISP people. Take the DHCP log custodien through chain of custody and protection from change stuff, more gently, since they did not plan to use the logs in court. Ask about reliability from his point of view, and suggest that keeping material that is not fit for purpose (for litigation) is a waste of everyones time.

Take the administrator who handles the Main Distribution Frame (where all the cables come in from outide) through the relation between cable, MAC address, IP address, and account. Ask how a customer or an outsider can get access using an account he does not own. This is where IP hijacking and sniffed or social engineered logon credentials come in.

Take a help desk person through complaints and service requests about the possible exploits. Note that you can add their estimates together, since it is unusual that a problem will be noticed by both.

It might be better to chat informally with the ISP people, then write a declaration for them to sign.