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.
It seems it's not possible to add "Cloud Identity Free Edition" to your account while the legacy subscription is still active, and I don't want to risk cancelling it before the deadline in case it has other unintended consequences :(
Even disregarding that the exemption was issued by the tennis association to play in the tournament, not for entering the country… it was predicated on him being able to provide a valid medical reason, _and_ not lying on his entry documents. Neither of which he managed to do.
Judge Kelly noted that Djokovic had provided officials at Melbourne’s airport with a medical exemption given him by Tennis Australia, which is organising the tournament, and two medical panels.
“The point I’m somewhat agitated about is what more could this man have done?” Kelly asked Djokovic’s lawyer, Nick Wood.
Wood agreed with the judge that Djokovic could not have done more.
All this posturing about "rules are rules" seems to be an after-the-fact finger-pointing exercise and trying to get someone to own a decision that should not have been made in the first place.
> No agreement, and no decision, was made on whether the ABF officer could have cancelled Djokovic’s visa under s 116 in a watertight way. All that was found was that the process he followed was deficient enough that the original cancellation couldn’t stand.
I do not understand the "what more could this man have done?" line.
Trying very hard to meet the rules for entering a country, but not actually being able to meet them, does not normally give people the right to enter that country.
I think the sticking point here was that he was given approval by the Victorian government which failed to communicate with the federal government. Arguably you can frame it as his fault that he did not get an assurance from the federal government, but a reasonable person would not expect the state government to have failed to secure the required assurances from the federal government.
Nope. That was a private comment made by the judge (who is obviously lacking in impartiality, since he made that comment very early on, before the two sides presented their cases). The decision to quash the original cancellation was due to agreement between Djokovic’s and the government’s legal teams, and the judge made no ruling of his own. See linked Twitter thread in the sibling comment.
The first visa cancellation was overruled purely on the grounds that it was issued too quickly and did not give him enough time to respond. It has nothing to do with whether his exemption was valid (which it clearly isn’t).
I swear, the early English grammarians did quite some damage calling the ej sound "long "a". I understand why they did that, but it really screws up any talk about comparing different languages: what pretty much everyone else calls "long "a" is the a:/ɑ: sound (or something very close to it) — which is actually long, compared to a/ɑ.
> Presumably Apple executives, by virtue of working for a global company, are more likely than average to use dual-SIM or swap between SIMs when travelling.
I’d imagine it’s the opposite. Presumably the company pays for their roaming charges so swapping SIMs is a foreign concept for them.
