23/10/13 13:49, [email protected] 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! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
