Re: Fwd: Re: [Cryptography] Encryption opinion

About SleazeBook. 2 observations, one minor, one major.

Minor point, we have long known it is harder to protect pure data than to protect authorities. Webkeys can protect you from giving away your authority to someone who spoofs one of your sites, but not even webkeys can protect you from someone who spoofs your site just to ask for your social security number. I call this a minor point because your scenario is still valid even if what you’re giving Sleazebook is a webkey reference to a file rather just a bunch of pure data.

Major point: we don’t need the distinction between 2 parts of the page to have the problem. SleazeBook can sell our file reference to the highest bidders without fiddling with promises about what won’t be put on the second half of the screen. Ocap virtues in this situation are as follows:


1)      At least we didn’t have to give SleazeBook our single signon so it could get to the file. We implemented least privilege. This is a very big deal. This may be the difference between a successful human future and a disastrous one. Of course, even with least privilege, we still have to make a trust decision about SleazeBook, but it is a reasonable human-scale decision to assess because we don’t have to give away a major portion of our identity. With standard approaches, the choices are simply intolerable, so traditional security people have trained the users to tolerate intolerable risk. BTW, this is the sort of least privilege analysis and decision making humans train for from an early age. When teenagers tell secrets of varying importance to their BFFs, and some of them gossip, the teenagers learn through experience about how important a secret can be trusted to whom (I first realized there was something profound going on in teenage gossip by observing my daughter’s network of friends. Frightening). We seem wired to do such least privilege trust analysis well. And we have cultural resources to hone those instincts, so embedded in our culture we don’t even recognize them. Note that many of Shakespeare’s plots are cautionary tales about trust and least privilege. Ocaps incorporate human beings into the security policy analysis in ways for which we are well-equipped; single signons and certificate authorities do not.

2)      As we have shown in a couple of apps, we can straightforwardly maintain complete audit chains so that, if our file is corrupted, we can hold SleazeBook responsible.

3)      If it isn’t SleazeBook itself that is leaking our authority to the universe, but rather one of SleazeBook’s third parties (and I sure hope SleazeBook is using third parties without burdening us with this excess info, and using ocap patterns of composition to give us more value at lower cost, and accepting the legal burden of the responsibility), SleazeBook itself can see, through the audit chain, whom Sleazebook trusted inappropriately and revoke them; we ourselves can also see the chain and again we have enough info to decide whether to continue to trust Sleazebook with the least privilege it needs, as long as it is doing responsible cleanup of its third parties, or to revoke sleazebook because we no longer trust their policies about delegation. Though in practice we will still probably not look any deeper than to hold SleazeBook responsible. After all, it works perfectly well to hold our car mechanic responsible without making decisions about what to do if the mechanic’s assistant is a screw-up.

Responding to an entirely different point from the original rant, the entire line of thinking, “if something hasn’t succeeded in X number of years, there’s surely something actually wrong with it” is bogus. In 1988, global hypertext had been Golden Vaporware for 25 years. Surely there was something fundamental wrong with whole the idea. And yet, 4 years later, it was obvious to everyone that this was the greatest invention since sliced bread. Within another 4 years, it turned out that everyone had always known hypertext was a great idea, it had always been so obviously great, it was hardly worth mentioning as an innovation.

But hypertext is not the record holder. Leonardo da Vinci invented an amazingly large chunk of the modern world single-handed, and it was all Golden Vaporware for centuries.

--marcs

From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Friday, August 29, 2014 12:25 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] Fwd: Re: [Cryptography] Encryption opinion

Sorry to keep self-replying but thoughts keep popping up in my mind. :)

Consider another example, a social network we'll call SleazeBook [tm]. Let's say I'm using it through some ocap UI that allows me to drag and drop stuff into UI representations of various actors.

As long as SleazeBook presents just one large "page" and I understand that everything I drag into SleazeBook is in a big wash with everything else, then I'm fine.

But then SleazeBook chooses to use the ocap features of my UI layer to claim that there are two distinct "regions" -- the Buddy Corner and the Public Forum. Anything I drag into the Buddy Corner is only shared with my Buddies. Stuff in the Public Forum is shared with the public. Now these are two objects that my UI shows as visibly distinct.

Now are they indeed distinct? It depends on how much I trust SleazeBook not to inadvertently or maliciously share stuff from my Buddy Corner with the public! In other words, the fact of that distinction is only "according to" SleazeBook.

Why do I think this stuff is central to building a usable ocap UI? Well, because we currently live in a world where executing third-party code on some Website is for the most part considered a hack worthy of a security advisory. But we *propose* a world where, by the power of ocaps, third-party code is merely a new form of media; something that is shared freely and embedded in all sorts of places. I claim that this, more than anything else, is the power of ocaps -- to make the world safe for objects! But if indeed that is our goal, then how do we represent -- and *pre*sent to the user -- the complex security scenarios that result?

Ihab

--
Ihab A.B. Awad, Palo Alto, CA

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk