In Germany, we do things differently. While our way of writing dates is debatable, one thing is a constant source of confusion: The decimal dot. In the US, it's a real dot–in Germany, it's a comma. You read that right. π ≈ 3.14159… for scientists, but we continue to claim that it is actually ≈ 3,14159….

Why is this a problem? Well, software sometimes expects input in the form of floating point numbers. In case your locale settings indicate that you are German, smart programs expects you to use the decimal comma, pretty please. Unfortunately, not all parts of our programs are built that smart. In some cases, we bluntly assume that you use decimal dots.

To clear that source of confusion, I added std::setlocale( LC_NUMERIC, en_US"); at the very beginning of our program. This fix worked beautifully until that fateful day where stopped. After much confusion, I found the culprit: QApplication! It turns out that QApplication likes to reset the locale settings for some reason. This is even detailed in the documentation for QCoreApplication (which I of course read after the problem had already been solved):

This can cause a conflict when using POSIX functions, for instance, when converting between data types such as floats and strings, since the notation may differ between locales. To get around this problem, call the POSIX function setlocale(LC_NUMERIC,"C") right after initializing QApplication or QCoreApplication to reset the locale that is used for number formatting to "C"-locale.

So, I heeded the wise words of the fine manual and moved the code for setting the locale after the initialization of QApplication. What a fun way to spend almost one hour.

A colleague suggested that I should search for "QApplication, what the fuck?", so these are the search terms to be used forthwith (the phrase "QApplication resets locale" might also be helpful, so I am including this here).

Posted late Thursday evening, August 1st, 2013 Tags:

I just wrote and deployed my first module for the Prosody XMPP server. Dubbed "Big Brother" for obvious reasons, the module enables Prosody to store all incoming and outgoing messages of all users of the server. See the short project description or the slightly longer README file for more information.

And don't ridicule the code too much. I am just learning Lua.

Posted Saturday night, August 3rd, 2013 Tags:

If you are using gitweb to serve your git repositories, you can add a file named README.html to the (bare) repository. gitweb will then display the contents of this file along with the tree of commits.

It is more satisfying, however, to generate the HTML file automatically. This is 2013, after all. We have the technology! I personally like Markdown as a lightweight and readable format. With the corresponding converter, you won't ever have to think about HTML again.

My current setup looks like this:

  • A git repository on a local machine somewhere
  • A file named README.md in the root directory of this repository
  • A remote bare repository on a server that is accessed by gitweb

To create the README.html file within the bare repository, I created a simple post-receive hook:

#!/bin/sh
git cat-file blob HEAD:README.md | markdown > $GIT_DIR/README.html

Place this hook in the hooks subdirectory under the name post-receive and make it executable. After the chunks for each commit have been received, the hook will look for the file README.md on the master branch of the repository and generate the corresponding HTML file from it. The best part of this is that the file is getting updated along with the program and you never have to worry about re-generating the documentation.

Posted Saturday night, August 3rd, 2013 Tags:

Security-wise, the last few weeks have been interesting, to put it mildly. After much idle assertions about how our intelligence services have never acted outside the law (pinky promise, I swear!), finally something good has happened: GMX, T-Online, and WEB.DE introduced E-Mail made in Germany, a new initiative with "high standards for security and privacy". With these players on board, we can finally show those bad Americans how E-Mail is done! German efficiency and all that stuff...

Unfortunately, this initiative is a farce. These companies really try to hoodwink their prospective customers. Big time. Let me explain why this sort of advertising makes me angry.

What is wrong with the advertisement?

First of all, they advertise the fact that their servers understand SSL encryption. Well, it's 2013, so any mail server that comes even close to deserving that name offers SSL encryption. If the server of your provider doesn't, you should really think hard about doing any further business with them. Besides, it seems like what they are really talking about is STARTTLS, meaning that your insecure connection can now be encrypted to a secure one. Great–what year was it again? 2002?

Second, they talk about how the transmission between servers is encrypted, but only if you use their servers. Their advertisement even has the gall to belittle other e-mail providers. Money quote (loosely translated): "Sending e-mails to other providers such as Google, Yahoo, or Microsoft, is of course still possible. However, for these providers, neither secure transmission nor (exclusive) data processing in Germany can be guaranteed". To me, this sounds slightly threatening: "What a nice INBOX. It would be a terrible shame if something were to happen to it". Cue the images of the standard German villains from movies (you know which ones I am thinking about).

Third, data processing is apparently exclusively done in Germany, using "secure data centres" and the "high standards of German privacy laws". I couldn't care less. While our courts have already established some sort of "basic human right to privacy", our security agencies still don't give a fig. Let me just drop the keyword Bundestrojaner (literally: federal trojan) here.

Fourth, and last, they try to use E-Mail made in Germany to pave the way for De-Mail. De-Mail is the idea of offering a new e-mail service to send legally-binding e-mails. While this may sound like a good idea, the actual implementation suffers from essentially the same.

What is wrong with E-Mail made in Germany and De-Mail?

In short, it does not offer end-to-end encryption. This means that while the connection from your device to the server is encrypted, the data is still stored in plain text. Even if data is encrypted when being transmitted between different providers, it still is stored in plain text somewhere. Let me reiterate: The data is stored in plain text. In plain text. Somewhere.

This implies that any malevolent individual or organization simply needs to obtain access to one of the servers to obtain all sorts of communications data. The fact that there is an encrypted connection between your device and the server simply ensures that the customers of the Starbucks you are sipping your latte in cannot easily see what you are sending. Other than that, the encryption is worthless.

For De-Mail, it gets even worse: Since your e-mail is legally binding, you might have a hard time to prove that an attacker modified an e-mail or sent it without your involvement.

Isn't this all very academical?

No. E-mails have been forged and read by unauthorized persons. Disgruntled ex-employees, employees with voyeuristic tendencies, and so on. I don't say that this is going to happen to you with a very high probability. But it still might. The possibility is not that far-fetched.

Are there any solutions?

Plenty! S/MIME and GPG (PGP) are two standards that can be used to obtain end-to-end encryption between two parties. Both systems could also be made legally binding, if any government desired to do so. It really is just a matter of identifying a person (which is what a government should be good at) and certifying it. I mean this both figuratively and literally. For S/MIME, each participant requires a certificate. For GPG, each participant creates a private key that is signed off by other participants to ensure a valid identity.

Both standards would be viable alternatives, yet almost no one uses them. Neither do governments endorse them to make e-mail legally binding. To make a wild guess, I think this is related to the fact that most people still think that any form of encrypted communication necessarily implies that both participants are criminals. If you are one of these people, convincing you is beyond the scope of this rant and almost certainly beyond the scope of my argumentative powers.

Do you have some sources?

Upon re-reading this article, I see that I made some outlandish statements here, regarding the possibilities of privacy violations for ordinary citizens. Here's a list of cases where e-mail privacy has been violated:

These are some articles that pertain to e-mail access specifically. There are others about (illegal) surveillance and abused privacy.

To end on a happy note…

I do not mean to sow despair, but rather to inform on shallow double standards and false advertising. If you use e-mail and do not wish to encrypt it, simply treat it more like a postcard. Do not talk about things that you consider too private. The same goes for chats on social networks, for example.

I mean to write about simple tools for encrypting your data some time soon. In the meantime, you may want to take a look at these great articles:

Posted at lunch time on Sunday, August 11th, 2013 Tags: