W3C Privacy Workshop

12 Jul 2010


See also: IRC log


Dan Appelquist, Thomas Roessler
Dominique Hazaël-Massieux (W3C; <dom>)
Thomas Roessler (W3C; <tlr>)
Caspar Bowden (MS), John Morris (CDT; <jmorris>)
Patrick Walshe (GSMA)
Charles Brookson (BIS)
Mischa Tuffield (Garlik; <mischat>)
Marcos Caceres (Opera; <marcos>)
David Singer (Apple; <dsinger>)
John Carr (European NGO Alliance for Child Safety Online)
Kristin Tigart (Tessitura Network)
Alissa Cooper (CDT; <alissa>)
Frederick Hirsch (Nokia; <fjh>)
Robin Berjon (Vodafone; <darobin>)
Graham Steel (INRIA)
Thomas Duebendorfer (Google)
Simon Moritz (Ericsson Research)
Hannes Tschofenig (Nokia Siemens Networks)
Bruce Lawson (Opera)
Jens de Smit (SURFnet)
David Rogers (WAC; <drogersuk>)
WonSuk Lee (ETRI)
Kangchan Lee (ETRI)
Sören Preibusch (University of Cambridge)
Ioannis Krontiris (Goethe University Frankfurt)
Cullen Jennings (CISCO; <cullenfluffyjenni>)
Zoli Piroska (Secret Sauce partners)
Ian Fette (Google; <ifette>)
Jochen Eisinger (Google; <jochen>)
Karl Dubost (<karl>)
Bryan Sullivan (AT&T; <bryan_sullivan>)
Dong-Young Lee (LGE)
Youn-Sung Chu (LGE)
Kasey Chappelle (Vodafone)
Richard Barnes (BBN; <rbarnes>)
Richard Carlsson (Ericsson)
Aza Raskin (Mozilla)
Patrick Gage Kelley (CMU; <pkelley>)
Franco Papeschi (Vodafone)
Mark Lizar (Smart Species)
Soonho Lee (SK Telecom; <soonho>)
Daniel Appelquist (Vodafone; <dka>)
Aram Perez (Qualcomm)
Kai Hendry (Aplix; <hendry>)
Deirdre Mulligan (UC Berkeley)
Henry Story (<bblfish>)
John Morris, Alissa Cooper, Karl Dubost, Robin Berjon


Karl Dubost: From Privacy To Opacity - Digital Me Management

See also: position paper / slides

Dubost: different identities in different contexts
... marketing leads to interesting discussions about "privacy"
... communications can be global, instantaneous
... info is replicated on net -- much harder to lie

<hendry> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-3.html is Karl's pp btw

Dubost: info is permanent
... once you give access, you have no way to take it back -- to say "stop using my data"
... how do we make it possible to have a loss of memory

<tlr> http://www.w3.org/2010/api-privacy-ws/slides/dubost.pdf

Dubost: privacy is cultural
... people's privacy views differ than businesses
... robots.txt is a bad protocol ... only works if you have access to root of site
... it shows what you want to hide
... can only do that with .htaccess
... Tumblr and other sites give you the ability to keep search engines from indexing personal site
... your site is public, but you give links to it (not reached through search engine)
... need something better that robots.txt
... browsers are my main communications tool

Dubost: could there be a layer in browser to collect what you have shared?

henry: mistake that data can be infinitely copied
... value of info depends on who is publishing
... so there is info destruction happening

John Carr: Child protection concerns and the new location services

See also: position paper

Carr: no slides

Carr: works with range of orgs across europe concerned about childrens use of Internet
... in UK in March 2010 Ofcom did research in child use of social network space
... of 8-12 year olds, 19% had profiles on three social networks
... most had profiles private, but 11% did not
... looking at all children - 25% of all children on sites they should not be on
... not all parents monitor kids at all times
... this is environment into which new geolocation services are being dropped
... geolocation services specify 18 year old as minimum age
... but geoloc services can be lined to 13 year old social network page
... wants to enlist group's help to address problems
... almost think that age limits should be dropped, because they are not being enforced

<dsinger> if, on the internet, no-one knows you're a dog, how do I 'know' you're a child?

<dsinger> and is there a Streisand effect here, saying 'if you're young, DO NOT LOOK HERE!'? what do the young immediately wonder?

<ifette> especially given that in the US we are forcefully against any sort of national ID card that could actually be used to prove identity/age online

Carr: sites purport to want to ban children, but they do not enforce
... asks what would an 8 year old's judgment be on what privacy means

<eisinger> in germany, we're currently developing an id card that would allow you to prove (parts of your) identity to a website

<drogersuk> +1 to ifette's point

<eisinger> such as the age

Carr: every country in world specifies 18 as minimum age to be adult

<ifette> jochen - remind me not to move back to germany :)

<drogersuk> also, as he said - the parents are actively encouraging the kids so they would just leave their card with the kid

<eisinger> ha, i'll remind you end of september that you didn't want to come here

Carr: hope that we can find a way in this technical space to find better technical tools to deliver broad social policy
... we all want privacy rules over out data, but if a company is dealing with physical whereabours, this is very highly sensitive
... in 2003 mobile services in UK started rolling out location,

<drogersuk> on the child protection issue - most kids are abused by someone that is known to the family so they are likely to have given their location to that 'trusted' person

Carr: companies accepted validity of location concern
... key thing they did is make location a paid-for service
... if you paid for it, there was an audit trail
... if you were trying to track a child, you had to do a further check
... postal checking process

<drogersuk> there are use cases getting mixed up here - for example preventing kids accessing over 18 content is entirely different to 'child protection' in the traditional sense

Carr: before you could commence tracking service on child

<fjh> example, know where you are at 4pm every monday, can determine pattern

