Re: Fwd: Re: [Cryptography] Encryption opinion

On Wed, Aug 27, 2014 at 10:16 PM, Karp, Alan H <[email protected]> wrote:

>  Ihab wrote:
>
>  * Without ambient authority, how do you implement a one-click "Buy
> button" on a product page from a publisher that takes you to a pre-filled
> order form at a merchant to buy the thing that is discussed on the
> publisher's page?
>
>
>
> Why would you need ambient authority for this?  Maybe I don’t understand
> the example.  Are you thinking about Amazon acting as a reseller?  That’s
> easy.  The merchant gives Amazon a buy capability for the item, which
> Amazon delegates to the user.  The user delegates to Amazon a capability to
> the user’s address info, which Amazon delegates to the merchant.  What am I
> missing?
>

Maybe nothing. :) Let me try to explain better though --

Ihab publishes a blog post about blenders. He puts a URL on his blog like:

  http://amazon.com/buy/prod=blendomatic&affiliate=1234

where "1234" is Ihab's affiliate code with Amazon, and "blendomatic" is a
product ID.

The affiliate code is incidental to the security scenario. It is merely
there to explain the commercial reason why this pattern is common. It's how
Ihab gets a kickback from Amazon for referring customers.

Alan goes to Ihab's blog, is convinced to by a Blend-O-Matic, and clicks on
the link. The result is that Alan ends up on Alan's own Amazon account,
with all account details filled in, with a one-click "Buy" button ready for
him to press.

There may be a way to do this with -- say -- a Web Introducer. It's just
the sort of thing that needs to be demonstrated as possible *and usable*,
because lots of people depend on stuff like that for their livelihood.

Here's another example.

One day, Alan goes to Amazon to search for telescopes. He doesn't buy
anything. Later, he goes to Ihab's blog post. Ihab has embedded an
advertising frame that looks something like:

  http://amazon.com/ads?affiliate=1234

Lo and behold, the ads on Ihab's blog are all about telescopes! Users like
you, Alan, searched for a Celestron model XYZ! Buy now!

Once again, this is a pattern that would need to be possible *and usable*
because the Interwebs depend on it mightily for their revenue.

This is by no means an exhaustive list. I'm merely trying to draw attention
to the fact that there are a lot of patterns and anti-patterns upon which
[mostly-] honest people all over have come to rely, and a convincing ocap
solution for the universe needs to take these into account.

 è * How do you represent the flow of authority between entities that may
> or may not have deals with one another? Are my assets on Facebook exposed
> to Microsoft? The other way 'round?
>
>  Why can’t I just transfer to Microsoft the capability for the Facebook
> asset I want to share?  I don’t see why they need a deal with each other?
>

This may or may not be a "real" problem. It represents a class of problems
I have worried about in the past and would be happy if others could bring
some perspective to it.

Let's say I have a Printer object. It's represented in some piece of
screen. I want to Print a Document, so I drag and drop the Document into
the Printer. The transfer of capabilities should be clear, and indeed, no
clicks were wasted on security, which is as it should be.

If the implementation of the Printer is confined to my personal computer,
over which I have control, and a physical USB connection terminating at a
hardware printing device that is not otherwise networked, then the
implication is clear. The outcome of this operation is, at most, the
production of a piece of paper, and/or the storage of the Document's
contents in the memory of the external hardware.

Things get more complicated if this Printer is a remote object hosted by
PrintCo. I have no control over the confinement semantics of the object any
longer.

Now I may assert that I can still *blame* PrintCo for anything that happens
as a result of the transfer of my capability to them. That's all well and
fine. But I still need to model my current best guess as to what *might*
happen, since the blame may come too late. So if I know that PrintCo is in
cahoots with the National Busybody, a salacious tabloid, I may pause before
using it to Print a sensitive Document.

It gets more complicated if PrintCo is trustworthy but is hosted on top of
a hosting service, SleazeHost, which is very sloppy with their security
practices and gets repeatedly hacked. What is my exposure then? In this
case, it's not even right to blame PrintCo!

I wonder about the extent to which this kind of reasoning -- reasoning
before the fact about the unconfined entities *to which* authority is
granted -- would be an important part of a usably secure interface. Because
our job is not merely to transfer capabilities at the behest of the
end-user willy nilly. We are presumably building this whole infrastructure
because there exist capabilities C and recipients R such that it is not a
good idea to transfer C to R. How may that be represented?

In reasoning about this de facto network of trust and suspicion among the
actors represented by the objects with which an end-user interacts, is
there a place for a trusted third party to which these decisions can be
outsourced? Something like a Consumer Reports? Is that the place where the
specific, day to day grunt work currently done by anti-virus companies can
be better applied?

Ihab

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

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