> -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Tuesday, June 17, 2014 4:48 PM > To: Tomasz Swierczek > Cc: Schaufler, Casey; Zhang, Xu U; Kis, Zoltan; [email protected]; > [email protected] > Subject: Re: [Dev] The SAPI proposal > > On Tue, 2014-06-17 at 08:55 +0200, Tomasz Swierczek wrote: > > > > >> [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? > > I'm not in the Crosswalk team, so let me point to Sakari's post instead: > https://www.mail-archive.com/[email protected]/msg02734.html > > Also see my follow-up questions about the exact role of the extension process. > > The takeaway from that mail thread was that the EP a) looks like a potentially > less privileged app process to the rest of the system and b) needs to talk to > system services to implement some of the Web APIs. > > So coming back to the question of SAPI: my opinion is that Crosswalk does not > depend on SAPI specifically. But we *do* need a way to expose at least some > system services and resources securely to Crosswalk. > Whether that is via SAPI, Cynara checks in the services and/or dbus-daemon > (for services accessed via D-Bus) is what we need to decide. > > This is the same as running native apps securely. > > > 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? > > For native apps, this is hard to answer. I'm with Casey here, we should focus > on > web apps first, in which case the question becomes: which services and system > resources does Crosswalk need to access from the extension process to > implement the Web APIs? [Zhang Xu ] There are dozens of Tizen device APIs. As far as I know, extension process usually need related device service to implement Tizen device APIs. For example, in order to implement BT APIs, extension process need access BT service and resources. For Tizen device APIs, you can find from https://developer.tizen.org/documentation/dev-guide/2.2.1?redirect=https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.device.apireference/index.html. > > We need a default deny for everything and then open up access to these > services and resources selectively after ensuring that access controls are in > place. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although I am an > employee of Intel, the statements I make here in no way represent Intel's > position on the issue, nor am I authorized to speak on behalf of Intel on this > matter. > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
