RE: Requirements from Seattle use cases

Hi Junichi-san!

I have one remark - application developers that utilize frameworks that does not include a full browser implementation should also be considered. 

For example: Webview in Qt, android.webkit.Webview, etc...


Br
Peter Winzell

-----Original Message-----
From: Junichi Hashimoto [mailto:xju-hashimoto@kddi.com] 
Sent: den 9 oktober 2015 20:26
To: Paul Boyes; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: Re: Requirements from Seattle use cases

Hi,

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?

Regards,
Junichi


On 15/10/8 11:19 , Junichi Hashimoto wrote:
> Hi,
>
> I've updated the worksheet.
> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdb
> koke690MA0kdo/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 Monday, 12 October 2015 07:08:49 UTC