segfault:
> 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:
>>>>
>>>> [...]
>>
>>>> - 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.
I agree with that reasoning and it should be easy to implement if the
connection information are displayed on click only (otherwise it will be
difficult in the layout to have them on top but not populated initially).
>> "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'm fine with that. From what I proposed earlier, I wonder whether it
would gain in clarity to even further distinguish what are "status
information" (now including the connection information button) and
"settings". Because on these mockups it's not clear from the layout only
that "Connection Information" is not a setting (it's something that you
have to understand through the meaning of the label).
> 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
I agree with all this.
> - 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)
But I'll disagree on this one again, sorry. In KeePassX, for example,
even when displaying the detail of an entry, the password is still
obfuscated, but there's an "eye" button to display it in clear. Still,
even when obfuscated, you can copy and paste it somewhere else, without
ever displaying it on the screen.
> - 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.
I'm still not convinced but I'll refrain from repeating my previous
arguments about the whole password thing. It's your project, it's
probably fine like this, and if it's not you should find out during testing.
>> 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.
Right, Tails is the place to teach about password managers and, as such,
the place to teach people that *password managers* are the tools to use
in order to generate strong random passwords. But unless you point back
to some password manager from Tails Server, you're not helping with
teaching this (and as said already, I don't think Tails Server is the
place to do that).
>> 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.
That's not my proposal as I prefer "Tails Server" and "service" as we
use them until now :) I'm just curious about how this is understood by
people. It might as well cause no problem, but I don't know, and if it
does cause problems then we should think about it again.
>> 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"
Up to you.
>> 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?
I think we should wait for the results of your first tests. Maybe people
will have no problem understanding the server → service → client thing.
If that's hard to understand, then yes, I think that a schematics might
help transmitting this.
>> 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.
Ok, so the user scenario for changing the onion address of a service is
to revoke access from people who had it previously (without loosing the
data from the service). Makes sense! (and should be mentioned in the
documentation as I wouldn't figure this out myself otherwise).
>> - 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?
I'll do that. I want to review all your user-visible strings "at some
point".
>> 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?
I probably got an older one...
>> 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).
Fair enough. If it's not easy then let's forget about that.
>> 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.
I'm fine with leaving it like this. Testing might further raise or lower
the importance of this.
>> 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.
:)
