Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

Post reply on HN
Print view View original

221–230 of 498 posts

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

#221

Post by manmal »

homakov wrote: post #187
manmal wrote: post #142

Earlier quoted context omitted.

No, it allows apps to be modified by the apps pulling JS code from rollout's servers. App reviews would be way too slow, and they are exactly the problem that rollout solves. However, review times have improved a lot since then. ADDITION: It works by "swizzling" methods, which is a valid mechanism in Apple's runtimes (like in Ruby or many other dynamic languages). In Swift, this will only work in subclasses of NSObje…

Ok, so there's no direct access to your App Store but idea is same - rollout can "hot fix" aka pwn all users at once. I'd be angry if I were apple too.

Indeed, I always wondered how Rollout would not same day be rejected by Apple.

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

#222

Post by runholm »

ChrisMorrisOrg wrote: post #134
diminish wrote: post #129

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?

I strongly doubt Apple would ever ban web browsers. The amount browsing done on iOS is too significant, it wouldn't make sense to ban them.

OP proposed a world in which the web starts now, so there is no browsing being done on iOS in this scenario.

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

#223

Post by kalleboo »

jahewson wrote: post #186
Vinnl wrote: post #172

Earlier quoted context omitted.

I do wonder why, if they're _really_ fine with that, why they're not fine with browsers with different rendering engines on iOS. Since they're not, I wouldn't have _too much_ faith in other things not being rejected.

Simple: JIT compilers are banned and so that excludes any modern browser's JavaScript implementation from iOS. But anyone using Apple's JavaScriptCore has nothing to fear.

The rules explicitly forbid any HTML renderer or JS interpreter aside from WebKit, JIT or no JIT. I believe all the popular third party browsers today still use the non-JIT UIWebView rather than WKWebView because the former gives you more control over the request cycle

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

#224

Post by tomasf »

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?

CNCopyCurrentNetworkInfo gives any app network info, including the SSID.

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

#225

Post by orless »

scintill76 wrote: post #215
orless wrote: post #191

Earlier quoted context omitted.

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps? I'm…

You see, this whole thing:

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

Basically says "only we, Apple, can do HTTPS right, you can't, and even if you try you can easily be MiTMed". Which is I don't agree with.

What you say is correct, but it's not the argument I criticize. You point is that they don't trust developers to implement secure loading of code and don't have technical means to control it and can't or don't want to check it in the review. But it's completely different to "you could be easily hijacked if you're not Apple".

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

#226

Post by teknologist »

orless wrote: post #225
scintill76 wrote: post #215

Earlier quoted context omitted.

HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps? I'm…

You see, this whole thing: "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." Basically says "only we, Apple, can do HTTPS right, you can't, and even if you try you can easily be MiTMed". Which is I don't agree with. What you say is correct, but it's not the argument I cr…

I'd trust Apple to do right more than I'd trust a small team at a startup trying to deliver features at breakneck speed. I really like the fact that Apple is looking out for its customers here.

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

#227

Post by madeofpalk »

seanclayton wrote: post #55
madeofpalk wrote: post #35

Earlier quoted context omitted.

..."provided that such scripts and code do not change the primary purpose of the Application"

So you can add features all you want, just make sure you don't change your todo list app to a dating app and all is fine.

Once you've 'worked' with Apple's app review for long enough you'll learn that you can't rely on such an assumption.

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

#228

Post by orless »

teknologist wrote: post #205
orless wrote: post #191

Earlier quoted context omitted.

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

In an ideal world where apps check/pin certificates and don't disable cert checks to make self-signed certs work in test environments you'd be right. If only this were reality.

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.

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

#229

Post by emdowling »

DaiPlusPlus wrote: post #188
huhtenberg wrote: post #168

Earlier quoted context omitted.

You are thinking "source code". "Code" is another term for what you are referring to as "binary".

Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of p…

I really don't think Apple, with it's war chest, is actively disassembling code to steal it. As has been demonstrated time and time again, they will just buy companies that have awesome tech and IP. Far easier.
Post reply on HN