iustitia

As usually, I think Privacy Guides provides a good baseline for this question:

https://www.privacyguides.org/en/real-time-communication/

TLDR: They recommend Signal, SimpleX Chat and Briar. They also mention Element and Session, but with a warning.

There are only two options I'd add:

Molly
https://molly.im/

hardened version of Signal

Cwtch
https://cwtch.im/

decentralized and focused on metadata-privacy in addition to communications privacy

Further Links

Molly – Privacy Guides Forum:
https://discuss.privacyguides.net/t/recommend-molly-instead-of-signal/17597

Molly – GrapheneOS Discussion Forum:
https://discuss.grapheneos.org/d/8976-signal-vs-molly-vs-molly-foss

Molly – GrapheneOS X:
https://x.com/GrapheneOS/status/1769277147569443309

Cwtch – Privacy Guides Forum:
https://discuss.privacyguides.net/t/cwtch-instant-messenger/11953

This post has given me inspiration for future projects, so first of all thank you:) I'm thinking about offering to install GrapheneOS for people in my region who aren't confident they can do so themselves. I might include buying the phone anonymously and initially guiding them into a secure & working setup if they want. I'd like this to be very accessible, so at most I'd accept voluntary donations and give 50 % to the project.

Of course, this would require strict security. This being a non-profit service and me not being rich, what would be the least expensive setup for this?

Under no circumstances would I want to expose the people coming to me for help to greater risk than required. Although I'm not Ed, I don't have a completely average threat model and neither would some of them. I'd need to ensure reasonably well that an infection of (some of) my devices couldn't spread unnoticed.

Albatross That's interesting, and I definitely see your point. Do you think there's anything that Qubes does better, excluding cases of "I just have to use a desktop"? Are there important security or privacy features not currently available for GrapheneOS, for which Qubes or any x64 platform might be worth using?

Much has been said about the increased security that mobile OS like Android and iOS offer over desktop OS. They are designed from the ground up for a hostile environment, which makes them much better suited for the reality we're facing now. I'll refrain from repeating what others have already expressed better than I could here; for example in this video by THO.

Now, mobile OS are more secure than desktop ones, and GrapheneOS is the most secure mobile OS, so Graphene wins, case closed? Not quite, at least not obviously so. Of course, the security of a system depends partly on how it is used. A user knowledgeable enough about these systems and their threat model might be able to design a relatively secure overall concept even when using relatively insecure tools to do so. But this is always true and doesn't say much about which OS should actually be used. In my opinion, the only real challenger for GrapheneOS to the crown of most secure OS, seems to be Qubes OS.

First, I think it makes sense to say that for many people, Qubes OS is simply not suited. GrapheneOS provides the absolutely luxurious option of using something that's as easy as Stock Android, and even very inexperienced users can switch relatively easily. Qubes OS doesn't have that option, especially if you use it in the way it needs to be for its security to really shine – by heavily compartmentalizing. For most, I'd recommend GrapheneOS in a heartbeat because it's extremely unlikely they will a) actually use Qubes and b) use it in a way that even has the potential of beating GrapheneOS. However, the question of which provides better security for a user who utilizes the OS in a way making use of its potential (within realistic bounds), remains valid. Or, if the strengths and weaknesses of the two are different enough to make such an "overall" security assessment nonsensical: Which OS has which advantages, what are its go-to use cases?

Something that seems obvious to me, is that GOS will generally be way more secure than a Qubes VM. If you use Qubes with one VM in which you always do everything, I doubt your security will be that much improved over whichever OS you use inside that VM, which will be less secure than GOS. Qubes strength lies in its use of compartmentalization between different VMs with different levels of trust, that can be erased and created on demand. This means that even though it might be easier to break into a VM on Qubes, that will not necessarily get you far. To truly compromise the system, there needs to be a way for the attacker to infect other VMs, or even the Xen hypervisor itself. Doing so will be much more difficult.

However, GrapheneOS provides options for compartmentalization itself: User profiles. They are a useful tool in general, but can also be utilized at least somewhat similar to how Qubes uses its VMs. With different profiles with different level of sensitivity or different application scopes, the attack surface can be decreased for each while giving an attacker more hurdles to overcome. This can also be extremely useful when there's a threat of physical attackers grabbing your phone, as not-running profiles will be encrypted. Installing apps into the owner profile also enables quick creation of a fresh user profile with (for example) nothing more than Tor Browser installed additionally, that can easily be deleted again after use.

