[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1010: anonymous client mode

[Tahoe-LAFS]

#1010: anonymous client mode
-------------------------+-------------------------------------------------
     Reporter:  duck     |      Owner:  warner
         Type:           |     Status:  new
  enhancement            |  Milestone:  soon
     Priority:  minor    |    Version:  1.6.1
    Component:  code-    |   Keywords:  privacy anonymity docs anti-
  network                |  censorship forward-compatibility i2p-collab i2p
   Resolution:           |  tor-protocol
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by str4d):

 For more terminology discussion, see
 [https://twitter.com/zooko/status/643863836756475909 this tweet by Zooko],
 and [https://twitter.com/zooko/status/643864107758800897 this one], and
 their replies.

 IMHO random Accounting client-ids are not necessary. From the I2P
 perspective, a Tahoe client is going to have a visible known I2P
 Destination at least for the duration of the process (by default client
 sessions are transient), and so an Accounting client-id that persists as
 long as the I2P Destination does is within the existing threat model. For
 a Tahoe client that is also a server, this will be long-term; for client-
 only nodes, this will be until restart (unless code was added to
 intentionally cycle Destinations on a shorter timescale). The Tor side
 will have similar considerations. I don't see a use case that requires a
 Tahoe client's I2P activity and Tor activity to be unlinked.

 Another consideration raised by this: we need to ensure that if the Tahoe
 configuration is changed, all identifiers are cycled (as best as
 possible). That means, if a user is running a "non-anonymous" client, and
 subsequently configures it to be "anonymous", then Tahoe needs to
 regenerate:

 * The I2P Destination
 * The Tor HS key
 * The Accounting client-id(s)

 The shares being accessed is a harder identifier to prevent leaking
 across, and I'm not sure how it could be done within the Tahoe-LAFS
 operational model. For comparison: the !BitTorrent client Vuze has an I2P
 plugin, and internally it runs two I2P Destinations - one for "pure" I2P
 traffic, and one for "mixed" I2P traffic (for any torrents being seeded
 simultaneously to/from I2P and the clearnet). It explicitly warns the user
 that once a torrent has been added with a given privacy setting, it should
 not be changed, because the already-fetched-blocks are a unique
 fingerprint for incomplete torrents. To change, they recommend deleting
 and re-adding the torrent. It's not something they can defend against, but
 they try to at least give the user plenty of warning.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010#comment:55>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage