How is WG protecting sensitive info

[samuelweiler]

Some of the data discussed are sensitive, particularly if they're combined with identifying information. Some are likely sensitive on their own (e.g. navigation) and others could be used to synthesize sensitive information (e.g. speed + wheel position, over time).

What is the WG's approach to protecting that information - or giving the user control over its transmission?

I wonder if a comprehensive approach is needed here - in particular, having information constraints applied on the vehicle, before the information leaves the user's control.

Perhaps the WG needs to add (or start with) an architectural description doc?

[tguild]

We are working on an accompanying In-Vehicle Application Best Practices document, regular calls and wiki but no draft document yet.

"The group intends to deliver In-Vehicle Application Best Practices to address many of the issues arising from allowing applications to reside and run on vehicles."

"The Automotive Working Group will follow and provide input on SDW group's unpublished Responsible Use of Geospatial Data, potentially drawing from it in the In-Vehicle Best Practices document for some of its privacy considerations."

[tguild]

We also note this information is subject to various existing and evolving state (eg Massachusetts recent right to repair ballot), nation and EU regulation which OEMs and telematics service providers need to comply with.

[samuelweiler]

In W3C specs, I expect privacy protections to baked into the specs from the beginning, not relegated to the backwater of "best practices".

I want to see robust technical fixes - including user consent and auditability. e.g how does a person stop the collection of geospatial data entirely, or at least prevent it from leaving the vehicle?

In this SDO, I am much less interested in policy-based protections for data once it leaves the vehicle.

[tguild]

Current practice for some connected vehicles is contractual agreements with owners, offline. Do we have any general consent capture work at W3C we could leverage, believe I asked you/PING for this in the past? Consent capture is a broader issue not limited to automotive. We have also been in discussion with EU SPECIAL project. While SPECIAL has some affiliation with W3C, do not believe aligned with PING.

While admirable, unsure how we can audit information use after the fact. My preferred solution and one not likely we can get the industry to adopt is proxy re-encryption https://www.w3.org/2019/09/trans-data-ws/W3_NuCypher_AHassard_09.13.19.pptx which gives the individuals fuller control on usage of their data by third parties.

[samuelweiler]

Do we have any general consent capture work at W3C we could leverage

We have this guidance on adding permissions which might soon be published as an IG note. It's written with the web in mind but is applicable in other contexts.

Current practice for some connected vehicles is contractual agreements with owners, offline.

That is, in fact, my concern.

As above, in W3C specs, I expect privacy protections to be provided using primarily technical measures.

I also expect consent to be obtained without coercion and to be easily revokable. Consent is meaningless when it is coerced, and "your car is bricked" is pretty coercive. We have also talked about the used car market and how a subsequent owner or a non-owner driver might want to revoke consent. Imagine, if you will, a regulatory regime where owner consent is not enough - and driver consent is needed. Perhaps we should be engineering to accommodate such a regulatory regime.

Consent capture is, IMHO, not the problem here. Gracefully degrading when consent is denied or revoked is the problem.

(For example: assume that one of the contracts you mention is revoked - perhaps through statutory or judicial means - how does the technology implement that revocation?)

[tguild]

I note a Note is even further backwater than even a Best Practice :) Still useful guidance and at the very least should factor into In-Vehicle Best Practices considerations but to clarify, there isn't any consent capture in any W3C specifications?

I am now confused by your earlier request of having a technical solution including consent and audit mechanisms in the specifications. We can and should have something in the VISS version 2 specification that states an application should have explicit consent to 'off-board' any information, must abide by any privacy regulations applicable to the location the vehicle is in, nationality of individual operating the vehicle (GDPR protections follows EU citizens outside of EU) or otherwise not run (application, not brick vehicle) that could be added. Would that suffice? This seems more specification specific than charter but if there is a W3C charter that addresses this concern, again broader and not unique to automotive, would be pleased to have an example to follow.

Used and rental vehicles, including wiping any personal information is in scope of our best practices document.

[tguild]

It might help to understand that in-vehicle application marketplaces will be operated by automotive manufacturers or designated service providers. It will not be the same free for all of smartphone apps due to privacy, security, legislative and other considerations.

[samuelweiler]

There might be some useful parallels to draw from the Devices and Sensors work - since many of these data times are from sensors - often the same sorts of sensors that WG is dealing with. Some examples:

