251–260 of 498 posts
It is too bad people is using it for good causes but the hole has to be closed. Sorry guys.
Earlier quoted context omitted.
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.
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.
It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs ( http://sourcedna.com/blog/20151018/ios-apps-using-private-ap... ) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mo…
From https://rollout.io/how-it-works/ : 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.
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.
devs should re-submit their code to apple, instead pushing "fixes" to phones. i guess it's fair to assume 99% of those pushes are safe (80%? guess it's more like 'benefit of the doubt'), but that 1% the escapes scrutiny is the one piece that makes the whole platform shaky, and honestly, poses a major attack vector. i wonder how often this was abused.
as to service like rollout.io, it's a service that was never supposed to be. especially if it serviced hundreds of apps - as a security minded indv. i shudder at the thought of what might have slipped through.
edit: after digging into rollout.io and finding out it's based in telaviv, is it wrong to speculate about origins and real purpose of an israeli company that specializes in injecting code into iphone applications?
Earlier quoted context omitted.
Nothing guarantees nothing. Life is ephemeral and we're all going to die. Yet, we can say that code review by a third party is better for trust of that code, than no code review by a third party. "Nothing guarantees" may have been strong. but "the set of attack vectors and their relative efficacy increases " doesn't roll off the tongue quite as nicely.
> we're all going to die That's guaranteed, at least ...
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 can't imagine any iOS developer who knows the guidelines and how your product works wouldn't have been worried.
Earlier quoted context omitted.
This is true. The problem is bad actors can use this to bypass Apple's review. As an iOS app publisher I slightly regret this inconvenience. As an iPhone user, I appreciate Apple looking out for my security.
Apple's review isn't that useful in this case as a pre-check, it is possible to avoid it if you want. Apple review does automated code checks & a reviewer manually using your app. With that review process you can deliver executable code after the fact in any way you want and only get caught after the fact if it's even noticeable. You can even get sneaky and add some security exploit to make it look like a mistake. It…
it's about damage mitigation, and shutting down a 3rd party "app-hot-fix" service is a good move.
it's harder to fool only apple, than to submit some naive looking thing and still have unmitigated access to changing its code.
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.
It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs ( http://sourcedna.com/blog/20151018/ios-apps-using-private-ap... ) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mo…
Apple often uses immature frameworks internally - like the extensions framework - to to polish them or to dog food them before making them official.