W3C

- DRAFT -

Privacy Interest Group Teleconference

23 May 2013

See also: IRC log

Attendees

Present
+358.504.87aaaa, npdoty, hannes, christine, +1.650.283.aabb, tara, Wendy, JC, marcosc, yrlesru
Regrets
Erin_Kennedy, Karima_Boudaoud
Chair
tara
Scribe
JC, npdoty

Contents


<trackbot> Date: 23 May 2013

<tara> Why, yes! Is muted now. :-)

<christine> Agenda:

<christine> 1. Welcome and introductions. 2. Introduction to The app: URI scheme [1] and privacy considerations (Marcos Caceres from the Sys Apps WG) 3. Follow-up to recent emails regarding the text for privacy considerations for Ambient Light Events and Proximity Events 4. Privacy guidance documents (Privacy Considerations; Fingerprinting; Process) 5. getUserMedia privacy review (update) 6. EME privacy review (update) 7. AOB

<christine> Would someone be kind enough to volunteer to scribe?

<christine> Who hasn't scribed for PING before?

<yrlesru> yrelsru is Frank Dawson

<JC> I can scribe

<tara> Thanks!

<christine> Big thank you JC

<wseltzer> scribenick: JC

Christine: Call for introductions for new people

<christine> Hi JC . Tara is chairing today.

<yrlesru> Frank Dawson just joined voice call.

Marcosc: I work for Mozilla in web API team. Work on Firefox OS for mobile
... enables apps of which some rely on API, which I will discuss today

app URI scheme

Christine: Let's move to first agenda item

<marcosc> link: http://www.w3.org/2012/sysapps/app-uri/

Marcosc: There is a newish class of app emerging in last 6-8 years, HTML & Javascript calls
... packaged into a zip file and a browswer can find the main file and startup the application
... a crucial part of the app is the ability to interact with services on the web
... though they are not linkable they need to interact with web technologies
... HTML5 and related techs define relationship around HTTP semantics
... for web apps need something similar to the ability to run HTTP without bringing in a web server
... the challenge is we have one instance of an application running it has to look like its running from one origin
... if there are multiple apps running it can look like there are running from dfferent locations
... we usage different IDs for each app
... each app can have its own cookie and storage to avoid overwriting each other's data
... the privacy issue arises from the URI scheme
... every person gets a unique number which makes for supertracking
... Bjorn has mentioned that it may not matter as an ID generator could be created to map IDs
... is this a problem that we should change?
... or address
... Windows 8 and Chrome have similar features

Tara: Ready for feedback or questions

Christine: Can you give me a practical example of multiple instances running at same time

Marcosc: Do you know dashboard widgets that come with Macs
... you can spawn two instances of calculator or other app
... that is the idea

Npdoty: Do we need a unique identifier?
... it seems like it is needed so each instance needs its own storage
... does that mean they need a unique ID?

Marcosc: You are right. From a dev point of view it is not needed e.g. files dont need them
... the reason they are needed is because browsers are designed to use a ID like domain name

<marcosc> app://foo/myfile.js

Marcosc: it would mean writing a great chunk of web browsers to get around this

<npdoty> but does it need to be a *persistent* identifier? or could it be just as opaque if it changed on every run?

<marcosc> app://myfunkyapp/myfile.js

Marcosc: the alternative is to use a string like app://myfunkyapp/myfile.js
... if I get rid of multiple instance problem that would solve problem

npdoty: does the identifier need to be persistant?

Marcosc: No, it doesn't. the app would need to regenerate it
... this is something browsers need to work out though

Npdoty: that's onlye one mitigation
... Even if we avoided this the app could create a unique ID

Marcosc: My proposal was to be able to clear all history and start with a new number
... let's say its a FB app running. You would get the same cookie, but login identifies the user
... It is fair to clear all data and start with a new ID

Npdoty: was there pushback?

Marcosc: Yes, because users would lose their data
... I think that is okay to lose the data. It shouldn't be that traumatic
... the dev can provide mechanisms to backup data

Wseltzer: The app serves as origin and acts as server?

Marcosc: Yes

Wseltzer: that is counter intuitive as far as user agent interaction.
... I like the idea of clearing the data. Is there room for other best practices?

Marcosc: We could ask user if the domain can track location.
... In that situation it would not be good to show random set of numbers

Wseltzer: is there a way to get the UA to translate the data back

<npdoty> +1, these would make for horribly ugly Geolocation permissions dialogs

Marcosc: the app ships with a manifest file so we can determine the name of the app

<npdoty> ..... assuming the name is correct

<npdoty> scribenick: npdoty

hannes: for the uri scheme, there is a security aspect (the same-origin policy)
... to have the functionality of a port number to deal with multiple instances of the same application running on the host
... the port number concept illustrates that you can use regular numbers without exposing a long identifier
... only needs to be local to the host, not globally unique
... re: security aspects, if the app wants to communicate with someone else and store data, they will need concepts beyond this identifier -- you won't want to base your security on this made-up identifier, not a cookie-like equivalent
... uuid wouldn't be enough to let the application be reachable, no resolution mechanism to translate the ID into an IP address for example

marcosc: outside of scope, but it may relate back. instead of using an ID, using a human-readable string
... in making an HTTP request, would send an Origin header, but send it with a random ID, then the server won't know who you are
... there is a proposal that applications should be able to fake their origin

<marcosc> app://google.com

marcosc: instead of faking an origin like http://google.com, instead: app://google.com
... fear of hijacking, how you would download an app, verify the app and send it to the server as authorized
... could eventually come back into the app uri scheme
... has to be part of a complete solution

