16:56:12 <RRSAgent> RRSAgent has joined #privacy
16:56:12 <RRSAgent> logging to http://www.w3.org/2016/02/25-privacy-irc
17:01:48 <npdoty> npdoty has joined #privacy
17:02:22 <npdoty> npdoty has changed the topic to: Privacy Interest Group, WebEx: https://mit.webex.com/mit/j.php?MTID=m24b262ddc3fb25b05432eb85bd431a93
17:02:56 <keiji> present+ keiji
17:03:18 <npdoty> present+ npdoty
17:03:46 <tara> Hello all - we're waiting for a few more to join on the phone before starting today.
17:06:51 <tara> Any scribe volunteers?
17:07:02 <npdoty> I can scribe, I don't think I'm as actively involved in any of today's agenda
17:07:08 <tara> Thanks, Nick!
17:07:16 <npdoty> scribenick: npdoty
17:07:20 <npdoty> present+ gnorcie
17:08:25 <npdoty> Topic: Introductions
17:08:31 <npdoty> tara: introductions from those on the phone
17:09:10 <npdoty> WebRTC chair @@, can answer specific questions about WebRTC under review right now
17:09:23 <stefanh> stefanh has joined #privacy
17:09:40 <npdoty> s/@@/stefanh/
17:10:06 <npdoty> Topic: WebRTC discussion
17:10:14 <HotBlack> HotBlack has joined #privacy
17:10:15 <npdoty> tara: a lot of activity on the mailing list on this topic
17:10:24 <npdoty> ... when is feedback most useful?
17:10:58 <npdoty> present+ fjh
17:11:02 <fjh> fjh has joined #privacy
17:11:24 <npdoty> stefanh: current status is working quite hard to reach Candidate Recommendation status, but at least a couple of months away
17:11:41 <npdoty> ... still have some issues to sort out related to control of audio/video sent to remote location
17:11:44 <chaals> Present+ chaals
17:11:57 <fjh> Present+ Frederick_Hirsch
17:11:58 <npdoty> ... meeting later tonight related to establishing connectivity to @@@
17:12:31 <npdoty> http://www.w3.org/mid/1447FA0C20ED5147A1AA0EF02890A64B374555EC@ESESSMB209.ericsson.se
17:12:46 <stefanh> s/@@@/a peer/
17:13:18 <npdoty> q+
17:13:37 <npdoty> stefanh: have been considering privacy actively over the years, not at all that we have disregarded it
17:13:45 <tara> ack np
17:14:41 <npdoty> npdoty: based on earlier privacy feedback or discussion, is there a list of privacy issues and the current status?
17:14:54 <npdoty> stefanh: most concrete thing would be to look at the privacy and security section of the draft
17:15:13 <npdoty> ... there is a lot of discussion, in issues/bugs and in connected working groups (including at IETF)
17:15:19 <npdoty> ... no strict boundaries between those
17:15:45 <keiji> q+
17:16:18 <npdoty> npdoty: will look at that section, and previous feedback/ TPAC discussion
17:16:22 <tara> ack k
17:16:48 <npdoty> keiji: in reading privacy/security considerations of the spec, group recognized the various issues, but not always clear how issues were solved or mitigated
17:17:20 <npdoty> ... change to the same-origin policy because of p2p communication
17:17:37 <gnorcie> gnorcie has joined #privacy
17:17:51 <npdoty> ... or client-side or device id leakage
17:18:19 <gnorcie> can i get in queue to speak on WebRTC?
17:18:22 <npdoty> ... document recognizes the issue but doesn't provide justification
17:18:26 <npdoty> q+ gnorcie
17:18:41 <gnorcie> thanks nick... i need to read up on w3c etiquitte
17:18:43 <gnorcie> :)
17:19:07 <tara> ack g
17:19:21 <npdoty> gnorcie: one thing I noticed was the leaking of local IP addresses
17:19:45 <chaals> q+ to point out that W3C *can* comment on user interfaces.
17:20:06 <gnorcie> * cannot
17:20:08 <gnorcie> *can't
17:20:24 <npdoty> ... also might be troubling that once a WebRTC connection has been granted, could be very difficult for a non-expert user to discover/revoke
17:20:46 <npdoty> stefanh: hear keiji in saying that we should provide more documentation on countermeasures and why we made the decision
17:21:07 <gnorcie> sorry
17:21:30 <npdoty> gnorcie: concerned that local IP address leakage could lead to physical danger to the user
17:22:01 <keiji> q+
17:22:12 <npdoty> stefanh: current design is to provide local IP address at the same time as the access to camera/microphone, so as to avoid multiple permission prompts that might confuse users
17:22:37 <npdoty> ... with the idea being that camera/microphone are typically more sensitive than IP address
17:22:38 <tara> ack ke
17:22:54 <tara> (Will get to you shortly, chaals!)
17:22:56 <npdoty> q?
17:23:02 <gnorcie> q?
17:23:48 <npdoty> keiji: the purpose of breaking the same-origin policy is @@
17:24:21 <npdoty> ... some indications of whether the privacy/security concern is acceptable
17:24:40 <npdoty> ... have live example of ad networks using WebRTC for accessing IP address
17:24:50 <npdoty> ... so should have a countermeasure in response to that, with documentation
17:25:35 <npdoty> stefanh: current design is that private local IP address is no longer accessible (for example to advertiser) unless also granting a camera/microphone permission
17:26:15 <npdoty> ... considering an option where top page would have to explicitly give the iframes permission to ask for camera/microphone
17:26:26 <npdoty> keiji: would be useful to have that documented in privacy/security section
17:26:39 <npdoty> stefanh: would be helpful if someone can consolidate these requests into text after the call
17:27:08 <npdoty> ack chaals
17:27:08 <Zakim> chaals, you wanted to point out that W3C *can* comment on user interfaces.
17:27:25 <npdoty> chaals: re gnorcie, W3C does make requirements of user interfaces in various places
17:27:44 <npdoty> ... the general plan is to be minimally constraining on UI, because heavy constraints tends to limit good UI ideas
17:28:14 <keiji> s/the purpose/the reason/
17:28:16 <npdoty> ... in areas like security/privacy, it may well be very important to describe certain requirements on UI
17:28:38 <npdoty> stefanh: WebRTC implementations vary, between Chrome and Firefox for example, on stored permissions
17:29:14 <npdoty> stefanh: getUserMedia specification which describes user interface, recommends that that only be allowed over secure (HTTPS) connections
17:29:18 <chaals> q+
17:29:22 <keiji> s/policy is @@/policy is acceptable is not clear.  It is just saying that should be O.K. because Web Socket is doing which does not make sense./
17:29:24 <chaals> q-
17:29:25 <npdoty> ... and implementations have followed
17:29:36 <keiji> q+
17:29:47 <tara> ack k
17:29:52 <npdoty> q+ on timing
17:30:07 <npdoty> keiji: as a user, want to know where I'm connecting to with a particular device input
17:30:21 <npdoty> ... or is there still not consent on what kind of information is being sent to whom?
17:30:40 <npdoty> stefanh: the user is not able to specifically consent on that.
17:31:19 <npdoty> ... once the application has access to the microphone/camera, it could record and send it to a server, which could then send it elsewhere (via websocket, or server-to-server communication)
17:31:36 <npdoty> ... and so WebRTC allows the application to set up a connection to a peer
17:31:55 <npdoty> keiji: would like to give users control over that, where their information goes
17:32:17 <npdoty> stefanh: didn't seem to make sense to control where it goes, given that the API provides recording access and there isn't a way to control what is done with the recording
17:32:55 <npdoty> keiji: a natural interest in wanting to know, when using WebEx for example, to know when I'm speaking or who it's going to
17:32:56 <npdoty> q+
17:33:10 <gnorcie> may i please be added to the queue
17:33:15 <npdoty> q+ gnorcie
17:33:16 <gnorcie> RE: webrtc
17:35:01 <tara> npdoty: Keiji is asking about the issue of the user being uncomfortable about where their data is/may be going.
17:35:32 <tara> npdoty: Which items (indicators) are going to left up to the application, and which in the user agent?
17:36:17 <npdoty> for example, camera light should be on when the camera is active, that shouldn't be left up to the application
17:36:18 <keiji> q+
17:36:24 <npdoty> q-
17:36:37 <gnorcie> q?
17:36:48 <tara> ack gn
17:37:15 <npdoty> stefan: yes, and it would be hard for the user agent to provide all the relevant information, depending on the user model in the application
17:37:30 <npdoty> gnorcie: what information is available prior to a permission prompt?
17:38:46 <npdoty> ... and for a user of Tor, what is an activist who is using this software to do when they might have to choose between communicating and revealing sensitive local information?
17:39:04 <npdoty> stefanh: a widely discussed topic, if we take this to email, can provide more specific questions and answers
17:39:06 <tara> ack ke
17:39:18 <npdoty> tara: can summarize our questions after the call
17:39:45 <npdoty> keiji: giving control to user agent or to application is a design decision
17:40:05 <npdoty> ... don't currently see the reasoning on choice of where those controls rely
17:40:18 <npdoty> ... if that is documented, we could understand better
17:40:26 <tara> q?
17:40:59 <tara> npdoty: some groups don't want to provide that detail in the spec, but might be in another document to consult.
17:41:15 <npdoty> npdoty: but it would help reviewers to be able to find it and read it somewhere
17:41:37 <npdoty> tara: thanks so much for that
17:41:46 <npdoty> ... I'll summarize after the call
17:42:03 <npdoty> ... understand the issues
17:42:50 <npdoty> stefan: regarding scheduling, have a little more time, into March certainly
17:42:51 <gnorcie> +q
17:43:10 <npdoty> Topic: Device APIs
17:43:39 <npdoty> fjh: have a Vibration Rec, and are considering updating it
17:43:49 <tara> Thanks, Stefan!
17:44:02 <npdoty> ... updating it with errata, and also could add a privacy/security section that was missing
17:44:13 <npdoty> ... and hearing now about a lot of novel attacks that use vibration
17:44:33 <npdoty> chaals: combining vibration apis with motion sensing apis that will let you uniquely fingerprint a device
17:44:51 <npdoty> ... if you can make a device vibrate, you can physically observe which device/user that is
17:45:33 <tara> https://lists.w3.org/Archives/Public/public-privacy/2016JanMar/0016.html
17:45:38 <npdoty> ... motion sensing can be used to detect things like entering pins or passwords
17:45:44 <tara> https://github.com/anssiko/vibration/commit/48489c54e0b7ed80900e0906fa79803c8fa77069
17:45:52 <npdoty> q+ on cross-device communication
17:46:03 <npdoty> fjh: group will craft language to highlight the possible threats
17:46:14 <npdoty> ... but applications will need to be aware of these things as well
17:46:23 <tara> ack gn
17:46:46 <npdoty> gnorcie: arbitrary length patterns of vibrations is possible
17:46:56 <npdoty> ... that pattern could be picked up by a second device
17:47:34 <npdoty> ... could have short or long options
17:47:52 <fjh> q+
17:48:06 <npdoty> ... but then could imagine static source code review to identify when that's happening
17:48:33 <tara> ack np
17:48:33 <Zakim> npdoty, you wanted to comment on cross-device communication
17:49:00 <tara> We had this issue with the Ambient Light spec - cross-device tracking.
17:49:07 <tara> (that was npdoty)
17:49:29 <tara> npdoty: can we at least detect if this is happening and alert user?
17:49:42 <npdoty> fjh: no problem with materially adding security considerations and make it as useful and clear to the implementers
17:49:51 <npdoty> ... more concerned about changing the API
17:50:10 <npdoty> ... as a risk management strategy
17:50:11 <chaals> q+
17:50:31 <gnorcie> +q
17:50:40 <npdoty> ... how does cross-device communication rank among other attacks related to fingerprinting?
17:51:06 <npdoty> ... seems to me that you could do a source-code examination with the current status of the API right now
17:51:10 <npdoty> ack fjh
17:51:24 <npdoty> ack gnorcie
17:51:51 <npdoty> gnorcie: people have gotten better at examining permissions, at understanding the different scopes of permissions that might be excessive
17:52:20 <npdoty> ... people are thinking creatively about exploiting when their application has some mental model for using a microphone permission, but then using it for other purposes
17:52:32 <npdoty> ... a feasible and prominent attack
17:52:46 <npdoty> q+ on cross-device vs. fingerprinting
17:52:58 <tara> ack ch
17:53:51 <npdoty> chaals: re: managing the cross-device risk, could do better at limiting *when* access is possible
17:54:31 <npdoty> ... vibration API use case is also important for a blind or visually-impaired user to explore an image
17:54:54 <npdoty> ... randomization effects would cause blurring for a user, effectively
17:55:11 <tara> ack no
17:55:14 <tara> ack np
17:55:14 <Zakim> npdoty, you wanted to comment on cross-device vs. fingerprinting
17:55:53 <fjh> Right, we should consider Cross device  tracking as a risk
17:56:00 <fjh> q+
17:56:09 <chaals> [+1 that fingerprinting and cross-device cases are different… A device might be "building surveillance system"…]
17:56:28 <fjh> agreed, fingerprinting and cross-device cases are different
17:56:38 <gnorcie> as an aside i have a blind friend I can consult with on the accessibility issue
17:56:42 <gnorcie> if desired
17:57:16 <npdoty> npdoty: difference between fingerprinting and cross-device
17:57:21 <npdoty> ... and detectability as a level of mitigation
17:57:54 <tara> ack f
17:58:41 <tara> Privacy questionnaire
17:58:49 <npdoty> fjh: thanks for including the cross-device use case, group will talk about that
17:58:57 <npdoty> Topic: Privacy questionnaire
17:59:01 <tara> Thanks for moving to GitHub!
17:59:11 <npdoty> gnorcie: questionnaire on github which might be easier for contribution
17:59:25 <npdoty> ... would like to try out the questionnaire on some of the more difficult questions
17:59:39 <npdoty> ... user interface, notice, consent, issues like that
18:00:11 <npdoty> Topic: Wrap-up
18:00:33 <npdoty> looking at March 24 or March 31, if people know of conflicts, please let us know
18:00:36 <gnorcie> I lied
18:00:39 <gnorcie> having trouble finding
18:00:43 <chaals> [24 March: W3C Advisory Committee meeting]
18:00:44 <gnorcie> I will send to ping list
18:00:50 <gnorcie> see ya'al
18:00:54 <tara> Okay, Greg!
18:01:53 <keiji> yes, I will
18:02:19 <keiji> RRSagent, make minutes
18:02:19 <RRSAgent> I have made the request to generate http://www.w3.org/2016/02/25-privacy-minutes.html keiji
18:02:57 <keiji> RRSAgent, make logs public