Re: Fwd: Re: [Cryptography] Encryption opinion

On Thu, Aug 28, 2014 at 9:12 PM, Karp, Alan H <[email protected]> wrote:

>  I don’t see any security issue in your Amazon examples.  What’s the
> protected resource, and what’s the threat to that resource?
>

The issues are that they rely on clickjack-able ambient authority via
cookies. In both cases, Ihab's blog can designate a page containing Alan's
private Amazon info using a generic URL.

I'm sure there's a way to do similar stuff with ocaps in a principled and
less sloppy manner than how it's done today. The question is how to make it
usable.


>  Your printer example is an irreducible problem.  If I give you a
> permission, taking you to court is the only recourse I have if you abuse
> that permission.  It doesn’t matter if PrintCo blabs or shares the document
> with National Busybody who blabs.  I hold PrintCo responsible and collect
> any penalty provided under my contract with PrintCo.  Similarly, it’s up to
> PrintCo to collect from SleazeHost under terms of their contract if the
> release is due to SleazeHost’s poor security.
>

So first of all, yes, maybe this problem is illusory on my part.

But to persevere for the sake of learning, the cases you note are _ex post
facto_. If we could sue the Nigerian scammers, the world would be so much
better in so many ways. But the fact is, we can't.

Or consider an Open Source Bitcoin wallet app running on a copy of
Sandstorm.io hosted on SleazeHost. If I get hacked and lose my BTC, then
they are practically lost no matter what, and no amount of suing is going
to bring them back. The *risk* that they are lost is computed from a
combination of my reliance that --

* The author of the app is not malicious and did a good job;
* Sandstorm.io implements proper sandboxing; and
* SleazeHost does a reasonable job of controlling ssh access to their
servers.

Perhaps, in most cases, we can "collapse" that down; we compute based on
our belief about the author of the app; assume that "infrastructure" works;
and deal with everything else as an emergency if it occurs. But I would
think we would want to do that deliberately.


>  Not allowing the transfer of a capability to a recipient falls under
> Voluntary Oblivious Compliance.  The Horton protocol shows how we might do
> that with capabilities.  However, the possibility of credential sharing
> limits us to voluntary compliance.
>

It's not about *not allowing* anything. It's about telling me whether it's
a good idea to entrust amount [x] of BTC to the app I described above.
Where if [x] is small, then the heck with it, I'll buy convenience. But if
[x] is large, then I'm going to be asking some very hard questions.

At this point, for large [x] in dollars, I rely on -- say -- the Vanguard
Website. Because I figure they control the entire stack, top to bottom,
down to the level of SSL traffic as attested to by their cert, and hope (I
guess...) that they have done a good job. Is this a generally applicable
model?

Ihab

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

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