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

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

#281

Post by Vendan » Wed, Mar 08, 2017, 1:03 PM UTC

carterehsmith wrote: post #152

grey-area wrote: post #131

Earlier quoted context omitted.

This is why you don't build on someone else's platform. Apple/Google/Platform Owner will always do what's right for them, not the customer, and not the developer, for example banning Amazon from selling books in their kindle app, not allowing competing browsers (they recognise the power of the web as a platform), not allowing competing sales mechanisms (where they don't get a cut), and here not allowing developers to…

Try making e.g. a game that is not on someone else's platform. Make a game that is not for PC or XBox or PS or Nintendo or iOS or Android or Facebook or Java or whatever. Count money. Oops, there isn't any. Or, try making a Photoshop clone, CAD software or similar without being on someone else's platform. Oops. "it don't work" :)

You are confusing platforms though. The various app stores are vastly different then how it works on Windows, and PC in general for that matter. I get to choose all the way down to the OS, very few phones get that kind of choice. On top of that, iPhone app store is one of the most controlling out there. Even android allows you to install out of band, and to install other app stores and that kind of thing.

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

#282

Post by mikeash » Wed, Mar 08, 2017, 1:05 PM UTC

leoh wrote: post #62

You can accomplish some crazy stuff with hot code loading: use private APIs, get around privacy restrictions. In theory, there are a lot of guys reasons for Apple to prohibit this.

You can accomplish all of that without loading new code. Apple's private API checks, for example, are easy to get around if you're motivated.

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

#283

Post by w0utert » Wed, Mar 08, 2017, 1:05 PM UTC

mikeash wrote: post #279

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…

Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.

That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc.

I agree that the review process itself does little for security, but surely you don't want to allow applications to pull in unchecked native code over the network, right?

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

#284

Post by mikeash » Wed, Mar 08, 2017, 1:06 PM UTC

w0utert wrote: post #283

mikeash wrote: post #279

Earlier quoted context omitted.

Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.

That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc. I agre…

What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care.

The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.

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

#285

Post by Slartie » Wed, Mar 08, 2017, 1:12 PM UTC

Brotkrumen wrote: post #270

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.

True, but in this case "return to compliance" means "scrapping the company", because its key product depends on the non-compliant behavior and is impossible to implement otherwise.

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

#286

Post by elmigranto » Wed, Mar 08, 2017, 1:18 PM UTC

I'm not an iOS developer, so I'm not sure what's possible, but am wondering about React Native apps (and similar technologies too). Here's a scenario:

- you publish an app that creates collages;

- user gives access to Photos;

- you change your JS to upload all the photos to your server.

Substitute "photos" part to any iOS permission; isn't this security risk? Should it be allowed under current App Store ToS? Also, what's stopping your JS code from downloading binary code and injecting it via some iOS exploit into "native thread"?

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

#287

Post by eddieroger » Wed, Mar 08, 2017, 1:19 PM UTC

Slartie wrote: post #285

Brotkrumen wrote: post #270

Earlier quoted context omitted.

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

True, but in this case "return to compliance" means "scrapping the company", because its key product depends on the non-compliant behavior and is impossible to implement otherwise.

It more meant "don't build a company on shaky ground," which Rollout clearly did. The only reason to be so specific about not breaking the rules is when you know you are breaking the spirit of the rules. The blog post he linked to is a year old - they're lucky to have survived this long.

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

#288

Post by orless » Wed, Mar 08, 2017, 1:19 PM UTC

bigiain wrote: post #241

orless wrote: post #228

Earlier quoted context omitted.

I'm just pointing out that "remote resource ... could easily be hijacked via a MiTM attack" is technically incorrect. The problem is not the remote resource per se, the problem is trusting developers to implement secure loading of resources. Which is a completely different argument.

Depends on who you're expecting the MiTM attack to be executed by. Are _you_ secured against, say, an attacker who works at Verisign and can create a valid cert for api.yourdomain.com? Or an attacker who has a buddy who works at GoDaddy who can subvert your dns records so they can trick LetsEncrypt into issuing a valid cert for api.yourdomain.com? Or an elbonian teenage hacker who's just got your AshleyMaddison asswo…

And all of this is "easily"?

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

#289

Post by johnhattan » Wed, Mar 08, 2017, 1:25 PM UTC

elmigranto wrote: post #286

I'm not an iOS developer, so I'm not sure what's possible, but am wondering about React Native apps (and similar technologies too). Here's a scenario: - you publish an app that creates collages; - user gives access to Photos; - you change your JS to upload all the photos to your server. Substitute "photos" part to any iOS permission; isn't this security risk? Should it be allowed under current App Store ToS? Also, wh…

There's not much to prevent that scenario from happening. There's now a "why" section in one of the app's descriptors where you need to describe what you're doing with the permission. So it's not enough to say "I want access to the photos". It's now "I want access to the photos so that I can put them on the screen and let you draw funny pictures on them."

But there's little to prevent you from lying about it, and there are so many iOS platform technologies out there now (native, PhoneGap, React Native, AIR, Xamarin) that there's probably no way for Apple to see what you're doing in an automated way.

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

#290

Post by marcinzm » Wed, Mar 08, 2017, 1:27 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…

How is this any different from native code? Afaik, you can access the native compiled source code of an app on a jailbroken phone. Sure it's more of a pain to parse through but security through obscurity isn't security.