On 24/10/13 16:55, anonym wrote:
>> 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!
Thanks.
> 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.
Oh yes. I didn't question the phrasing "hide your geographical location"
but it is ambiguous indeed.
What about removing it :)
This option hides the serial number of your network cards to the
local networks. It is generally safer to spoof MAC addresses, but
it might also raise suspicion or cause network connection problems.
See the documentation.
>> 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.
The thing is that if you want to AvoidSuspicion to a decent level you
*have to* use bridges (and you probably know that already, otherwise
you're screwed anyway) and in some cases you might also *have to* use
your real MAC (and you might not know that) - quoting the example from
your RFC: « security guards are sent to investigate an "alien computer"
at your workplace, or similar ».
That why I considered there was an increased probably of danger for
spoofing MAC when we already know someone wants to use bridges. Then I
thought a trick could be to disable the default settings and force the
user to make a conscious decision.
But if nobody else find that trick relevant, it's really no big deal.
>>> ### "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.
Agreed.
>>> ## 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.
Good news.
>> 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.
Well, if we couldn't do that we would have to provide a "no network"
mode from that interface.
