Enabling jabber in WebOS on the Palm Pre using a binary patch

One of my main complaints about the palm Pre is that there is no support for the major IM protocol's such as jabber, icq, aim, msn, ...

As I discovered, they're actually using a library (libpurple) that supports all those protocols. It's just the UI and the intermediate LibpurpleAdapter program which artificially restrict the features that this library offers.

So it sounds to me like palm is getting money or other favors from Google to artificially restrict the capabilities of the Webos messenger.

As I have described in this mail to the webos-internals mailing list, you can actually use a very simple one-byte binary patch to LibpurpleAdapter to enable jabber support.

After that binary patch, you can add jabber contacts with the regular user@jabber-server.doma.in address and use the regular messenger application for keeping in touch with your jabber contacts. Just like how it is supposed to be.

Legal notice: Making this binary patch is legal, since LibpurpleAdapter is actually released under LGPL. If you have a working build environment for the Pre with all the libpurple headers, you can of course modify the source code and recompile it (as explained in the mail).

Side note: The libpurple-adapter source code that Palm has published on opensource.palm.com does not correspond to the actual binary code. This is a LGPL violation. However, since palm is the copyright holder, nobody can really do anything about it. But it once again shows that the software build/release process does not automatically generate the source code packages and that there is an erroneous manual process involved :(

India prohibits import of GSM handsets without IMEI

As has been reported at telecomtiger.com, the Commerce Ministry of India has banned the import of mobile phones with no IMEI.

This is somewhat funny, as the IMEI is stored in flash memory in all the phones that I have seen in recent years. Tools to erase or change the IMEI can be found for many popular phones, including (but not limited) to the many MTK based inexpensive phones from China.

So sure, you can now no longer import a device legally with no IMEI, but well, any self-respecting organized criminal will find a way to erase or alter the IMEI anyway ;)

Implementing the GPRS protocol stack for OpenBSC

During the last week or so, I've been spending way too much time implementing the network-side GPRS protocol stack as part of an effort to not only provide GSM voice + SMS but also GPRS+EDGE data services with OpenBSC

GPRS is fundamentally very different from the classic circuit-switched domain of voice calls and CSD (circuit switched data). Not only conceptually and on the protocol level, but also in the actual system architecture. They way it was added on top of the existing GSM spec is by making no modification to the BSC and MSC, and only the minimal necessary modifications to the BTS. They then added a new Gb interface to the BTS, and the SGSN and GGSN core network components, who in turn talk to HLR/VLR/AUC.

So in the most primitive GPRS network, you can have the GSM and GRPS domains completely independent, only using the same databases for subscriber records and authentication keys. This goes to the extreme end that your phone would actually independently register with the GSM network (ISMI ATTACH / LOCATION UPDATING) and to the GPRS network (GPRS ATTACH / ROUTING AREA UPDATE). While both of the requests get sent to the same BTS, the BTS will send the GSM part to the BSC (and successively MSC), and the GPRS part to the SGSN.

Also, the actual software architecture looks completely different. In the GSM circuit-switched domain you always have a dedicated channel when you talk to a phone. The number of dedicated channels is limited by the transceiver capacity and the channel configuration. In OpenBSC I chose to simply attach a lot of state to the data structure representing such a dedicated channel. In the packet-switched domain this obviously no longer works. Many phones can and will use the same on-air timeslot and there is no fixed limit on how many phones can share a radio resource.

What's further important to note: The protocol stack is very deep. If you look at the GPRS related output on an ip.access nanoBTS while your mobile phone makes a HTTP request, the stack is something like HTTP-TCP-IP-PPP-SNDCP-LLC-BSSGP-NS-UDP-IP-Ethernet, while the first HTTP-TCP-IP-PPP is obvious, I would not have expected that many layers on the underlying network. Especailly if you look at the almost zero functionality that NS (GSM TS 08.16) seems to add to this stack. Also, the headers within the protocol can actually be quite big. If we only count the number of bytes between the two IP layers in this stack: 8 bytes UDP, 4 bytes NS, 20 bytes BSSGP, 6 bytes LLC and 4 byte SNDCP. That's a total of 42 extra bytes. And that for every small packet like TCP SYN, SYN/ACK or the like! No wonder that mobile data plans have been prohibitively expensive all those years ;)

