Re: A Somewhat Critical View of SOP (Same Origin Policy)

> On 16 Sep 2015, at 20:12, Tony Arcieri <bascule@gmail.com> wrote:
> 
> On Wed, Sep 16, 2015 at 12:06 PM, Henry Story <henry.story@co-operating.systems> wrote:
> Before I discovered <keygen> we were adding keys to Firefox using the
> puposefully  difficult to find certificate properties file. To get users to do
> this could be exceedingly difficult. Even if they did succeed it would increase
> the likelyhood that they would mistakenly add Root Certificates to the keystore.
> And even if they managed to place the keys in the right certificate slot the
> danger would be that they would add client certificates with private keys known
> to other entities, which is very bad practice.
> 
> These are issues of Browser and OS design where ease of use is as important
> as security of the crypto protocol. We can't say that the current situation is
> great: it is a first step on which should have evolved a lot further over the
> past years.
> 
> Yes, that's true, but the UX of <keygen> is abysmal:
> 
> 1) Browser generates key with <keygen> and sends it to the server to be signed
> 2) The next response, the user is prompted to install the certificate. The page must now tell the user to acknowledge the browser wants to install the certificate, and do something like follow a link or refresh the page. This is a confusing and jarring workflow
> 3) After the user has the certificate installed and makes another request, the user is now prompted for which certificate to use. They have to choose the certificate they just installed. Hopefully they're able to figure out what this is. If more than one site is using <keygen>, the user must pick the correct certificate for the site
> 
> This is a terrible user experience. If client certificates were origin-bound, it would eliminate the need for the user to select the appropriate certificate for the site.
> 
> Compare to something like a U2F token:
> 
> 1) User enrolls the token by pushing a button
> 2) User authenticates by pushing a button

Yes, what FIDO has helped is to make progress by taking on
only one use case.

But it does not cover the use case of cross origin identification. 
For that some more User Interface innovation is needed.

This would require something along the lines of what I posted
to the TAG and I'll repost here:
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0063.html

[[
So part of the problem is of course that since the inception of `<keygen>` 
JS  has taken over and we end up with problems of which agent actually 
is responsible for which action.  This has corrupted the intended 
meaning of the <keygen> tag. ( I have been thinking in my work about 
the intention of keygen - well aware that the reality of it had not been
developed to the full )

In this case since the keystore is being affected and the user did not click
the button - it makes sense that the toolbar indicating insertion of the 
certificate should allow the user to decide whether to accept that action. 

Of course you'll answer: how does one get the user to understand what that
action means? 

This would require an intuitive Identity UI - based on a card and wallet 
metaphor perhaps -  which has to be consistent throughout the web 
and even the OS experience. An action of adding a certificate to such a 
keystore has to make it visible as such a card being added to the wallet. 
This is only needed if the card is to be used cross origin.  So for example
the current FIDO UI would not need that.

Addition of cards to the wallet should be sortable by origin in the wallet.
Origins that add a lot of useless cards to spam the user, should be 
deselectable by the user in bulk, and he should be able to either limit 
their use to that origin, or delete them, and refuse further ones from them.
It seems that making the origin of a card visisible is another important element
of this.

What this suggests is that the keygen tag during the process of calculating
the public private key should open an empty card and have some way of indicating
to the user that the action of producing one is in gear. This again is part of the
chrome/OS and should not be something the page can hide. 

This is the type of thing that is needed to put the user in control. It's along the lines
of the marketing that is going into fingerprint authentication making its way 
into phones.

This would be required whatever the type of support for the card. (X509 is just an
accident here ). From the User's point of view: the card UI is what is real, meaning
that better formats can change under the hood.
]]

>  
> -- 
> Tony Arcieri

Received on Wednesday, 16 September 2015 19:36:53 UTC