Geo-IP location targeting:
When is consent required?

Posted on January 23, 2012 by Jim Brock

In AdExchanger, the CEO of location-data company, PlaceIQ, explains how IP addresses are used to determine a user’s location, and how this practice is becoming increasingly precise:

Starting at the most granular, or hyper‑local, is a smartphone, your typical Android or iPhone. You have a hyper‑local request on that phone. This is the pop-up which says, “Will you share your location?” That can be incredibly granular, so you can get down to city blocks and sometimes better. Sometimes it’s not so good, but really, that’s the best data for us to use. That can come from the mobile web as well as a mobile app.

Also, from here, zip code can be captured in different ways. For example, triangulation, takes the hyper‑local request and changes it to zip code. Also, if a mobile ad impression comes in and it has an IP that lets me know that they’re on wireless, I can take the IP address of that wireless and turn that into location using Geo IP – which brings us to the second piece of location-based advertising – online location. This is, historically, Geo IP, which was DMA-based and has slowly gotten better. Some people are claiming zip code [level accuracy], some people are claiming better.

A few privacy and policy implications:

  • Apple and Android have already established user expectations about consent. Location-based services in the operating system provide very precise location information, but only through a user-consent framework built-in to the OS. This creates a baseline user expectation about consent for precise location targeting.
  • Zip-code should be the consent threshold. IP addresses can provide zip code location, even without an independent user consent (this has been in use for some time on traditional websites and ads). As Geo-IP targeting improves beyond zip-code granularity (based on IP-address alone), users will rightly expect to provide consent before the collection and use of that data. This is consistent with self-regulatory principles such as the NAI code, which deems “precise real time geographic location” as sensitive information requiring prior user consent. To avoid ambiguity, self-regulatory organizations should make the definition perfectly clear in their written guidelines.
  • “Do Not Track” must address location, too. For the purposes of Do-Not-Track, does Geo-IP location targeting need to be turned off if a user has made the election? Given the consent framework already in place, there’s little doubt that this is what the average user would expect.
Posted in Do Not Track, mobile | 1 Comment

Developers: Check yourself before you wreck yourself (on privacy)

Posted on January 20, 2012 by Jim Brock

If you’re developing mobile apps, take a few minutes to check out this talk by Morgan Reed (ACT) at the recent MoDev conference.

Get started here.

Posted in Uncategorized | Leave a comment

Do Not Track: Advice for early adopters

Posted on December 28, 2011 by Jim Brock

While the W3C working group continues to hammer out specifications for the Do Not Track header, it’s good to see a few tracking companies already moving ahead with their own implementations.

Here are two key points for companies adopting the DNT header in their choice framework.

  1. Confirm it in your privacy policy. Otherwise, it doesn’t mean much. While leading companies like BlueKai have said publicly that they honor the DNT header, it’s hard to give that much credit until they literally confirm it in their privacy policy. (That’s also when we will indicate DNT compliance in the PrivacyChoice Tracker List.)
  2. Explain what you do differently when you see the header. As an example, here’s what AdOcean recently added to their policy:

If DNT is turned on then the following scenarios may happen: a) you already have an AdOcean cookie stored in your browser – in this case this cookie will never be read or written again; b) you don’t have an AdOcean cookie yet in your browser – in this case it will not be created in the future either.

In most cases, companies will treat the presence of the DNT header as equivalent to an opt-out cookie, so the same explanation can easily apply.

Posted in Best Practices, Do Not Track, Opt Out Cookies | 1 Comment

So this is what a privacy audit looks like

Posted on December 22, 2011 by Jim Brock

2011 may be remembered as the year of the Big Privacy Audit, with the Federal Trade Commission using consent decree powers to commit both Facebook and Google to decades of regular third-party oversight and reporting on privacy. You may not have realized that a very important Facebook audit was already underway, initiated by the Irish Data Protection Commission. Now with the publication of specific requirements from this process (painstakingly cataloged at Techcrunch), we can start to see how privacy audits will work and what it means for users world-wide.

Of the 45 different changes required by the Irish DPC in the audit report, here are a few that I found most interesting:

