This increases verifiability. Not security. And it's not the real issue.
On Linux, many apps are open-source yet users don't compile them themselves; they trust that their distro vets packages properly before making them available in official repositories.
In this situation, the problem isn't the lack of reproducible builds, but insufficient oversight by Apple that led to an untrustworthy package being made available in their "repository" (App Store).
Security is provided by the OS. A side loaded app has no more access to the device than an AppStore app.
I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
>I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
What on Earth are you talking about? The OS can provide certain boundaries in terms of "this software can do X and only X kinds of permissions" but short of a full general AI how would you expect it to tell between two pieces of software with user file access and network access permission, both of which accept banking credentials and allow you to see and manipulate your money but one of which doesn't also direct all your money elsewhere after awhile and the other does. For example. Or two password manager apps, both of which send encrypted data to a remote location, one of which does so with zero knowledge the other that has baked in a secondary key or subtle flaw in the encryption. Or a million other things.
What you're talking about is, at best, an 80s or 90s view on security where it's purely about one "user" messing with another or gaining root or that sort of thing. But we've long since passed the point where it's possible for users to suffer enormous harm purely within a constricted limited set of non-admin permissions that they have over only their data, which are needed merely to do general productive work with it at all. That's a much harder problem, and involves trust relationships with other humans and organizations. There are technical efforts that can make pieces of it better or more recoverable, but particularly given the need to interact with existing real world stuff even what can be done on that front is further limited.
Claiming all potential malicious software is just a "problem with the operating system" is kind of wild to see someone write apparently unironically in 2023. I mean, there are entire classes of software where "malicious" is going to come down pretty purely to consent for otherwise identical function. If someone accepts an advertising supported software experience and consents to their data being used in certain ways (on another system at that), that's not malicious, whereas the same thing stealthily snuck in would be. Or if their data is then used in ways that were contrary to what the software claimed, now what? How is the OS on their client supposed to police that? That's a relative power problem as well as a vetting one.
With verifiability although, a side loaded store gives better nerd-level verification ability that the vast majority of nerds wont even bother with, while a trusted app store gives more low skill masses verification higher success rates in a practical manner. Facebook is going to be facebook on the apple app store, not fake facebook, and by breaking the app store only world, your going to get a lot of old people and other vulnerable people be scammed more on their phones.
>your going to get a lot of old people and other vulnerable people be scammed more on their phones.
This hasn't happened on Android. The fears about evil apps and developers insisting on their own app stores are fabricated FUD by Apple. The simple truth is 99.9% of regular users will never install an app outside the official store. Most will never know it is even an option.
A good middle ground would be an equivalent to F-Droid, where the developer can only submit the source code and the code is either compiled by F-Droid, or it is verified as a reproducible build.
I think a good middle-ground would be having the default store have the functionality for verifiable builds like F-Droid. Add a banner/badge that the app you're looking at is open source, a red flag if it's closed source, a link to the release page in their code repository for that specific release, so that techie-people can verify the hashsum themselves and look at the code.
Of course, there's still plenty of possible supply-chain attacks and the like. Closed source app store, git repositories taken over or sneaking in malicious commits, binary blobs required to run your device, and so on. But we should encourage any progression in security, and turn good security practices into common sense.
It's possible that Apple's new Xcode Cloud service could support this at some point, providing a continuous pipeline from source to release. Though I doubt it is a high priority for them.
I’m not arguing that you shouldn’t allow side loading.
But let’s say this is what developers start doing. We compile our own code and side load. Great for us. How many people can each individual support? Immediate family and close friends? Are most people on their own? Now say your immediate contacts are compromised. That exposes some of your details as well would it not? At least you’d be more vulnerable to social engineering.
So maybe you have to work towards a system where everyone is safe.
