[cap-talk] Re: Capability development principles - "no copy"
seen as wrong
Sandro Magi
smagi at naasking.homeip.net
Fri Dec 2 22:43:29 EST 2005
Jed at Webstart wrote:
> At 05:17 AM 11/30/2005, Sandro Magi wrote:
>
> If, after it has completed your request, you would like to keep it from
> being able
> to use that capability in the future, you should only give it a
> revokable copy of
> the capability and revoke it after your request is complete. That will
> mean that
> it can't mediate any permanent sharing via that capability, but in this
> case it
> seems that's what you want.
>
> There just isn't any more protection you can get, so why struggle?
I agree with this 100% as it applies to software agents. Capability
patterns are absolutely on the money here, so you're preaching to the
choir. :-)
However, I'm stil convinced that end users will not want to go through
some of the burdens of properly managing their security *in some cases*.
Now I know, as MarcS said, you can always invent a "dumber user", but
there is something fundamentally wrong when the burden placed on the
user is rather high; the incentives for them to do the right thing just
aren't there. Then who will they complain to when something bad happens?
Their friendly neighbourhood application developer: me. :-)
For instance, in the scenario I laid out with the sales rep using a
customer's computer: the rep can absolutely go into every customer's
browser settings and tweak the privacy settings so his bookmarks and the
cache during his session are invalidated when he closes the browser. How
is this any less of a burden than remembering a password though? It's
arguably more of a burden for an application he uses every day.
So I was looking for a design which could keep the web-calculus intact
for all those other things it's great at, but handle this one scenario
where the burden seems a little cumbersome for some people.
When/if the browsers improve the way they handle "secure bookmarks" and
"secure urls", then this requirement will probably go away. It's just
there for backwards compatibility with the "one true way". :-)
Sandro
More information about the cap-talk
mailing list