Re: Fwd: Re: [Cryptography] Encryption opinion

I’d like to stay (for the moment) with the scenario of generating
personalized advertising from Amazon on Ihab’s blog.  Creating a “Buy Now”
button would probably require more careful handling due to the higher
economic impact.

We would like to have an iframe content URL that indicates both the
advertising affiliate and the Amazon account holder. In a pure
capability-URL world, this URL would be created by a short transaction
between the three parties that resulted in just such a URL.  This URL would
be stored by the affiliate, and used as iframe content whenever that
specific user arrives at the site.

Notice the following requirements:

  1) The affiliate (blog) must also maintain account information, hopefully
using capabilities itself.  It must at least associate the Amazon-ad-URL
with the current user of the blog.

  2) As mentioned, there has to be a way to create this new capability URL
before we can get the desired effect.

I’m sure that many would argue that these requirements are too much of a
burden over and above current methods, and therefore will not be adopted.
So how do we provide such a result without the above requirements?

I think the answer is by judicious use of cookies to create the effect of
low-authority capability URLs.

First, let me observe that when many people hear “cookie” they think
immediately about ambient authority and separation of authority from
designation.  This is certainly the way many web sites work today, but it
doesn’t have to work like that.  A cookie can be associated with a specific
path, both so that the browser sends it only for requests to that path, and
so that it is useless (grants no authority) anywhere else.

So we have the following:

  1)  The affiliate uses the same URL as currently (
https://amazon.com/ads?affiliate=1234)

  2) Amazon (at some point) sets a cookie on that page (minus query string)
with what is  essentially the “private” part of a capability.

  3) In response to the general URL and the cookie Amazon provides a
personalized ad page which has no authority of note.  (No click-jacking
attack, etc.)

This third point is important.  This needs to be low-authority:
personalized ads, tracking the users path through affiliate sites, etc.  If
the user needs to continue with more authority, some other mechanism would
have to be used.  I think at this point we start needing methods that would
also apply to “Buy Now” buttons.

I think much of this feels like Tyler’s Web Introducers:

  1) The general URL provided by the blog (affiliate) corresponds to a
service request.

  2) The URL-specific cookie represents the user’s participation.

  3) Amazon’s personalized ad page generator represents the service
implementation.


Terry


On Sun, Aug 31, 2014 at 5:28 AM, Sandro Magi <[email protected]> wrote:

> On 31/08/2014 12:59 AM, Karp, Alan H wrote:
>
>> I don’t see that the ambient authority is an issue in this particular
>> case. Ihab’s blog may determine which page I see at Amazon, but Ihab has no
>> authority over that page even with ambient authority.
>>
>
> Ihab's blog has precisely the same authority over the Amazon page as the
> client of the compiler in the Confused Deputy scenario has over the billing
> path, ie. they can both designate a protected resource and confuse the
> agent with permission to write to that resource (the compiler, Amazon
> respsectively) into doing something undesirable.
>
> In Ihab's blog, he just needs to create a page with a button that says
> "Animate Kittens", but which overlays the "buy now" Amazon button to
> trigger a $10,000 purchase. This is preventable in Waterken because the
> URLs are unique for all clients with a "buy now" button.
>
> So how can a user be automatically redirected this unique URL from the
> public URL without also permitting malicious scripts from doing so?
>
> Sandro
>
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

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