Category: Uncategorized

When I recently helped a friend to configure the email program on his Android phone I was quite happy to see that the auto configuration function worked pretty well. With only the email address and password, the program configured itself to send and receive email to one of Germany's national major email hubs. What I didn't like though is that both SMTP and POP3 where configured to use non encrypted communication.

In practice this is quite a serious shortcoming as many people still use Wi-Fi hotspots in restaurants, cafes, etc. and are thus very vulnerable to password and identity theft by simple Wi-Fi sniffing by a black hat sitting at the other end of the cafe, or just at the next table…

Yes, I am aware that there are quite a number of possible security settings email servers can use but I suppose a couple of trial and error attempts in the background to find the right one to use wouldn't hurt. And if still nothing can be found, open communication could be the last resort, combined with a warning to the user that the service has been configured without encryption. Let's hope we'll see this in the future.

No doubt, calendar and address book synchronization between PCs, smartphones and perhaps a web based interface is a convenient thing. However, so far I always stayed away from this as it meant handing over my data to a web based company. While I am sure that pretty much every online service has my phone number and email address by now from other people using Facebook, WhatsApp and other services that suck complete address books right out of smartphones, I at least didn't want to give my data myself to them. Also, to the best of my knowledge, my calendar information is still my own. O.k. a little bit less convenience but my data has remained private for the most part. But now there's a solution for this as Owncloud, that I started using for sharing files, also has calendar and address book sharing support.

I was quite amazed how simple it was as Owncloud uses CalDAV and CardDAV that are supported by quite a number of programs and operating systems. On the PC I use Thunderbird / Lightning for my calendar needs. Getting my Thunderbird calendar on my own Owncloud server at home was as simple as exporting all calendar entries in a file and pushing it via the web interface to the Owncloud file server. From there, a click on the file imports all calendar entries to one of the online calendars I created. Perfect, a 2 minute job for calendar entries of several years.

Synchronizing with Thunderbird is equally simple. Owncloud provides a URL for accessing the calendar via CalDAV which can be used in Thunderbird for accessing an online calendar. Another two minute job and I can see the calendar in Lightning and not only via Owncloud's web interface. Thunderbird also has the option of keeping an offline copy of the calendar. New entries or changes to an existing entry are immediately sent to Owncloud if a connection can be established. If not, Thunderbird saves the changes and can be made to send the changes once connectivity is available again. Perfect!

But of course all of this is of little use unless I can synchronize the calendar with my other devices as well. Android doesn't support CalDAV natively but "CalDAV-Sync beta" from the app store adds the functionality. With that I synched an HTC smartphone and a Samsung tablet with the Owncloud calendar and changes in Thunderbird or one of the mobile calendars replicated nicely to the other devices periodically or when triggered manually. I tried very hard to see if I could break synchronization in some way by deleting the same entry on several devices, by adding new entries simultaneously on different devices, etc. but all changes were always synchronized correctly to all devices. Perfect again!

And finally there's my address book that I'd really like to synchronize. Unfortunately there's no support for CardDAV in Symbian so the best I could do was to export all addresses from my N8 into 'vcf' files and then upload them to Owncloud. Again, the server immediately recognized the address files and added them to my cloud based address book at home. From there I can now easily access the address book via the Owncloud web interface and synchronize it to Android address books, again with a little helper program from the App store.

Almost perfect I'd say! The combination of address book and calendar synchronization might provide an incentive in the future to retire my N8 and go for an Android based device, while keeping the N8 for offline navigation and quality photography, two things that I still find lacking in any Android based device I've so far fancied.

Both thumbs up for Owncloud, and I'd raise two more if I could. Finally I am beginning to love the cloud, as my data is stored on my own hardware in my place and still accessible anywhere I am via secure http (and port forwarding from my DSL access point to my Owncloud server + Dyndns).

Here's a link to an interesting post over at AnandTech on Broadcom demoing their new LTE chipset running in a Band 17 (700 MHz) and Band 4 (1700 MHz) LTE carrier aggregation mode (10+10 MHz). AT&T owns spectrum in both bands so it's clear whom this targets. Also have a closer look at the pictures at the bottom of the post as they contain some further interesting details.

And here's AnandTechs report about LTE carrier aggregation demonstrated by ST-Ericsson. Interesting in the pictures at the bottom of the post is the band combinations shown, lots for the US, one for Korea and one for Japan. A good indication of who's going to use it first and who's not on the list at all (Europe!).

While in Europe, many network operators have 20 MHz of continuous spectrum and thus don't need carrier aggregation some indeed only use a 10 MHz channel in the 800 MHz band and might be tempted to add another 10 MHz from some of their other spectrum holdings in the future. But I guess US carriers are more starved for it than their European counterparts, who are still doing fine serving their customers data hungry devices on UMTS.

Kudos to AnandTech for reporting from MWC off the beaten smartphone path.

Before returning to the normal programming a quick thank you to all who have taken part in my survey from earlier in the week on how you read this blog. Out of the 160+ votes, 2/3 responded that they read this blog via an RSS Feed reader. I've also received a lot of comments and private emails on the topic confirming this an only two responders said they use something other than Google Reader. Looks like an overwhelming market share and lots of people will be looking for an alternative to Google Reader soon. My personal favorite today is the reader to be integrated into Owncloud and I will definitely keep you posted on my experience with it once it is released. And now back to wireless…

In a quick follow up to my post yesterday about the closure of Google Reader not only being a sad move but actually a chance for the web to develop I would be quite interested how many of you read this blog directly and how many of you use an RSS feed reader. If you could spare a couple of seconds I’d appreciate if you could take part in the poll below.

Thanks very much!

If you are reading blogs like mine via an RSS Feed Reader you've probably heard by now that Google wants to shut down their popular Google Reader in a couple of months. Being a Google Reader user myself I was disappointed at first because it is a great service, works well and using it is part of my daily routine. What I like(d) is that I can read posts on my mobile and on the desktop and that the reading status is synchronized between both. But then I realized that while this is disappointing news it is also a big chance for me and the web as a whole as well.

Some background on my usage behavior: Apart from Google's search engine and the Android market, Google Reader is (will have been) the only service I use from Google. I intentionally don't use Google online apps such as Google docs, their online calendar and address book synchronization, no gmail or any other online service from them. My private data is mine and I don't want to store that unencrypted or encrypted with the key being held by the online service on some far away server. Instead I use Owncloud with a tiny Rasperry Pi at home for sharing files and lots of other stuff (more details in a separate post soon). For backups I do indeed use a cloud drive, but all data is encrypted before it leaves my network with an encryption key only I posses.

Back to Google Reader. It's one of the few cloud based service I use in which private data is stored. And in Google Reader the amount of private data is limited to the feeds that I have subscribed to and my reading behavior. So while it's sad to see the service go it's also a chance for the web and myself to think about alternatives. Today there seem to be few as many RSS feed readers use Google Reader's API. But the programmers of some of them have already responded that they will make themselves independent of Google before their API goes out of service. I have high hopes that the OwnCloud RSS Feed Aggregator (Owncloud News) is being extended in time so I can use it on the desktop and also via a mobile web browser or an app.

So with a bit of luck Google's move will bring back diversity and give those who want a free, open and decentralized Internet real choices in the future.

Good luck Google, and thanks for all the fish!

I'm usually not very positive when it comes to mobile networks in France but today I have a positive story!

Like many other countries, France now has a fourth mobile network operator and competition has significantly increased. It has increased so much that a friend of mine decided to switch operators. We tried to get a better deal before switching but they were pretty much inflexible. It's this way or the highway was the message. O.k., so we took the highway and here's the story of how that went:

The only issue with switching operators in this case was that it was crucial to take the mobile number to the new network operator. There is Mobile Number Portability in France for some time now how but how long would it take to port the number and how long would the service interruption time be? We had no idea, 10 days to port the number was quoted in some forums but not much other information was available. But the pricing pressure was higher than the fear of service interruption and temporary numbers so we risked the step.

The new operator only sells prepaid and postpaid SIMs online which was much better for us anyway than going to a shop somewhere. The order process was swift and already included the necessary steps to get the mobile number ported. During the online order process the system requests that a call is made  to an automated system to get a porting identifier that then has to be given to the new network operator. That's all I thought, no forms to be filled out and mailed, no hassle, no nothing!? Well, that's almost too simple!? However, that was really all.

The SIM card arrived a couple of days later and after activating the SIM card, again via the web portal, by typing in the last three digits of the card-id, it was activated within 2 hours with a temporary number. During each step of the process an email arrived to confirm that the step was successful and with information about next steps and approximate durations. At this point the web site and the email confirmed the successful activation after about two hours and that the number portability process was now in its final stage. Three days maximum were promised for the number to be transferred. This was around 11 pm in the evening.

At around 7.20 am the next morning we received another email that the number is now ported. Wow, 8 hours later, very nice! The phone had to be restarted once as described in the email and then it just worked, the old number was on the new SIM card.

I have to say, I AM REALLY IMPRESSED!!! The process worked flawlessly, the information provided was clear, precise and accurate and everything worked very quickly. I have a lively imagination based on previous bad experience,  so after having been prepared for the worst, i.e. the number lost somewhere during the process, endless calls to hotlines of both network operators and two contracts running side by side for a couple of months you can't believe the joy I felt.

Very well done, finally something I am impressed about the French mobile landscape!

For ordinary files, the write speed of USB Flash sticks is probably of only secondary importance. However, when writing large files onto them, for example ISO images of Linux distributions or virtual machine images, write speed becomes an important factor.

Writing a 1 GB file to a slow USB flash disk at 1 Mbyte/s takes over 16 minutes while the same operation takes just over a minute when using a fast USB Flash disk that can write around 12 Mbyte/s to its Flash cells. And that's about the span I discovered on my various USB flash disks that have accumulated over the years. I have a couple of physically very small 4 GB USB sticks that hardly stick out from a USB port but the 1 Mbyte/s write speed is just measly. It's probably not due to their size as similar sized current models are advertised with write speeds of around 5-6 Mbyte/s.

Then I have a number of USB sticks with capacities between 2 GB and 16 GB of various sizes. Most of them are capable to write between 4.5 and 6.5 Mbyte/s to their flash cells. But that's still slow for 1+ GB sized files so I ordered a couple of 8 GB Transcend Ultra Speed USB sticks as they are rated for writing speeds of 12 Mbyte/s. And indeed, when testing them I could get 12.5 Mbyte/s of sustained writing speed out of them on sequential large file writes. Random write access is a bit slower, around 4.5 Mbyte/s.

When reading data on the sticks I see data rates between 20 Mbyte/s on the slowest ones up to 35 Mbyte/s on the Transcend Ultra Speed, which is pretty much the limit of the USB 2 port. Perhaps I should also try a USB 3 capable Flash stick. I don't have a USB 3 port on my PC but the write speed of these sticks seem to be again much faster.

The picture on the left shows the read and write speeds of the Transcend stick. The average write rate seems to be from random writes as writing a 1 GB file to resulted in a write rate of 12.5 Mbyte/s (timed with a watch, with unmount afterwards to ensure empty buffers).

There we go, with my cloud file sharing service dead in the water thanks to AVMs lousy software that they don't want to fix anytime soon I had to look for other options to turn the tide and convert a defeat into a victory. To recap, I sometimes need to share large files and don't want to use Dropbox like services that require my data to go out to a server somewhere on the web.

While thinking about alternatives I remembered that I once came accross ownCloud, an open source software that should do just what I wanted. And indeed after having taken a closer look it seemed to be exactly what I wanted. Then I remembered a low cost, low power computer called Rasperry Pi that runs Linux, perhaps a perfect base for running ownCloud inexpensively? And indeed, a Google search revealed how to install ownCloud on a Pi in just a few steps.