Carr: does not see evidence of these checks in the new location services
... the web based loc services just require the ticking of a box

<rbarnes> hendry: depends a lot on the browser

<drogersuk> @hendry - maybe we should ban the internet

Carr: experience with ticking box -- gambling sites just asked to tick a box to gamble
... kids were developing gambling addiction

<hendry> drogersuk: i think a child can survive without geolocation features

Carr: law changed to require age verification system

<drogersuk> @hendry - or the internet ;-)

<ifette> Payment doesn't seem like any guarantee. I can go to any store in the US and buy a "pre-paid" credit card, and provide whatever name and address I want that will get associated with the card.

Carr: since law has passed, children have not been able to invent identities

<drogersuk> I remember this discussion about 0898 numbers in the early 1990's. Never stopped me

<hendry> rbarnes: turning off geolocation needs to be really simple to do. simple enough for a parent/guardian

Carr: easy for 18 year olds, much harder to do for younger

<rbarnes> hendry: ... and permanent enough that the kid can't turn it back on?

<ifette> hendry - turning it off isn't the hard part. It's ensuring that the kid, who is probably more savvy than the parent, can't turn it back on

<drogersuk> @dsinger - yes I missed that too

<hendry> ifette: true, but i struggle to toggle geolocation and i'm smart I think

Appelquist: what role do education, parents, etc. play in addressing this problem?

<drogersuk> most of the people in this room started their technical careers getting round restrictions that were put on them as kids

Carr: agree that education is part of it, but technical is also part

<hendry> ifette: in chrome the option to turn off geolocation is buried under a couple of menus!

<ifette> hendry, everything in chrome is buried under multiple menus because for most users there is no desire to turn this off permanently

<rbarnes> hendry: i can't find the toggle in firefox; ironically, it's not under the "privacy" tab

Walshe: to clarify re 2004 code of practice - it was successful because mobile operators were in highly regulated environment

<ifette> hendry, chrome will also ask you on each site

<ifette> (as will any browser afaik)

<hendry> i have taken a few screenshots battling to turn off geolocation (on already authed sites) http://www.flickr.com/photos/hendry/sets/72157624456158938/

Morris: 2004 included extra layers for children

<hendry> ifette: i think the desire is there. i need to turn it off from time to time. ;)

Rogers: use cases mixed up - gambling , predators, different use cases

<ifette> hendry, please do not use ifette: as then the minutes will have me reflected as saying that.

<ifette> hendry, in chrome you could have done it much more simply

<ifette> click on the little target in the url bar

<ifette> and you can change settings for the site you're on

Jennings: how did gambling work

<bryan_sullivan> do any of the browsers make it easy to create a user-specific button to turn geoloc on/off?

<eisinger> also the website can already locate you pretty good with only your ip

<ifette> in one click

Jennings: gambling restrictions on kids

<hendry> is that for all open tabs btw?

Carr: when you apply to gambling site, you allow credit, other checks

<ifette> hendry if you clear it, future requests will fail

<ifette> on all tabs/windows

<ifette> the setting is stored for the origin, not tied to a window/tab

Carr: 5% cannot verify with databases, they must use other papers

Singer: is there error the other way- children in databases?

<hendry> i mean for all running apps (different origins)

<ifette> the setting is per origin

<tlr> http://www.w3.org/2010/api-privacy-ws/slides/chappelle.pdf

Kasey Chappelle, The Future of Privacy - Vodafone's Perspective

See also: position paper / slides

<ifette> i find it rather unlikely someone suddenly decides they want to turn off geolocation for all sites

<ifette> we have these theoretical discussions, in practice it doesn't seem to happen

<hendry> ok,we'll debate this later :)

Chappelle: privacy is the right to decide - informational self-determination
... lots of words on slides ..
... web 2.0 mashup ability means I am more empowered to talk
... economic changes ..
... regulation becomes a barrier to entry
... need to walk fine line
... disruptive innovation is happening all the time, do not want to stop that
... regulatory environment in flux

<karl> http://slidesha.re/cNmZGw - my slide From Privacy to Opacity - Digital Me Management

Chappelle: EU is relooking at data protection directive, US is proposing privacy laws,
... old distinctions between controller, processor, subject are blurring
... some consistent principles around the world
... if you meet these principles, companies will avoid privacy fiascos
... key principles : transparent notice, informed choice, access/correct/delete, minimize/delete
... privacy policies ... 4000 words... not read

Chappelle: users do not know what choices are.... info not available in helpful manner

Chappelle: if regulators decide how privacy is done, then this will chill innovation on privacy
... security does not equal privacy
... security is how/what info is being accessed, but not the why

<drogersuk> @dsinger - I brought my camera for a laugh just to see if anyone would complain - I walked in and some guy had a huge lense taking pictures of everyone

Chappelle: this is broader that geolocation

<fjh> can barriers to entry created by regulation also create possible monopoly structures due to the need for scale for meeting the regulations?

Chappelle: embedded code in handset can create profiles

Hirsch: is "informed" a well defined term?

Chappelle: opened, evolving area
... 4000 word policy is not "informed"

Hirsch: "reasonableness"?

<ifette> 4000 seems pretty short :)

Sullivan: any specific characteristics that would help us understand when users have been informed

<drogersuk> @dsinger that's how we identified German morse code operators in the war

Chappelle: if we continue to focus on consent only, we have failed
... one has to balance experience - we need to rethink fundamental structure
... look to primary purpose, secondary purpose distinction

Moritz: have you looked at where data are located?

<karl> interesting. Do you give enough information to make a decision? What's happening with regards to intimate discussions between two persons. Since there are devices and private companies in between, they carry neutrally (bits transport) or not the information (data mining)

Chappelle: this is part of the problem - my employer is based in UK, but if online service is accessible everyone, what rules apply?
... perhaps moving toward global standards

??: national content standards

Chappelle: national content standard need to still apply
... privacy standards may be different
... reactions are fairly similar - giving choices is what matters

<drogersuk> solution is we need a global government with global laws. Is that a possible outcome of this workshop?


Roessler: moving to general discussion
... karl talked about forgetting things in real life, not online
... john talked about specific regulatory framework in UK - note tension between rule and reality
... kasey talked about some regulatory frameworks .. need to tell people "why" you want to use their data
... common theme - there are hard and fast rules that do not map into social reality

Carr: when I was 15, I wanted to get a pint of beer in pub
... we should not strive to match the social reality
... offering of internet is aimed of family homes all over world -- we have to stop thinking about children as an afterthought
... we should shift our mindset to recognize that lots of children are online

Fette: to do anything useful, you must know who is a child
... in US, we are against national ID card

Carr: you will want to solve problem

Hirsch: karl mentioned things to do, but technical solutions often do not work
... we need social mechanisms
... how does technology enable to social mechanisms to address concerns

Dubost: what we can do is to enable people to have more control over data

??: there will be social catastrophes

<eisinger> there also will be keyboard catastrophes

??: how to create solutions without creating monopoly?

Dubost: gps is completely anonymous system, cell phone triangulation is bad because others can see

Preibusch: age verification is one example of how things get complicated by moving to web

<bblfish> oops forgot the queue here

Preibusch: some social network push authentication back to users -- peer-to-peer authentication
... seems that appear to be closed are flawed on technical level

Singer: what if I want to interact without revealing info about myself

Carr: if there is a claim that service is age limited, then that should be enforced

<fjh> isn't it true most people will give up much information for a coupon? Research somewhere, lost pointer.

Sullivan: anonymity is weak protection - lots of info is available

Rogers: take issue about age limits - 18 year old limit is not a privacy rule, it is a contract/legal rules
... use case is mixed up

Carr: my point is that sub-18 year old is not in position to evaluate privacy questions
... to companies that go geoloc have a responsibility to do more

Fette: asked for concrete proposals can follow, and I've yet to hear any proposals

Chappelle: we are setting a scene

Roessler: we will come back to question

Story: liked what karl said about giving user control
... parent can set computer to appear as a child

Appelquist: we have not talked about role of parent
... you buy phone for child, set it up, you give it to child

Walshe: couple issues on regulation - kids set up yahoo account to pretend to be adult
... all info on kids available because of registry
... in some countries, 15 year olds can marry, have kids, but they cannot use location services?

Carr: I am enlisting your help for solving problems
... internet is fragmenting, and will happen more unless we solve these problems

<dsinger> to jmorris: in the USA you can fight and die for your country (and vote) at the age of 18, but not drink a beer...

Carr: technology companies seek to avoid responsibility, and that leads gov'ts to try to step in

Dubost: would like to move away from privacy policies discussions to focus on simple tools to control data that will enable privacy. social structures already exist

Chappelle: trying to encourage technology to allow users to decide where on the public/private spectrum they should be

David Singer: Privacy and the W3C: Questions towards a direction

See also: position paper / slides

Singer: we don't realize something was private until it's gone
... who owns what?
... protocols and plumbing not the W3C's problem
... apps are not our problem either
... formats and presentation are out problem
... priv expression languages are hard

Singer: with rights expr language, you can change it on every transaction
... constant need to expand policies to cover everything
... is it possible to verify that policy matches intention?
... tension between what's allowed vs. forbidden
... how much data accumulation is too much?
... users tend to balk at the unforeseen even if it was fairly innocuous

Singer: policies are too long for people to read

Chappelle: law encourages long policies
... but emerging legal thought in US is that important info has to be outside policy

Singer: questions for W3C
... can we
... define privacy?
... identify W3C's scope?
... do policy languages?
... manage degree and context?
... keep disclosure informed and voluntary?

Singer: some key players are not members of W3C
esp sites and services
... IETF has security considerations in specs
... do we need privacy considerations?

Roessler: Example: XHR 2 has security considerations as exit requirement

<jmorris> +1 on proactively having privacy considerations sections

<jmorris> +1 on there being privacy implications on most of what W3C does

Singer: do we have enough mistakes to learn from?

