RE: Requirements from Seattle use cases

No, I think cookies are well covered. Actually my remark was only to point out that using WebView is not the same as using a browser. 

Br
Peter Winzell

-----Original Message-----
From: Junichi Hashimoto [mailto:xju-hashimoto@kddi.com] 
Sent: den 14 oktober 2015 07:51
To: Peter Winzell; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: Re: Requirements from Seattle use cases

Peter-san,

Thank you for your remark. I understand the situation but cannot clearly imagine issues which is originated by the lack of implementation. You might point that webview, for instance, doesn't provide a way for clearing cookies. Could you show me some example?

Junichi

On 15/10/12 16:01 , Peter Winzell wrote:
> 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_muCmUayVqmVfd
>> b
>> 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 Wednesday, 14 October 2015 06:42:52 UTC