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

431–440 of 498 posts

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

#431

Post by t1amat »

iOSGuy wrote: post #421
jameside wrote: post #398

Earlier quoted context omitted.

Apple has been fine with WebViews in apps since the beginning of the App Store, including WebViews that make calls to native code, like in the Quip app. WKWebView even has APIs for native and web code to communicate. It's OK for a WebView to call out to your native code that saves data to disk, registers for push notifications, plays a sound, and so on. React Native is very much like a WebView except it calls out to…

Well, let's be clear here. I use React Native, and it would take me about 30m to write a bridged React Native method that could execute ObjC code dynamically, including accessing all the private APIs you could want.

It may already exist: https://github.com/wix/react-native-invoke

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

#432

Post by jameside »

menckenjr wrote: post #425
jameside wrote: post #372

Earlier quoted context omitted.

Definitely, running "strings" on a binary is about as easy as finding the JS for a hybrid app (WebViews or React Native). Depending on your experience it could be easier to extract API keys from an IPA than from JS. In either case the root issue is about sending secrets like an unscoped API key to the client. "Client secret" is an oxymoron in this context regardless of the programming language.

You'd have to know a few things first, like (1) the IPA is a ZIP file, (2) the ZIP file is actually of a directory and (3) you can dump the actual code in the JS files (if they're in the bundle directory) much easier than you can look for strings from the binary that might look like an API key. The API key is actually the least of the hazards, since you can hide that in the keychain. Having source code for your busin…

Shipping source code with business logic (assuming the definition of source code includes obfuscated JS) is how the entire web works today! With WASM the code that is shipped will be even further away from the original source code and really not so different from downloading ARM from the App Store or Java/ART bytecode from the Play Store.

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

#433

Post by Hydraulix989 »

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…

I learned this lesson the hard way a long time ago when I built a service that uses ML (I was doing GPU powered ML in 2011) and social graph clustering to recommend "better" Facebook friends to invite in apps that use the FB SDK. They would send our API their users' FB access tokens (only required the default FB user permissions, too, for mutual friends), we'd issue calls to the FB SDK to get their social graph (completely on the issuing app's behalf), crunch it on our GPUs, and send back a sorted list of recommended friends to suggest to invite for improving virality.

Back in 2012, it wasn't prohibited by the ToS at all; we read and re-read the ToS over and over again to make sure so that we wouldn't waste our time building something "illegal."

Once I had the third largest social gaming company as a customer, Facebook's lawyers pulled the plug on it right away.

Turns out (according to Archive.org Wayback Machine), they added a new clause to their ToS two days before emailing us about our ToS violation:

"You must not give your secret key and access tokens to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers."

Moral of the story: If they want to nuke you, they WILL nuke you (I'm sure Facebook wasn't too happy about my database storing millions of users' social graphs on it, and that was the REAL reason for the shutdown).

Even during our YC interview, a couple of the most legit original partners told us on our way (permanently) out the door "yeah, you guys are going to get shut down..."

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

#434

Post by [deleted] »

krona wrote: post #386
ballenf wrote: post #326

Earlier quoted context omitted.

Disagree -- it's not the court's job to even categorize a thing as a loophole or not. It simply applies the law. Some actions will fall inside a prohibition and some outside. Divining the intent of the drafters of the law is something fraught with problems considering the process. Just one example -- there may have been a group of supporters of the law in question used against Aereo that only supported the law becaus…

> It simply applies the law This is not the case in common law systems, which the US and UK have. Judges discover the law through principals and precedent. Legislation can override this, however. The US Constitution is a good example.

[deleted]

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

#435

Post by je42 »

Operyl wrote: post #341
Xylakant wrote: post #295

Earlier quoted context omitted.

Chrome uses WKWebView on iOS, so it's basically safari with a different UI (so does firefox on iOS)

Yes, I know. I was saying the OP of this thread was wrong because it's not UIWebView, it's WKWebView with a JIT :).

WKWebView has JIT. In executes the JS in a different process than the hosted app; there the JIT lives, this special process is whitelisted to do JIT magic.

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

#436

Post by matthewmacleod »

batmansmk wrote: post #375
teknologist wrote: post #161

Earlier quoted context omitted.

I'm not sure why people are concerned about React Native being targeted by this new enforcement of the rule. It is not the same thing at all.

The main reason for React Native to not be impacted is that Facebook + Instagram + Airbnb + Soundcloud + ... are using it and Apple cannot justify to their userbase to not accept those favorite apps for a technical reason.

No, it's not. It's because React Native is a totally different technical solution.

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

#437

Post by jameside »

iOSGuy wrote: post #421
jameside wrote: post #398

Earlier quoted context omitted.

Apple has been fine with WebViews in apps since the beginning of the App Store, including WebViews that make calls to native code, like in the Quip app. WKWebView even has APIs for native and web code to communicate. It's OK for a WebView to call out to your native code that saves data to disk, registers for push notifications, plays a sound, and so on. React Native is very much like a WebView except it calls out to…

Well, let's be clear here. I use React Native, and it would take me about 30m to write a bridged React Native method that could execute ObjC code dynamically, including accessing all the private APIs you could want.

Yeah. Objective-C is definitely really flexible. From my reading of the warning, the important thing is not to execute Objective-C dynamically or access private APIs regardless of whether you're using React Native, Cordova, a WebView, or even a bare iOS app.

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

#438

Post by st3v3r »

wolfgke wrote: post #422
st3v3r wrote: post #390

Earlier quoted context omitted.

"What is "code"?" Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.

> "What is "code"?" > Apple has decided that, and you're not going to get around their policies with a clever rhetorical question. Apple cannot change mathematical facts by "decisional" rhetoric.

They're not changing anything. They're deciding the rules for their platform.

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

#439

Post by Dylan16807 »

euyyn wrote: post #392
tluyben2 wrote: post #252

Earlier quoted context omitted.

But they can theoretically create that as they own the entire chain; dev env, tools, OS, software, hardware (CPU included). I know it is not currently the case, sure, but they can do it was my point.

They "own" a compiler, but not all of them. Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents…

> Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region.

Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job.

Put privileged code into a dynamically-linked library that Apple provides. Only code in that block of memory can call private APIs. Pretty straightforward to implement, and requires nothing fancy from the kernel.

Of course this only works if you can prevent the attacker from corrupting memory.

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

#440

Post by st3v3r »

John23832 wrote: post #429
st3v3r wrote: post #388

Earlier quoted context omitted.

Under that reasoning, wiretapping laws and privacy laws should not apply to digital communications, because they were not specifically mentioned.

Not at all. If the existing law is interpreted by the courts to apply to digital communications then it does. Congress a has the ability to remove interpretations by specification.

So you disagree with your previous statement? That courts can interpret the law, including the intention of it?
Post reply on HN