Older blog entries for LaForge (starting at number 171)

Why do self-respecting hackers use Gmail & Co?

Yesterday morning I was reading through the logs of my exim-based mailserver and noticed _how_ many messages were delivered to Google/Gmail. This is mostly related to the various mailing lists that I'm hosting at lists.{gnumonks,osmocom}.org.

Now if those lists were general-purpose mailing lists for let's say a group of environmentalists or a local model train club, I wouldn't be surprised. But almost all of those lists are about very technical projects, where the only subscriber base should be people from either the IT security community, or the Free Software community. The former is typically extremely security and privacy aware, whereas the latter is at least to some extent in favor of what I would describe as 'being a producer rather than just a consumer of technology.

So why is there such a high degree of Gmail usage among those groups? I really don't get it. Let me illustrate why this is a surprise:

  • you give away control over your personal data

    Control over your own data means you own it, you have it on your hard disk, it is not on somebody else's storage medium. Control over your data also means that somebody needs a search warrant to your home in order to get to it. It also means that you decide when or how to shut it down, not a large corporation in a foreign country.

  • you put your personal data within the U.S. jurisdiction

    Depending on where you are, this may or may not be an improvement. I don't want to start a political debate here, but you have to be aware what this means specifically, especially in terms of government authorities or private companies getting access to your mails. I myself would not even say that I understand enough about the US legal system to determine the full outcome of this. Also, in case there was a subpoena or other legal action in the US, how would I defend myself? That's so much easier in my home country, where I know the laws and regulations.

  • you give Google not only the social web information who mails whom, but also the full content of that communication

    Now Google may have privacy policies and other rules that this data is not to be mined for whatever purposes they deem fit. But first of all, what guarantees do you have on it? Definitely less than if you ran your own mail server on your own hardware. Secondly, whatever Google promises is always within the scope of the US jurisdiction. In the 10-year aftermath of 9/11 there have been a number of alarming developments including wiretaps to phone lines without court review/order, etc.

Now I don't want this to be a bashing of Google. The same applies more or less to any email hosting company. I also don't want it to be a bashing about the US. The above is meant as an example only. In Europe we have our own problems with regard to data retention of e-mail related data (who is mailing whom). But those only apply to companies that offer telecommunications services. If you host your own mail server, you are not providing services to anyone else and thus are not required to retain any data.

There's also what I would call the combination effect, i.e. millions of millions of people all using the same service. This leads to a large concentration of information. Such concentrations are ideal for data mining and to get a global 'who is who'. This information is much more interesting to e.g. intelligence communities than the actual content, as it is much easier analyzed automatically. It also doesn't help to encrypt your messages, as the headers (From, To, ...) are still unencrypted.

Furthermore, this concentration leads to single points of failure. I'm not speaking physically, as Google and other web-hosters of course know how to replicate their services using a large-scale distributed system. But all is under control by the same company, maintained by the same staff, subject to the same jurisdiction/laws, etc.

There was a time when the Internet was about a heterogeneous network, de-centralized, without a single point of failure. Why are all people running to a very few number of companies? The same question goes for sites like sourceforge. All the code hosted there subject to the good will of the hosting company. Subject to their financial stability, their intentions and their admin staff. They've had security breaches, as did apparently Google. Sure, self-hosted machines also have security breaches, but only the breakage of a very small set of accounts, not the breakage of thousands, hundred thousands or millions of users simultaneously.

Now hosting your own mailserver on your own machine might be a bit too much effort in terms of money or work for some people. I understand that. But then, there are several other options:

  • You team up with some friends, people you know and trust, and you share the administrative and financial effort
  • You look out for NGOs, societies, cooperatives or other non-for-profit groups that offer email and other services to their members. At least in Germany we traditionally have many of these.
  • You use a local, small Internet service company rather than one of the big entities.
While you still give up some control with those alternatives, you keep your data within your jurisdiction, and you still keep the spirit of de-centralization rather than those large concentrated single point of failures.

Syndicated 2011-06-11 02:00:00 from Harald Welte's blog

ETSI and its ridiculous fees for old archived documents

I am currently looking for some old meeting minutes in order to understand who was the driving force behind certain features in GSM.

