On Wed, May 14, 2014 at 3:50 PM, Lukasz Wojciechowski
<l.wojciechow at partner.samsung.com> wrote:
>> W dniu 2014-05-14 07:43, Zhang, Xu U pisze:
>>>>>> -----Original Message-----
>>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
>>> Sent: Tuesday, May 13, 2014 10:29 PM
>>> To: José Bollo
>>> Cc: dev at lists.tizen.org>>> Subject: Re: [Dev] enforcing priviliges of web apps
>>>>>> On Tue, 2014-05-13 at 16:09 +0200, José Bollo wrote:
>>>>>>>> On mar, 2014-05-13 at 15:59 +0200, Rafał Krypa wrote:
>>>>>>>>>> On 2014-05-13 14:29, Patrick Ohly wrote:
>>>>>>>>>>>> On Tue, 2014-05-13 at 11:13 +0000, Counihan, Tom wrote:
>>>>>>>>>>>>>> I will end up with a total count of 1 browser process and 4
>>>>>>> other processes (2x extension & renderer) = 5 processes?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is this correct?
>>>>>>>>>>>> And to extend the question, which process will be the one talking
>>>>>> to the rest of the system services?
>>>>>> [...]
>>>>>>> I agree with you. There is a problem. Is was thinking that the W3C API
>>>> was handled at the renderer process level. Having it common to all
>>>> apps is a problem for the reasons you written.
>>>>>> Note that my question about "which process talks to services" (or, in a
>>> similar
>>> vain, accesses files) has not been answered yet. It might still be the
>>> per-app
>>> render process which does it.
>>>> [Zhang Xu ] Tizen extension APIs will be implemented in extension process.
>> So extension process in crosswalk will talk to service.
>> For W3C APIs, it is up to how system implements W3C API module. For W3C
>> APIs other than Tizen extension APIs in crosswalk, the process which
>> implements the module follows the design of chromium. In chromium, the
>> render process will send IPC message to browser process firstly. And browser
>> process will talk to the service to get the result. Then browser process
>> will transfer the result to render process.
That is for internal extensions.
Tizen API's (and W3C API implementations in Tizen) are external
extensions to crosswalk.
>> If we follow such design all calls to services will be made by browser
> process and not by application process. It means that services won't be able
> to provide application granularity access control because all calls will be
> made with SMACK label of browser.
> It is a problem.
Except if the browser / extension process become security enforcement
points, doing the runtime checks. Since they are different processes
than the the one running the app, they could load a library
implementing the runtime security checks and enforce permission. Of
course then the platform becomes as secure as the browser... but
Chromium security is rather high.
Best regards,
Zoltan