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

[tahoe-lafs]

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

Comment(by davidsarah):

 Replying to [comment:2 zooko]:
 > 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!

 You can maintain the opacity property as far as the code running on that
 server is concerned. See below for why this is useful (for some, not all,
 possible uses of opacity).

 > 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.

 That's not true in general. I think you're assuming that the code running
 on the opaque object server is fully trusted by the user who controls
 that server. But that code may not be fully trusted because it may have
 bugs that are exploitable for a particular input, and/or it may have been
 provided by another party.

 The opacity helps in both these cases, since it allows enforcing
 confinement
 between subcomponents or between the code and Tahoe files, or enforcing
 other restrictions on the computational model, such as determinism. It
 also
 helps in ways that are not only security-related -- basically anything
 that
 depends on knowing the reachability graph (memory management,
 transactional
 memory, various optimizations...). All of the advantages of using opaque/
 partitioned capabilities rather than data capabilities where possible,
 apply in this situation.

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