• Your own published privacy policy should clearly explain how you handle personally identifiable data (like name, phone number and email address) in the following ways:
  • Personal data won’t be conveyed to third-parties without the user’s permission. It’s typical and appropriate to make this statement in general terms, and follow it with a set of exceptions (like government requests). But if the policy is open ended (“exceptions include …”) without any limitation, we can’t score it as protective.
  • A user’s request to delete personal data will be honored. Of course, there may be exceptions for transactional information or data relating to pending disputes, which we recognize in the privacyscore. But those shouldn’t be stated in a way that undermines the principle.
  • Notice will be provided in the case of disclosure in legal process or government requests, where legally allowed. “Where legally allowed” is a key qualifier that protects you and wouldn’t surprise most users.
  • If service providers have access to personal data, their use should be restricted and confidential. This is a matter of reviewing contracts to confirm that confidentiality has been assured.
• All trackers seen on your site should meet the following requirements, on the face of their privacy policies:
  • Personal data is not be collected or use, or is always separated from behavioral data. We weight this factor heavily, given reasonable user expectation that tracking behavior across sites will not be individually identifiable.
  • Boundaries are recognized in areas like health conditions and financial data. Currently, nearly any statement establishing sensitive boundaries suffices for scoring; although such statements do vary in strength. The strongest (and best) prevailing expression of boundaries comes from the rules for Google’s Certified Ad Network program (read about it here). Over time, we expect to provide more granular scoring to take into account significant differences in boundary coverage.
  • Choice is provided as to whether data will be collected or applied for the purpose of ad targeting. Currently, any choice mechanism suffices for a full score on this point, even though obviously in some cases the choice offered only affects ad selection and not data collection. This is another area for improvement to the scoring.
  • Accountability is provided by industry or other independent organizations. Currently, we award points for regular compliance reviews of internal processes by industry organizations (such as the Network Advertising Initiative), as well as ongoing external monitoring of practices by industry organizations (such as the Digital Advertising Alliance). Soon we will also include other independent privacy audits and compliance efforts.

If you have trackers on your site that don’t meet these criteria, we suggest that you reach out to them to find out why. If you’re not satisfied, remove their tags from your site. If they are being brought to the party from an ad exchange or optimizer, ask the intermediary what privacy qualifications they are requiring of their participants. (Feel free to send them our way, too, particularly if they believe we’ve scored them incorrectly.)

Learn more in our FAQ

Check out privacyscores

The road ahead - Photo: M. Brenn

We launched privacyscore.com on Monday. The amount of positive press attention was gratifying (New York Times, Wired.com, ZDNet, Huffington Post, Time.com, The Telegraph, Daily Mail and others ), as was the number of visits and downloads.

Here’s what we learned and what we’re doing about it:

1. People really like privacyscores. Our hunch was dead-on that web users would appreciate the simplicity of a single number as a measure of privacy risk. This is not to say that a privacyscore is all you need to manage your own privacy across sites; but we’re sure now that there is no better starting point.
2. privacyscores are already motivating better practices. We were overwhelmed with the number of publishers and tracking companies wanting to engage about their privacyscore. We heard again and again from the privacy champions within these companies that the privacyscore framework and visibility gives them ammunition to make improvements in their policies and practices.
3. People don’t understand Facebook’s privacyscore(s). We anticipated confusion around Facebook’s privacyscoring, but we didn’t address it strongly enough. (The point is: Facebook has one privacyscore for Timeline and newsfeed, and quite different privacyscores for each app page on Facebook.) People are so used to hearing about Facebook’s privacy challenges (which mostly involve poor usability and notice), that they have trouble with our our framework, which focuses on the terms of the privacy policies itself. We’re working on a redesign that will make this much easier to understand, and we will be publishing research about how privacy risk differs across the different realms of Facebook.
4. Data concentration matters, too. In the feedback on Facebook, Google and other large providers, we also heard that even when privacy risk is relatively low, the sheer concentration of data into the hands of a single provider creates privacy concern for users. We have some interesting developments in the works on this, and it may become a key element of our Privacy Analytics framework.
5. We need to support more browsers. We launched with privacyscore addons for Firefox and Chrome (and have seen roughly equivalent download numbers for each). Top requests from users include coverage for Safari and Internet Explorer. Both of those are now in the works, as is a bookmarklet which you can use in just about any browser to check scores for the site you’re on.
6. Customization of privacyscores is not as important as we thought. We designed the privacyscore system to allow us to enable users to change the weighting of privacyscore factors. We still plan to implement this down the road, but the vast majority of users seem to be okay with our default weights, so we are deprioritizing this change.
7. Our algorithm must continue to evolve. In the course of the week we identified and implemented several additional algorithmic improvements that will make privacyscores an even better measure of privacy risk. Of course,  we also found errors in our formulas that we’re correcting in a new push over the weekend. Scores may move a bit in individual cases, but we aren’t projecting major moves overall.

