Hacker News Reader

Comment by simplehuman | Hacker News Reader

Does Rollout comply to Apple’s Guidelines?

    Yes. As per Apple’s official guidelines, Rollout.io does NOT alter binaries. ... With over 50 million devices already running our SDK, it is safe to say that Rollout complies with with Apple’s development and App Store guidelines.

Ouch. Just like the company's future is in danger.

View on HN

> Rollout lets you push code-level changes to native iOS apps, without waiting on the App Store.

What did they expect when their entire business model is based on something that's literally the opposite of what the review guideline allows?

Uber is still doing kind of ok.

Uber isn't going up against one company though. It is going up against 1000s of governments.

What does Uber do?

They run an illegal taxi service. There's an app for it too.

It's legal in many cities.

It's become legal (after the fact) in several cities, and Uber has allegedly intentionally attempted to subvert attempts by law enforcement to investigate their operations.

Some cities it was legal to begin with, btw.

Only following the law in "some cities" is not a good thing.

"Illegal" doesn't mean "I have a beef with it".

Uber is legal in the vast majority of cities.

"Mostly legal now" doesn't change the fact that it was illegal in the past and is still illegal in cities that are not in the "vast majority".

Not to mention that they (allegedly) attempted to subvert law enforcement attempts to investigate them, by "greyballing" law enforcement. Whether that is considered obstruction of justice is a secondary question to whether it is incredibly shady.

I know. I'm using "illegal" to mean "against the law".

Half of Uber activity is illegal (UberX in states, it was called Uber Pop in France but it got banned). The other half is perfectly legal and convenient.

However, due to their miserable practices I am glad that almost all (if not all) drivers for Uber also drive for the local taxi-in-an-app service.

So is Airbnb...

Uber may be good at skirting local laws, but as a company it's a ticking bomb.

Uber is not a ticking time bomb if it is able to convince a sizable portion of the regulators of the markets it operates in to continue to operate for the foreseeable future

The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim to do without flagrantly violating the guidelines.

I'm guessing there are two things Apple is worried about. The first is using hot code push to change the purpose of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs.

You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls back into pre-existing native code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban the app and the developer if they catch it.

It appears that Rollout started using some API that would enable it to do the second, and Apple is preemptively making sure that it doesn't happen. The wording of the rejection is based on passing computed parameters to introspection routines.

> The second is using hot code push to violate app store review guidelines, like the use of private APIs.

I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?

Presumably because many private APIs are used behind the scenes by public APIs and the security model must allow applications to run them.

Because some of these APIs are useful in an enterprise app setting that aren't distributed via the App Store. Like Disney applications on their turnstile devices at Disney World.

You aren't supposed to call private APIs in your code, but your app is definitely making private API calls all the time since the libraries provided by the platform are running in-process.

Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.

They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?

Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.

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 people from using a different linker anyway, one that would put private API body functions out of the restricted region of memory.

The only real way to achieve that would be to move all their frameworks to the kernel, which would be all sorts of problematic.

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

I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage.

And well, in any case they need to maintain compatibility with current apps for who knows how many years.

> I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage.

Such a scheme wouldn't stop ASLR. The loader just needs to tell the verification code where it put the privileged libraries.

> And well, in any case they need to maintain compatibility with current apps for who knows how many years.

Do they? I think Apple could easily order everyone to switch over to a more secure compiler with a one year deadline.

At best all they could do is change literally every single private function call everywhere to inspect the return address and see if that return address is in a system framework or is in the app image. But this would be huge overhead, a real pain in the ass, and also not even reliable, because all you have to do is pick a public function, figure out the address of the `ret` instruction, push your $pc onto the stack, and then call the private function passing the address of that `ret` instruction as the return address. The private function will see that this address is in a system framework, and so will work, and then it will return, passing control to that `ret` instruction which immediately returns back to your real caller function.

So no, there's no way for Apple to technologically make it impossible to call private functions. The only actual solution there would be to completely rewrite the OS such that literally every call into a framework that an app makes actually goes over IPC (so that way apps can't even attempt to invoke private functions since they won't be linked into the app), but that would probably be crazy slow which is why nobody does that.

> I'm guessing there are two things Apple is worried about.

I'm sure it worries about them but there's a much larger, riskier scenario.

Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong.

1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secure manner, but the server from which the code is served becomes cot mpromised 3. A malicious employee at an iOS app vendor pushes harmful code out via her company's app

Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. Just like Android or MacOS.

However, I sympathize with them here. For nearly a decade people have been downloading code from the App Store with the understanding that it is safe to do so. Even I appreciate this much of the time... I'm an engineer but I'm busy. I can't audit every app I download. I wish there were other options, but I find huge value in the fact that I don't have to worry about an App Store app screwing my device. And it's a big reason why I recommend iOS despite its flaws to older family members.

> Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources.

This exists today and has for a long time, it just costs you money for this "privilege".

You can compile and run apps on your own devices without a paid developer membership: https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-...

They've nerfed this so that the app will only run for a week before you must push another build.

You can drop a .ipa file into iTunes and load/run the app on a phone that's syncing to that copy of iTunes...

Getting the .ipa signed still costs money (or has a week-long timebomb), and you can't run unsigned code.

Which is disingenuous to say because the guidelines forbid using these methods to make "significant changes to the app" - it doesn't mention modifying the binary.

Heh, "We're in so many apps... it MUST be allowed!"

To be honest, I think the fact that they're used by so many big players is the reason that Apple is requiring removal in future updates rather than outright removing for ToS violations.

Very little sympathy for anyone who didn't see this coming, I'm more just shocked they even got it past Apple in the first place.

Even if I had the idea and the technical skills to pull such a product off I wouldn't even bother trying for fear it wouldn't even get past the first hurdle.

It won't be the first $10m+ company killed by Apple's App Store policy. I hope it will be among the last though.

So you're routing for ${FutureAbusiveSpamCompany}?

Rooting. As in 'root password acquired' ;)

Ha, I'm British and it shows.

I would be cashing out now...!

Reply on news.ycombinator.com