[tahoe-dev] [tahoe-lafs] #1216: document our commitment never to add government backdoors

[tahoe-lafs]

#1216: document our commitment never to add government backdoors
-----------------------------------------------------+----------------------
 Reporter:  davidsarah                               |           Owner:  somebody          
     Type:  defect                                   |          Status:  new               
 Priority:  major                                    |       Milestone:  soon (release n/a)
Component:  documentation                            |         Version:  1.8.0             
 Keywords:  security confidentiality integrity docs  |   Launchpad Bug:                    
-----------------------------------------------------+----------------------
 The New York Times has recently reported that the current U.S.
 administration is proposing a bill that would apparently, if passed,
 require communication systems to facilitate government wiretapping and
 access to encrypted data:

 http://www.nytimes.com/2010/09/27/us/27wiretap.html (login required;
 username/password pairs available at
 http://www.bugmenot.com/view/nytimes.com).

 Commentary by the [https://www.eff.org/deeplinks/2010/09/government-seeks
 Electronic Frontier Foundation], [http://reason.com/blog/2010/09/27/obama-
 administration-frustrate Peter Suderman / Reason], [http://www.cato-at-
 liberty.org/designing-an-insecure-internet/ Julian Sanchez / Cato
 Institute].

 The core Tahoe developers promise never to change Tahoe-LAFS to facilitate
 government access to data stored or transmitted by it. Even if it were
 desirable to facilitate such access -- which it is not -- we believe it
 would not be technically feasible to do so without severely compromising
 Tahoe-LAFS' security against other attackers. There have been many
 examples in which backdoors intended for use by goverment have introduced
 vulnerabilities exploitable by other parties (a notable example being the
 Greek cellphone eavesdropping scandal in 2004/5). RFCs
 [http://tools.ietf.org/html/rfc1984 1984] and
 [http://tools.ietf.org/html/rfc2804 2804] elaborate on the security case
 against such backdoors.

 Note that since Tahoe-LAFS is open-source software, forks by people other
 than the current core developers are possible. In that event, we would try
 to persuade any such forks to adopt a similar policy.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1216>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage