On lun, 2014-06-16 at 22:26 +0300, Kis, Zoltan wrote: > 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.
That is also what I understood. What I can add: there is no AMB API in the Core API but there is a BT API in the Core API. Taking back the case of AMB. It seems that accesses to AMB will be done through DBUS, I dont see other plugins except BT or Websocket client plugins but they aren't useable as such. > 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. I fully agree with you. If extensions exist, they have to be treated as untrusted. Is there a definition of how a package installs crosswalk extension? Maybe Xu U could tell us more on that topic. > 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). I also agree with you but want to recall the fact that SAPI will not always call DBUS, for some services (which?) the call is direct, not through DBUS, as is shown on the discussion page https://wiki.tizen.org/wiki/Talk:Security/Overview#.5B4.5D_Calling_the_service_via_proxy_SAPI_that_checks_the_privileges Best regards. José > Best regards, > Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
