To make it harder for a competitor to pop up and offer their own flavor of the binaries and support. It's just to raise the barrier of entry to others monetizing your project
I do, and wherever all other things are equal, I always choose an open source solution. But if all other things were always equal, I'd be running OpenBSD full time, so...
Being open source is not as useful on iOS though, since there’s no way to verify that what they uploaded to the App Store was actually built from the source that you can see.
The point was that you _could_ verify whether a binary package matches the source if you wanted to on other platforms, not that you _have to_ do it all the time. With iOS you don’t have that ability so you’d have to have complete trust in the developers. The threat model is someone publishing innocent source code but sneaking in something malicious in the version they publish on the App Store, of course.
> Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible.
Apart from Debian and NixOS, I'm not aware of any other large-scale efforts to make builds reproducible, so this something you have to assess on a case-by-case basis for every single piece of software you might want to download and install. Not IF the checksums match, but IF the project aims for reproducible builds in the first place.
By the way, if you download an iOS app on an M1 Mac, you can inspect its archive freely, including generating and comparing checksums of each file, disassembling the executable, and so on. So while not every iOS app can be downloaded on a Mac (the developer actually has to opt out), and not everyone has access to an M1 Mac, this is not entirely impossible.
> With iOS you don’t have that ability so you’d have to have complete trust in the developers.
This is not entirely true. I also have a certain degree of trust in the application sandbox provided by the OS, and in the app review process. I know neither is perfect but it's not like everything I install runs with full root.
> The threat model is someone publishing innocent source code but sneaking in something malicious in the version they publish on the App Store, of course.
What is your strategy for applications that do not publish any source code? Do you exclusively use software with source available?
Don't get me wrong, you raise valid and important points, but this is a way bigger fish and "if only Apple did X" is just the first step.
I wasn’t thinking of reproducible builds specifically, more that you’d be able to disassemble the binary if you wanted to check, because…
> if you download an iOS app on an M1 Mac, you can inspect its archive freely, including generating and comparing checksums of each file, disassembling the executable, and so on.
I did not know this. I thought iOS binaries are always encrypted. Why would they make the unencrypted binary available for M1? And now that they did, why would they bother still encrypting the same binary on iOS? (Do they still?)
> I also have a certain degree of trust in the application sandbox provided by the OS, and in the app review process.
I’m not too worried about an app escaping the sandbox and harming the rest of the system either. More that it could do something malicious with the data it has legitimate access to. For example, a password manager sending all your passwords to a 3rd party, a browser app injecting JavaScript into the pages you open, or a VPN app analysing all your traffic.
> What is your strategy for applications that do not publish any source code? Do you exclusively use software with source available?
Well _you_ were the one who preferred open source, not me. I was merely pointing out that “open source iOS apps” might as well be called closed source, since I thought it was impossible to know if you’re really running that code on your device.
> I wasn’t thinking of reproducible builds specifically, more that you’d be able to disassemble the binary if you wanted to check [...]
Disassembling and analysing a binary (even with source available as a reference) is an *extremely* huge leap from comparing checksums. We're mere mortals. Get real ;)
> I did not know this. I thought iOS binaries are always encrypted.
I've just checked a bunch of iOS apps I have installed on my Mac (Apollo, Blink, Bandcamp, Organic Maps, iSH); ran strings, dyld_info, otool, etc on them, no walls. Maybe only the headers, rodata, linker metadata, etc are unencrypted? Should I keep digging?
> Why would they make the unencrypted binary available for M1? And now that they did, why would they bother still encrypting the same binary on iOS? (Do they still?)
No idea. But the binary being distributed on macOS and iOS is the same; or at least, it doesn't need a separate build/upload, apps published before the debut of M1 just work.
My company actually needs to release an update to an iOS app in the near future, perhaps I can take the chance to compare the artifacts.
> More that it could do something malicious with the data it has legitimate access to.
There are two possible scenarios where this happens: the developer being malicious, and a supply chain compromise.
In the first case, the developer risks getting ostracised by both the community, and the Apple overlords (e.g. for violating App Tracking Transparency). It's also a very risky move, since the traffic from the app can be analysed (e.g. on your home router) at any time, without the app ever knowing; and without e.g. certificate pinning, can also be snooped or MITM'd; this puts a timer/window on it. So in practical terms, for this to be remotely useful or worth the risk/effort, this would have to either be a narrowly targeted attack, and/or a one-off smash & grab. Again: not perfect, but the system has countermeasures.
The latter case is something we (as in: the entire industry) are still trying to figure out. Even with a fully OSS supply chain, it's far from ideal: https://drewdevault.com/2022/05/12/Supply-chain-when-will-we... - and again, in case of the App Store, with a third-party (Apple) review step, there is at least the idea of independently verifying the app's legitimacy.
> I was merely pointing out that “open source iOS apps” might as well be called closed source, since I thought it was impossible to know if you’re really running that code on your device.
You've never asked me, what was my own motivation for preferring free/open source software - and made a bunch of assumptions, not all of which held.
However I do share your view, that under certain (actually, very common) circumstances, software that is nominally free/open, can be considered closed in practical terms: and that, in my book, is rampant complexity. If the code is too complex for me to read and fully understand it, what use do I have from source access? Hence, my actual vote is for OpenBSD; but sometimes you just need to compromise to get stuff done.
Because if I need to deploy some tech for a company with a thousands of clients I want something what doesn't need my attention for every other client station. I need something robust what would work 99% of times and for a 1% what disbehave I can OR just change the environment so the client would run or drop a ticket to the guys who I am paying for diagmosing these things and after a couple of days or weeks:
Just install a new version which would work OR
Have the understanding how I can change the environment so it would work.
The thing is what I don't need to spend my time on solving these things.
