Bobulate
Home [ade] cookies
Privacy and metrics
November 20th, 2009
On Wednesday the Washington Post’s “Security Fix” blog had a small item on privacy issues with the smart grid. It was most interesting for me because of the graph that was included: by looking at a simple metric (power draw in the house) one could reach conclusions on what was happening inside. Breakfast, lunch and dinner can be spotted. This isn’t much of an issue if the data is available only to the power company, stored securely, and applied only to its intended purpose for which it is collected. Presumably that’s to optimize power delivery.
But when the information is used outside of that context, then bad things can happen.
This kind of concern applies to all kinds of metrics that indirectly show what is happening inside a closed box. Consider an active developer on software project where the source repository is available publicly. This applies to lots of them — and CIA.vc makes relevant stats for many even more public. By looking at time stamps you can find out roughly when the developer is active. How accurate this is depends on the style of development, but I know I’m a commit-early, commit-often guy so you can (or used to be able to) find out when I’m awake by watching commits. No commits? I must be elsewhere. Commits skewed by three hours? I must be in Brasil, hacking.
Even that information isn’t all that bad, although it’s a derived piece of information that possibly wasn’t intended to be public. But you can use it for nefarious purposes (e.g. housebreaking). Power consumption of an encryption chip was once used to determine whether it was doing a multiply cycle or an add — and knowing that revealed bits of the key being used, and so extracted the key from the chip. That’s the kind of ancillary information leakage that we can also worry about.
All in all I think it comes down to: data collection technology isn’t bad per se, but the safeguards around the collected data and the purposes to which the data is put might be. Privacy then is a matter of trust in the people that hold the data to do the right thing (regrettably humans are susceptible to temptation).
Who is the FSFE?
November 19th, 2009
The FSFE stand at FSCONS was staffed by a mix of full-time employees, interns, volunteers, Fellows, country team leads and (occasionally) anyone who would stand there for a few minutes while the rest took off for a food break. In order to show who the FSFE is, I took to drawing little portraits on the whiteboard. Now, my artistic skills are well known — I believe I’ve written of my sheer awesomeness with Kolourpaint; phrases like “skillz like a road-kill hedgehog” apply. Nonetheless, here is a little flash-card which you can use to identify FSFE people at your next conference.
An alternative to KRecipes
November 18th, 2009
Every now and then I post a recipe on this blog, and sometimes I muse about KRecipes, and there have been a few KDE events (the launch event in Mountain View, or CampKDE) where I’ve baked cookies or done other foodie-oriented activities. You can usually count on me to go looking for interesting food (there is no guinea-pig to eat in London, BTW) at events as well. But this winter season, I’m looking at something different. We are looking at something different. The “we” here is the FSFE, and we’ve decided that there’s worse things to do than cook a lovely dinner for some of our friends. So as part of our 2009 Fundraiser the executive team (comprised of at least three affirmed foodies — I’m not sure we have anyone who can function as a sommelier though) will be cooking a lovely dinner for one lucky sponsor of the FSFE.
Perhaps I’ll be able to practice this weekend with Claudia in Berlin — I seem to remember we got along pretty well cooking dinner in Paul’s appartment last year, but it’s a little hazy. Otherwise I’m left to come up with something creative to do with the rutabaga in this week’s vegetable hamper all on my own.
So watch out: Freedom Food might be coming your way.
The Science of Innovation
November 18th, 2009
A somewhat odd article that touches on patents and science crossed my desk last week in the weekend science section of my newspaper, the NRC. It’s about an experiment used to detect dark matter, the DAMA experiment undertaken under the Gran Sasso mountain. Science is largely about reproducibility, at least in the physical sciences: an experiment must be repeatable for it to have any weight as a data point. The reporting might be a little sketchy here, but it claims that the experiment is not repeatable (by researchers elsewhere) because there’s a *patent* on some parts of the original experiment and no-one can deliver the parts to another group of researchers without violating the patent license. The patent holders in this case are the research group who did the experiment in the first place.
Now, this might simply come down to a basic patent licensing dispute (which might be resolved either by granting special permission by the patent holder to another research group, or by re-using some of the original equipment, or by working around the experiment design entirely), but it’s certainly an illustration of how patents can stand in the way of even basic science questions asking “is this true?”
A Day at FSCONS
November 14th, 2009
FSCONS day one is nearly done. The FSFE track in the morning was fairly well attended. Both technical topics (like the Fellowship GPG smartcard) and legal. I’ve attended a few other talks, talked to lots of people about licensing issues, eaten scrumptious cookies (the catering is both vegetarian and excellent), and now I’m ready for a nap. After that, I have a few new software licenses to read and think about, because I’ve been asked to comment on several from a Free Software perspective. Not that I’m authoritative on that topic, but I can do the rough work.
Right, Constantly
November 14th, 2009
Markey is right. Some of his commenters are not. So I’ll illustrate, because const-correctness and const-consistency is important for cross-platform quality. In other words, getting it right means that other plaforms than Linux-with-GNU-userland-and-gcc will be able to compile KDE apps in one go.
The main thing about const-consistency is that some compilers mangle the constness of parameters into the function name. Consider the following trivial bit of code:
extern void foo(const int i);
void bar(int i) { };
I compiled this bit on FreeBSD with gcc (which is a platform that doesn’t mangle constness into the name) and Solaris with Sun Studio 12 (which does). The output from nm is like this:
In FreeBSD:
0000000000000000 T _Z3bari
U _Z3fooi
In OpenSolaris:
[22] | 0| 5|FUNC |GLOB |0 |2 |void bar(int)
[__1cDbar6Fi_v_]
[24] | 0| 0|FUNC |GLOB |0 |UNDEF |void foo(const int)
[__1cDfoo6Fki_v_]
The name mangling is clearly different — but note that the parameter of foo() and bar() is typed “i” in both cases by g++, and as “i_v_” and “ki_v_” in Studio. I used nm -C under Solaris to show the de-mangled form of the names as well as the actual symbol. If I add -C against the g++-compiled object, then it prints foo(int) and bar(int) — the constness in the function parameter has disappeared.
The effect of this is that constness does matter on some platforms, and if the interface (e.g. .h file) says “const” then the implementation must do so as well; conversely, if there’s no const in the .h, don’t add a const in the .cc as a safeguard, because it breaks on linking.
As for the stylistic issue of const on POD parameters, well, Ilet’s call that a matter of taste (and the application of the relevant coding style guidelines for the code you’re working on).
QtCreator on OpenSolaris
November 14th, 2009
At FSCONS I attended a talk by Johan Thelin — good to see someone whose blog I’ve followed for a long time, but whom I’d never met before — about QtCreator. The talk itself was a bit simple, more a “how to get the toolchain going” than a “deep secrets of Qt creator.” But because I was there I decided to update the OpenSolaris specfile for qtcreator to version 1.2.90 (the latest version for which a source download is available), and it took remarkably little effort to get it going.
Several of the patches from previous versions of the spec had been upstreamed — thanks Ossi — and only the bogus cruft patches remain like dragging in extra libraries and dealing with PTRACE.
The resulting qtcreator.bin works reasonably well — there’s an issue in detecting where Qt is installed, so I had to set that manually and the RPATH isn’t set to include lib/qtcreator/ — which means the method-autocompletion works and it does compile and run an application. I haven’t tried debugging or anything complicated, though.
This bit of Qt coding was in between my talk — on license selection and governance models in Free Software projects, where I was glad to have received useful feedback from the GNU hackers meeting yesterday — and a talk by Christina Haralanova. Just enough time to compile once, and it works.
North by North-West
November 12th, 2009
Right. Got that heading? Now turn 90 degrees to your right, because Gothenburg is that way. It’s time for FSCONS, the Free Society Conference and Nordic Summit, so off we go. I’ll be talking about licensing, best practices in governance and trying to learn about Swedish copyright law for a few days. Looking forward to it, including taking advantage of Henrik.
KDE 4.3.2 on OpenSolaris
November 11th, 2009
For those tracking KDE4 OpenSolaris, I’ve updated the pkg repository for KDE4 packages. There’s a couple of things to note:
- This build requires nv126 or later. Build 124 introduced some new incompatibilities in OpenSolaris itself, which trips up kdebase-apps builds — this has been hacked around, but we need to find a good fix that we can upstream.
- There will be no KDE 4.3.3 from the KDE4-OpenSolaris folks. We’re going to focus on 4.4.0, since there’s plenty to chase after there. Hajma has been doing a great job in tracking trunk these days, and I’ve been tagging along with 4.3.2.
- Upstreaming patches is tough. We intend to actually set up nightly builds that report to the KDE dashboard, as Alexander Neudorf has once again extended the hand of friendship to us non-Linux folks for the dashboard.
- As always, the source specfiles can be found on solaris.bionicmutton.org/hg/ and they all point to the original upstream sources.
Bitlbee FTW!
November 10th, 2009
I’m old-school. No, really. Even in this day and age of graphical desktops (and, hey, I could hot-desk X11 sessions at home with my smartcard if I really wanted to) I keep an ssh tunnel open to a friendly server, with GNU screen and irssi in there. And that’s my Instant Messaging setup. Kopete is nice (er .. usually, although I haven’t managed to get it to do anything useful in Solaris yet), but misses the always-on functionality of screen.
But irssi is an IRC client, and the FSFE uses Jabber for much of its communication. There’s #fsfeurope on Freenode, but other than that .. the Fellowship page on communications channels is a good resource. I briefly mucked about with irssi-xmpp plugin on FreeBSD, but couldn’t get any useful functionality out of it. It also seemed quite complicated to set up right.
Enter BitlBee, which bridges some other IM clients to IRC, by acting as an IRC server locally. This is one of the rare times that I’ve rushed up to one of the developers of an application and gushed “I love your app! It improves my life!” Well, I’ve met Jelmer enough times at various conferences, I think I can take liberties like that 🙂 The FreeBSD port installs flawlessly, has a few issues when running in jails and segfaults on OTR requests, but those are technicalities: the functionality and the level of guidance given by BitlBee (the in-channel help is excellent) makes it dead simple to set up and use. And as a consequence, I now have 4 IRC channels (#ebn and #kde4-solaris among them) and 3 Jabber groupchats open (including the Fellowship channel), in screen, on my server, where I can enjoy years of uptime and uninterrupted conversation.
Thanks Jelmer, Maurits and Wilmer.