From the battery status api: "The user agent should inform the user of the API use by scripts in an unobtrusive manner to aid transparency and to allow the user to revoke the API access."

And sometimes the DAS WG has invented novel mitigations, downgrading the frequency or resolution of data provided: "To mitigate these Ambient Light Sensor specific threats, user agents should use one or both of the following mitigation strategies:"

[samuelweiler]

It might help to understand that in-vehicle application marketplaces will be operated by automotive manufacturers or designated service providers. It will not be the same free for all of smartphone apps due to privacy, security, legislative and other considerations.

That is an interesting choice of parallel. The operators of smartphone app stores are large companies - comparable in revenue, perhaps, to the largest of automakers, but much larger than the smallest. And they are tech companies. And even with their financial resources and abundant technical competence on staff, you describe a "free for all of smartphone apps".

This argues - in big, broad, strokes - for engineering-based solutions, not operational ("app marketplace") ones.

[samuelweiler]

there isn't any consent capture in any W3C specifications?

I don't (fully) understand what you mean by "consent capture", so feel free to clarify.

I'm not immediately aware of any. The feedback I hear is that browser developers want freedom to experiment with UI. They're fine(*) with being told "this feature needs to have user consent", but they want to do something more clever than a blocking pop-up window every time and be free to change the details when someone invents a better mousetrap. In that case, though, no one is referring to a multi-page, hidden-in-the-fine-print, and perhaps even click-through contract - they have user experience researchers exploring how to meaningfully ask for consent.

An example might be an icon in the browser chrome or on a tab indicating that the tab has microphone and/or camera access. The user can then click on that icon to revoke the permission.

(*) actually, in some cases, some WGs argue against that. There are some WG's, though, like devices and sensors WG and the Immersive Web WG, that understand they're dealing with (very) sensitive info and are taking steps to mitigate that risk.

[tguild]

Android was certainly more of a free for all, eg flashlight apps requiring access to address book. That was cleaned up a fair amount.

Battery spec similar to what I was suggesting above although putting responsibility on service operator (auto manufacturer) wrt having consent and abiding by laws as we do not have UX with which to reach users. As this is getting in the weeds/spec specific, question is more what should go in the charter. Probably something about collaborating with PING on mitigating privacy concerns.

Sampling frequency and accuracy already in scope of our best practices document, adding those resources to our recommended reading and potential references list

[tguild]

For VISS version 2 work item I added: "Privacy considerations concerning use of data will be addressed." Sam and I discussed some explicit items for VISSv2 including above suggestions:

• service operators must ensure they comply with applicable privacy laws

• consent should (some including complying with regional legislation would convert that to see must) be explicit before off-boarding data from the vehicle. The mechanics can be in-vehicle or out of bounds via smartphone, click through agreement at car rental counter, etc

• consent should (again some would like to see must including applicable law) be revokable.

The question is whether to make such assertions in the charter or keep it high level. We can expect pushback if we do not adequately address when we publish.

Given the myriad of nuanced items we have been discussing to date for best practices, some items will belong there. Frequency of data sampling for example is not just a potential privacy concern but safety/operational if underlying control unit is overtaxed and unable to perform core function.

[samuelweiler]

Android was certainly more of a free for all, eg flashlight apps requiring access to address book. ...

Indeed.

... we do not have UX with which to reach users.

Vehicles have enough UI to capture - at the very least - revocation of consent. Here are some examples:

• a hardware radio switch, which could be hidden next to the fuse box or otherwise not on the dashboard. I remember laptops with hardware WiFi switches...

• the mechanism used for programming an early-2000's Toyota to accept new remotes - it involved inserting and turning the key, opening the door, cycling the locks, and similar things in a particular pattern. This mechanism is too clumsy for ordinary users, but it demonstrates an available UI interface with no new hardware. The car honked its horn and cycled its locks to indicate success or failure, so there was even feedback!

• and, of course, the infotainment systems on many vehicles.

Even if existing UI isn't rich enough to do nuanced consent management and is not used to obtain initial consent (which I suspect it is and should be, respectively), vehicles have enough UI to revoke consent. Accordingly, while I would like 1) this WG's specs to mitigate issues at the data level (see below) and 2) the systems to provide more nuanced consent management, I expect the specs to require - at a minimum - a technical means for revoking consent.

Sampling frequency and accuracy already in scope of our best practices document, adding those resources to our recommended reading and potential references list

