> -----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. (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
