04/11/13 14:49, intrigeri wrote:
> Hi,
>
> anonym wrote (24 Oct 2013 14:34:01 GMT) :
>> 19/10/13 18:53, intrigeri wrote:
>>> anonym wrote (09 Oct 2013 16:32:25 GMT) :
>>>> ## Documentation access in Tails Greeter
>> [...]
>> Welcome to Tails
>> Administrative password Show help
>> [...]
>> Windows Camouflage Show help
>> [...]
>> MAC spoofing Show help
>> [...]
>
> Looks good to me at first glance. We'll want some HCI expert to review
> all this at some point when we revamp the greeter UI anyway.
IMHO this is better than nothing, but yeah, it may change with input
from a UI expert some time later. To get something now I've implemented
this in T-G's feature/spoof-mac branch (actually in
feature/spoof-mac-help, merged into said branch). For consistency I also
added similar help links for persistence and "more options" in the first
screen, although this easily can be reverted if not desired.
(I had a couple of procrastinate opportunities for doing this last week;
other than that I've been absolutely swamped with my non-Tails
commitments until now, that's why the commits are old in comparison.)
A side-effect of this is that these links changes the "TAB-order" of
things because each link can be selected via TAB:ing (also the key
arrows can be used, apparently). I tried to make them un-TAB:able, but
even making the labels containing them doesn't affect this. I suppose
the pango-markup stuff creates object outside of our control. Oh, well...
The bad part is that users with sight impairment will need guidance from
an assistant to re-learn the login process. Of course, this is the case
whenever we add a new option in T-G too, but this time it changes the
TAB-order on the first window for the first time. IMHO that may warrant
a mention in the release notes.
As pointed out in a different part of this thread, some virtual machines
don't like MAC spoofing at all (e.g. in VirtualBox networking breaks
completely for NAT- and bridge-based adapters). Therefore I also made
T-G check if we're running in a virtual machine, and if so it changes
the default to *disable* MAC spoofing. For more info, see the blueprint,
section "MAC spoofing and virtual machine networking issues".
Furthermore, if the user checks the MAC spoofing box, a warning is
shown. The warning disappears if the box is unchecked, which is unlike
the warning shown when the admin passwords mismatch, which never removes
the warning. For greater consistency, I also made the latter warning
disappear once once changes any of the password entries, which I think
is a general improvement.
A .deb has been built and pushed it to Tails' feature/spoof-mac APT
suite, which also has been merged into experimental's APT suite. Please
let me know what you all think.
>>>> ## Connection failure detection
[...]
> Perhaps it's premature, but at some point you'll want to add this
> stuff to the relevant blueprint.
Done.
>>> * On the AdvGoalTracking and AdvGoalProfiling fronts, MAC spoofing
>>> alone is not enough (when NM persistence is enabled), unless we
>>> make sure NM doesn't use active scanning (hopefully this doesn't
>>> seriously break any usecase).
>>>
>>> After a quick look, I think that grep'ing the NM source for
>>> scan_ssid should be enough to point to the relevant pieces of
>>> code. It would be great to do this on Squeeze, Wheezy and current
>>> upstream Git, as I have empirical reasons to suspect that the
>>> behavior may have changed, and we don't want to see our nice
>>> design silently broken by the move to Wheezy.
>>>
>>> Although not strictly related to MAC spoofing, given the user
>>> goals expressed in this design, IMHO this has to be addressed in
>>> the first released iteration of this work.
>
>> Unless we plan to start NM earlier than T-G's post-login, we can skip this.
>
> I'm not convinced. Even with a spoofed MAC, NM with persistent
> connections still is subject to AdvGoalProfiling and to a more general
> version of AdvGoalTracking that can be expressed as "monitoring of an
> individual's geographical movement". Is this is fixed somehow and I've
> missed it?
Ah, I didn't connect the dots before. What you mean is that, with
persistent NM-connections, the list of ssids/bssids/whatever probed for
can be used as a fingerprint.
I haven't looked into NM's code yet, but I promise to do so soon, cause
I certainly get your point. I've at least updated the blueprint to
reflect this (see the "Active probe fingerprinting" section).
However, what do we expect here? In grand GNOME tradition, I can't
imagine this is configurable right now. Worse, even if we write patches
that make it so and send them upstream, I doubt we'll get it upstreamed
within the next couple of *years*. From past experience, following a few
feature-request *with patches* for years, these things move at glacial
speed. I imagine we'll have to patch and build NM ourselves more or less
indefinitely. And since the aim is to get this into Tails before wheezy
we'll probably have to make a backport of the patches for 0.8.1. Worse
again, I imagine that the current Debian package maintainer of NM isn't
very interested in maintaining a new patch-set for squeeze since it's
soon to be EOL'd.
My point is that that, unless I've missed something, the consequences of
implementing this may result in a relatively significant addition to our
maintenance burden (stealing precious dev time). And while I appreciate
the implications of not doing this, I think we may want to consider not
putting too much effort into this. Sending a patch upstream -- yes.
Trying to make the Debian maintainer import a backported patch for
*wheezy* builds -- if the backporting doesn't result in a complete
re-write, definitely yes (I suppose this is more likely to happen than a
quick upstreaming :)). Trying to get a backport into squeeze -- is it
really worth it?
> To end with, I notice the blueprint was not updated (modulo typos etc.
> I fixed) since almost a month. At some point, you'll want to make it
> include all the good thinking that was put into the
> recent discussions.
Done. Sorry for the non-atomic commit.
Cheers!
