Privacy Interest Group Teleconference -- 28 Sep 2017

<christine> looking for a scribe

<scribe> scribenick: weiler

<npdoty> +1

<christine> Agenda item - privacy consideration of vehicle information specs

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.
... we have many because @@, but we expect that number to grow.
... not all manufacturers will expose all. component vendors may not expose details.
... manufacturers conscious re: individual privacy. looking, per-application, at what people want to access.
... e.g. a Waze-type application that knows fuel level, may not need to know # of pax in the vehicle.
... some apps will send data off of the vehicle to manuf.'s data silos.
... there will be third parties that want intrusive data, e.g. insurance companies.
... current practice is opt-in.

weiler: who's done the analysis of what's privacy sensitive v. not?

ted: everything is considered sensitive - there is not granularity.
... planing to launch new RG at MIT; want to go further w/ privacy (and sec) guidelines. re: how to expose choices to users.
... all info should be guarded

<npdoty> 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

weiler: is there any data authenticity protection, e.g. something that would present bad data to insurance co.

ted: no such protection. You can falsify info now. Compare this to UDP- signals are in plaintext, unauthenticated.

weiler: as you contemplate doing this sec /auth work, does the charter have any protections for the user?

ted: we haven't gone there.
... between now and EOY... new @@ based on VW submission.
... when group recharters at EOY, that would be a good opportunity to provide input on deliverables.

christine: is there any way to tell that opt-out promise is being honored?

<npdoty> yeah, setting deliverables regarding security and privacy threat modeling and principles might be valuable at re-chartering time

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.

christine: should be transparent if possible.

<npdoty> maybe logging or auditing would be useful capabilities to specify

ted: @3 will show what info applications are allowed to have.

weiler: this is a protocol, not just a data model, right?

ted: yes. can get/set parameters.
... can subscribe to part of tree.

weiler: e.g. set up a notification context.

ted: or periodic notifications v. event-driven.

weiler: given that there's a protocol involved, I was imagining a more thorough walkthrough of the protocol. Should we do that in future?

christine: concerned re: Ted's time.

ted: this time is good.
... willing to go through it later.

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, ....
... this would be useful for the WG to do, in general. and it makes our review easier.
... you said some privacy/sec scenarios were considered - would be good to have those documented (in the doc or otherwise)

ted: we collaborate w/ GENIVI. they have a sec expert group. we're next in the queue, to do a full attack tree.
... we don't have that at present.

nick: will that be public?

ted: don't know.
... will find out.

<npdoty> 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

christine: next call in late Nov. maybe we could do a review during TPAC; join meeting?

ted: WG meets Mon/Tues; could do something then.

<npdoty> maybe we could take the TPAC scheduling conversation offline, but I agree that meeting at a TPAC session would be really useful

cwebber: EFF has lawsuit re: John Deere "freedom to tinker" stuff. this might intersect with this.

ted: there was been legislation re: "right to repair"

cwebber: I'll put you in touch with @3.

christine: will do walkthrough planning offline.
... Web Content Accessibility Guidelines. there is a note re: timeouts, re: privacy regs may require user consent. has anyone looked at this?

nick: I looked at it. I was surprised that we were going into this level of detail.

christine: is it important to flag collection and retention of data, but something generic may be more appropriate.

+1 617-324-0000

meeting number: 648 986 475

<christine> https://www.w3.org/TR/WCAG21/#timeouts

<npdoty> WebEx meeting

<npdoty> https://mit.webex.com/mit/j.php?MTID=meda7c1b71d647aefa4377d4610c67648

<npdoty> +1 617-324-0000

<npdoty> meeting number: 648 986 475

<wseltzer> s|

<keiji> is password for something

christine: joshue, do you want to talk about things other than timeouts?

joshue: some users' accessiblility needs (e.g. re: timeouts) conflict with those from , e.g. a bank.
... privacy implications from keeping data around for long intervals.
... I don't know if there are things beyond timeouts that are concerning. other new stuff is re: how assistive tech interacts w/ browser.

<npdoty> I wouldn't make this guidance refer to compliance regimes and I'm not sure the relevance of mintors and consent is useful

<npdoty> 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

christine: general language alerting to the potential risks and legal requirements may be better than just naming one or two things.

joshue: we'd appreciate guidance re: [how to change text?]. Not as normative changes, but in explanatory & interpretive text.
... beyond timeouts & preserving user data, I'm struggling to find things that implicate privacy.
... I can talk w/ cochair and team contact and add some sort of note re: privacy to our 'understanding' document.
... how does that sound?

christine: good. your group has been at the forefront of thinking re: privacy implications of your work.
... we've appreciated your group's prior engagement because they have an instinct re: protecting privacy.
... we were tying to say 'there's a lot of detail in your spec re: timeouts; maybe you need something more general instead'

nick: I think that's right

christine: we should help you with that language.

cwebber: I'm coeditor of activity pub. a decentralized social networking protocol. now at CR.

<cwebber> https://www.w3.org/TR/activitypub/#Overview

cwebber: can implement either part. uses activity streams vocabulary.

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.
... but also abuse unexpected disclosure, etc.

cwebber: one was delivery... mastadon does support private messaging.
... activity streams msgs have an addressing mechanism similar to email
... mastodon provides some tooling including a 'block' verb. activity pub is a traditional C-S protocol by default...
... 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.

<npdoty> those are really useful descriptions/analogies for us, thanks, cwebber

weiler: how o you prevent disclosure of connections / disclosure of the network?

<npdoty> it seems like implementation of followers/following collections would lead to that kind of disclosure

cwebber: if publicly addressed msgs, can just look at addressing. activiyy pub does not specify if followers list is public.

<npdoty> > Every actor SHOULD have a following collection.

cwebber: activity pub servers can expose follow/following lists.

<npdoty> collections can have separate access control (I missed that on reading the spec initially)

<christine> time check

weiler: e2e crypto not on by default?

cwebber: right

weiler: can we change that default?

cwebber: no. spec is built around accommodating existing nets as built. lots of server-side side-effects e.g. counting 'favor" bits.

<cwebber> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/RWOT-User-Story.md

cwebber: 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....
... there are new directions to improve this going forward, but this was built to accommodate existing networks as built.
... I'd be more available in the future than today.

next call Oct 19th, to plan for TPAC (if nothing else)

chrsitine: if there are ideas for language for WCAG timeouts bits, send them.

- DRAFT -

Privacy Interest Group Teleconference

28 Sep 2017

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output