8 ms·
A threat analysis of sideloading [pdf]
- jagger27 5y agoIt’s the sharpest of all double-edged swords. Of course I would immediately sideload a Gameboy emulator but I’d want it to be signed by Apple. Maybe even Mozilla would make a proper build of Firefox for iOS. Surely Apple is confident in its app sandbox security model and can properly enforce those boundaries, right? I find Apple’s most convincing argument to be that schools and businesses might force you to sideload their craptacular app that didn’t pass review.
- ENOTTY 5y agoI think Apple makes great products and skimming through the paper, I find this analysis to be on-target. But this is coming from an obviously biased source. As with most things in security, it's a trade-off between competing goals and principles.
- willvarfar 5y agoI don’t understand why the “private” apis aren’t protected by capabilities. iOS has the facilities to lock these apis down properly https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app https://developer.apple.com/documentation/xcode/adding-capab... . Grepping App Store submissions seems obviously flawed.
- vlozko 5y agoThat's not what is meant by private APIs. There's a difference between the ability to call an API and getting a specific result of the API. What you're linking to are entitlements. The APIs for these entitlements are very much public but will not yield a valid result if the entitlement is missing or the user hasn't provided access. Private APIs, on the other hand, will return valid results each time. However, they are often hidden behind actual public APIs. For example, take these two stack frames: 9 UIKitCore -[UITableView _reuseTableViewCell:withIndexPath:didEndDisplaying:] + 268 10 UIKitCore __25-[UITableView reloadData]_block_invoke + 184 The reloadData call is a valid, public API call. Internally, it then calls the function in frame 9. Calling the function in frame 9 directly from within app code would be a private API violation. The Objective-C runtime makes it pretty easy to call private APIs through use of target/selectors and msgSend. I don't believe checking at runtime if a private API call is made is practical. For one, I'm not sure how technically feasible it would be but worse, there would be a performance penalty accrued with every private API. More importantly, though, the app would already be out in the wild. Compile-time and app review is really the only time to check. To the best of my knowledge, I'm not sure there's a way to force a private API call within Swift, particularly for classes that don't inherit from NSObject or are functions not tagged with @objc.
- marcodiego 5y agoI use an old android phone reflashed to e.os using f-droid. I think all those threat modes are avoided by using it. I don't think it is safe for every user to do the same I did, but I'm glad I could do it. I think a reasonable solution would be something like a hardware seal that unlocked the bootloader once broken. If the vendor worries about how this may affect them, breaking the seal could also void device warranty. I'd gladly buy a second hand still powerful device, void its warranty and install whatever I wanted on it.
- raxxorrax 5y ago> Adult video chat sites lure targets into downloading spyware Contrary to all the apps on the proprietary stores of smartphone manufacturers that never spy on people. Information extraction is a security issue, plain and simple. Smartphones are extremely bad here compared to platforms that allow sideloaded apps. Being dependent on one manufacturer is also a security issue. So I don't understand the security argument. Apps on shops probably don't contain malware, many of them exploit you legally. The software landscape outside of stores is far less prone to exploitation.
- reaperducer 5y agoContrary to all the apps on the proprietary stores of smartphone manufacturers that never spy on people. At no time did Apple state that there are zero apps in its store that violate its guidelines and spy on people. You're taking one side of an argument that doesn't exist. Too often in this debate, people think that pointing out that Apple isn't perfect somehow negates all of its legitimate arguments. It doesn't. Not even remotely.
- wvenable 5y agoWhy would the API of the device allow for spyware? What can any app do on an iPhone that will spy on me outside of that app?
- Crontab 5y agoI appreciate that requiring the use of the App Store makes security easier but I think the current situation gives Apple and Governments too much power over developers and users. Side-loading should be permitted. I am okay with it not being allowed by default but it should be something a user can override.
- simion314 5y agoWith the NSO revelations we know that Apple can secure their own apps and from the other releases of zero days we know Apple is bad at communicating with security researchers and that their automatic security review is a joke, honestly someone motivated could implement a better security scanner that could actually catch the "private" API usage though we all know that the solution is to not have private/hidden APIs that are shared only with special apps like Apple ones and partners. TLDR there could be a safer store alternative.
- HatchedLake721 5y agoI think you deeply misunderstand what it takes to run a marketplace generating $60+ billion revenue and serving over billion users thinking “we can just run a safer store ourselves” by “simply implementing better security scanner”
- simion314 5y ago>I think you deeply misunderstand what it takes to run a marketplace generating $60+ billion revenue A monopoly is an easy way to do it, then inconsistent review and bad security scanners are irrelevant, you need to add some PR team to try to defend all the bad stuff and misdirect.
- keehun 5y agoOne of the salient points Apple makes in the document is that by the mere ability for sideloading to be possible, it would be forced upon users by schools and jobs. It also opens an entirely new attack vector by spoofing and other means of deceiving the user into either sideloading an app they didn't mean to.
- Someone1234 5y agoIf this was actually about security instead of control, Apple could compromise: Allow third party app stores to exist, but Apple gets to sign the third party store app itself (and can set minimum requirements like app review). It may sound counter-intuitive, but the whole issue here is that Apple is using their store for anti-competitive things (e.g. blocking/slowing competitors, requiring the use of Apple's payment infrastructure, Apple's ads, etc). If third party stores could exist, you wouldn't need side loading, and security isn't completely compromised as hopefully the third party store provides some level of assurance (Vs. essentially none with side loading). This of course won't happen because it is absolutely about control. Apple may one day allow side loading but will make the process incredibly unpleasant citing For Security Reasons™ as their justification.
- sudhirj 5y agoYup. Trying to solve security and control with the same hammer is going to get them in trouble. If I make a calculator app, it’s fine to review it and make sure it’s secure, but to tell me that there’s too many calculator apps (or worse reject for a bullshit reason and make their own) is going to get them in trouble. Security checks are fine, choosing who gets to enter is not.
- woah 5y agoWhat would be the point of that?
- Someone1234 5y ago> It may sound counter-intuitive, but the whole issue here is that Apple is using their store for anti-competitive things (e.g. blocking/slowing competitors, requiring the use of Apple's payment infrastructure, Apple's ads, etc). To solve those?
- judge2020 5y agoThe reason nobody wants this is that is barely moves the needle. Apple is still the de-facto "gatekeeper" if they set the rules for running a third-party app store like app review and what specifically has to be reviewed (which they need if they don't want the 3p dumbing down the review process to something like just verifying the name matches the app functionality). I don't think many developers interested in a new app store would take it if Apple randomly blocking them for not having stringent-enough app review is a possibility.
- howinteresting 5y agoPersonally I think sideloading on personal computing devices like smartphones should be mandated by law, and then the big brains at Apple can figure out how to make it secure.
- reaperducer 5y agoWhile I don't ordinarily approve of whipping out the law hammer to solve every problem, this does provide a little food for thought. Instead of a gub'mint telling Apple "OK, you have to let there be an app store free-for-all right now" and Apple watching its work descend into chaos overnight, there could be a middle ground: "OK, you have to let there be an app store free-for-all in five years." That could give Apple a good amount of time (and it already has the money) to harden iOS as much as it can. (I'm only half-way through reading the Apple document, so maybe this is addressed later.)
- howinteresting 5y agoPerhaps it might mean Apple has to slow down feature development, beef up its sandboxing, switch to memory safe languages like Swift, or do more to entice developers to its app store. All of these would be good outcomes. I'm fine with giving Apple a bit of a lead time here, but ultimately people should have the right to do whatever they want on their own personal computing devices.
- throwaway946513 5y ago> Over the past four years, Android devices were found to have 15 to 47 times more malware infections than iPhone. This reminds me of the NSO and Apple's history of failing to cooperate with security researchers. If sideloading "were possible" and "forced upon users by schools and jobs" then I'd find it interesting that Android users by far haven't complained about this. I used to use an Android device and never had anyone force or tell me to sideload an app that I didn't want to use myself. I've actually had to install more apps through the Play and App Store for my education and work. All this said - my current iPhone 6s will be derelict soon and replaced by a de-googled Android device in the future.
- jmull 5y agoApple's argument is basically, "It'll be chaos!!!" But... We don't have to wonder what it would be like. There's been mass use of platforms that allow "side loading" (AKA, just regular installing) and "third-party app stores" (AKA, just regular buying software) for decades. No, it hasn't always been pretty. Yet it just hasn't been that bad either, and the benefits have proven to be very substantial. There are incredible amounts of great software available that doesn't fit in to Apple's idea of what ought to be allowed. And it's not like you can download with confidence from the Apple App Store either. They play a cat-and-mouse game with malware constantly and there's been plenty of collateral damage. I think there's no question third-party app stores, or just direct side-loading would lead to a lot of new great software, without a ton more risk. I think the weakness of this argument document show that.
- gumby 5y ago> We don't have to wonder what it would be like. There's been mass use of platforms that allow "side loading" Apple is a significant vendor of such platforms. They have an A/B experiment running on the Mac. I prefer to buy directly to send more money to the developer, but I suspect most people prefer the (confusing) store. In other words: what chaos?
- musicale 5y ago> They have an A/B experiment running on the Mac Kind of, in terms of sideloading restrictions; not at all in terms of software library, business model, and incentives. Most (70%+) of Apple's iOS App Store revenue is from games (largely in-app purchases since mobile games tend to be "free to play.") In fact Apple's profits from iOS gaming are larger than the gaming profits of Sony, Nintendo, Microsoft, and Activision combined. You can ask any poor Mac gamer about the state of the Mac game business... it isn't great, and it certainly isn't Apple's bread and butter like iOS gaming. From the perspective of Apple's business and profits, the iPhone is largely a walled-garden game system, much closer to the PlayStation, Switch or Xbox than to the Mac. Apple isn't wrong about potential security and privacy threats, but the threats to Apple's business and profits are most likely the driving issue.
- 5y ago
- samgranieri 5y agoGranted, I've never submitted an app to the App store (outside of work) and I do have some serious reservations about how Apple runs the store, but I actually like the fact that the only way to slideload apps on the device is to jailbreak or compile and install the app yourself (provided you sign up as an apple developer account). I think the lack of officially sanctioned slideloading keeps the device simpler, and in my mind that's more secure.
- wayneftw 5y ago> ...compile and install the app yourself... Every 7 days!! if you only have a free developer account, otherwise every year and only for a limited amount of apps. If we could compile and install apps without any limitations, we'd already have a competing app store that automates this for people.
- boringg 5y agoI am maybe the anomaly in this crowd (I also don't develop apps for iPhones) but I appreciate the security benefits that Apple puts on people. Sure it comes at a cost of "freedom" of applications that I could put on my phone, but it gives me a bit of piece of mind that my aging parents and my nieces and nephews are able to use the phone without downloading very risky applications (I mean there are still risks abound, but it decreases it significantly). There are already enough security flaws that continue to be patched up on an on-going basis that it seems unnecessary to open this level of risk for their client base. One less thing I need to worry about. Understand I am fairly alone in this perspective.
- HatchedLake721 5y agoYou’re not alone in this. You can be alone in this in the tech bubbles where developers suggest mums use Kubernetes to run their knitting blogs and complain why they can’t run Docker on their iPads. Outside of this, while Apple has a financial incentive for the status quo, they also care about customer experience (we know Apple is laser focused about this even in the pre App Store years and decades). And on the whole, sideloading will do more harm than good.
- diebeforei485 5y agoThe argument about users being forced to sideload apps by their school (effectively spyware) is a good one. This has become a real issue during remote learning. Ultimately, if Apple keeps insisting on digging in their heels on the supracompetitive 30% commission, then governments will have to act with a broad brush and allow sideloading as a way to force competition.
- orev 5y agoRemember when LinkedIn made an app that MITMed email connections just so they could add a signature to your messages? [1] Or when Facebook was distributing internal dev certificates to the general public so they could collect data on teenagers using private IOS APIs? [2] Sure, most here would know not to do it, but it’s abundantly clear that the general public cannot manage technology. And this is what these companies were doing publicly. Imagine if they had unrestricted access through other app stores? Data is the modern day gold rush, and it seems like every company has gold fever. They just can’t help themselves in being as intrusive as humanly possible. It’s nice to have some kind of control over it. I would be open to alternate app stores if and only if they were unable to circumvent MDM restrictions. At least that way you could protect company assets. [1] https://news.ycombinator.com/item?id=6600597 https://news.ycombinator.com/item?id=6600597 [2] https://www.theverge.com/platform/amp/2019/1/30/18203551/apple-facebook-blocked-internal-ios-apps https://www.theverge.com/platform/amp/2019/1/30/18203551/app...
- smoldesu 5y ago> it’s abundantly clear that the general public cannot manage technology Remind me again how Apple has transcended beyond "the general public".
- mikewarot 5y agoUntil we can safely support native mobile code, and let the hardware and OS keep it from going rogue, we're on the losing end of the war against general purpose computing.