23/10/13 13:49, sajolida@??? wrote:
> On 09/10/13 18:32, anonym wrote:
>> # User interface design
>>
>> ---------- Spoof all network cards' MAC addresses ----------
>>
>> This options prevents leaving traces of your geographical
>> location. Leaving this option enabled is generally not harmful but
>> may cause network connection problems. See the documentation.
>>
>> [x] Spoof all network cards' MAC addresses
>
> I tried to improve on your proposal and here is what I came up with. All
> in all it's 48 words instead of 32:
>
> Spoof all MAC addresses
> =======================
>
> This option hides the serial number of your network cards to the
> local networks. This can help you hide your geographical location.
>
> It is generally safer to spoof MAC addresses, but it might also
> raise suspicion or cause network connection problems.
> See the documentation.
>
> Spoof all MAC addresses: (x) Yes ( ) No
This wording is *much* better, thank you!
In the docs, we should make really clear what we mean with "hide your
geographical location", i.e. that it has nothing to do with your
torified traffic. I imagine the following misunderstanding: disabling
this option (to *not* hide the location) makes end-points in torified
communications know your geographical location.
> A few comments:
>
> a. I agree with calling that option "MAC spoofing" or whatever. But I
> also tried to explain what it does in simple words. Having both a geek
> name and a simple description might be a good trick to satisfy both
> audiences.
Indeed, "serial number" should give non-geeks some intuition about what
this feature is for.
> b. I added that spoofing might raise suspicion. I felt it was important
> to explain that spoofing is not a magic wand for security. More people
> might read the doc if we say that :)
Looks great!
> c. I changed "not harmful", for "safer" (beware of the buzz word!). My
> rationale for that is to provide a slightly stronger warning to people
> who might disable this too fast while trying to solve unrelated network
> problems.
Looks good. Also, avoiding negations almost always makes things clearer too.
> d. I changed the checkbox into radio buttons. The implications of this
> option is quite different if bridges or obfuscated bridges are used:
> then the user might be actively trying to AvoidSuspicion and
> AvoidIdTails and spoofing MAC might becomes dangerous if used at home,
> or at work for example. So we could remove the default setting and force
> the user to make a decision when using bridges. What do you think?
I'm not convinced. AvoidIdTails in the MAC spoofing scenario becomes
irrelevant if bridges are used. After all, we advertise bridges as a
feature for a stronger version of AvoidIdTails, so it takes over that
part of the threat model. Hence what remains is AvoidSuspicion, and it's
just as relevant with or without bridges.
So, I think we can deal with these two features independently from each
other.
> e. The current Tails Greeter interface is not a good place to explain a
> lot of things. So yes, we might stick to a very short description and a
> pointer to the documentation. But once we'll have the revamped Tails
> Greeter, and probably a bigger tab for each option, we might have space
> to explain more things. So let's keep in mind that we are designing an
> interface for this particular Greeter and contraints, and that things
> might change in the future.
Can't wait! :)
>> ### Be more specific about when to disable?
>>
>> [...]
>> After all, users that don't
>> press on "more options" won't even be aware of any issue we would
>> spell out there. If that's a problem for this case, we definitely have
>> to reconsider having MAC spoofing enabled by default option as well.
>
> In my proposal, if people enable bridges they would be forced to make a
> conscious choice for that option. We might move it to the first screen
> of the Greeter, or force them to go through the second screen. I'm not
> sure what's easier to achieve from a coding point-of-view.
>
>> ### "network connection problems" problems :)
>>
>> We may want to drop the "network connection problems" part of the
>> short summary. Although it refers to being able to establish a network
>> connection, users may confuse it with the similar problem of a captive
>> portal blocking the normal browser, or other post-connect problems.
>> The user may then wrongly disable MAC spoofing in a bad situation.
>
> Do you think my comment (c.) makes sense in this regard?
It does, but we should elaborate on this in the documentation.
>> ## Documentation access in Tails Greeter
>>
>> For this Tails Greeter option, and similar complicated options to
>> come, it would be very handy to be able to access the appropriate
>> documentation inside Tails Greeter, similar to how we do it in
>> Whisperback.
>
> Did you have time to investigate on that?
Yes, see my answer to intrigeri. Alternatively (or additionally) we may
get the "T-G option for disabling the network" feature, so users can log
in without the network, read the docs, and then restart and make an
informed choice.
> Being able to do this or not might change the design of the
> interface quite drastically.
How? I still think we need a good short explanation like the one you
provided.
Big thanks for the great feedback!
Cheers!
