RE: Requirements from Seattle use cases

Hi Hashimoto-san!
Thank you for your great input!

I have been talking with the QtC (The Qt company) and their ongoing implementation of WebEngine(blink based) and the extension of a QML variant of the API. 

If I understand you correctly the log(history) should be treated the same way as cookies and the actual application should provide a way to clear that history cookie ? How would  that then be associated with the API specification ?  Recommendation or just as an example on how to clear the history ? I fully agree that this should be handled by the user as you suggest. 

Br
Peter Winzell
-----Original Message-----
From: Peter Winzell [mailto:Peter.Winzell@melcogot.com] 
Sent: den 14 oktober 2015 08:42
To: Junichi Hashimoto; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: 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 Friday, 23 October 2015 09:21:48 UTC