Re: Design help requested: Certificate Chooser UI.
On Fri, 2016-06-10 at 11:47 +0100, David Woodhouse wrote:
>
> If the GtkFileChooser would just allow us to use it *without* its own
> GtkPlacesSidebar, that would probably suffice...
Ahem...
gtk_widget_hide(
/* GtkPlacesSidebar */ gtk_container_get_children(
/* GtkHPaned */ gtk_container_get_children(
/* GtkBox */ gtk_container_get_children(my_file_chooser) -> data
) -> data
) -> data
);
(Yeah, I know. Nasty proof-of-concept hack. Really nasty.)
This actually kind of works — we can place our own GtkPlacesSidebar
*next* to the 'hacked' GtkFileChooser, and we could theoretically sync
the settings of that one into the 'hidden' one in the GtkFileChooser,
to make it look like the real one.
However, the plan falls down we can't actually add our own non-file
locations to a GtkPlacesSidebar. This just doesn't do anything:
gtk_places_sidebar_add_shortcut(self->page1_visible_sidebar,
g_file_new_for_uri("pkcs11:..."));
If we do want to show the 'foreign' locations like PKCS#11 tokens in
the GtkPlacesSidebar — whether it's "properly" with the co-operation of
the GtkFileChooser, or whether it's done externally — we'd want to
resolve that.
For the time being I suspect unless anyone comes up with any bright
ideas, we might just stick with a separate list on the left-hand side
with all the tokens and 'File system', as the ASCII art in my previous
email showed. We'll leave fixing that as an exercise for a later date.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Fri, 2016-06-10 at 06:35 -0400, Nikos Mavrogiannopoulos wrote: > Only a nitpick. "Choose from PKCS#11" is very cryptic for users. I don't > expect from someone not working in security to understand what is this > about. "Choose from smart card" is something more approachable. Except it isn't correct either. Since 'smart card' then includes such locations as GNOME Keyring, and the user's NSS database. Seriously, the *good* way to do this from the UX point of view is just to make the PKCS#11 tokens show up as locations/shortcuts in the chooser, alongside the various directories. That's what you had in the design study: https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 The only problem with this is that it's hard to expose the internals of the GtkFileChooser to allow us to 'take over' the internal browse_files_stack and display our own list of objects within the token — which we need because it needs to look like the Seahorse display in the main pane of http://david.woodhou.se/seahorse.png and the 'file browser' doesn't cut it. And obviously we don't want to use something *other* than a GtkFileChooser for the case where the user *is* actually choosing files; that would be horrid too. If we can't fix this to be like the mockup, maybe the least-bad option is to have two separate 'places sidebars' side by side. The first isn't really a GtkPlacesSidebar; it's a lit of all the PKCS#11 tokens PLUS 'File system'. And then when it's selected, the GtkFileChooser with its own GtkPlacesSidebar is shown next to it. So it's... - | PIV_II | Recent | Gnome2 Key Storage | Home | Gemalto | Documents | Entersafe | Downloads | | ... |→File system← | | | That is still marginally confusing — users will ask why can't they all be in the *same* list instead of having to select 'File system' first? But at least it isn't as bad as our current hack. If the GtkFileChooser would just allow us to use it *without* its own GtkPlacesSidebar, that would probably suffice... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Wed, 2016-06-08 at 21:48 -0500, Federico Mena Quintero wrote: > On Wed, 2016-05-11 at 13:08 +0100, David Woodhouse wrote: > > Tyagi is working on a GSoC project this year, implementing a > > certificate chooser which will probably live in the GCR library. > > I would love to have exactly this thing available for use, for example, > from gtk-vnc and vinagre. > > Right now gtk-vnc assumes that the user will put certs and keys in some > hardcoded locations. The code more or less allows for a scheme where > the user would be prompted for them instead; I'd love to have a good API > to call there. Thanks, Federico. I'd be very grateful if you could join us on #keyring and also check out Tyagi's current work: https://github.com/tyagi-prashant/gcr The new dialog can be tested by running ./gcr-certificate-chooser-test after building GCR. Aside from the request for overall design assistance as discussed, we could also do with some help with the details — just things like when we select a certificate and its preview is shown, everything in the dialog is jumping around as things change size. Those would probably be trivial for you to help with, but neither Tyagi nor I are particularly familiar with the intricate details of how to lay things out properly. If you could help with that, it would be much appreciated! -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Mon, 2016-06-06 at 13:43 +0200, Bastien Nocera wrote: > As nobody has replied, and you asked me to look at the mail, here it > is. Given the long mail and the incredibly specific application of it, > it's unsurprising that there were no answers, and I'll try to explain > why. Thanks, Bastien. I've created a page at https://wiki.gnome.org/Design/OS/CertSelection for this. To keep things simple I've reduced the scope — from the overall "cert + key chooser wizard" flow (which is fairly uncontentious) to just the internal widget which gets used twice to choose *an* object. That's the part we really need help with. The design used in the Red Hat user study was based on a file chooser, with additional 'shortcuts' in the places_sidebar for the PKCS#11 tokens. It seems quite intuitive for the user, and could be made to work well: https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 The problem is that this is non-trivial to implement without access to internals of the GtkFileChooser widget, and there is understandable resistance to providing that. (As a straw man proposal, we can *already* add shortcuts with 'pkcs11:' URIs, so one way we could implement this is by just adding a way to register an widget to live in the browse_files_stack for a specific URI protocol. So 'file:' is built-in, and you can add others. You might even pretend this is a cleanup and handle things like 'Other Locations' that way instead of with special cases in the main code). I've even considered a hack where I register the additional shortcuts for the PKCS#11 tokens, but when they're selected I flip *away* from the GtkFileChooser (which can't handle them) to something else which looks identical to it — with a shadow of the same places_sidebar, but with the Seahorse-like PKCS#11 object browser in the middle. And when the user selects a file shortcut again, we flip back to the real GtkFileChooser. But... ick :) So for now we've side-stepped the issue by having explicit buttons for the user to press for 'Choose from file' vs. 'Choose from PKCS#11'. Once we've finished the cosmetics, we end up with something which is basically the same as our "ideal" idea above — it's just that the location pane can only show file locations *or* PKCS#11 locations at any one time, and you have to "change modes" to flip between them. It seems hard to justify that from the design/UX point of view; only from the "oh, it's too hard to do it nicely" point of view. It's that conflict I'd appreciate help resolving. If anyone can come up with a design idea that *doesn't* involve "nasty hacks" to the file chooser, that would be great. I'd also settle for a consensus from the design side that "we're in this to make it work nicely for the users, not to make life easy for the implementers. Just get on with it" :) Perhaps a slightly less intrusive request for GtkFileChooser is "let us hide this places_sidebar". Then I can put my *own* places_sidebar next to it and I *can* flip to a more appropriate object chooser when it's not a file shortcut that's selected? Thanks! -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design help requested: Certificate Chooser UI.
On Wed, 2016-05-11 at 13:08 +0100, David Woodhouse wrote: > Tyagi is working on a GSoC project this year, implementing a > certificate chooser which will probably live in the GCR library. I would love to have exactly this thing available for use, for example, from gtk-vnc and vinagre. Right now gtk-vnc assumes that the user will put certs and keys in some hardcoded locations. The code more or less allows for a scheme where the user would be prompted for them instead; I'd love to have a good API to call there. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Design help requested: Certificate Chooser UI.
Tyagi is working on a GSoC project this year, implementing a
certificate chooser which will probably live in the GCR library.
We currently have a variety of incomplete and buggy implementations of
this, spread across various places; especially NetworkManager UIs and
the VPN plugins. All of them get *something* wrong — not implementing
support for certain types of certificate/key file, or not supporting
PKCS#11 for access to objects in gnome-keyring and hardware crypto
tokens.
The point of the project is to have a consistent UI for choosing a
certificate (and corresponding private key), which everyone can use.
This is https://bugzilla.gnome.org/show_bug.cgi?id=679860
The "output" from such a widget would be four things:
• Certificate location (file:… or pkcs11:…)
• Passphrase or PIN for certificate, if necessary.
• Key location (file:… or pkcs11:…)
• Passphrase or PIN for private key, if necessary.
In some cases the certificate and key are found in the *same* location
(in the same file, or referenced by the same PKCS#11 URI). In some
cases there may not be a passphrase or PIN. In rare cases, you might
need different passphrase/PIN to access each of the certificate and the
key.
The overall UI flow of the certificate chooser probably ends up looking
something like...
• Select certificate (from file or pkcs11)
• If PIN/passphrase required, ask for it.
• If key in same location, display 'preview' and activate 'OK' button
• If no key, select key (from file or pkcs11)
• If PIN/passphrase required for key, ask for it.
Once the certificate and key are both found and unlocked, we can do a
crypto operation to check that they *match*, display the details of the
cert/key, and allow the user to click 'OK'.
There's scope for UI designers to improve that overall process, and
feedback would be welcomed. Note that the above description slightly
glosses over some of the details about precisely what the various file
formats can support and *when* the PIN is needed.
But the most important thing right now, I suspect, is the thing that
crops up twice in the above:
• select from file or pkcs11.
We had an intern at Red Hat do some user interaction tests¹, and the
favoured model looked like the mockup shown at
https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663
Basically, the available PKCS#11 tokens are shown as 'locations' in
what otherwise looks like a file chooser dialog. But when those
locations are selected, you end up with an inner widget (in the
GtkFileChooserDialog's "browse_files_stack") that lists objects in a
PKCS#11 token instead of files in a directory — modelled more on the
Seahorse UI as seen at http://david.woodhou.se/seahorse.png
From the purely UI point of view this seems (to me) to be ideal —
presenting the available PKCS#11 tokens as "locations" makes sense, and
seems like the better user experience.
However, it's apparently a pain to implement, and requires extensions
to the GtkFileChooserDialog that don't make people happy.
I'm reluctant to implement a top-level choice, *first* forcing the user
to choose between file and PKCS#11, and then having a list of file-
locations vs. a list of pkcs11-locations depending on that first
choice. I just don't like that from the UI point of view, although I
appreciate that there's a trade-off between UI and ease of
implementation, and also that I'm not the person to be having strong
opinions on UI design... which is precisely why I'm here asking for
feedback.
I think we *could* make the model in the mockup work; we might even be
able to do a nasty trick with a GtkStack which has one child which is a
GtkFileChooser and another child which is a widget of our own design
which just happens to *look* like the surroundings of a GtkFileChooser
(the locations bar on the left, and our own PKCS#11-selector in the
main area). We'd mirror the contents of the location ("shortcut"?) list
in both widgets... and when a PKCS#11 location is chosen we'd flip the
outer stack to display our own one, and when a file location is chosen
we'd flip to display the real file chooser instead.
That's a vile plan, of course; it does seem like there should be nicer
ways to enable this use case in GtkFileChooser. Perhaps by allowing the
caller to register a URI "scheme" handler so that when a location with
a matching (e.g. 'pkcs11') URI scheme is selected, the appropriate
callback occurs and our own widget is put into the browse_files_stack.
Or instead of a scheme handler, perhaps a variant
of gtk_file_chooser_add_shortcut_folder_uri() which also takes a
callback to *create* the widget. You might use that approach to also
clean up the special-case for things like 'Other Locations', allowing
that to be provided as the same kind of 'plugin' instead of special-
cased as it is now.
Alternatively... is there a better UI design that doesn't lead to us
asking such questions at all? Suggestions are most welcome. As noted,
I'm not really keen on "choose file
