Privacy Interest Group Teleconference -- 05 Apr 2018

<tara> IETF PING f2f

<tara> discussed the hackathon ahead of IETF meeting

<tara> Three projects - analysis of IETF mailing lists (npdoty)

<tara> error code 451

<tara> and WebRTC implementations in different browsers - when/how disclose local IP address

<tara> information to be circulated in future

<tara> also: device API group is up for re-charter -- see agenda item today

<tara> Consider getting rep for next PING call

<tara> fingerprinting doc - move towards group note (npdoty)

<tara> error code 451: content blocked -- is there an alternative

Device and Sensors Working Group: https://www.w3.org/2009/dap/

<tara> re: device API WG: can consider the *charter* as place to push privacy

<tara> also: adblock detection arms race discussed

<wseltzer> https://w3c.github.io/dap-charter/DeviceAPICharter.html

<tara> some sites detecting private browsing mode

<tara> npdoty: user permissions came up during httpbis

<tara> can we coordinate user permission work across different WGs

<tara> suggestion: can we have guest speakers alternating between review discussions, as way of keeping things interesting

yay for christine and weiler !

<tara> Sam Weiler has agreed to help Christine out on questionnaire

<tara> For PING & privtech community in general: could have "standing instance" at IETF hackathon doing public interest-type work

<tara> Can plan for Montreal IETF, using lead time we have, can rope in local community & others

<tara> - Article 19 doing work in this area

<tara> Christine: yes, we paired with many others, looking for more partners

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

<scribe> scribenick: npdoty

tara: Sensor APIs have published several Candidate Recommendations, looking for feedback
... and recharter as well might be an opportunity

<jnovak_> https://github.com/w3c/gyroscope/issues/27

npdoty: have we tracked previous comments we've raised with the sensors folks?

jnovak_: reference particular known mitigations for certain sensors

<jnovak_> https://github.com/w3c/accelerometer/issues/30

jnovak_: filed issues on gyroscope and accelerometer, which have been closed and should be addressed in the CRs

christine: look back to see if all the issues identified were made github issues
... read through the CRs to see how they have described the privacy risks and mitigations
... I'll plan to do some of that myself
... make sure the mitigations are clearly documented

tara: invite to an upcoming call?

christine: come prepared, have a couple people who have reviewed them already

feedback requested by 1 May 2018

jnovak_: I'll volunteer to help review these
... how can we better incorporate privacy in rechartering of this sensors work?

https://w3c.github.io/dap-charter/DeviceAPICharter.html

wseltzer: says in stronger language that privacy and security need to be addressed, given the sensitive nature

<jnovak_> "Given the sensitive nature of the data and sensors to which these APIs grant access, these APIs must be both secure and privacy-enabling by design, based on the current Web browser security model. When existing browser-based privacy and security metaphors apply, the WG will endeavour to reuse them. When those metaphors do not apply, the WG will explore innovative security and privacy mechanisms."

<wseltzer> [[Given the sensitive nature of the data and sensors to which these APIs grant access, these APIs must be both secure and privacy-enabling by design, based on the current Web browser security model. When existing browser-based privacy and security metaphors apply, the WG will endeavour to reuse them. When those metaphors do not apply, the WG will explore innovative security and privacy mechanisms.]]

wseltzer: "explore innovative privacy and security mechanisms"
... will still need PING experts to contribute to accomplish that

<tara> Okay, thanks!

jnovak_: based on what we've done so far on sensors api, is there anything we can learn about a baseline or goals for privacy support, ensuring new sensors don't expose new fingerprinting surface without mitigations, e.g.
... having explicit goals in the conversation early
... maybe not in the charter, but have a meeting early on in the newly chartered group, prior to new sensor specs
... these are the goals that PING has for new sensor specs

mikeoneill: are they using the Permissions API now?
... browsers would prompt by default for the first use
... do embedded elements have the same access as first-party elements?

[not sure about the answers]

mikeoneill: we could recommend that for future APIs

jnovak_: permissions is a good back stop, if privacy risks can't be mitigated otherwise

mikeoneill: important that the user is made aware of what's going on, and have a chance to stop it