So with regard to the actual GPRS implementation in OpenBSC, the following things had (or still have) to be done

• Add support for generating System Information 3 + 4 rest octets and System Information 13

This is a very time-consuming bit-fucking experience, encoded relative to the padding pattern of 0x2b. Without this, the phones would not realize that the cell actually supports GPRS. DONE.

• Add support for the ip.access extensions to the A-bis OML (TS 12.21) layer

This is needed to configure the GPRS parameters such as channel configuration, coding schemes or the IP and NS/BSSGP parameters for the link to the SGSN (OpenBSC). Without it, the BTS would not even start to speak NS/BSSGP, i.e. not connect to OpenBSC for GPRS services. DONE.

• Implement the NS protocol (GSM TS 08.16)

Turns out this was really simple, as NS doesn't really do much anyway. DONE.

• Implement the BSSGP protocol (GSM TS 08.18)

This protocol is - among other things - responsible for the flow control. Both globally for the BTS as well as individually for each MS. I've implemented the basic functionality to be able to send/receive signalling and user data, but no flow control yet.

• Implement the LLC protocol (GSM TS 04.64)

This is actually the protocol that is terminated between the MS and the SGSN, so we have moved beyond the BTS level here. Actual data from/to the mobile phone. I've implemented a minimal subset of it, including the CRC24 checksumming. I'm not taking care of packet loss, retransmissions or fragmentation yet. Just simple S, UI or U frames.

• Implement the GPRS mobility management (GSM TS 04.08)

This is pretty much work in progress, but GPRS ATTACH and ROUTING AREA UPDATE is already handled. More work needed here, especially with regard to persistent storage of P-TMSI allocations as well as the last-seen position of every MS in a database.

• Implement the GPRS session management (GSM TS 04.08)

This is the messages for activating and de-activating PDP contexts. Work has not started yet.

• Implement GGSN functionality (PPP tunnel endpoints

After all, we need to terminate the PPP sessions that the phones establish somewhere. Work has not started yet

Once all that full stack has reached a level where it works to a minimal extent, issues like BSSGP flow-control as well as LLC re-transmission, fragmentation and [selective] acknowledgement have to be dealt with.

Finally, if somebody is bored enough, he could also work on things like combined GSM/GPRS attach, or SMS over GPRS.

As you can see, it's quite a large task. But we need to start somewhere, and a lot of this will still be needed when moving into the 3G and 3.5G domain. Even if not at the lower level protocols, but from the software architecture point.

If you're into communications protocol development and don't mind our ascetic 'plain old C language' approach and are interested to contribute, feel free to introduce yourself on the OpenBSC mailing list.

A common misconception: GPRS encryption differs from GSM encryption

In the last couple of months, I've met numerous people with varying background all sharing one misconception about cellular networks. Even I was not very clear on this until recently: GPRS encryption is very different from GSM encryption. Most people know it uses different algorithms, sure. But it also operates on a completely different layer in the protocol, and is between two different entities.

Encryption in GSM networks happens on the Layer 1 of the Um interface between the MS and the BTS. It is a simple point-to-point encryption of only one particular network interface. There is no more encryption as soon as the signalling, voice and SMS data leaves the BTS (on a microwave link or actual land line) to the BSC, MSC, SMSC and other network elements.

In GPRS, the encryption is not on the Layer 1, but on the Layer 2 (LLC) of the Um interface. As the LLC layer is not terminated at the BTS but at the SGSN, the data is still encrypted when it leaves the BTS.

This means, among other things, that things like eavesdropping on unencrypted microwave links does not work for GPRS anymore.

German constitutional court hearing on data retention

On December 15, there will be a court hearing by the German Constitutional Court (Bundesverfassungsgericht) on the law on data retention which was enacted in 2007 and has been valid since January 1st, 2008.

This law requires any communications network operator to keep digital records of every voice call and e-mail, including sender and all recipient addresses.

This law was required by the European Union Directive 2006/24/EG, one of those paranoid reactions against the perceived threat of terrorism. Laws implementing this directive in the EU members Romania and Bulgaria have already been invalidated by their respective constitutional court.

In Germany, more than 34,000 (I'm not kidding) people have filed a constitutional complaints against this law. This is the first time that such a significant number of individual citizens has ever made constitutional complaint. Only the documents about power of attorney have filled 12 large boxes, each with many folders. As you could probably guess by now, I'm one of those plaintiffs.

As an interim solution, the constitutional court has already decided on March 19, 2008 that such data can only be used under special circumstances, such as only certain criminal offenses, and only if there is already a very strong initial suspicion, and if there is close to no other way to prove or deny the allegations brought forward by the prosecutor.

I hope the court hearing on December 15 will bring the court closer to actually ruling on this case. This has been dragging on for a long time now.

Just like when the constitutional court had a hearing on voting computers, I am planning to be in the audience and want to see live what the constitutional court does with regard to matters that I strongly care about. I hope my registration will make it in time... given the number of plaintiffs I suppose there will be many more people interested in attending the hearing than they have space. Which raises another interesting issue: I suppose if you are an actual plaintiff, it would be weird if a court refuses you to be at the actual hearing. But which court would hold > 34.000 plaintiffs? ;)

Qualcomm launches Open Source subsidiary

As several news sites have been reporting (here a report from LinuxDevices.com), Qualcomm has announced the launch of an Open Source Subsidiary.

As usual, I very much welcome such a move. Qualcomm is one of those companies who have a very bad reputation in the Open Source and particularly Linux community. They have so far failed to provide user manuals or other reference documentation for any of their parts. They haven't even managed to publish reference documentation on the external interfaces such as the AT command dialect or the binary shared memory protocols that are used to interface the GSM/CDMA/WCDMA baseband in their product.

So when it comes to an Open Source project that wants to interoperate with Qualcomms hardware, they have so far been doing everything to make that as hard as possible. Neither the community as large has access to the information that it needs, nor do the Qualcomm customers get the respective document under a license that allows them to actually contribute to Open Source projects.

If that documentation was available, or if Qualcomm was actually working on FOSS licensed drivers and contributing those mainline, the support for Qualcomm's hardware in Linux would be much better - resulting in less time to market for companies interested in using Qualcomms parts in their products.

The actual press release does not indicate that this newly-founded subsidiary truly understands this. It speaks of hardware-optimizing the performance of mobile operating systems. That sounds like "we'll take the existing code, make a fork, do non-portable micro-optimizations and ship that to our customers". It does not mention actually contributing to the community or understanding the benefit that the Open Source development model.

I remain to be convinced. Let's hope Qualcomm has scored somebody with a lot of actual hands-on Open Source community experience to advise them properly.

Palm Pre: Nice UI, severe lack of functionality
Using the Palm Pre: Everything but an exciting experience :(

During the last week I've started to use my new Palm Pre (for those of you who're living under a rock: The Palm Pre is a smartphone powered by an Operating System called WebOS, which is in turn powered by the Linux kernel and lots of other "standard" Linux programs like glibc, alsa, udev, ...

This adherence to a more standard Linux userland makes the Pre much more attractive than the Android based products out there. Android is reinventing the wheel everywhere, and things that Linux users and developers have been taking for granted during the last five to ten years simply don't exist on Android.

To be honest, the experience was everything but exciting. More about that later. Lets' start with the positive side of things. Yes, I like the device for the following facts:

• it's using a not-too-ancient Linux kernel
• it uses a fairly standard Linux userland, that
• the development tools are also running on Linux (albeit proprietary)
• there is an easy way to access the command line of the device via USB
• there is software for re-flashing the phone in case it is bricked
• the WebOS "distribution" is built using OE and uses the ipk packet format
• they did not try to lock the device down from their users. You can easily be root on your phone, install additional ipks from third parties and own your phone

Which is what got me excited and made me buy one of those expensive devices.

However, looking at it from a strict user point of view, I am not very happy with it. It simply lacks so much in functionality that it is not even funny.

• No RSS reader

The Nokia web tablets had a working, built-in RSS reader even many years ago when the n770 was released. Given the importance of RSS feeds and blogs in todays web, I'm surprised that webOS does not ship with a RSS reader. To make it even worse, I could not find any third-party RSS reader for it!

• No Jabber / ICQ / AIM support

The messenger supports only SMS and Google Talk. WTF?!? What about the millions of Jabber, ICQ, YIM, MSN and other users? Don't you think they want to use their default messenger application with those accounts? This is particularly funny, since they're using libpurple for the actual messenger protocols, which is a LGPL'd library of the pidgin chat client. So the library has all those capabilities, but Palm decided to arbitrarily remove them in their LibpurpleAdapter program. Luckily that one is LGPL'd too, so removing the restriction is relatively easy. But not for a regular user!

• Some applications always want to use the cellular network, even when wifi is available

This is particularly stupid when using their e-mail client. While I'm at home or in some other area with wifi coverage, I don't want to squeeze every bit through a high-latency cellular network. Why not simply make that decision a per-application property that the user can set?

• Cheap mechanical quality

The mechanical quality is really disappointing for a device that sells for EUR 481. It's much lower than what one is used to from Nokia, Blackberry or HTC devices in a similar price range. As one example, the entire plastic of the device squeaks every time I carefully push one of the keys on the keyboard.

• E-Mail client does not support pre-downloaded messages in subscribed IMAP folders

A standard feature that every desktop e-mail program has: Pre-download and cache the message headers for fast listing / browsing through a mailbox. Not on the Palm Pre, where the interactivity of the mail program is close to zero, fetching every bit over a high-latency link. The entire point of using IMAP is to have local copies/caches and to not suffer the latency/interactivity penalty of e.g. webmail!

• Calendar offers no integration with standard calendar formats/servers

There is no way how you can simply feed data from ical or xcal calender data into the Palm Pre calendar. You can synchronize with Google and Exchange. WTF? Why do we have [more or less] standard file formats for calendar data? Exactly for enabling interoperability.

• No support for standards-compliant address books

You can import your contacts from Facebook, but you cannot import contacts from vcard files, or let's say from a LDAP based address book. Great. So I first need to disclose all the personal contact details from all my contacts, put those into Facebook (into the US jurisdiction and a company that I don't trust) to simply get my contacts on the phone ?!?

• Too low battery life

I can barely make it through one day even without making phone calls, simply having the e-mail client running. The battery is too small. I would not mind a bigger/heavier device in exchange for more power!

That is simply the user point of view. I also have many more technical points from a developer perspective, but that is probably better kept for another post. Meanwhile I'm not sure if the Pre was all that much of a good idea. The N900 is coming up next, and will be much closer to the standard Linux userland stack (including X11, GTK, Qt, ...) than the Palm Pre is.

Symbian kernel Open Source release and Tanenbaum

As most people have noticed by now, The Symbian Foundation has released the source code of their microcernel under an open source license. While any open source release of formerly proprietary software is something I warmly welcome, I doubt that it will take of as an actual open source project.

There's a difference between releasing software under a FOSS license and running a successful FOSS project. The latter involves a sufficiently large community of developers, ways how they can contribute, ...

Especially with special purpose code such as an operating system (kernel) for mobile devices, very few people will show interest as long as there is no actual hardware where they can run the software, without or with custom modifications. Sure, there will be academic interest and people who will look at the source code to find ways to exploit potentially existing security weaknesses, but no community of people who work on it since they will practically use it on their own device.

So what I'd do if I was the Symbian Foundation: I would release an actual mobile phone which is open enough for people to run (modified or unmodified) recompiled parts of the Symbian codebase which are now available as open source. This way it will be much more appealing. However, even at that point, many other parts of the system are (or even will forever be?) closed, limiting the amount of impact. Furthermore, since modified versions cannot be installed on any other regular non-developer phones, the impact of any contribution to the codebase can not be to the benefit of many people. Just compare that with contributing to the mainline Linux kernel, where a contribution will be used on at least almost every server/workstation/laptop after the next distribution (and thus kernel) update.

Another issue that I really was shocked is the following quote by Andrew S. Tanenbaum: 'I would like to congratulate Symbian for not only making the source code of its kernel open source, but also the compiler and simulation environment,' said Andrew S. Tanenbaum'

However, the compiler was not made open source. It is released as proprietary binary code, and is only "free as in beer" for organizations up to 20 employees. So either Tanenbaum did not really look at the hard facts of what was being released, or he was misquoted in a really bad way! That should not have made it into the final release, as it's now a damaging statement for both the Symbian Foundation and Mr. Tanenbaum.

By the way, according to a lwn.net comment thread, they're working on making it able to compile under gcc, and they're actually accepting patches, which is of course great.

Despite my negative comments: I wish them as much luck and success as possible with their new open source Symbian kernel. I personally just am not seeing it turning into a vibrant, community-maintained project - and I hope the founders of the Symbian Foundation did not start the project based on that assumption and will in the end perceive it as a negative experience when evaluating the open source move some years down the road.

One final note: The fact that they chose the EPL as license is really strange, as it prevents exchange of code with the major existing FOSS kernel projects (Linux, *BSD). Not that I think there is much to be exchanged, given the microkernel approach...

FOSS.in CfP running for quite some time

In case you have been sleeping throughout last week: On October 16, The FOSS.in Call for Participation had been released.

FOSS.in is one of my regular conferences, and probably the only event aside from the Chaos Communication Congress that I managed to visit in five consecutive years. I'm looking forward for this year's incarnation, and I'll definitely do my part to make the event more interesting :)

I hope everyone will now hurry to submit their proposals for talks, workshops and work-outs! It's a collaborative event, and it lives by your contribution.

Differential Power Analysis on mobile phone?

cnet.com reports some researchers succeeding in performing a differential power analysis (DPA) on a mobile phone in order to "steal cryptographic keys that are used to encrypt communications and authenticate users on mobile devices".

This sounds fishy. At least on GSM phones, the keys for authentication are stored inside the SIM card. And somebody claiming that within a mobile phone with it's many analog RF and digital circuits (causing interference and noise) he can still perform a DPA on the SIM card just simply sounds unreasonable.

I would like to see those results being fully disclosed and independently reproduced before giving them much credibility.

The current encryption session key is not used for authentication, it is very short lived (typically 1 to 5 calls before a new key is negotiated), and it is not considered very safe anyway. The phone writes it to the SIM card, and malware programs installed on the phone are likely to get access to that key anyway. So no need for a DPA here...

Letter to the European Commission opposing Oracle's acquisition of MySQL

As can be found here, Knowledge Ecology International, the Open Rights Group and Richard Stallman have issued a joint letter to the European Commission asking it to disapprove the acquisition of MySQL by Oracle.

I very much welcome this move. There clearly is a conflict of interest between Oracle's own proprietary database software offerings and MySQL. Sure, the community could always fork MySQL, but at what cost? Potential disputes about the trademark, being forced to rename itself, and confusion among the millions of users world wide (well, might just be hundreds of thousands).

Palm Pre GSM model source code available

Last night I got an e-mail by palm, that following-up to my request, the source code releases for the WebOS 1.1.2 and 1.1.3 releases have been uploaded to opensource.palm.com.

I think the response time was very quick, and I thank them for that. However, still sad that one has to remind them of it. Let's hope with future releases they have a fully automatic process for that.

Just to be very clear: The GPL does not state that you have to automatically have the source code on a web site. But the way how Palm's written offer is phrased, they say that you should visit the website to download the sources. In that case, the web site of course needs to contain the sources...

Additionally they also offer the source code on a storage medium, if you write them snail mail to a specific address - which is a good safeguard since the GPL says it has to be made available on a storage medium commonly used for software interchange.

TI tries to stop alternative operating systems on its calculators by the DMCA

Apparently, TI has been trying to use the DMCA and U.S. copyright to stop third-party developers from working on or distributing alternative operating systems for some of their calculators.

The stock OS that TI is shipping uses a cryptographic signature process to prevent the user from booting any non-TI operating system. However, the signature verification was broken and people have managed to run their own software, developed independent from TI's software.

TI is not claiming that the DMCA DRM restrictions are applicable to this case, and that the signature process constitutes a DRM system. This is obviously bogus to any technical person. The TI firmware is not encrypted, and you can copy and run it on other hardware or an emulator if you please. The protection mechanism is rather the other way around: The hardware authenticates the OS.

The Electronic Frontier Foundation has taken up the case and is defending some of the affected people from the community against TI.

As you can see from the EFF letter to TI, the EFF cites a number of precedent cases where the courts have ruled in very similar cases that such mechanism is not a DRM system on the software.

That precedent summarized in the EFF letter is actually very exciting to me. It is directly applicable to all kinds of locked-down devices. Let's assume we're talking about a Linux-powered device like the Tivo, Motorola MAGX phones, the G1 phone (non ADP-Version). They all use GPL Licensed software that is cryptographically signed to prevent the user from exercising his Freedom to run modified versions of the GPL licensed program.

Precedent that indicates that such a system does not constitute DRM as protected by the DMCA means there is a lot more freedom for people to break such systems and freely talk about how it was performed, as well as distribute alternate software images for the respective devices - as long as the code they use is either their own or Free Software and does not contain proprietary bits of the device vendor.

ST-Ericsson Community Workshop 2009

Today, I had the honor to hold the opening keynote of the ST Ericsson Community Workshop 2009.

At this event, ST-Ericsson presented their Nomadik STn8815 SoC, as well as their work on getting the u-boot and kernel ports submitted back into the upstream/mainline projects.

As anyone following the linux-arm-kernel list will have noticed: For the last months, they have worked hard on cleaning up and submitting the code for this SoC. Like many people in the community, I personally appreciate this very much. Finally, ARM SoC vendors actively putting resources to become a "first class" member of the community.

The STn8815 is a ARM926EJ-S core based SoC, including a ST DSP for video codec acceleration as well as a number of standard peripherals such as I2C, SPI, UART, SDIO, etc.

The STn8815 reference software that they released today, includes 100% open source drivers for everything that runs within Linux, inside Linux or on top of Linux on the application processor. The codec implementations inside the DSP are closed source / proprietary. However, the infrastructure to communicate with the DSP, as well as the gstreamer/ffmpeg integration on the Linux side is fully open source.

The attendees of the workshop are receiving the NHK-15 reference boards, which have the STn8815 SoC plus a total of 384MByte NAND flash and 128MByte of DDR memory. There's also a number of peripherals that you expect in such a product, including LCM, SD card slot, Bluetooth, Audio Codec, and Wifi.

Unfortunately, the Wifi driver is closed source. However, the Wifi is a dedicated peripheral component. The use/choice of this Wifi chip on the NHK-15 is probably a bad design choice from an open source point of view. But: This proprietary Wifi does not affect the openness of the actual STn8815 SoC.

Included with the kit for the attendees also a full programming manual as well as register-level specification for the STn8815, as well as the complete schematics of the development board. No NDA required :)

