portrait picture


balancing software engineering & infosec

Equipped to spy

posted on Wednesday 20th of February 2019 in ,

Some very eventful days, especially when you are in for some good, old privacy drama. First we had news about Singapore Airlines having cameras in their on board entertainment systems and now microphones in Nest smoke detectors. Thanks to the last few years the conclusion that companies are equipping their hardware to gather more information about you is not far fetched. Especially if one of them is basically designed around gathering as much information as possible about everyone.

Singapore Airlines was pretty quick to comment on this and state that the cameras are not in use, that there are no plans for them to be used and that they were simply part of what they bought.

Singapore Airlines replied that it was indeed a camera, embedded into the seat back by the original equipment manufacturers of the plane, but said the cameras had been disabled on its aircraft and “there are no plans to develop any features” using them.


And obviously Google was also pretty quick to explain that they never intended to keep this a secret from their customers.

“The on-device microphone was never intended to be a secret and should have been listed in the tech specs,” the person said. “That was an error on our part.”


Now the company doing evil telling you they are actually not, so all is good, right? Okay, enough cynicism. Let us ignore the obvious conclusion that there was malicious intent.

Looking at both incidents leaves some room for doubt about the intention to spy on everyone. Now assume a “regular user”, someone who is exposed to IoT devices, maybe even uses them, but has no motivation to learn anything. How should a regular user know if there is a risk for their privacy?

Singapore Airlines bought something and it happened to have a camera. So they deactivated it, why would they need one on board of a plane anyway, right? They surely did not go out of their way ordering a custom made system without a camera at a way higher cost, disabling the existing one is easier.

And Nest could use the microphone to record shattering glass to detect a break in. But they never got to the part where they developed the feature, maybe because the acquisition came along. And not documenting unused hardware is not a big deal anyone would have an eye on, right?

I do not think we have to discuss the long term feasibility of deactivating hardware via software. There have been more than enough examples that show what garbage security features in network connected devices are.

If we trust both statements, both companies paid for components they did never intend to use. How feasible it would be to skip adding them depends on many factors – it could have been more economic to keep them in the design and assemble them.

The really important thing is that both companies are big enough to just change it if they would see the existence of the components as problematic. And they decided having a camera and a microphone in a place where they are not needed is not something to be concerned about.

In an age where companies are notoriously bad at securing their little toy devices they want to put everywhere and where most of them lost all trust from privacy concerned people this is simply a bad stance to take. On top of that some of those companies business model boils down to “gather as much information as you can and sell it to whoever pays for it”.

Not having regular users being able to tell anymore if a company is trying to setup yet another device next to your TV to spy on you or if an honest mistake was made is a real problem. And there seems to be no sufficient backlash to instil the mindset of thinking about privacy in companies – enterprises and startups alike – product teams. And if an honest mistake happened the paranoia is already there hitting the wrong company and people.

I am not saying those two incidents were mistakes. I am also not saying Singapore Airlines and Google were working on yet another way to spy on people. But what I can say for sure is that every single little incident which can have some potential impact on privacy will become a bigger deal in the future. There could be two potential, worrisome outcomes – regular users will get more concerned with every device, leading us to some diesel punk inspired future. Or worse, people start ignoring all of this, leading to the dystopian future some people predict.

The third option is finally starting to design privacy as a first class feature in every single product. No matter if hardware or software. If companies finally step up and take responsibility not only for what they individually did, but also how the larger industry messed up over the past years we might have a chance to recover some of the lost trust. But to get there and to instil this mindset of privacy first we need people pointing out every single small incident – and make it a big deal.

We all win

posted on Sunday 17th of February 2019 in

I know I am a bit late with this, but not watching the Super Bowl means I also miss all the commercials and have to wait for them to show up through another channel. The one that really caught my eye was the one from Microsoft. Having played a lot with people with disabilities during my active World of Warcraft time I got a little insight into the challenges some games and some input methods provide.

Especially with games and gaming becoming more and more relevant, for a lot of different reasons varying from person to person, I really appreciate Microsoft stepping up and trying to address some of those challenges.

With IT having some place and relevance to my life since the 90s I have seen Microsoft do a lot of things and the larger community reacting to it. There was a lot of shady things going on deserving all the critique and sneer Microsoft received for it. But looking at all the change since Satya took over time I have hope for Microsoft.

