Hi,
>>
>> Spencer:
>> Attached visualization
>>
>
> Lunar:
> Thanks! Happy to see you interesting in working on this. :)
>
No worries :)
>
> * “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.
>
Word. I think this is a big feature not present in Tor today (afaict).
>
> * “Work offline / Manual configuration / Automatic (or Guided?)
> configuration” is something that would be in the greeter given the
> way Tails is currently architectured.
>
Word.
>
> * “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)
>
Interesting. Dedicated screens become resource drains; linking to the
settings could be enough.
>
> * 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.
>
Word.
>
> * “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.
>
Interesting.
>
> * If there's a captive portal, the new idea here is that we present
> them with a browser *inside* the “connection wizard”.
>
Is there more information defending this function? Things inside of
things can become difficult to use.
>
> * 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.
>
Word.
>
> * 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.
>
Is this 'Work Offline'? If not, how does it differ?
>
> 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.
>
Word. I am working on some of this now.
>>
>> Though, I do not understand the "Can't change the MAC address" note;
>> will
>> you explain where it fits in the flow?
>>
>
> For some hardware/driver, Tails might not be able to set a random MAC
> address.
>
> 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.
>
This will be classified as secondary or undesired in the flow.
>>
>> 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.
>
Interesting. This kind of continues the Guided Configuration into the
desktop environment.
>>
>> 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.
>
Hopefully :)
I will work out the full start up process sometime soon (which seem to
contain the boot and connection processes).
Wordlife,
Spencer
