Cookie Crumb Mobile App Design

Biz & IT —

Your favorite mobile apps leave a trail of cookie crumbs

We monitor our own smartphone traffic to see how much data apps are giving up.

Instagram's cookies and unencrypted Web traffic give you up to anyone watching packets pass by.

Sean Gallagher

Most people know the privacy risk of Web cookies—the bits of data that Web browsers store and return to websites to help them keep track of your credentials, where you are in an application, and other information. Advertisers, social media services, and search engine providers use cookies to track users' travels on the Web to target them for advertising. And as we've reported, those cookies can be used by someone surveilling Web traffic to track you as well.

But when people use mobile applications, they're also vulnerable to the same sort of cookie tracking. Many mobile apps are just Web applications wrapped in a package for an app store—they send cookies back to the same server to identify the user and provide location information and other data about a device to the application vendor, third parties, or anyone who happens to be watching network traffic. Taken together with other data, these cookies can be used to track individuals as they wander the world, posing a significant privacy risk.

There are other components of the Web content consumed by mobile apps that can be used in tracking. Some use REST interfaces that pass data as part of their requests back to servers, and that data is often sent in the clear. JavaScript elements within Web content can also access local device data and send it back as a data structure; this data is often sent unencrypted as well, and the process follows a common enough format for hackers or intelligence organizations to reverse engineer it.

To see just how much data can be collected on an individual from mobile cookies, I monitored my own smartphone traffic on iOS and Android devices for a few hours on three separate days to see how much of the cookie data remained the same—both from day to day and from device to device. It was clear that if someone was trying to track me based on Internet traffic alone, they'd have a pretty good idea of my movements.

Instagram

Facebook has done a lot to try to preserve users' privacy in its applications (both mobile and Web). But Instagram, which Facebook acquired in 2012, doesn't do nearly as much to protect its users. While sessions are protected from cross-site request forgery by a Django CSRF token created within each session, the "user_id" (a numeric value) and "igfl" (the actual username for Instagram) within cookies for Instagram sessions remain the same from session to session and device to device. There's also "agent" information sent as part of the cookie, which identifies the hardware and operating system of the mobile device.

This data is sent to Instagram's servers each time a user fetches new content, posts a comment, likes an image, or posts their own image. The text of comments is sent in the clear as part of the posts, and images are sent in the clear as well. But EXIF data is at least scrubbed out of the images, so no location data is shared. Location data would have to be extrapolated by your broadband cellular IP address geolocation or by using the known location of whatever Wi-Fi network you connected to—or by grabbing data from other cookies from your phone.

Angry Birds and Plants vs. Zombies

Enlarge / Angry Birds' SkyRocket "cookies" are in JavaScript Over Network (JSON) data format, and they're full of information about your phone.

Sean Gallagher

Games aren't immune to leaking cookie data, especially ones that display in-game advertisements. Angry Birds, for instance, sends a cookie back to its cloud servers that includes geolocation data and the universal device identification (UDID) number of an iPhone.

Rovio, like many other game developers, uses an in-app advertising platform to "monetize" Angry Birds. The company's platform of choice is SkyRocket, a service of Burstly (acquired earlier this year by Apple). SkyRocket collects data like the IP address, UDID, geolocation by latitude and longitude, and other identifying data to determine which ads to serve up to the device running the game.

PopCap Games' Plants Vs. Zombies 2 also uses in-game ad services, including SupersonicAds' Ultra and Conversant Media (formerly ValueClick). Both of these services use identifying cookies, though Ultra's includes much more data than Conversant—requesting the phone's carrier information, its make and model, operating system version, free storage space, the type of connection (Wi-Fi or cellular), and Google Analytics tracking codes. The app also generates a unique machine ID, which persists from session to session. On Android devices, there's a "player ID" that gets passed in cookies as well, though this data is blocked in iOS (where the user ID is handled by Apple's Game Center app).

