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

14/11/13 10:28, sajolida@??? wrote:
> anonym:
>> ## 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.
>
> As another consequence of lessening the danger of spoofing by
> mistake, shall we reconsider the usage of the -e option?
>
> I mean, changing only the end of the MAC address can still provides
> useful bits of information when spoofing is a strong requirement. It
> would be interesting to study how unique the first part can be, but
> I bet some are quite identifying.

Some are, indeed. But it goes both ways; if we pick the vendor-bits from
some list of "common" vendor ids (like macchiato's lists) we still may
pick an unusual vendor id for the geographical area in question.
Furthermore, I quoted "common" above because, at least from what I
gather, these lists are not well-understood by the macchiato maintainer,
who pretty much pulls any vendor ids s/he comes across. I definitely
think that the study you suggest would be great, but I fear it's a very
complex matter.

Even ignoring this, the lists are still quite short, so the gain of
using them is unclear in general, so it seems to me not trying to be
clever and just randomise the non-vendor-bits is good enough for now.

> On the other hand if we believe that spoofing is of low risk when it
> is not needed, which means that we globally lessen the important of
> AvoidSuspicion, and AvoidIdTails in favour of AvoidTracking, [...]

It's all about balancing these goals, right. In some ways AvoidTracking
is the ptime motivation for this feature, so perhaps it is more
important in some sense. Nevertheless, I think that AvoidSuspicion (or
AvoidIdMacSpoof as I call it now) isn't a problem here (see my reasoning
in my other recent answer to you in this thread) and AvoidIdTails is
solved in a better, more general way by using bridge mode + obfuscated
bridges, which I think is a separate issue (again, see my other answer
to you). Unless I'm mistaken, I think we have the best situation already.

> [...] then having an obviously fake but totally random MAC address seems
> better.

Sure, a *totally* random MAC address (which surely will fail
AvoidIdTails) could help AvoidTracking in case you have a truly uncommon
(= "more unique") vendor id on your NIC. But how can we *reasonably*
deal with this? Ideally we could ship geographical distributions of each
vendor id and try to make intelligent decisions for the user based on
this but how reasonable is that (rhetorically speaking)? Trying to be
clever about this seems highly complex for uncertain gain. I think we
just have to settle with "good enough" again ("good enough" being
randomising only the non-vendor bits).

> This topic and this threads are very heavy to process to me, so I'll
> let anonym react on that proposal, but maybe I didn't think about it
> deeply enough and it will be easy to discard. Still I wanted to raise
> the topic.

Tell me about it! Your input is invaluable for preventing this to become
a half-arsed solution.

Cheers!