hannes: have you written these different aspects already? a somewhat complicated story, same origin in the context of downloaded application
... same-origin intended to protect against a browser sending off data to some other server
... downloaded applications historically could send data to any place

marcosc: these are not supposed to do that
... at least in Mozilla, came up with a System XHR which does contact any server you want, not a great solution
... spec at the moment is limited to the use case where a developer wants to access or save something locally to the package, which all rely on origin
... I'm treating them as outside the scope, because these applications can't yet communicate with the outside world
... enable with CSP and CORS
... in theory the app uri scheme can be used with CORS, no reason why it can't; in theory it works quite nicely with CSP

hannes: will have a look at the document, seems like a complicated story

marcosc: that story is not covered yet, but sysapps will need to address that in one spec eventually
... if you have any idea about that, it would be a huge help, but a broader scope

tara: could use more discussion on the mailing list about this?

marcosc: I think so, the points have been raised already, but can discuss more on the list
... at least as it evolves, if we do address using CORS or faking origins, looking at those implications and possible solutions
... could we somehow get a token from the server that owns a domain to prove this app is 'okay'

hannes: that @@@ exists

marcosc: can you point me to papers or examples?

tara: encourage more of this discussion on the list, and if we have more extensive resources

+1, thanks marcosc!

tara: thanks, marcos!

Ambient Light / Proximity follow-up

christine: security and privacy considerations proposed by Frederik
... nick raised some questions, then addressed by Frederik
... spec updated by the editor, and then some editorial changes by fjh
... we should provide our comments before next week

<christine> https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.html#security-and-privacy-considerations

<christine> https://dvcs.w3.org/hg/dap/raw-file/default/light/Overview.html#security-and-privacy-considerations

tara: please do send those comments along

Document Status

npd: on fingerprinting, no new updates on the fingerprinting-guidance text in particular
... but the app: uri scheme we just talked about might actually be a great example for us to discuss in terms of cookie-like

<christine> http://www.tschofenig.priv.at/privacy-questions-markup.doc

hannes: went through the list of privacy questions, a great list, to see how they might work in our privacy considerations
... some of them already exist; a few where I have clarity questions (from Karl D. in particular)
... some questions were new, which I made as updates to the document
... some questions I didn't have answers for (from Nick and Wendy)
... it would be nice to get some reviewers for an updated version of the document, further room for improvement
... included links to Nick's fingerprinting document for definitions

yrlesru: Specification Privacy Assessment document
... working with Nick to get that up on GitHub, should be there soon hopefully
... haven't received any comments on that

tara: looking for comments now? wait to get it on GitHub?

yrlesru: should be up there this week and then ask for comments

tara: want to make sure we're getting the feedback you all need

<christine> Updated privacy guidance document is here: http://www.tschofenig.priv.at/w3c-privacy-guidelines.html

npd: examples of the new questions we need answers for

hannes: does the service/browser provide some information so that the user can adjust their behavior?
... background events firing in all browser contexts allow correlation of users across contexts, not sure how to answer that yet
... david asked a couple of questions about correlation, so added some text on that
... user preferences / user control; who can have access to the data, how visible is that to the user
... can code send signals to nearby devices, an interesting thought

npd: great, thanks. hope we can be more systematic than just the questions that we have asked so far, maybe Frank's document can help with that

hannes: I've tried to provide some clustering, but Frank's document might be more principled with regard to process

yrlesru: had sent around one document with Security and Privacy Considerations
... a PIA template, will dig that up and post to the list

christine: the Privacy Impact Assessment Template <author unknown>

yrlesru: might be a nice way of grouping the questions; engineers may prefer a checklist like a pilot, rather than a formal process
... checklist of questions might be more operational

tara: thanks all, can give some time for Frank on the next phone call

Quick Updates on ongoing privacy reviews

hannes: a bit behind on getUserMedia privacy review
... have looked at the document, somewhat similar to the Geolocation privacy assessment
... with the difference that you can't as easily utilize data minimization because reducing the quality of audio in a conference call isn't all that useful
... maybe someone can help me with a short write-up? tara: volunteers?

christine: joe might have offered to help previously, to review something that's been drafted
... hard because the TPWG is taking up a lot of privacy people's time

tara: understanding that we all have a lot of work; any assistance is much appreciated

wseltzer: EME, would love to get volunteers to help look into the privacy considerations in encrypted media
... a rich spec for investigation, nothing new to report

<christine> Can we have draft privacy reviews done before the next call?

<wseltzer> christine, no

npd: timeline for EME? are there particular people we could recruit inside that group?

<wseltzer> Wseltzer: good questions

wseltzer: a long potential timeline, going through bugs, etc.; don't know of people in particular, but we should enjoin them to encourage participation

next call?

<christine> I prefer 20/6

<christine> If it is 27/6, I am may be in transit or still in a far east time zone

<yrlesru> Thx. Bye.

how about tentatively June 20th, and north-europeans should let us know about their summer party schedules

tara: thanks all

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-05-23 17:02:09 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/linable/linkable/
Succeeded: s/interach/interact/
Succeeded: s/Christine:/Tara:/
Succeeded: s/Tara:/Wseltzer:/
Found ScribeNick: JC
Found ScribeNick: npdoty
Inferring Scribes: JC, npdoty
Scribes: JC, npdoty
ScribeNicks: JC, npdoty
Default Present: +358.504.87aaaa, npdoty, hannes, christine, +1.650.283.aabb, tara, Wendy, JC, marcosc, yrlesru
Present: +358.504.87aaaa npdoty hannes christine +1.650.283.aabb tara Wendy JC marcosc yrlesru
Regrets: Erin_Kennedy Karima_Boudaoud
Found Date: 23 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/23-privacy-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]