npdoty: many APIs use a permissions model, even if it's not handled through the separate Permissions API

christine: mikeoneill and jnovak could write up this piece of the general privacy guidance for web specifications
... not urgent, since it's already taken a long time for us
... follow up email offlist

wseltzer: weiler is trying to put together workshop on permissions and capabilities, what's the overall flow that APIs should use when they want to ask user permission for more sensitive access
... recommendations to API designers and UAs, on how to ask for user permission
... a cross-WG need

mikeoneill: scheduling?

wseltzer: will have at least 2 months notice for a workshop

invite help in shaping the workshop, identifying hosts

<wseltzer> https://github.com/w3c/strategy/issues/78

christine: there might be US West Coast hosts outside of Silicon Valley

wseltzer: W3C workshop model, 1-2 days in person discussion
... weiler is the point of contact

<wseltzer> [I'll invite Sam to send more information here]

Horizontal Reviews

<tara> https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0000.html

Pointer Events Level 2

<tara> https://www.w3.org/TR/2018/WD-pointerevents2-20180404/

tara: they have a security and privacy considerations section that they didn't have previously

(which follows the basic security questionnaire)

christine: worth looking at, as a kind of sensor, to make sure it has appropriate mitigations

<tara> jnovak: there are some issues worth highlighting: exposes unique identifier; pointing device as fingerprinting

<tara> Also what does the device reveal about user, e.g., assistive tech user

jnovak_: 3 areas of risk, 1) exposes a unique identifier and not clear on when to rotate it, 2) significant fingerprinting surface about how the user interacts including angle and pressure, 3) could reveal use of assistive technologies

<tara> Perhaps implied by interactive behaviour

<jnovak_> pointerId

<jnovak_> A unique identifier for the pointer causing the event. This identifier MUST be unique from all other active pointers in the top-level browsing context (as defined by [HTML5]) at the time. A user agent MAY recycle previously retired values for pointerId from previous active pointers, if necessary.

tara: what's the most effective way to get comments back to them
... seem to prefer email over github issues

<jnovak_> The "MAY" seems ... concerning from a privacy perspective was one of initial thoughts

tara: separate call might be useful?

mikeoneill: +1 on fingerprinting risk, and disclosure of pointer device

<tara> Disposition of horizontal review issue for TTML2

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

https://www.w3.org/TR/2018/CR-ttml2-20180313/#security-and-privacy

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

tara: how do we wrap up this particular item?
... nice to have a method (as suggested by chaals) to have a process for wrapping up an issue to note that it's resolved or not

<wseltzer> +1

<tara> Idea: have responsible person for the issue - could be the one raising it -- who could weigh in quickly

<tara> e.g., "looks good!" or "back to PING", etc

here's the github issue from our comments to them last July: https://github.com/w3c/ttml2/issues/405

npd: +1 to have an issue/review owner

https://www.w3.org/2017/07/27-privacy-minutes.html

npdoty will review

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

<jnovak_> Open:

<jnovak_> https://github.com/WebAudio/web-audio-api/issues/1500

<jnovak_> Closed:

<jnovak_> https://github.com/WebAudio/web-audio-api/issues/1499

<jnovak_> https://github.com/WebAudio/web-audio-api/issues/1498

jnovak_: opened 3 separate bugs, and they pinged me to check whether they were addressed
... maybe we should have a process where we check on closed github issues

christine: useful to have a process, and encouraging that people are starting to come back to see whether their resolution was satisfying
... would be good to do this efficiently
... ad hoc process as a way to start, with the people who are opening individual github issues
... though it would be great to keep the whole PING group informed

tara: +1, good to bring back to the group

https://lists.w3.org/Archives/Public/public-privacy/2018JanMar/0030.html

next meeting

tara: any known conflicts

May 10?

tara: will follow up on the mailing list with any further topics
... great to see people working on reviews

[adjourned]

trackbot, end meeting

<wseltzer> present=npdoty, tara, mikeoneill, christine, jnovak, wseltzer

- DRAFT -

Privacy Interest Group Teleconference

05 Apr 2018

Attendees

Contents

Horizontal Reviews

next meeting

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output