> -----Original Message----- > From: Kis, Zoltan [mailto:[email protected]] > Sent: Monday, June 16, 2014 12:27 PM > To: Schaufler, Casey > Cc: Ohly, Patrick; José Bollo; [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.
AMB isn't going to need help from SAPI. We have full control over the version of AMB we're using in Tizen. It is completely reasonable to change AMB to use Cynara. Services that use dbus don't require SAPI. They require dbus configuration. > 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 assert that the examples presented are completely addressable. > 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. My understanding of the *intent* of Crosswalk is that only the browser communicates outside of the browser/render/extension trilogy. The browser is the trusted bit. > 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). The only reason that Crosswalk makes any sense at all is if the downloaded (99.44% probability of being malicious) program is prohibited from contacting system services directly. There is absolutely no reason for the separation into multiple processes if you're not doing isolation. > Best regards, > Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
