Hi,
anonym wrote (21 Nov 2013 05:58:37 GMT) :
> 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.
Right.
> 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).
Great.
> 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 share similar experience, but I'd like to counterbalance it with
some good experience we've had recently: the seahorse-nautilus
patchset was promptly merged upstream, and IIRC it affected
3 different components of GNOME, maintained by 2 different teams.
I also put some hope in the current mainstreaming of concerns on
privacy and tracking topics, that might ease our task a bit (e.g.
recent GNOME has a great configuration panel for privacy settings).
To end with, zack has volunteered to help in the "talk to other free
software projects" area, which could be very helpful too.
> I imagine we'll have to patch and build NM ourselves more or less
> indefinitely.
I agree we would have to be prepared to this. Note that we only
upgrade NM when we migrate Tails to a new version of Debian, so this
adds work every two years "only".
> 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.
Right.
> 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?
Neither Debian oldstable nor stable get new features anyway, so the
best we could hope (assuming the patch enters in upstream NM) for
would be to either 1. backport the new upstream release (in
wheezy-backports), which may be non-trivial (a number of other
packages will need to be rebuilt against the new NM, and backports
uploaded accordingly) or 2. backport a set of patches against the NM
that's in Wheezy, ship a patched version in Tails, and get back to the
Debian's NM once Tails is based on Jessie. I don't think #1 is worth
it, and I don't know how hard #2 would be.
In the end, I think we should first evaluate how hard it would be to
implement what we need upstream, and then discuss this again.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
