[liberationtech] [p2p-hackers] how do I tell these Chinese people "You're doing it wrong!" ?
Rebecca MacKinnon
rebecca.mackinnon at gmail.com
Wed Nov 10 17:10:58 PST 2010
I refer you to Isaac Mao, a Chinese blogger and technologist who is on the
Libtech list and who replied to this thread earlier. He has knowledge of the
entire situation and of the Chinese folks involved.
Best,
Rebecca
On Thu, Nov 11, 2010 at 12:53 AM, Serguei Osokine
<Serguei.Osokine at efi.com>wrote:
> On Wednesday, November 10, 2010 Zooko O'Whielacronx:
> > So, how do we explain to these Chinese users (and everyone else)
> > that if they want good security, they must run a Tahoe-LAFS gateway
> > (which is a web server) on a computer they control?
>
> Zooko, are you sure that there *is* any computer that they control?
> Maybe they know all that, but since they have no computer that they
> can view as 100% safe, the computer controlled by *you* can be the
> next best thing? It sure beats the computer that can be captured
> by the adversary at any moment.
>
> Best wishes -
> S.Osokine.
> 10 Nov 2010.
>
>
> -----Original Message-----
> From: p2p-hackers-bounces at lists.zooko.com [mailto:
> p2p-hackers-bounces at lists.zooko.com] On Behalf Of Zooko O'Whielacronx
> Sent: Wednesday, November 10, 2010 8:20 AM
> To: theory and practice of decentralized computer networks; tahoe-dev;
> liberationtech at lists.stanford.edu
> Subject: [p2p-hackers] how do I tell these Chinese people "You're doing it
> wrong!" ?
>
> Dear people of p2p-hackers, tahoe-dev, and liberationtech:
>
> I think I confused the issue when I said in [1] "some people in China
> might be relying on using the Tahoe-LAFS public demo over unencrypted
> HTTP and thinking that it provides security properties like they would
> get if they ran their own copy of Tahoe-LAFS locally".
>
> Encryption of the HTTP connection isn't very important, so it was
> confusing when I mentioned "over unencrypted HTTP". I should have just
> said "some people in China might be relying on using the Tahoe-LAFS
> public demo and thinking that it provides security properties like
> they would get if they ran their own copy of Tahoe-LAFS
> locally".
>
> Look at this diagram:
>
> http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.html
>
> Using an unencrypted connection (HTTP or FTP) between the Tahoe-LAFS
> client and the Tahoe-LAFS gateway means that the link between those
> two objects on the diagram is red, meaning that you are vulnerable to
> anyone who controls that link. If you instead used an encrypted
> connection (HTTPS or SFTP) between those two objects then that link
> would be black, meaning that you are not vulnerable to someone just
> because they control that link. But you are still vulnerable to
> whoever controls the Tahoe-LAFS gateway which the link goes to!
>
> The right way to do it is to run the Tahoe-LAFS gateway yourself on a
> computer that you control. The Tahoe-LAFS gateway object is red on
> that diagram, meaning that you rely on it for your security, which is
> why you should run it on a computer that you control.
>
> You could run it on the same laptop or desktop that you are running
> your web browser (which is acting as the Tahoe-LAFS client), in which
> case it doesn't matter whether you use HTTP or HTTPS because the
> connection is only running over the loopback interface anyway.
>
> Or you could run it on some other computer that you control, in which
> case you need to use HTTPS so that you aren't vulnerable to anyone who
> controls the link between your local computer running your web browser
> on and your remote computer running your Tahoe-LAFS gateway.
>
> So, how do we explain to these Chinese users (and everyone else) that
> if they want good security, they must run a Tahoe-LAFS gateway (which
> is a web server) on a computer they control? Perhaps it would help to
> draw one variant of this diagram showing a user using a gateway on a
> remote server and being vulnerable to the people who control that
> server (which may include more people than the server's legal owner
> thinks), and another picture showing a user using a gateway on his
> local machine and being safe against the threat of the server operator
> betraying him.
>
> Does anyone have design skills (and Chinese!) and could try to explain
> this?
>
> Here is the source code for the current version of the diagram:
>
>
> http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/network-and-reliance-topology.svg
>
> Regards,
>
> Zooko
>
> [1] http://lists.zooko.com/pipermail/p2p-hackers/2010-November/002551.html
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at lists.zooko.com
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
> Confidentiality notice: This message may contain confidential information.
> It is intended only for the person to whom it is addressed. If you are not
> that person, you should not use this message. We request that you notify us
> by replying to this message, and then delete all copies including any
> contained in your reply. Thank you.
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
>
> Should you need to change your subscription options, please go to:
>
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> If you would like to receive a daily digest, click "yes" (once you click
> above) next to "would you like to receive list mail batched in a daily
> digest?"
>
> You will need the user name and password you receive from the list
> moderator in monthly reminders.
>
> Should you need immediate assistance, please contact the list moderator.
>
--
Rebecca MacKinnon
Schwartz Senior Fellow, New America Foundation
Co-founder, GlobalVoicesOnline.org
Cell: +1-617-939-3493
E-mail: rebecca.mackinnon at gmail.com
Blog: http://RConversation.blogs.com
Twitter: http://twitter.com/rmack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20101111/d759980f/attachment.html>
More information about the liberationtech
mailing list