On Thu, 2006-06-01 at 17:35 +0200, Bas Wijnen wrote: > It is not much different from how you plan to do it though. Suppose I do this > without system support. I join a group and donate some storage to it. A part > of a private key gets stored on that storage. I decide to leave the group and > revoke my storage. Then the private key that was (partly) stored on it is > lost, giving the whole group problems. If you want to make this system > usable, the storage must be durable. There may be approaches which work > without the system administrator, but they need support from the system, that > is the machine owner.
1. This is a different failure mode. 2. When I said "donate", I did not mean "revocably". > And how can the group protect against revocation? Right, it can't. So you > need to trust the members that they don't revoke the storage. Your assumption, not mine. > They will have to do it socially anyway. The trust this is about is trust in > the machine owner. With TC, it is trust in the OS builder (and the TC > component manufacturer). In most circumstances, the decision to trust the OS owner involves a much smaller degree of exposure than the decision to trust the machine owner. > > But the factor that you seem to be ignoring is the importance of > > *confidence*. > > Why would people have more confidence in us and the TC component builders than > in the person who installed the OS on the machine (which in many cases they > may be themselves)? Easy: In one case, they *only* need to rely on the OS+TC builders. In the other case, they need to rely on OS+TC+Installer. One dependency set is strictly larger than the other (therefore has lower confidence). I would add: of these, the Installer is the weakest link; there is a qualitative reduction in confidence here. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
