[cap-talk] Webkeys vs. the web
Karp, Alan H
alan.karp at hp.com
Thu Apr 2 12:35:09 EDT 2009
Raoul Duke wrote:
>
> ok, i think that helps me understand a bit better, thanks! -- the
> distinction between calling it an attack vs. just an unfortunate event
> is what i didn't get. the thing is, i don't understand how you can
> hold that opinion, given the examples you've used! :-) if it is just
> "less likely" that i'll accidentally send you direct access to my
> Schwab account, or to the write cap of my blog, rather than it being
> "simply not doable", that makes me wonder just how much "less" it
> really is. if not much then that doesn't seem like a good goal.
>
I try to avoid saying "eliminate" because no matter how idiot proof you make it, there's always an idiot who falsifies the proof. I'll be happy enough if we can make the easy way the secure way. It isn't if we treat webkes as regular URLs.
>
> i suspect people have sketches of end-to-end apps in their heads which
> are what they base statements on, and i just don't have that in my
> head -- at least, not a sketch that yet makes safe sense to me. e.g. i
> think it was Ihab who mentioned using HTTPS to avoid eaves dropping,
> which then in theory lets us say that as long as the browser
> environment can't nefariously pass webkeys along to some attacker,
> then as long as the browser doesn't expose webkeys then everything is
> sewn up tight enough? but then can you bookmark things, how does
> history work, etc.
>
http://www.hpl.hp.com/techreports/2009/HPL-2009-53.html is an extreme example. The entire UI is a single page rendered in Flash. Every item in the UI has a corresponding webkey, but the user only sees webkeys in two situations. The mailbox is accessed by a webkey stored in a bookmark. That bookmark is currently sharable, but it shouldn't be. Indeed, one of our users sent me the webkey to her inbox. The second is the webkey used to set up a new Pal. That's a one-use webkey, but our users didn't like seeing it, so we plan to encapsulate it in a file. I believe we can do something along these lines with more conventional web pages.
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> bounces at mail.eros-os.org] On Behalf Of Raoul Duke
> Sent: Thursday, April 02, 2009 9:16 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Webkeys vs. the web
>
> > I don't consider these examples to be attacks. They are user errors
> that arise from the inability to distinguish authority bearing webkeys
> from non-authority bearing URLs. I contend that we need to design our
> user interface so that users are less likely to make this kind of
> mistake.
>
> ok, i think that helps me understand a bit better, thanks! -- the
> distinction between calling it an attack vs. just an unfortunate event
> is what i didn't get. the thing is, i don't understand how you can
> hold that opinion, given the examples you've used! :-) if it is just
> "less likely" that i'll accidentally send you direct access to my
> Schwab account, or to the write cap of my blog, rather than it being
> "simply not doable", that makes me wonder just how much "less" it
> really is. if not much then that doesn't seem like a good goal.
>
> i suspect people have sketches of end-to-end apps in their heads which
> are what they base statements on, and i just don't have that in my
> head -- at least, not a sketch that yet makes safe sense to me. e.g. i
> think it was Ihab who mentioned using HTTPS to avoid eaves dropping,
> which then in theory lets us say that as long as the browser
> environment can't nefariously pass webkeys along to some attacker,
> then as long as the browser doesn't expose webkeys then everything is
> sewn up tight enough? but then can you bookmark things, how does
> history work, etc.
>
> (if i were more of an actually useful contributor rather than just
> constantly slow and befuddled, i'd ask the favor of working out some
> use cases and end-to-end flow charts of proposed systems visually on a
> whiteboard, to help everybody get the gestalt, and to help show
> different thoughts side by side. :-)
>
> sincerely.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
More information about the cap-talk
mailing list