<trackbot> Date: 28 March 2013

<Christine> Apologies: Joe Hall

<Christine> Agenda: Agenda: 1. Welcome and introductions. 2. Media Capture Task Force* - camera and microphone access (Dominique Hazael-Massieux) 3. Reports and discussion on open action items: (Nick re privacy considerations; Frank re process document; Rigo re EME privacy review) 4. AOB

<tara> Too much management! :-)

<Christine> Agenda item 1: Welcome and introductions

<npdoty> Hannes Tschofenig, Nokia Siemens Networks

<npdoty> scribenick: tara

Tara Whalen in transition from Office of the Privacy Commisioner of Canada to Apple Inc. (on Monday).

<Christine> Those on IRC people write your name and affiliation for the minutes.

<Christine> Christine Runnegar - co-chair PING

And yes, Tara is also co-chair PING.

<wseltzer> Wendy Seltzer, W3C

Dom can you type in your name + affiliation for the minutes?

<dom> Dominique Hazael-Massieux, W3C

<npdoty> Nick Doty, W3C

<JC> JC Cannon Microsoft

<Ashok_Malhotra> Ashok Malhotra, Oracle

<Bert> Bert Bos, W3C, Style Activity Lead, but here today for an EU project called STREWS about security in WebRTC.

<dom> Privacy & Media Capture

Media Capture Task Force Agenda Item...

<wseltzer> [slide 2]

Dom presenting ongoing work - for web apps and sites to get access to camera + mikes on devices.

Media Capture Task Force is doing this work.

joint task force between Device APIs and WebRTC Working Groups

Same API used for screen sharing

This presentation mostly on camera and microphone

media stream can be used locally - like an application that can take picture of yourself.

But can send audio/video stream to remote party

"Skype inside the browser."

Not only remote party that can get handle on media streams, but the service operator

Adding access control mode - if service operator provides option, you can have prevent access from that outside party.

Q from Hannes: you couldn't know who you were sharing data with unless you knew implementation (? was this SIP?)

How does this work in this context - how to provide right amount of detail to user?

Hard part - how to determine that you are sending to the party you *think* it is (e.g., sending privately to attacker)

