Do Not Track and Preference Management

By Travis Pinnick
User Experience Designer | TRUSTe

The current industry standard of providing user preferences around ad-related tracking makes use of a script-based in-ad icon as specified by the DAA which links to a preference management tool. Newer browsers are also supporting the Do Not Track (DNT) header request as an alternate method of indicating user preferences.

With the proliferation of DNT it is becoming more obvious that future systems need to be technology-agnostic in their approach to preference management. Until the industry fully adopts DNT, a temporary solution could be to integrate DNT recognition mechanisms into existing cookie-based systems.

DNT vs Cookie-based preferences

DNT is a browser feature that appends a header to http requests expressing a user’s preference not to be tracked (currently implemented in newer versions of Firefox, IE, and soon to be implemented in Chrome).

A strong advantage of DNT is that it makes it easy for consumers state a clear preference regarding tracking. Unfortunately other than an acknowledgement response that the signal was detected, DNT lacks a technical method of enforcement and relies on trackers to honor the request.

Cookie-based opt-out tools are used to indicate that a user wishes to be opted-out of behavioral advertising. This places the burden of control on the user to deal with large numbers of tracking domains, and deleting cookies (a common consumer approach for controlling privacy) also deletes the opt-out preferences.

DNT Exception Handling

DNT in its current incarnation is a global preference associated with the browser, whereas cookie-based opt-out allows for granular tracker-specific preferences.

While DNT only applies to third party trackers, it’s still possible that a user may want to grant exceptions for third parties on a site they trust for the purposes of enabling desired functionality. For this purpose future browser implementations of DNT may accommodate exception handling – allowing the user to set browser-based DNT exceptions for specific domains.

view demo »

Mozilla was an early champion of DNT and specifically chose the term to avoid the ambiguity of interpretation that plagued cookie-based opt-out mechanisms. Microsoft’s surprising move to make DNT the default in IE10 will force the industry to decide how to interpret this signal. For companies who plan to honor DNT, this will be an opportunity for a new kind of consumer engagement and education by way of a DNT exception request, in which the publisher can request on behalf of the ad providers that the user allow tracking for a trusted site.

Complications of an Integrated Solution

One of the difficulties of integrating DNT and cookie-based preferences is that these two preference mechanisms, while similar in their representation of user intent, are functionally very different. DNT is a global setting in the browser and is communicated along with all http requests, while cookie-based preferences are maintained in the browser cookie storage and can only be accessed by the individual domains who set them.

Any preference mechanism which attempts to recognize both types of preferences will have to deal with collisions – what happens if the user has set a global DNT preference in their browser, but has an opt-in tracking cookie? Collision logic will be necessary to determine which preference is the most accurate signal of user intent. This will be complicated even further if browsers implement domain-based DNT exceptions, wherein users may have a global DNT preference, a domain-based DNT exception, and a cookie-based preference, any of which may conflict.

DNT and Automatic Cookie-based Opt-out

Since a user who has stated a DNT preference most likely does not wanted to be targeted, existing cookie-based systems could also be implemented to respond to DNT detection. TRUSTe has developed a DNT-integrated ad tag solution capable of acknowledging a user’s DNT preference and reflecting it via the transparency afforded by the in-ad icon, using the ad tag script to automatically record the user’s preference by triggering opt-outs for all tracking entities associated with the ad tag.
More on this »

A less invasive approach is for this option to be presented to the user in the ad interstitital messaging, or at the point of interaction with the preference manager (rather than being invoked by the script serving the ad tag). While functionally similar, this approach gives the user control over the execution of the opt-out, rather than letting the system do this automatically.

view demo »

The future of DNT is still uncertain, as the industry struggles to reach an agreement regarding how it should be honored, which its inclusion as a default in IE10 will only reinforce. A parallel approach to this is to find ways to integrate DNT recognition mechanisms into existing preference systems in ways that are both meaningful and graceful, without forgetting its original intent.


Technical Analysis of the IOS6 Tracking Identifiers and Privacy System

The new release for IOS6 contains several improvements in the tracking and privacy systems for advertisers and consumers. The release features are definitely just a starting point in what appears to be a long term strategy to embed privacy controls into the platform.  Below is an analysis of what is included within the system along with some insights from TRUSTe based upon on our learnings from launching the industry’s first comprehensive mobile ad privacy system earlier this year.

From a high level, there are two major components to this system:

  1. A new system for identifying users based upon two identifiers.
  2. A new privacy control system for users to signal privacy preferences.