Limit data collection from social plugins, restrict access to this data, and delete it on schedule, though social plugin data is not currently used in ad targeting – Immediately

Switch from retaining ad-click data indefinitely to a 2 year retention period – Review in July 2012

Anonymize data about a user’s searches on Facebook with 6 months

Anonymize all ad click data after 2 years

Roll out updated granular data permissions dialog box to all applications – End of February 2012, review in July 2012

Educate users on the importance of reading app privacy policies, possibly increase size of links to report an app or view app its privacy policy in the data permissions dialog box – End of February 2012

Implement a tool that determines if links to app privacy policies are live. First, Facebook will asses the technical feasibility of such as tool – Review progress towards implementation in July 2012

Improve system for disclosing data to law enforcement by requiring validation from a senior officer and a full explanation for why the data is needed – Commence in January 2012, review in July 2012

Many of these requirements are more substantive than would be possible under the FTC’s consent decree with Facebook, which is limited (more or less) to ensuring that Facebook doesn’t change its policies in the future without appropriate notice and consent. While Irish authorities can’t bind Facebook to these changes world-wide, as a practical matter it’s hard to see Facebook maintaining significantly distinct versions of the service based on local privacy rules (except perhaps where highly valuable data would be lost). In this way, more stringent requirements from Europe may end up leading the way when it comes to defining best privacy practices and oversight.

Posted in Best Practices, Facebook, Oversight, Social Network Privacy | 2 Comments

The FTC’s Seven Opt-out Rules:
A must-read for tracking companies

Posted on December 21, 2011 by Jim Brock

The Federal Trade Commission’s recently finalized settlement with ScanScout is ostensibly about the use of Flash cookies, which led to the enforcement action. But as is often the case, the consent decree also outlines requirements that provide all companies, not just ScanScout, with guidance on how the FTC thinks the opt-out process should work for behavioral targeting.

If your company tracks users across websites for marketing purposes, how does your notice-and-choice process stack up to the FTC’s Seven Opt-out Rules?

  1. You must provide a link to your opt-out from your homepage, worded like this: “We collect information about your activities on certain websites to send you targeted ads. To opt out of our targeted advertisements click here.” This can lead to a page with more details, but the user must be able then to complete the process in no more than one additional click.
  2. Your opt-out must operate to prevent collection of any data “that can be associated with a particular user,” which would include cookies and IP addresses, except for expressly permitted purposes (see below). Note: the FTC is talking here about the collection of data, not just the targeting of ads.
  3. Your opt-out must contain specific points of disclosure:
    1. You collect information about users’ activities across websites to target ads,
    2. If the user opts out, you won’t collect this information for ad targeting purposes,
    3. The user’s current status, read from their cookies (“opted out” or “not opted out”), and
    4. The circumstances that can disable the opt-out (“e.g., use of a different browser, use of a different device, or deletion of cookies”).
  4. Your opt-out must prevent use of “previously collected data,” as to that user or device. This can be accomplished by replacing any unique cookie identifier with a generic, non-unique indicator (cookie text = “opt out”) or a new unique ID that cannot be matched with the ID in place before the opt-out.
  5. Your opt-out must prevent your processes from redirecting data to other parties. This means that if you have other companies piggybacking on your tags, that must be turned off as to opted-out users.
  6. For each individual opted-out user, you must limit how you use data that you continue to collect. The permitted uses are limited to:
    1. Frequency capping (how many times the user has seen or responded to an ad),
    2. Fraud prevention (not defined, but this could include means to spot fraudulent clicks),
    3. Providing a service requested by the user (although it’s hard to think of an example), or
    4. Verifying the user’s age (for age-restricted ads)
  7. You must limit the period of retention of any data about opted-out users to “no longer than reasonably necessary” for the permitted purpose (and no longer than 24 hours or the current browsing session, in the case of the user’s age). This may mean a different length of data retention depending on the permitted purpose (for example, frequency capping data couldn’t be retained longer than the life of the campaign).
Posted in Best Practices, Opt Out Cookies | 1 Comment

Rules of the Road: Best Privacy Practices for Developers from the CDT and FPF

