[Tails-ux] Brainstorming session on the connection process

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Spencer
Data:  
Para: tails-ux
Asunto: [Tails-ux] Brainstorming session on the connection process
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