As a summary: I welcome ST-Ericsson to join the Linux community and to provide Open Source friendly solutions, provide the documentation and holding this workshop. However, the STn8815 is already quite 'old' hardware, as it is still ARM9 based - while much of the competition is shipping ARM11 or Cortex-A8 today. Let's hope at some point in the future we will have more competitive hardware with just as much openness.

The txtr e-book reader hardware architecture released

Today, the Berlin-baased start-up txtr has released more technical details on their first e-book reader.

They have also released their developer website including a wiki and access to a svn server with sources as well as fedora11 based source and binary RPM's.

What's also interesting is that they have disclosed a hardware block diagram and a PCB footprint on their developer website before the product even starts shipping to the mass market.

As few of you will know, some my friends and colleagues are behind the system-level software and hardware R&D. The electrical engineering is done by Milosch and Brita of bitmanufaktur, with whom I've had the pleasure to work on OpenOCD, OpenPICC, OpenBeacon as well as for a dedicated assignment inside Openmoko. Andy Green of Openmoko kernel + bootloader hacking fame has also been involved... last but not least for porting Qi (originally developed for the never manufactured Openmoko GTA03 based on the Samsung S3C6410) to the Freescale i.MX31.

Palm Pre privacy invasion

One great example of why we need more open source based mobile phones is that we can actually discover all the undocumented "features" of the devices that we use every day.

