5 ms·
Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and
by jameside 10y ago
Hi, I work on Expo (YC S16) and also am a core contributor to React Native.
Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning.
React Native is different from those libraries because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs.
Technically it is possible for a WebView app or a React Native app also to contain code that exposes uncontrolled access to native APIs. This could happen unintentionally; someone using React Native might also use Rollout. But this isn't something specific to or systemic about React Native nor WebViews anyway.
One nice thing about Expo, which uses React Native, is that we don't expose uncontrolled or dynamic access to native APIs and take care of this issue for you if your project is written only in JS. We do a lot of React Native work and are really involved in the community and haven't heard of anyone using Expo or React Native alone having this issue.
- santiagobasulto 10y agoJames, do you know if they're going to go agains the Exponent app per-se?
- jameside 10y agoOh, no, I don't have reason to believe so.
- chj 10y agoHow can you ship an app with access to private APIs? There is a private API usage scanning before you can submit for review.
- 0x0 10y agoThe scanner isn't foolproof. You could fool it if you obfuscate your calls to performSelector well enough, for example if jsonResponseFromYourBackend contains:"runThis" then performSelector:json["runThis"] and make sure you don't send a runThis param while the app is in review. Unfortunately for Apple's app review process, Apple's own objective-C language and runtime has very strong dynamic reflection capabilities.
- joosters 10y agoApple could potentially close any loopholes here by scanning new apps for their API usage, checking for any 'bad' calls, and then writing the remaining discovered calls into a permissions file that is delivered with the app in the store. At runtime, any API calls made by the app are checked against this file; if a new API call is found, then it must have escaped Apple's code scanning logic. The API call can be rejected and logged for Apple to improve their scanner.
- edude03 10y agoThis is a great idea actually. Actually, isn't google already doing this via SELinux? You give the app a manifest of calls it's allowed to make, and if the call isn't in the manifest the call gets rejected?
- AstralStorm 10y agoSELinux is not that strong. It works on kernel syscall boundaries and some parameters thereof, and those aren't particularly fine grained. Service access is governed by a separate Google API, for example. Moreover, any random app cannot enhance SELinux policy of the system.
- leonatan 10y agoThere are many legitimate uses of calling methods and functions using reflection. Expecting to hit all of them in a short review process is comically optimistic for anything but the simplistic of apps. Your suggestion of enforcing this also makes no sense from performance or privacy standpoint.
- Vinnl 10y agoI do wonder why, if they're _really_ fine with that, why they're not fine with browsers with different rendering engines on iOS. Since they're not, I wouldn't have _too much_ faith in other things not being rejected.
- jahewson 10y agoSimple: JIT compilers are banned and so that excludes any modern browser's JavaScript implementation from iOS. But anyone using Apple's JavaScriptCore has nothing to fear.
- kalleboo 10y agoThe rules explicitly forbid any HTML renderer or JS interpreter aside from WebKit, JIT or no JIT. I believe all the popular third party browsers today still use the non-JIT UIWebView rather than WKWebView because the former gives you more control over the request cycle
- Operyl 10y agoExcept, apparently, Chrome https://blog.chromium.org/2016/01/a-faster-more-stable-chrome-on-ios.html?m=1 https://blog.chromium.org/2016/01/a-faster-more-stable-chrom...
- menckenjr 10y agoThis needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much of your business logic you've pushed into the JS layer to enable that "80% code sharing" that makes managers go all tingly you may be exposing all kinds of things - cached access tokens, API keys and whatnot - to anyone who wants to install your app and mine its secrets.
- scarface74 10y agoYou as an end user jailbreaking your own phone is not a "security hole". I'm not aware of any non-tethered jailbreak for iOS 10
- nb777 10y agoI think he's talking about application wide (not user specific) "secrets" in the javascript layer.
- menckenjr 10y agoYes, I am. As for untethered jailbreaks, http://pangu8.com/10.html http://pangu8.com/10.html mentions a few.
- rimantas 10y agoJust using one to potential open many more to other apps.
- davewritescode 10y agoYes it is, jailbreaking bypasses critical security features of your phone. Granted, it's required to run certain kinds of software but there are better ways to run your own code on your phone (like getting your own developer certificate) that preserve the security model.
- woah 10y agoHuh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?
- weego 10y agoRather than a speculating on what really boils down to semantics once ToS is involved maybe someone could actually try submitting an app and reporting back on whether it triggers the same failure?
- jameside 10y agoI haven't heard any reports of Expo developers or React Native developers (who aren't using Rollout or JSPatch) getting this warning.