An Open Letter to Apple from Rollout.io – Proposing a SECURE JavaScript Injection Approval Process

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 Rollout and Microsoft’s CodePush were created. Both allow app developers to push bug fixes or minor modifications to end users immediately. Rollout 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 Rollout 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 Rollout 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.

Click for Detail

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 Rollout, 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 Rollout 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 Rollout.io

Eyal Keren

When Eyal was six years old, he started copying English letters from the BASIC book he found in the IBM XT box his parents purchased. Debugging those programs was hard because he didn't know what GOTO means in English. He is a fast eater, a movie buff and doesn't like ketchup. Today Eyal focuses on software craftsmanship, continuous design and TDD. He loves to write code, but even more... he loves deleting it.

Coming soon - A Continuous Feature Release Solution

Rollout’s totally new product, a Continuous Feature Release System, lets your mobile dev team build apps at the speed your business needs, without compromising on safety. Decouple feature deployment from version releases. Decide who gets which feature and when, measure impact and respond in real-time. All without waiting for your next release. Sign up for early access
  • Matthaus Woolard

    This is an interesting suggestion i’m not sure why the need for apple to strip the other cificate. Surely it would be better to use a certificate chain for this.

    1) Developer sigs with their normal signature or a dedicated one (but make the dedicated one contain a reference to the main developer signature so that this can be checked on the app by the developer)
    2) Code is pushed out to apple for auto review
    3) Apple counter sign the code+developer signature
    4) Developr upload code/and all signatures to update service

    on device
    1) framework/kernel checks when loading js that it is signed by apple and signed by the developers key
    2) developer can optionally add checks themselves as well to ensure that their signature is in place and good

    By keeping the developer’s signature attached you also keep a history with timestamps etc, this has some nice benefits such as if a developer’s root certificate is revoked then all the live updates (even those already signed by apple) can be revoked.

    Longterm I think a better solution than injecting JS would be for apple to let us push signed code analysed swift code down the pipe. Since swift is a Type safe language this would let the code checking ensure that it will not produce any clear errors and will also make things easier for developers to merge these fixes into their app properly down the road, I am a little worried about users patching in js since it does not make it easier for them to fix the bug properly down the road, a system of hot loading signed swift binaries (compiled on apple’s servers) would be the best option for both app users and developers.

  • Derek Hoolsley

    I think you need to step back and see this from Apple’s point of view. What you’re suggesting is simply a method of allowing rollout.io continue as it was before. If Apple decide to allow automatic-review-only patching, it isn’t going to involve monkey patching javascript into native methods. The only reason that method was being used to begin with is because Apple don’t allow automatic-review-only patching.

  • Rollout.io

    Derek,
    Point understood, keep in mind that the suggested concept is not only to secure patching solutions like Rollout, but also to secure other hybrid platform or just any remote JS code that is being loaded, Apple has not blocked React Native + CodePush/AppHub, but they potentially have the same MiTM attack vulnerability, moreover many devs use JS in their App around places which are sensitive (and they need the flexibility of changing them w/o version release), in many cases they load new JS assets dynamically w/o Apple’s approval…

  • Eyal Keren

    Hi Matthaus,

    Certificate chain is indeed a good idea, thanks!

    In general, we can choose to inject Javascript (for react-native and cordova) ,or for native apps, any other format in the chain from source code to Binary (swift src -> SIL -> LLVM IR -> .a file) it really depends on the nature how the binary was packed in the first place, and what are the hooks of the system that can be replace. (one example can be dynamic loading of components)

    In Rollout we are replacing code in the granularity of a method, you can replace a single method of a class in objective-c and swift.

    Thanks again for your insights