New IO6 Identifiers

The two identifiers are as follows:

  1. advertisingIdentifier(aI)
    • Per the documentation, this is a read-only, alphanumeric string unique to each device, used for advertising only.
    • The value is constant for all third parties, but the ID can be deleted “if the user erases the device.”
  2. identiferForVendor (idV)
    • Per the documentation, this is a read-only, alphanumeric string that uniquely identifies a device to the app developer.
    • The value is the same for apps that come from the same app developer running on the same device.


  • These IDs are an improvement over UDID and MAC Address usage, as the ID’s are non-permanent, can be deleted and have two different systems that can be used for Advertising and Analytics.
  • Offering a separate developer-only version also provides some origin control around access to the ID.  But, the aI is available to any third party so profiles can be built across different apps.
  • In order to delete these ID’s, users will have to erase their device to remove the ID which is a pretty extreme analog to clearing your cookies from your browser.
  • Cookies also offer the added benefit of including expiration dates so they only be used for short finite periods, whereby these IDs offer no such controls.

New Tracking Controls

There is a new “Limit Ad Tracking” function that allows phone users to control the use of their aI by advertisers.

  1. There is a user-controlled setting under “About” in the Setting menu where a user can turn this on or off.  It is defaulted OFF.
  2. Apple Provided text to consumer:
    1. iOS 6 introduces the Advertising Identifier, a non-permanent, non-personal, device identifier, that advertising networks will use to give you more control over advertisers’ ability to use tracking methods.
    2. If you choose to limit ad tracking, advertising networks using the Advertising Identifier may no longer gather information to serve you targeted ads.
    3. In the future all advertising networks will be required to use the Advertising Identifier.
    4. However, until advertising networks transition to using the Advertising Identifier you may still receive targeted ads from other networks.

How exactly does this work?

There are two new functions:

  1. NSUUID *adid = [[ASIdentifierManager sharedManager] advertisingIdentifier];
  2. BOOL tracking = [ASIdentifierManager sharedManager].advertisingTrackingEnabled;

The first function is to get the aI , and the second one requests the state to check if tracking is enabled (it is ON by default), which is sort of a “DNT” flag concept:

  1. When a user keeps the Limit function in its default OFF position, the aI gets sent to third parties and “TrackingEnabled” returns “YES.”
  2. When a user turn on Limit Ad Tracking, the aI still gets sent and “TrackingEnabled” returns “NO”.


  1. This is definitely an expert function for the most privacy-sensitive users, which TRUSTe applauds Apple for making these controls available as a baseline.  General consumers will not know this function exists without additional education.  As such there is still need for a transparency system by app developers and the ad industry to let users know when their data (identifiers) is being used by third parties.
  2. There is only one option to Limit Ad Tracking and this is a global setting. There needs to a more granular system to allow users to provide exceptions beyond the global option, as some [free] apps are predicated on the fact that they can be ad supported.
  3. This system has some structural similarities to the DNT header feature that is rolling out in most browsers, but with some important gaps like Exception management and some definitions around what behaviors are expected by third parties once the user has set the flag.
  4. It is unclear how this system will work in conjunction with the browser-side DNT deployment that also is rolling out in IO6.
  5. It appears that restricting access to UDID and MAC address will occur at the app approval process vs. platform level, as access to the UDID is still possible when the Limit flag is set.  There are no official positions stated by Apple around MAC address, but one would have to assume this will be eventually limited like the UDID was.


This is an interesting first step for Apple to bring some improvements to its platform, to help advertisers offer targeted advertising in a more privacy-safe manner.  But, there are still some pretty important gaps around user transparency, user education and more granular choices that reflect those users that want free apps from trusted brands.

TRUSTe has been working hard for over a year on its TRUSTed Mobile Ads product with leading app developers and third party ad and data providers to provide users with transparency around their data use and flexible choice options on how they want their information shared with third parties.  This information includes their device ID’s but also other parameters that are used by advertisers.

TRUSTe’s solution offers a very robust set of choice options that include permissions for brands, ad networks and global preference options.  The solution also binds these preferences across both sides of the mobile device to give the user comprehensive control.  Finally, it is a general permission framework which goes beyond just those users that wish to opt-out, but also provides capabilities for user to tell advertisers what they are interested in, which is what a full-featured interest and privacy system should accomodate.