If I use a device for personal things like my private communication, my scheduling, contact information and similar, then I have to put a certain amount of trust into that device. I trust that the vendor selling this device will provide a device that is safe for me to use and where my information is stored securely.

However, the amount of closedness and control that equipment vendors and GSM operators traditionally have in the mobile world is a big conflict with my personal interest for privacy and security.

You can see this reflected by SIM Toolkit specifications that allow the operator to read and modify your phonebook, or with flash over the air where the operator is able to modify the software on your device.

In fact, in such cases the operators treat the device like they own the device, when in fact the customer has bought the device and owns it.

Since Palm's WebOS is [to a large extend] based on Free / Open Source software, we can analyze in more detail what they are doing. As it was pointed out in this blog post two months ago, they seem to regularly receive information when you were using which application, as well as the GPS coordinates of the phone!

This is outrageous, especially without any way for the user to switch it off - or even better: Have an opt-in, i.e. off by default but who wants it can enable it.

Palm has responded to it, but as that very same posting indicates: The Palm Privacy Policy is not even completely listing the information for which it is applicable.

I don't think Palm is particularly worse than other companies. But the question is: How do we know? How does the user know what his phone wants to communicate to the operator or the manufacturer without his knowledge or authorization? The only two ways I can imagine are:

• by having more open source software on the phone, so users can study the code, determine what it is doing and then modify the software to remove such privacy invading surveillance features
• by having more people with their own GSM/GPRS networks with projects like OpenBSC, where we can actually see from the network side what the phone is trying to do. Unfortunately GPRS support is still not finished in OpenBSC, but work is ongoing.