I elaborated on my thoughts quite a bit, but please don't confuse this with giving an answer. I hope I was able to identify some general themes or maybe provide some base for complete beginners, but evaluating and comparing the exact level of security is far beyond what I can do on my own. For example, would it generally be more difficult for an attacker to a) on GOS break into a user profile, infect it and spread to other profiles or b) on Qubes break into an untrusted VM, infect it, and spread to other more trusted VMs? I have no idea, and I'm not even sure there's a definite answer – how do you even objectively measure difficulty?

To be fully transparent, I think most of the time, Qubes just isn't an alternative to GrapheneOS, and that's okay. What they focus on achieving is quite different, even though both have security as one of their main goals. Still, I think this question is interesting to ponder and provides great grounds to learn about what makes both of them secure, which in turn increases knowledge of security in general. So, for security, science, or maybe just for fun:

Which is the most secure, Qubes OS or GrapheneOS?

GrapheneOS

Thanks for clearing that up. It did strike me as somewhat contradictory to the usage guide.

GrapheneOS Portraying this as something specific to Google apps is incorrect.

My question was specifically about Google, but it wasn't my intention to portray Googles abilities as special. To my understanding, the only difference to most apps would be the Play Store having permission to install apps, but this wouldn't be any different for Accrescent or F-Droid. Whether this permission opens up an additional way to gain information about installed apps (even from other sources), I don't know.

GrapheneOS Apps can see the other apps installed in the same profile, and if two apps within a profile agree to it they can communicate with each other.

Okay, so my assumption was correct here. Would an app that's disabled inside a user profile still be visible for other apps inside the same user profile?

Could you please share some thoughts on installing all apps through the owner profile but thus being able to only grant first-party-downloads permission to all user profiles? I'm aware there isn't a blanket answer. Still, someone with a great overview sharing their opinion about both sides of the trade-off (threat of linkability, identifiability vs. improved security) could be very helpful. My struggle comes down to the difficulty of assigning an exact value to the up- and downsides here because even with a clear threat model in mind, it's hard (but crucial) to always take all relevant factors into account.

GrapheneOS GrapheneOS has a planned App Communication Scopes feature

You just can't help pushing the boundaries further and further, can you? :D

LegroomPolicy

If the user desires to install apps from sources besides the Play Store, it would probably be best to do so inside the owner profile. The apps should not be granted the network permission during install, can then be disabled and installed into the user profiles they're going to be used in.

Without going into detail, my opinion for which source should be used is Accrescent, otherwise Obtainium, otherwise F-Droid Basic. Aurora Store isn't reliable in my experience and doesn't provide a clear benefit over the Play Store in this setup. Obtainium should also only be used if updating the specific app works reliably, which might not always work with all sources.

N1b

N1b If I'm not mistaken most apps that require Play Services (of benefit from them) need them present upon installation, otherwise they won't work.

That's an important detail to avoid confusing beginners. Maybe it makes sense to test this for a few basic apps (Tor Browser, Orbot, Signal, etc.) to give users an idea beforehand.

N1b use the owner profile entirely for app installation and updates

Congratulations, you found my exact setup!:) I think it's quite elegant and very well suited for beginners without compromising on security. Combined with auto-reboot, which imo is essential for activists anyway, I have high hopes that even new users will be able to follow an update routine somewhat reliably.

My main concern is indeed the potential for fingerprinting leading to linkability, non-repudiation and identifiability risks from Google. The likelihood and severity of this is doubtful, but I want to at least fully explore it and make sure there really are no ways around this.

N1b For these people it's important to be aware of much more than their smartphone OS, but it's of course a good start.

I fully agree. In the beginning I'm forced to focus on the essentials because my resources in both time and money are very limited, and meeting a very high-quality standard in one way or another consumes lots of both. However, I'll try to ensure organic growth is possible from there on, so I can slowly increase the scope while keeping all existing content up to date.

And nice recommendation, I'll definitely include many links to relevant sources, and THO will surely come up regularly. Love his content!

N1b These are all suggestions and probably nitpicks

Don't worry about that! I believe anyone putting out advice on security and privacy in general, but if targeted towards vulnerable groups like activists in particular, has a responsibility to ensure it's of high quality. Now maybe I'm just an anon user posting in some forum, but once I do put out these guides, the personal safety of my potential readers will depend in part on me being correct and not misleading anyone, even accidentally. I do have my methods for this, but external critique or suggestions are invaluable and always appreciated, nitpicks included.