One of the Ultra ad cookies from <em>Plants vs. Zombies 2.</em> — Enlarge / One of the Ultra ad cookies from *Plants vs. Zombies 2.*

Sean Gallagher

I couldn't find GPS location data within PvZ's cookies, so PopCap isn't doing highly geotargeted advertising… yet. But the ad providers are certainly using IP address data to do some localization of advertisements.

Lima Sky's Doodle Jump only had one set of obvious cookies embedded—Google Analytics calls for "_utma" and "_utmz." The value for these cookies was different from those used by Plants vs. Zombies because they each had different "agent" identifiers.

Hotel hunting

I was pleasantly surprised by how well the location-based apps I tested have locked down their data using secure protocols and hashed data. By their nature, these apps have to use location data to do their job. Hotels.com, for example, collects information on location to help a user search for a hotel nearby.

However, Hotels.com hashes cookie data to protect privacy. The "user" identifier in Hotels.com cookies has a life of one day, so it's not something that could be used to trace a user over multiple sessions and locations (though the Omniture "Etag" used for analytics might be a unique identifier for a longer period of time). And while the service uses advertisements, the ad requests are encrypted using HTTPS (well, at least for the ads served by the French ad server Criteo).

However, Hotels.com also uses Facebook cookies. These cookies are also encrypted, but they're used by Facebook to drive on-site advertisements and might be used for cross-site marketing. They could also theoretically be used for analysis by a government agency requesting the data—but then again, so could Hotels.com's server logs.

HotelsByMe, another hotel search app, used secure HTTP for much of its communication with its Akamai-hosted content. Its advertising and analytics platform, Flurry, gave up a bit more information about the phone, including its time zone data (America/New York for me in Baltimore), the type of device, and the OS. Flurry also assigns what appears to be a unique ID to the device, which is trackable from session to session.

Sometimes apps are better

Mobile apps are sometimes more secure than their Web counterparts. For example, Wikipedia's mobile app uses TLS encryption for all its traffic. However, search Wikipedia from a mobile Web browser, and by default the site is unencrypted—and location data is passed as part of WikiMedia Foundation's cookies.

I performed the same search from the Wikipedia client and from the built-in browsers in iOS and Android. While the application's data was fully encrypted by default, some images culled from the Web browsers sent information on my geolocation—including a latitude and longitude that were within 500 feet of my location, as well as the explicit city, state, and country information. I reached out to the Wikimedia Foundation for comment on the location cookie ~~but did not receive a reply~~. Erik Möller, Wikimedia Foundation's vice president of Engineering, said that the cookie is used for performance purposes.

"This is what any site or service you visit immediately knows about you (by looking up your IP address in one of the many databases that match IP addresses and probable locations)," Möller wrote in an email to Ars. "This information is very imprecise -- it's reasonably accurate at the country level, but the exact location estimate will often be wildly off. We use this information for two primary purposes. When we run fundraising banners, we often target specific geographies to optimize timing and messaging. This is done at the country level only. [And] The Wikimedia community sometimes runs banners inviting users to participate in community events. There's two types of these right now: country-level banners that are shown for all users (e.g." The Great American Wiknic "), [and]more targeted information (using the coordinate estimates derived from the IP address) that's shown when a user visits their watchlist, e.g. for a community event in a specific city."

Outed by advertisers

Analysis of the traffic of a host of other applications led me to conclude that the biggest privacy hole in applications comes not from the cookies that were created by the app developers themselves but by the advertising, analytics, and "monetization" services they've bolted on to them.

Google Analytics, for example, can execute JavaScript within the Web containers used by these applications to extract geolocation data. While regular browser users can turn this off with a plugin, that's not an option for mobile apps where the user has no control over how the Web component behaves.

Because services like Google Analytics, Omniture, and SkyRocket are so commonly used in mobile applications, they make a ripe target for those interested in tracking mobile users. Even if you're not explicitly giving apps access to location data, you could still be leaving a trail that's easily followed by those who connect the data from these services with IP address data and other information gleaned from traffic.