Yeah Graphene really do not like competition. I’m not sure they fear competition as such, but they are very aware that they want as many users using their OS as opposed to alternatives. So they basically bash the competition to try and make themselves look better.
However, I believe it makes them look like twats, especially considering that the open source community is often quite supportive (or is that wishful thinking?). I’m sure its a great project, but I wouldn’t support projects that bad mouth others.
They don’t seem to realise that other projects don’t have the same aims as their own.
12 Likes
I do think Graphene is interesting, but their obsession with shit-stirring on their social media has made me never want to try it honestly.
However they’ve always been relatively dodgy; I remember Daniel Micay (was that his name? the lead developer guy until a few years ago) was caught blackmailing Louis Rossmann. Daniel, in the process of trying to dismiss valid criticism, decided it was a good move to demolish his own reputation.
They need to drop the antagonistic approach. It’s unprofessional and makes them look extremely arrogant.
10 Likes
That’s one of the things that pushed me over the edge to not even want to try that OS.
4 Likes
The aggressive language here isn’t @Zilvinas ‘s fault. This series of posts came from the official GrapheneOS account on Mastodon in response to something I posted about how great SFOS is. It was a surprisingly aggressive response and ran through multiple posts. I’ll put a link to my post below which then includes the text that @Zilvinas describes above.
I decided to swing by the forums to ask about this as well- - less a question of “is this true?” and more along the lines of, what is going on with the GrapheneOS folks that would make them respond in such a way? Is there some bad blood here between them and Jolla that I didn’t know about?
It doesn’t exactly make me confident recommending their products to my followers who are looking for data sovereign solutions…
9 Likes
Oh hey @kea they tried to bait you too? Glad i’m not alone … although wtf is going on with these people?
2 Likes
@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
30 Likes
This is a great summary, thank you @moripeluka 
I have also heard concerns about the use of Android in the OS itself, including but not limited to the emulator. I’ve had people confidently explain to me that SFOS is all Android under the hood, and others declare that it emphatically isn’t and so isn’t secure … I doubt either of these characteristics are accurate but what does this group know about the role of Android in SFOS?
4 Likes
Not all, but most of the devices SFOS runs on were designed to run Android.
Consequently, the core Software components to access the hardware, kernel drivers, firmware blobs, and some associated programs (services/daemons) are only available in a form that supports an Android environment.
In order to run these, and be able to run a standard Linux userspace on top of them, something called libhybris was created. This is a translation layer between the core Android world around the hardware bits, and the rest of userspace.
SailfishOS does not intrinsically require to be run on top of hybris, it can run on regular Linux if that supports all the hardware bits, but in practice most ports do need it.
So you have an “Android-like core”, based on something like AOSP or Lineage at the base, supplying Kernel, firmware, devicetree, and some binary userspace programs to interface with that.
Still the OS is not Android. Most of what makes Android Android is not there.
Does not follow. Why would something running Android imply that it is secure? Why would not running Android make it insecure?
7 Likes
And by the way this is exactly where the claims of Android being Open Source fall apart.
HW vendors supply the bits required to run their products only in binary, closed-source form, and those binaries require the Andoid libc etc.
Often (almost always), the kernel drivers they supply may be open source, but only support a very specific and heavily patched Linux kernel.
This makes updating the Kernel hard to impossible.
This is a property of the Android ecosystem which basically furthers and requires fragmentation and forks on the kernel level for each vendor and device family.
5 Likes
Please don’t see this as criticism because you clearly stated you don’t use App Support but I would like to say it’s the other way round, the vast majority of Android apps I tested happily run on Sailfish without issues.
11 Likes
I modified the message to reflect your comments.
Could someone comment if the “extract partition” method works on the C2?I wrote it works on the Xperia phones due to the bootloader locking question, but maybe this is a more more general vulnerability that also exists on the C2 and the Jolla Phone?
2 Likes
I’ve had exactly the same experience. They just get triggered when one points out that GrapheneOS is an Android and not an alternative to iOS or Android.
I still like GrapheneOS and use it on my backup phone. There’s a reason there’s a global smear campaign going on against them and that’s because it is one of the most secure OSs available that is hard to crack, even physically.
That is something that SFOS is far from, but they cannot get it through their skulls that people have other reasons for running SFOS than device security. SFOS offers security from the global surveillance capitalistic system. It challenges the status quo of Apple and Google and US Big Tech. That’s something GrapheneOS does not (nor does running Chrome which is loved by cybersecurity ‘professionals’).
There’s one main guy that was the main GrapheneOS dev that started it all and he had some trauma from doxing and swatting, so I forgive him 
Also @cyberlyra I think GrapheneOS is also bearing the brunt of (successful) smear campaigns against them to make them look bad, both by state actors and competitors. (They’re certainly not helping themselves by how they’re acting on social media though.)
10 Likes
And instead of looking for allies they try to antagonize as many people as possible, what a great strategy 
8 Likes
Thanks. I have tried to explain this but usually get confidently rebuffed. It’s like they assume I couldn’t possibly know anything about an OS I have used and a community I’ve been a part of for over a decade. Sheesh.
Hopefully the new Jolla phone will eliminate the requirement for such a layer at the ‘android-like core.’
2 Likes
What are you referring to? You mean breaking the on-disk encryption by brute-forcing the key/PIN?
That will work on any device where you can dd some bytes off a partition.
1 Like
The question was probably if it will be possible to extract the partition from the phone, not if it’s possible to crack the encryption once you have obtained a partition image.
What really grinds my gears is when android devs baptize their android custom roms “OSes”.
Build your own OS, your own hardware, and then talk. Period.
14 Likes
Yes I am referring to the dd trick from here: How to: Unlock the encryption of your /home if you don't know your lock code (Bruteforce)
It is possible because SFOS lets users enter fastboot mode and gives a shell with tools like dd to exfiltrate information. My question is whether there is a connection to the booloader locking question; and whether it is doable on Android phones.
1 Like
If you use community encryption solution, as on some unofficial ports, extracting partition will not help you much - LUKS key is based on PIN and TEE backed hardware key. As a result, even short PIN makes brute force impractical, as far as it was estimated.
4 Likes