Ever since the GSM standardization had been handed over to 3GPP, all meeting minutes are freely accessible and downloadable for everyone. But what about the 15-20 years before that? They remain in the ETSI archive.

So from April 2011, the ETSI has started to offer an archive DVD, containing all the early CEPT and ETSI documents such as draft standards and meeting minutes. What a great idea. This DVD set is titled A Technical History of GSM Standards

But then, when you look at the price tag, you can only think "Seriously? They must be kidding!!". They are selling it for 6,000 EUR. Yes, this is not 60 EUR, not 600 but 6,000!. Go and see with your own eyes at the ETSI web-shop or this flyer.

But if that hefty price was not enough, they add an additional burden: You have to be an ETSI member to even buy it. And what is the cheapest option? Well, as an individual/small business you can join for a reduced price of EUR 3,000 per year. So in order to get access to some old meeting minutes from the 1980ies or 1990ies, I have to pay a total of EUR 9,000? They must be out of their freaking minds. Sorry, but I am simply lacking any other words how I could put it.

I think ETSI and the entire telecomms industry can be happy if anyone shows an archaeological interest into ancient specification texts at all. Scaring them away with a more than ridiculous price tag is certainly not going to encourage students or researchers to understand who, how and why GSM has ended up what it is today.

Syndicated 2011-06-07 02:00:00 from Harald Welte's blog

Looking for documentation and/or protocol traces for Motorola Horizon BTS

It seems like I'll be getting my hands on some Motorola Horizon 1 BTS soon. Of course it would be great to add OpenBSC support for yet another vendor / model.

So if anyone out there has any information on Motorola Horizon, I would be more than happy. Information includes:

  • Motorola A-bis (Mo-bis) protocol traces
  • Motorola A-bis (Mo-bis) protocol specs
  • Installation manuals
  • Configuration manuals
  • Service manuals

Thanks in advance!

Syndicated 2011-06-01 02:00:00 from Harald Welte's blog

Starting to investigate old Motorola Dimetra EBTS

Together with some friends, we have managed to get our hands on some ancient (1997) Motorola Dimetra TETRA equipment. Specifically, this includes the Base Radios (BR) and the TETRA Site Controller (TSC).

We haven't yet managed to put everything up in the wiki, but you can watch our progress at the Dimetra_EBTS page on http://tetra.osmocom.org/ as well as it's sub-pages.

It's going to be a big challenge to put all that equipment to some good use. Success is probably defined in terms of running your own small TETRA network with such an EBTS but without any of the Motorola Dimetra core network infrastructure (SwMI, basically the same thing we did for GSM with OpenBSC.

