SV_MEETING_TITLE -- 25 Feb 2016

<tara> Hello all - we're waiting for a few more to join on the phone before starting today.

<tara> Any scribe volunteers?

I can scribe, I don't think I'm as actively involved in any of today's agenda

<tara> Thanks, Nick!

<scribe> scribenick: npdoty

Introductions

tara: introductions from those on the phone

WebRTC chair stefanh, can answer specific questions about WebRTC under review right now

WebRTC discussion

tara: a lot of activity on the mailing list on this topic
... when is feedback most useful?

stefanh: current status is working quite hard to reach Candidate Recommendation status, but at least a couple of months away
... still have some issues to sort out related to control of audio/video sent to remote location
... meeting later tonight related to establishing connectivity to a peer

http://www.w3.org/mid/1447FA0C20ED5147A1AA0EF02890A64B374555EC@ESESSMB209.ericsson.se

stefanh: have been considering privacy actively over the years, not at all that we have disregarded it

npdoty: based on earlier privacy feedback or discussion, is there a list of privacy issues and the current status?

stefanh: most concrete thing would be to look at the privacy and security section of the draft
... there is a lot of discussion, in issues/bugs and in connected working groups (including at IETF)
... no strict boundaries between those

npdoty: will look at that section, and previous feedback/ TPAC discussion

keiji: in reading privacy/security considerations of the spec, group recognized the various issues, but not always clear how issues were solved or mitigated
... change to the same-origin policy because of p2p communication
... or client-side or device id leakage

<gnorcie> can i get in queue to speak on WebRTC?

keiji: document recognizes the issue but doesn't provide justification

<gnorcie> thanks nick... i need to read up on w3c etiquitte

<gnorcie> :)

gnorcie: one thing I noticed was the leaking of local IP addresses

<gnorcie> * cannot

<gnorcie> *can't

gnorcie: also might be troubling that once a WebRTC connection has been granted, could be very difficult for a non-expert user to discover/revoke

stefanh: hear keiji in saying that we should provide more documentation on countermeasures and why we made the decision

<gnorcie> sorry

gnorcie: concerned that local IP address leakage could lead to physical danger to the user

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
... with the idea being that camera/microphone are typically more sensitive than IP address

<tara> (Will get to you shortly, chaals!)

keiji: the reason of breaking the same-origin 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.
... some indications of whether the privacy/security concern is acceptable
... have live example of ad networks using WebRTC for accessing IP address
... so should have a countermeasure in response to that, with documentation

stefanh: current design is that private local IP address is no longer accessible (for example to advertiser) unless also granting a camera/microphone permission
... considering an option where top page would have to explicitly give the iframes permission to ask for camera/microphone

keiji: would be useful to have that documented in privacy/security section

stefanh: would be helpful if someone can consolidate these requests into text after the call

<Zakim> chaals, you wanted to point out that W3C *can* comment on user interfaces.

chaals: re gnorcie, W3C does make requirements of user interfaces in various places
... the general plan is to be minimally constraining on UI, because heavy constraints tends to limit good UI ideas
... in areas like security/privacy, it may well be very important to describe certain requirements on UI

stefanh: WebRTC implementations vary, between Chrome and Firefox for example, on stored permissions
... getUserMedia specification which describes user interface, recommends that that only be allowed over secure (HTTPS) connections
... and implementations have followed

keiji: as a user, want to know where I'm connecting to with a particular device input
... or is there still not consent on what kind of information is being sent to whom?

stefanh: the user is not able to specifically consent on that.
... 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)
... and so WebRTC allows the application to set up a connection to a peer

keiji: would like to give users control over that, where their information goes

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

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

<gnorcie> may i please be added to the queue

<gnorcie> RE: webrtc

<tara> npdoty: Keiji is asking about the issue of the user being uncomfortable about where their data is/may be going.

<tara> npdoty: Which items (indicators) are going to left up to the application, and which in the user agent?

for example, camera light should be on when the camera is active, that shouldn't be left up to the application

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

gnorcie: what information is available prior to a permission prompt?
... 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?

stefanh: a widely discussed topic, if we take this to email, can provide more specific questions and answers

tara: can summarize our questions after the call

keiji: giving control to user agent or to application is a design decision
... don't currently see the reasoning on choice of where those controls rely
... if that is documented, we could understand better

<tara> npdoty: some groups don't want to provide that detail in the spec, but might be in another document to consult.

npdoty: but it would help reviewers to be able to find it and read it somewhere

tara: thanks so much for that
... I'll summarize after the call
... understand the issues

stefan: regarding scheduling, have a little more time, into March certainly

<gnorcie> +q

Device APIs

fjh: have a Vibration Rec, and are considering updating it

<tara> Thanks, Stefan!

fjh: updating it with errata, and also could add a privacy/security section that was missing
... and hearing now about a lot of novel attacks that use vibration

chaals: combining vibration apis with motion sensing apis that will let you uniquely fingerprint a device
... if you can make a device vibrate, you can physically observe which device/user that is

<tara> https://lists.w3.org/Archives/Public/public-privacy/2016JanMar/0016.html

chaals: motion sensing can be used to detect things like entering pins or passwords

<tara> https://github.com/anssiko/vibration/commit/48489c54e0b7ed80900e0906fa79803c8fa77069

fjh: group will craft language to highlight the possible threats
... but applications will need to be aware of these things as well

gnorcie: arbitrary length patterns of vibrations is possible
... that pattern could be picked up by a second device
... could have short or long options
... but then could imagine static source code review to identify when that's happening

<Zakim> npdoty, you wanted to comment on cross-device communication

<tara> We had this issue with the Ambient Light spec - cross-device tracking.

<tara> (that was npdoty)

<tara> npdoty: can we at least detect if this is happening and alert user?

fjh: no problem with materially adding security considerations and make it as useful and clear to the implementers
... more concerned about changing the API
... as a risk management strategy

<gnorcie> +q

fjh: how does cross-device communication rank among other attacks related to fingerprinting?
... seems to me that you could do a source-code examination with the current status of the API right now

gnorcie: people have gotten better at examining permissions, at understanding the different scopes of permissions that might be excessive
... 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
... a feasible and prominent attack

chaals: re: managing the cross-device risk, could do better at limiting *when* access is possible
... vibration API use case is also important for a blind or visually-impaired user to explore an image
... randomization effects would cause blurring for a user, effectively

<Zakim> npdoty, you wanted to comment on cross-device vs. fingerprinting

<fjh> Right, we should consider Cross device tracking as a risk

<chaals> [+1 that fingerprinting and cross-device cases are different… A device might be "building surveillance system"…]

<fjh> agreed, fingerprinting and cross-device cases are different

<gnorcie> as an aside i have a blind friend I can consult with on the accessibility issue

<gnorcie> if desired

npdoty: difference between fingerprinting and cross-device
... and detectability as a level of mitigation

<tara> Privacy questionnaire

fjh: thanks for including the cross-device use case, group will talk about that

Privacy questionnaire

<tara> Thanks for moving to GitHub!

gnorcie: questionnaire on github which might be easier for contribution
... would like to try out the questionnaire on some of the more difficult questions
... user interface, notice, consent, issues like that

Wrap-up

looking at March 24 or March 31, if people know of conflicts, please let us know

<gnorcie> I lied

<gnorcie> having trouble finding

<chaals> [24 March: W3C Advisory Committee meeting]

<gnorcie> I will send to ping list

<gnorcie> see ya'al

<tara> Okay, Greg!

<keiji> yes, I will

- DRAFT -

SV_MEETING_TITLE

25 Feb 2016

Attendees

Contents

Introductions

WebRTC discussion

Device APIs

Privacy questionnaire

Wrap-up

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output