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

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

#351

Post by orbitur » Wed, Mar 08, 2017, 4:12 PM UTC

mikeash wrote: post #347

orbitur wrote: post #345

Earlier quoted context omitted.

If they're using JSC, then they can definitely download JS and execute native methods. They could subclass any UIKit object and make it conform to JSExport. Done, now they're "running native code."

Sure, and an app displaying a web page using WebView can provide hooks that allow doing that sort of thing too. Neither one is downloading native code.

Only UIWebView, which is going away soon.

But surely you can see the difference between executing limited actions inside a web view, and making available any native method to a web view.

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

#352

Post by ballenf » Wed, Mar 08, 2017, 4:16 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.

don't forget to change their lines about "hundreds of apps use our system and none have ever been rejected by Apple"

to: "we've been getting away with it for a long time, so there's that"

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

#353

Post by mikeash » Wed, Mar 08, 2017, 4:18 PM UTC

orbitur wrote: post #351

mikeash wrote: post #347

Earlier quoted context omitted.

Sure, and an app displaying a web page using WebView can provide hooks that allow doing that sort of thing too. Neither one is downloading native code.

Only UIWebView, which is going away soon. But surely you can see the difference between executing limited actions inside a web view, and making available any native method to a web view.

WKWebView allows the app to execute arbitrary JS within the loaded page, and intercept URL loads and other actions made by JS code. That's all you need to build a bridge.

I don't see any fundamental difference here. Both (UI|WK)WebView and JSC allow bridging. Neither one grants full access to JS code automatically, the programmer has to put some effort into it. And even if there is some important difference, neither one is native code which is what I was disputing above.

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

#354

Post by mikewhy » Wed, Mar 08, 2017, 4:27 PM UTC

menckenjr wrote: post #303

woah wrote: post #277

Earlier quoted context omitted.

Huh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?

Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but... http://www.wikihow.com/Bypass-iPhone-Passcode

"This bypass won't work on iPhones running iOS 9.3 and up"

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

#355

Post by [deleted] » Wed, Mar 08, 2017, 4:28 PM UTC

tdhz77 wrote: post #348

unethical_ban wrote: post #325

Earlier quoted context omitted.

Then the letter of the law means nothing.

The law is a living breathing organic document. Anybody who says otherwise is living in 1776 with slaves.

[deleted]

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

#356

Post by ksk » Wed, Mar 08, 2017, 4:30 PM UTC

I'd say this is only going to further the arms race. One simple way around this would be to intentionally introduce a bug with a "controlled" exploit that lets you send a specially crafted data packet to your app, and execute shell-code of your choice.

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

#357

Post by edude03 » Wed, Mar 08, 2017, 4:32 PM UTC

joosters wrote: post #321

0x0 wrote: post #163

Earlier quoted context omitted.

The scanner isn't foolproof. You could fool it if you obfuscate your calls to performSelector well enough, for example if jsonResponseFromYourBackend contains:"runThis" then performSelector:json["runThis"] and make sure you don't send a runThis param while the app is in review. Unfortunately for Apple's app review process, Apple's own objective-C language and runtime has very strong dynamic reflection capabilities.

Apple could potentially close any loopholes here by scanning new apps for their API usage, checking for any 'bad' calls, and then writing the remaining discovered calls into a permissions file that is delivered with the app in the store. At runtime, any API calls made by the app are checked against this file; if a new API call is found, then it must have escaped Apple's code scanning logic. The API call can be reject…

This is a great idea actually. Actually, isn't google already doing this via SELinux? You give the app a manifest of calls it's allowed to make, and if the call isn't in the manifest the call gets rejected?

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

#358

Post by maverick_iceman » Wed, Mar 08, 2017, 4:41 PM UTC

stinkytaco wrote: post #312

libertymcateer wrote: post #308

Earlier quoted context omitted.

> 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. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

Justice Clarence Thomas wouldn't agree with you.

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

#359

Post by throwaway729 » Wed, Mar 08, 2017, 4:42 PM UTC

ballenf wrote: post #336

AdmiralAsshat wrote: post #315

Earlier quoted context omitted.

f.lux strikes me as a good example. f.lux came to the market first with its idea to control screen temperature. Apple decides "No, you're not allowed to do that...but that's a great idea!", kicks f.lux out of the app store, and then adds their own Night Mode into later versions of iOS, using API's only they are allowed to access.

I love f.lux and have a soft spot for the very nice developer couple behind the app. That being said, it's hard to argue that Apple (or Android) shouldn't be able to set boundaries on behaviors which are only allowed to be done by the OS as a opposed to an app. Apple's tight control of device screen characteristics makes it pretty understandable that they don't want one app able to control how another app looks on th…

> It's hard to argue that Apple (or Android) shouldn't be able to set boundaries on behaviors which are only allowed to be done by the OS as a opposed to an app

It's really not. The argument for user freedoms is almost as old as software.

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

#360

Post by justinzollars » Wed, Mar 08, 2017, 4:44 PM UTC

The Unfree web.