TRUSTe looks forward to evolving its solution alongside this new IOS solution in addition to the DNT program on the browser side.  TRUSTe’s solution is ID-agnostic, so it will automatically work with the new IDs.  The TRUSTe solution will also be compatible with any user-invoked settings via the Limit Ad Tracking settings.


San Francisco Privacy Engineering Meetup – Kickoff

The San Francisco Privacy Engineering group held its first meetup in late August at the TRUSTe’s office in Union Square. Eleven attended keeping it perfectly sized for an intimate discussion around Travis Wellman describing “Spaciousness”, a new model, based on Content Addressing and graphs, for users to store their information in the web. The new model differs from the walled garden approach prevalent in today’s web in how data is addressed and queried. There are Photos of the meetup and Travis has provided slides here to check out.

SF Privacy Engineering brings together those interested in learning about and discussing technical issues surrounding data privacy issues on the web and mobile devices. Specifically, developers who develop or spec out systems/applications to discover personal data transfers, inform first parties of data transfers and manage permissions and preferences for personal data transfers. What is personal data? That is a good subject for an upcoming meetup.

Please keep an eye out for the next meetup on our SF Privacy Engineering home page. We are planning to meet monthly and are now scheduling speakers for the next couple of meetings.

If you would like to present at a meetup, please let us know by submitting suggestions on the meetup home page, or by emailing the organizers (Joseph Green or Jenny).

We look forward to meeting you at the next meetup!

Joe Green
Director, Engineering



Mobile Privacy Consumer App

By Travis Pinnick
User Experience Designer | TRUSTe

TRUSTe is in the process of designing a consumer app that addresses mobile privacy issues. The current app design consists of 3 sections:

  • App Permissions (reflects the current permissions of apps on the user’s device)
  • App Activity (allows the user to see what data calls their apps are making and to whom)
  • Ad Preferences (a mobile version of our Trusted Ads Preference Manager)

The app will probably initially be Android only, as iOS doesn’t allow access to the permission and data transmission information.

Interactive Demo »

Initial Design and Testing

We conducted a small user test of the initial design to assess overall messaging and usability, as well as the perceived usefulness of the app content. Overall users liked the app, and no one had any trouble with the overall purpose or usability of the app.

App Permissions

Most of the users initially deemed the App Permissions section the most valuable (though a couple ended up preferring the App Activity section once they understood its function). Because the App Permissions section shows information that can already be accessed in Android OS settings (though in a different format), I was surprised by it’s perceived value. Maybe this is because consumers like to have similar related functionality in a single app.

App Activity

Users seemed to have the most confusion with the App Activity section (called ‘App History’ during the user test – other names considered were “Data History” and “Data Access”). None of the users was able to articulate what they expected this section to do until after they had seen it, so finding a title that conveys the appropriate meaning to users will be very important. Users were split on their perceived value of this section; more technical users were interested in who their apps were contacting from a privacy perspective, while less technical users were interested in the frequency with which their apps were using data from a resource conservation perspective.

Ad Preferences

As with similar tests of our desktop preference manager, most users had confusion around what it means to set an ad preference. This is probably to be expected, since ‘opting-out’ in the desktop world generally means opting-out of targeting only, and the mobile equivalent has yet to be defined (TRUSTe’s mobile preference management system currently stores a user’s preference for an ad provider to access, but the industry is still debating how the preference will be interpreted).


The purpose of creating a consumer app should be consumer engagement, and it seems evident from the testing that consumers are responding well to this “all in one” multi-component privacy app idea. This design is still a work in progress, and feedback is welcome.


Designing Effective Policies

By Travis Pinnick
User Experience Designer | TRUSTe

Policy policies as initially conceived were meant to afford consumers protection from poor data practices, but have since evolved to serve more as legal protection for the companies collecting the data. As such they are often needlessly complex and intentionally vague.

Therefore there is strong interest, especially among regulators and consumer advocates, to move beyond policies into easily digestible privacy short notices that can be represented in the browser.

Attempts to Summarize Policy Data

An early approach for simplifying the consumption of privacy policies was the Platform for Privacy Preferences (P3P) developed by Lorrie Cranor (Carnegie Mellon CyLab), which enables sites to express their privacy practices in a standard format that can be interpreted by machine-readable user agents. A short notice style of P3P agent which gained attention was the Privacy Nutrition Label by Patrick Gage Kelley (Carnegie Mellon CyLab), which was able to display P3P policies in a graphical matrix which compares the types of data collected to the uses of that data. A similar icon-based approach to visualizing privacy policies called KnowPrivacy was attempted by UC Berkeley graduate students Soltani, Gomez, & Pinnick. Both designs display policy data for a wide number of categories in a grid format.