<tlr> (Part of David's point was that neither privacy nor security considerations being mandatory in W3C specs.)

Singer: need a taxonomy

Applequist: last question was driver for this workshop

Appelquist: want to know what we learned from implementations
... of geoloc API

Singer: conclusion: this is a big fluid area

Sullivan: who owns what is a key question
... as in, who owns data about my identity

Roessler: ownership is used in broader priv literature, but it's limited

Perez: machine-to-machine (m2m), like smart grid, is emerging
... info about people that they don't even know can be collected about them

Roessler: interesting questions beyond javascript APIs

Story: ownership is the wrong framework
... value of info changes depending on who I got it from

Singer: was talking about ownership of specs, not ownership of data
... nefarious web sites built with our specs are not our fault

Pat Walshe: GSMA position paper for the W3C workshop on privacy for advanced APIs

See also: position paper / slides

Walshe: EU commission is looking at who owns data
... putting the user back in the center of things
... complex web of relationships around the user
... Eric Schmidt recently said priv will become so impt that it will have to regulated on country-by-country basis
... focus on consent is misguided
... why "preservation" and "protection"? why not expression of choice and preference? innovation?
... all different apps collect different kinds of data, but all claimed not to be PII
... GSMA was concerned about what was happening with mobile privacy
... priv not being treated ... consistently or in functional terms
... security does not equal privacy
... looking for consistent priv experiences
... how do entities across borders agree about how to respect my privacy?
... privacy in standards: one approach is privacy principles
... users have priv needs and expectations that need to be incorporated into development processes
... focus on outcomes
... long policies are not good outcomes
... principles are looking at context-aware priv prompts
... asking for consent for everything undermines privacy
... privacy design guidelines useful for meeting global expectations

Walshe: expectations transcend borders and contexts
... ISO is doing work on priv standards, regulators are involved
... some regulators concerned that SDOs can't get the job done themselves
... Article 29 working party out to set express consent baseline for applications
... developers need something that they can understand

Appelquist: mentioned that ISO is opaque
... have lots of convos happening internally, but we're not talking to each other

<jochen> I love those bug reports: I blocked the 3rd 7th and 9th cookie and now the page went in a redirect loop

Appelquist: would like to see more transparency around those processes

Walshe: our process is transparent now

Preibusch: what does GSMA do concretely?

Walshe: have gotten members to agree to privacy principles
... and priv design guidelines
... previous efforts have been aimed at fixed line context

Preibusch: where do guidelines come from?

Walshe: guidelines from many different members

Fette: how do you cut the crap out of priv policies?
... everyone has to explain the same nonsurprising stuff

Preibusch: users care about different things, may be surprised by diff things

<fjh> need to focus on exceptions, management by exception

Sullivan: priv by design still has a long way to go

<fjh> +1 to ifette

Sullivan: how are we going to determine conformance to Privacy by Design principles?

Walshe: looking at a seal program

<drogersuk> I cannot believe that comment: "if you want to know what a cookie is, go to W3C" - that is so far out of touch with the reality of 99% of users to be offensive

Barnes: GSMA has one API program that has good building blocks for higher layer decisions

Walshe: one API allows one interface for buying on mobile

Hannes Tschofenig: The Role of the Internet Engineering Task Force (IETF) in Improving Privacy on the Internet

See also: position paper / slides

<karl> drogersuk, the issue is not necessary where it is defined but more how people access it and in which language do we explain it. That's another issue of privacy policies. Living in a foreign country with a different language.

Appelquist: developers are interested in ideas around privacy guidelines

Tschofenig: IAB shares goal with IETF of making internet work better

<rbarnes> GSMA OneAPI: http://www.gsmworld.com/our-work/mobile_lifestyle/oneapi.htm

<drogersuk> @karl, completely agree but most users do not have a clue about anything technical, we need to bring it down some notches to what is understandable

Tschofenig: privacy = fair information practices
... no shortage on priv principles
... IETF applies hybrid of PbyD and "priv by policy"
... PbyD is more understandable to engineers
... although it's often advocated by non-designers

Tschofenig: role of SDOs
... some orgs are strongly focused on standardizing every aspect of a system -- 3GPP, OMA, ETSI, ITU-T
... then proprietary: not Internet-based
... then built on top of standards
... need for standards decreases as you go up the protocol stack
... priv seals and certifications haven't provided a lot of value
... IETF has remained generic in protocol definition

Tschofenig: IETF often standardizes after implementations and deployments exist, limiting designability

<karl> programmatic forgetfulness = creating a system which makes it possible to automatically delete information against certain criterias (once seen by X, in 3 days, once seen by someone in that location, etc.)

Tschofenig: pragmatic approach required
... IETF also often doesn't see what happens when things get deployed
... limits to what behavior IETF can dictate
... Example: SIP

<karl> http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_1_1_1_1,00.html

<karl> OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data

Tschofenig: Example: protocol for session establishment and maintenance
... priv not incorporated at first, but extensions developed throughout
... with deployments, got regulatory requirements and business requirements
... e.g., recording sessions

<karl> IETF Policy on Wiretapping http://www.ietf.org/rfc/rfc2804.txt

Tschofenig: Example: tension between security/priv and these requirements
... e.g., lawful intercept
... question is how to tackle conflicting requirements?

Tschofenig: things for W3C/IETF to do
... (acknowledging limitations)

<dom> http://tools.ietf.org/html/draft-hansen-privacy-terminology-00

<dom> (July 5 2010)

Tschofenig: feedback appreciated on priv terminology doc
... education and awareness for engineers
... guidelines for having privacy considerations in standards
... establish review teams for privacy considerations
... would like to establish smilar views among other SDOs
... want to avoid forum shopping
... identify implementation and research challenges (IRTF)

<dom> Internet Research Task Force

Tschofenig: education of regulators
... regulators can help increase transparency

Sullivan: how is IPv6 going to affect privacy?

Tschofenig: if your IP address never changes, sites you visit will see it all the time, but there are standardized solutions to change that

Preibusch: theme seems to be need to cut down to simple decisions
... on other hand we have frameworks and guidelines
... lack of empirical evidence about what users want
... or what will surprise them

Appelquist: we are talking across a wide range of things
... PbyD can be about app or service, but HT was talking about design of protocols

Preibusch: IETF trying to engineer new protocols

Tschofenig: at the end it's about what goes over the wire
... but more complicated than that
... whole collection of entities need to work together
... e.g., XMPP made deliberate decision to route all traffic through core nodes, but could be totally different

Walshe: research has been conducted about what people want
... but we need more
... guidelines are needed to unify across platforms

Roessler: there are diff pieces of the system that have entirely different privacy discussions
... location acquisition (GPS, cell triangulation) vs. consumer of location information
... designing pieces of protocol vs. pieces that interface with apps

Appelquist: only as private as the weakest privacy link

Tschofenig: we did something specific in geolocation about how granular preferences are

Walshe: speech-to-text app dropped in rankings because it started invading privacy

Chapelle: privacy fiascos tell us about what users want

Singer: targeted advertising spooks people

Carr: many companies shape consumer expectations, don't they have an ethical view of these questions?

Piroska: have done consumer research
... we shouldn't make decisions for consumers
... but we've found that there's a big difference between sharing with friends and sharing with companies
... most privacy issues are with friend sharing
... company data collection is important: but consumers care about social sharing more

Roessler: powerful frame for a general discussion

Barnes: challenge Kasey notion that we know what consumers want

Chappelle: we learn from fiascos

Singer: all of my transactions used to be physically distinct

Rogers: different users have diff expectations

Cooper: consumers can't care about things they don't know about

<karl> useful for this workshop http://mypoyozo.com/ Poyozo is an automatic, personal diary system to help reclaim and consolidate your ever-expanding digital life with simple visualizations that you can use every day.

Sören Preibusch: APIs and Consumers' privacy decision-making

See also: position paper / slides

Preibusch: I have been looking at how users make decisions
... if users are not satisfied with their privacy will feed competition.
... toxic triangle: cancel and switch / false data / cancel

Preibusch: these will create negative business impacts
... we do not know why people switch between these three angles of the toxic triangle
... privacy negotiation is not necessary formalized. It can be a straightforward process as consumers make choices.
... There could be incentives behind privacy questions.
... Privacy practices have been observed to be better at Web sites with more users, longer history, bigger web sites, etc.
... This is correlation and not causality.
... We did laboratory experiment.
... We really need more data by observing people.
... We need to know what people do.
... experiment made around buying DVDs.
... Two companies forms look like exactly the same
... on one side we asked for the colour on the other one for the income for the same price. And an additional case with a lower price.
... if the price is better, they are ready to give more information.
... they go to discount instead of privacy.

??: what was the population distribution?

Preibusch: students.

??: did they have incomes at all?

Preibusch: the experiment was real. They really bought the DVD. We checked income data for plausibility. There was no evidence for participants lying about their income.

<dsinger> s/??/several people/

Hendry: is the sample too low?

Preibusch: it's too low to test for randomness
... but it's fine for applying heuristics; results are significant otherwise.

Preibusch: we know that people made this choice even if they were not satisfied about it

Preibusch: we asked them if they were willing to reveal their data.
... people will use the cheaper company against their own rules.
... data about privacy preferences are not homogeneous.
... valid experiments reveal user's privacy decision-making.
... forget intuitions
... collect real data from experiments.

???: it's difficult to assess what users want in this kind of experiment for ??

Preibusch: true
... maybe collection is not the right thing to test, but the use.

Patrick Kelley: User-Controllable Location Privacy

See also: position paper / slides

Kelley: We are actually working with users.
... to be sure the information is really usable.
... Users have things more and more difficult to configure.
... example a router.
... I will focus on sharing in a mobile social way.
... These apps on mobile location have been developed by dozens.
... We do not have yet a situation of the size of Facebook, even 4square.
... We developed Locaccino in a way to study the privacy settings and their usage.
... We study how they use their phone on a long term.
... There is no policy which makes it acceptable for every type of users.
... It doesn't exist.
... people have been asked for every location what would be their sharing behaviour.
... Is it possible to group the results in a way which is meaningful for creathing rules.
... location rules don't exist
... time rules don't exist
... you can only put in group rules
... (friends, etc.)
... The white list is the lowest "average time shared"
... for each type of groups.
... People do not want to share with Advertisers group
... Future work
... soft paternalism…
... We have been running the system for 3 years and thousands of people
... users have complex privacy settings
... There are not enough people using LBS to be sure about the true complexity of your Privacy policies.
... approving and disapproving a friend, your mother and your work colleague are quite hard challenges.
... We need time to see how it will evolve.
... we have studied labels design and we come up with two types of designs.
... The table one was the more effective overall.
... 20% of people miss the word cookie in the middle of a paragraph.
... People prefer the graphical approach.

Hendry: did you measure blacklist and whitelist?

Kelley: no, we didn't


pkelley: I can't answer this question
... I'm not sure I can believe users, but it's what they report.

Appelquist: location obnoxious

Kelley: It is often unclear what is the ideal outcome
... where do you try to push the users to?
... people do not want to be completely private.
... Nudging could be "Are you really sure to do that?"

Appelquist: Users might turn off

Kelley: yes indeed.

Singer: did you dig in personal preferences or is it just the results of social context?

Kelley: Long time research shows that people are not going to many places
... it's hard to assess
... the quality of data.

<cullenfluffyjenni> Is there a twitter tag people are using for this workshop ?

<dom> #w3cprivacy

Lalana Kagal: Access Control is an Inadequate Framework for Privacy Protection

See also: position paper / slides

Kagal: I do not propose any technical solutions.
... I will propose future directions researchs.
... Brandeis = access to information
... Westing = use of information
... sensitive information can be inferred from public resources.

Kagal: (slide 3 of 9)
... Once I have access to an information, I can post it in another context
... but the context has changed and then I might violate the privacy of a friend
... Gaydar project helped to reveal the sexual orientation in Facebook.
... even with people having totally private profile.
... It was before the list of friends was made public.
... We should have system where data could be used in a more sensitive way.
... privacy social systems should be built in accordance of physical social norms
... Signals and signs in human society describe behavior (example car parking sign)
... There are mechanisms to identify violators and to respect the rule.
... We do not know if there is a technical solutions.
... we have ideas about possible systems
... give enough information to users to make decisions.
... If their privacy will be respected, if they should sue, etc.
... Google Dashboard goes into the right direction.
... information accountability should be supported.
... We are interested in privacy enabling interface design.
... When I try to copy a picture, make a box for warning the users of the context of the photos.
... Not an enforcement mechanisms but an information that users will be reminded of the privacy context.
... policy awareness through icons for example.
... privacy nudges help to prevent users to send emails.
... "Are you sure you want to send to all these people?"
... Before you submit, having a message explaining the consequences.
... There are works on data usage.

Dubost: you need a google account to check google dashboard. It's an issue.

Kagal: indeed.

Singer: ??

Kagal: When I see the CreativeCommons I can make a decision to care or not care about
... but I make an informed choice.

Bowden: access control is only a part of the solution
... but you should distinguish the notion of social networks and user with organizations.
... access control is different, for example, for employees of organization dealing with users data.

Kagal: discussing with facebook people, they said that "oh we tell them to not look at the data"

Bowden: at microsoft, we have very strict policies.
... very small set of persons access emails for example.

Appelquist: Who at facebook look at the picture?

Story: one of the weird things with a network with a uri and a photo.
... Even for access control, there is a need for interface
... it's much easier to link to photos than copy.
... Access control for friends is necessary too.

Appelquist: how do we make privacy information usable in many different contexts and for different type of users?

Roessler: people have no idea when they are asked.
... disconnect about what they have set and what they say they have set.

??1: People are bad at making decisions about their privacy in advances
... maybe the best way is to let people know after the facts the implications.

Preibusch: Nudges remind me of a paperclip.
... it can be annoying.

??1: icons are meaningful, tables are meaningful.

??2: this is nothing new. You trust your bank.
... Vodafone can listen any of your conversations.

Story: the best way to help users would be to have systems what their page look like for another user.

??3: people do not want to have to configure.
... is there more things we can do for defaults.

Preibusch: How to choose the default is the issue. There are very powerful.

Kelley: there could be a set of predefined defaults
... the issue is when they change the sets
... it's what happening with Facebook.

Preibusch: giving an example of 4 sets.

Cooper: what are the things which are right for standardization?
... Is it better to have competition
... is it better to have the same for every companies

<tlr> Lalana's slides: http://www.w3.org/2010/api-privacy-ws/slides/kagal.pdf

Kagal: standardizing icons could be good thing

Fette: In real life, companies are not necessary comfortable with generic profiles.
... they want to know exactly what the user wants.
... antifishing practices
... each time a user is confronted with something new, users are freaking out about it.

Roessler: we should take into consideration the length of time the users are freaked out.

Kagal: is it a question of design of interface

Fette: I do not think it will solve it.

Raskin: we know that people do not know what they want.
... should people care about privacy?

Kelley: researchs help to figure out some of the data around privacy policies.

Raskin: for most of people, it goes over their head

Hendry: what about users who never find out?
... every time you visit a Web site, they check. Nobody knows that.

Preibusch: if they learn it later on in NYT, they will really freak out.

??4: Google has no way inferring the uri because of a hash.

??5: What kind of change do you need?

Fette: (missed the answer)

??6: What is the best way to communicate to users what they want
... they know what they want

Roessler: the question is often the mismatch between what the user wants and what is happening

Bowden: we can learn a lot of p3p
... if we do not remember that stuff, we will fail.

Fette: some things just do not work.

<darobin> Scribe: darobin

Jochen Eisinger: Practical Privacy Concerns in a Real World Browser

See also: position paper

Eisinger: geolocation is a content setting

<cullenfluffyjenni> Talk about geolocation api and problems implementation of it

Eisinger: the spec tells you to get consent from the user
... you should include the URI of the respource that wants geolocation
... but it's not just text+markup, it's an application stack
... the straightforward approach is to just prompt the user with lengthy information about where the javascript requesting info comes from
... it's complex because there can be iframes and remote scripts involved

Preibusch: do you need an API key to use the Google geolocation service

Eisinger: only for mashups

Hendry: with v2 you don't need it

Fette: this is a generic problem with javascript on the web

Eisinger: including the domain, but of what?
... you have to track where each piece of js comes from, and what it's talking to
... once you have permission from the user, the spec says she should be able to change her mind
... which means you then need some UI to make this accessible
... if you go to maps.google.com it's easy, everything's from google
... (demonstrates infobar in chrome)
... an icon in the address bar tells you that the page is using geo, and you can revoke
... it's accessible, but that's the easy case
... (shows the same case, but with google maps embedded in a third party site)
... should we show this as google requesting or as the 3rd party site requesting?
... it's not an easy question
... we ask the user for what's included
... but if you go to the revocation UI it shows the permission for what's included as embedded by the third party

Barnes: do you go several levels of embedding down?

Eisinger: no only one

Roessler: you're matching on the top origin and on the embedded origin?

Eisinger: yes
... in-between levels of embedding, if any, are not listed
... the reason it took me 8 clicks to get to these settings is because we believe that this is a level of detail that is too advanced for users
... we had a similar settings exposed for cookies earlier
... but users used them in random ways that broke websites

Hendry: so you think it's too complicated, and therefore hide it?

Eisinger: yes, average users don't understand embedding

Hendry: it could just be your UI design that's bad

Fette: only 10% of users even understand the menu from the icon in the address bar (??)

Appelquist: do you know whether or not average users are paying attention to that icon

Eisinger: we track this information, but the data are skewed
... but based on the data we have people don't use them

Cooper: how many people are going to location-aware sites?

Eisinger: google home page, google mobile...

Roessler: alissa's question is how many folks are exposed to an activated geo page, and how many use the icon

Eisinger: I can't tell for chrome, but for the mobile browser location is a highly used feature

Appelquist: on the android browser I don't see the icon

Eisinger: it's not there currently

Roessler: what were your considerations in changing it

Eisinger: we found that the way we used to do it (accept once) was not what users wanted — controlling geo more granularly should be easy
... you don't want to share your location every time you open maps

Preibusch: how many people revoke permissions:

Fette: none

Hendry: are you going to make the android UI the same?

Eisinger: there isn't a lot of room...

Appelquist: there's the title bar with room

Eisinger: from an implementers' point of view we'd like to see standards that take usabiilty into account
... try browsing with cookies set to "promtp" to get an idea
... you don't want to prompt the user all the time
... you want a way to grant permissions for an entire web application

room murmurs "widgets" a lot

??: if you don't grant access, the application doesn't get installed (or doesn't run)

Eisinger: in chrome we have a file api that grants access to a virtual file system
... it can be granted to a given origin, and no other website can access it
... it's tightly sandboxed

Hendry: over time you can build up a large number of sites which you trust, can that be saved and sent to another chrome browser?

Eisinger: yes, with chrome sync
... the file system API is a good example of privacy by design

<karl> sometimes, you can't know beforehand.

<karl> example: The Facebook like button which are tracking fb users out there even if they do not click the "like" button.

<karl> s/which are/which is/

Eisinger: designed in such a way that you don't need to prompt the user

Berjon: is that the DAP/WebApps file system API?

Fette: yes

Cooper: geo says nothing about the iframe issue, you guys took it upon yourselves to handle that

Eisinger: from an implementers' perspective, you know these things and you have to deal with them

Hazaël-Massieux: have you submitted that to the WG?

Fette: yes
... and our solution is conforming
... but had the spec been wrong, we would have ignored it

Roessler: the specification seems clear if you read it with a spec-writer's mindset. interesting that there's a need for clarification

Appelquist: there might be a disconnect between the creation of the API and the implementation
... google was a key driver in the development of the API, so we need to work on closing that loop

Jennings: problems for mobile implementation, the icon is a problem?

Eisinger: no, there wasn't much thought put into what the UI ought to do

Morris: but that's because google was against us saying anything useful about the UI

Jennings: is your complaint that we chose the wrong thing or that you couldn't figure out which is best?

Eisinger: including these sections in specs is good

Jennings: missing the details of what you were missing, we want it

Roessler: think we will come back to this in the final discussion

Appelquist: implementation experience is crucial

<dom> http://www.w3.org/2010/api-privacy-ws/slides/caceres.pdf

Marcos Caceres: Privacy of Geolocation Implementations

See also: position paper / slides

Caceres: I looked at chrome, opera, mobile safari
... firefox
... I made a critical framework including Accessibility, Control, and Confidentiality

<dom> (the book/author are "Database Nation: The Death of Privacy in the 21st Century", by S. Garfinkel)

Caceres: in iOS, all apps must get user permission

<dom> Marcos' paper: Privacy of Geolocation Implementations

<dom> it actually was The Future of Reputation: Gossip, Rumor, and Privacy on the Internet, Solove

Caceres: lots of modal dialogs lead to click fatigue, you can't see what's on the website while the dialog is up

[less scribing for Marcos as he has slides people can read]

Caceres: iOS has 50 pages of unreadable text with unclickable URLs
... it's super frustrating

<dom> "hard to read gray" (tm)

Caceres: but users probably just don't care
... revocation can only be done in a very well hidden screen
... potentially that could be improved [speaker enjoys udnerstatements]
... in v4 there's an indicator
... there's a semiotic connection there

Preibusch: I had a problem with the first dialog — does "current" location mean current = now or current as in always current

Caceres: yes, it's unclear

Cooper: does the permission time out after 24h

<dom> [I wonder if any of the implementations make a distinction between watchPosition() and getCurrentPosition() ]

<DKA> [also, it does not ask you "remember? yes/no"

Caceres: I don't know
... verdict: iOS not very accessible, some level of control, some level of confidentiality
... moving on to firefox
... more control, non-modal, access to learning more about the privacy policies

<karl> [It would be fun to be able to define shapes of location forbidden for tracking. Automatic switch… but how do you know you are out of the shape :)

Caceres: the FF guys have done great work
... but
... if you want to do more advanced tasks, you gotta go to access:config
... way too technical
... it will even warn you against hacking it
... verdict: hard to manage sites, control hard to change, hard to make confidential

Roessler: can you remind me how I can find out whether a site I'm using is tracking me?

Caceres: it's somewhere under tools
... not easy
... looking at Opera now
... similar to FF, no access to privacy policy
... reason for that is that on first use of the feature we display T+C for the service
... it's quite bad, it has links but no back button so that if you click one of the links you lose the policy and can't read the rest
... this is what happens when you mate lawyers and UI people
... we are going to fix that
... FF approach better

Appelquist: this is the geo policy right, not the requesting site's policy?

Caceres: correct
... our location provider dialog is also in opera:config
... a little more accessible than the FF version
... some built a fake Opera Unite geo provider so that people can fake their own location
... which is handy
... the contextual help for the dialog says "no data available"

Caceres: verdict: accessibility yes, control yes but hidden, confidentiality yes
... now looking at chrome
... kudos to the chrome guys for solving the embedding problem
... we people who work for browser vendors are kind of unique
... verdict: accessibility yes, control yes but no control over provider, confidentiality yes
... do we need more standards for UI? or leave it to the market?

<rbarnes> side-by-side comparison of the four desktop implementations on Mac OS: http://geopriv.dreamhosters.com/w3c/w3c-geolocation-implementation.gif

Caceres: verdict: equivalent to the padlock for https
... browsers have different icons, should we align? and if so how?
... we compete on user experience

<dom> [the limit of UI indicators is: how many of them can you usefully deploy as the number of indicators grow (e.g. with the number of APIs]

Preibusch: there's also the RSS icon where the market found a solution

Dubost: what's frustrating with multi browsers is that you have to control your preferences n times
... it would be good to have a common standard for that

Caceres: people use different browsers for different things

<darobin> [scribe agrees with karl]

Chris: (??) am I gonna to have to go through all these menus and indicators?

Caceres: depends on how much you care about revoking and various services

<rbarnes> +1 to karl / ian / scribe

Caceres: the critical side is the server-side too
... we're going to fix it over time though, don't know how but that's why we're here

<karl> [it could be multiple profiles, but a standard format across browsers for preferences including privacy settings would be super helpful]

Preibusch: I think it's okay to have complexity because at one point in time you will have an addon that hides that complexity. We can have complexity so long as there is a way for third-parties to fix it

Caceres: there is no API to access this though

Roessler: for our purpose there is a UA that has access to a sensor, there are inherent issues with that and how it interacts with the web

Rogers: in desltop we have more screen space, in mobile it's constrained
... you run the risk of having lots of blinking lights that make things hard to use

Caceres: yes, we're looking for solutions

Barnes: a lot of the implementation concerns ought to be rolled back into the spec
... it's striking how similar the implementations are

Caceres: people are violently against this, there might be a new WG?

<drogersuk> no need to create another working group

<drogersuk> confront this head on in our existing working groups

<drogersuk> (my view)

Ioannis Krontiris: W3C Geolocation API calls for Better User Privacy Protection

See also: position paper / slides

Krontiris: location privacy is not just about not revealing where you are right now, but mostly about past locations

<karl> [location privacy idea: if you are at less than 500m from this person, hide me]

Krontiris: some services don't require that you identify yourself to use geo
... eg google maps don't require a google account
... we like that usage

Krontiris: we want to provide unlinkability between the locations that have been provided
... threat comes from unique identifiers (IP addresses, esp ipv6, cookies, LSO) plus geo

<karl> [people laughing at http://ncowie.files.wordpress.com/2009/04/xfgeye1iupqro5pold.jpeg]

Krontiris: there are some defense mechanisms
... (shows the panopticlick study)
... footprinting attack remove the need for cookies
... 94% of browsers are unique if you have java/js/flash
... footprinting can therefore be used in conjunction with geo, which can lead to building location traces
... services might not know to whom the location belong, but it only takes one idenfitication to create that link
... FB Share for instance is enough
... another attack can be built on the fact that people move in restricted spaces and move in restricted patterns
... the threat becomes more interesting if we think of 3rd party geo providers who accumulate information sent to many websites
... they concentrate a lot of information
... solution approaches with privacy by policy
... but these are not tamper proof against stronger attackers not deterred by regulation
... and accidental disclosure happens
... looking at privacy by design, there's minimisation (for geo, granularity of information)
... but this does not solve the 3rd party geo provider issue
... and also only works when precise location is not required
... we could decrease footprinting, e.g. suppressing Java
... we could have a monitoring process that computes our general privacy exposure

<dom> [but who monitors the monitor? :) ]

<karl> [need to be on the browser side?]

Krontiris: maybe the W3C could enforce some additional measures for web browsers

Roessler: we might persuade, not sure we can send the conformance police

Story: what you're pointing out is that geo info is sent and can be tied to identity — what is needed is a very clear way for users to change identities, not sure it is possible
... currently at the SSL layer, browsers send certificates without asking you, it is hard to change
... FF working on an identities framework
... privacy is identity plus extra information
... if you can't change the identity you're in trouble

Roessler: no, there are ways of tracking users based on incidental information — no need for actual identity to track
... how do we avoid unintended user identification

Rogers: it's very difficult to prevent footprinting attacks
... you said you wanted to reveal when the user has revealed "too much". How? What is too much?

Krontiris: we would need a metric, we don't have it now
... it depends on the level of precision of your location, the frequency, the location of what it is (house or other)
... lots of contextual information needed
... I don't think that we have the means to do it right now

Hazaël-Massieux: related to massive data aggregration, does any implementation distinguish between getPosition and watchPosition?
... and throttling

Caceres: Opera does, though it's a bit hidden

Hazaël-Massieux: you're talking about the service provider, not at the API level

Caceres: I don't know

Preibusch: wouldn't it be great if Amaya implemented geo?

Roessler: we'd need a javascript runtime first...

Caceres: we haven't had that many issues, no showstoppers

Fette: suggestions that now that we have this experience we shold shove it in the spec

<karl> [just for clarification, Amaya is not a reference implementation, but a tool to test a few things]

Fette: I think that we're still experiementing, shouldn't overspecify
... great to document best practices, but we should be careful with detail

Barnes: I wasn't thinking about making it normative, but document it in the spec so that it is captured

Eisinger: it is important to keep in mind when writing specs that someone will have to implement it

Appelquist: this is important because geo is rechartering, this is useful feedback

<bblfish> so one issue is simply that it should be possible for the user to change their logged on identity. I think Firefox is working on the Weave plugin, which I suppose I am now thinking is an important solution.

Appelquist: what can we pull out of this that could apply to DAP, eg the camera?
... can we apply the geo lessons to camera, etc. or is it all too different?

<bblfish> then there are issues with client certs. Chrome has a bug issue on this http://code.google.com/p/chromium/issues/detail?id=29784

Eisinger: one basic thing is that it ought to be asynch

Berjon: all the DAP APIs have asynch security entry points

Dubost: do we know how many people want to share their location versus people who just want to know their location?

Eisinger: I don't have data about that

Hazaël-Massieux: notion that accessing the data locally will have a different impact than getting it off the network — though of course if you have a map it goes back to the map provider

Fette: most browsers use a remote service to get the location anyway

Roessler: that's one provider though, as opposed to an indeterminate number of sites

Story: issue with javascript and asynch, what happens if your browser is a web server and your geo data is at a URL

<darobin> [scribe sort of loses the point]

Caceres: it's always more complicated, switching to REST doesn't change the fundamental problems

Rogers: issue with passing information in URLs

Caceres: that's not a problem, the communication channel needs to be secure

<karl> http://info.gigya.com/Identity.html

<karl> Which Identities Are We Using to Sign in Around the Web?

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.134 (CVS log)
$Date: 2010/08/12 12:13:14 $