Re: browser change; little, nothing or a lot?

On 12 Feb 2011, at 02:24, peter williams wrote:

> One output of the group can be to outline changes to browsers (and http libraries used in multi-site apps).

yes. We even have ISSUE-14 for the "WebID and browsers"

> We tended to start with: FOAF+SSL has to work with the last 5 years’ worth of deployed browsers.

Yes. That means it is immediately deployable and useable, allowing other things to develop in linked data space.

>  
> But, we also see threads that say:
>  
> Change the UI

There are different issues here:
  - obvious changes, such as Firefox certificate selection for example is obviously bad/no design
  - bugs that need to be fixed whatever happens (such as Safari sending client certs without the user being able to stop it or being aware of it, once he has made an initial decision)
  - UI improvements: 
    + displaying what identity the user is logged in as and allowing him to change it
    + tying cookies and all more tightly to the identity chosen by the user
    + using information from the WebID to improve UI of cert selection
    + allowing user to jump from cert selector to Profile Page in one click  

> Change the ClientHello Extensions (to tie into the likes of SRP, to help out HTTP)

   Forgot the details of these.

> Define a new cert-type like PGP did (hello extension..)

   Could be useful, but clearly independent of the UI issue. There would be a big format war to decide there, and it's not clear what the advantage is going to be, apart from reduction of bugs due to ASN.1 parsing problems. So here I think there needs to be a lot more work done finding the benefits. My guess is that this should be done after wide deployment of WebID, because then the advantages of what should go into such a certificate will be a lot more obvious.

> Tie SSL crypto state to HTTP headers, so that MITM of SSL is at least detectable (the “channel bindings” feature that the Shib group seem to be looking at, FINALLY!)

   I think Bruno Harbulot had suggested something at that level. That would be worth looking into.

> [snip] 
> So one consensus topic can be: how much do we want to recommend changes to browsers – on a scale from none to significant.
>  
> IF we argue that login/logout/clientcert state needs to be accommodated in UI design, my gut tells me: that is so massive in political reality that we might as well go the whole hog: and define a new cert type for use in SSL’s cert msg, getting past X.509 once and for all for clients.

? User Interface changes such as the above are completely independent of the SSL/TLS message type. There is no reason to tie them together.


> So long as it’s a variant of xmldsig, the level of roar from the crowd is going to be deafeningly positive. If its otherwise, it will be a groan, and history will consign another generation of humanity to ASN.1

It's not humanity that is tied to ASN.1. It's browser and security developers. And they may like their esoteric knowledge. So I would not expect a roar of approval.

>  
> Just imagine a world in which one had xml-dsig signed XRD files sitting as simple files on hosts, and xmldsig self-signed credentials for webid protocol… and xmldsig-updated p3P files…. all due to W3C.

What would the user advantage be for that?


>  Just needs will, selling and vision. IE#10 must already be now being conceived…


The vision is going to be easy to sell for UI improvements. 

Henry

Social Web Architect
http://bblfish.net/