This sort of mitigation is great! It should be in the normative specs, not in best practices.

[samuelweiler]

We also note this information is subject to various existing and evolving state (eg Massachusetts recent right to repair ballot), nation and EU regulation which OEMs and telematics service providers need to comply with.

This assumes that the OEMs and service providers have the data in the first place. I want car owners and drivers to have control over their data - including how much of it an OEM or service provider collects. Ideally, I'd like to see an architecture where the OEM and service provider(s) are less powerful points of capture and control - and consequently less tempting targets for regulation. If regulators want to demand that owners/drivers make specific data available (whether via the OEM or in other ways), let's have an architecture that encourages them to impose that obligation directly on the owners/drivers and that lets the owners/drivers comply with the specific data demand without providing information that is not subject to the demand. (For example, while a hardware radio switch is a form a user control, it doesn't let the user comply with a mandate for limited data.)

Having had some synchronous discussion with Ted and others, I think the answer to my opening suggestion is "yes":

Perhaps the WG needs to add (or start with) an architectural description doc?

Yes, the WG needs a document describing its overall approach to providing owners and drivers control over their data. (n.b. the WG might well decide to specify an architecture that - contrary to my recommendation above - is more susceptible to capture and control, but I'd like us to go into that with eyes open, with the WG explicitly documenting which tradeoffs they are choosing. In any case, I want to know the story for how users control their data, and that story must provide users with meaningful controls.) No strong preference re: whether this is integrated with https://github.com/w3c/automotive/issues/359 or not.

[samuelweiler]

Thanks to @tguild, @wseltzer, and @swickr for further offline discussion.

Following that, I propose in section 2.2 of the charter (Other Deliverables):

The Working Group will deliver the following W3C non-normative documents:

• Use cases,
• Requirements, and
• A high level architecture for data privacy, explaining at what layer(s) in the technology stack the owner and/or operator will have control over the collection of data as well as what other specific privacy mitigations are anticipated in this group's normative specifications.

The group intends to deliver In-Vehicle Application Best Practices to address many of the issues arising from allowing applications to reside and run on vehicles. [as before]

Other non-normative documents may be created.

In section 3 (Success Criteria):

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users. Additionally, specifications must provide mitigations for the security and privacy issues they raise.

[tguild]

@samuelweiler see https://github.com/w3c/automotive/commit/fcf0cceeadfd10678fd21a0b7ab77fb5d533d5bc#diff-c555837d280da43aa83b39c6a228235146d723ab1340aa4b58ad7a374d899eed

Based on your proposed text, side conversations with various people and comfort from group on today's call.

The Working Group will deliver the following W3C non-normative documents:

Use cases,

Requirements, and

High level architecture for information flows to facilitate understanding of the different standard and proprietary solutions being used within the industry and to further discussions on data privacy considerations throughout.

In-Vehicle Application Best Practices to address many of the issues arising from allowing applications to reside and run on vehicles including but not limited to security, privacy and safety considerations beyond the confines of specifications being delivered.

Privacy Interest Group

The Automotive Working Group will organize an open discussion with the Privacy Interest Group to explain standards it is creating, ecosystem it will be utilized in and seek input on its deliverables for protecting personal information.

(instead of the previous solicit review since that is required anyhow)

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users. (as it appears in current charter template)

[samuelweiler]

@tguild

High level architecture for information flows to facilitate understanding of the different standard and proprietary solutions being used within the industry and to further discussions on data privacy considerations throughout.

Will that architecture make it clear at what layer(s) in the technology stack privacy controls can be usefully applied, possibly (hopefully!) including giving the owner and/or operator will have control(s) over the collection of data? (This question is a modified version of what I proposed above.)

In-Vehicle Application Best Practices to address many of the issues arising from allowing applications to reside and run on vehicles including but not limited to security, privacy and safety considerations beyond the confines of specifications being delivered.

Keep in mind, though, that PING typically expects privacy issues to be mitigated normatively in the specs that create the issues. If mitigations are instead at a different layer(s) of the stack, PING will expect (at the least) to be convinced of the strength of those mitigations.

[tguild]

@samuelweiler we cannot speak to other organizations standards wrt controls but can make clear some of the various potential information flows. We expect mix of proprietary and standard based solutions. Again, the point of the best practices document underway is to speak to the larger ecosystem.