191–200 of 498 posts
It seems that most people are overlooking one of the more significant points Apple have made here: "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." Source: https://github.com/bang590/JSPatch/issues/746
Earlier quoted context omitted.
> Oh man. You were surprised? Really? Exactly! Apple has always been adamant that they see _all_ code that goes onto devices. Live patching is so bloody obvious against their EULA.
They don't 'see' the code. They run a program on the binary for some obvious checks and do a QA smoke test of the app itself.
If you use hot code push together with React Native, then you're borked.
Just imagine www didn't exist and Apple already had ios and apps. If someone came up with the idea of www and an app called web browser , would apple accept it in the app store? They would only accept it if they build it themselves. At some point is there a risk that Apple may also start to ban the web browser, despite that it's under strict control on IOS?
It would be possible to build a browser without JavaScript though.
Earlier quoted context omitted.
Most likely most games are updating only game related data and graphics files. Very few games actually use internal scripting that would be needed to do code updates
The only app I've got that appears to actually update itself without going through the AppStore is the HSBC mobile banking app. I'd be interested in hearing the discussions going on between Apple and HSBC at the moment.
I.e. it downloads a bunch of javascript/html/css and that executes within a UIWebView/WKWebView. Using caching and localStorage, you can construct such an app to not need to download everything on each launch.
The reason that's allowed is because everything executes within a sandboxed browser environment. No native code is downloaded.
Earlier quoted context omitted.
> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary t…
Nothing guarantees that. There have been RCE exploits on iOS. One could argue that live patching allowed companies to fix or mitigate security problems faster than Apples (awful) app store policy (and timescale) would otherwise allow.
Yet, we can say that code review by a third party is better for trust of that code, than no code review by a third party.
"Nothing guarantees" may have been strong. but "the set of attack vectors and their relative efficacy increases " doesn't roll off the tongue quite as nicely.
Earlier quoted context omitted.
You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.
An objc swizzle is not native code injection, it's a function pointer swap. They swizzle the method to their general objc message handler which then executes a piece of javascript code. For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead. No binary code being injected.
A number of other posts talk explicitly of dynamic delivery of native code. If you're sure, it's a genuine question: I'm interested to know how this works. Function pointer swaps are one thing, but how would this allow you to patch bugs in the app? I can see how this could let you change the app's behaviour, even including calling private API's, but surely this would be constrained to calling pre-existing behaviour?
Or by adding new behaviour is this to mean new javascript behaviour.
Earlier quoted context omitted.
Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.
They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?
Understandable, but there is a deeper problem of course - the app store model is broken for apps that need hotfix capabilities (aka enterprise). We've been meeting with Apple on this topic for years and continue to sideload our app as we need to meet SLAs with our customers. They sign the binaries with their dev certificates, which violates Apple's guidelines too. But, alas, once you have critical mass in a vertical…
In this case it isn't required at all though because Apple allows enterprise to sideload apps outside of the review process.
Earlier quoted context omitted.
What does Uber do?
They run an illegal taxi service. There's an app for it too.
However, due to their miserable practices I am glad that almost all (if not all) drivers for Uber also drive for the local taxi-in-an-app service.