[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    RE: [cap-talk] Cap vs. cap + password
From:       "Stiegler, Marc D" <marc.d.stiegler () hp ! com>
Date:       2005-11-29 23:33:00
Message-ID: BCD023E7727C0A4C93574C4D6C7FE3125B31B0 () cacexc12 ! americas ! cpqcorp ! net
[Download RAW message or body]



> I'm persuaded!  (You have a mechanism here to
> prevent leakage which is potentially better than
> asking users to remember more passwords :)
> 
> So, one broad question:  Is the secure bookmark:
> 
>    a) something that "exists now" according to your
>       anecdotes and lives happily in the browser,
>    b) something that we need to address in terms of
>       "minor tweaks to browsers" to make them work
>       properly within the concept,
>    c) a suitable and preferable metaphor for YURLs, or
>    d) some combination of the above?
> 
> You've obviously thought about it a lot, so I'm
> being lazy here and trying to get it into scope.

"Secure bookmarks" is the term I am trying to popularize for the form of
YURLs that are created and used by the Waterken web server today (I have
found that the term "secure bookmark" leads many people to a quick
intuition of the idea, while "web calculus, though it is a more accurate
definition, is daunting and does not lead to the intuitions as quickly).
If I recall tyler's categorization, YURL is a generic term that embraces
E's capuri, httpsy, and the https urls of the current server.

Secure bookmarks work well enough with browsers so that you can use them
today. But now I must list the ways in which the secure bookmarks that
you can use today are not as good as you want them to be:

-- to get the full security benefits, "minor tweaks to browsers" are
required. Most important, without tweaks, current browsers will not
check the fingerprint of the site to which you've connected.

-- secure bookmarks are hard to work with unless you use a waterken
server. Tyler first did secure bookmarks with a module for Apache, but
found that debugging was nearly impossible for detailed technical
reasons he can explain if you're interested.

-- the waterken server has a steep learning curve (at least for me). The
documentation has not been exercised effectively. I have kept copies of
all the emails that have flown around recently as people tried to get
started with the server, because I intend, starting in mid January, to
write the "Waterken Server in a Walnut", and the problems people have
had are going to be a great help to me in the effort. 

-- once you get past the learning curve, the server is sound. Tyler did
some serious financial projects with it before I met him, and it hasn't
given me any trouble for any of the small projects I've worked on with
Tyler since we got together.

Whether the secure bookmark is a suitable and preferable metaphor for
YURLs, I have a complicated opinion. I think the secure bookmark is an
excellent metaphor for many applications. We could use a couple more
good metaphors for other applications. I will be working on an
application in which the YURLs are given a look and feel that makes them
seem to be Windows shortcuts, with the big distinction that, if I double
click on the shortcut on a computer inside one firewall, and the file is
on a file server behind another firewall, the shortcut still works -- I
begin editing the document remotely.

There is a specific situation in which a little more metaphor work is
required. One of the strengths of secure bookmarks is that, unlike
passwords, people will be surprised if someone asks them to type it into
a field on the web page. This feature, which makes secure bookmarks
robust against phishing, would break if we used the "secure bookmark" as
the metaphor for a holder of electronic money, because in those
protocols you create a reference and then paste/drag-drop/type the
reference into the recipient page. I think there are straightforward
ways of clearly distinguishing the "this is a big powerful authority,
think really hard about giving it out" yurls from the "grant this to the
recipient" yurls, but there is work to be done there. I have not yet
formed an opinion about whether they should both be called "secure
bookmarks".

I personally still prefer E with capuri to secure bookmarks for a bunch
of reasons, but in the two years I've spent promoting object
capabilities at HP Labs, it has become evident that I do not have the
skills of persuasion and articulation to get people to use a new
language, even if the language gives you a factor of 4 to 7 increase in
productivity, even for new startup projects that can make non-legacy
choices. Secure bookmarks exploit legacy machinery in a manner that
makes developers feel comfortable. I have become convinced that the path
to the future lies through secure bookmarks.

--marcs

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]