Re: Fwd: Re: [Cryptography] Encryption opinion

<[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <CAG7xX7rOTivOw20_G=QB-tPh70pJ_1ohJ5kot18a4_AukEwUCA@mail.gmail.com>
Hey everyone,

Apologies if I respond briefly. I'm on vacation on the Joizey Shore and
have only an Android device to type on.

On Aug 31, 2014 5:30 AM, "Sandro Magi" <[email protected]> wrote:
> 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?

Indeed, that is the crux of the Amazon buy button and advertising problems.
The ambient authority on the Web is the ability for anyone to designate and
activate a private resource as a result of cookies and the Same Origin
Policy. This was not fully thought through at the outset (what ever is, in
human history?), and is therefore exploitable. People have come to rely on
this. We'd need to propose a solution, and as noted upthread, there are
indeed good capability patterns.

Note that I'm not saying "ocaps are teh suxorz" -- if I were, believe me,
all y'all would not need to guess. :) All I'm pointing to is that millions
of person hours over a couple of decades on a poorly thought-out foundation
will produce something that ordinary users consider more "easy to use" than
the work of the most talented researchers (e.g. esteemed members of this
list) on a well thought-out one. It's a tough challenge.

      ~   ~   ~   ~   ~

As for the remainder of the proposal I made, it is clear to me now that I'm
making a nontrivial claim. So I withdraw for the moment my assertion that
we will not have created secure and usable ocap systems unless we solve
that problem. I still suspect that to be the case, but the argument I'd
need to make is nontrivial.

Let me summarize, though, that my goal with such a proposal is not that an
average end-user should see a trusted path with annotations and metadata
and what not. Ideally, the user should see *one* decoration on each
distinct object in the UI -- green for "it's ok to make yourself vulnerable
to this object for stuff that you care about", and red for "it's not ok to
make yourself vulnerable to this object".

I would hope that my bank or BTC wallet would show up as green, and a
"punch the monkey" game someone sent me would be red. The great thing about
ocaps is that I could still enjoy the punch the monkey game, and might even
drag and drop the equivalent of $2 into it to get more monkeys, but would
have no more faith in what's going to happen to that $2 than I do if I buy
a cheap touristey tchotchke at a roadside stand.

The power of ocaps is to make it possible to enjoy the cheap touristey
tchotchke despite my lack of trust. But it does not absolve me of the
responsibility to not do dumb things. As for the architecture that would
guard against doing dumb things -- well, that is the thing for which I have
a proposal, and which we'd need to discuss, and which I'm clearly not going
to do justice typing with my Android tablet. :)

Ihab

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.