See also: IRC log
<trackbot> Date: 23 May 2013
<tara> Why, yes! Is muted now. :-)
<christine> 1. Welcome and introductions. 2. Introduction to The app: URI scheme  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
<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
Christine: Let's move to first agenda item
<marcosc> link: http://www.w3.org/2012/sysapps/app-uri/
Marcosc: There is a newish class
... 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
... 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
... the reason they are needed is because browsers are designed to use a ID like domain name
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: 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
... 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?
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
... 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: instead of faking an
origin like http://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
... 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
... 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!
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
tara: please do send those comments along
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
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
... 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
... 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
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
... 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
... 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
<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
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]