An Open Letter to Apple from - Proposing a SECURE JavaScript Injection Approval Process

Written by: Eyal Keren

Dear Apple, Call it what you want - code pushing, hot patching - but the concept is the same: a framework that allows apps to be updated by developers AFTER download. I think we can agree the goal is sound - reduce bugs and crashes. But is this concept - let’s call it a “Live Update Service” safe? If not, can it be made safe? We have a proposal for you. Please hear us out! How we got to this point Historically, delivering a bug fix to iOS end users has required pushing a new version of that app through the App Store approval process. While to your credit, Apple has greatly reduced the time this takes, every minute can be crucial when critical bugs or vulnerabilities need to be addressed. Even 24 hours can be too long to wait. Buggy apps hurt everyone - app developers and end users alike. This is why Live Update Services such as CloudBees Feature Management and Microsoft’s CodePush were created. Both allow app developers to push bug fixes or minor modifications to end users immediately. CloudBees Feature Management works with Obj-C / Swift apps and CodePush works with Cordova and React Native apps. (In fact, this can be done without these frameworks - many apps are doing this by themselves by injecting javaScript into their app on areas where logic needs to change - for example, parsing external resources that might be subject to change.) Today, thousands of apps used by billions of people, including some of the most popular apps available, rely on Live Update Services to ensure bugs are squashed and vulnerabilities are closed within minutes of their discovery. This has been the status quo for several years. A new chapter begins Last week you began contacting developers, warning them that any framework or “code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval” is no longer in compliance with its guidelines. Here is the full email and our initial response. Your letter stated: “Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.” We believe you have a point! Developers need a way to quickly update their apps to fix bugs and close vulnerabilities - without exposing end-users to additional security risks.  And end-users want apps they can trust. You have been doing a commendable job of ensuring iOS users are provided with a safe, secure and private user experience. Before an app can be downloaded from the App Store and run, it goes through an extremely secure process of signatures and security checks, which you control. While CloudBees Feature Management and others have protocols in place to prevent MiTM attacks, the fact remains: you cannot ensure the same level of security for solutions that bypass the App Store and directly modify live apps. That is why we are proposing the following solution for all apps that load JS at runtime, which meets the need of developers to fix issues instantly, while also providing security that is controlled and set by Apple. We at CloudBees Feature Management believe this solution will address your concerns. We sincerely hope it will be adopted by Apple, SDK companies, and app developers.

The Solution is Simple

Just as full releases require a distribution certificate, developers will obtain a “Live Update Service Certificate” from Apple. Just as Apple signs .ipa files, which are pushed to the App Store and then downloaded to end user devices, we propose Apple begin to sign Javascript code, which is returned to the developer, who can then push it directly to live devices. The Apple SDK would verify the signature authenticity and only execute verified code. Flow:

  1. A developer obtains a “Live Update Service Certificate” from Apple.

  2. The developer creates the Javascript code which will be pushed through a Live Update Service.

  3. The JavaScript code is then moved into pending Apple Approval

  4. The developer signs the Javascript code with their own “Live Update Service Certificate” stored on their Mac.

  5. The Javascript code and signature are sent to Apple for an automatic process of code re-signing.

    1. Apple verifies the code was signed with a valid certificate

    2. Apple examines the code with its code analyzer and approves it..

    3. Apple strips the existing certificate and re-signs the code with Apple’s own certificate.

    4. The newly signed code is sent back to the developer. All these steps can and should be done without human intervention

  6. The developer sends Apple’s signature to the Live Update Service.

  7. The Live Update Service sends the both the code and signature to live devices.

  8. The Live Update Service SDK loads the code sent from the remote resource and provides the signature to Apple’s designated API (part of JavascriptCore Framework)

  9. iOS framework authenticates that the code was indeed signed by Apple using their public key.

The Benefits are Clear

  • Developers gain ability to use in-house solutions to inject Javascript into their app

  • Developers able to use third party vendors like CloudBees Feature Management, Microsoft CodePush and others to fix production issues in real time.

  • Apple gains ability to to enable/disable a developer from injecting a specific Javascript patch into their app.

  • Apple or the developer can revoke the “Live Update Service Certificate” at any time.

  • Apple can examine and analyze all JS code that is pushed (just as in the full app version approval process) and reject it if needed.

  • The entire flow is automatic and fast - after all, if it wasn’t, it would defeat the purpose!

We are realistic. We don’t expect you to implement a solution like this immediately. However, we do urge you to consider the benefits of this approach. We at CloudBees Feature Management are committed to partnering with you and with developers to deliver a safe, bug free experience to all. Thank you! Eyal Keren Co-founder and CTO of CloudBees Feature

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.