Since the Palm Pre units so far (CDMA and GSM) are not locked down, i.e. you can become root and modify the software, it will be much easier to have "custom ROMs" (where the name ROM is stupid since it is flash, ...)

I can only hope that people will quickly come up with custom Linux based firmware images for the Palm excluding the surveillance features.

In addition, everyone should write a letter to Palm, complaining about those features and the fact there is no way to opt out of them.

Palm Pre GSM Version sells in Germany - No corresponding source code

Some 4 months ago, I wrote about Palm shipping the Palm Pre CDMA version in a GPL incompliant way. You should assume that the company has learned about their mistakes and created opensource.palm.com as a site to host their source code, compliant with the GPL and other Free Software licenses

Yesterday, the Palm Pre GSM model started to ship in Germany through O2 Telefonica. The WebOS version installed on the device is 1.1.2, and they are doing an OTA upgrade to 1.1.3.

Both of those versions are not available on the Palm opensource website!

Again the same mistake!

I wonder how much this tells us about the development procedures and release management inside Palm. We know they use OpenEmbedded to build their packages and filesystem image. OpenEmbedded can automatically generate the source code tarballs (+ patches), so the entire process of putting them up at the website could and should be automatized. No manual intervention, no mistakes, no license violations.

I have asked my lawyers to send a letter to Palm, demanding immediate release of the complete corresponding source code. If they do not comply, I am prepared to take legal action against O2 who is distributing the devices in Germany. I desperately hope we do not have to escalate to this point. If we go there, I'd better not imagine how upset O2 will be about Palm and how this will affect their business relationship.