<npdoty> (I can't find anything in the getUserMedia spec on HTTPS, SSL, TLS, encryption, key exchange...)

Identity solution - third-party identity provider (like Facebook) provide assertion to verify identity; rely on identity mechanisms.

Wendy: key exchange with the other party in private mode to keep the intermediary out, is that right? Dom: Yes.

In terms of how you would be exposed - service provider would allow opt-in to that mechanism; browser would allow extra confidentiality for communications.

<dom> https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-rtcweb-generic-idp.txt

<wseltzer> [Slide 3]

Don't want just anyone getting access to your media stream; user confirms that they want to share access.

Consent granted through browser chrome

Can share multiple devices.

Can specify which device to share.

<wseltzer> [slide 4]

browser will give unique ID for that device that remains constant across sessions.

Reason for unique ID is to make it possible to automatically recreate same state as the last session.

Same setup of cameras, etc (could be complex configuration)

Fingerprinting risk? Recommend that the ID be scoped by origin.

Nick: what is purpose of the ID at all? Can't browser remember these details?

Dom: Example why webapp needs to know: situation w/3 cameras.

One each left, middle, right -- browser won't understand this type of detail.

(Context-specific.)

Also can be much more complex in nature - mixing streams, etc.

Can I get a temporary scribe for a minute?

<npdoty> npdoty: couldn't you accomplish that with an ordered list instead?

Dom: to be clear, am presenting current situation. Getting outside perspective will help and change the approach.

(Nick, are you scribing for a moment?)

Thanks!

<npdoty> scribenick: npdoty

<wseltzer> [slide 5]

dom: mentioned unique ID per device, but also enable service operators to collect the name of every device, once the user has granted access to any device
... a user has started using the video chat service, and you want to move to a separate camera in another part of the room
... web app needs to know that there is another camera, and a name the user can relate to
... screenshot of what it looks like in a Google Hangout, for example
... need a list of all connected media capture devices
... obviously has possible important privacy impact

<wseltzer> [slide 6]

dom: very early work on making the same API enable screen sharing
... camera and microphone already potentially intrusive, sharing your screen has very interesting possible intrusions
... violate the same-origin policy
... likely come with different restrictions, but this is very early work

christine: silence a sign that we're all listening very closely :)

<wseltzer> [slide 7]

dom: summary of privacy risks already identified and discussed (though perhaps not to our satisfaction)
... risk of surveillance, spying on the user
... important that the user understand that the camera/mic are in use, and that the other user and the service operator may have access
... fingerprinting (common with device APIs), associating the attached devices to identify a particular user
... have to have shared at least one device before this is possible, debated quite a bit in our group

<tara> Thanks Nick - I can take back over.

dom: by having human friendly names, you learn about, for example, purchasing power

<scribe> scribenick: tara

Those are the three main risks identified so far - are likely more.

Giving access to came + mic is not something you would do lightly; is compromise to be made.

[slide 8]

Trying to develop means to tell user that they may be being recorded.

Lot of issues are UI considerations - so not in scope directly of the WG.

This is common issue with many APIs.

How to provide indicator that you are being recorded; also this could be one of many indicators.

Don't know how scalable this solution this is.

<Robin_Wilton> And the mechanism is likely to rely on the good behaviour of the app/plugin/platform...

The common tradeoff of UX versus privacy (information overload).

[slide 9]

What we want help on

Want expert insights from privacy community - who have good grasp of both the risks and the technological constraints.

No "privacy considerations" in this document yet, but that doesn't mean one is not planned.

Fingerprinting was heavily discussed, for example.

Would like more explicit guidance on this issue.

<Christine> Please type your question in Robin

<Robin_Wilton> Sorry about the audio, there :^(

Nick: how were UI discussions included in discussion (out of scope?).

<Robin_Wilton> My question: have you given thought to how "bad apps" can be prevented from activating camera/mic without giving the user any indication?

Dom: don't have anything formal; concerned that there may be no good identified solution available.

At TPAC, was some discussion about turning a light on, for example.

<npdoty> the light next to the camera is a *great* example, though

Dom: response to Robin's Q:

Right now, you simply cannot activate camera + mic w/out explicit user consent.

Once consent is granted, then visual indicator turns green (e.g., to show camera access is on).

<Robin_Wilton> OK - thanks Dom

Use "pulsing" recording light, to get user attention.

[slide 10]

Schedule: last forecast call in June/July

Firefox, Chrome & Opera have already releases with that API

Hannes: this is being deployed, but the UI parts are not yet set.

<JC> +q

There is a UI to show which devices you have granted access to?

Ans: hasn't been quite worked out yet. Sharing camera with site is different from one user.

In terms of "out of scope" - this is more something for [couldn't make out who?] to address.

<Christine> Time check - we have 10 minutes left

<npdoty> I think dom's point is that it may be more likely to provide best practices to implementers, rather than the WG specifying it

[slide 11]

Recording captured media streams mayhave additional privacy impact.

Also P2P communication across browsers raises its own set of issues (e.g., backchannels).

But focusing on media capture to get some feedback.

Christine: Have identified need to PING to help w/ this emerging issue.

<JC> Can you elaborate on work Chrome, Safari and Firefox have done?

<JC> You can send an email as well

Christine: as with Device API specs (ambient light) - get group of volunteers to review the specs

Also consider what questions might be included in privacy considerations.

Hannes volunteered.

Any other volunteers?

<npdoty> ACTION: hannes to lead privacy review on Media Capture [recorded in http://www.w3.org/2013/03/28-privacy-minutes.html#action01]

<trackbot> Created ACTION-3 - Lead privacy review on Media Capture [on Hannes Tschofenig - due 2013-04-04].

<JC> Not sure of question, but can help

Will be followup emails about this - to gather more reviewers.

<npdoty> action-3: JC may be able to help

<trackbot> Notes added to ACTION-3 Lead privacy review on Media Capture.

<Robin_Wilton> Tara - "recording" is a point at which control *may* be impossible to retain... (for instance, if I point an offline video camera at the screen which is displaying the webcam feed...) :^(

Bert's question will be addressed on email list.

Action items

Thanks, Dom!

<npdoty> http://www.w3.org/Privacy/track/actions/open

Frank: update by email

Rigo not on call...

Report from others?

Tracker instance has been opened (see link from Nick).

<npdoty> http://w3c.github.com/fingerprinting-guidance/

NIck is tracking item already - gathering list of questions for Hannes....

<npdoty> https://github.com/w3c/fingerprinting-guidance

Also Nick is working on the fingerprinting guidance (see github link).

You can work with github to contribute.

See TAG document on fingerprinting - in github (may fork as document evolves).

<Christine> Here is the link from Hannes - https://docs.google.com/document/d/1uFyPErULC0gaYv54yxYqTdlOcQavlLme4SvyGsKCCcI/edit?usp=sharing

Hannes: have been talking about what would go into guidance document; has provided initial thoughts (see above link).

<npdoty> we may want to share these links and provide a chance for feedback on the mailing list

Need call for next month.

April 25?

<npdoty> April 25 works for me

I have a program committee meeting that day.

<npdoty> dom++, thank you

(But I am but one person.)

+1 to domthanks.

Christine: we need to push forward discussions on the documents under development before next call.

AOB?

Thanks all, until next month - and please volunteer!

<Robin_Wilton> Thanks everyone

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Firefox & Opera are working to this schedule [do I have that right?]/Firefox, Chrome & Opera have already releases with that API/
Found ScribeNick: tara
Found ScribeNick: npdoty
Found ScribeNick: tara
Inferring Scribes: tara, npdoty
Scribes: tara, npdoty
ScribeNicks: tara, npdoty

WARNING: Replacing list of attendees.
Old list: +358.504.87aaaa
New list: +1.613.304.aaaa npdoty Christine +358.504.87aabb tara Hannes wseltzer dom [Microsoft] Bert Ashok_Malhotra? Ashok_Malhotra

Default Present: +1.613.304.aaaa, npdoty, Christine, +358.504.87aabb, tara, Hannes, wseltzer, dom, [Microsoft], Bert, Ashok_Malhotra?, Ashok_Malhotra
Present: +1.613.304.aaaa npdoty Christine +358.504.87aabb tara Hannes wseltzer dom [Microsoft] Bert Ashok_Malhotra? Ashok_Malhotra
Found Date: 28 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/28-privacy-minutes.html
People with action items: hannes