Privacy Interest Group -- 09 Nov 2017

<mkwst> scribenick mkwst

<npdoty_> TPAG agenda: http://lists.w3.org/Archives/Public/public-privacy/2017OctDec/0009.html

<tara> Do we have any IRC folks waiting for WebEx?

<tara> The WebEx password is "PING"

<mkwst> tara: Welcome!

<mkwst> ... Let's do introductions.

<mkwst> ... [Introductions]

<mkwst> ... [Agenda]

<mkwst> ... https://lists.w3.org/Archives/Public/public-privacy/2017OctDec/0009.html

PING privacy questionnaire

<mkwst> tara: This has been an item we need to put a bit more attention on.

<mkwst> ... Idea is to help folks who are submitting documents..

<mkwst> ... Provide guidance for editors so they think about potential problems, and record those in their documents.

<mkwst> ... There's a related document from the TAG.

<mkwst> ... Looking for feedback on these documents.

<mkwst> ... Are they useful? We know they're _being_ used.

<npdoty_> https://www.w3.org/wiki/Privacy_and_security_questionnaire

<mkwst> ... But it would be helpful to understand what's missing.

<npdoty_> https://cdn.rawgit.com/w3c/ping/master/privacy-questions.html

<mkwst> dsinger: What's the status of the one pasted into IRC? (https://www.w3.org/wiki/Privacy_and_security_questionnaire)

<mkwst> wseltzer: Is Christine the one who's supposed to be sorting this out?

<mkwst> tara: Yes.

<mkwst> wseltzer: Confusing at the moment, should consolidate at some point.

<mkwst> tara: Yes. GitHub should be the canonical one.

<mkwst> ... Not canonical yet.

<dsinger> Then there is also https://gnorcie.github.io/ping-privacy-questions/

<dsinger> and the TAG one for the record https://www.w3.org/TR/security-privacy-questionnaire/

<mkwst> wseltzer: I'll raise this.

<mkwst> dsinger: Perhaps we could take these three and do a union on them?

<mkwst> ... Giood first step>?

<mkwst> npdoty: It's a problem that we have this diversity, but perhaps the bigger problem is that they're all stale.

<mkwst> dsinger: Is there a TAG rep?

<mkwst> [torgo walks in the door]

<dsinger> and Dan A walks in to the room

<mkwst> dsinger: How should we improve the privacy questionnaire?

<mkwst> ... Several docs.

<wseltzer> [noted that Greg is no longer working with CDT or PING]

<mkwst> torgo: Pushed responsibility to the ... something something privacy/security group in W3C?

<mkwst> ... Looking at wseltzer.

<mkwst> wseltzer: It's a challenge that we're relying on volunteers in groups to do these things.

<mkwst> ... Not getting sufficient input.

<mkwst> ... I'll have to ask Christine if she needs help from someone else?

<mkwst> ... Might have to assign someone from the team.

<mkwst> torgo: TAG doesn't think it's driving the document.

<dsinger> wait, there is also https://github.com/w3c/ping-security-questionnaire

<mkwst> ... Happy to participate, but we're not driving it.

<mkwst> tara: Sounds like we need actual drivers.

<dsinger> then there is https://w3ctag.github.io/security-questionnaire/

<mkwst> ... Have any feedback from the TAG on usage of questionnaire?

<wseltzer> ACTION: wseltzer to work with Christine to sort out privacy questionnaire(s)

<trackbot> Created ACTION-16 - Work with christine to sort out privacy questionnaire(s) [on Wendy Seltzer - due 2017-11-16].

<mkwst> torgo: We like seeing it used. Interested in feedback from folks, but not our intention to own the process.

<mkwst> ... Often the case that WGs choose that review time to go through the questionnaire.

<mkwst> ... Say in the review request that they've gone through.

<mkwst> ... Part of the review request template.

<mkwst> tara: We should unfork these questionnaires if possible.

<mkwst> jochen___: Is a lawyer looking at words like "identifiable data" and new regulations like GDBR?

<mkwst> wseltzer: Goal of document was not to provide legal advice, but to give editors things to think about when writing their documents.

<mkwst> ... Given myself an action to make sure we have a plan to have a single place to go for this kind of thing.

<mkwst> ... I think we've gone off in weird directions.

<mkwst> ... Some versions have much more detail than others.

<mkwst> tara: Perhaps one canonical, then supplementary documents.

<wseltzer> mkwst: what's the goal?

<wseltzer> ... sometimes, help people think about privacy

<wseltzer> ... sometimes, give people detail on the terms and considerations

<wseltzer> ... it would be good if we produced something light enough weight that editors could work through it

<wseltzer> ... and a secondary document that helped people who did run into issues to consider them in more depth

<wseltzer> ... I don't think making those the same document is valuable.

<mkwst> dsinger: The critical thing is to have a document that makes people think.

<mkwst> torgo: If you make the first document too detailed, people won't use it.

<mkwst> ... Needs to be useful to spec editors.

<mkwst> npdoty_: I recall those conversations.

<mkwst> ... But that's maybe why we have so many documents.

<wseltzer> mkwst: we need an editor

<mkwst> npdoty_: If we can't find that person, then I'd rather have one detailed doc.

<wseltzer> ... who's actually committed to driving a document through

<mkwst> dsinger: What I hear is that the TAG wants folks outside the TAG to submit PRs and issues to the TAG document.

<mkwst> ... Given that everyone is already looking at the TAG document?

<mkwst> torgo: Sounds like a good proposal. If we do that, perhaps we should assign a TAG member as editor.

<mkwst> ... Happy to do that if there's the energy here to make proposals and work with us on evolving it.

<mkwst> ... Can discuss it with the rest of the TAG...

<mkwst> wseltzer: Seems to me that this should be a core function of the PING.

<mkwst> ... Frustrating that it's been difficult to give sustained attention to it.

<mkwst> torgo: If we find an editor in the TAG, could we find a co-editor in this group?

<mkwst> dsinger: I want to be able to point the community to a single owner.

<mkwst> tara: Coordinating through the TAG seems useful.

<mkwst> mkwst: Using the TAG as a chokepoint for reviews is useful.

<mkwst> ... Blink, for example, forces all new features through the TAG.

<mkwst> ... [Discussion of historical forces that drove the document to the TAG]

<mkwst> colin: Security questions vs privacy questions?

<mkwst> mkwst: Similar in nature, so far as I can tell.

<mkwst> ... The current TAG document is security focused because of the authorship.

<mkwst> ... Would welcome a better balance.

<mkwst> weiler: Privacy expertise in this group would be good to couple with security expertise.

<mkwst> npdoty_: Security reviews?

<mkwst> weiler: It's in terrible shape right now.

<mkwst> ... Trying to spin it up.

<mkwst> tara: Talk about that a bit?

<mkwst> Yoshiro: Security is a feature, privacy is a policy

<mkwst> ... Questions in the document are more helpful for implementers.

<mkwst> jochen___: We have policies and features around both privacy and security.

<mkwst> ... We have a legal baseline, and then user-facing features, etc.

<mkwst> ... Hard to distinguish between "feature" and "policy".

<mkwst> tara: Dependencies between the two. Can't decouple them cleanly.

<mkwst> ... Just groups with different functions. Want to find the best way to make headway there without overburdening the editors or questionnaire.

<mkwst> ... Need experts from this group to give feedback on privacy.

<mkwst> ... If Security IG had been meeting in the same way we are, would have a clear path forward.

<mkwst> ... Right now we're a little lopsided.

<mkwst> ... Tons of security work, but no obvious partner.

<npdoty_> scribenick: npdoty

<npdoty_> weiler: right now security review infrastructure in progress is different, more about identifying individuals to look at particular specifications

<npdoty_> ... as opposed to shallower group review

<npdoty_> ... which doesn't create a corresponding community

<npdoty_> tara: do security folks have a questionnaire or infrastructure?

<npdoty_> weiler: currently, no. I am asking to see if these questionnaires are helpful or what they are using.

<npdoty_> dsinger: "have you thought about security/privacy and written a security privacy considerations section?" is becoming mandatory, thought not formally part of the Process

<npdoty_> ... raising of eyebrows are used

<npdoty_> tara: we would need to know feedback from groups that have used the questionnaire to see where it's helpful and where it's not

<npdoty_> tara: while we have best intentions for helping, need to insist on particular drivers.

<npdoty_> weiler: if the Team owns the document, not sure there would be sustainability of editors

<npdoty_> dsinger: if both privacy and security, could be formally owned by TAG, with work from the privacy and security interest groups, who have the expertise

<npdoty_> jochen___: have had a situation where WGs send reviews to webappsec, are told that webappsec doesn't do reviews, send to the security interest group, and then no one replies

<npdoty_> DKA: let me take this back to the TAG as an option, to see if they can help drive it

<npdoty_> dsinger: nominally owned by the TAG, but Privacy IG owns the privacy part, Security IG owns the security part ...

<npdoty_> DKA: sure, but if TAG owns the document, then they will resolve any conflicts

<npdoty_> ... TAG assigns an editor to edit the document, with discussions/suggestions in issues list from privacy interest group and security interest group

<npdoty_> weiler: whoever has time is the Editor, although the TAG can ultimately say yes/no

<npdoty_> DKA: definitely in github

<npdoty_> [round agreement]

<npdoty_> npdoty: given small groups and overlapping matter, does it make sense to combine?

<npdoty_> dsinger: could help with small sizes and lack of volunteers

<npdoty_> weiler: has been discussed, but sometimes privacy can get overlooked in that structure

<npdoty_> wseltzer: while small, this group has been effective at getting people to come discuss, getting privacy considerations, getting people to talk about privacy

<npdoty_> ... don't want to disturb that, or change the structure

<npdoty_> dsinger: want to add a feedback question to the questionnaire: did it help or not? what did it miss?

