> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Schaufler, > Casey > Sent: Monday, June 16, 2014 5:02 PM > To: Kis, Zoltan > Cc: [email protected]; [email protected] > Subject: Re: [Dev] The SAPI proposal > > > -----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.
So, I've just had additional conversations about Crosswalk that lead me to believe my prior understanding of Crosswalk is incorrect. I need to sort out with understanding is right before taking this any further. > > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
