On 26.03.2010 13:44, Gervase Markham wrote:
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
Hi Gerv,
thanks a lot for your feedback. I've created a graphical presentation
for the client authentication part:
http://kuix.de/mozilla/sslauth/cli-v1-pres/
Some more explanations:
There isn't a lot of UI involved, besides some icons and a configuration
dialog with dynamic content (see ASCII screenshot in the client
authentication document, pages 7 and 8).
(For each icon there'd be a related menu command for accessibility.)
When an icon is clicked, you'd get a popup menu with the list of related
sites (connection attempt or currently authenticated).
If there's just one related site, we could jump to the config dialog
directly.
I'd put the icons on the status bar, but I'm fine with any location in
primary chrome. If neither client auth nor bad certs are involved, all
icons are hidden.
On 16/03/10 23:12, Kai Engert wrote:
In short, we'd like to stop the current prompts and implement a better
user interface.
I think that it would be extremely wise to include Mozilla's UI design
community as we look for a solution to these problems.
Sure!
> Do you have any plans to reach out to them?
> I notice your message was not cross-posted
> to mozilla.dev.usability... You mentioned Aza's previous post. Has he
> looked at your proposals?
I made Aza and Johnathan aware the day I posted the documents here, but
I'm still waiting for their feedback. I'm fine to cross-post.
I believe the concept related the "logged in = using authentication"
state is similar or identical to Aza's post.
The differences are:
- the location where the indicator is shown
(I don't mind where exactly it will be shown,
but would highly prefer the same location for both
"authenticated" and "not authenticated" icons.)
- the contents shown in the indicator
(I propose an icon,
while Aza used a "john @" prefix in the URL bar,
which may be difficult to do when using client certificates,
because of the difficulty to derive a short unique name from a cert
containing a potentially very long common name (CN).
(Although Axel Hecht had the inspiring idea to allow a user to assign
short nicknames to each personal cert.))
From reading the documents, it's clear that we do have a difficult
simplicity/power tradeoff to make here.
I hope we can find a solution that is acceptable to UI designers
for simple scenarios, but powerful enough to cover advanced scenarios,
(without requiring background configuration to enable advanced modes).
In order to help make it, do we
have any statistics or ideas how common it is to have scenarios like:
I don't have any statistics.
As of today there are probably not too many sites on the web using
client authentication, but that may also be related to the fact that
it's difficult to use with browsers. It may change once we make it
easier to work with.
- A page whose components and subcomponents together require auth using
more than one client certificate
- A page where the top level does not require a client certificate but
sub-parts do
Even if a single certificate is sufficient to access all components, the
components may be located on multiple hosts, like html.site.com and
images.site.com and private.site.com, and the user needs to control
where to present the site, and where not.
I agree it's an advanced scenario that sites should avoid, but some may
not. There may be existing complex sites where there's the desire to
start using client auth, and where it may be hard to consolidate to
single hosts.
Automatic sending of client authentication credentials is considered a
privacy issue, that's why Mozilla software currently doesn't send it by
default.
For the same reason I would not automatically send authentication data
for sub content on separate domains, even thought the user has agreed to
authenticate with the main page.
Although we have a good solution in the browser (show an error page,
allow override), the solution in non-browser applications (e.g.
Thunderbird) is inferior.
Why do you say that?
Because click-through is being considered "bad".
> Non-browser applications are very different to browsers. For mail, for
> example, you do not add and remove dozens of mail servers on a daily
> basis. As long as the software allows you to remember an override, I
> don't think there's an issue in using a popup in this case.
Let's say you have your mail server configured.
Now you're in an Internet Cafe, someone MITMs you, and you get a cert
warning for your mail server cert.
As people tend to click-through warnings, so we should make it more
difficult for this attack scenario to work.
Instead, we should
use an error status indicator in the chrome (for one or multiple
failures),
I think the risk is that such an indicator would not be noticed, and the
user would be confused when their application didn't work.
In the "bad cert" scenario for non-browser applications, we'd show the
error message (without click-through), which ensures that the user will
notice, and can find the status bar indicator (maybe a
yellow-human-with-question-mark) to get to the "add override" dialog etc.
Although I've stated that we want to avoid prompts, for the client-auth
scenario, we could agree to still use prompts, if the user visits a site
for the first time, in other words, if the user has never accessed the
client-auth configuration dialog for a site.
Once the user has configured (using a cert, or not using a cert), we'll
remember, and can avoid the prompt in the future.
With this approach, the user will have the chance to notice when a new
sites requires authentication.
Hope this all makes sense and looking forward to additional feedback.
Regards,
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
