Ian G wrote: > I agree in principle, a security-browser of some sort is needed.
Internet financial transactions need a custom client - for example web money and tencent's QQ. So what is needed is a generalization, a superset, of those clients. We have seen an interesting tool for managing capabilities:SCoopFS, <http://www.hpl.hp.com/techreports/2009/HPL-2009-53.pdf> though I argue that its implementation of Zooko's triangle and messaging was necessarily incomplete. We also see an interesting tool that creates lots of capabilities that need managing, tahoe, and which is at present a bit short on anything to manage them with. A big part of the solution is links and bookmarks that contain cryptographic information. Another big part of the solution is bookmark and buddy list management that encapsulates these links, hides the horrible parts from the user, and knows the significance of the cryptographic part of these capabilities - that this one is immutable, that this one is secret, that this one identifies the destination. Another big part of the solution is that it has to, like QQ and the Webmoney client, directly support securely logging in, that the client and the protocol has to know what a state of being logged in is, whereas with browsers and http, the browser provides a pile of toothpicks that can be glued together to construct something that to the user mostly acts as if he is logged in - but in subtle, surprising, and unexpected ways fails to act as if he is logged in. We need clients with real logins, cryptographically powerful links, and smart bookmarks where the client knows the power and meaning of the cryptographic information in the links and refrains from exposing the user to long strings of random gibberish. Yet a browser that supported smart bookmarks and secure login would not in itself be adequate to support money, since tencent and webmoney clients are primarily instant messaging clients, and the pecunix web site provides an email like capability for messages between people using pecunix. Most people do their email inside their browser, and many people do their instant messaging inside their browser, so a tool that is a browser, instant messager, and email client is pretty reasonable - but the thing is, we would want the tool to be able to do instant messages and email end to end, rather than being reliant on a single central site, as browser email and IM solutions are. And we need the messaging, mail, and browsing clients to use the same kind of smart bookmarks, as buddies in one messaging case, as contacts in the mail case, and as links in the browsing case, which implies that our tool for managing these things needs to be able to represent a single entity as supporting one or all of messages, mail, and browsing, and future protocols (such as money transfer) as yet unimagined, and nonetheless represent that as one entity. This concept is often refered to as "facets" of a single capability With existing urls we have that by manually editing domain names, for example ftp://example.com and http://example.com, but manual editing is a kluge. A link containing cryptographic identifying information should allow a drop down menu of lots of different things that you could do with that identifying information, and should not present you with a random string that looks like gibberish. The great strength of http and the browser has been that instead of giving you a boat, it gave you a pile of toothpicks and glue with which to construct whatever boat you wanted. But the pile of toothpicks and glue approach has failed for security wherever it has been tried, for example XML security. That security solutions have to be complete and end to cuts across layering, and severely restricts the extent to which they can be divided into toothpicks, and that glue can usefully be applied. As I have argued elsewhere, we need compilation rather than layering. This specification seems like a very big random pile of stuff, not a specification. What is the elegant core of this? _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
