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