Spencer:
> Attached [0] is a visualization of this. I recreated what you all had,
> adjusting words as needed.
Thanks! Happy to see you interesting in working on this. :)
There's a couple of misunderstandings from what I see. And maybe more
things we need to add.
* “No one should know I'm using Tor” is to illustrate an use case where
users will want to do manual configuration. For example, it should
also skip asking if the system should probe for a captive portal and
have users answer the question themselves.
* “Work offline / Manual configuration / Automatic (or Guided?)
configuration” is something that would be in the greeter given the
way Tails is currently architectured.
* “Can't connect to local network”: if the error is that we can't get
an IP address or associate with the Wi-Fi, maybe we should have
a screen offering to disable MAC address spoofing. (see also below)
* There should be multiple tries to connect to the Tor network after
fixing potential issues. So we detect that time is wrong after
connecting to Tor fails. And once time is set we should try again.
Same thing after login in a captive portal, and after configuring
bridges.
* “Verify captive portal”: here we are going to ask users if they
want the system to probe for a captive portal. As this is an
operation which can trigger network alerts or be logged and later
recognized as coming from a Tails system, we don't want to do that
blindly. If users don't want the system to probe, then we should
make them able to verify themselves.
* If there's a captive portal, the new idea here is that we present
them with a browser *inside* the “connection wizard”.
* Captive portals are very different from one place to the next.
For example, in NUMA Paris, you don't even see a login screen. You
just need to connect to any website once and then it's good for
a couple of hours. In some other places, it's just “agree with
the terms and condition”. And in others there will be a
login/password. So the “Secured by passphrase” labels are wrong.
* Also, some captive portals require that a web browser window is
kept open as long as you are connected. That's why I was mentioning
a “detach” button that would take the current browser and move it to
a separate window.
I'm not entirely sure where we should ask for HTTP proxy settings.
Likely around the bridge configuration.
Maybe there's some other things that are currently missing, but this is
what I thought while looking at your drawing.
> Though, I do not understand the "Can't change the MAC address" note; will
> you explain where it fits in the flow?
The MAC address can be used to identify computers as there's a default
MAC address set in factories for each network devices. Tails can set a
different MAC address at random. See the documentation:
https://tails.boum.org/doc/first_steps/startup_options/mac_spoofing/
For some hardware/driver, Tails might not be able to set a random MAC
address. MAC address randomization is currently enabled by default and
can be disabled in the greeter. When randomization is enabled, but can't
be done, the network will be disabled entirely.
So I guess we might want a screen displaying the error. Maybe with a
“too bad, let's connect anyway” button surrounded by proper warnings.
> Also, "What do you want to do" isn't that clear to me either.
Currently, once Tor is connected and ready to be used, we only display a
small notification. I think it would be best to offer buttons to access
the web browser, the email client, the chat client, or the
documentation. Maybe with a pointer to where to open more things.
Makes sense?
> And can you clarify what the white note says, I get:
>
> - Check vs. persistent Tor state
> - Check vs. Tor monitor
I think it was written because it's not clear how the workflow could
interact with these features. intrigeri might be able to elaborate.
Hope that helps,
--
Lunar <lunar@???>
