<tara> Giving people a few minutes to join...

<weiler> scribenick: weiler

TPAC review

<tara> https://www.w3.org/2017/11/09-privacy-minutes.html

tara: ~20 people at TPAC, drifting in and out. some visitors. Enjoyed Jason's energy. Did several reviews.
... large items were 1) tackling priv & sec questionaire. Need to coordinate w/ TAG.

2) nick's mitigating fingerprinting. time to ship it as a group note.

3) hadley beeman did a presentation on consistency in private browsing modes. need to decide what work to do in that space. some inconsistent assumptions of what happens in those modes since there's not a uniform definition.

4) tracking protection WG asked us if we want to weigh in on viability of that work.

<npdoty> I wasn't clear what the next step was for private browsing mode. do we have a proposed document with an editor?

5) David Singer brought up topic of making W3C a center of excellence for privacy on the web.

scribe: how do we bring in talks/resources/expertise
... Answering Nick: not clear. Multiple docs: MNot's + Hadley's presentation. need to f/u. first step: determine if we want to take this on. Not sure which doc/editor to run with.

<npdoty> okay, I think we are interested, but I think maybe we are waiting for mnot or hadleybeeman to propose a more specific task that they want help with

scribe: I still need to write up notes from TPAC.

Nick: Do we want to send comments on DNT or not?

tara: I don't think we had decided. Q is do we want to.

wseltzer: one Q that would come up if group wants to go past CR is "did you get wide review". Might be good to get this group's thoughts on a spec which is so privacy focused.
... Might be diverse opinions re: value on work WRT privacy on the web (in the current environment). I don't see implementation/use - my Q is how do we get from here to there? If we don't get there, is there value to recommending DNT as a spec? or recommend that it wait for further implementation?

Nick: what's our action?

tara: does that fall to a chair?

wseltzer: the chair should at least assign the action.

weiler: message is from IG, not from chair. doesn't matter who drafts it.

<npdoty> I think dsinger, npdoty and wseltzer are the participants who have been most involved, if the chair wants to start a separate email thread

<wseltzer> +1

jason: One other piece of TPAC biz: we talked to WebAuthn, and there was much confusion.
... they were going to revise...

weiler: new version is out and ready for review.

<wseltzer> WebAuthn WD 07

tara: they didn't send to the list.

weiler: *sighs*

nick: we also talked to sensors folks; they need feedback soon.
... Jason and I(?) took the action to raise points. Not sure if we have a plan to finish that.

<Zakim> npdoty, you wanted to ask about generic sensors

jason: if there are known attacks e.g. ambient light, gyro - those should be in the specific specs, not incorporated by reference. I'll file issues in github.

weiler: nick, can you f/u w/ Phillipe re: tagging issues for privacy - this seems like a good opportunity.

nick: you do that.

<npdoty> jnovak, I'd be interested in those issue links as well

<jnovak> will do.

tara: AOB re: TPAC?

<npdoty> did the AC discuss dsinger's "center of excellence" topic?

tara: TPAC in Lyon next year.

wseltzer: my action from tpac was to check in with Christine re: questionaires - I saw her at IETF the next week and got her agreement that she was working to consolidate those.

<npdoty> wseltzer traveled all the way to Singapore just to check in with Christine!

tara: I don't know re "center of excellence".... I 'll f/u w/ Dave Singer.

weiler & wseltzer: don't recall any details from AC mtg (and were not there for all of it)

Web Audio API

<tara> https://webaudio.github.io/web-audio-api/

<tara> https://github.com/WebAudio/web-audio-api

<tara> https://webaudio.github.io/web-audio-api/#Security-Privacy-Considerations

weiler: is the right answer to invite them to our next call?

<npdoty> they have some tentative questionnaire answers in the editor's draft, and at least a privacy issue in github

tara: yes. they said they wanted by EOY but let them know if we want more time; they want comments in github

nick: seems like a large fingerprinting surface. shouldn't commonly be needed and may reveal a lot of hardware details.

jason: while this is an audio API, it doesn't necessarily require the playing of audio to do the fingerprinting.
... this is probably rarely needed. implication would be "if a user is using it, a sound will be playing". But it doesn't require playing a file in order to do the fingerprinting.

nick: seems like there should be a natural mitigation. complicated audio.... but there's nothing in the spec limiting it so.

weiler: a permission issue, perhaps?

nick: ideally you wouldn't throw another permission, but we should be able to divide sites into ones where it makes sense and ones where it does not.
... could be permissions. could be inference.

tara: I'll cirlce back with them we see if they can join us in Jan. or if that is too late for them.

weiler: with holiday schedules, letting them accept only comments over the next two weeks may not get far...

tara: but go ahead and file comments

WebRTC Working Group

<tara> https://w3c.github.io/mediacapture-image/

<tara> https://w3c.github.io/mediacapture-fromelement/

<tara> https://w3c.github.io/mediacapture-record/

tara: feedback before jan 12; this was sent on Dec 2.
... also want github issues.

<npdoty> I don't totally understand how this differs from getUserMedia ... are these things that sites can't do yet, or just like a convenient API on top?

tara: I don't know re: difference from getUserMedia

Jason: went I reviewed @@ APIs... these could be layered on top of getUserMedia, and inherit all of the privacy concerns and add a few wrinkles. e.g. in image capture, some addl metadata on camera and photos
... there might be some non-camera data in image, like location..
... So Q is what addl is revealed, and what addl mitigations are needed, on top of getUserMedia
... in mediaCaptureFromDOM - discussion re: what source can be, .@@ ... spec makes this a requirement, but doesn't give much impl. guidance. Q for us: to what extent should that be spec-driven v. implementation-driven?

<npdoty> +1, that's an interesting write up in the Security Considerations section there: https://w3c.github.io/mediacapture-fromelement/#security-considerations

jason: has anyone else looked at @4 business group? (web advertising?)

<npdoty> is there a link / mailing list / agenda?

wseltzer: I have joined it. welcome participation from those thinking of privacy. what are places

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

wseltzer: all constituents of web think we can make advertising environment better
... e.g. accessibility.
... privacy is a factor. advertisers would like unique identifiers.

tara: any regular mtgs?

wseltzer: mailing list. potential calls or w/s.

keiji: I was not at TPAC. there was a group on web marketing. this is a different group?

wseltzer: this is a new BG. there were previous attempts to get conversation going ... this has a broader set of participants.
... marketing group was never a "group".

tara: jason, you might have some colleagues in the group - at least wendy.

schedule next call

tara: conflicts? I'm assuming late.

weiler: if we can get groups to show up, maybe start reviews in early Jan?
... e.g. WebAuthn wants comments before EOY.

<npdoty> scribenick: npdoty

weiler: if you're familiar with yubikeys and similar tokens, part of the spec allows tokens to provide a batch identifier regarding their provenance
... the number of devices with the same identifier might be too low, so that you can link users across different sites (which otherwise was going to be prevented)
... some sites don't care about the batch, but other sites do and will want to blacklist tokens that have known compromises
... and whitelisting would have negative ecosystem consequences for smaller new manufacturers
... attestations could be taken through a proxy (Google proposed Privacy CA), where Google would do the investigation and remove the batch identifier
... pushback on the idea of going through a single vendor
... linkability of the AAGUID is the most notable privacy consideration

npdoty: Mozilla suggested that it could just be stripped/replaced with self-signed, if not many sites cared about the batch id

weiler: that was a stronger proposal, that it wasn't needed at all for sites to know what the device is. we could have the opinion that the risk to privacy was too great

npdoty: different users have different privacy concerns, should have documented options

weiler: some members of the payments industry would argue that they can't do business in those cases

<tara> We're at time -- shall we take this to the mailing list?

npdoty: that might be acceptable, there might be some situations where it isn't possible to provide assurances to do business

<weiler> tara: leaving Jan 4th as tentative first meeting.

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/in the Christine/in with Christine/
Succeeded: s/a couple privacy issues/a privacy issue/
Succeeded: s/like image/like location./
Present: npdoty tara wseltzer jnovak weiler keiji
Found ScribeNick: weiler
Found ScribeNick: npdoty
Inferring Scribes: weiler, npdoty
Scribes: weiler, npdoty
ScribeNicks: weiler, npdoty
Found Date: 14 Dec 2017
People with action items: 

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.)