[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