Add a GrapheneOS configuration / starter guide?

Hi there :wave:, currently the Operating Systems page lists six operating systems: Android, iOS, Linux, macOS, Qubes OS, and Windows. I think it makes a lot of sense that Qubes OS has its own overview since it brings a lot of unique features to the table, and it’s important for end-users to understand those features to best take advantage of Qubes OS. I also think it makes perfect sense that Privacy Guides be the ones to provide this overview; after all, people come here for accessible privacy tools and advice, so providing an overview plus this helpful community allows Privacy Guides to be a one-stop shop.

With the above being the case, I am of the opinion that Privacy Guides could benefit from a dedicated GrapheneOS overview beyond the existent Android Overview. GrapheneOS brings a lot of powerful features to the table, but for usability reasons, many are disabled by default. These include but are not limited to: exploit protection toggles, user profiles, contact and storage scopes, etc. The goal would be to create something very similar to the iOS overview, which provides a lot of recommended toggles to enable / disable for privacy and security.

At the same time, there is an argument to be made, which I myself have made in the past in similar circumstances, that it is best to go to the official documentation, in this case Features overview | GrapheneOS and Usage guide | GrapheneOS. However, this documentation isn’t as accessible since it’s very information-dense and mostly describes how individual features work rather than providing an overview of how a user might want to set up a fresh device.

I am very interested and open to contributing heavily to this myself, assuming I have the blessing of the Privacy Guides team and community, but I would absolutely welcome anyone who is interested in contributing. Is this something you all think would be helpful?

TL;DR: Would it be appropriate to start working on a GrapheneOS overview separate from the Android overview? Would the community find that helpful? And would anyone here be interested in writing such an overview with me?

edit: I agree that the overview category is perhaps not the best place for this so kindly replace every time I mentioned overview above with the existing GrapheneOS entry. :smile:

4 Likes

If they are configuration recommendations, it would be better off being added to GrapheneOS’s existing entry, in a similar fashion to how browser configuration recommendations are handled here: https://www.privacyguides.org/en/desktop-browsers/#recommended-firefox-configuration

4 Likes

Well actually it depends on what you want to write. If there are just some non-default settings that you think should be enabled then what I said above is true. If you want to write about the features themselves and describe them, and also mention features that exist but don’t require any special configuration, then a knowledge base overview may be more appropriate. Basically if you’re writing about a paragraph or so of information about each feature, I’d say, as opposed to just various line items.

You’ll notice for example the Qubes and iOS overview are mainly talking about privacy/security features that exist rather than merely telling people what to enable.

If we do a knowledge base overview article though, then yes I do worry a bit about us just duplicating their existing documentation, which should be avoided. So we would need to have an idea of how our article would differentiate itself.

Let me know what you think would be the best course of action.

2 Likes

Thanks for explaining the differences between the two. I’m going to take some time to think about it and try to come up with a course of action, and go from there.

I actually have an additional related question, how do tutorial articles play into this? None have been created for a couple years but some exist and are still largely relevant. Would it be appropriate for an recommendation entry to link to a tutorial article (e.g. to allow for a more in depth guide).

Hmmm, I am guessing what you are proposing is something like this?

While we all know GOS work with or without Google Play Services, which then lead to a lot of different configurations or limitations. To serve the purpose of a “starter guide”, we might need to make some tree diagram to help possible users’ decision making process. Purly text base would be quite difficult to read.

Starter guide will also need to address ROM limitations such as lack of Google Pay, unable to pass Integrity test which means many apps will not work, Seedvault backup issues, etc. These are some of the big deal breaker for potential users.

Regarding privacy / security enhancement settings, those are quite simple and straight forward so group policy setting style should be fine. But again, we know some of the enhancements causes app breakage, and the tricky thing is you will need to tell average users about basic troubleshooting. Or we could leave a line like “Might cause app breakage, turn this feature off in app info if it happens”.

lastly, if we are to prepare a starter guide for GOS, we might want to consult GOS team as well, just to avoid possible “issues” from their end.

Since GOS already has most of the documentation, the guide you propose might end up including a big bunch of hyperlinks linking back to GOS’s documentation.

However I think the possible users really should read GOS’s FAQ, starter guide really can’t include that much, plus there’s plenty relevant videos on Youtube, they might end up just watch those instead of crunching another wall of text :rofl:

1 Like

It would be really useful!

I’d suggest an approach like this:

1 Like

I have set up and configured several Pixels with GrapheneOS for nontechnical people. While of course the best approach would be for them to dive deep into the official documentation, IT security and privacy basics, how modern phones work in general and Android specifically, often they are not interested and just want a working phone.
After setting it up for them (Play Services + configuring permissions, wifi+bluetooth location, installing basic apps), they are usually quite happy with it and i don’t need to do much tech support.

However, when i didn’t set this up and they tried on there own, they were quite frustrated, as basics things didn’t work (location takes too long, notifications don’t work, the basics apps are outdated) and wanted to go back to stock Google Android.

So I think a guide for that use case would be really helpful!

Btw: i found such a guide, albeit being a bit outdated and lacking

1 Like

I would not recommend it as the project is constantly evolving and requires staying up-to-date with all of the developments. While you may be fine contributing today who knows what will happen in the future.

GOS offers a number of communities for users to help answer their questions.

You misunderstand here.

Having a starting point a user can use to configure GrapheneOS would be great and of course would be updated to be stayed up to date.
And most things when it comes to it remain unchanged (Iirc most) so we don’t need to use the GrapheneOS community.
Besides the community here have some takes I don’t fully agree with so I wouldn’t recommend it.

1 Like

Yes I understood that the intent is to create a user guide. This has been discussed in GOS communities for a while and one of the team members even thought of developing something similar that would cater to various threat models and use cases.

As far as I can tell, Privacy Guides often tries to make recommendations such that they will work for the majority of users. It is therefore not my goal to make the most agreeable guide, but rather a guide which is the most helpful to the average Privacy Guides user. A tree structure with tens of choices is not what is most helpful for the average user. For example, using the owner profile with the nested profiles is a much more reasonable approach for most people than meticulously relegating social media, banking apps, streaming apps, etc. into separate secondary profiles so that’s likely the recommendation we would make. In such a case (I think) it makes more sense for a user to consult the official documentation / guides that are intended for a more extreme threat model.

What do you all think about Sandboxed Play Services? Currently I think the most logical approach to recommend is to use it in the private space with the apps that require it. The problem becomes notifications with apps like private messengers and email clients which often depend on FCM for push notifications which don’t otherwise depend on GMS. I’d like to know how you fellow GrapheneOS users approach this and what your recommendation would be.

It of course isn’t up to me at the end of the day. Your ideas and feedback are very welcome.