Hacker News new | ask | show | jobs
by saddlerustle 1360 days ago
Notably on iOS there's no good way to isolate unsafe native libraries from the rest of your app without violating app store policies, because Apple enforces apps to be single process and doesn't allow use of its own sandboxing apis.
4 comments

You have to understand, they enforce those rules for security reasons. /s
I believe you’re able to use XPC Services to achieve that no?

Edit: actually no, XPC Services are Mac only so wouldn’t help on iOS.

WASI would be the closest thing to a secure runtime

You can compile your less trusted libraries to webassembly and then run them in a webview?
That sounds like a huge hit to energy use, if it is even feasible for something like implementing webrtc because of communication costs with the native process.
Hrm. If you had a specific WASM engine embedded in the app, you might be able to get it to precompile the bytecode (to avoid violating the runtime modification policy); that might be low-enough overhead (since you also control the communications layer & could make it cheaper).
Video decoder in bytecode?
When most code is Objective-C it hardly matters anyway.
Plenty of mobile code, especially at large companies like this, rely on a ton of C code. It makes it easier to support features on both Android and iOS. I’m sure there are more benefits I’m not aware of.
Benefits that security researchers appreciate as job security.
You only need a bug in a single line of code of your dependency to compromise the whole app. Most of the code doesn’t matter for security.
The usual argument that safer languages are needless, because bugs happen anyway, yet Apple is going Swift, and adopting hardware mitigations to fix these kind of issues.
Hardware mitigations which you can’t use?
I'm pretty sure they're talking about things like PAC, which are are definitely available to apps (and I think even required?).
Not for third party apps, the ABI is not stable yet.