<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: Once More On Downloading</title>
	<atom:link href="http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/</link>
	<description>by Derek Slater</description>
	<lastBuildDate>Fri, 05 Dec 2008 12:07:35 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joe</title>
		<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/comment-page-1/#comment-4395</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Sat, 26 Jul 2003 21:49:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/#comment-4395</guid>
		<description>&lt;a&gt;&lt;/a&gt;

you&#039;d have to intercept packets coming from a sharer going to a &quot;downloader&quot; (not sitting on a proxy)... that in itself is probably pretty illegal (right? at least without the proper warrant). Then you&#039;d have to determine what was being sent from the sharer to downloader and if this infringes your copyrights.

&lt;p&gt;A far easier way (but more specific) would be to get the address of a sharer (which is being done as we speak by the RIAA) and park close enough to determine if they have a wireless network... if so, then you could sniff the wireless packets (wireless encryption is &lt;a href=&quot;http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html&quot;&gt;pretty weak&lt;/a&gt;) and tell what&#039;s going in and out of the sharer&#039;s network.  Determine what files are being sent, and who to... subpoena the downloader&#039;s IP address (it&#039;s just so easy isn&#039;t it?) and send them a c&amp;d. I don&#039;t want to get too far into territory that is too technical for me... someone else should chime in.</description>
		<content:encoded><![CDATA[<p><a></a></p>
<p>you&#8217;d have to intercept packets coming from a sharer going to a &#8220;downloader&#8221; (not sitting on a proxy)&#8230; that in itself is probably pretty illegal (right? at least without the proper warrant). Then you&#8217;d have to determine what was being sent from the sharer to downloader and if this infringes your copyrights.</p>
<p>A far easier way (but more specific) would be to get the address of a sharer (which is being done as we speak by the RIAA) and park close enough to determine if they have a wireless network&#8230; if so, then you could sniff the wireless packets (wireless encryption is <a href="http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html">pretty weak</a>) and tell what&#8217;s going in and out of the sharer&#8217;s network.  Determine what files are being sent, and who to&#8230; subpoena the downloader&#8217;s IP address (it&#8217;s just so easy isn&#8217;t it?) and send them a c&amp;d. I don&#8217;t want to get too far into territory that is too technical for me&#8230; someone else should chime in.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/comment-page-1/#comment-4393</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 26 Jul 2003 18:06:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/#comment-4393</guid>
		<description>&lt;a&gt;&lt;/a&gt;

But let&#039;s say there&#039;s no SSL encryption - how easy is it then?</description>
		<content:encoded><![CDATA[<p><a></a></p>
<p>But let&#8217;s say there&#8217;s no SSL encryption &#8211; how easy is it then?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe</title>
		<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/comment-page-1/#comment-4391</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Sat, 26 Jul 2003 16:42:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/#comment-4391</guid>
		<description>&lt;a&gt;&lt;/a&gt;

Cracking SSL encryption (which is what we use when at Amazon or Wells Fargo) is a pain in the ass.  You&#039;ve literally got to search key space [1] which takes days.  So even lightweight encryption is &quot;a good thing&quot;&#174;. I think a better idea would be a widely distributed p2p proxy server... this would mean that you would appear to be surfing from all over the world in a single session... and it would be &lt;em&gt;really&lt;/em&gt; hard to figure out who&#039;s who. 


&lt;p&gt;[1] Check out &lt;a href=&quot;http://pauillac.inria.fr/~doligez/ssl/press-conf.html&quot;&gt;this guys&lt;/a&gt; quote:
&lt;blockquote&gt; Not much. Everybody who understands the technical details knew perfectly well that this was doable and even easy. You have to understand what happened exactly. I did not break SSL itself. I did only break one SSL session that used the weakest algorithm available in SSL. If I want to break another session, it will cost another 8 days of all my machines.
&lt;/blockquote&gt;</description>
		<content:encoded><![CDATA[<p><a></a></p>
<p>Cracking SSL encryption (which is what we use when at Amazon or Wells Fargo) is a pain in the ass.  You&#8217;ve literally got to search key space [1] which takes days.  So even lightweight encryption is &#8220;a good thing&#8221;&reg;. I think a better idea would be a widely distributed p2p proxy server&#8230; this would mean that you would appear to be surfing from all over the world in a single session&#8230; and it would be <em>really</em> hard to figure out who&#8217;s who. </p>
<p>[1] Check out <a href="http://pauillac.inria.fr/~doligez/ssl/press-conf.html">this guys</a> quote:</p>
<blockquote><p> Not much. Everybody who understands the technical details knew perfectly well that this was doable and even easy. You have to understand what happened exactly. I did not break SSL itself. I did only break one SSL session that used the weakest algorithm available in SSL. If I want to break another session, it will cost another 8 days of all my machines.
</p></blockquote>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/comment-page-1/#comment-4390</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 26 Jul 2003 08:05:41 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/#comment-4390</guid>
		<description>&lt;a&gt;&lt;/a&gt;

Yeah - the way I was thinking about it was: we use encryption on Amazon and such to keep people from viewing transactions, right?  Well, that must mean those transactions are viewable if someone has enough info. Wouldn&#039;t a similar idea apply to P2P?  Of course, viewing those transactions could still violate some sort of computer crime/fraud law. So, while technically possible, it might not be legally possible for the RIAA to do so.</description>
		<content:encoded><![CDATA[<p><a></a></p>
<p>Yeah &#8211; the way I was thinking about it was: we use encryption on Amazon and such to keep people from viewing transactions, right?  Well, that must mean those transactions are viewable if someone has enough info. Wouldn&#8217;t a similar idea apply to P2P?  Of course, viewing those transactions could still violate some sort of computer crime/fraud law. So, while technically possible, it might not be legally possible for the RIAA to do so.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe</title>
		<link>http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/comment-page-1/#comment-4389</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Sat, 26 Jul 2003 01:19:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/cmusings/2003/07/25/once-more-on-downloading/#comment-4389</guid>
		<description>&lt;a&gt;&lt;/a&gt;

Hey guy, I guess I&#039;ll answer in the comments so that more tech-savy people can beat me down... the only way (I think) that you can monitor a download like you are saying is to know which pipes the packets (TCP/IP frames) are going through... that&#039;s tough... you could install some software on a machine/router near a particularly heavy sharer... and monitor the IP addresses that downloads were going to... even then, you probably wouldn&#039;t be sure what they were receiving... I think it would be tough.

&lt;p&gt;Actually, now that I think about it... the RIAA itself could set up a &quot;honeypot&quot; and monitor all the Kazaa users who download stuff from the honeypot, then subpoena the PII of certain IP addresses and then get a warrant for a computer search... this seems pretty obfuscated... I guess that&#039;s why it&#039;s so easy to go after sharers... you know what they have and you can get to them.  If a downloader quickly moves stuff out of their shared folders, you&#039;d need to hack into their computer (interdiction) or get a warrant for dicovery.

&lt;p&gt;Someone please add to this!!!</description>
		<content:encoded><![CDATA[<p><a></a></p>
<p>Hey guy, I guess I&#8217;ll answer in the comments so that more tech-savy people can beat me down&#8230; the only way (I think) that you can monitor a download like you are saying is to know which pipes the packets (TCP/IP frames) are going through&#8230; that&#8217;s tough&#8230; you could install some software on a machine/router near a particularly heavy sharer&#8230; and monitor the IP addresses that downloads were going to&#8230; even then, you probably wouldn&#8217;t be sure what they were receiving&#8230; I think it would be tough.</p>
<p>Actually, now that I think about it&#8230; the RIAA itself could set up a &#8220;honeypot&#8221; and monitor all the Kazaa users who download stuff from the honeypot, then subpoena the PII of certain IP addresses and then get a warrant for a computer search&#8230; this seems pretty obfuscated&#8230; I guess that&#8217;s why it&#8217;s so easy to go after sharers&#8230; you know what they have and you can get to them.  If a downloader quickly moves stuff out of their shared folders, you&#8217;d need to hack into their computer (interdiction) or get a warrant for dicovery.</p>
<p>Someone please add to this!!!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
