[cap-talk] Webkeys vs. the web
chip at fudco.com
Mon Mar 23 23:28:33 EDT 2009
"Karp, Alan H" <alan.karp at hp.com> wrote:
>I have built one UI based on webkeys and mocked up two others. The only
>webkey the user sees in any of them is the root authority. (Actually, the
>user does see another webkey in SCoopFS, but that's something we need to fix.)
>Once they're looking at the UI, all they see are buttons and forms. The
>webkeys are manipulated in the background. Want to delegate an authority?
>Click the delegate button. Want to revoke an authority? Click the Manage
>button, select what you want to revoke from a list, and click OK. The trick
>is to make the users think they're navigating with buttons rather than URLs.
This is more or less the approach I've been trying to follow, except that the
SCoopFS UI is done using Flash and I'd like to just use straight
authority to squirrel bits away persistently, which allows it to hold onto
capabilities across context switches. I don't know if Alan was making use of
any such thing, though.
Here's an idea for y'all to try to shoot down:
In addition to its normal "cookie nature", you can treat a cookie simply as a
small piece of persistent storage that survives a page load and is accessible
of simply following a link, run a script that generates a request that is
parameterized by information taken from a cookie (some kind of sealed
authentication credentials, say). The server handling this request would only
act on requests thus parameterized and would otherwise ignore the cookie
script some kind of popup or other UI interaction that could not be masked by a
clickjacker (in the sense that, as Tyler points out, bookmarks can't be masked,
in their case because they're in the browser chrome). The clickjacker would be
able to fool you into initiating that interaction, but then the user would have
to follow through with it for it to take effect, which, hopefully, they
wouldn't do if it wasn't what they intended.
More information about the cap-talk