29/10/13 18:19, sajolida@??? wrote:
> On 24/10/13 16:55, anonym wrote:
>> 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.
Just to be clear, I don't believe *any* reasonable wording (which is
still easy to understand and concise) will make this any clearer than
your previous wording. It will have to be a documentation problem. Also,
the new wording removes one of the main motivations for this feature,
namely AvoidTracking. Your previous short description does this, and
warns aboud AvoidSuspicion (or AvoidIdMacSpoof as I call it now) and
AvoidConnectionProbs, which is great! It ignores AvoidIdTails, but
that's cool -- I don't see how we can explain that clearly without
giving the wrong impression. I'm not even sure we should mention it in
the docs. If we do, at least we should make it clear that bridge mode +
obfuscated bridges is the real way to achieve that user goal.
I really am very happy with your previous wording, and I doubt we can
improve it without being too verbose. With my previous comment I only
suggested that we explain (in the *docs*) the exact meaning of "hide
your geographical location", and in particular *how* your geographical
location may be logged when MAC spoofing is off.
What do you think?
>>> 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.
Ìn the threat model, my intention and wording ("Identify MAC spoofing
individuals. [...]") with AvoidSuspicion was to have it *only* deal with
suspicion related to MAC spoofing, namely for an adversary to identify
that activity. It doesn't deal with (network-related) "suspicious"
activity in general, and identifyng Tor-usage in particular. Perhaps a
better name would be AdvGoalIdMacSpoof? I updated the blueprint with
that name, and similarly I did s/AvoidSuspicion/AvoidIdMacSpoof/.
AFAICT the kind of suspicion you talk about is the suspicion inherent in
AvoidIdTails (=Tor), and IMHO it's dealt with via bridge mode *using
obfuscated bridges*. With an obfuscated bridge, our current agreement
seem to be that "if using Tor is dangerous in your country" (quoted from
our bridge mode docs) then you must use obfuscated bridges, and this
definitely is a stronger version of AvoidIdTails (=Tor) than the one in
this threat model. Without obfuscated bridges, however, we probably
should consider it very easy for the adversary to see that Tor is used,
so AvoidIdTails (=Tor) fails. Therefore bridge mode + non-obfuscated
bridges means that the user only cares about censorship circumvention,
not the stronger version of AvoidIdTails (=Tor).
So, not only are there two distinct use cases embedded in bridge mode,
but it is a separate decision from MAC spoofing. However, I admit the
distinction is hair-thin, and in practice my reasoning may be wrong. I'm
admittedly mind-fucked to only analyse everything logically due to my
current non-Tails commitments, so I definitely may be overlooking how
users *really* will deal with this at the moment.
> But if nobody else find that trick relevant, it's really no big deal.
If you're onto something I'd gladly implement it. It's just that I don't
see it yet. So if you still think I'm wrong (which, again, I very well
may be) please provide a clearly defined scenario where you think a user
would make a bad choice with the current checkbox approach, and please
also outline why you think the radio button approach you suggest would
help. Otherwise, I'm just reluctant to make the "more options" page of
T-G more complicated by introducing "blocking" behaviour like that.
>>>> ## 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.
Implemented! It's in current Tails feature/spoof-mac and experimental.
Please tell me what you think! For more info, see my recent response to
intrigeri in this topic.
Slightly OT: I think we're quickly approaching the vertical limit of how
much we can fit, due to vertical resolution constraints (we want to
support lower resolutions of course, at vertical 768, right?). For
instance, I implemented a GUI option in T-G for enabling network
blocking in addition to MAC spoofing (see feature/block-network in T-G's
Git) and with it the window is getting seriously close to the limit of a
screen with 768 in vertical resolution. I think we'll be in trouble for
Wx768 when the bride mode option finally is added.
I tried to save a few unnecessary text lines breaks by playing with the
properties of our current Gtk.Label:s (which is used for all text we
display), since they currently line-break really sub-optimally (and it
gets worse for every option we add). It turns out that it just doesn't
work -- Gtk.Label:s are unaware of its parent's size, so line-breaking
works like shit. I gave a shot with Gtk.TextView + Gtk.TextBuffer, but
the view was very different graphically so it didn't look good either.
Sorry, but I give up on this. If there's a Gtk guru out there, please
advice!
>>> 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.
Ah, now I get it. Since it's implemented now, do you think any change is
necessary? I still personally think we need a good short explanation,
and that the T-G in feature/spoof-mac and experimental has (i.e. the
previous one you suggested) is really good, IMHO.
Cheers!
