Sailfish OS: Clarifying claims about open/closed source, security and privacy

@Zilvinas, it would be very tedious to reply point by point to the very inaccurate (and bad faith) opinions you quote from the GrapheneOS forum. Instead, I will just reply on my take on SFOS security.

GrapheneOS certainly has built a very secure OS, and according to leaks, one that resists Cellebrite, a tool used by police and secret services of certain countries to hack into nearly every Android phone. However, unless you have a specific reason to fear the police, for example you are a journalist or human rights activist working in difficult countries, security against tools used by secret services shouldn’t be your focus.

SFOS on the other side is:

  • A nearly standard Linux distro. Your data should be just as secure as on any Linux computer.

  • A hackable phone. I guess GrapheneOS is also hackable, but by being a Linux distro, SFOS is much more convenient at least if you have previous knowledge of GNU/Linux systems.

  • A Linux phone that includes an Android emulator. (I don’t use it.) SFOS can only be worse than GrapheneOS at this respect, since GrapheneOS includes the actual Android code and closely follows its evolutions. I read on the forum that SFOS AppSupport has limitations for example I think bluetooth is sub-optimal, and some apps might refuse to launch. You know better what your priority is. As the whole point of SFOS is staying away from Android, I expect most users to only require a very small number of Android apps e.g. public transport, bank, and not install random free games.

  • A phone that doesn’t send pings or leaks connection metadata to Google and other tech companies. That is, unless you voluntarily install apps e.g. you want Whatsapp or Facebook or a Microsoft mail access or something like that.

  • A phone that where your data isn’t on any cloud services from Google or Microsoft or other big tech companies (unless you install some app from them). Your call and message history, pictures, videos, and backups, are on your phone, your SD card or on a Nextcloud instance (that you could run at home on your own computers or rented from a provider of your choice). To the contrary on Android phones, most people happily synchronise their communication and application data with Google.

In terms of security:

  • Just as good as any Linux computer; remote untargeted attacks are unlikely to be tuned for this kind of system.

Limitations in terms of security:

  • The browser is unfortunately lacking far behind (Firefox ESR 91 as we speak, hoping to get ESR 102 in next update, and there are still rendering issues Jolla employees are fighting with). Likely, old vulnerabilities exist.

  • Updates are not super frequent, so unpatched vulnerabilities in the overall system are also likely to exist, like in any Linux machine (or Windows or Mac for that matter) that you don’t update on a daily basis.

Regarding encryption:

  • You are free to set a PIN that is 20 characters with letters and symbols and have unbeatable encryption even by secret services. I guess few people do that because it’s not convenient when you need to type it to unlock the phone. You could use a very strong password in combination with the fingerprint reader for quick unlock, but the fingerprint reader is susceptible to police or traffickers compelling you to press your finger on the sensor.
  • You can and should encrypt your external SD card using a complex password, and you only need to type the password of the SD card after a reboot.

On Xperia phones: the bootloader cannot be locked; a recovery mode is available. An attacker with physical access to the phone can boot in recovery mode, extract a copy of the encrypted partition (where your SMS and call history and application data reside) and brute-force attack the encryption on an external computer. Which is typically immediate to crack as the encryption is tied to the PIN lock code and most people use a 6-digit PIN with only 10 million combinations. There is an unofficial modification by @rinigus for some phone models that enables to set a complex encryption password together with a simpler lock pin, that can mitigate this problem.

It all depends on your threat model. If you fear the police, you need a very strong password and must not configure the fingerprint sensor. If you fear pickpockets stealing your phone, you need a moderately strong password, but you can use the fingerprint reader. If you fear remote attackers, you can use simpler PIN, but you should (as always) be careful which website you visit and which Android apps you install. You are only as secure as the apps you install; prefer f-droid (FOSS repository) when possible, and install only vital applications from highly trusted sources such as your government and your bank.

Considering the new Jolla Phone:

  • It has yet to be known if a recovery mode is available; if no recovery mode exists (contrary to Xperias but similarly to the C2), then the “extract partition” vulnerability to crack the password does not exist.
  • You can configure the privacy switch to turn off the Android apps for when you don’t need them, minimising data leaks. Say, you can use Whatsapp when you need it and make totally sure it only communicates with Meta when needed and does not spy on your other activities in the meantime.

What data leaks to Jolla: (guessing)

  • your name and address if you buy from them;
  • the contents of your posts on this forum;
  • a ping from your phone if the update verification is activated in the settings;
  • which apps you have installed from the Jolla store.

Edits: addressing the case of the SD card encryption; correction of AppSupport according to comments by @unmaintained; encryption system by @rinigus; what data leaks to Jolla

32 Likes