Thanks a lot for the extensive review :)
sajolida:
> Meta: I'm realizing now that George was probably not put in copy while
> discussing the UI on tails-ux [1] and now we're discussing many UX
> issues on tails-dev without putting tails-ux in copy. All my comments
> probably make more sense on tails-ux so I'm moving there with George
> still in copy.
>
> [1]: https://mailman.boum.org/pipermail/tails-ux/
>
> segfault:
>> George Kadianakis:
>>> segfault <segfault@???> writes:
>>>
>>> [...]
>>>
>>> I gave your iso a try! The application seems to work pretty well!
>>
>> Thanks for testing it!
>
> Same here this morning and I was really impressed by the state of
> things!!!
:)
I didn't read George comments before doing my testing (so
> duplicated comments are really duplicates).
>
>>> Here are some nitpicking comments. Feel free to ignore comments that involve
>>> parts you have not yet implemented.
>>>
>>> - When Mumble starts it just says "Online". There is no indication on how to
>>> use it, what's the onion address, or how you connect to it.
>>>
>>> - Why is the reset button available only for Gobby?
>>>
>>> - Mumble has no options? Not even port or onion address like Gobby?
>>
>> That should not happen. Seems like you discovered a bug. But I can't
>> reproduce it in the current version. :/
>
> I didn't get that bug.
>
>>> - OTOH, Gobby provides useful information when it starts, like the onion
>>> address and the port.
>>>
>>> However, in both cases I was actually not sure how to test or use the
>>> service. I wonder if it would make sense to have a small paragraph for each
>>> type of service pointing to resources on the internet, or a small guide on
>>> how your friends can connect to you... (hm, localization issues?)
>>
>> I plan to relay on the documentation for this (the question mark).
>
> This also relates to the mental model issue I wrote you about in private
> the other day. I feel like we need to make it more explicit somehow how
> these services need to be used.
>
> You have the "Connection Information" field which is a good start but I
> feel like we need something more. Maybe we should differentiate and
> treat better the three different areas of the right pane:
>
> 1. General information, service status, On/Off button
> 2. Service settings
> 3. Connection Information
>
> Because right now for example the connection information look like a
> setting while it's instead a summary of read-only information that are
> themselves extracted from the settings (Onion Address, Password).
> Hypothesis:
>
> - The connection information could be displayed only once the service is
> started (right now I get "None" before the service is set up and that's
> useless and confusing).
ACK
> - Maybe it could be displayed at the bottom and be a bit more verbose,
> like George suggested, it could be:
I think it should be at the top, because it's more important than most
of the options.
> "To connect to this service, use:"
>
> - Application: Mumble (included in Tails)
> - Address: pecdctvzgspqtlif.onion
> - Port: 64738
> - Password: ***********
I like the idea to include the name of the client application.
> If the application is not included in Tails we would display something
> different and tell which software package to install; but I don't think
> we have valid examples right now.
ACK
>
> I hope this could be added without making the window too clumsy.
> Otherwise maybe have a button "Learn how to connect to your service"
> with a popup with this information and an explicit link to the
> documentation.
I thought about displaying the connection info only on click. Especially
if we decide to use the "editable labels" approach, this would neatly
blend in with the other clickable labels. The attached screenshot uses
these clickable labels (like suggested by Spencer in previous drawings).
I see several advantages with displaying the connection info on click:
- It doesn't overstuff the panel with the connection info
- It doesn't display duplicate information next to each other
- It doesn't display the clear text password in the main window (and the
password obviously has to be displayed in clear text in the connection info)
- The user will be able to see the complete information without resizing
the window or copying it blindly to the clipboard
>
>>> - In Gobby, is the server password securely auto-generated? Can we make this
>>> more obvious maybe? Or maybe can we have an opt-in "auto-generate" button
>>> that generates a password only if the user wants?
>>
>> In both Mumble and Gobby the server password is a 20 character random
>> string. We could implement a button to generate a new (secure) password,
>> but I kinda like the secure default. Do you think explaining this in the
>> documentation would be acceptable?
>>
>>> Or maybe the current auto-generate by default approach is best for UI. Not sure.
>>>
>>> BTW, did you write the password generation routine yourself or is it a
>>> module? You don't have one that uses readable words instead of random base64?
>>
>> I use Python's random module:
>> import random; import string;
>> ''.join(random.SystemRandom().choice(string.ascii_letters +
>> string.digits) for _ in range(20))
>>
>> I kinda expect users to copy-paste the `Connection Info` (including
>> onion address and password). But I think you're right and it wouldn't
>> hurt to use something more readable. I did a quick search and didn't
>> find any Python module in Debian that provides such a function. Do you
>> know one?
>
> I'm more and more doubtful about whether we should provide password
> generation at all (sorry), or at least not by default.
>
> I understand that the intent here is to provide strong passwords by
> default. But unfortunately, people are not used to manage such random
> passwords and I'm wondering whether it will lead to more troubles than
> benefits. We (übergeeks) have quite different ways of dealing with
> passwords and secure communications than what I expect to be (or would
> like to be) the average Tails user. I'll miss personas here to make my
> point!
I disagree on this one. I think random passwords are actually more
usable than leaving it to the user to pick a secure password. From my
experience, thinking up a new secure password is one of the hardest and
most time consuming parts of every cryptoparty. Writing down a 20
character password on a piece of paper is a lot faster. And we already
have the onion address, which is a unmemorable information required to
connect to the service. So the user will have to save the connection
info somewhere anyway, so memorable passwords are not that much of a
benefit.
Currently users don't have to modify any configuration to start a secure
Mumble service. I don't want to lose this awesome feature by having
users to think up a secure password before they can start the service.
> Such passwords take for granted that people will send them over the
> Internet through secure channels. I think that proposing this by default
> can be problematic depending on the password culture of the user. For
> example, some security practices teach you to never send a password (in
> clear text) over the Internet. Another reasonable practice that I see
> around me is to have weaker passwords but that people can memorize and
> share only in person or written temporarily on pieces of paper.
I don't see why we need weaker passwords if people write them down to
share them.
> People might also not (yet) be clear about what a secure channel is
> appropriate for sending such passwords. Is sending emails through GMail
> and HTTPS all-right?
>
> People receiving these passwords will have to store them somewhere and
> if they are not used to use a password manager they might do something
> much worse than using a weak but memorable password.
>
> And if they are used to use a password manager, then they can use the
> password generation tools from there. Which will have more features than
> the one we can provide here (diceware!). This is what I would be
> personally and having the password generation directly in Tails Server
> wouldn't bring me much benefit as I'll probably want to generate more
> readable passwords for example.
>
> On the other hand, providing a traditional blank password field wouldn't
> question the usual password management of people. They might equally
> prefer shared memorable passwords or already be using a password manager
> that can generate random passwords.
Providing a secure default password doesn't prevent people to set a
memorable password or generating random password on their own.
> Of course, I would love to teach people to use password managers and
> always different random passwords but I don't think that Tails Server is
> the place to do this.
People won't necessarily need password managers to use the random
passwords, but beside that, I think Tails kinda is the place to teach
people to use a password manager.
> Also, password shouldn't be displayed in clear text by default. That's
> another reason to let the user choose their own password: it will be
> easier for them to find out what it is.
We can find other means to solve this, for example the clickable labels
(see screenshots).
>
>>> - When Gobby is offline, the "Connection info" says "None". Maybe it should say
>>> "Service has not been started" or sth?
>>
>> A status message is already displayed above, in the status line. The
>> onion address is also "None" if the service was not started yet. I don't
>> know if it makes sense to set them both to status messages instead.
>
> +1 I think it shouldn't be displayed until the service is started
> (because there's no real "connection" to get "information" about yet).
>
> Some more comments in no particular order:
>
> 1. Regarding the terminology "server" vs "service". The application is
> called "Tails Server" but then we always talk about "services". I don't
> think it's bad as such but I wonder how it will be understood by users.
> Maybe you could ask some questions like this at the end of your testing
> session, during the debriefing:
>
> - What does the word "service" means to you?
> - What does the word "server" means to you?
> - Why is the application called "Tails Server"?
Not sure if it's that important. I'm totally fine with renaming the
application to "Tails Services" if that is what you are aiming at.
>
> 2. Related to that, in the connection information, different client
> applications use different terminology and we should help people
> understand this. For example Mumble talks about "Server" and "Address"
> and Gobby asks for the "Host Name". Maybe we could display, for example
> for Gobby, one of:
>
> " - Address: pecdctvzgspqtlif.onion (host name)"
> " - Address / Host Name: pecdctvzgspqtlif.onion"
> " - Host Name: pecdctvzgspqtlif.onion"
Yeah, I agree that we should adapt the terminology of the clients. I
think I prefer:
" - Address (Host Name): pecdctvzgspqtlif.onion"
> 3. When first starting the application, both the [Add Service] and [+]
> buttons do the same thing. You're also missing a sentence as placeholder
> for the empty left pane. I propose we solve both issues at once by
> removing the "Add Service" button and writing instead something like:
>
> « Tails Server allows you to create online services to which other
> people can connect through Tor. For example, you can create a Mumble
> service to organize group calls.
>
> Click '+' to create a new service. »
That seems good.
>
> We could even have a little monochrome schematics of a Tails Server and
> several clients connecting to it. If you want that I can volunteer to
> draw it :)
That's a fun idea and I would love to see it. But do you think it would
really help users?
> Maybe add a link to the documentation of Tails Server in general here.
ACK
>
> See https://developer.gnome.org/hig/stable/empty-placeholder.html.en
> also reads "If there are controls that allow items to be added, it can
> be appropriate to highlight them using a suggested style while the
> list/grid is empty." which is, I understand, the button with a blue
> background. Maybe it's worth trying...
ACK
>
> 4. Still when first starting the application, the [-] button active but
> does nothing. Why not deactivate it?
ACK
>
> 5. We could maybe find something different to translate the dependency
> between "Autostart" and "Persistence", to avoid always displaying
> "(requires Persistence)". What about:
>
> - Putting "Autostart" in the same line as "Persistent".
Not sure if this would make the relationship clear enough.
> - When "Autostart" is clicked while disabled, display a popup reading:
>
> « You can automatically start a service when starting Tails only if
> the service is made persistent first.
>
> [Cancel] [Make Persistent] »
Not sure about this one either. Should the checkbutton still be grayed
out? Will the user click on a grayed out button? Also, unexpected popups
are quite annoying. I would like to find a nicer solution.
> This would both clean the main window and provide more information about
> the relationship between the two options.
>
> 6. I'm still not convinced by the usefulness of the [Reset] button for
> the onion address:
>
> - What would be the user scenario for changing the onion address of a
> service which already has user data, for example, a Gobby service for
> which several documents have been written already?
For services which don't have a password (none implemented yet, but
there will be), the onion address is the only information needed to
access the service. If you want to use the service only in a defined
group of people (which is the main use case I have in mind for Tails
Server), resetting the onion address is the only way to exclude people
from this group. Of course this changes once I implemented the client
authentication. Maybe then we can discuss again if it is reasonable to
allow resetting the onion address.
> - What's the advantage of changing the onion address of a service with
> no user data, for example to organize a Mumble call with different
> people, instead of removing and creating a new service?
Keeping the rest of the configuration, for example the certificate.
> - Isn't it always better to recreate a new service that to reuse one?
> Could it be problematic that people change the onion address instead of
> creating a new service in certain scenarios?
I think allowing users to keep their configuration makes sense.
> If we keep this option, I'd like to rephrase the dialog. Also, the new
> onion address is not generated until the service is restarted which is
> not clear (I expected a new address immediately which is what I
> requested by clicking on the button).
Yeah, I intended to generate a new address (which is why the button was
labeled "Generate New" until recently), but this is technically not
feasible without publishing the service (or a lot of unnecessary
complexity). I'm not satisfied with the current label either, but
couldn't find anything better. Do you have a suggestion?
> 7. I like the status spinner and little status sentence! Still, I don't
> understand why it says "Connecting to Tor" while my Tails is already
> connected to Tor :) Maybe we should say "Registering onion address" or
> "Configuring service" instead or something that would make a more
> explicit reference to the service itself.
ACK. I like "Registering onion address", because this is close to what
is actually going on (actually, what is taking so long is sending the
hidden service descriptors to the hidden service directories and waiting
for their responses).
> 8. In the Mumble client, how should I check the server's certificate?
> I know that you are working on an upstream patch to display the
> fingerprint of the server in this dialog but we're probably missing this
> information in the "Connection Information" from Tails Server.
I already added the fingerprint to the Connection Info a few days ago.
Was it not included in the latest nightly?
> 9. I like the edition widgets. And the fact that they are disabled when
> the service is running seems pretty clear.
The problem with this is that users can't select the strings to copy
them while the service is running. This is another reason why I like the
clickable labels approach, because with them we could use regular labels
while the service is running, which allow text selection.
> 10. When adding a new service, I wonder about the workflow. Sometimes
> people explore and try stuff just to see what it does, and we should
> allow and support this; especially for something like Tails Server that
> might end up having many different services with obscure meanings. Right
> now when I add a new service I have:
>
> i. The list of services with the name of the service and a very
> short description.
> ii. The service is created with the status "Installing". Maybe if I
> was only exploring I would feel like things were going too fast
> and instead expected to get more info about the service before
> modifying my Tails. Would it be hard to move the installation at
> the beginning of the first launch? Still, it's a minor issue :)
> Maybe we could still start `apt update` in the background!
Mmh, the problem with this is that for some options we need the
configuration files to get the default values. This is why the options
are only displayed once the service installation finished. So if we only
install it when the user starts the service, he won't be able to modify
the options beforehand. Also, it can be easily reversed by clicking the
"-" button (and doesn't block the application).
> 11. Maybe to support this exploration and learning even better we could
> make the question mark button, the one that links to the user
> documentation, even more explicit. Maybe "Learn more about Mumble..."?#
Maybe, but this needs requires some work, because then the button won't
fit beside the title anymore. Redesigning the GUI is always quite time
consuming for me and there are many other things I want to work on which
have a higher priority IMO, so don't expect this to happen soon.
> 12. Why say "Virtual Port"? Isn't "Port" enough? In Mumble client at
> least the field is called "Port" only and we should match this.
Yeah, I guess we could name simply name it "Port". Originally, there was
also the "Local Port" option, which is the port the application actually
listens on locally (while the virtual port is the port that is opened
via Tor). The local port would be needed if we support multiple services
which would use the same port. But this might actually happen sooner
than later, because I think there will be multiple web services.
> 13. In Gobby, "Autosave Interval: 30", 30 what? You missing a unit here.
ACK
> 14. In Gobby again, the client asks for the "Host Name" and the port is
> not needed by default. So I propose we simplify the connection
> information not to mention the port; unless it's not the one by default
> but I'm not sure in which user scenario this would make sense.
ACK
> 15. When trying to stop one of the services, the spinner and the status
> "Stopping..." went on for more than a minute so I thought they got stuck
> and restarted the service instead (and it worked).
Yeah, Gobby's status doesn't turn to "stopped" but stays in "stopping".
This is a known issue which I couldn't fix yet, because somehow the
systemd unit doesn't send an "inactive" signal.
> 16. When removing a service, could we propose a backup of the service?
> I'm thinking of Gobby here for example, where there is no way of
> accessing the internal documents (outside from the clients). Maybe we
> could create an archive of the configuration, the onion service key, and
> the data of the service as a backup? I felt that this could be a cheap
> way of being forgiving when people remove a service but maybe this would
> duplicate a possible future backup tool in Tails.
Yay, more compexity :) I think this should be left for future work.
> I'm attaching a few screenshots that might help others understand what
> we're talking about.
You forgot the screenshots ;)
