On mar, 2014-06-17 at 08:59 +0000, Zhang, Xu U wrote: > > > -----Original Message----- > > From: Tomasz Swierczek [mailto:[email protected]] > > Sent: Tuesday, June 17, 2014 2:56 PM > > To: Schaufler, Casey; Zhang, Xu U; Kis, Zoltan > > Cc: [email protected]; [email protected] > > Subject: RE: [Dev] The SAPI proposal > > > > > > > > >> [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. > > > > In all these discussions I feel like the thing we miss is the process tree > > for > > typical Crosswalk application. Who forks() and execs(), who does JavaScript, > > who does rendering and who does calls to external services. > > > [Zhang Xu ] I can introduce the process tree. As you may know, crosswalk > includes three processes: browser/render/extension process. > (1) The browser process is started by systemd service when the device boots > up.
It is per user: one browser process launched per logged user. > (2) When end user try to launch web application by clicking icon from home > screen, launchpad_daemon is notified of this action. > (3) Launchpad_daemon fork a child process "App1 xwalk-launcher" for clicking > application, xwalk-launcher handles IPC with lanchpad and browser process. > (4) "App1 xwalk-launcher" send IPC to browser process to open App1 application > (5) when browser process receive the message to open app1, it will fork a > render process. > (6) Render process send IPC to browser process on render process created > (7) browser process tells xwalk-lancher that render process is created > (8) xwalk-launcher create a new thread for extension. So extension and > xwalk-launcher shares a same process, let's call it "extension process". > > All Javascript is executed in render process, which is responsible for > rendering. For external calls, there are two cases. One is for Tizen device > API such as Bluetooth and the other is for some W3C/HTML5 API such as > Geolocation. > The general flow for Tizen API case is as below: > (1) When Tizen device JS API such as Bluetooth.read() is called, render > process will send IPC to extension process firstly. > (2) When extension process receives the message, extension process will call > SAPI > (3) extension return the result to render process > > The general flow for W3C APIs is as below: > (1) When W3C JS API such as Geolocation.update() is called, render process > will send IPC to browser process firstly. > (2) When browser process receives the message, browser process will call > Cynara > (3) If Cynara allow this request, browser process call Geolocation APIs and > get the result > (4) browser process return the result to render process. > > > Is there any *good* place over internet that we can base our discussions on, > > that you guys (I'm talking mostly to Crosswalk team now) can recommend? > > Only after understanding Web applications in 3.0 (this means crosswalk > > architecture) we can implement worthy security there. > > > > Similar thing is with native - for now, 3.0 doesn't really have native > > defined & > > maintained. SAPI is just a proposal to solve problem that *will* arise - > > but will it > > *really* arise? Before defining what really is the supported native API of > > Tizen > > 3.0 and beyond, discussing SAPI itself will be mostly hypothetical > > (although I'm > > not saying its invaluable). > > > > Maybe the real question we should start from is what is the native, publicly > > exposed API in Tizen 3.0? Or rather in 3.1? > > > > > > BRs, > > > > Tomasz > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