It is so easy for Palm to have that source code on their website. We know that for technical reasons (see above). Why are they deliberately exposing themselves to the legal risk? Why are they willing to accept all the negative PR from them not respecting copyright and the GPL?

Please don't get me wrong. I am not set out to continuously complain about Palm. I would like to see more Linux phones. But why do they have to do everything wrong they can do wrong? Why do they not have somebody to advise them on playing nicely with the legal requirements of the technology they use?

Report on the OpenBSC powered GSM network at HAR2009

I've finally finished the report on the GSM test network at HAR2009, which we operated with OpenBSC in August.

Lack of good Free / Open Source ASN.1 tools detrimental to FOSS in Telecom sphere

For years, I've been working with the GSM specifications by now. My contributions to wireshark, airprobe and most of all the creation of OpenBSC about one year ago further forced me to become very intimate with the various GSM related protocols.

Over the last month or so, I've been looking into some 3G/UMTS specific protocols such as RANAP, as well as more recently at various LTE protocols. It seems like they're more or less all specified in ASN.1 and use a variety of encodings, e.g. PER aligned and unaligned.

Not having useful tools like a code generator for parsing and formatting messages as per those ASN.1 specifications is a major turn-off for starting any Free Software or Open Source project in this area.

It's like having to start from designing tires if you want to build a car. asn1c is a start, but it does not support all the required encodings and even ASN.1 syntax that is used in the 3GPP specs.

