Apple starts rejecting apps with “hot code push” features • Hacker News Board

Re: Apple starts rejecting apps with “hot code push” features

#261

Post by scarface74 » Wed, Mar 08, 2017, 12:05 PM UTC

menckenjr wrote: post #240

jameside wrote: post #103

Earlier quoted context omitted.

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 t…

This 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 it…

You 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

Re: Apple starts rejecting apps with “hot code push” features

#262

Post by jpetso » Wed, Mar 08, 2017, 12:15 PM UTC

eeeeeeeeeeeee wrote: post #154

adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…

> And ultimately it's their store and their rules.

It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.

Re: Apple starts rejecting apps with “hot code push” features

#263

Post by nb777 » Wed, Mar 08, 2017, 12:17 PM UTC

scarface74 wrote: post #261

menckenjr wrote: post #240

Earlier quoted context omitted.

This 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 it…

You 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

I think he's talking about application wide (not user specific) "secrets" in the javascript layer.

Re: Apple starts rejecting apps with “hot code push” features

#264

Post by Operyl » Wed, Mar 08, 2017, 12:18 PM UTC

akmarinov wrote: post #210

threeseed wrote: post #170

Earlier quoted context omitted.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

Except for the time when Facebook did it (and still does). They use private apis to monitor user activity even while the app isn't running and collect all sorts of data that others don't have access to like wi-fi SSID and device MAC address. But what's Apple going to do - not have Facebook on iOS?

Err, as far as I know collecting the SSID is a public API.

Re: Apple starts rejecting apps with “hot code push” features

#265

Post by wruza » Wed, Mar 08, 2017, 12:21 PM UTC

prabodhprakash wrote: post #237

jameside wrote: post #135

Earlier quoted context omitted.

The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Obje…

"You write regular Objective-C methods that are callable from JavaScript," - the objC function that I am calling from JS can be capable of calling a private API received by it in an argument - that breaks the entire claim of reactNative not supporting calls to private API. React Native must also go down.

See the difference between a regular human who in theory can take a knife and violently rob or kill someone, and human-like robot that can be easily programmed to do the same. Who has to be isolated?

It is all about intents. If app allows that, it is banned for that behavior, not for having React in his kitchen. But if you have armed drone there, then police has a question.

Re: Apple starts rejecting apps with “hot code push” features

#266

Post by weego » Wed, Mar 08, 2017, 12:23 PM UTC

jameside wrote: post #103

dilipray wrote: post #76

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo. Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute nativ…

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 t…

Rather 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?

Re: Apple starts rejecting apps with “hot code push” features

#267

Post by menckenjr » Wed, Mar 08, 2017, 12:27 PM UTC

nb777 wrote: post #263

scarface74 wrote: post #261

Earlier quoted context omitted.

You 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

I think he's talking about application wide (not user specific) "secrets" in the javascript layer.

Yes, I am. As for untethered jailbreaks, http://pangu8.com/10.html mentions a few.

Re: Apple starts rejecting apps with “hot code push” features

#268

Post by johndoe4589 » Wed, Mar 08, 2017, 12:28 PM UTC

jpetso wrote: post #262

eeeeeeeeeeeee wrote: post #154

Earlier quoted context omitted.

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…

> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.

Yeah, so we can have one store with strict policies that protect users and the value of the hardware; and a bunch of other shit stores that offer apps that can hijack our devices. That makes sense!

And then Apple is to blame, and can spend tons of dollahs and man hours to fix problems caused by your "open" alternatives.

Re: Apple starts rejecting apps with “hot code push” features

#269

Post by wolfgke » Wed, Mar 08, 2017, 12:28 PM UTC

abcd_f wrote: post #151

macspoofing wrote: post #144

Earlier quoted context omitted.

Oh man. You were surprised? Really? You blog sounds like the PR spin that came out of Aereo, a company that spent an inordinate amount of effort to stay within the absolute letter of a law. Predictably they got killed by lawsuits because judges aren't idiots and the law isn't inflexible to the point where the intent and context isn't considered. Your case is even worse because you engineered a solution to adhere to t…

> 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.

What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-controlled) server if one does not want to get into a self-contradiction.

Re: Apple starts rejecting apps with “hot code push” features

#270

Post by Brotkrumen » Wed, Mar 08, 2017, 12:29 PM UTC

adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

"We are in full compliance. Everything is fine. The house is not on fire. The heat you are feeling is coincidential."

Man, do I dislike marketing speak. A "We knew we were non-compliant, but think the security benefits of quick bugfixes outweigh the disadvantages. We will work with apple to return to compliance." would've been honest, better and not bs.