4 ms·
He's right, but he's almost too right: absolutely everything he says is a problem with bitcode applies to normal app store distribution and all other centralize
by api 11y ago
He's right, but he's almost too right: absolutely everything he says is a problem with bitcode applies to normal app store distribution and all other centralized cloud-powered OSes and apps. Therefore I don't see this as a good argument against bitcode -- not using bitcode does not prevent anything he says from occurring since anything that can be done to bitcode can be done to machine code.
(1) Apple has the signing master keys for app store certificates. It would be easy for them to binary-patch your app with anything they want, generate their own signing certificate in your name, and re-sign the app as they push it out to users. Since app store transactions are on a per-customer basis this could be done only for some customers -- such as only residents of a certain country, people whose names are on a list, etc. It's very unlikely that anyone would notice.
(2) It would also be easy for an attacker to do this if they compromised Apple's core infrastructure as described in this article. Then they could generate signing certs in other developers' names and trojanize apps in exactly the same way. A "doomsday hack" that trojanized all Apple devices in the world within hours is not impossible. If they all started, say, DDOSing core BGP and DNS systems at the same time, such an attack could take down the entire Internet.
(3) Apple, since they control the platform and can remotely patch it at any time, needn't bother with trojanizing apps. They could simply trojanize the OS kernel or user-space OS components and accomplish anything a trojanized app accomplishes.
The same also applies, by the way, to Windows and also to Linux if you trust remote code repositories and do not compile everything yourself from verified known-safe source code. It also applies to from-source-compiled OSes and distributions if you did not painstakingly check every line of code yourself. Google the "underhanded C contest."
If you run code that is not yours, you are trusting someone else. It's a subset of a larger principle: civilization implies trust. Without trust you cannot have specialization of labor, commerce, or law. Without those there could be no advanced technology or infrastructure, so none of this would matter.
To use an Apple device is to trust Apple, at least insofar as that device and any data you keep on it goes. To use Ubuntu and its repositories implies the same level of trust in Canonical, etc.
The privacy problems of the digital age are not entirely technical in nature and do not have entirely technical solutions. They can only really be solved legislatively and socially.
- SomeCallMeTim 11y ago>The same also applies, by the way, to Windows and also to Linux if you trust remote code repositories Curiously, Google/Android has developers sign the app, and that exact signed package is what's distributed, so at least the app developer can verify that the distributed app is identical to the one shipped to the store. On the other hand, Amazon/Android signs apps with their own keys, so they suffer from the same issue as Apple.
- joosters 11y agoUsers don't check the signature of apps that they download, their phone does it for them. So even if apps are signed by the developer, the app store owner can throw away the signature, modify the app and then sign it with their own key. People downloading and running the app won't see a difference.
- SomeCallMeTim 11y agoIf a developer downloads the app, they can verify it. But more to the point, I published an app on the Play Store that actually verified its own signatures (as an anti-piracy measure) and it worked correctly. Not only that, but it used the signature as a key to decrypt some of the assets, so a changed signature would mean the app would completely fail to work. So it's a solvable problem on Android. But not at all on other ecosystems.
- donarb 11y agoYour digital signature on your app is a contract between you and Apple, not you and your customer.
- BlunderX 11y ago> He's right, but he's almost too right: absolutely everything he says is a problem with bitcode applies to normal app store distribution and all other centralized cloud-powered OSes and apps. Therefore I don't see this as a good argument against bitcode -- not using bitcode does not prevent anything he says from occurring since anything that can be done to bitcode can be done to machine code. Not true. Not using bitcode allows you to select optimization options and have a "receipt" on what CPU:s your code will run, by providing those slices. Now, Apple can also (in theory at least) change endianness of the target code. Instead of users being unable to install the app (a bad idea), they will install an app that breaks (an even worse idea). Endianness is one example. Optimizations another. There can be more. Hiding even MORE stuff from a developer who in turn is responsible to a customer and to users can only raise the development cost (because maintenance contract is usually a part of development cost), not lower it. I do not need MORE hidden issues and LESS control over the work I put my face on.