Posted on December 21, 2011 by Jim Brock

Mind the lines

The Center for Democracy and Technology and the Future of Privacy Forum have published an important new resource that brings together the best practical privacy advice for mobile developers. This is an important step forward in establishing widely accepted “rules of the road”

Get it here (PDF): Best Practices for Mobile Application Developers

Here’s their key advice for developers (from the summary):

  • Be completely transparent about how you are using or transmitting user data
  • Don’t access more data than you need, and get rid of old data
  • Give your users control over uses of data that users might not expect
  • User reasonable and up-to-date security protocols to safeguard data
  • As the app developer, you need to be responsible for thinking about privacy, and taking privacy into consideration during the various stages of your app life cycle

I’m pleased to have had the chance to provide input on drafts, and will work to incorporate these principles even further into the resources we provide for developers. Reaching developers with the message of best privacy practices — and making it as simple as possible to adopt them — is the next challenge. This won’t happen without the support of the major app distribution and advertising platforms. Here’s hoping we see this in 2012!

Visit our mobile privacy resource center (and make your own policy) >>

Posted in App Stores and Markets, Best Practices, mobile | Leave a comment

Yet another (better) definition of sensitive boundaries for ad targeting

Posted on December 14, 2011 by Jim Brock

Photo by Kevin Collins

The concept of “sensitive” categories pervades the policy structures governing online ad targeting; there is a sense that certain online activities are “out of bounds” when it comes to behavioral advertising. Both the Network Advertising Initiative and the Digital Advertising Alliance have defined “sensitive” categories that participants must avoid when targeting ads.

Google, which operates the world’s biggest ad network, recently established a third standard, and it’s one that the industry should embrace.

Google’s applies their rule to advertisers who want to use the Google network for “remarketing.” This is the practice of reaching users who have previously your site in order to woo them back. A site using remarketing allows Google to tag the user when they visit the site, and Google uses that same tag to find that list of users later to show them ads on other sites they visit. The use of sensitive information in this way could cause greater concern than typical anonymous network advertising, since the website doing the remarketing may have stored user behaviors and characteristics tied to personal identity information.

Here’s how how Google defines the boundary around “sensitive” data that cannot be used in remarketing campaigns on their network:

Company may not use User Lists to select or target advertisements (i) based on past or current activity by Users on adult or gambling sites, government agency sites, or sites directed at children under the age of 13 years or (ii) based on other inferred or actual sensitive information (including without limitation, health or medical history or information, financial status or other detailed information pertaining to a person’s finances, racial or ethnic origins, religious beliefs or other beliefs of a similar nature, the commission or alleged commission of any crime, political opinions or beliefs, trade union membership, or sexual behavior or orientation).

Google also provides great detail and examples about these categories (but it isn’t stated whether these also are the boundaries applied to Google’s direct targeting on AdSense, which have a more limited definition).

Google’s definition above is not only more expansive than either the NAI’s or the DAA’s, it also contains a critical difference: it applies not just to actual status of the user, but also to inferred classifications. For example, you might infer that someone probably has high-blood pressure because they researched that condition on a medical website. By contrast, the NAI and DAA standards, while differing from each other in important ways, talk only about “precise” health information, as if it might need to come from direct medical records to be deemed off-limits. Yet I’d be surprised if most consumers would view such “inferred” health classifications with less concern than “actual” ones.

The definition of “sensitive” ad targeting goes to the heart of consumer fears about data collection — that sensitive profile data might end up being used for harmful purposes, like insurance eligibility. The self-regulatory effort would be more credible if the various standards for sensitive boundaries were unified and strengthened along the lines of Google’s definition. Tighter restrictions on sensitive categories no doubt would destroy some ad targeting revenue, but the benefits to consumer peace of mind would be well worth it.

Posted in Best Practices, DAA, Google, NAI, Self-Regulation | 5 Comments

Windows Store has strong privacy disclosure requirements for app developers

Posted on December 7, 2011 by Jim Brock

Windows Store, which is Microsoft’s upcoming app store for Windows 8 applications, contains one of the strongest app privacy policy that we have seen so far in compiling our comprehensive guide to app-store privacy requirements. Microsoft’s Developer Agreement says:

If your app enables access to and the use of any Internet-based services, or otherwise collects or transmits any user’s personal information, you must maintain a privacy policy. You are responsible for informing customers of your privacy policy (including by submitting that policy to us for display to customers). Your privacy policy must (i) comply with applicable laws and regulations, (ii) inform users of the information collected by your app and how that information is used, stored, secured and disclosed, and (iii) describe the controls that users have over the use and sharing of their information, and how they may access their information. If your app uses the geolocation, texting/SMS, webcam or microphone capabilities, you must also provide access to your privacy policy in the app’s settings as displayed in the Windows settings charm.

What’s good about this:

  • A privacy policy is required for any Internet-based service, even if personal information is not collected;
  • It specifies when access to the privacy policy must be provided from within the application itself (notably, this applies to geolocation features); and
  • It requires submission of the policy to Microsoft, presumably for the purpose of displaying it in Microsoft-controlled Windows Store listings.

Microsoft deserves credit for upping the bar on privacy requirements, and here’s hoping that they will also make privacy policies directly available in the store, and enforce the requirement as part of the onboarding process for new apps. As discussed in a prior post about Apple’s App Store, the leading players in app distribution still have a ways to go before privacy policies can be consistently and easily found by users.

Make your privacy policy now >>

Posted in App Stores and Markets, Best Practices, Microsoft, Privacy Policies | Leave a comment

Can Do-Not-Track users be convinced to allow anonymous, accountable tracking?

Posted on December 7, 2011 by Jim Brock

From a survey on privacychoice.org of users with Do Not Track already enabled in their browser.

Posted in Do Not Track | 1 Comment

Alert: New behavioral targeting guidance for Canada (updated 12-13-11)

Posted on December 6, 2011 by Jim Brock

[Post updated 12-13-11 based on briefing provided by Canadian Privacy Officials to the Future of Privacy Forum]
If your site or app reaches Canadian users and you show targeted advertising, consider the latest regulatory guidance from the Canadian Privacy Commissioner. In a nutshell, it says that for typical behavioral targeting, you don’t need to obtain prior consent (providing an opt-out mechanism is sufficient) so long as you meet certain conditions:

  • You must make your users aware of the practice in a way that is “clear,” “understandable” and “obvious.” Approaches may include “a variety of communication methods, such as online banners, layered approaches, and interactive tools,” but mere references in a privacy policy are not sufficient. No guidance is provided as to whether ad-icons from the Digital Advertising Alliance are sufficiently “obvious.” [On FPF call, officials expressed skepticism about whether users understand the meaning of the icon sufficiently for this program to suffice.]
  • The notice needs to identify “the various parties involved in online behavioural advertising,” which presumably is the list of tracking companies in operation on your site.
  • An opt-out must be provided “ideally” at or before the time information is collected; for retargeting campaigns, this could read to mean that the opt-out must be offered at the first contact with the user, as opposed to when the data is applied to show the retargeting ad. [On call, officials reiterated the need to provide notice and choice before data collection begins, stating that this may not be met through the ad-icon approach, but that the Do Not Track browser approach is promising in this respect.]
  • The opt-out must be “persistent,” although it is not clear whether than means it must survive the deletion of cookies (which is not generally supported by prevailing opt-out frameworks). [On call, officials stated that the choice must survive the deletion of cookies, but did not endorse a specific approach like DNT headers.]
  • It isn’t expressly stated whether the opt-out needs to terminate the collection of data or if it is sufficient for the opt-out to deter the use of data for ad targeting, which has been an area of controversy. However, the context strongly implies that the opt-out needs to terminate data collection and not just use. [On call, comments supported notion that opt-outs must end collection not just targeting.]
  • Use of device fingerprinting is disfavored, to the extent that users have “no viable possibility for them to exert control over the technology used.” It is not expressly stated whether the existence of a device-fingerprint opt-out (which works with the same identifier) would be permitted.
  • Behavioral targeting should not be used at all on children, so kid-focused sites should avoid the practice entirely.
Posted in Uncategorized | 3 Comments