./acs-law.co.uk/andrew.crossley/cur/1281173676.H197274P22678.mail2.dfsv61.com,S=53341_2,S

Return-path: <acslawsb+caf_=sbirdsey=acs-law.co.uk@gmail.com>
Envelope-to: sbirdsey@acs-law.co.uk
Delivery-date: Fri, 04 Jun 2010 16:11:03 +0100
Received: from foundry4.dataflame.co.uk ([91.103.220.248])
	by mail2.dfsv61.com with esmtp (Exim 4.69)
	(envelope-from <acslawsb+caf_=sbirdsey=acs-law.co.uk@gmail.com>)
	id 1OKYXk-0001qv-BL
	for sbirdsey@acs-law.co.uk; Fri, 04 Jun 2010 16:11:03 +0100
X-Envelope-From: acslawsb+caf_=sbirdsey=acs-law.co.uk@gmail.com
X-Envelope-To: sbirdsey@acs-law.co.uk
Received: From mail-wy0-f178.google.com (74.125.82.178) by foundry4.dataflame.co.uk (MAILFOUNDRY) id YGdVbG/zEd+3TAAw for sbirdsey@acs-law.co.uk; Fri, 4 Jun 2010 16:08:12 -0000 (GMT)
Received: by wyb29 with SMTP id 29so900808wyb.9
        for <sbirdsey@acs-law.co.uk>; Fri, 04 Jun 2010 08:10:41 -0700 (PDT)
Received: by 10.227.146.75 with SMTP id g11mr10780915wbv.130.1275664241432;
        Fri, 04 Jun 2010 08:10:41 -0700 (PDT)
X-Forwarded-To: sbirdsey@acs-law.co.uk
X-Forwarded-For: acslawsb@gmail.com sbirdsey@acs-law.co.uk
Delivered-To: acslawsb@gmail.com
Received: by 10.227.155.67 with SMTP id r3cs3933wbw;
        Fri, 4 Jun 2010 08:10:40 -0700 (PDT)
Received: by 10.227.135.7 with SMTP id l7mr2784596wbt.204.1275664240291;
        Fri, 04 Jun 2010 08:10:40 -0700 (PDT)
Received: from mail2.dfsv61.com (mail2.dfsv61.com [91.103.216.62])
        by mx.google.com with ESMTP id e9si4025530wbb.90.2010.06.04.08.10.38;
        Fri, 04 Jun 2010 08:10:38 -0700 (PDT)
Received-SPF: neutral (google.com: 91.103.216.62 is neither permitted nor denied by best guess record for domain of jonathan.miller@acs-law.co.uk) client-ip=91.103.216.62;
DomainKey-Status: good
Authentication-Results: mx.google.com; spf=neutral (google.com: 91.103.216.62 is neither permitted nor denied by best guess record for domain of jonathan.miller@acs-law.co.uk) smtp.mail=jonathan.miller@acs-law.co.uk; domainkeys=pass header.From=jonathan.miller@acs-law.co.uk
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=acs-law.co.uk;
	h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:Importance:X-MimeOLE:Thread-Index:In-Reply-To:X-ACL-Warn:X-Source:X-Source-Args:X-Source-Dir;
	b=La2lhcUh+kBbJaBfsUaO9tRCZ623OOfnyiUD8/Qn3Icm03Y3re4tlIUvz0ZYu75EjyBp4Moop5ZhoG6p5Qlei78O3GDBb3MTbbllrAchSecV09eHBMvL7KYAjwZr41CO;
Received: from [88.211.49.82] (helo=2c3dc1b649b04b2)
	by mail2.dfsv61.com with esmtp (Exim 4.69)
	(envelope-from <jonathan.miller@acs-law.co.uk>)
	id 1OKYXa-0001p6-Ky; Fri, 04 Jun 2010 16:10:34 +0100
From: "Jonathan Miller" <jonathan.miller@acs-law.co.uk>
To: "'Alireza Torabi'" <alireza@ng3sys.com>
Cc: <acslawsb@gmail.com>,
	"'Andrew Crossley'" <andrew.crossley@acs-law.co.uk>
