W3C

- DRAFT -

Privacy Interest Group Teleconference

07 Jun 2018

Attendees

Present
wseltzer, npdoty, jnovak, tara, weiler, Barry_Leiba
Regrets
Chair
SV_MEETING_CHAIR
Scribe
tara

Contents


waiting a minute to see if we get GamePad API reps joining...

<jnovak> WoT outreach?

<weiler> ACTION: Christine will invite WoT people to next call.

<trackbot> Created ACTION-17 - Will invite wot people to next call. [on Christine Runnegar - due 2018-06-14].

<npdoty> action-17: or at least some future followup, if not for the next call

<trackbot> Notes added to action-17 Will invite wot people to next call..

https://www.w3.org/TR/2018/WD-gamepad-20180508/

https://github.com/w3c/gamepad/issues/new/

Gamepad API

I'll see what I can do

Issues in github re: privacy

<npdoty> I think all the issues labeled security are relevant: https://github.com/w3c/gamepad/labels/security

#73 id field in gamepad might have a persistent identifier - https://github.com/w3c/gamepad/issues/73

Gives info on product, vendor, name...how much is this needed?

barryleiba: these types of identifiers cause vendor-specific code, but also leak info, and advertise to attackers if a particular vendor's code is vulnerable

christine: justification is unclear for this ID, apart from convenience

barryleiba: often they *want* vendor-specific code but this often causes more problems than it solves

christine: yes, this leads to interop issues

npdoty: another justification is human-readable name. Tell user which device they are supposed to user for, say, XBox controller

(not long string)

barryleiba: passing on user-defined name solves this problem. User gives devices nickname, and can tell them which device to use, which doesn't leak personal info or cause interop issues

npdoty: this does disclose the user-defined device name though

barryleiba: is still preferable to basic vendor info

christine: reduces problem but doesn't remove it

npdoty: we are brainstorming alternatives here in 30 seconds which are potentially an improvement over the basic scenario

christine: volunteer to comment on issue 73 and suggest alternatives?

barryleiba: volunteers!

Thanks Barry.

#72 clarifications for getGamepads (incl. what does “interacted with the user mean”) - https://github.com/w3c/gamepad/issues/72

christine: lack of clarity on "interacted"

npdoty: listed as way to deter fingerprinting; don't want list of all devices available across sites (fingerprinting vector)

christine: mitigation depends on what "interacted" means, e.g., "ever interacted"

jnovak: is this "pressed button" or more detailed info? They need to further specify.

christine: can we help them to clarify boundaries, e.g., "this should not be considered 'interacted with'", exclude these scenarios

npdoty: emphasizing origin concept would be useful. Worst case, cross-origin. If top-level context, pressed button here...not being tracked across origins

christine: this is subject to same-origin policy, yes?

npdoty: problem is GamePad would return same list each time (piece of hardware persists)

christine: volunteer for commenting on Issue 72?

npdoty & jnovak will coordinate and comment

Thanks Nick & Jason!

#71 how do connection/disconnection events interact with “device has been interacted with by the user” - https://github.com/w3c/gamepad/issues/71

christine: sounds like closely-related issue

npdoty: seems that this has been acked in the comments

npdoty (same fix applies)

<jnovak> is it worth also discussing 70: https://github.com/w3c/gamepad/issues/70

<jnovak> "Make getGamepads API asyncronous to support permission request"

christine: suggest we add privacy tags as appropriate

jnovak: maybe necessity of this depends on other mitigations?

christine: if they applied mitigations to the issues identified above, it may not be necessary to have requirement that API sit behind perm request?

<npdoty> I think I was able to add "privacy" labels to the three issues we've discussed so far (I'm not quite sure why I have this capability, but...)

jnovak: yes, and issue 70 is already asking if this is necessary to begin with
... so we can contribute to the discussion on the related issues to guide that decision

jnovak will add note to issue 70

Thanks, Jason!

