Dissecting traffic from SpringPad for iOS

My research over the last couple of months has focused on the security ghetto of WordPress plugins. But recently @arnimarhardar turned me to the subject of mobile applications. As they often use HTTP, I felt right at home. I decided to download a few random applications onto my iPad and then go to town. I personally use my iPhone on a daily basis, so what I’m about to describe to you was quite the eye-opener for me in terms of what sort of data is sent about you to third-parties and such. Let me present to you, an extremely popular application: SpringPad.

Note: I’ve masked out parts of requests since they may contain unique identifiers and such things.

Dissecting Springpad
Armed with my recently acquired copy of Burp Pro, I booted up the application for the very first time. I was greeted with an authentication screen, asking me to sign up. Already at this point, Springpad has contacted a number of very interesting domains. There’s a few calls to Twitter and Facebook and such, but I’ve left those out since they offer no insights into what Springpad does.

  • https://api.redlaser.com
  • http://data.flurry.com
  • http://iphone3.springpad.com
  • https://ws.tapjoyads.com

Of these 4 requests, only one of them is actually related to the application at all. That seemed very odd to me. So let’s look at what they did in order listed.

Third-party requests

RedLaser is a “RedLaser is a free shopping app for iPhone, Windows Phones, and Android that has been downloaded over 19 million times.”. Ok, interesting. How that is used by a note-taking application is a mystery to me. But from what we can tell from the request, is that they sent the name of the application making the request, an unique identifier, the platform, hardware versions, sdk version, the build number, locale, application version and OS version. Of course, sending across an unique identifier is a bit questionable, given that I as an end-user have no idea what redlaser is, but let’s move on!

This one is fun, because it seems to be sending across an actual data-structure, null-byte padding and everything. But it’s sending across a couple of (unique) identifiers, resolution, model, and version information. That’s nice. Not only does there seem to be one piece of identifying information in this request like to redlaser, there’s several.

Before getting into the actual request to springpad, we need a last stop over to tapjoyads.com!

The third request to a third party consists of a lot of fun information, such as country, device type, carrier name, language, iOS version, and your devices’ mac address.

Springpad requests
And now, for the main course, Springpad. Let’s see what it’s got in store for us!

This is the first request it makes, and the very first thing that greeted me was that this communication didn’t go over HTTPS, which is a concern. But onto the request, we see some OAuth fun, and then a device identifier, which is again your mac address. Ok, not the biggest of deals, let’s now sign up!

At this point, we post our credentials to the site(Over HTTP, mind you. Ooops) with the addition of a sessionID in our cookie. Again we see the transmission of your mac address.

Hold on a minute, what is that being sent across the wire? At this point, all I’ve clicked on is for me to sign up and just finish registration. I’ve not been requested to submit all of my contacts which are stored in my iOS contact list. Huh, that’s odd! I thought maybe I missed something, so I checked again. Nope, I’m not asked if I want to upload this.

Note that these emails were a part of the HTTP request

The fine-print part of the story
So let’s go consult our privacy policy as for what information the application will automatically upload from me:

Oh, how odd. Not a word about contacts! This isn’t really what I’d expect. There’s another bit of the privacy policy which states:

Thinking that I could now log into their web-site and see which information they have obtained from me, I logged in and started reviewing it. To my surprise, not a single mention of contacts was to be found. This is starting to smell. So let’s consult the iOS Application Guidelines as put forward by Apple:

I am no lawyer, but I don’t see that this application should have, as per Apples application guidelines, taken this information from my device without permission.

Does this remind anybody else about Path?

Response from vendor
When I contacted Springpad about my concerns in regards to the lack of HTTPS and their use of contact information, they were very prompt in a reply to my concerns, specifically in regards to the lack of HTTPS and the use of contact informations. They explained that the lack of HTTPS was a result of a bug in the build process. A fix for this was being fast-tracked for submission to Apple by the end of the day.

They acknowledged that the application uploaded the emails from the contact book of the device. They noted that the data wasn’t stored, only kept in memory to see if anybody you know uses SpringPad as well. They plan to request for explicit permission in version 3.0.7, which at the time of writing is being tested by their QA.

Overall, they were extremely quick to reply and addressed my concerns quite well, despite having a bad time all at the same time.

Leave a Reply