(left: Kelley’s Nutrition Label; right: KnowPrivacy’s icon policy summary)

In 2010 Mozilla hosted a workshop about the use of privacy icons to communicate only the most important information practices to consumers. Workshop feedback suggested that privacy icons should ONLY be used when the user does NOT have a reasonable expectation regarding how data is used, and that the icons needed to represent a small number of categories in order to be useful in a consumer-based short notice.

The revised versions of the Mozilla icons (started by Aza Raskin and finalized by Alex Fowler and Ben Moskovitz with icon design by Disconnect.me) consisted of four categories: Third Party Use, Sharing with Ad Networks, Sharing with Law Enforcement, and Data Retention. Similar to other attempts at icon designs, each category (except for retention) used 2 icons per category to represent binary states.

What policy summaries mean to users

TRUSTe also conducted a user test of both the Mozilla policy summary icons and a similar set proposed by TRUSTe. Both were well received, but testing suggested the following conclusions:

  • Users don’t seem to have preconceived notions of what categories make the most sense regarding privacy. Every user tested was unable to articulate what categories they expected to see, but also every user agreed that the first categories they were shown met their expectations
  • Icons aren’t important, it’s presentation and finding the appropriate method (and timing) of delivery that’s important. The actual icon used seemed to be of minimal importance compared to user concerns over presentation of the short notice categories. No user was able to articulate clearly what icons they associated with the categories other than the ones shown, and several commented that icons work as long as they make reasonable sense in context

There is clearly a need for policy summary data, but consumers are looking to privacy and policy experts to find the appropriate method of delivery.

New applications for policy summaries

TRUSTe has also been encoding short notice data for client re-use.  We’ve built the capabilty to read this short notice data into our layered privacy policies, adding an extra summary layer to the full policy information.

We’ve also built the capabilty to read this short notice data into a couple of our products where it makes sense for a user to need this information (like at a decision making point regarding a site, app, etc). One example is our Tracker Protection browser client, a tracker blocker plug-in which can also read our policy summary data for a given site, the other is our EU Cookie Consent Manager offering.

Policy data and mobile

Mobile presents more challenges in delivering policy information. Most mobile apps and web apps have just as complicated data collection practices as their desktop counterparts, but with even less screen real estate available to convey this information.

Shown here is our mobile-optimized privacy policy we provide our mobile certification customers. TRUSTe and Privacy Choice also offer free mobile privacy policy generators for app developers.

Mobile also provides another opportunity for the delivery of policy summary data. Unlike normal web browsing, the nature of app usage provides an ideal time in the user experience to provide summary information – at the point of installation.

Shown here is an early version of our policy short notice integrated into our mobile-optimized privacy policy. Also shown is the treatment of android’s permission summary screen, which is an analogous example of delivering summary data at a highly relevant decision-making point in the mobile user experience.

(left: possible TRUSTe mobile short notice; right: Android permission consent)


An effective policy summary should:

  • Provide only the information that is most relevant, like the data collection practices which are invisible to users
  • Support a user’s ability to assess a site or app’s privacy practices at an appropriate time (like a decision making moment such as app download)
  • Support a method of delivery that is informative without being overwhelming or intrusive to the user experience

For all the talk about icons, what really matters is the delivery of easily consumable summary data at the appropriate time when it is most relevant and least intrusive.

For more on this topic see my talk at the PII 2012 creating effective policies panel with Casey Oppenheim (Disconnect.me) and Jim Brock (PrivacyChoice).

Follow me on twitter at @xtratrav.


Transitioning ‘Ad Choices’ to Mobile Apps

By Travis Pinnick
User Experience Designer | TRUSTe

TRUSTe is preparing to launch an ad preferences offering for mobile apps, which essentially takes the foundation of our Trusted Ads tracker database and applies it to the mobile ecosystem. Unlike the Trusted Ads offering, which uses an ad tag that displays the ‘ad choices’ notice and directs users to the Preference Manager, the mobile offering requires an SDK to be embedded by the app publisher. The SDK can be created by either an app publisher, ad network, or ad network aggregator, and functions by storing a user preference which is associated with a revokable device ID, an app ID, and one or more ad network IDs.

View demo of the various implementation options »