weiler: is navigation stuff time-dependent *now*? The timestamps that are relative to navigation start - is that currently browsing-context dependent?

<npdoty> I think it's not an absolute timestamp, but relative to when the device was first attached?

weiler: there is timestamp for every gaming event. Are timestamps based on same clock -> makes hig-res tracking beacon
... if this is context-specific, then mitigates cross-origin tracking capability of timestamp

npdoty: good point; seems it may depend on implementation as to whether this happens

weiler: anyone know navigation timing spec well? Published in 2012...

npdoty: we could open issue and have them clarify this

weiler: will open issue to get clarification

Thanks, Sam!

(might turn out to not be a risk but we could use the clarification regardless)

jnovak: WWDC news

WWDC news

you can watch the video if you like

there is an additional privacy-specific talk, ITP v2 & storage API, and WebKit blog posting

<npdoty> oh, would love to see links, thanks

on Monday: two big Safari features. Anti-fingerprinting & ITP v2

Anti-fingerprinting: three changes

1. reducing information in User Agent String. Parts are frozen.

freely-available entropy reduced

in Mojave: reducing ability to query for fonts -- system fonts, is same across Macs, so not useful

Can't get user-installed plugins as source of info

ITP v2: v1 domains that are detected as "tracking domains" - have partitioned cookies...after 24 hrs in partitions, then deleted

<wseltzer> machine-learned on device

<scribe> new version: cookies are *immediately* partitioned, change to storage API

[eventually this is going to just have to be link to the technical doc]

[scribe unable to keep up with volume of data]

<npdoty> cookies accessible only on gesture, and now embeds who ask for those cookies get a user-permission prompt before getting access to cookies

https://webkit.org/blog/7675/intelligent-tracking-prevention/

<jnovak> https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

christine: lot of press on "Apple is going to block Facebook tracking"

jnovak: really, it's about ensuring cookies that are used are more about first-party relationships & current context
... def'n of first party & third party have evolved, so we've updated accordingly, and ensuring that since we have way for site to request access to their cookies

Then policy can be enforced accordingly

christine: this sounded like FB-tracking elements, so good to get clarification of the whole story, practice is broader

jnovak: Storage Access API gives ability for 3P imbeds, and can block cookies that previously we could not

npdoty: in past, UA strings for fingerprinting, we said - different versions have different features, so there will be entropy..but some of them seem to have a *lot* of detail.

So: how is Apple deciding how much to freeze? And can we give guidance on this?

jnovak: there *was* a lot of info in UA string before, like OS Build version...may not have any impact on actual Safari version, not useful

npdoty: are there places where standardizing Storage Access API would be useful?

jnovak: it's working through WHATWG

<jnovak> https://github.com/whatwg/html/issues/3338

<jnovak> ^^ Storage Access API proposal for standardization

Thanks, Jason, for details + links

christine: is it possible/useful for have PING call dedicated to Storage Access API, w/broader community invited?

jnovak: would need to consult w/Apple & others

wseltzer: on-device ML for tracking interesting ("what's a tracker?") -- can user access the list of what has been classified as a tracker?

jnovak: will get back to you on this

christine: has put summary in GitHub, will likely circulate in email as well

Expect summaries to continue in future

WoT outreach? will be offline & return to later

July call?

July 12

Thanks, all!

christine: will try to send meeting call w/calendar invite for next meeting

Summary of Action Items

[NEW] ACTION: Christine will invite WoT people to next call.
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/07 16:57:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/GameaPad/GamePad/
Succeeded: s/yeah, I'm having connection issues today//
Succeeded: s/I think I've figured it out//
Succeeded: s/still an improvement/potentially an improvement/
Succeeded: s/on issue 71/on issue 73/
Succeeded: s/topic: WWDC announcements//
Present: wseltzer npdoty jnovak tara weiler Barry_Leiba
No ScribeNick specified.  Guessing ScribeNick: tara
Inferring Scribes: tara

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 Jun 2018
People with action items: christine invite people will wot

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]