As always, we thrive on comments and input. Leave them here or email us directly: contact@privacychoice.org.

Opt-out here
http://privacychoice.org/mobile/optout

This mobile-ready page gathers and executes opt-outs for a handful of popular mobile tracking companies, including Google and Apple.

App developers should provide this information through simple and short disclosures or icons that are easy to find and understand on the small screen of a mobile device. Parents should be able to learn what information an app collects, how the information will be used, and with whom the information will be shared. App developers also should alert parents if the app connects with any social media, or allows targeted advertising to occur through the app. Third parties that collect user information through apps also should disclose their privacy practices, whether through a link on the app promotion page, the developers’ disclosures, or another easily accessible method.

The quickest, easiest and cheapest way to act now on the FTC’s guidance is to create a mobile privacy policy with our free Policymaker tool: the summary statements are short, identified by icons, and are layered with the more detailed disclosure. Third-party data collection (such as for ads and analytics) is built into the policy, so you don’t have to worry about finding the right links and embedding opt-outs; we take care of that for you.

I’m also hoping that Apple and Google are tuning into the FTC’s urging that they do much more to enforce their privacy-policy requirements:

The app stores also should do more to help parents and kids. The two major app stores provide the basic architecture for communicating information about the kids apps they offer, such as pricing and category information. However, the app stores should provide a more consistent way for developers to display information regarding their app’s data collection practices and interactive features. For example, app stores could provide a designated space for developers to disclose this information. The app stores also could provide standardized icons to signal features, such as a connection with social media services. Although the app store developer agreements require developers to disclose the information their apps collect, the app stores do not appear to enforce these requirements. This lack of enforcement provides little incentive to app developers to provide such disclosures and leaves parents without the information they need. As gatekeepers of the app marketplace, the app stores should do more. This recommendation applies not just to Apple and Google, but also to other companies that provide a marketplace for kids mobile apps.

I’ve written before about the disfunctional privacy framework of the app marketplaces. With the talent and resources available to these companies, there’s no reason that we can’t quickly have a framework that works much better for users (kids and grownups!) and meets the FTC challenge. It’s time to get on with it.

Apps that collect or transmit a user’s contact data without their prior permission are in violation of our guidelines. We’re working to make this even better for our customers, and as we have done with location services, any app wishing to access contact data will require explicit user approval in a future software release.

If your app accesses contact or other personal information from the device, you should already have been asking for permission to do so. If you haven’t been, be sure you are now.  And it goes without saying that your privacy policy should be very clear about listing exactly what you pull in, whether you anonymize it (see below) and how long you keep it.

Here are two questions Apple hasn’t yet answered:

1. What transmission and server side privacy protections should be followed once the user has provided consent? At a minimum, these would include the use of SSL for the actual transmission of contact information to the server, and the hashing of the information. When done right, this doesn’t have to impair functionality like finding common connections with other users of your app. This fine article about hashing explains it very well (and is also linked in our resource center.)
2. If you already have collected data without consent, do you need to delete it? As of this post, Apple hasn’t provided guidance on this question. It would be most conservative to delete the information and request new consent from the user to upload it again; in this process you could ensure that you conform with SSL and hashing practices. I can hear a practical argument that there’s no privacy disadvantage to instead immediately hashing all contact information on hand, and then provide the choice to the user and immediately delete the hashed version if they so choose.

privacyscore details - click for full view

Today we launched our most important and ambitious project: privacyscore.com. In it we are applying analytic methods to measure privacy risk across more than a thousand websites. We’re doing it to help solve a big problem for web users: how to understand the privacy risks they take every day online. Through privacyscores we’re also giving publishers and advertising companies important insights (and incentives) that they need to manage their own privacy practices, which in turn will benefit the people they serve. More than anything we’ve done before, privacyscore embodies the PrivacyChoice mission to “make privacy easier.”

What is a privacyscore?

A privacyscore for a website is an estimate, on a scale of 0 (worst) to 100 (best), of the privacy risk associated with giving the site your personal and behavioral information.