Surely not everything is great. There are still very questionable things going on in some parts of MS. I think I only have to say Candy Crush to trigger some people. But looking across all departments of the company you can see change. Positive change I hope they will try to make in all of their departments. And “we all win” surely is this kind of change where they do something directly addressing (potential) users trying to improve their life.

Unit testing command line applications in Swift

posted on Wednesday 13th of February 2019 in

A joke I hear since the release of Swift 2 is “Swift is production ready, except when it is not” and it feels like I ran into one of the parts where this might be true. I decided to write a small command line application last weekend and since I wanted to see how it feels like working with Swift outside of iOS I took the opportunity and fired up Xcode. Oh, if I would have only know what a wild ride and confusing internet search session I had ahead of me.

The most important reason for me to keep up with Swift outside of the iOS platform is the hope to use it for server side development one day. While it feels like Swift is getting more complex with each release and might suffer from feature creep one day, I still like using it and it feels like an elegant and powerful tool in the toolbox, most of the time.

Starting the application is pretty straight forward. Open Xcode, select command line applications and press “Run”. Easy enough. The first thing that might catch your eye is the fact that no test target was created. But this requires only a few clicks, so that is quick to fix, even if it is a bit inconvenient. As usual when setting up tests I imported the project and asserted a random structs static value. Just a sanity check to make sure everything is wired up properly.

Undefined symbols for architecture x86_64:
  "Token.eof.unsafeMutableAddressor : Swift.String", referenced from:
      implicit closure #1 : @autoclosure () throws -> Swift.Bool in XRI.XRITests.random() -> () in TokenTests.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

So, um,… okay? I have to admit I have not seen this one before. Or I can at least not remember it. There are various solutions you get when searching for this error thrown by the linker, but most of them are not as helpful as you would hope.

I spare you the journey of discovering what the actual error is, to make it short: You cannot test a Swift target compiling to an executable. Technically getting rid of main.swift does the trick, but this might be a bit inconvenient for programs that are, well, build to be executed.

The workaround I am currently using is creating an ordinary library and adding two targets, one for testing and one for running the code. You can take the easy way out and simply add all source files to your target to run the code or you create a proper library like someone who actually cares about abstraction and design.

I clearly have some catching up to do with macOS development, I think the last time I worked on a serious project on this platform was around the transition to OSX. I really hope my solution is not the correct one, even if you find it in various places when searching the web, but simply me not being up to date on how to properly start a project like this. Otherwise I would really have to question the Swift advocates who praise Swift for server side or tooling development, because this is clearly not the way to go.

Screen recoding on iOS

posted on Sunday 10th of February 2019 in ,

When I wrote about Apple revoking enterprise certificates I complained that they missed a unique chance to make a strong statement for their users privacy. Now, a few days later, they actually did exactly this when telling companies to either disclose or remove screen recording from their applications. Except citing App Store review guidelines they point out the importance of protecting users privacy and commit to taking immediate action if necessary. This is exactly the kind of strong statement I asked for.

Looking at the timing I have to assume that some engineers will have a pretty bad weekend thanks to this. They have 24 hours to comply or the app will be removed from the App Store. While I already hear people chanting “they knew what they shipped, they deserve this!” – please keep in mind that not everyone is in the favourable position to freely change jobs with the same frequency as their underwear. There is even a good chance some of the people who now have to fix this did not even know of its existence or consequences. While this should not be understood as a general excuse of developing or shipping products that invade a users privacy – or other questionable things – it should serve as a reminder that there are a lot of grey areas in this discussion we should not plainly ignore.

Having worked on internal and public applications, B2B and B2C, even featured in the App Store I can tell for sure that the amount of times I wished I had a screen capture of everything the user is doing to either improve the app or fix a certain bug is exactly zero. We obviously always had proper bug and exception tracking and custom information attached to crash logs. But they never left our control and private information were scrambled. I can think of two instances where unscrambled user input would have saved us an hour QA time, but this would not have been worth the price every user would have had to pay. And I am talking about “submitted” input, not things that happened and were undone / changed before the user pressed a button. There are a lot of reasons various departments in a company might want screen recordings of user interactions, but not a single one of them will be “to improve the user experience”.

And based on Glassboxs marketing website, companies seem to understand that it might turn out unfavourable being associated with screen recording. Comparing the “who we work with” on archive.org with the one currently live a lot of customer logos disappeared. Guess why.