Thank you a lot for your kind words. Hearing this occasionally really helps <3

A GrapheneOS device can be utilized in a large variety of ways. An important part of this is the basic configuration, which should act as a solid foundation for secure and private usage. Yet, choosing the best option for yourself can be challenging, especially for new users.

In this post, I will show you an approach to this, explain the reasoning behind it and guide you through some parts of the setup.

I might use this as the foundation for a guide in a future project of mine, so your thoughts on the content as well as the style of the text are hugely appreciated.

Goals & Priorities

When deciding on device configuration, it makes sense to set specific goals and ideally work out a threat model beforehand. This helps by giving us a clear focus and prioritization, which we can then make decisions upon. I'll keep this very short here for the sake of brevity and universality, but keep in mind that your requirements might differ. That said, the approach we'll follow won't be a downright catastrophe in most cases, it just might not be optimal.

Our goal will be to choose a setup for our device that provides a good base for further usage. We want to be able to protect all data on the device and prevent threat actors from linking any info they get to our personal identity. When in question, we're going to prioritize security over privacy.

The setup should work well with compartmentalization and using different user profiles for different activities. It should be flexible to allow for profiles adapted to their purpose, while minimizing the chance that a compromised profile can be used to compromise the whole device. There should be a secure way of installing apps, reliably offering timely updates. Which apps we install and the actual usage of them are outside our scope.

Google Play Services

There are many valid approaches that don't require Google Play Services at all. At first glance, they might seem fundamentally preferable, as even with the sandboxing from GrapheneOS, Google is still an additional, in many ways malicious, party. All else being equal, avoiding Google would be preferable. In practice, there are clear benefits, like improved push message functionality, FIDO2 support, and access to the Google Play Store.

For our scope, the last one is especially important: Currently the Play Store provides superior security to F-Droid, better reliability than Aurora Store or Obtainium, and much greater app variety than Accrescent. It is also one of the most simple and certainly the most beginner-friendly option. Its biggest drawback is easily the privacy threat, especially because a Google account is required to use it.

Here, we will go with installing Sandboxed Google Play and using the Play Store as our method to download and update apps. The reasons for this are its security benefits and usability advantages, which trump the privacy concerns in accordance with the goals we set in the beginning.

Mitigating the Privacy Threat

The decision in favor of the Play Store might be in line with our goals, but the concessions in privacy we are forced to make might still leave some feeling unsatisfied. Google is a considerable threat to privacy, especially in the realms of linkability, identifiability and non-repudiation. However, we are far from powerless and will not simply accept defeat without a fight.

Google can be assumed to collect as much info as it can, but through its sandboxed implementation, its access is limited. The GrapheneOS Usage Guide summarizes it well:

Since the Google Play apps are simply regular apps on GrapheneOS, you install them within a specific user or work profile and they're only available within that profile. Only apps within the same profile can use it and they need to explicitly choose to use it. It works the same way as any other app and has no special capabilities. As with any other app, it can't access data of other apps and requires explicit user consent to gain access to profile data or the standard permissions. Apps within the same profile can communicate with mutual consent and it's no different for sandboxed Google Play.

This enables us to block Google from accessing most data it would be able to collect on another OS. We are going to use Google only where necessary, namely the Play Store, and restrict its permissions as much as possible without breaking the functionality we require. We will also be using a trusted VPN or Orbot with a killswitch in all user profiles with Sandboxed Google Play installed, to prevent being identified because of our IP address.

Something we can't shield from Google in this setup is data about which apps we have installed. As a highly unique identifier, this can allow Google to fingerprint and identify us. Our counter against this is splitting our usage into multiple user profiles. Google isn't able to link multiple instances of Play Services from different user profiles on a device, and will thus only ever know part of all the apps we use. This isn't perfect, but if enough activities are split off to specific user profiles, app-fingerprinting should become much less of a threat, if not impossible.

Anonymous Google accounts

To prevent Google linking data from different places to reveal our identity, any Google account should exclusively be used for one purpose. This means, for every user profile from which we want to download apps, we are going to use a new Google account. It should be created inside the profile in which is then used. If the linked user profile is deleted, they should not be reused and can be deleted as well.