<npdoty_> ... could help in getting feedback from groups

<wseltzer> https://github.com/w3ctag/security-questionnaire/issues/26

<wseltzer> ^ dsinger's issue

<npdoty_> npdoty: would be interested in adding harassment/abuse level questions

<npdoty_> jnovak: verifiability of who you're talking to

<npdoty_> tara: often a part of "Trust & Safety" in corporations

<npdoty_> ... not sure the exact home, but probably not other groups in w3c that cover it

<npdoty_> ... what do we do about problematic actors? whether it's network/security/spam issues or social harassment/unwanted contact

<npdoty_> ... more "right to be left alone", privacy beyond data protection

<npdoty_> npdoty: might be more relevant for some specs than others, particularly higher-level ones

<npdoty_> [introduction regarding privacy in video and broadcasting]

<npdoty_> dsinger: could questionnaire help with high-level privacy regulations in different jurisdictions?

<npdoty_> [people scared about legal advice and scope]

<npdoty_> hadleybeeman: a lot of spec editors that aren't aware of cultural and legal differences around the world, rather than a single view of privacy

<npdoty_> ... also, no guarantees / liability

<npdoty_> [private browsing modes as a topic]

<npdoty_> jochen___: most concretely: how does your API work if you're not allowed to persist data?

<npdoty_> ... want graceful failure modes, to avoid sniffing for private browsing mode

<npdoty_> hadleybeeman: I think it's a problem that threat models are not common for private browsing modes between browsers, both for users and for spec authors

<npdoty_> ... almost all of us are not aware of the cross-browser differences

<npdoty_> jochen___: but there might be *overlapping* features, a core

<npdoty_> hadleybeeman: +1, it would be nice to have a consensus about that core, which would be helpful for other spec authors

<npdoty_> ... while still allowing diversity of experimentation between browsers

<npdoty_> dsinger: can't fix it as a standard, but could describe some terminology that would be helpful

<npdoty_> tara: could have a separate agenda item on that later

<npdoty_> jnovak: should have a specific callout for sensors, sensor data or device data

<npdoty_> ... not just geolocation

<npdoty_> +1, needs to be broadened

<npdoty_> jochen___: fingerprinting is mentioned in the questionnaire, and should have references to make it easier to have a common conversation

<npdoty_> ... we constantly have discussions, but not effective

<hadleybeeman> https://w3c.github.io/fingerprinting-guidance/

<npdoty_> dsinger: would like to expand the conversation to talk about cross-device tracking, not just fingerprinting of a single browser instance

<npdoty_> jochen___: related to device sensors as well

<weiler> Linking of devices, or of individuals (see NSA's co-traveler)

<npdoty_> tara: we have some good questions/issues for adding to the questionnaire

<npdoty_> ... and we have an item of interest looking for owners and contributors

<npdoty_> dsinger: dka is investigating TAG involvement

<npdoty_> ... we are going to look at what needs to be done for privacy improvement

<npdoty_> ... and weiler is investigating a security interest group, and if there could be security help with the questionnaire

<weiler> scribenick: weiler

davidsinger: chair is trying to finsih this work. one thing that came back in review is that we made a msitake: we should have used promises.
... this would break @@, editors decided to do a more general simplification.
... [explains re: exceptions, where sites ask for specific exceptions - site-wide exceptions, web-wide exceptions]
... other than around exceptions, spec has not changed much.
... debate whether this is helpful to comply with GDPR. consensus: if changes are needed for GDPR, that will be done in a 1.1
... wendy, do you agree with that assessment?

wendy: I have Q's for the AC and the group: group is chartered through EOY. chartered in 2011. is there a continuing purpose for the DNT work?
... would be useful to hear from PING whether you think this is a necessary and useful compenent to privacy on the web.

tara: who's been involved in both? Wendy, DSinger
... hadley trying to track both.

hadley: there are amendments in EU laws that reference DNT. recognize challenges in making changes now. concerned that if EU laws point at us, it could be hard to make changes.
... pushing off Q of compliance, comes with add'l uncertainties for our own work.

plh: how do they reference the draft?

tara: it surprises me to see legislation taking this so seriously.

plh: I have doubts on capability of WG to push this to rec. hearing that it's been referenced by EC... is messed up.

<hadleybeeman> ePrivacy Regulation text: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52017PC0010 See paragraphs 22-24

plh: I don't think we made commitments to them....

hadley: text of legislation ...legal idea is that users should be able to control who can track them and how. gets into details of first/third party cookies.
... law in this form does not mandate DNT specifically.

dsinger: common understanding that legislatures shouldn't go into tech details. similarly, technologists shouldn't try to legislate.

Dan: privacy directive trying to clean that up.

hadley: they recongize that the cookie directive failed.

dsinger: that puts the onus on tech groups to come up with mechanisms to support the principals. disturbs me that DNT is our only privacy-specific spec.

plh: not true. we're requiring new specs to have privacy considerations.

dsinger: but this is the only one that is intended to have effect on privacy

plh: many of our specs make sure privacy is being addressed.
... webauthn wg today talking about delaying some privacy stuff past CR...

hadley: re: who's good at what: I agree with your generalizations. But the techies are making significant socieital decisions. we have the pwoer to work out what the future is going to be. gov'ts are then tryign to catch up.
... trying to keep corps from violating rights, etc. it's important for us to get up to speed in a hurry.

tara: things are coming through more routinely for review now than in the past.

nick: we may not have had a group, but people were involved before. I'm not sure why the exceptions API was changed so as to break prominent implementations.

plh: . @2 ... they insisted they wanted to move to PR.

nick: other parts of specs (header) are widely impemented.

plh: they didnt want to put any feature at risk

dsinger; they said all of spec was at risk. all or none.

<hadleybeeman> s/disgner/dsinger

dsinger: if they want to implement, we could spin WG back up again.

plh: we need to talk to chairs.

disnger: in absence fo consentual solutions like this, we'll continue to see "hostile" solutions

jasonNovak: this is what the advertising folks are talkign about

plh: I want guidance re: what to do. does spec make sense as-is, from a privacy perspective?
... danger of closing in two months is we gets bashed on head with "w3c doesn't care about privacy"

weiler: do we have a simple concise answer to PLH?

hadley: not useful because not implemented

nick: useful as a "here's something ready to go"

wendy: rec or note or ???

dsinger: note, explaining why not CR, serves W3C and community purpose.

<wseltzer> dsinger: Note, explaining why we couldn't make it a Rec because we didn't have 2 ingteroperable implementations

break until 11am local time.

<tara> Waiting for folks to trickle in...

<tara> Evidently phone jack in the room is broken, so any WebEx has to be run through someone's laptop

<tara> Wait there has been a Polycom miracle

<mkwst> scribenick mkwst

Network Information API

<mkwst> tara: Came out in October.

<tara> https://wicg.github.io/netinfo/

<mkwst> ... CG report.

<mkwst> ... npdoty_ brought this to the mailing list.

<mkwst> ... Might be time to get more eyes on it.

<npdoty_> https://lists.w3.org/Archives/Public/public-privacy/2017JulSep/0025.html

<mkwst> npdoty_: Sure.

<mkwst> ... Before we take it directly, I sent this to the public-privacy list because I was looking for ways to send constructive feedback, identify common problems.

<mkwst> ... Email was frustrated, not constructive to send along.

<mkwst> ... This API is part of WICG.

<mkwst> ... Written by perf folks.

<mkwst> ... Related work in IETF, client hints at HTTP layer.

<mkwst> ... JS API that gives websites some information about how a user is connected to the web.

<mkwst> ... Events for seeing when those connections change.

<mkwst> ... Motivating use cases are changing behavior based on user network information.

<mkwst> ... Bad to download a big file if the user's on a slow, metered connection.

<mkwst> ... Privacy issues are revealing the first hop connection.

<mkwst> ... Not end-to-end. Are you connected over 2G/3G/4G, etc.

<mkwst> tara: Previously, folks would guess at this based on device?

<mkwst> npdoty_: Sure, or IP address. Testing speed.

<mkwst> ... "Seems like it's not that fast, maybe they're on a slow connection."

<mkwst> weiler: The list of things they're sending here is a connection type, several (9) options.

<mkwst> npdoty_: Down to the specific downlink speeds. Round-trip timings.

<mkwst> ... They have a privacy/security section.

<mkwst> ... Which concludes that there are privacy issues, but that they're not new.

<mkwst> weiler: "If you want to mitigate, disable JavaScript, use a VPN, don't connect to untrusted sites."

<mkwst> jochen___: There's a lot of discussion on GitHub.

<mkwst> ... Two iterations:

<mkwst> ... First, shipping in Android, exposes this detailed information.

<mkwst> .. Doesn't give developers the data they need. Just being on 4g doesn't tell you enough.

<mkwst> ... Second pass at it has different buckets. "4g-like network"

<mkwst> npdoty_: Is this not the most recent spec?

<mkwst> jochen___: Discussion on the issue tracker, which has apparently gotten Mozilla folks on board.

<mkwst> mkwst: Link to a bug?

<mkwst> jochen___: Looking it up.

<mkwst> weiler: They say this isn't new, but there is new data,

<mkwst> ... Data provided by the client is more useful for fingerprinting, more predictable.

<mkwst> weiler: Did they ask us for this review?

<mkwst> npdoty_: No.

<npdoty_> mkwst: lots of vendors are using WICG for incubation of new ideas, rather than needing to pick a WG before we know it very well

<npdoty_> ... and graduate to suitable WG later

<mkwst> tara: The question then is what form of engagement is reasonable at what time.

<npdoty_> mkwst: provide feedback, file issues, as usual

<jochen___> there's https://github.com/WICG/netinfo/issues/64 for reducing the fingerprint

<npdoty_> ... just lighter weight than a WG, but it is an indication that they want feedback

<mkwst> npdoty_: Say they're shipping in Chrome, not sure what version, flags, etc.

<jochen___> https://github.com/WICG/netinfo/issues/41 for general issues

<jochen___> status in chrome: https://www.chromestatus.com/feature/5108786398232576

<mkwst> mkwst: [Describing Blink's "Intent" process]

<mkwst> mkwst: https://www.chromium.org/blink/launching-features

<mkwst> ... Short version: feedback welcome.

<mkwst> npdoty_: I'm happy to take an AI to convert my email into some more direct feedback.

<mkwst> ... I'd like for us to more generally discuss the "Oh, there's nothing new here" privacy section.

<mkwst> dsinger: Is it reasonable to say?

<mkwst> npdoty_: Sometimes it's true, sometimes it's not.

<mkwst> mkwst: Not that many bits of entropy.

<scribe> scribenick: weiler

mkwst: should look at low hanging fruit. as long as set of users who use that feature is small, will be robust protection. canvas fingerprinting is the low hanging fruit. if you take that away, will not solve fingerprint, but will remvoe one vecotr.
... my worry: there are vectors. can't remove all. good that firefox has an easy vector to remove fingerprinting that is widely used. tension between ease and secodn order impacts in ecosystem

jason: I challenge assertion re: moving all of the vectors... there's a process of ensuring we're not adding add'l bits.

mkwst: worthwhile to examine entropy platform exposes. a bunch of entropy is exposed in places where it's hard to remove. even IP address. IP addr + network stack + user agent + dev characteristics... possible to build a browser with less than N bits, but not sure what that looks like.

jason: fingerprinting we're trying to remove is not just browser... need to solve some of this elsewhere in the stack? when you move cost of fingerprinting out of browser, makes f'printing harder

mkwst: network fingerpritning is cheaper, though. @@ is strictly network based.

<npdoty_> http://lcamtuf.coredump.cx/p0f3/

jason: i meant expensive as in 'need to execute code elsewhere....'

nick: we're moving into next topic.
... "nothing new" response keeps jumping between specs. circular references.

<tara> speaker: Jochen

jochen: encourage you to raise these in github.
... the earlier you raise, the less pushback you'll get.

<npdoty_> http://w3c.github.io/fingerprinting-guidance/

mtitigating browser fingerprinting.

<jochen___> previous statement by tag I was referring to earlier today: https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

nick: doc talks about feasible mitigation; making it more observable; making it more expensive.

jnovak: one can argue that fingerprinting is a response to ad blockers, cookie policy - things that make it harder to get state on device.
... goal is to reduce the attack surface... make the attacker go somewhere other than the broswer. mkwst has a point re: hard to address re: IP address.
... attackers go to attack that easiest. cookies. that became harder --> moved to fingerprinting. fingerprinting attacks in browser now no easier than outside-browser attacks.
... trying to drive the attacker out of the browser space.
... to IP addr, network stack, wifi physical layer attackers.

<YoshiroYoneya> There were an interesting presentation regarding browser fingerprinting at USENIX'17: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/vila

mkwst: you're suggesting that reducing amount of entrooy we expose in APIs gets us down to level where addressing external concerns is useful? what's our goal? How do we know if we're succesful, by cariving out entropy that's "not our problem"?
... what's success? what should we be targetting?

nick: I want to try to coordinate w/ other parts of the stack
... not sure how feasible.
... some things might be more detectable in the browser.

jnovak: there aren't regulations re: storing canvas bits, but there are re: IP address. some elements have different socio-political elements around them.

mkwst: I think we can't solve fingerprinting technically, but they might be solvable.

nick: TAG doc suggests that what we can do technically is limited.
... we should be considering the non-technical mitigations.
... I've been making slow progress, but I'd like to call it done.
... got tag feedback. what else needs to be done before publication?

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

nick: need review of issue resolutions.
... and feedback on what would make it useful.
... "make it more actionable".
... some people want a quantitative soln. I don't know how to do that.

mkwst: what do we know re: publishhing updates to notes.

nick: IG notes ... nothing bad happens if we publish one.

mkwst: you addressed tag; move on. don't block.

dsinger: should we give tag feedback that they should add to their guidance @4?

<dsinger> do not write in your spec. that this doesn’t make fingerprinting worse because similar information is available in other ways. (a) similar is not the same as identical. (b) the other ways almost certainly have differences in difficulty of use and ubiquity of information. (c) such disclaimers have a risk of being circular (two or more specs that end up referencing each other to support the claim that they make the situation no worse)

mkwst: circular refs are bad.

AOB

nick: we need to address issue of insufficient resources. e.g. I'm not spending much time on fingerprinting doc.
... how can we build up resources?

dsinger: how can we make the W3C into a recognized center of excellence for online privacy?

<tara> on lunch until 13:30

<tara> Waiting for folks to return from lunch...restarting soon

<npdoty_> scribenick: npdoty

<npdoty_> scribenick: npdoty_

Generic Sensors

<npdoty> scribenick: npdoty

tara: a large scope, so I want to make sure we have time to look over it
... welcome anssik

anssik: chair of device and sensors working group, generic sensor api and concrete sensors built on this abstract base class

<tara> https://www.w3.org/TR/generic-sensor/

anssik: accelerometer, gyroscope, magnetometer, orientation, ambient light, proximity
... shipping trials in Chrome for a few of these now
... started wide review, looking for privacy reviews, asking for feedback through 2017

<anssik> https://github.com/w3c/sensors/blob/master/security-questionnaire.md

<scribe> ... completed the security self-questionnaire, which was useful for us

UNKNOWN_SPEAKER: we saw no red flags

anssik: iOS implementation of device orientation events has some issues regarding embedded iframes
... trying to fix some of those issues here, with connections to Permissions API and Feature Policy
... so that top-most frame is in control
... based on review of existing API and its privacy issues

dan: currently Safari only lets the main frame access device motion data

anssik: previous spec didn't have normative statements, but that seems like a good implementation approach

dom: just cross-origin? dan: I believe in all cases of child frames.

anssik: want to do it right here, in the generic specification, so that additional sensor features will automatically have that understanding

<dydz> correction, WebKit only disallows cross-origin child frames from accessing device motion and orientation

tara: want to make sure the questionnaire is addressing sensors more generally

jnovak: and in fact for device information more broadly

dom: given all that we've learned from generic sensors, other specs can link to this section of the generic sensor spec
... could abstract that out, as we've done work on particular ways for mitigation
... there's an opportunity for collaboration on privacy beyond this particular spec

anssik: all sensors apply the mitigations in 4.2, and case-by-case for the other mitigations
... only specify in one place and then reference them elsewhere

https://w3c.github.io/sensors/#extension-security-and-privacy

tara: question about depth of the privacy/security guidance

dsinger: +1, we would appreciate suggestions on ways to improve privacy in sensors design

anssik: we would welcome your feedback

<Zakim> npdoty, you wanted to ask about existing extension specs

<jochen___> https://docs.google.com/document/d/10wHDt0qUaOYMdD6w8lNsySISrmIsxAjWXXbylQZi0Ss/edit chromium priv & sec notes for generic sensors api

https://w3c.github.io/accelerometer/

concrete sensor specs "implement" the generic sensor spec

and so when they mention nothing specific in security and privacy, that means it does implement the required set of mitigations, but not additional ones

where ambient light lists a longer set of potential threats, with different mitigations

<anssik> https://developers.google.com/web/updates/2017/09/sensors-for-the-web

npdoty: does having requirements in the spec for the abstract class ensure that implementers will automatically apply those restrictions to every such concrete class?

anssik: goal is to complete wide review in 2017

dom: the more we can get the base right, the better the future will be, because derived sensors will inherit other good privacy aspects

tara: great to identify the threats and the mitigations

anssik: has helped to work with privacy researchers inside the group
... better to hear about those things now, rather than later in the shipping process

dsinger: do we consider environmental fingerprinting, or cross-device tracking?
... can you identify that two people are in the same place at the same time?
... for example, audio beaconing

anssik: ambient light was a particular case for cross-device communication/linking

dsinger: but shouldn't we consider that a generic problem?
... might need to include more detail on those threats, or how to elevate that to the generic sensor

dom: acceleration data could identify people on the same train

anssik: +1 for sending that issue in the PING feedback

<Zakim> npdoty, you wanted to ask about permissions api dependency

npdoty: is there a dependency on the permissions api?
... spec and implementations not complete

<tara> Is a normative dependency but API is usable without

anssik: is implemented in Chrome, and not all the features are necessary to implement the sensor API

dom: revoke in permissions api can help with the privacy of sensors

npdoty: but not clear where we are on implementation/support for revoke()

jnovak: given that we know that accelerometer/gyro can be used as keyboard sniffing ...
... should we enumerate those risks in the concrete sensor specs themselves?

anssik: hearing both feedback to move things up to the abstract generic sensor and to detail them in the concrete specs

jnovak: if there are specific and known attacks for a sensor, it's important to highlight that in the specific specs

anssik: +1 to include in the PING feedback, to highlight specific attacks in that particular sensor

jnovak: we know which sensors can be used for which attacks in some cases

anssik: one way or another to get that information to the implementer.

dom: useful to have the attacks in front of your eyes when you're implementing that specific sensor, so that you can think of other mitigations at that time

anssik: have a web platform test suite which will apply to all

weiler: does CSP have facilities for revoke functionality?

dom: I think it doesn't right now.

npdoty: heard the possibility of using a separate, anonymous origin for that purpose

[debate over the intuitiveness of the Web platform ;)]

tara: a good start, thanks!

<hadleybeeman> [Not sure it's debate. We may all agree that parts of it are terribly unintuitive...!]

anssik: try it out, in Chrome 63+

Vehicle Information Service Specification

tara: anyone who went to Automotive session this week?

hadleybeeman: I think it is very much worth reviewing, and still very much in progress so can make a big difference at this point

debate about RESTful design and device APIs

upgrade path / security capability

generally accessible/addressable to the Web

what is the liability if apps crash or if software is distracting to the driver?

<tara> http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html#security

https://www.w3.org/2017/09/28-privacy-minutes.html

tara: there seems to be more security focus here rather than privacy issues
... a lot of access control, but less high-level
... comments from previous PING call don't seem reflected in the security considerations section

<tara> Access control text doesn't really address privacy issues - like, which apps collect which data and share with whom...

whether it belongs in this spec or not, should be considered during this design process

Private Browsing Mode

<hadleybeeman> https://www.slideshare.net/hadleybeeman

<tara> Break deferred for discussion of Private Browsing

https://www.slideshare.net/hadleybeeman/private-browsing-a-rant-for-opentech-2017

hadleybeeman: spreadsheet of which features of the web platform each of the browsers affects in their private browsing modes

<hadleybeeman> https://docs.google.com/a/linkedgov.org/spreadsheets/d/10kulKoA6b_EWXDjzlg2DXS2vKL1NbW0NvPbcnWo5v0s/edit?usp=sheets_home&ths=true

hadleybeeman: it varies, and isn't well-documented in public places, and lots of confusion even among vendors
... can't explain to users in a way that they protect themselves
... other specs can't normatively interact with private mode, can't clarify that they should interact differently in such a particular mode

jochen___: not sure how the spec would help users. still work to be done on explaining things to users in Chrome UX

hadleybeeman: I think consistency across browsers might help users have a more consistent mental model
... don't want to stop user agents from continuing to change, but could still make something more common at the basic level

dsinger: want to improve the consistency while still maintaining innovation/variation
... mentioned in the privacy questionnaire, but we don't have a way to give them guidance
... could come up with common terminology

chrome and safari both consider network privacy measures out of scope for private browsing modes

weiler: is there a need for sites to request being in private browsing mode?

<hadleybeeman> https://usercontent.irccloud-cdn.com/file/azJpEtjl/Screenshot%20-%20private%20browsing%20table.png

<hadleybeeman> weiler: ^^

npdoty: that use case has been considered (for a domestic abuse shelter), but has dangerous side effects (for sites that want to cover their tracks)

jochen___: Google considers this possibility, has custom headers for when logging into another google account while logged into a browser

<jochen___> on android

dsinger: users want private browsing without being anonymous, like being logged-in while shopping but not wanting that to be reflected elsewhere

hadleybeeman: for example, with containers
... site controls puts power into hands of the site developer, but I'm more concerned about user control

<dsinger> I would like to separate *discussion piece* from best practices from normative spec. work in this area

https://gist.github.com/mnot/96440a5ca74fcf328d23

<Zakim> npdoty, you wanted to mention mnot text

npdoty: there's a lot in mnot's text, in describing three categories and giving guidance to spec authors that they should specify what should happen in each of those categories

hadleybeeman: should look for more browser vendor interest
... and someone who could coordinate and direct work

tara: could have an event if enough people of interest

weiler: if we have a vision of constructive deliverables ....

dbates: I'm not sure if standardization is a way forward, but one strawman idea
... providing a way that web sites can document their affiliation with other websites, in a way that the UA can inform somebody, so that the user knows what information will be shared

weiler: could be similar to shared security domains/origins

dbates: standardize a way for websites to tell you what other websites it will share information with

hadleybeeman: Internet Advertising Bureau has a proposal (ads.txt) on who can sell what ads

npdoty: P3P also included some features (our_host or same_host or something) we might consider as prior art

<tara> Web Authentication: An API for accessing Public Key Credentials Level 1

<tara> https://w3c.github.io/webauthn/

<tara> Changes coming over the weekend...

<tara> What is best to review?

<tara> Scribing mainly taking place on webauthn IRC - refer to those minutes for this item

<tara> We are now claiming our 30 minute break - back at 4, back on the agenda

<tara> With Item #9 - Highlights of privacy-relevant efforts in other groups

Highlights of privacy-relevant efforts in other groups

<mkwst> Yoshiro: HTTPS in local network.

<mkwst> ... Working on a document.

https://www.w3.org/community/httpslocal/

<mkwst> ... Will consult this group when there's a draft ready.

<mkwst> tara: Do you have a timeline?

<mkwst> Yoshiro: Hoped for before TPAC, didn't quite make it.

<mkwst> npdoty: How is this being done now?

<mkwst> ... Do enterprises install a root certificate?

<mkwst> Yoshiro: That is one idea that can work.

<mkwst> ... Integration with ACME.

https://datatracker.ietf.org/wg/acme/charter/

<mkwst> npdoty: That seems of interest to this group.

<mkwst> ... Browsers have proposed restricting features to HTTPS, hear feedback from developers that that should be simpler.

<mkwst> ... Moving more things towards HTTPS is good.

<mkwst> jnovak: Attended the "Improving Ads on the Web" session.

<mkwst> ... New business group.

<mkwst> ... Co-chairs from Nielson and IAB.

<mkwst> ... Talking about how to improve ads' experience for users, publishers, and advertisers.

<mkwst> ... They see browsers taking different tacks:

<mkwst> ... "Safari targeting retargeting. Firefox targeting ads. Google targeting experience."

<mkwst> ... Trying to better map the space so folks can discuss them in a more wholistic way.

<mkwst> ... Interesting that co-chairs are Nielson and IAB, not more traditional web companies.

<jnovak> https://www.w3.org/community/web-adv/

<mkwst> [discussion of WebRTC that the scribe missed because ChromeOS dev channel. :( ]

<mkwst> [3DS]

<mkwst> jnovak: "Here are the things that 3DS is doing."

<tara> We don't have any info from WebRTC so should sync with them to see what up

<mkwst> ... Way to deal with card-not-present transactions.

<mkwst> ... Right now, put card into a web form, get an OTP on the phone.

<mkwst> ... Flows to improve that experience.

<mkwst> tara: We talked to folks about payment mechanisms, but didn't have deep privacy discussions.

<mkwst> ... Blog post about privacy concerns in Web Payments, determine which payment methods a user has.

<mkwst> ... https://blog.lukaszolejnik.com/privacy-of-web-request-api/

<mkwst> ... Permissions breakout.

<mkwst> ... Discussion of how they're done, at what level, how we ask users.

<mkwst> ... Leading towards permissions workshop next year.

<mkwst> ... Probably something that PING should be involved in.

<mkwst> npdoty: I went to Web of Things.

<mkwst> ... Trying to document the security models.

<tara> WebAppSec?

mkwst: security stuff is generally useful for privacy
... finer-grained origins (sub-origins, or maybe another name), whether or not that should be exposed to users (generally: probably not)
... still quite early
... chunk your origin into pieces (different applications within example.com), segregate them and restrict their access to each other
... old applications are still on an origin, and hard to move, but could be dangerous regarding xss
... users probably won't be satisfied with clearing their state on only one application within an origin
... could use more help figuring it out
... origin configuration, with a manifest file on your origin, a single point of control for a variety of origin-wide configuration settings (HSTS could be done this way, for example)
... extract from resource responses and instead put into a configuration file in a well-known location
... advertise it to the origin, and then don't send down headers on every request
... acts like a cookie (because it could be declared specific to a user)
... would probably need to be cleared simultaneously
... makes it harder because when users block cookies, we'd have to ignore that configuration

https://wicg.github.io/origin-policy/

<mkwst> https://wicg.github.io/origin-policy/#tracking

acts like a cookie in the sense that the client needs to send the version number of the manifest back to the server each time so that it can be updated

if there were some caching or declarative solution to prevent that version number from being abused as a cookie, that would be helpful

mkwst: Clear-Site-Data for sites to clear all the data, or to clear out after a site has been hacked

https://w3c.github.io/webappsec-clear-site-data/

mkwst: feedback from Chrome shipment so far is that the buckets are very coarse, and some would like more granular about what they clear

feedback on this spec would be useful

Planning next year's work

tara: privacy/security questionnaire and mitigating fingerprinting are documents to work on that we publish as a group
... private browsing mode a topic to talk more about (it could turn into a document, or maybe not)
... other groups are talking about "incognito mode" with unclear assumptions
... defining common terms for use elsewhere

whether we should weigh in on dnt ongoing, utility and viability

follow-ups on Generic Sensors, Webauthn, Web Payments, @@

tara: could we make W3C a center of excellence regarding privacy on the Web (via dsinger)?
... are there ways to bring in more privacy expertise, bring in someone to talk of interest to people in various groups?
... how do we get and retain sufficient resources and contributions?

npdoty: concerned about sustainability from volunteer effort. funding is one possibility used by other standards bodies

jnovak: the possibility of informal requirements now, but should we consider formal requirements?

npdoty: having a formal requirement without people and expertise probably wouldn't work, but we might be getting to a point now where we could usefully do that

mkwst: did nudges with Bikeshed/Respec, provide a warning for authors
... could talk with dsinger about the Process
... the questionnaire is part of the TAG's design review template, so it asks you whether you've looked at it
... and Blink asks everyone to go through the TAG process
... so it would have an impact
... could PING integrate reviews with TAG's design reviews?
... could have a "TAG buddy" for a particular call

tara: via weiler, could use lightning talks at industry/research conferences to highlight ongoing work and volunteer opportunities
... a la EasyChair, an automated system for tracking reviews and reminding people

npdoty: will follow up and ask plh about the use of github labels to identify issues across repositories

[none of us are quite sure how that works, but we are interested]

<tara> Next call?

<tara> Tentatively Dec 14; will check with Christine

<tara> That is all for TPAC, folks -- thanks!

trackbot, end meeting

- DRAFT -

Privacy Interest Group

09 Nov 2017

Attendees

Contents