[tahoe-dev] Client Certificate UI for Chrome?

James A. Donald jamesd at echeque.com
Sun Sep 6 18:11:16 PDT 2009


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?


More information about the tahoe-dev mailing list