All of this is of limited worth if we hand Google our identity on a silver plate during account creation. Luckily, we can avoid doing so.

To begin, we will install a trusted VPN or Orbot either through the owner profile, or by downloading and installing the .apk file directly through Vanadium. It's important to make sure the download is coming from the official website or GitHub page. After it is done, the permission to install apps can be removed from Vanadium again, and the VPN should be connected with killswitch enabled. It is crucial that the killswitch remain active at all times that an internet connection is possible to continually mask our real IP.

Now, Google Play Services can be installed through the official GrapheneOS app repository. After it is finished, we can open the Play Store and create a new Google account. It is likely that SMS verification will be required. While some have found success by connecting to a VPN server from certain regions that might give you an option to skip it, this method doesn't work reliably. If you can't skip SMS verification, the easiest option will likely be to use a burner phone number. I successfully tested this with JuicySMS, but you can also pick a different service; KYCnot.me provides a good overview. For any other inputs that can't be skipped, use fake but realistic info.

The actual configuration

We have decided on the Play Store to download apps, and we know how to minimize Googles privacy invasiveness by using Sandboxed Google Play and anonymous Google accounts. Now we just need to put all of this into a specific configuration.

Most importantly, almost all usage should take place in different user profiles, each with a specific purpose. Permission to run in the background and access to phone & SMS should be given out restrictively. The owner profile should only be used for administrative purposes.

Play Services should at least be installed in the owner profile, as this enables the option to install apps from the owner directly into a user profile. If all apps inside a user profile are installed this way, this means that the permission to install apps can be withdrawn for that profile, and that Play Services aren't needed there. Meanwhile in the owner profile, unused apps can be disabled without impeding updates or functionality inside other profiles. This can benefit security, privacy and usability, if still used sparingly to avoid fingerprinting the owner profile through the apps.

Final Thoughts

I hope you found this helpful or interesting! As I touched on in the beginning, this is V1 of something I might use in a future project of mine, addressed mostly towards beginners. Apart from general feedback and your thoughts surrounding the contents of the post, I'd like your opinion on a specific consideration:

In the last paragraph, I touched on the idea of using the owner profile for downloading & updating apps to then distribute them into user profiles. In principle, I find this to be quite elegant, but the more it is done, the higher the risk of fingerprinting being used as a unique identifier. At a certain point, it seems to become a question of weighing the added security of having user profiles without the permission to install non-first-party-apps against the lost privacy from a more unique fingerprint. What's better depends on individual priorities, but I struggle to really assign a "value" to both of them, especially how big of a security improvement this enables. So, please share your evaluation of this if you have a more profound understanding of the factors!

Again, thank you all <3

TrustExecutor Wow, didn't know that! That's great. Does it work only with the clock in the owner profile, or all of them? Any how does it even work?

If it's a wishlist...

• A kind of quick setup for User Profiles. My idea would be to use GrapheneOS somewhat similar to Qubes, regularly setting up new Profiles for very limited tasks and deleting them afterwards. This is already possible, but could be made easier. For example, there could be multiple default profile types you can select to automatically have the settings configured like this.
• Another hurdle currently is that while you can install apps into new User Profiles from the Owner profile, this doesn't do much if you have a setup where you pretty much don't use the owner profile at all and don't actually have any apps installed in it.
• In fantasy land, where you have unlimited capacity, I'd love for you to provide more apps in "Apps". In practice, Obtainium and Accrescent projects are looking quite promising and F-Droid seems to also head into a better direction, so it would probably be a waste.
• Dark/black/more beautiful themes/UI for the keyboard, calculator, clock, maybe more
• A very very basic GOS notes app that's there by default
• Security Keys as MFA for User Profiles
• A way to avoid being fingerprinted through your background (question: does this currently only affect the home background, or is the lock screen a problem as well?)
• And finally, a more extensive wiki/way of sharing knowledge with further scope. I consider the GOS team as some of the most knowledgeable people (surprise) on many infosec questions. GOS as a tool for targetted people that need the safety it provides might benefit everyone a lot by sharing more knowledge. Something like an official Blog that now and then comments on current events or provides easily accessible insight into what's being worked on, might be good. Communication generally could, imo, be improved upon.

I want to add that this is not in any way to be understood as criticism. Graphene is an incredible product and its achievments are the reason expectations are that big:) Also, maybe those things don't make sense, I'm not a dev, pls don't judge me too hard:D