With Google's Android, this issue will never arise because Android is open source. Any attempt to plant a backdoor will be outright monitored by the community.
Not too sure about this. Keep in mind that in most commercially sold Android phones, closed source, self updating, Google Play Services is installed by the manufacturer with system level privileges. That alone is enough to create a non insignificant back door.
Or, said differently, Play Services are already a backdoor. They can (and do) install updates or other software pushed by server automatically, without you being able to do anything about it. And they have access to anything on the phone.
Google Play Store manages the permission dialog for apps installed via Play Store (Play Services is one). It just doesn't show it for Play Services and just auto-accepts installation.
But you can always root your phone and install Cyanogenmod from scratch, right? Agreed that this is not too trivial right now because of standardization issues, but it could be done if you really care about privacy.
Not all of CyanogenMod is free software (you still have a bunch of binary blobs, and everyone has to use Google Play Services anyway because every app seems to implicitly require it). Replicant would be a much better alternative if it actually supported anything newer than 2G.
> and everyone has to use Google Play Services anyway
This isn't true. You can stick to app repositories like F-Droid and use Raccoon to download Play Store apps via your desktop without using a Google account on your phone.
It is true that you can get Play Store apps without a Google Account, but the Place Services framework does a lot more than this. Many apps rely upon the framework for certain pieces of functionality from Google's libraries.
Many Android apps include the Google Play Services framework in themselves, as they provide extra functionality that is not in the baseline Android API, e.g. a JSON parser.
Nobody builds their Android from source. Nobody uses Cyanogenmod. And nobody runs Android on a phone where the entire stack is open source and blob free.
Not quite, but you can come close. I have Cyanogen installed on all my Android devices and I try to use as little proprietary software as possible. However I am patiently waiting for the Neo900, which is a free (libre) hardware design based on the Nokia N900: https://neo900.org/
According to them, there are unfortunately no baseband modems on the market that can legally have their firmware distributed as free software. Their workaround is to keep the modem as isolated from the CPU/RAM as possible.
> According to them, there are unfortunately no baseband modems on the market that can legally have their firmware distributed as free software.
What is the legal restriction here? (It sounds like you're referring to some restriction beyond simple copyright protection on some of their components - are there FCC regulations regarding the firmware?)
EDIT: Ah, of course, the FCC needs to certify devices before they can actually be used.
>We unfortunately cannot provide free baseband modem firmware, as there is no option available on the market which would be able to fulfil this requirement. Even if it existed, it would bring very little value to the users, as operating a radio device with modified firmware on public networks without recertification is prohibited in most jurisdictions of the world and privacy concerns in cellular networks are mostly related to what happens on the network side, not inside the device.
I don't have any more information than this. If someone can quote specific FCC regulations to back this up, I would find that very interesting :)
> Even if it existed, it would bring very little value to the users, as operating a radio device with modified firmware on public networks without recertification is prohibited in most jurisdictions of the world and privacy concerns in cellular networks are mostly related to what happens on the network side, not inside the device.
Not entirely true, publishing the code isn't the same as allowing its modification. Code signing can be used to limit which versions are allowed to run.
Reproducible builds of the source would allow one to ensure that the binary, certified version of the code their baseband processor is running is legit (i.e. not backdoored). It would also help audit the code and spot security holes.
> Not entirely true, publishing the code isn't the same as allowing its modification. Code signing can be used to limit which versions are allowed to run.
If I can't run my home-compiled versions of your code - whether because of code signing restrictions or because of federal law prohibiting firmware that hasn't been certified - it's not free[0]. So without without reproducible builds, providing the source code for the firmware provides very little benefit (since I have no way to prove that the code corresponds to what's actually running on the device, nor any legal way to install and run it on the device myself.)
Reproducible builds could in theory work, but actually getting builds to be bit-for-bit reproducible is not an easy feat. I'd be very surprised if firmware were capable of this.
[0] This is a great example of why a free software license doesn't necessarily mean that the software is free. It means that the author has waived his/her ability to restrict your freedom to use/modify/distribute the software, but that doesn't mean that third parties (ie, the government, or a patent troll) have done the same.
Not free, but open. I'd argue the latter is significantly more important than the former if you're trying to protect against the code working against you. At least if the code is open, you can inspect it and verify its operation.
That's the current state of affairs. I know of no baseband manufacturer who has ever offered (nor seemed open to the idea of releasing) source for their chips.
Basebands aside, the rest of the device is somewhat feasible to see being open.
Despite the openness of Android/AOSP, there are still, unfortunately, things like binary blobs for certain graphics chips and closed-source firmware for things like Wi-Fi chipsets. Given what we've seen agencies like NSA are capable of (intercepting hardware in transit to apply backdoors, paying off RSA to make Dual EC the default pRNG in their crypto libraries, etc.), them compelling a manufacturer of a component to include a backdoor in their closed-source blobs is no stretch of the imagination.
Apple even has this problem: basebands in cellular modems are notorious for being the source of exploits in otherwise-secure phones.