To see if ownCloud would be a solution for me, I downloaded a virtual machine image with a x86 Suse Linux base and ran it in Virtualbox on my PC. I came away very impressed about how easy it was to create users in ownCloud and how to share files by creating URLs in the browser. Also, uploading files via WebDAV as an additional convenience worked out of the box. Perfect! So I decided to go for the Raspberry solution and ordered one for next day delivery.

Needless to say I could hardly wait for its arrival but at least I could busy myself with preparing a couple of SD cards to boot it from. For a quick start, a Pi enthusiast has already created an SD card image with ownCloud preinstalled, so I used that for my first steps. In addition I downloaded the original Raspian Pi image to install ownCloud from scratch lateron.

As expected the Pi was delivered the next day and getting it up and running was as simple as connecting it to a mobile phone charger via USB to supply power and to plug in an Ethernet cable for connectivity. For the first experiments I also used a keyboard, mouse and monitor but quickly switched to a network only configuration as for the few cases in which I need a graphical user interface on the PI I can run that over the network using X11VNC.

Since I had ownCloud preconfigured on the SD card image I could log in immedately via the web browser and could start using it. With wired connectivity, I could read and write files at around 30 MBit/s. That doesn't sound like much at first but since the main use will later on be over Wi-Fi which is limited to around 25 Mbit/s at my place and over VDSL with a 5 Mbit/s uplink speed it is enough for my purpose. Also, the Pi only runs on around 2 Watts (!), which will only add around 3-4 Euros per year to my engery bill. So I think the 30 Mbit/s is a good compromise.

The final step was installing ownCloud on a plain Raspian image which also just took half an hour at most thanks to this tutorial, including the extra configuration for having a 5 GB system partition and a 10 GB data partition on the SD card and configuring the mount in fstab manually.

So for 60 Euros including the 16 GB SD card, a 3-4 euros per year power bill and a lot of fun setting the whole thing up I have my own file server now that I can use to share documents with other people on the fly. I really like that!

But of course I couldn't stop there because ownCloud can also synchronize calenders and address books between devices, something I don't want Google or anyone else do for me and from which I so far always refrained from. In a follow up post, I'll describe how that went. So stay tuned.

Back in December I was ecstatic when AVM released a new software version for my Fritzbox VDSL/Wi-Fi Router at home as they included a cloud file server system in the box that made it very easy to share large files with other people, which I sometimes do. And things worked pretty well for about a month ago until things suddenly started to go wrong.

I first noticed it when I got an email from a friend that the sharing URL I sent for a file stored on the Box was not working. I investigated and found out that the sharing link disappeared from the routers sharing links list. So I added it again and just to make sure rebooted the box. And gone it was again. Hm, o.k. so I added it again and told my friend to download the file immediately before my daily automated power interruption (for stability reasons) resets the link again. Lets fix this later I thought.

Then he told me that the link worked but the file download always terminates after around 30 MB. What!? So I tried myself and indeed, after 30 MBs the transfers to the outside world always terminated. Now this was getting really inconvenient. So I saved the configuration, made a complete firmware reset of the router and restored the configuration in the hope that the file sharing problem would go away. But unfortunately it didn't. Hours wasted on two problems and no fix in sight.

So I opted for the last resort and contacted tech support with a detailed description of my two problems. A couple of days later (what a joke) I got a response that the early file transfer termination is a known problem and would at some point be fixed. But they couldn't give me a date and also didn't mention if there's a fix in sight for the second problem with the disappearing sharing links after reboot.

Very disappointing really and I don't think it's going to be another Fritzbox for me in the future… I felt a bit stranded as I was left without a good solution for my use case as I don't want to use Dropbox and Co. But then I remembered that the other day I read something about a personal cloud service, OwnCloud, which finally saved the day. But that's a story for the next post.