W3C home > Mailing lists > Public > public-automotive@w3.org > October 2015

Re: Requirements from Seattle use cases

From: Junichi Hashimoto <xju-hashimoto@kddi.com>
Date: Fri, 9 Oct 2015 11:25:41 -0700
To: Paul Boyes <pb@opencar.com>, public-automotive <public-automotive@w3.org>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>, "public-auto-privacy-security@w3.org" <public-auto-privacy-security@w3.org>
Message-ID: <561806A5.2030605@kddi.com>

I think there are at least two items that we should consider deeper from 
the aspect of privacy. That is ID and Log(history) functions.

As to user ID, we have three requirements in the list[1].
No. 30 requires that the driver exclusively logs into system during 
driving as if the user of a classical web browser does. On the other 
hand, No. 32 requires that a passenger whom a probe data belongs to 
should be identifiable. It implies that the data might be controlled by 
multi-user. I think that a single user model is preferable to avoid 
complicated privacy control. Moreover this feature should be supported 
by browser level instead of API so that apps will be free from switching 
user preference.

As to Log(history) data, automaker might want to see all of them while 
driver might want to hide it after an accident. I think we should stand 
with the user side and provide  a way to clear the log data. One idea is 
treating log as cookie. Cookies are recorded in background and browser 
provides user a way to clear them. Even if it is impossible to clear 
actual data on ECU, the browser still can hide log which is recoded 
before user requests to clear them.

What do you think of them?


On 15/10/8 11:19 , Junichi Hashimoto wrote:
> Hi,
> I've updated the worksheet.
> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=1828778399
> In the Requirements sheet of the above document, 32 requirements are
> listed. I derived these requirements from factors of the use cases that
> we listed up in the Seattle F2F.
> Related use case is referred by its number. For example, a requirement
> "Users should be possible to restrict API depending on application" is
> from use case number 27 and 44.
> The purpose of this matrix is to make clear which item should be covered
> by the spec and how to treat other items. It requires consideration from
> several aspects such as feasibility, responsible module, vehicle topic
> or not, etc. My thought is described in column I.
> I'd like to ask members to review the column as well.
>  From my perspective, there are at least two items which we should
> consider deeper. They is user ID and Log(history). I'll post another
> mail about them.
> Regards,
> Junichi
Received on Friday, 9 October 2015 18:32:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:45 UTC