Publisher Implementation

The publisher version of the SDK has a number of options regarding how the preference manager mechanism is invoked. The publisher can include an option to set preferences in the app settings, in a first time user alert, or anywhere else the publisher deems appropriate.

Ad Network Implementation

The ‘ad choices’ in-ad tag approach is the only preference manager invocation option for ad network SDKs, since the ad network only has access to in-ad content. Unfortunately the ‘ad choices’ ad tag doesn’t translate well to mobile ads, as it’s about 15 x 15px (the smallest recommended clickable icon size for mobile is 40 x 40px), but anything bigger will dwarf the ad content in an already limited ad unit space.

A potential solution is having the ad tag be a static part of the ad content, and moving the actual invocation mechanism to the frame of the full page ad the user sees after clicking the ad and being taken to an in-app web view. It requires the user to actually open the ad to access the preference manager, but it’s still a viable solution for ad network SDKs, especially considering the lack of alternate locations.

Follow me on twitter at @xtratrav.


It’s Official: Bye-Bye UDID

This weekend’s news of Apple rejecting apps due to their exposing UDID’s to third parties makes official one of the most anticipated events (and not necessarily positively for everyone) for mobile this year.  This leads to two very big questions:

  1. What does this mean to the future of mobile advertising on the IOS platform?
  2. Are Android and other platforms going to follow?

Both of these questions are clearly uncertain at this point, but below are a few points we felt are worth mentioning based on our extensive involvement in this area recently:

  1. UDID was removed from usage as a tracking identifier by Apple because it is permanent and non-deletable.  It incorporated less privacy than web cookies which can be controlled by browsers, usually expire, have a notice and choice system that works with 100% certainty and can be ultimately deleted by privacy-sensitive users.  Whatever subsequent solution is adopted by the industry needs to include these elements.
  2. MAC address is considered by some as an alternative but it does not reflect all of the above criteria. As such, it should be considered only a short term bridge solution and ONLY if there is at least a notice and choice system in place along with it.
  3. This is a tough problem to fix and TRUSTe supports new technology approaches that explores device-id alternatives including OpenUDID from AppsFire and newer device fingerprinting methods, as long as there is a path forward to providing integrated notice/choice frameworks along with some of the stated requirements above.
  4. But, we ultimately believe the final tracking solution needs to be integrated with the privacy system by design.  Privacy systems needs to work with 100% certainty: an opt-out must opt a user out. If an ad system is off by a 1%, that is OK, the user just sees a non-relevant ad or a metric is off a little. But there is not the same tolerance for a privacy system.
  5. We see a role for the DNT header here but not in the near term as there are too many elements that need to retrofit in the stack and there is no common user interface with which to build into. Longer term, we do support Mozilla’s effort and technology demonstration via Boot2Gecko as an example of how this can work.
  6. Ecosystem fragmentation.  Any system that is ultimately chosen must reach critical mass and widespread adoption, else it will not succeed and multiple systems will co-exist creating unnecessary complexity.  The industry needs to reach consensus on that approach and the system needs to be INDEPENDENT from the ad and data companies using it. It should be operated or overseen by a neutral or trusted third party or set of third parties that are not competitive with their ecosystem partners.

From a high level, like most things in privacy technology, there is usually a limitation to the design of the near-term solution, due to what is available technology and deployed footprints of user devices.  As such, a roadmap is usually required to build the higher-integrity solution and in this case it is no different.

It will be a very interesting point forward for sure around this topic. TRUSTe will be releasing its technology solution later in April and we encourage you to take a deep look.  We have been working with ad networks and publishers on thinking through our approach and are excited to put forth our thinking for feedback.

VP Product


EU Cookie Consent Interfaces

By Travis Pinnick
User Experience Designer | TRUSTe

Cookies are a pervasive browser tool used for the purpose of creating stateful interactions (ie. keeping track of your preferences, analyzing site usage, or to show ads tailored to your interests.) This year a new law goes into effect in the European Union requiring user consent before cookies may be placed on a user’s machine. This requirement will have a significant impact on how users experience the internet, both tangible (consumers will potentially be presented with a myriad of consent options) and intangible (if requiring consent affects ad targeting opt-out, it could also affect how the ‘free’ web is monetized).

Cookie Consent Interfaces

Implementing privacy systems like what is described by the EU directive requires strong user experience considerations. We conducted an initial test of two versions of the interface, as well a conceptual assessment of users’ understanding of how cookies work and how users feel about being required to consent to their use.

