[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion

troubadour · January 13, 2015, 4:44pm

Have [re]checked the installation steps in Ubuntu (could not do it with Tails. Seemigly, the greeter does not show when Tails is installed on a DVD).

The first screen in Ubuntu shows the list of the available languages. It defaults to English US. The keyboard list comes after the time zone (from the IP address location), the default layout set according to the latter.

In whonix-setup-wizard, the language page is ready, using brute force (listing all the options individually in the code), but there is a way to refine it, and the keyboard layouts can be done with the same design, which may vary. At the moment, all the available languages from kde-l10 are on a separate page. We could show a list box when the user selects “Other languages”, but the list is long (55 items).

Regarding whonix-gw-first-run-notice, I do agree that mixing it with the language options is probably too much.

So the new wizard (greeter, installer ?? Good point, wizard is too reminiscent of Windows) steps:

Greeter: Welcome to Whonix. Default language, other language option. (ready)
If other language:
- languages page (soon ready)
- keyboard layouts page.
- download and install page (progress bar)
- success page (optional ?).
Disclaimer pages.
Connection page.
Tor status page.
whonixrepository pages.
Finish page.
First run notice.

Patrick · January 13, 2015, 6:08pm

Screenshot of “the old?” Tails greeter (see lang selection menu at the bottom):
https://tails.boum.org/doc/first_steps/startup_options/tails-greeter-welcome-to-tails.png
(in context: https://tails.boum.org/doc/first_steps/startup_options/index.en.html)

I can see it when booting the Tails DVD in VirtualBox. There is apparently a bug in my version of Tails / VirtualBox. I need to press the maximize button twice and then I can scroll the window down to see all of the greeter.

For example, when you choose “German” as language, it sets locale and keyboard layout to “German” as well. That’s good usability. And once you choose “German”, all the other messages become German as well.

For the keyboard layout, they prefer showing you the ones that are most relevant for the language you selected. That’s all stuff we shouldn’t reinvent and learn the hard way.

The symbol for “language” and “layout” is not super obvious to me. But that could just be me.

I think Tails now has a tails-ux mailing list where they talk to “usability experts” if I haven’t heard wrong.

Please see also, “Revamp the Greeter UI”:

Maybe that is knowledge that has been concluded from these discussions and perhaps even usability studies?

Tails greeter is fortunately a python app:
http://git.tails.boum.org/greeter/tree/

Can you look into it please to get some inspiration?

[hr]

One thing to point out. You cannot download stuff before going through the connection wizard. I am not sure it’s a good idea to automate apt-get using scripts. That’s a rabbit hole. Too much can go wrong. From apt-get repository down, to invalid repositories, mismatches and so forth. Hard to cover all cases in scripts.

There is a package anon-shared-desktop-langpack-kde:

github.com

Whonix/anon-meta-packages/blob/master/debian/control#L196


      
          Depends: non-qubes-vm-enhancements-cli,
           kicksecure-dependencies-system,
           kicksecure-dependencies-cli,
           whonix-shared-packages-dependencies-cli,
           whonix-shared-packages-recommended-cli,
           whonix-gateway-packages-dependencies-cli,
           anon-connection-wizard, tor-control-panel, ${misc:Depends}
          Description: Default Packages for Non-Qubes-Whonix-Gateway CLI
           A metapackage, which installs packages, for a
           Non-Qubes-Whonix-Default-Gateway without graphical user interface (GUI).
           .
           Do not remove.
          
          
Package: whonix-gateway-rpi
          Architecture: all
          Pre-Depends: legacy-dist
          Depends: non-qubes-whonix-gateway-cli, raspi3-firmware, fake-hwclock, wpasupplicant, firmware-iwlwifi, firmware-atheros, firmware-brcm80211, firmware-ralink, firmware-realtek, iw, linux-image-arm64 (>= 4.16), ${misc:Depends}
          Description: Default packages for Whonix-Gateway-RPi CLI
           A metapackage, which installs packages for a CLI
           Raspberry Pi 3 Whonix-Gateway.
           .

Looks like it’s broken in Whonix 9. But we could fix it for Whonix 10. Would install all the language packages.

If we were to install all language package by default, i.e.:

sudo apt-get install kde-l10n-*

That’d be + ~310 MB. Not sure if that would be a good idea.

During the build process we could also download all the kde-l10n-* packages (the .debs) into a special folder, but not install any of them. Then whonix-setup-wizard could - if the folder is populated - and, then install the appropriate one and wipe the other ones. Just ideas for now.

nrgaway · January 14, 2015, 1:56am

This is how I set a generic locale for Debian and Ubuntu templates:

# Set locale... Works for Wheezy & Jessie
localedef -f UTF-8 -i en_US en_US.UTF-8
update-locale LANG=en_US.UTF-8 LANGUAGE

# Set keyboard layout
# Note:  I only used 'cat' to tmp file here since it was difficult to pass the data via chroot
# and / or systemd-nspawn
    cat > "${INSTALLDIR}/tmp/keyboard.conf" <<'EOF'
keyboard-configuration  keyboard-configuration/variant  select  English (US)
keyboard-configuration  keyboard-configuration/layout   select  English (US)
keyboard-configuration  keyboard-configuration/model    select  Generic 105-key (Intl) PC
keyboard-configuration  keyboard-configuration/modelcode    string  pc105
keyboard-configuration  keyboard-configuration/layoutcode   string  us
keyboard-configuration  keyboard-configuration/variantcode  string
keyboard-configuration  keyboard-configuration/optionscode  string
EOF
    debconf-set-selections /tmp/keyboard.conf

Patrick · January 14, 2015, 6:58pm

The debconf way seems rather difficult, because it requires so many settings. Extrapolating from there to choose a lot other languages looks like reinventing the wheel.

http://git.tails.boum.org/greeter/tree/tailsgreeter/language.py seems to contain lots of stuff we need. Like a python function get_languages (Return a list of available languages codes), language_from_locale (Obtain the language code from a locale code) and much more. They apparnetly also have code to write to /etc/default/keyboard so we don’t have to figure out what to write to such files.

troubadour · January 14, 2015, 8:36pm

Had a quick glance at the Tails code. Yes, it looks like there is a lot there that we might be able to reuse (if I manage to understand it). But as far as I could gather, the big trick is that Tails greeter is a replacement of the display manager (GDM), which allows the locales to be changed on the fly. And it implies that all the languages are shipped in the ISO.

Whatever the solution we find to change the locales, because the wizard is run after the environment is loaded, I do not know if there is way to make them effective without a reboot.

Patrick · January 14, 2015, 10:34pm

Tails greeter indeed is a display manager replacement. I followed their discussions. Last time I checked, they discussed difficulties porting it to newer Gnome. I conclude this is desktop environment specific and therefore bes avoided.

There is one solution, that I find quite simple. We could also start a language selection wizard before loading KDE. Directly start the whonix-setup-wizard GUI using xinit.

Try this.

sudo service kdm stop

host key + F1 to switch to tty0.

sudo xinit /usr/bin/whonix-setup-wizard

Small background:
Could work similar as whonix-initializer systemd unit:
https://github.com/Whonix/whonix-initializer/blob/master/lib/systemd/system/whonix-initializer.service
whonix-initializer runs as an “app” during first boot. Its systemd unit is configured to wait until whonix-initializer finished.

We could do something similar for whonix-setup-wizard. Before kdm/gdm/etc. would start, we could check if “whonix-setup-wizard language” has been run at least once. I.e. check for the existence of a [font=courier].done[/font] file. And if it doesn’t exist, start “whonix-setup-wizard language”. Then let the user select the language and exit normally. From there, the boot process would continue. When the desktop environment has been load, we could continue in the usual “whonix-setup-wizard setup” mode.

Most likely this requires some support from rads (Platform-specific Desktop Tips). I think this would be doable.

Only issue:
Wouldn’t work for Whonix-Qubes, because rads is ignored there. (Whonix Forum) But for Qubes, selection another language wouldn’t work without reboot anyhow. Maybe they’ll find another way (such as pre-seeding language settings from the host) or got another suggestion.

If you you find the xinit approach interesting, I would research further on the boot process integration feasibility.

troubadour · January 15, 2015, 8:38pm

Tails greeter indeed is a display manager replacement. I followed their discussions. Last time I checked, they discussed difficulties porting it to newer Gnome. I conclude this is desktop environment specific and therefore bes avoided.

There is a lot of Gnome specific code in Tails greeter, but the internationalization magic (like displaying the language names in their own character set) is coming from the icu and pycountry modules (python-pyicu and python-pycountry in Debian). That might help.

Installed xinit (it’s not installed by default in Whonix), it looks like THE solution. For the test, I just replaced the whonixcheck command at the very end with “kdm”.

We could do something similar for whonix-setup-wizard. Before kdm/gdm/etc. would start, we could check if "whonix-setup-wizard language" has been run at least once. I.e. check for the existence of a .done file. And if it doesn't exist, start "whonix-setup-wizard language". Then let the user select the language and exit normally. From there, the boot process would continue. When the desktop environment has been load, we could continue in the usual "whonix-setup-wizard setup" mode.

Yes. As an alternative, we could run the whole wizard before starting the desktop environment, and run first-use-notice and whonixcheck after it's started.

If/when we use tor-launcher, when the user selects the censored option, we set a variable or file to launch it once the environment is loaded. That’s what Tails is doing (a bit confusing, because the user has to reconfirm in tor-launcher that Tor is censored).

A bit off immediate topic, but in the Tails version of tor-launcher, the bridges name/addresse have to be entered manually. Not very handy.

Patrick · January 15, 2015, 9:01pm

I think it would be much better to keep the xinit part of whonix-setup-wizard as minimal as possible due to ugliness and limitations in that environment. I.e. only let the user choose what’s necessary there. Language. If really necessary, also keyboard layout and locale. All the other questions look so much nice in the full desktop environment. What do you think?

troubadour · January 16, 2015, 3:43am

Yes, aesthetically much better (that’s important too). Then the locale and keyboard layout parts do not have to be implemented in the wizard. From my side, programming wise, it would be actually easier to write a standard Qt dialog run by whonix-initializer service.

whonix-setup-wizard could be cleaned and polished with the last missing bits, and I could have a fresh start on a first run Whonix greeter.

Provisionally, something like this:

Whonix default installation language is English (US). You can install another language blah blah… (we could leave the “translation contributors are welcome” bit).

If the user selects other language, we enable some drop-down lists (language, country, keyboard layout) like Tails are doing.

troubadour · January 16, 2015, 3:47am

This design implies that the languages are shipped in the Whonix images.

Patrick · January 16, 2015, 4:03am

Let’s please not mix this into whonix-initializer. It’s a very different package and I will be happy to deprecate it when Debian reproducible project finished. Whatever whonix-initializer does, we can add this startup hook functionality also to other packages.

If the user selects other language, we enable some drop-down lists (language, country, keyboard layout) like Tails are doing.

Why not do it even simpler? Start with a language selection bar?

This design implies that the languages are shipped in the Whonix images.

Hard decision. But probably no other way if we want to add internationalization support.

whonix-setup-wizard could be cleaned and polished with the last missing bits, and I could have a fresh start on a first run Whonix greeter.

Hm. Wondering if we really need another package. At the moment whonix-setup-wizard has a "repository" and a "setup" mode. Why not add just another "no_desktop_environment" mode, that only asks to setup stuff we cannot setup when the desktop environment has been load?

Having it all inside whonix-setup-wizard, one (Qubes users) could also run all these components from the desktop environment. They’d just need a hint then, that reboot (or restart desktop manager) would be required.

Unless you find it easier doing it in a separate package.

troubadour · January 16, 2015, 4:37am

Yes, it would be easier to make a separate package, but it makes sense to integrate it in whonix-setup-wizard, if only for Qubes users. So, lets go that way.

troubadour · January 17, 2015, 10:45pm

A point of the situation on internationalization in whonix-setup-wizard.

Trying to make it as simple (usable) as possible.

At the moment, two combos boxes (drop-down lists):

languages as per KDE when all the languages are installed.
keyboards layouts as per KDE in Start Menu -> System Settings -> Hardware -> Input Devices -> Layouts

[If someone knows which files contains those lists, it would be really helpful].

Do we want to add the country selection, for extra settings, like time?

Patrick · January 17, 2015, 11:57pm

Fix, don’t use hard coded “kdesudo” within “.desktop” file, lintian doesn’t
like this and it’s not desktop environment agnostic. Added a wrapper to
workaround the lack of a Debian utility such as “su-to-root -X” that supports
passing command line parameters.:
https://github.com/Whonix/whonix-setup-wizard/commit/188759890b88ffb6dc679f69ac22afcc18c9002d

Patrick · January 18, 2015, 12:05am

- languages as per KDE when all the languages are installed.

*When* they are installed sounds good. Because there will be a build parameter for not installing them.

[If someone knows which files contains those lists, it would be really helpful].

Indeed! Doing it manually creating such lists seems wrong.

How does Tails obtain them?

Could you please ask someone who could know? Otherwise I could also ask arround. (unix.stackexchange.com, stackoverflow, debian-users mailing list, kde-users mailing list, intrigeri, other Debian maintainers)

Do we want to add the country selection, for extra settings, like time?

Country, probably yes. (Tails has it as well.)

Time:
https://phabricator.whonix.org/T71

troubadour · January 18, 2015, 11:39pm

Internationalization is a nightmare

Tails are hard coding the language codes in http://git.tails.boum.org/greeter/tree/default_langcodes. From there, they get the languages names from a dictionnary.

I am doing that, with the languages available from KDE. Two options (dictionaries) however:

1- icu returns the names in native characters (utf8). At the moment, some languages (Japanese, Chinese, Korean…) are not properly shown in the drop-down list (boxes).
2- pycountry languages return ascii (extended) characters.

it would be nice to have 1, knowing that if the user selects one of those languages, we’ll have to install the right interface anyhow.

The country list is taken from pycountry, which is supposed to be up to date (data taken from Debian pkg-isocodes).

Still looking for the keyboards layout codes. Have to dig in the Tails code, but the list is in /usr/share/X11/xkb/symbols/.

Patrick · January 19, 2015, 12:17am

We could also consider starting the tools that already come with kde

In KDE start menu I typed “country”. Then started that tool. Then “ps aux > a”. Closed that tool. Then “ps aux > b”. Now “diff a b”. That’s how I found out how to start that tool.

We could consider starting those tools if they wish one by one using xinit for them.

Would that be easier?

Would that be appropriate internationalization support?

Patrick · January 19, 2015, 12:19am

I mean, I was thinking a bit like “back to the drawing table”. What’s the problem we want to solve here. And I was wondering, if it’s feasible given our resources at hand to develop something more usable and bug free than what the KDE team could come up with.

Patrick · January 19, 2015, 12:23am

Or we forget about xinit. Not sure how usable that would be anyhow. whonix-setup-wizard would just start these tools for them and explain how they can start them again. And then it would assist them with rebooting (offer as option) and/or tell them that they have to reboot in order to have the language changes have any effect. If they use the assisted reboot, whonix-setup-wizard could then ask the final questions.

Would be a bit ugly, because then whonix-initializer would auto reboot at first start and whonix-setup-wizard would ask for another reboot. Not that pretty.

However, if that idea is any good, it can be refined.

troubadour · January 19, 2015, 1:10pm

No, you are absolutely right. Why reinvent the wheel when the tools are at hand? One get easily carried away while programming.

We can still use xinit, it would be too cumbersome to do it after the desktop environment is loaded.

The wizard could be:

button: Default English (US) → Start desktop (or whatever has to be done prior to that).
button: Other
- checkbox: different coutry/language → /usr/bin/kcmshell4 language
- checkbox: different keyboard → /usr/bin/kcmshell4 kcm_keyboard
- Start desktop