4 ms·
You are correct that Capacitor plugin API entry points are in the same thread as your web/UI code (which will run in a separate process from your native plugin
by yesimahuman 5y ago
You are correct that Capacitor plugin API entry points are in the same thread as your web/UI code (which will run in a separate process from your native plugin code given WKWebView sandboxes your app in a separate process. They communicate through message passing only). I don’t think it’s directly comparable to Electron for a few reasons. What Capacitor is doing is more like adding new Web APIs to the browser. You have full control over which of those APIs are exposed and they are all backed by the native sandboxing and permission model available on each platform. Additionally you are almost always only loading trusted local content. Electron exposing node runtime to untrusted remote content running in unsandboxed win32 apps, for example, is a pretty different beast. We do take security seriously though and would be happy to review or consider how we can enable users to lock down their apps even more.
- sroussey 5y agoElectron apps, like Capacitor app, are trusted content. This is a red herring. However, both can have a bug that exposes XSS and give direct access to all the nice APIs both add. For example, adding a SQLite plugin gives the attacker full access to all local db data for the app. Or node APIs vs FileSystem APIs. The solution to have have two threads and let the dev specify their own API to communicate. Electron had bad solutions for a while but it’s gotten better these days and might offer some ideas I’m a fan of your work improving the stalled Apache product and moving it forward as Capacitor. I use it! v2 though, as I haven’t upgraded to v3. Maybe I’ll try that this weekend.
- yesimahuman 5y agoAppreciate the feedback and insights! Definitely more we can do there and will see about incorporating more of their techniques