Modal interface

The first design tested was ‘modal’ – ie. users are shown an alert message the first time they visit a site and are required to state a preference before using the site.

View interactive demo »

Passive interface

The second design tested was ‘passive’ – ie. the alert is fixed at the top of the screen, and though it is persistent until the user states a preference, the user is otherwise able to interact with the site.

View interactive demo »

User Preferences and How They Affect Implementation

Half of the users tested were UK citizens, and half were based in the US. Unsurprisingly the US-based users were universally resistant to a cookie consent requirement, while the UK-based users were more accepting of the idea. Regarding their likelihood to allow cookies when they encountered a consent notice, almost all users stated that they would simply allow cookies for sites they trust, and block them otherwise.

Of the two designs, users preferred the second ‘passive’ version of the consent interface 2 to 1, mostly because they like the idea of being able to interact with the site before making a decision. However users also universally stated the expectation that no cookies should be set during this interaction period until a cookie preference was stated. Users also stated they would be annoyed if cookie inhibitions affected site functionality, which would almost certainly be the case given this implementation.

Next Steps

We will be iterating and further testing this design and will share the results as we get them.  Our goal is to design systems that offer the right educational material and set of choices. This is a work in progress and feedback is encouraged.

Follow me on twitter at @xtratrav.


Mobile Tracking: How it works and why it’s different


The principles of tracking in mobile are fundamentally the same as those used in the online world.  Specifically, you want to have an identifier that works across different domains and if that identifier is short lived, you need to be able to tie it to domain specific identifiers that have greater persistence.  There are just a couple of wrinkles that make things a little more difficult in the world of mobile.

The following blog describes some of the techniques used in mobile and highlights the differences with the online world.  Being able to identify and track users is something under taken by a number of the entities in the delivery of a mobile advertisement.  For the sake of brevity, in this blog it is assumed the advertisement is coming from and the tracking being undertaken by ad networks.  This brevity is not meant to imply that ad networks are using practices not used by others in the delivery chain.  It should also be stated that due to some of the problems consumers have passing their privacy preferences to the various entities in the mobile advertising chain, those entities in general and for the purpose of this paper, ad networks specifically, do not necessarily use consumer identification for behavioral analysis and may limit its use for campaign frequency capping or unique user calculation.

Mobile Web and Applications

The main challenge that mobile ad networks face is that they deliver advertisements to consumers while the consumer is accessing content through both applications and mobile web sites. On mobile devices, applications and web sites are separate domains, in separate sandboxes, utilizing separate identifiers.  That means for the ad network, a single user may look like one or more separate individuals unless the ad network takes steps to try to tie the multiple identities together.  More on that later.

Initially, let’s confine the conversation to mobile applications.  In mobile apps, developers have been using an operating system (OS) identifier to uniquely identify the consumer.  Focusing on the two most popular mobile platforms Android and iOS, the identifiers are the Android_ID and UDID respectively. The Android operating system also allows other system identifiers to be made available.  These include the equipment identifier (IMEI, MEID or ESN depending on the cellular technology) and the subscriber identifier (IMSI from the SIM) if the android device is a phone as well as the WLAN MAC address if the device is WiFi capable (MAC address is also accessible on iOS).  The use of OS based identifiers has been good news for the ad networks since the same value will be passed regardless of which publisher created the application.  In effect, this means the ad network can track the individual across different applications.

This practice and the fact that consumers have little control over it, caused Apple to deprecate UDID in iOS5.  Deprecation doesn’t mean that it isn’t still available for use by developers and ad networks (they still do use it), but it means they should not use it and is an indication that it will be removed (made unavailable) in future versions of iOS very soon.

Instead of UDID, Apple recommends developers create a unique user identifier for their application.  Of course, this doesn’t help the ad networks as each app on a consumer’s mobile device could identify the user differently.  A number of alternate solutions have been proposed to help cross application tracking, while managing the privacy concerns that led to the UDID deprecation by Apple.

Moving the conversation onto mobile web, like online, third party cookies are used by ad networks to identify consumers across different mobile web sites.  Unlike online, the absence of security software on mobile devices means ad networks can count of third party cookies remaining on the device browser when they are able to write them.   Third party cookies are effective on Android devices.  However, on mobile devices consumers typically don’t use other browsers than the one the device shipped with or change the factory set defaults for those browsers.  As a default, Apple ships Safari browser with third party cookies disabled which means that ad networks cannot use them for cross domain tracking Apple devices.  Instead ad networks have developed a variety of techniques to track iphone and ipad users through their browser sessions.