Subject: RE: IMPORTANT:  Data Monitoring Processes - LITIGATION STAGE
Date: Fri, 4 Jun 2010 16:10:24 +0100
Message-ID: <7D47F50ADBD54C9B8029428399474E71@2c3dc1b649b04b2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.6856
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Thread-Index: AcsDxkLXMWUzE8zPTN29JJlL9adaRQAMbPcg
In-Reply-To: <4C08C3C1.8080403@ng3sys.com>
X-ACL-Warn: {
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail2.dfsv61.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acs-law.co.uk
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Status: No, score=0.6
X-Spam-Score: 6
X-Spam-Bar: /
X-Spam-Flag: NO

Thanks for this Ali.  We'll get back to you shortly, if any further
questions.

Have a good weekend.

-----Original Message-----
From: Alireza Torabi [mailto:alireza@ng3sys.com]
Sent: 04 June 2010 10:14
To: Jonathan Miller
Cc: acslawsb@gmail.com; 'Andrew Crossley'
Subject: Re: IMPORTANT: Data Monitoring Processes - LITIGATION STAGE

Hi,

Please see followings:

Regards,
Alireza


>    1. Would you kindly give me a brief rundown of what you do,
>       specifically how you capture the data, what tools you use and how
>       the process works?
Even briefly it'll be a long story.

The main capturing software is my modified and updated software "xTrack"
that runs on top of a P2P client software called "Transmission".

For each content (ie. an item that is being shared on P2P) xTrack finds
all peers (ie. computers running a P2P client software that are
connected to that content) and disregards all that are not in the UK by
filtering non-UK IPs. Once a UK peer is found, xTrack checks to see
whether or not they understand P2P protocol. If yes, then xTrack checks
whether or not they are uploading the content to its P2P swarm (ie, all
peers uploading/downloading that content). If yes, 3 different pieces of
that content are downloaded by xTrack and checksum -ed to establish 1)
the peer is uploading/seeding content and 2) the pieces are part of that
content. This will happen every day for a specific peer. All above
transactions are logged by xTrack.


>    2. How do you know or more importantly, should I say, what technical
>       information have you gathered which indicates to you that the
>       evidence has a high degree of credibility?
Once an IP is uploading/seeding to a P2P swarm, it's 100% safe to assume
that the data is coming from that IP unless ISPs who are transporting
the packets between that IP and xTrack are somehow modifying its data,
very unlikely and I'd say virtually none.


>    3. Andrew mentioned to me that, when you capture the data from the
>       infringer, it is in the form of data packets. Would it be possible
>       to somehow convert these data packets into viewable formats (i.e.
>       AVI or mpeg)? This way, we would be able to visually marry the
>       evidence together with our client's Works, thus present the
>       evidence in an easily recognisable format to the court.
Pieces downloaded for each content (read movie) are on average 512KB to
8MB in size for movies and this highly depends on that size of movie in
its whole. Now, for example if there are 3 pieces of that content it's
about 1-3 (on average) minutes of that content and they are almost
always of different parts of it, ie. 1:13 (hh:mm:ss), 18:32 and 1:02:02
into movie in a 1:30:00 movie. So visually you'll see a flash or jumps
from scenes to scenes if you put them together PROVIDING the compression
used in the AVI or MPEG is recognized by the Playback software depending
on the positions of the pieces in the movie.

>    4. In relation to question 3, would you be able to return to us any
>       and all data packets pertaining to each infringer's case (as well
>       as the converted viewable versions, if possible) upon request?
Yes. As Andrew said only for those ones you specify, otherwise you'll
need a CD/DVD production plant for all of them to be delivered to you.


>    5. What is GUID? How does GUID relate to File ID as contained within
>       the Statement Report of our LoC? Where does GUID fit into your
>       data capturing process?
GUID in LoC is a Ghrapical Unique IDentifier, 40 characters long that a
P2P client software assigns to itself when it starts up. It'll stay the
same until it restarts again.
When pieces are downloaded, a whole host of information regarding the
uploading peer is logged as well as this GUID. It's a good data part
plus the ISP details of the peer that allows to filter out duplicate IPs.

>    6. Does the File ID identify our client's Works exclusively?? Would
>       it be possible that multiple copies of the same Work is being made
>       available by infringers with different File IDs??
File ID is a hash that is almost globally unique for contents shared on
P2P networks. Copies of the same work (read client's work) will have
different File ID but copies of the same content are just copies and
basically will have the same File ID. File IDs are just there to
determine the copies of the contents on P2P networks.

It's very possible and a common practice actually for a client's work to
be shared with different File IDs ie. via different P2P contents.

To marry a File ID to a client's work, the original should be provided
by clients and then visually checked against the content for a %100
accuracy.