App Updates with Hidden Features

There seems to be a recent trend for smartphone apps: hidden features are shipped in app updates without mentioning the new functionality in the changelog. Only later the feature suddenly becomes active without further notice.

Recently Threema added the ability to conduct polls in a group chat. Apparently, parts of the feature were already shipped before the feature was released to everyone. I was able to answer polls on my phone running the Android app, but I was not able to create them. One could argue that maybe their app UI is so extensible that it can display anything as provided by their API. However, once I installed the next app update—mentioning the new poll feature in the changelog—the UI for polls also changed significantly. This is a clear indication that the feature has a UI part which was already included in the previous update, but was hidden from the user until announced publicly to everyone.

Similarly WhatsApp recently added their second screen solution to the popular messaging service. The menu item to scan the bar code on the WhatsApp web site suddenly appeared in my app, without any update. The next update now mentions the feature in the changelog, but apparently it was already shipped with the previous version.

I totally understand the intentions behind these hidden updates. The companies behind the apps want to enable their users to adopt new services immediately without disruption. If Threema is not able to understand a message that starts a new poll, the user will see garbage, or an error message, or a request to update the app. For WhatsApp, users would be asked to scan the bar code, but cannot find the menu item in their app. Both examples demonstrate undesirably user experience they want to avoid.

However, this means any app update might always contain a hidden feature. Something you do not see in the UI yet, but which is included in the code. No changelog mentions this new functionality and unless someone starts to decompile and inspect every app update, nobody will notice it at all. Maybe there was already a planned feature shipped with an app update once, but it was never activated? Nobody will ever know.

For me, this was on Android, where Google basically only reacts to complaints from users to remove misbehaving apps. Did they also get these new features past the app review process for iOS by Apple? They are well-known to be very harsh in their app reviews and easily reject updates not satisfying all criteria. Did these companies tell Apple about the new features before telling everyone else? Would a small company be able to pull off the same thing and ship hidden features?

For a suspicious user this is a scary situation. Maybe they don’t want to continue to use the app with the new feature? The examples above were mostly harmless, but what if the new hidden feature is something that affects your privacy? The blue ticks for read receipts in WhatsApp already caused a lot of uproar from users a few months ago. (Fun fact: as I tried to link some reference for this, I noticed this new feature was not even worth an announcement on their blog. Well, it got enough publicity, anyway).

What if an app suddenly decides to share your current location all the time? Sure, it asked for the permission to get your current location, but it was only using it for another purpose before. You agreed to allow it for the purpose you saw in the UI. Users have to be aware that everything they allow an app to access might suddenly be used for a purpose they have not seen in the UI before—and no review of the app mentioned it.

By the way, the same has already been true for web services for a long time. Updates are inherently provided by the company running the service and you cannot use the old version anymore. You would even only know about the update beforehand, if they gave you a heads-up. Are we also heading to a continuous update model for apps now? Are we just fine with unanticipated changes being applied to the apps installed locally on our devices?

This kind of problem is tied closely to closed source software, because nobody can easily verify what it actually does behind the UI. These recent examples prove one thing to me: if you want full control over what software does on your device, you have to use open source software only.

Yes, the pessimistic haters will say that I had to expect nothing else from closed source apps, anyway. But I will not give up on closed source software now. Frankly, I cannot do that without also giving up a lot of convenience and ease of use at the moment. Nevertheless, I will watch out more closely which permission I hand out to which app. Likewise you should be aware every app on your phone might suddenly use your data and information about you for something completely different, even before the app update changelog announces any new features.

John Murphy – Anonymous Rejected Filmscore

In August this year, John Murphy released his Anonymous Rejected Filmscore. A soundtrack that was rejected and actually never used for the film it was written for. Nevertheless, these tracks found their way to their own album years later. John Murphy wrote about the release:

John Murphy – Anonymous Rejected Filmscore

‘Ano’ is the soundtrack album based on a film score I had thrown out five or six years ago. And even though the score hit the cutting room floor, I always felt it was one of my better, more original efforts. In my head it became the ‘lost score’. The score without a film.

Continue reading

SNI bug fix for ssl-cert-check, now on Github

Recently I found some new bug in ssl-cert-check, my tool for checking the expiry dates of local and remote SSL certificates. The tool has worked fine for me over the years, but I used to have expiry dates that were very close to another, so I never noticed that it did not work for web servers using SNI to serve multiple domains with virtual hosts from the same IP address. I am sorry I did not think of this earlier. I fixed the bug now and in case you have such a setup, I encourage you to get the new release.

I also noticed it becomes cumbersome to maintain the updates with blog posts and downloads here. Therefore, ssl-cert-check is now on Github and I will continue to make releases from there.

You can get the latest release tagged 2014-08-20 either as a local download or from github.com.

Distrusting StartSSL

Heartbleed

Heartbleed

After the HeartBleed bug in OpenSSL, a lot of SSL certificates must be considered compromised now. This means that a huge amount of SSL certificates needs to be reissued. The security scheme we are using relies on trust. You have to trust that the CA only signs certificates after verifying the requester and that nobody else knows the private key for the SSL certificate. CloudFlare demonstrated now that it really is possible to get the private key through this vulnerability. If you don’t trust your own SSL certificate any more because its private key has been compromised, you have to get a new one and revoke the old one.

Going through this process alone is bad enough already. However, many people I know and also myself are using free SSL certificates issued by StartSSL.

StartSSL

I always thought StartCom, the company behind the StartSSL brand, is doing the right thing by providing free SSL certificates. I trusted them because I thought they would advance the use of crypto on the internet by giving everyone access to SSL certificates in order to secure their personal web server, mail server, or anything else that uses SSL.
Continue reading

Tiny LEDs for a tiny microcontroller

Version 2.0 of the #ATtiny9 board setup with LEDs. SMD makes this so much smaller.
Originally published at https://twitter.com/raimue/status/433353488043499520

Compared to the ATtiny9 on this board, my previous setup with 10mm LEDs took way too much space. So I miniaturized it with some spare SMD components I still had from previous projects.

This LED bar is breadboard compatible and fits directly onto the board. I deliberately chose to make it a bit larger than it had to be, now taking 5 pin columns of space. This size allows to use it on either side of the breadboard, as the Vcc and GND bus strips are switched on the other side. I also decided to leave out two pins on the GND pin header to make it fit in more different positions on the board, which was necessary due to pin grouping. Besides that I had to solve alignment issues, as the pins on the GND strip and the rest are a little bit shifted. I had to use a little bit force by pushing it into its position and then solder it as it was plugged onto the breadboard.

Actually this was not only for the ATtiny9 thing, but I think this device will be helpful in the future in general. From now on I will always have some LEDs available for the breadboard without fiddling around with wires and resistors.