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