I really see a big demand here, otherwise Free and Open Source software development in this area will be severely hampered by the lack of required tools for even more time.

If anyone is interested in helping out to change this, please contact me!

Netgear trying to fool their users with "Open Source Router"

Two days ago, Netgear has announced the so-called "Open Source" WNR3500L router, together with an equally "Open Source" MyOpenRouter community.

The problem with this Open Source router is: It ships with binary-only kernel modules. Not only is this extremely Closed Source, but it also

• has very practical security implications: You can never update your Linux kernel to get the latest security fixes, but have to run vulnerable old kernel versions
• is a very questionable legal practise. Netgear as the vendor is simply relying on the fact that none of the authors who have written parts of the kernel against which their binary-only module links will ever make copyright claims against them

One would have hoped that Netgear did thoroughly study the Open Source market that they're trying to address. Apparently they either did not do that, or they chose to ignore the values/rules by which this community works, or they had somebody with limited understanding to advise them on this.

If anyone has a relationship with Netgear and contacts to the product manager responsible for this product, I would like to ask them for an introduction to that product manager. I would be very happy to help them understand the embarrassment and PR impact that they are putting themselves into by releasing an "Open Source" product that is in fact legally questionable and proprietary.

There are people in the various communities (like OpenWRT or OpenMoko) who have a very clear understanding of what it takes to create a true Open Source product to address the Open Source market. Why are they not asking those experts?

Netgear, you can do much better than that!

Palm has noticed their mistakes

As has been described at TechCrunch, Palm has announced to fix their most prominent issues that many bloggers, including myself, palm has realized that they need to fix some issues with the way they are trying to over-control webOs development.

According to the TechCrunch article, Palm will allow people to write and distribute their own applications (though still you need some kind of URL forward from Palm), and there will be no registration or other fees for people who write open source software for webOs.

This is definitely good news. Let's hope the respective changes will be implemented soon.