W3C

- DRAFT -

Privacy Interest Group Teleconference

03 Dec 2015

See also: IRC log

Attendees

Present
npdoty, christine, gnorcie, tidoust, mfoltzgoogle, tara, wseltzer
Regrets
Chair
christine
Scribe
npdoty

Contents


<christine> Hi all. We'll just wait a couple of minutes before starting.

<scribe> scribenick: npdoty

Welcome and introductions

christine: small group this week, might be getting into holiday schedule

welcome!

Presentation API - privacy considerations - further discussion

<christine> http://www.w3.org/TR/presentation-api/

http://www.w3.org/TR/presentation-api/#security-and-privacy-considerations

christine: helpful when you joined our call last time. but it sounds like you had group conversations on privacy/security while at TPAC

mfoltzgoogle: will give estimate of current status of several privacy issues
... how do we ensure that the context that renders the presentation, which is rendered onto a shared device potentially, what is the browsing context?
... don't want to leak information to other browsing contexts or other presentations
... feedback from the TAG was that there isn't any well-defined context for this already
... we want an empty local storage, cookie jar, permissions set, etc. (like a private browsing mode)
... should this interact with the Permissions API?
... currently investigating the ability to see whether a presentation screen is available already or not
... how should the spec interact with mixed content?
... how should the API interact with nested browsing contexts? does the top-level browsing context control how iframes have the ability to request presentations?
... okay to allow this by default, because risks are just annoying the user
... but top-level contexts will have the ability to blacklist or prevent its frames from using presentation
... if the controlling context is on a different device than the presentation, how do we secure the channel for messages?
... defining that protocol is out of scope, but a Community Group will define a network-level protocol for presentations, including one way to secure presentations

christine: very busy as a group
... any questions?

npdoty: questions about the cleared local state context

mfoltzgoogle: can send authentication tokens across messaging
... want to avoid leakage, but also want to ensure that this will work in the cross-device situation

<mfoltzgoogle> FYI: Our pull request that defines the empty browsing context: https://github.com/w3c/presentation-api/pull/219

tidoust: not just audio/video streaming, particularly in the cross-device case

gnorcie: more concerned about the privacy risks to the user, and streaming audio/video from the user is potentially very sensitive

tidoust: use case is video rendered from the page, not the user's microphone/camera

gnorcie: but seeing what is on my screen is also very sensitive (like documents open on the screen)

tidoust: that matches how we thought about the issue
... if there are issues we haven't addressed yet, please let us know
... don't want to miss any strong concerns

christine: so happy that your group is taking privacy/security so seriously

wseltzer: Presentation API gives a good use case for standardizing some private browsing mode, what is the minimal and safe context that can be established
... can get a standard description of that sandboxed context that works across browsers

<tidoust> [I note that the TAG discussed Private Browsing Mode in relation with the Presentation API yesterday, see draft minutes at: https://pad.w3ctag.org/p/02-12-2015-minutes.md ]

christine: is the goal that when we have another spec with this kind of scenario, then we can suggest using this text?

wseltzer: start collecting these use cases and the approach, possibly into a Note, or could possibly charter a group if there's some more complicated set of use cases about that private mode

christine: could help coordinate discussion with webappsec as well

wseltzer: PING could be helpful, particularly in setting requirements that can be used by security engineers

<wseltzer> npdoty: a few different specs raise security considerations around fullscreen

<wseltzer> ... because user might not know origin of content

<wseltzer> ... could be spoofing risk

<wseltzer> ... does presentation API consider this?

<gnorcie> can someone put me in the queue to discuss privacy questionaire?

<gnorcie> I need to leave at 1 so i want to make sure we discuss

mfoltzgoogle: UX focused on making the user know which origin is being displayed, and origin being accessible after the fact
... phishing more awkward in this scenario because the user has to grant permission for displaying on that presenter display each time

tidoust: could open a issue for notes to add there
... is there any screen that the second screen could be used by another user
... could a user be tricked into thinking that they're just doing regular browsing on the separate device

npdoty: yeah, seems like there are multiple users by definition

mfoltzgoogle: maybe have an issue about multi-user, like a second user controlling the presentation without the user's knowledge

christine: will send out email summary, to note for people who want to raise issues that now is a good time

High Resolution Time Level 2

the academic paper, http://arxiv.org/pdf/1502.07373v2.pdf

http://www.w3.org/TR/hr-time-2/

christine: request in from phillippe, note some privacy/security concerns
... the spec recommends a minimum resolution to protect against cache attacks which could identify the user

npdoty: would have to read the paper in more detail, not sure which attacks are protected by the 5 microsecond resolution change

christine: can ask phillippe if they want to come and talk to us, might explain how useful the mitigation is

npdoty: can also ask whether the academic community has provided specific review

yay, that Interest Group Draft Note published

<wseltzer> npdoty: now we have a reasonably stable doc we can ask people to review

<wseltzer> ... and we can invite people to add to github issues list, provide proposed resolution

<wseltzer> christine: should I solicit input from chairs?

<wseltzer> npdoty: yes

Moving forward with the Privacy Questionnaire

gnorcie: sent out email in things we can send as specific pull requests to the TAG for the security questionnaire
... privacy things would just be the very simple things (did you think about privacy?)
... and if you want to dive deep, including edge cases that won't be applicable for every standard

npdoty: +1, matches the TAG discussion at TPAC, where they wanted a very simple version for most, and then a drill-down

gnorcie: want to make this collaborative, rather than just my own thoughts

npdoty: I know what you mean :) yes, take that as a reminder

christine: maybe we can split up, focus on one small question at a time, looking at different documents
... even when we have best intentions, many collaborators are going to be doing this in the spare time during their day jobs
... mailing list does best with snippet discussions on particular topic

<tara> Hullo all! Sorry to join late.

christine: will schedule a time to talk with greg

npdoty: some things will need a full document review, but when we have a specific attack or a specific news item, should have that small discussion and ask whether we have general guidance about it

January 28

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/03 17:59:50 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: npdoty
Inferring Scribes: npdoty
Present: npdoty christine gnorcie tidoust mfoltzgoogle tara wseltzer
Found Date: 03 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/03-privacy-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]