RE: Requirements from Seattle use cases

Hi Ansari!

I think that work on QtWebengine is ongoing and not at all set yet. Why we always depends on qt company? What do you mean ? Who is depending on the Qt company ? It is just one possible implementation. However, since Qt is preferred (currently) by several OEMS as a general application framework it is of great interest to follow and possibly take part of their implementation. (Also As I mentioned briefly they will probably provide this API through their QML layer as well which will indeed address performance)

 Br
Peter Winzell

-----Original Message-----
From: Ansari, Asadullah [mailto:Asadullah.Ansari@harman.com] 
Sent: den 23 oktober 2015 13:18
To: Peter Winzell; Junichi Hashimoto; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: RE: Requirements from Seattle use cases

Thanks for reply. One more question --  qtwebengine is api layer (like webview in webkit )over content layer of chromium/ blink but blink supports asynchronous apis but qtwebengine provides synchronous api which again some performance so my question is Why we are not using cef ( chromium embedded framework) instead qtwebengine? Why we always depends on qt company? Is any particular requirement for qtwebengine ?

BR
Asad


________________________________________
From: Peter Winzell [Peter.Winzell@melcogot.com]
Sent: Friday, October 23, 2015 4:30 PM
To: Ansari, Asadullah; Junichi Hashimoto; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: RE: Requirements from Seattle use cases

No same...and Digia is not the name of the Company anymore , they have  changed their name to The Qt Company.  http://www.qt.io/about-us/

Br
Peter Winzell

-----Original Message-----
From: Ansari, Asadullah [mailto:Asadullah.Ansari@harman.com]
Sent: den 23 oktober 2015 12:49
To: Peter Winzell; Junichi Hashimoto; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: RE: Requirements from Seattle use cases

Dear All
Are you mentioned webengine(blink based) different than qtwebengine( blink based - provided by digia) ?

BR
asad
________________________________________
From: Peter Winzell [Peter.Winzell@melcogot.com]
Sent: Friday, October 23, 2015 2:50 PM
To: Peter Winzell; Junichi Hashimoto; public-automotive; public-autowebplatform@w3.org; public-auto-privacy-security@w3.org
Subject: 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 11:25:33 UTC