On 09/10/13 18:32, anonym wrote:
> All comments are welcome!
Sorry for taking so long to comment on that. I read it once a few weeks
ago but it was hard to find the time to process all that information!
> ## Conclusions
>
> The strong requirement of enabling MAC spoofing in a few cases, and
> the low risk of keeping it enabled even in the cases where it should
> be avoided, warrants for making this feature enabled by default, with
> the possibility to opt-out.
I agree with your conclusion. MAC spoofing should be enabled by default
with an option to opt-out (at least when not using bridges, see below).
> # 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
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.
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 :)
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.
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?
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.
> ### 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?
> ## 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? Being able to do this or not
might change the design of the interface quite drastically.