The big conceptual difference to GSM here is: In GSM, the internal protocols (A-bis, A, ...) are all publicly specified. There are vendor-specific dialects, but those are relatively easy to figure out. In TETRA, the ETSI only specified the air interface, but not the interfaces between the wired components of the network. This leaves pretty much everything else proprietary :(

Syndicated 2011-05-31 02:00:00 from Harald Welte's blog

HTC announcement about no more locked-down phones

As it has been covered at various news site, HTC has apparently announced that they will not be shipping Android phones with locked-down bootloaders.

If this is really true, it would mean that more people not only have the theoretical freedom to run modified versions of Linux (granted by GPLv2), but also the practical freedom. If there is no cryptographic restriction on only booting HTC-supplied versions of the Linux kernel (and other software), this is good news!

It comes as a bit of surprise though. "Traditionally", HTC is known for behaving unfriendly towards the community. Not only due to their source code releases being constantly too late, but also due to the fact that their phones were some of the first to use cryptographic signatures to keep people from installing their own versions of Linux (and Android).

The other surprising move has come from Motorola, who probably has the longest tradition of shipping Linux-based phones (in various degrees of GPL compliance), but then using technical means to deprive their customers of the Freedoms the GPL wants to grant to them, i.e. the freedom to run modified versions of the Software (Linux in this case). They did this with the later models of the EZX range, with their MAGX phones, as well as now with their Android phones over the last couple of years. So it was very puzzling to see the same Motorola announce a 180 degree turn in policy at least for their Xoom tablet.

Also, in recent news, Sony Ericsson made a similar announcement that at least some of their Xperia models can be bootloader unlocked.

It's really striking. During the least seven years, I used to be involved in a number of projects that tried to enable the user of mobile smartphones to have the full source code for (at least) the Linux kernel, and to be able to modify, tinker and re-program it any way they want. Now some of the vendors seem to be moving in the right direction.

What's sad is that Samsung is not capitalizing on their potential here. They have always had very timely and complete source code releases for all their Linux based phones at http://opensource.samsung.com/, and they have very rarely tried to lock any of the bootloaders. I don't know if this is intentional or not. But now the other vendors are getting good PR for stopping to do something that (to my knowledge) Samsung has not done, at least not to the extent of the others.

In any case, I still think the Nexus S is the best choice for anyone who wants to have a developer friendly device. It is fully supported in the main AOSP tree, everything in the kernel is GPLv2, and those binary userspace blobs that are required are distributed independently at https://code.google.com/android/nexus/drivers.html so they can be integrated into custom builds. This is by no means perfect, but the best compromise that seems available at this point. I still don't understand why the userspace drivers for the GSM/3G modem, Wifi, Bluetooth and GPS would need to be proprietary. Or even the NFC par, it's sort-of ridiculous to have that proprietary with Free Software RFID stacks like libnfc and librfid around...

Syndicated 2011-05-30 02:00:00 from Harald Welte's blog

Apple not providing LGPL webkit source code for latest iOS 4.3.x

As some people may know, next to a plethora of BSD licensed code, Apple is using some LGPL licensed code in their iPhone products.

So far, it seems they have always provided the respective source code in a timely manner for each and every release they have made on a website www.opensource.apple.com.

However, in recent months it seems they have deviated from that policy for unknown reasons. As my friend and webkit developer zecke has blogged, Apple has stopped to release their webkit source code with iOS release 4.3.0. The corresponding website simply states: "coming soon".

iOS 4.3.0 was released on March 10, 4.3.1 on March 25, 4.3.2 on April 14 and 4.3.3 on May 4. For all of those releases, no source code has been published.

It cannot be a simple oversight, as multiple inquiries have been made to Apple by interested developers. However, no source code until today.

I think it is time that Apple gets their act together and becomes more straight-forward with LGPL compliance. It is not acceptable to delay the source code release for 8 weeks after shipping a LGPL licensed software. Especially not, if you have already demonstrated in the past that you are well aware of the obligations and have a process and a website to release the corresponding source code under the license conditions.

Syndicated 2011-05-06 02:00:00 from Harald Welte's blog

Jounrees Logiciels Libres / ENSA Tetouan, Morocco

I've been invited to Tetouan, Morocco by the organizers of the second incarnation of the Journees Logiciels Libres. Tomorrow I'll have the pleasure of presenting about Free Software projects related to GSM, including OpenBSC and OsmocomBB.

The organizers have done a great job in caring about the foreign speakers (who include Richard Stallman and myself).

I've been listening to various talks by RMS RMS over the last 16 years or so... but right now I'm listening the first time to him giving a French presentation.

Overall, this trip has done more to improving my understanding French than anything else in a long time. I once had 4 years of French from 1st to 4th grade in school, but never really continued with it. However, what I remember, combined with my knowledge of Portuguese (and even English) is sufficient to e.g. understand all of the French language slides that have been presented at this conference. However, most spoken French is too hard to understand for me.

One striking observation is the apparently much higher percentage of women taking a communications or computer engineering degree here than what I'm used to in Germany or the so-called western world. It reminds me of India where you have the feeling that almost 50% of the IT related students are female. It would still be interesting to see some scientific research why the supposedly open and anti-discriminating, women-rights-embracing 'western world' is seeing less women taking up engineering studies...

Syndicated 2011-05-02 02:00:00 from Harald Welte's blog

PTB kann nicht nur Wahlcomputer nicht prüfen, sondern auch Spielautomaten

To my non-german-speaking blog readers: Deep apologies, this one makes more sense in German. It will remain an exception in this blog.

Eine Gruppe von namhaften öffentlich bestellten und vereidigten Sachverständigen hat ein 25-seitiges Positionspapier herausgegeben, das erläutert, wie die Untätigkeit oder Unfähigkeit der PTB (Physikalisch-Technische Bundesanstalt) dazu führt, daß die gesetzlichen Bestimmungen zur Spielsuchtbekämpfung unterlaufen werden.

Die von der PTB herausgegebenen technischen Richtlinien entsprechen nicht dem Stand der Technik. Nicht nur das, sondern es werden auch noch Sachverständige zugelassen, die sich nicht auf dem Gebiet der Informationsverarbeitung (IT/EDV) auskennen.

Das erinnert mich 1:1 an die extrem peinliche Rolle der PTB im Bereich der Wahlcomputer. Zur Erinnerung: Eine Behörde, deren Vorschriften nicht im Entferntesten geeignet sind, die komplexen informationstechnischen Systeme in adäquater Weise zu prüfen. Eine Behörde, die ihre Prüfvorschriften nicht herausrücken wollte, und deren Prüfberichte nicht veröffentlicht wurden - schließlich wiegt das Geschäftsinteresse der Hersteller schwerer als das Interesse der Bürger an transparenten Wahlen, nicht wahr? Erfreulicherweise hat uns das BVerfG bis auf weiteres von Wahlcomputern befreit, und damit auch die Frage erübrigt, ob die PTB qualifiziert ist, Regeln in diesem Gebiet zu erlassen und/oder Geräte zu prüfen.

Man sollte einfach eine Abteilung für die Prüfung der Spielgeräte beim BSI einrichten. Man kann vom BSI halten, was man will - aber man arbeitet dort einfach auf einem ganz anderem Kompetenzniveau. Man sehe sich die umfang- und detailreichen technischen Richtlinien zur De-Mail an. Da hat jemand über Nachvollziehbarkeit und Sicherheit von IT-Systemen nachgedacht, der wirklich Ahnung hat. (ganz unabhängig davon, ob das System an sich für den Bürger nützlich ist)

Die PTB mag sich ja mit der Eichung von Messgeräten und ähnlichem auskennen - zumindest als es noch um mechanische Waagen oder so geht. Der Name sagt ja schon technisch-physikalisch, nicht etwa Soft-und Hardware von Informationssystemen. Aber genau um letzteres geht es bei den Spielgeräten heutzutage: Moderne Computer, mit komplexer Hardware und Software.

Syndicated 2011-04-19 02:00:00 from Harald Welte's blog

Finally: A parseable MAPv1 ASN.1 specification

After way too much work in extracting the ASN.1 text from word documents, learning about the differences in pre-1990 ASN.1 and pre-1990 TCAP with their respective current-day counterpart, some futile attempts with the incomplete ASN.1 grammar files available for ANTLR3, I have finally dedicated the entire day to manually convert the MAPv1 from ETSI TS 09.02 3.10.0 (1994) to work with present-day TCAP and present-day ASN.1 syntax.

The result not only passes the syntax and semantic checker, but it is accepted by the Erlang asn1ct. It has not been tested/validated against any test data so far. Just in case anyone else needs a 'working' version of MAPv1 some 20 years after it was created, I have published the result here: http://cgit.osmocom.org/cgit/asn1_docextract/tree/output/3.10.0

Any bugfixes/improvements/complaints are obviously welcome.

Now I just need to figure out how to properly work with the ROS/ROSE CONTRACT class and TCAP APPLICATION-CONTEXT class to formally describe the various application contexts, their respective MAP operations and associated application context versions. It's actually quite a bit surprising that the ETSI/3GPP don't specify this formally in 29.002. The information is contained in the human-readable part of the document, but not in the formal ASN.1 notation. I wonder why...

Syndicated 2011-04-12 02:00:00 from Harald Welte's blog

Facebook "Open Compute Project" nothing but hot air

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs and simple specification data sheets. More or less every vendor is publishing that kind of information, or at least there are common form factors that are specified (like ATX, eATX, mini-ITX, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

  • Any type of electrical schematics (mainboards, power supply, ...)
  • Any type of detailed data sheets or programming manuals on the electronic components used
  • Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

Syndicated 2011-04-09 02:00:00 from Harald Welte's blog

162 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!