IRC log of privacy on 2016-02-25

Timestamps are in UTC.

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