[tahoe-dev] [tahoe-lafs] #959: "tahoe objects" concept

[tahoe-lafs]

#959: "tahoe objects" concept
-------------------------+--------------------------------------------------
 Reporter:  warner       |           Owner:  nobody   
     Type:  enhancement  |          Status:  new      
 Priority:  major        |       Milestone:  undecided
Component:  unknown      |         Version:  1.6.0    
 Keywords:               |   Launchpad_bug:           
-------------------------+--------------------------------------------------

Comment(by zooko):

 Norm wrote on http://cap-lore.com/BigStore/Tahoe.html:
 > This plan contravenes an implicit Tahoe dictum: “Trust no mechanism
 outside your physical control.”. The O-agents of a given RSA key pair rely
 on either tamper resistance, or more likely physical protection. I think
 that Tahoe also violates this property in their scheme for mutable
 objects. (I am not sure.) Such violation also seems necessary for
 revocation services. In all three cases the trust of externally
 instantiated objects impacts only those who specifically rely on them.

 I don't think Tahoe-LAFS violates this property for our mutable files but
 to be sure let's see if we can restate the property in terms of "reliance
 sets" (as in [https://www.cypherpunks.to/erights/talks/thesis/markm-
 thesis.pdf MarkM's thesis]).

 The set of things that you rely on for the unforgeability of your mutable
 files is:
 1. the client (e.g. a web browser which is viewing the file or a unix
 shell which is catting the file to its stdout)
 2. the Tahoe-LAFS gateway

 Note that a very common deployment pattern is that you run your own Tahoe-
 LAFS gateway on your local computer, so both of the items in the reliance
 set are running as user-space processes within the protection of your
 operating system and your machine.

 So all of the items in the set of "things on which you rely for
 unforgeability of your mutable files" can be under your physical control.

 Now, what about this notion of "Tahoe-LAFS objects"? My proposal for how
 to implement Tahoe-LAFS objects is simply to make a special client that
 implements the attenuated, revocable, filtered, or otherwise modified
 access and that itself has access to the underlying files. That Tahoe-LAFS
 client then serves its special kind of access out to another client. Let's
 call that Tahoe-LAFS client an "opaque object server". Then the set of
 "things on which you rely for the unforgeability of your mutable file"
 becomes:
 1. your client (such as a web browser or cmdline tool), which connects to
 the opaque object server
 2. the opaque object server, which connects to the Tahoe-LAFS gateway
 3. the Tahoe-LAFS gateway

 (Note: the "opaque object server" is just what Norm mentioned early on his
 page when he wrote: "The obvious way to do this is to create a web server
 with the custom filter programmed in, and endow that server with the file
 handle to the original file.".)

 Now here is where it gets confusing to me: we can't maintain the opacity
 property if you run the opaque object server on your own local machine! So
 now you can either have the unforgeability property within your physical
 control (by running all three elements of the reliance set on your own
 local machine) or you can have the opacity property (by running the opaque
 object server on a machine that you cannot hack), but not both.

 (I haven't thought it through, but I suspect that the "distributed opaque
 object" proposals by Norm and by Brian will have the same choice.)

 But you know what, the opaque object property is not something that the
 user actually wants. I'll be happy to run all three elements on my own
 machine and use the resulting "not really opaque" objects. The opacity
 property is a way to prevent me from doing something, not a way to offer
 me any useful property. So there must be someone else who wants this
 opacity property to be preserved, and whoever that is ''they'' should run
 the opaque object server (and the Tahoe-LAFS gateway that it uses) on
 ''their'' machine and give me remote access to the service provided by
 their opaque object server.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/959#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid