[e-privacy] MUTE legalita' (negli USA) dei nodi

pinna pinna at autistici.org
Thu Sep 30 17:41:02 CEST 2004


sto per disiscrivermi dalla mailing list di MUTE, poiche' non riesco a 
seguirla adeguatamente. uno dei thread recenti piu' interessanti 
sembra essere stato "[MUTE] Illegal running a mute node?", di cui vi
incollo qui alcuni messaggi prima di liberare la mia mailbox :)
vi sono considerazioni sulla legalita' (negli USA) di un nodo MUTE, 
sulla (non) possibilita' di implementare un sistema di crittazione 
end-to-end, etc. 

ciao
pinna



As I know, sharing chunks of copy righted material is illegal. Based 
on 
this I had the following thought: Is it also illegal if you don't even 
know what you are sharing? Related to mute: Is it illegal to be a node 
which just acts as proxy for the newest song of Britney Spears?

If yes, the RIAA just needs to connect to mute network, ask for copy 
righted material, and prosecute their neighbour nodes - no matter what 
they share, but what they provide. Because 1) sharing parts of copy 
righted material is illegal, 2) no matter whether the person is aware 
of 
what he/she is sharing. I am not sure about the second point.


-------------------------------------------------------


This is a  
section from the Ants story on Slyck. This is the part where they ask 
law group  
what they think:
 
[quote]
Turning to a lawyer instead, Fred von Lohmann explained, “The law is 
simply  
unclear. No court has ever considered whether you can be held liable 
for  
copyright infringement simply for proxying data in a network. EFF 
strongly  
believes that the answer should be that, assuming you have no 
knowledge of what  the 
packets are that you're passing, you should not be liable for the 
contents  
of the packets. That is, after all, the rule for ISPs. The same rule 
should  
apply for individuals,” he explained.

If the law favors the EFF view,  then neither MUTE nor ANts peers can 
be held 
liable for proxying objectionable  files. Although ANts provides 
endpoint 
encryption, the average user of MUTE  would not know where to begin 
discovering 
what they are proxying. The overhead  of endpoint encryption provided 
by ANts 
would therefore be wasted in a legal  context.

When questioned about this, Gwren admitted that he does not know  if 
the 
encryption is a wasted overhead or not. After all, the encryption is 
not  in place 
for legal protection.
[end quote]


-------------------------------------------------------


The key quote is this one:

"EFF strongly believes that the answer should be that,
assuming you have ***no knowledge*** of what the
packets are that you're passing."

We *do* have the ability to *know* with Mute.  With
Mute you have the *ability* to know what you and your
neighbours are passing with a simple hack.  That is
dangerous ground to be on - the realm of willful
blindness.

Much better to have *NO* possible way to know rather
than simply choosing not to.  I2P / ANtsP2P with
end-to-end encryption accomplishes this as it is not
possbile to view the encrypted end/end data stream. 
Freenet also has this since the content itself is
encrypted with the retrieve key.

Mute lacks end-to-end *AND* key encryption thus the
files are open to plain view - very dangerous.  After
giving it some thought I must recommend that people
consider not using Mute until this is fixed :(.

Mute's contribution will live on since its GPL, and at
least ANtsP2P is still around :o), 



-------------------------------------------------------

[msg di Jason Rohrer)

You know, I have been over this again and again...  people keep 
forgetting:

SECURE END-TO-END ENCRYPTION IN AN ANONYMOUS, ROUTED NETWORK IS 
IMPOSSIBLE

For end-to-end encryption to work, the endpoints need to exchange keys 
in a secure way (even for public key systems, the endpoints need to 
be sure that they obtain the correct, unmodified keys).  Since they 
don't know eachother (they are anonymous, after all), the only way 
for them to exchange keys is to send those keys through a multi-hop 
MUTE route.

Of course, any node along that route (the RIAA, for example), could 
substitute their own public key in place of the key being routed, 
thus enabling them to spy on the supposedly encrypted end-to-end 
communication.

This is called a "man in the middle" attack.

I will never add end-to-end encryption to MUTE, because end-to-end 
encryption provides no real security (only a false sense of 
security).


(Sorry for the all-caps above, but every few months, people start 
asking for end-to-end in MUTE again, and it is starting to get 
annoying).

Jason 


-------------------------------------------------------


Yes, end to end encryption works, but is not secured to "man in the 
middle attack", like jason described. Not even in Ants, I suppose. 
Because mute is open source, it's not so much effort to write a client 
able to perform such spying. Theoretically. But as long as mute/ants 
is 
not this populary, legal organisations like **AA won't do this 
(because 
after all, modifying a mute client is effort). Not as long as they 
find 
enough people sharing music over 2nd generation networks.

At this point I'd like to express mit dislike against capitalism which 
doesn't hesitate to press the government to change copy right laws, 
which has the effect of criminate a lot of people which just love to 
share good music. This is what happened in germany. Copy right laws 
were 
originally made to protect the artists rights, not to secure the 
profits 
of the music industries. 
http://www.ccc.de/campaigns/boycott-musicindustry?language=en



-------------------------------------------------------


My point exactly.  We all understand (ad nauseum), quoting from Jason, 
that 
"SECURE END-TO-END ENCRYPTION IN AN ANONYMOUS, ROUTED NETWORK IS 
IMPOSSIBLE", 
and I think we all agree that this is a fact.

But end-to-end encryption DOES provide your proxy node with 
significantly 
better plausible deniability, because it is virtually impossible to 
decrypt 
and "spy" on the data packets that are flowing through your node.

As MUTE functions today, all that an "evil" modified node has to do in 
order 
to spy on actual unencrypted data coming in from neighbor nodes is to 
add a 
few printf's to the code.  The evildoer can then state to the Judge, 
"Nodes at 
the following IP addresses sent to our 'sniffer' node segments of the 
following copyrighted material: A, B, C.  These nodes can easily see 
this 
unencrypted data, even if they themselves did not originate it.  Hence 
they 
are all guilty of contributory infringement."  This could be applied 
to 
hundreds of IP addresses simply by restarting their "evil" node 
frequently, so 
that they get a new batch of neighbor (victim) nodes.

If end-to-end encryption were to be implemented, however, that "evil" 
node 
would have to mount a MITM attack, by substituting it's own public key 
in 
place of a legitimate one as a D-H key exchange request went by.  Then 
it 
could decrypt the data as it came in (as described above).  But here 
is the 
significant difference: The neighbor (intermediate) nodes have NO way 
of 
telling what the data is that they are actually transferring, because 
it was 
encrypted using a public key that does not belong to them, and hence 
they do 
not have the private key that would be necessary to decrypt it.  So no 
amount 
of printf's would show them what the actual data payload was.  That's 
PROPER 
plausible deniability.



-------------------------------------------------------


And since routes change it's hard to always be the MITM / always get
inbetween the key exchange.

You also don't want to get sued for DMCA violations by decrypting a
private encrypted data stream and if you got to court I don't think 
the
lawyers could force you to be put in a position of admitting that you
violated DMCA, also making yourself liable for a lawsuit from the 
other
party who was having a nice private communication.

Since most normal end users wouldn't want to violate DMCA :)  I think
that we wouldn't see any MITM things going on for normal regular 
program
users who most likely wouldn't know how to do a MITM attack.



More information about the E-privacy mailing list