Linking this next time somebody tries to tell me iOS's limitations on sideloading improve security.
In reality it costs the bad guys $299 to bypass this limitation, while your average user is locked out of this feature.
In reality it costs the bad guys $299 to bypass this limitation, while your average user is locked out of this feature.
> In reality it costs the bad guys $299 to bypass this limitation
And enterprise certs aren't so easy as "just give Apple $299", try and get one then get back to me.
The point I'm trying to make is that Apple isn't consistent here. If they actually believed this to be true there would be no way to get a sideloading cert that worked on all devices.
"Sideloading is dangerous because users could install malware" and "We'll let any iPhone sideload your app if you jump through some hoops and pay us" are incompatible statements, but Apple makes both of them.
> And enterprise certs aren't so easy as "just give Apple $299", try and get one then get back to me.
Obviously not, but the linked post demonstrates attackers are more than capable of getting one.
I don't see this as Apple making incompatible statements.
I've never seen Apple claim that its system is flawless. Do you have a link?
I'm sure the fact this setup forces all apps to go through Apple's app store and pay them 30% of their revenue is just a unfortunate accident.
My point is that if Apple truly believed sideloading was a risk to user security there wouldn't be certificates that let you sideload on all devices. They would force companies to provide a list of devices or only allow devices enrolled in their MDM or some similar reasonable restriction.
Does a normal enterprise charge its users to install internal apps? If not, this seems like an odd complaint.
> My point is that if Apple truly believed sideloading was a risk to user security there wouldn't be certificates that let you sideload on all devices. They would force companies to provide a list of devices or only allow devices enrolled in their MDM or some similar reasonable restriction.
That last part is effectively what they're doing: you have to do the same level of scary prompt and authentication to install an enterprise certificate as you do to enroll for MDM. Yes, users can still be socially engineered to compromise their device but that's an order of magnitude harder than just convincing someone to run some random binary.
Even on Android with its openness and notoriety for security issues, to sideload APKs means having to navigate multiple settings menus to get to it, which screens out the majority of non-technical users. Though that is more playing to the "strength" of that platform (clunky design and unwieldiness), which Apple would not be doing.
I personally think the best solution here is regulation: let Apple and Google control app distribution, with some legal mandates for prompt responses both to active threats as well as developer complaints, but cap the percentage they can charge.
Most people do not bother to root their Android phones, and it's perfectly possible to pirate iOS apps on non-jailbroken phones, so that point is also moot. The people who are technically savvy enough to pirate apps are already doing so whether sideloading is made possible or not.
Finally, you discount Apple's mastery of UX patterns and their capability of design. By simply changing non-Messages texts to green, they created an entire dichotomy between messages from iOS devices, and non-iOS. Do you really think they wouldn't be capable of doing something similar towards official App Store-originated and non-official apps? Simply a subtle color tint, a badge, some off-looking font, and they can get users to look askance at sideloaded apps with caution. If Apple had to make sideloading possible, you can bet they can make it a secure and curated experience, as they do with the rest of their walled garden.
(0) https://twitter.com/marcoarment/status/1489595417117483010
Your second sentence contradicts the first: the difference is not whether it’s theoretically possible but whether it’s easy and thus widespread. That’s the important distinction and it deserves more careful thought when you’re talking about devices large percentages of the population trust heavily.
> By simply changing non-Messages texts to green, they created an entire dichotomy between messages from iOS devices, and non-iOS.
Similarly, this deserves more careful thought: is the difference the color or the fact that one which isn’t controlled by the phone companies is faster, more capable, more secure and cost less for years?
Again, I’m not saying that Apple is perfect but it’s not as simple as people like to portray it, either. Multiple of the topics here are market failures where governments were deterred from stepping in. What Apple has done is not purely benevolent but it’s also satisfying a lot of users - they didn’t go from niche to one of the most important tech companies because they weren’t doing what people liked (and, no, it’s not “just” marketing or design).
Apple can allow sideloading without making it easy. This whole discussion is about whether or not Apple can craft a user experience that carefully balances between permitting users to use a powerful and potentially insecure ability, and carefully warning them against it, warning off those who are not savvy. I believe they can.
> Similarly, this deserves more careful thought: is the difference the color or the fact that one which isn’t controlled by the phone companies is faster, more capable, more secure and cost less for years?
I believe it's self-evident. The appearance of the different UI itself, which clashes against Apple's otherwise uniform design scheme, presents its own inherent psychological friction. Certainly, non-Messages apps come with certain poorer performances in Messages. The way group chats get broken up. The inability to respond to Messages. None of that has anything to do with phones being faster, more capable, or more secure. The difference in of itself is created by the users drawing the distinction in their own minds.
Similarly, I believe if Apple was to curate the sideloading experience, the majority of iPhone users can simply be guided away from that. And it will remain safely the province of developers and power users. Apple is simply too good at crafting user experiences to not be able to do that.
Indeed. I'm (maybe) willing to sideload an app from my employer but not from some other company. Perhaps only managed devices should have this capability, and only for apps signed by the managing authority.
I won't allow my employer to manage my personal phone; they have to issue me a phone if they want that kind of control. And in that case it's their device; they are welcome to manage it as they see fit.
Also: this is different from TestFlight.
I'm missing how these are incompatible statements. You might as well say "if Apple thought certain apps could be dangerous they wouldn't have an App Store or even allow their own first-party apps on iPhones." Of course the position of Apple is that they should be able to approve every app/vendor before it's allowed to be installed on iPhones. The fact that they do approve some apps and vendors isn't incompatible with their position.
EDIT: Formerly I asked: What does the scary warning look like? Is there a screenshot of an example? I would like to show this to my employees and family and tell them never to trust such a cert.
Often it's custom or white labeled software that benefits from enterprise distribution.
EDIT: Also if an organization is large enough TestFlight might not be suitable to cover everything they need. For example you might want nightly developer builds, weekly/milestone internal test builds, stagings builds, and then TestFlight and release. You can accomplish this with multiple apps that are never released (My App - Dev, My App - QA) so you can use TestFlight for each and then only release the production "My App" but that has some sharp edges and requires everyone be added to the Apple development team.
And since they're company devices, either IT can set them up before handing them out, or you can use tools to pre-install the certificates.
It's a moderately hard problem to resolve.
If it's my own device, I don't have to worry about it because it'll never happen.
This kiosk type stuff that was mentioned up thread is the type of stuff that could just as easily be run off of a corporate LAN site that I can access via my company provided compute device. The fact that the younger generations have been forced to accept BYOD as a work device is just sad to me.
Imo the key question is: If you can find an exploit in the iOS sandbox, will the app store review really stop you? Compared to the expertise required to find such an exploit, it should be pretty trivial to obfuscate it or load the payload remotely after install.
The App Store review is two-pronged -- it includes some human QA testing, and it also includes some automated screening of your executable, which includes checking for any suspicious library imports or strings. (This sometimes trips up applications which happen to use method names which happen to match up with Apple's internal APIs.) While it isn't entirely impossible for a malicious application to slip past this examination, it's significantly harder than for an Enterprise application which doesn't go through this process at all.
I believe you, but... so how does a "commercial spyware" company get one, and has it been cancelled by Apple after they see what they are up to?
Or do their not-so-easy requirements... allow "commercial spyware" companies to fraudulently impersonate other apps with the cert?
With this article shining yet more negative light on the program after the Facebook/Google spying-on-the-internet-access-of-kids debacle effectively shut the Enterprise program down, the MDM space will be even harder to innovate in, considering no startup will ever meet the required bar for signing up for an Enterprise account.
While I wouldn't say that's exactly wrong, if this type of thing happened often I would think that we wouldn't see Google writing this up as interesting. Doesn't seeing this mean it is a rare and noteworthy event and more evidence that iOS's limitations on sideloading do improve security? I'm not sure how often this happens, so I could be way off.
This IS a case of using an enterprise certificate to sideload an app.
If anything, this proves that sideloading, even with scary warnings to the users, enables malware.
They also had to get verified as a mid-sized or greater corporation (Apple does use real verification partners), and further Apple can pull the rug on the certificate in an instant, immediately invaliding that $299 certificate and the considerable effort that went into getting it.
In reality this group likely had to hack an existing Apple Enterprise approved business first, then using that to springboard to the next step.
Casually dismissing that enormous gate is pretty tenuous.
Organizations sophisticated enough to build something like this already target organizations like device manufactures to get kernel driver signing certificates on Windows.
Even if I take your prices at face value, I'm not sure "Apple charges 1/2 the price of the phone to unlock sideloading" to be a killer argument.
You need to be a verified business to get this.