> -----Original Message----- > From: Zhang, Xu U > Sent: Monday, June 16, 2014 7:04 PM > To: Kis, Zoltan; Schaufler, Casey > Cc: [email protected]; [email protected] > Subject: RE: [Dev] The SAPI proposal > > > > > -----Original Message----- > > From: Dev [mailto:[email protected]] On Behalf Of Kis, Zoltan > > Sent: Tuesday, June 17, 2014 3:27 AM > > To: Schaufler, Casey > > Cc: [email protected]; [email protected] > > Subject: Re: [Dev] The SAPI proposal > > > > On Mon, Jun 16, 2014 at 8:25 PM, Schaufler, Casey > > <[email protected]> wrote: > > >> -----Original Message----- > > >> From: Patrick Ohly [mailto:[email protected]] > > >> Sent: Monday, June 16, 2014 10:03 AM > > >> To: Schaufler, Casey > > >> Cc: José Bollo; Kis, Zoltan; [email protected]; > > >> [email protected] > > >> Subject: Re: [Dev] The SAPI proposal > > >> > > >> On Mon, 2014-06-16 at 16:31 +0000, Schaufler, Casey wrote: > > >> > > But how do you propose to handle extensions implemented in the > > >> > > extensions process? So, which Smack label shall that process > > >> > > have, and shall it call Cynara itself instead of relying on the > > >> > > system to > do > > that? > > >> > > > >> > The extensions process is the manifestation of the application and > > >> > is served only by the render and browser processes. An extension > > >> > that tries to communicate with a service provider other than the > > >> > browser will be blocked by Smack. > > >> > > >> Extensions will not be allowed to use system services at all? I know > > >> of at least one specific example where that is not going to be > > >> sufficient (Automotive Message Broker) and I'm pretty sure there are > more. > > > > > > AMB is a service, not an application. > > > > > > > Patrick meant that there is an xwalk extension, which would like to use > AMB. > > Other extensions need to use Bluetooth DBUS API's (or the new BT > framework), > > others oFono DBUS API's on the system bus (or corresponding SAPI), etc. > > > > There are browser-internal extensions for which your idea works, but > there are > > also external extensions, like the ones above, for which it doesn't (if I > > understand right) - and that is what Patrick has brought up. > > > > I was also wondering why an extension process could not be trusted, once > it is > > a separate process from the renderer and browser, and a web app cannot > > break into it. The best answer I could come up was that 3rd parties can also > > implement and deploy extensions and not only web apps, therefore > extensions > > are not trusted in general, and their instances are considered part of the > > applications, i.e. they are treated like native apps.
> [Zhang Xu ] Yes, extension is not trusted. The third party can implement their > extensions. In crosswalk original API permission design, which has been > dropped because Cynara security framework proposed, extension must > send an IPC to browser process to do permission check before extension talk > to service. You can't trust the extension to send a message to the browser process any more than you can trust it to send a message to Cynara. I was under the impression that ALL communications for services went through the browser process. If you have untrusted application processes talking directly to services we have a very different situation. > > > > However, it would be desirable both for native apps and web runtime > > extensions to be able to access DBUS objects/interfaces/signals etc, > otherwise > > we need to implement all functionality accessible on DBUS (together with > all > > asynchronous idioms) as SAPI, basically doubling our middleware size and > > latency. (Of course, non-DBUS API's would use the corresponding SAPI > anyway). > > > > Best regards, > > Zoltan > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
