Re: Quick overview of privacy icons (Aza and Arun's W3C position paper from privacy workshop)

On a similar note Renato has a paper where he presents Privacy Icons within a the social networking context, the work is based on ODRL, subject of the previous teleconf.

 http://semanticidentity.com/Resources/Entries/2010/7/1_Virtual_Goods_+_ODRL_Workshop_2010.html

Mischa
On 14 Sep 2010, at 19:09, Harry Halpin wrote:

>> From http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-22.txt
> 
> Just cut and pasting it below so people can read before telecon:
> 
> = Privacy: A Pictographic Approach =
> 
> Submitted by:
> Aza Raskin <aza@mozilla.com>
> Arun Ranganathan <arun@mozilla.com>
> 
> On behalf of Mozilla
> 
> 
> Mozilla believes that privacy policies are long documents written in
> legalese that obfuscate meaning. Nobody reads them because they are
> indecipherable and
> obtuse. Yet, these are the documents that tell you what’s going on with your
> data — how, when, and by whom your information will used. To put it another
> way, the privacy policy lets you know if some company can make money from
> information (like selling your email address to a spammer).
> 
> Creative Commons [1] did an amazing thing for copyright law. It made it
> understandable. Creative commons reduced the complexity of letting others
> use your work with a set of combinable, modular icons.
> 
> In order for privacy to have meaning for actual people, we need to follow in
> Creative Commons' footsteps. We need to reduce the complexity of privacy
> policies to an indicator scannable in seconds.
> 
> Mozilla believes that solving all of the problems with privacy in one go is
> tilting at windmills. P3P [2] took a taxonomic approach and languished in the
> exponential complexity. Instead, we should be seeking to answer the
> question: "What attributes of privacy policies and terms of service should
> people care about?" and then highlight those attributes. Further, we should
> only be highlighting attributes of privacy which are not "business as usual"
> so that users do not become inured by constant warnings.
> 
> Finally, Mozilla believes that the attributes should be machine readable to
> encourage user-agent and other innovation.
> 
> == Only What People Should Care About ==
> 
> The “should” is critical. Privacy policies are often complex documents that
> deal with subtle and expansive issues. A set of easily understood and
> universal icons cannot possible encode everything. Instead, we should call
> out only the attributes which are not “business as usual”: the warning flags
> that your privacy and data are at risk.
> 
> Here's an example. Should we have an icon that lets the you know that your
> data will be shared with 3rd parties? Isn’t 3rd party sharing intrinsically
> a bit suspect? The answer is a subtle no. Sharing with 3rd parties should
> raise a warning flag but only if that sharing isn’t required. The classic
> example is buying a book on Amazon.com and getting it shipped to your home.
> Amazon needs to share your home address with UPS and Privacy Icons shouldn’t
> penalize them for that necessary disclosure. In other words, Privacy Icons
> should only highlight 3rd party data sharing when you do not have a
> reasonable expectation that your data is being shared.
> 
> The “should” is a major differentiator from many of the prior approaches,
> like the taxonomic P3P or Lorrie Cranor’s crowd-sourced Privacy Duck [3].
> 
> == Bolt-on Approach ==
> 
> Privacy policies and Terms of Services are complex documents that
> encapsulate a lot of situation-specific detail. The Creative Commons
> approach is to reduce the complexity of sharing to a small number of
> licenses from which you choose. That simply doesn’t work here: there are too
> many edge-cases and specifics that each company has to put into their
> privacy policy. There can be no catch-all boiler-plate. We seem to have lost
> before we have even begun. There’s another approach.
> 
> Here’s where we stand: companies need to write their own privacy
> policies/terms of service, replete with company-specific detail. Why?
> Because a small number of licenses can’t capture the required complexity.
> The problem is that for everyday people, reading and understanding those
> necessarily custom privacy policies is time consuming and nigh impossible.
> 
> Here’s a solution: create a set of easily-understood Privacy Icons that
> “bolt on to” a privacy policy. When you add a Privacy Icon to your privacy
> policy it says the equivalent of “No matter what the rest of this privacy
> policy says, the following is true and preempts anything else in this
> document…”. The Privacy Icon makes an iron-clad guarantee about some portion
> of how a company treats your data. For example, if a privacy policy includes
> the icon for “None of your data is sold or shared with 3rd parties”, then no
> matter what the privacy policy says in the small print, it gets preempted by
> the icon and the company is legally bound to never sharing or selling your
> data. Of course, the set of icons still needs to be decided.  Mozilla
> held a workshop on the 27th of January 2010 to help decide these kinds
> of questions, and will host further events in the future.
> 
> == Lawyer Selected, Reader Approved ==
> 
> Since its release, Creative Commons has continually pared down the number
> of licenses it provides and is now down to just two icons, one with two
> states and one with three. It has to be so simple because everyday people
> choose their own license. Privacy Icons don’t have that constraint. A
> qualified lawyer chooses what icons to bind to their privacy policy, and so
> there can be substantially more icons to choose from allowing the creation
> of a rich privacy story. As long as the icons are understandable by an
> everyday person, we are golden.
> 
> == Machine Readable ==
> 
> Some of the attributes will have potentially a bad normative value, like an
> icon that indicates your data may be sold to third parties. The question
> becomes, why would any company display such an icon in their privacy policy?
> Wouldn’t they instead opt to not use the Privacy Icons at all? This is the
> largest problem facing the Privacy Icons idea. Aren’t we are creating an
> incentive system whereby good companies/services will display Privacy Icons
> and bad companies/services will not?
> 
> If attributes become widely adopted then the correlation of good companies
> using the icons and bad companies not using the icons becomes rather strong.
> If a privacy policy doesn’t include any icons it runs the risk of
> becoming synonymous with that policy making no guarantees for not
> using your data for evil. The absence of Privacy Icons becomes
> stigmatic.
> 
> Asking people to notice the absence of something is asking the implausible.
> People don’t generally don’t notice an absence; just a presence. The
> solution hinges on Privacy Icons being machine readable and Firefox being
> used by 400 million people world-wide. If Firefox encounters a privacy
> policy that doesn’t have called-out attributes, we’ll automatically display
> the icons with the poorest guarantees: your data may be sold to 3rd
> parties, your data may be stored indefinitely, and your data may be turned
> over to law enforcement without a warrant, etc. This way, companies are
> incentivized to display these attributes and thereby be bound to protecting
> user privacy appropriately.
> 
> == Attribute Strawperson ==
> 
> As a strawperson, here are the 7 things that we believe matter most in privacy:
> 
> * Is you data used for secondary use? And is it shared with 3rd parties?
> * Is your data bartered?
> * Under what terms is your data shared with the government and with law
> enforcement?
> * Does the company take reasonable measures to protect your data in all
> phases of collection and storage?
> * Does the service give you control of your data?
> * Does the service use your data to build and save a profile for non-primary
> use?
> * Are ad networks being used and under what terms?
> 
> === Secondary Use of Data ===
> 
> *Is your data used for secondary use?* The European Union has spent time
> codifying and refining the idea of “secondary use”; the use of data for
> something other than the purpose for which the collectee believes it was
> collected. Mint.com uses your login information to import your financial
> data from your banks — with your explicit permission. That’s primary use and
> shouldn’t be punished. The RealAge [4] tests poses as a cute questionnaire and
> then turns around and sells your data. That’s secondary use and is fishy.
> When you sign up to use a service you should care if your data will only be
> used for that service. If the service does use your data for secondary use,
> they should disclose those uses. If they share your data with 3rd parties,
> then they should disclose that list too.
> 
> === Bartering User Data ===
> 
> *Is your data bartered?* You should know when someone is making a gain off
> your back. You should also know roughly how and for what that data is being
> bartered.
> 
> === Goverment and Law Enforcement as Third Parties ===
> 
> *Under what terms is your data shared with the government and with law
> enforcement?* Do they just hand it over without a warrant or a subpoena?
> 
> === Private Data Storage Considerations ===
> 
> *Does the company take reasonable measures to protect your data in all
> phases of collection and storage.* There are numerous ways that your data
> can be protected: from using SSL during transmission, to encryption on the
> server, to deleting your data after it is no longer needed. Does the company
> protect your data during transmission, storage, and from employees? This
> icon should tell you what the weak link is.
> 
> === User Control of Data ===
> 
> *Does the service give you control of your data?* Can you delete your data
> if you choose? Can you edit it? What level of control do you have over the
> data stored on their server.
> 
> === User Profiles for Non-Primary Use ===
> 
> *Does the service use your data to build and save a profile for non-primary
> use?* This is a subtle one, as we want to include the concept of PII
> (personally identifiable information). What we are worried about are
> companies secretly building a dossier on you — say by taking your email
> address and then buying more information from a 3rd party about that email
> address to get, say, your credit rating. Then using that profile for uses
> with which you haven’t agreed.
> 
> === Use of Advertising Networks ===
> 
> *Are ad networks being used and under what terms?* On the web most pages
> include ads of some form, and the prevalence of behavioral tracking is on
> the rise.  While letting users get a handle on ad networks is
> important, raising the alarm on every page would be counter-productive. We
> haven’t figured out yet how to handle ad networks and are looking for more
> thought here.
> 
> == Conclusion ==
> 
> Mozilla believes that it is possible to have a small set of easily
> understood icons that can represent actionable privacy choices to a
> user, and is open to discussing standardizing these across user
> agents.  Additionally, we should consider making these icons machine
> readable, and discuss the best way to do so.
> 
> 
> [1] http://creativecommons.org/
> [2] http://www.w3.org/P3P/
> [3] http://lorrie.cranor.org/
> [4] http://www.zdnet.com/blog/healthcare/is-realage-a-scam/2040
> 

___________________________________
Mischa Tuffield PhD
Email: mischa.tuffield@garlik.com
Homepage - http://mmt.me.uk/
Garlik Limited, 1-3 Halford Road, Richmond, TW10 6AW
+44(0)845 645 2824  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD