15:59:22 RRSAgent has joined #privacy 15:59:22 logging to http://www.w3.org/2017/09/28-privacy-irc 15:59:24 RRSAgent, make logs 263 15:59:27 Meeting: Privacy Interest Group Teleconference 15:59:27 Date: 28 September 2017 16:00:29 keiji has joined #privacy 16:00:35 present+ 16:00:39 present+ 16:00:40 Present+ Ted 16:00:52 present+ 16:01:15 present+ 16:01:40 zakim, who is here? 16:01:40 Present: terri, npdoty, dsinger, tara, keiji, weiler, wseltzer, cwebber, Ted, christine 16:01:43 On IRC I see keiji, RRSAgent, ted, cwebber, christine, nigel, chaals, LCPolan, dustinm, yoav, Mek, plinss, jyasskin, terri, mkwst, dveditz, natasha, weiler, Zakim, trackbot, 16:01:43 ... mounir, adrianba, hadleybeeman, wseltzer 16:01:45 regrets+ tara 16:01:56 present+ weiler 16:01:59 npdoty has joined #privacy 16:02:10 present: wseltzer, cwebber, ted, keiji, christine, weiler 16:02:10 present+ 16:02:16 zakim, who is here? 16:02:16 Present: wseltzer, cwebber, ted, keiji, christine, weiler, npdoty 16:02:18 On IRC I see npdoty, keiji, RRSAgent, ted, cwebber, christine, nigel, chaals, LCPolan, dustinm, yoav, Mek, plinss, jyasskin, terri, mkwst, dveditz, natasha, weiler, Zakim, 16:02:18 ... trackbot, mounir, adrianba, hadleybeeman, wseltzer 16:02:30 looking for a scribe 16:02:43 scribenick: weiler 16:04:07 -> http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html VISS spec 16:04:07 -> https://github.com/GENIVI/vehicle_signal_specification/ data model 16:04:29 +1 16:04:57 Agenda item - privacy consideration of vehicle information specs 16:05:42 ted: exposing signals from a vehicle (e.g. speed, tire pressure, brake status) ... not exposing these directly on the internet - do not want vehciles to be addressable with a link. 16:06:05 ... we have many because @@, but we expect that number to grow. 16:06:41 ... not all manufacturers will expose all. component vendors may not expose details. 16:07:28 ... manufacturers conscious re: individual privacy. looking, per-application, at what people want to access. 16:08:09 ... e.g. a Waze-type application that knows fuel level, may not need to know # of pax in the vehicle. 16:08:30 ... some apps will send data off of the vehicle to manuf.'s data silos. 16:08:51 ... there will be third parties that want intrusive data, e.g. insurance companies. 16:09:02 ... current practice is opt-in. 16:09:29 weiler: who's done the analysis of what's privacy sensitive v. not? 16:09:41 ted: everything is considered sensitive - there is not granularity. 16:10:41 ... planing to launch new RG at MIT; want to go further w/ privacy (and sec) guidelines. re: how to expose choices to users. 16:11:12 ... all info should be guarded 16:11:14 that principle of general data minimization is sound, but it might be useful to think through the different classes of privacy implications related to different kinds of data 16:11:34 weiler: is there any data authenticity protection, e.g. something that would present bad data to insurance co. 16:12:12 ted: no such protection. You can falsify info no. Compare this to UDP- signals are in plaintext, unauthenticated. 16:13:21 s/no./now./ 16:13:34 weiler: as you contemplate doing this sec /auth work, does the charter have any protections for the user? 16:13:40 ted: we haven't gone there. 16:14:08 ... between now and EOY... new @@ based on VW submission. 16:14:59 ... when group recharters at EOY, that would be a good opportunity to provide input on deliverables. 16:15:34 christine: is there any way to tell that opt-out promise is being honored? 16:15:39 yeah, setting deliverables regarding security and privacy threat modeling and principles might be valuable at re-chartering time 16:16:30 ted: nothing in spec re: telling the user what is being shared. I have seen this suggested as guidelines... if it should be part of the spec.... this would be an opportune moment to introduce a new req. 16:17:13 christine: should be transparent if possible. 16:17:20 maybe logging or auditing would be useful capabilities to specify 16:17:23 ted: @3 will show what info applications are allowed to have. 16:17:24 chaals-o has joined #privacy 16:18:05 weiler: this is a protocol, not just a data model, right? 16:18:19 ted: yes. can get/set parameters. 16:18:39 ... can subscribe to part of tree. 16:18:48 weiler: e.g. set up a notification context. 16:19:16 ted: or periodic notifications v. event-driven. 16:20:42 weiler: given that there's a protocol involved, I was imagining a more thorough walkthrough of the protocol. Should we do that in future? 16:21:04 q+ on threat modeling 16:21:05 christine: concerned re: Ted's time. 16:21:17 ted: this time is good. 16:21:33 ... willing to go through it later. 16:22:15 npdoty: thanks, ted. this is a different type of spec for us.... as I read through this spec, it would be useful to do a more detailed threat mdoel. identify potential attacker; where they'd be in the system, .... 16:22:38 ... this would be useful for the WG to do, in general. and it makes our review easier. 16:23:06 ... you said some privacy/sec scenarios were considered - would be good to have those documented (in the doc or otherwise) 16:23:21 q+ 16:23:25 q- 16:23:42 ted: we collaborate w/ GENNIVE. they have a sec expert group. we're next in the queue, to do a full attack tree. 16:23:49 ... we don't have that at present. 16:23:58 s/GENNIVE/GENIVI/ 16:23:58 nick: will that be public? 16:24:02 ted: don't know. 16:24:54 ... will find out. 16:25:37 I understand not all groups will have public as their default process, but I was mentioning it because security would be especially important for wide-spread review 16:26:32 q? 16:26:42 christine: next call in late Nov. maybe we could do a review during TPAC; join meeting? 16:26:52 ack cwebber 16:26:55 ted: WG meets Mon/Tues; could do something then. 16:27:25 maybe we could take the TPAC scheduling conversation offline, but I agree that meeting at a TPAC session would be really useful 16:28:00 cwebber: EFF has lawsuit re: John Deere "freedom to tinker" stuff. this might intersect with this. 16:28:57 ted: there was been legislation re: "right to repair" 16:29:45 cwebber: I'll put you in touch with @3. 16:30:06 christine: will do walkthrough planning offline. 16:32:05 christine: Web Content Accessibility Guidelines. there is a note re: timeouts, re: privacy regs may require user consent. has anyone looked at this? 16:32:25 nick: I looked at it. I was surprised that we were going into this level of detail. 16:33:30 christine: is it important to flag collection and retention of data, but something generic may be more appropriate. 16:34:48 +1 617-324-0000 16:34:48 meeting number: 648 986 475 16:35:47 AndroUser has joined #privacy 16:36:26 https://www.w3.org/TR/WCAG21/#timeouts 16:37:21 WebEx meeting 16:37:21 https://mit.webex.com/mit/j.php?MTID=meda7c1b71d647aefa4377d4610c67648 16:37:22 +1 617-324-0000 16:37:23 meeting number: 648 986 475 16:37:49 s|https://mit.webex.com/mit/j.php?MTID=meda7c1b71d647aefa4377d4610c67648 16:37:54 s|https://mit.webex.com/mit/j.php?MTID=meda7c1b71d647aefa4377d4610c67648|| 16:38:57 W3CPINGMM 16:39:05 is password for something 16:39:41 s|W3CPINGMM|| 16:40:59 rrsagent, draft minutes 16:40:59 I have made the request to generate http://www.w3.org/2017/09/28-privacy-minutes.html wseltzer 16:41:15 rrsagent, make logs public 16:41:17 rrsagent, draft minutes 16:41:17 I have made the request to generate http://www.w3.org/2017/09/28-privacy-minutes.html wseltzer 16:41:55 christine: joshue, do you want to talk about things other than timeouts? 16:42:57 joshue: some users' accessiblility needs (e.g. re: timeouts) conflict with those from , e.g. a bank. 16:43:33 ... privacy implications from keeping data around for long intervals. 16:45:01 ... I don't know if there are things beyond timeouts that are concerning. other new stuff is re: how assistive tech interacts w/ browser. 16:45:03 I wouldn't make this guidance refer to compliance regimes and I'm not sure the relevance of mintors and consent is useful 16:46:57 could just note that there potentially is a tension with privacy when data is retained, either on the client-side or the server-side, rather than focusing on legal compliance in different jurisdictions 16:48:08 christine: general language alerting to the potential risks and legal requirements may be better than just naming one or two things. 16:49:31 joshue: we'd appreciate guidance re: [how to change text?]. Not as normative changes, but in explanatory & interpretive text. 16:49:55 ... beyond timeouts & preserving user data, I'm struggling to find things that implicate privacy. 16:50:21 ... I can talk w/ cochair and team contact and add some sort of note re: privacy to our 'understanding' document. 16:50:33 ... how does that sound? 16:50:51 christine: good. your group has been as the forefront of thinking re: privacy implications of your work. 16:50:57 s/as the/at the/ 16:51:20 ... we've appreciated your group's prior engagement because they have an instinct re: protecting privacy. 16:51:51 ... we were tying to say 'there's a lot of detail in your spec re: timeouts; maybe you need something more general instead' 16:51:58 nick: I think that's right 16:52:14 christine: we should help you with that language. 16:54:29 AndroUser2 has joined #privacy 16:54:33 Chis: I'm coeditor of activity pub. a decentralized social networking protocol. now at CR. 16:54:41 https://www.w3.org/TR/activitypub/#Overview 16:54:58 s/Chis/cwebber/ 16:55:17 cwebber: can implement either part. uses activity streams vocabulary. 16:56:33 nick: mastodon has gotten some usage. looks like twitter, but federated. lots of privacy issues in the space. not just identifying particular browsers or privacy. 16:56:43 ... but also abuse unexpected disclosure, etc. 16:57:07 cwebber: one was delivery... mastadon does support private messaging. 16:57:08 q+ 16:57:22 .... activity streams msgs have an addressing mechanism similar to email 16:58:31 ... mastodon provides some tooling including a 'block' verb. activity pub is a traditional C-S protocol by default... 16:59:12 ... comparable to email. if server is malicious or compromised, .... there is an module for end to end crypto but it breaks some of the server features. 16:59:34 those are really useful descriptions/analogies for us, thanks, cwebber 16:59:54 weiler: how o you prevent disclosure of connections / disclosure of the network? 17:00:08 it seems like implementation of followers/following collections would lead to that kind of disclosure 17:00:22 cwebber: if publicly addressed msgs, can just look at addressing. activiyy pub does not specify if followers list is public. 17:00:34 > Every actor SHOULD have a following collection. 17:00:49 ... activity pub servers can expose follow/following lists. 17:02:44 collections can have separate access control (I missed that on reading the spec initially) 17:03:29 time check 17:04:08 weiler: e2e crypto not on by default? 17:04:15 cwebber: right 17:04:21 weiler: can we change that default? 17:04:56 cwebber: no. spec is built around accommodating existing nets as built. lots of server-side side-effects e.g. counting 'favor" bits. 17:05:42 https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/RWOT-User-Story.md 17:06:32 ... i have a paper.... could move more to p2p. not using heavy, http-based nodes. if you're worried about observation of server-side side effects, use a smaller server and e2e crypto.... 17:08:05 ... there are new directions to improve this going forward, but this was built to accommodate existing networks as built. 17:08:29 ... I'd be more available in the future than today. 17:09:49 next call Oct 19th, to plan for TPAC (if nothing else) 17:10:02 chrsitine: if there ideas for language for WCAG timeouts bits, send them. 17:10:25 s/there/there are/ 17:15:07 rrsagent, draft minutes 17:15:07 I have made the request to generate http://www.w3.org/2017/09/28-privacy-minutes.html keiji 19:04:30 LCPolan has joined #privacy 20:07:24 yoav has joined #privacy 20:59:39 LCPolan has joined #privacy