The Apple Watch that finally won my heart

posted on Saturday 9th of February 2019 in

It was nearly three years ago that I blogged about the Apple Watch. Back then I basically had to get one to start an exploration of how we could leverage the Apple Watch for our app at FlightCar. I was nearly sure I would not like it very much, but I tried giving it a fair chance. Results were pretty mixed. I primarily used it as a fitness tracker when working out. But product development continued and the watch became more appealing to me.

I still do not consider it a watch, at the end of the day it is either an extension to my phone or a stand alone mini version of it, depending on the current usecase. I am not a fan of the “always available” mentality, so when going out with friends for dinner I usually leave my phone in DND and in my jacket and wear a real watch. I obviously have some people on my VIP list that can call through the DND setting, emergencies exist. But responding to an emergency does not happen very often and I rather have a nice conversation while happily munching Sushi than checking Slack to see if anyone pushed a new commit at 2am PST. My favourite watch right now for a casual evening is a Bruno Söhnle Glashütte.

Bruno Söhnle Glasshütte watch

The Apple Watch 3 with the LTE option paired with the AirPods changed the game. I could walk the dog, be reachable and listen to music, without carrying my phone with me. And not carrying a 1200€ phone with me while playing with my 62kg dog actually puts my mind to ease a bit, collateral damage is far less severe. I nearly never carry my phone with me when working out at the gym, except for when I am on call. With the Apple Watch LTE with me I was actually able to get an emergency call for an incident while I was not on call, but was able to help resolving it an hour earlier than I would have otherwise. Again, this does not happen very often, but when it does I am glad to be available and have a chance to engage as needed.

After getting the Apple Watch 3 with LTE I started wearing the watch more often, but still only during certain activities were I did not want to bring my phone. It just did not feel great wearing it all day. And since I do not really bother with counting calories it does not make a difference to me to not know how many I potentially burned.

The same way the Apple Watch 3 changed the game, the next iteration changed it again. When watching the keynote for the Apple Watch 4 I was not really impressed.

“Oh nice, it is a bit smaller. And a bit larger. Biiiiiiig deal.”

Since I had the chance to pass on my Apple Watch 3 and get my hands on the potentially useful new sensors I was interested, but did not really expect any significant change. Ohh, was I wrong. The new form factor actually makes it way more pleasant to wear the watch. I did not expect a few millimetres here and there to make a big difference, but it actually does for me. The slightly larger “edge to edge” display looks great and gives a more well-rounded look to the device and the overall responsiveness helps a lot to make the watch feel better when using it, the dimensions are clearly the defining factor for me. Weight actually went up a tiny bit, but I really cannot claim I have noticed the difference.

Another very important change was the availability of Apple Pay in Germany. Yes, we actually did it, even a year earlier than I predicted. What an amazing feat for a digital development country. Not only being available for the people I want to be available for, but also being able to leave my wallet at home is another improvement of my day to day life. By now I actually wear my Apple Watch nearly the whole day, except when going out – then I still have a phone in my jacket and a real watch at my wrist. Nothing beats the feeling of looking at a fine piece of mechanical craftsmanship.

Something I also learned when starting to wear v3 for a longer time (and really noticed with v4) is the difference in wristbands. You often hear people claiming a cheap third party wristband is as good as an expensive one from Apple. To make it short: no, it is not. I would try to compare a Nike sports band vs a 10€ no name one – but this would not only be unfair, but also completely pointless since there is no comparison. With one you already start sweating putting it on while the other keeps your wrist in a decent state during a whole workout. And the same goes for the nylon bands. Being cheap on your wristband is basically the same as being cheap on the case for your 1200€ phone. Sure, it kind of works, but it still sucks if your sense of touch if not completely distorted.

Apple Watch and sport wristband

Being actually happy with the Apple Watch made me reevaluate my opinion on what device I would actually like to see from Apple, but I came to the same conclusion – an Apple Wristband. Slightly longer, not square, integrated in a nice fabric for the actual band which I can wear on my other arm so the very useful device does not compete with my watch. I enjoy using the Apple Watch on a daily basis, but it will not get a permanent spot on my arm. A wristband on the other hand would.

(As a general note: I will also not start wearing two watches, even if one of them is a mini computer – for the same reason you will never see me carrying two phones. I am so not important enough for that.)