W3C Privacy Workshop -- 12 Jul 2010

Karl Dubost: From Privacy To Opacity - Digital Me Management

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

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?

Discussion

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

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?

W3C Privacy Workshop

12 Jul 2010

Attendees

Contents

Karl Dubost: From Privacy To Opacity - Digital Me Management

John Carr: Child protection concerns and the new location services

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

Discussion

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

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

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

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

Patrick Kelley: User-Controllable Location Privacy

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

Jochen Eisinger: Practical Privacy Concerns in a Real World Browser

Marcos Caceres: Privacy of Geolocation Implementations

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