“Privacy risk” means the chance that your data may be used in ways you don’t expect. A privacyscore measures this risk through nine different factors, each weighted based on importance. The factors include how the site promises to protect personal user data, as well as the privacy qualifications of tracking companies who collect data, weighted based on their share of the tracking events on the site. (The factors and default weights are explained in detail on each privacyscore report and in the privacyscore FAQ.) At launch, the average privacyscore across all sites monitored was 71 of 100 possible points; within site categories, average privacyscores range from 65 for shopping sites to 80 for travel sites. We’re tracking these numbers on a daily basis; if we succeed, they will move up and to the right.

What does it mean for web users?

It’s obvious that long-form privacy policies have largely failed in informing web users about privacy risk. Convinced that there has to be a better way, we’ve experimented with icons and we’ve tested short summaries, each of which add value in their own ways. But again and again users have told us: There’s nothing simpler than a number. When you think of privacy risk in terms of numbers, you can know instantly if there’s cause for concern. With numbers, it’s much easier to compare privacy risks between different sites. When you use privacyscore through a browser add-on, privacy awareness becomes part of your regular web routine. You can identify risks before you provide personal data. You can also know at a glance whether a site is being responsible in how it shares data with advertisers. Privacyscore becomes your online privacy guide.

With privacyscores, web users also have the opportunity to contribute. The heart of our system is the mapping we maintain between web sites and the ecosystem of ad and data companies collecting cross-site data. When add-on users check the box to share tracking activity with our system, they extend the breadth and depth of our coverage. Soon we will also open up the tools we have built for the rapid review and classification of website privacy policies; privacy fans (and websites themselves, we expect) will help us scale privacyscore coverage to tens of thousands of sites.

What does it mean for websites and advertisers?

The launch of privacyscores marks the beginning of a new discipline we call “Privacy Analytics,” applying quantitative techniques to the measurement and management of privacy risk. For publishers and advertisers, this means for the first time they have metrics to guide the decisions they make affecting user privacy. We’re inviting publishers to join our Privacy Analytics beta to have access to a set of more advanced measurements and tools to manage privacy risk on their own websites.

Based on early feedback, web publishers are ready. In previewing privacyscores with websites and tracking companies, almost immediately they ask, “How can I make my privacyscore higher?” and “What are the privacyscores of my competitors?” You can’t manage what you can’t measure. With privacyscores web sites and ad companies have the metrics they need to manage privacy risk on behalf of their users.

Most publishers have been surprised by our estimate of privacy risk on their sites. Few sites monitor which third parties are collecting data, and even fewer focus on the privacy qualifications of those companies. The privacyscore report brings these facts into clear focus, but with more than just a list of trackers seen. By weighting the privacyscore based on prevalence, and accounting for differences in privacy qualifications among companies, publishers get a representative assessment of privacy risk and clear priorities for improvement.

What are the limitations of privacyscores?

A privacyscore is by no means a perfect measurement of privacy risk. Users have varied expectations about privacy. While our factors capture well-known risk factors, not everyone will agree with our picks, nor with our default weightings. We can’t account for the risk that actual data practices may not comply with stated privacy policies. Our framework also doesn’t reflect the risks in consensual information sharing (like in social networks) where notices may not always be complete nor well understood. Nor does our framework as yet comprehend the unique ways in which different types of tracking companies use and share data amongst each other. These shortcomings are part of the work ahead of us.

Where do we go from here?

We’re actively gathering feedback from our users. Our first deliverable based on that feedback is to activate privacyscore customization, so users can provide their own weights to apply throughout the experience. Privacyscores will become part of our API set, and will be used by other companies to power their own privacy applications. The algorithm also will evolve to include additional factors, which are likely to differ based on the nature of the site.  The number of websites with privacyscores will grow through crowdsourcing. We will develop privacyscoring for mobile websites and apps, and they will reflect uniquely mobile privacy risks. We are already discussing with other researchers how to use privacyscore data for analysis that can be useful to policymakers and self-regulatory efforts.

We expect to continue to spend a lot of time responding to input from websites, ad companies and industry organizations, which will no doubt include some concerns. In this process we pledge to be as open and objective as we can be, and to quickly correct any mistakes or misconceptions (which are inevitable). We’re confident that this dialogue can only make the service better, and that there’s plenty of common ground when we stay focused on doing right by web users.

We thrive on your comments and feedback. Please take our user survey, or contact us directly.

A note of thanks

This project could not have been realized without the great work and insights of over a dozen coders, designers and analysts, as well as scores of testers and supporters (at Nextspace and beyond). We’re inspired by these people and deeply grateful for their contributions.

Her deadline: June 2012.

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.

Get started here.