One technique relies on exploiting a security hole in the Safari browser that allows cookies to be written if the ad network writes a form in an invisible iframe to the browser.  This technique was widely reported from the work of Stanford graduate Jonathan Mayer (http://webpolicy.org/2012/02/17/safari-trackers/ ).  Another approach is to collect information disclosed by the browser itself to build up a “fingerprint” for that device.  Depending on the browser, whether javascript is enabled and how heavily the consumer uses the browser, accuracy over 94% is readily achieved (https://panopticlick.eff.org/browser-uniqueness.pdf ).

Another technique is to rely on domain specific persistent identifiers being made available to the ad network and tying that identifier with a transient cross domain identifier.  The persistent identifier is typically passed to the ad network as a UID in the ad request and is related (one to one mapping) to the first party cookie.  The transient binding could be the IP address that typically remains the same during a consumer’s browsing sessions or an identifier passed by the mobile carrier’s WAP gateway (all browsing sessions pass through a network element called the WAP gateway).  Depending on the carrier and the relationship between the carrier and the publisher(s), the gateway identifier may be long lived (even always the same in the extreme case) or short lived.  Obviously this technique is only effective for identifying a user across sites that they regularly visit and it takes time for an ad network to build up their view.  This technique may be used with the device fingerprint technique to either increase the accuracy of the fingerprint or reduce the number of times a fingerprint has to be calculated.  This technique is illustrated in the following diagram.


Tying Mobile Web and Application identities together

As the preceding sections have already stated, mobile web and application are separate domains, with separate identifiers.  From the ad network’s point of view, this means one individual, using one device can look like two different people.  From a consumer’s point of view, this means that any opt-out (of tracking and behavioral analysis) preference expressed in one domain (e.g. opt-out cookie or do not track preference in the browser), may not be respected in the other domain simply because the ad network doesn’t recognize it as the same individual.  This gets confusing for the consumer as they may not understand the interplay between mobile web and mobile apps as they often bounce between each other.

The most common method to tie identifiers across application and mobile web domain only works when the user clicks on an ad within an application.  The click through URL is unique to the user, containing a parameter that has a one to one mapping with the application domain user identifier.  When the consumer is redirected to the advertiser’s mobile web site, the ad network is able to tie the application domain identifier passed in the click through URL with the web domain identifier(s).   Ad networks may use a myriad of techniques to map in the alternate direction (a key use case for ad networks is when a consumer clicks on a mobile web ad for a new application such as the latest, coolest game and the ad network wants to see if the ad click resulted in the game being downloaded).  These techniques rely on the ad network having access to shared storage between the two domains which is easier on some OS compared to others.

Privacy by Design

It is hard to talk about targeting without privacy. The inventive solutions developed to overcome default factory settings and application sandboxes indicates the industry needs to rethink its approach to privacy and the persistent identifiers that enable tracking.  The consumer should be faced with a simple choice of whether they want content and advertisements delivered that are tailored to their interests and be able to control it.  That control should extend across the browser and application domains.  It should be easy for them to find out who has what information about them.  By taking such a fundamental approach to privacy management and tying it to a revocable identifier, the industry will win by having a reliable identifier for those consumers happy to be tracked and consumer will win by finally having true privacy transparency, choice and control.


Top 10 Challenges in Mobile Privacy

Top 10 challenges in Mobile Privacy

Every week we hear about a new privacy scandal with a mobile company involved. Google, Apple, Pandora, Carrier IQ, Path and Hipster are only a few examples. So who is next? And why anybody should be next? Why is it so difficult for companies to achieve privacy-by-design on mobile? This blog outlines some of the reasons.


Apps are now tracking.

Unlike in the old desktop word where a web browser is a “single point of data leakage,” in mobile, apps are meant to be “connected” by design and are commonly supported by advertising. As a result, almost all apps collect and transfer user data in a numerous ways.

Best practice: App developers should seek independent third-party verification of their apps if they want to increase consumer trust and lower regulatory risks.


Advertisers provide in-app SDKs that Publishers cannot control.

An Ad Network SDK incorporated into a mobile app can do everything the app can do. This makes it much tougher for the app developers to provide consumers with full transparency. They cannot control in-app SDK activity nor even disclose it properly in the app privacy policy.

Best practice: App developers should consider working only with the SDKs of certified third-parties whose data collection and usage practices have been independently verified.


The mobile ecosystem is much more diverse.

It is not just regular apps who collect user data. There are also ad networks, ad aggregators, mobile carriers, platform vendors, ad network in-app SDKs, and data aggregators – all technically able to access a device in a multitude of uncommon and technically diverse ways.

Best practice: Ad Networks and app developers should collect and honor consumer privacy preferences in a way that is uniform and consistent across multiple ecosystem players.


There are several different platforms.

Apple iOS, Google Android, Blackberry and Windows 7 – all have a sizable market share, yet different architecture, privacy and permissions systems. That makes establishing uniform privacy guidelines very difficult.

Best practice: The companies who work with different mobile platforms should adequately describe the privacy-related peculiarities of these platforms in their privacy policies, which they should display in a consistent format.


There are no reliable cross-platform identifiers.

Mobile opt-out cookies can no longer be relied upon for an opt-out mechanism when browsers like Safari disable them by default, and after Apple announced the deprecation of UDID identifier the industry has considered using all sorts of other identifiers: MAC Address, IMEI equipment identifier, IMSI subscriber identifier, device fingerprints (BlueCava’s, 41st Parameter’s, AdTruth’s), and custom identifiers (AppsFire’s OpenUDID, OpenFeint OFUID single-sign on, and Mobclix’s ODIN.)

Best practice: Developers and Ad Networks should consider adopting a uniform and private-by-design identifier that would allow consumers to express an opt-out or opt-in preference based on their jurisdiction. (US vs EU)


Tracking now is happening in both app and web.

When a consumer opts-out from tracking by a particular company, he or she usually expects to opt-out from it across both app and web. However, this is often impossible because the browser cannot read system identifiers such as UDID or MAC Address, and applications cannot read browser cookies that are not from their domain.

Best practice: Companies should rely on a user identification mechanism that would be accessible from both the regular mobile apps and browser web sites.


Mobile web Publishers are often involved into the ad chain.

Because of smaller bandwidth, lower Javascript processing power, and limited third-party cookies support, mobile web Publishers often make ad calls directly from their servers and then serve web content with ads and third-party cookies incorporated in it. However, this makes the third-party cookies technically look like first-party ones for the browser.

Best practice: Mobile web publishers should thoroughly examine the third-parties they work with to vet that the privacy practices of those third parties are consistent with the practices the publisher describes in their policies.


Applications transmit user information in ad calls.

Mobile Ad Networks normally require Publisher apps to transmit unique identifiers, such as UDID or Android ID, in an ad call. Even if UDID is the only thing that an Ad Network receives from the apps, it can still build an “anonymous” profile containing the information about what apps a person uses, how often, at what time, for how long and from what IP addresses. In practice, app developers pass much more data. Transferring zip code, age, gender is common practice now.

Best practice: Publishers should list the types of data that they transfer to the Ad Networks and Data companies in their privacy policies.


Mobile phones know users’ location.

Regardless of whether users enable or disable precise location services, the carrier will still know users’ approximate location and wireless access points’ IP addresses. An unscrupulous app can ask users for access to their location over and over again until they succumb, which is when compliant apps may inadvertently get access to it too and assume that users are ok with them using it.

Best practice: Applications should disclose whether they use location services, and provide information on how to disable precise location services indicting whether it can be done at the app level or must be done at the device level.


The size of mobile screens makes complicates disclosure.

Screen size presents challenges for companies to effectively communicate their privacy practices. Most apps either do not have a privacy policy or link to a long privacy policy hosted on a website that is difficult to navigate and read on a small screen.

Best practice: Companies should create a mobile optimized versions of their privacy policies so it would be easy for users to read and get the information they are looking for.


The proliferation of mobile devices quadrupled the privacy challenges previously attributable to desktops. Every week companies from Google to Path, from Carrier IQ to Pandora find themselves in the middle of a new privacy debate. So who is next? When Path was recently caught uploading users’ address books to its servers, its CEO Dave Morin noted in his blog that it was the “best industry practice.”  As controversial as that comment was, he was right – it is the “best industry practice,” along with many other practices established without privacy in mind. It is time for the app developers, ad networks and platform vendors to wake up. Unless the companies take consumer privacy seriously and address it with proper disclosures and control mechanisms, the frequency of these scandals will only increase over time.

Older posts «

» Newer posts