Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofin…

Delete this message

Reply to this message
Autore: anonym
Data:  
To: The Tails public development discussion list
Oggetto: Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in Tails
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!