Practical GrapheneOS for the Paranoid [Guide]

Privacy
1

Amazing resource that compiled all common questions that people ask about GrapheneOS that are hard to find, instead of searching through their official twitter account or forum.

3 Likes
2

Thanks, looks like a good overall guide.

1 Like
3

Wow, such a detailed guide. Thanks for sharing.

off-topic rambling

I really dislike the paranoid term being used here and in similar resources. It implies that privacy is for the paranoid. Most of us are just trying to protect our right of being able to to choose what we share, when, for how long, with whom, and for which purpose. I don’t think it’s a crazy thought or goal. It’s not about hiding, or about thinking that someone is out to get us.

3 Likes
4

Agreed, and I don’t think that’s off-topic at all. This guide is more harmful than good with all the misinformation it is spreading. Beyond that it also doesn’t actually contribute anything, with large parts just parroting GrapheneOS but making their claims sound like baseless allegations.

2 Likes
5

Do you mind expanding on this? I haven’t gone through the guide myself but it may be useful, especially for users of GOS, if you could point out some examples of what you mean.

6

While I don’t think most people will need to enable the features available in GrapheneOS, I do think it gives a good explanation of features available so that users can make the informed decision on whether or not they want to enable them

1 Like
7

Of course.

  • As @quitet.gear pointed out, the title isn’t productive and also isn’t representative of the article which doesn’t discuss any ‘extreme’ measures.
  • Calls out GrapheneOS for sacrificing “convenience and usability” which is entirely false, it is just as convenient and usable as stock, and arguably more so than bloated OEM skins.
  • Statements like “According to GrapheneOS there currently simply isn’t another reasonable choice [other than Pixel devices].” Presenting it in this way makes it sound like more of a political stance from the project. An article that added value could make this assertion themselves and provide the evidence to back it up (which could include statements from GrapheneOS). I basically feel like a lot of what this article does is repeat what the GrapheneOS project has said, but often losing important nuance and details when paraphrasing them.
  • “The GrapheneOS team has announced that 2-factor fingerprint unlocking will be launching soon where unlocking the device will require both a fingerprint scan and the PIN/password.” This is incorrect, it will be possible to use a fingerprint + pin but not fingerprint + password which wouldn’t take much sense since the main unlock method will presumably be a secure password anyways
  • “If you have an eSIM or especially a physical SIM, it makes sense to configure a SIM PIN - though it should preferably be a different one than the one used for unlocking.” This is true but some justification would be nice, it goes back to my point that at least personally I don’t think this is much of a guide and I don’t think it adds anything that reading through the GrapheneOS twitter wouldn’t.
  • There are a lot of minor things which are honestly kind of nit-picks but it’s also a big reason why it’s much better to rely on the official documentation and channels from GrapheneOS.
    • “The GrapheneOS project maintains a list of detailed requirements” This is false, the list is clearly stated to be non-exhaustive.
    • “These partnerships fell through, in the end it was simply easier for these OEMs to make money by producing questionable hardware wallets for cryptocurrencies.” I don’t see how this is relevant to a supposed guide on configuring GrapheneOS but again reading the original tweet would yield more accurate information. Regardless both OEMs failed with their crypto projects and afaik at least one went out of business

Additional attack surface reduction and security can’t hurt, GrapheneOS defaults could be much stricter with minimal breakage. I would encourage users to enable all exploit protection toggles and work backwards from there for the few apps which may experience serious breakage or crashes.

I agree that there is a need for robust guides on GrapheneOS, I just don’t think this is it. I was probably a little harsh with my initial criticism but I still think it gets more things wrong than going straight to the source with GrapheneOS tweets. I also disagree with calling it a guide and I will probably make my own guide or submit a pr to have one added to Privacy Guides in the near future if that’s something y’all think people would be interested in.

8 Likes
8

The problem is that apps can seem to function just fine, and then at some moment you really need them to not crash, they do crash. I wish there was some list of apps and the corresponding exploit protection setting that can be safely used. And ideally GOS could even apply setting automatically based on such database. Afaik something like this might already exist but not to the extent I’m describing.

9

Memory tagging, Native code debugging, DCL via memory and DCL via storage all show notifications when an app tried to use those blocked features. GrapheneOS also makes crash logs and general logs very accessible so you can easily submit issues to the developers. From my perspective and experience this is really a non-issue.

2 Likes
10

Yes it’s fine once you know that they don’t support the exploit protection setting and you just disable it, my point was that there are features in apps that are rarely used that may trigger the crash and you have no way of knowing until that happens. May also not even be related to any feature, the crash may just happen seemingly randomly at some point. This is far beyond what most people would be willing to put up with.

11

So when the crash happens you know why. And then change the setting that caused it. :thinking:
I havent had any issues I could not find right away with the exploit protections.
Some work very good withouf any issues.
DCL via Storage and Memory are special and need trying. But once you care enough to try you’ll find out what works where and what doesnt.

Its just that most people running GrapheneOS already do though :thinking:
Running GrapheneOS is such a plesant expierience in my opinion.
Almost like stock.
This “almost” requires the user to care though. Not everything is going to be like stock.
But if you run GrapheneOS you already are not the “average Joe” anyway.
My suggestion is to run as is and get used to it instead of trying to change it to suit one self.
This energy can be used to read the documentation, and/or find out what works and what doesnt :slight_smile:

12

I prefer GrapheneOS over stock, honestly.

Even disconsidering the privacy and security side.

Never liked bloatware.

3 Likes
13

Ah, sadly I didn’t see this until now. Thank you for the feedback!

  • It’s an unfortunate reality that titles need to be catchy or nobody will care about your article these days. Remember that, compared to the other content of my blog, I wrote this article specifically so that I can share it with my non-technical friends - and from their perspective these measures are certainly “paranoid” enough.
  • Same about the convenience aspect - there might not be a convenience issue to you, but there will be one eg. for my parents.
  • I absolutely agree that it would be best for everyone to “simply go through the tweets themselves” - but very few are going to do that - the information is scattered among a enormous amount of tweets which takes days to go through. The article explicitly states that its aim is to tie up the information in a singular place - it never claims to contribute anything significantly new to the conversation.

TL;DR This article was not written for experienced, well informed and highly technical GrapheneOS users, but intents to build a bridge such that less technical users can benefit from what it has to offer too.

I’ll try to make some improvements to the other things you mentioned to make them clearer and hopefully less misleading. Cheers

5 Likes
14

I appreciate you being so open to feedback. I do recognise that I’m probably not the target audience for your guide, I’ll try to keep that in mind in the future.

1 Like
15

Very cool guide, it is nice to read and well researched and put together!

Just some small thoughts I had while reading:

  • Are you sure the work profile allows apps to communicate with apps in the main profile? I thought it didn’t.
  • “Private spaces have (…) better user interface integration with the Owner profile [than a work profile].” This is unfortunately not true in my opinion. For example:
    (1) The private space require you to authenticate yourself again (with PIN or fingerprint) every time you start an app installed in it after unlocking the screen.
    (2) Likewise, the notifications are locked (just app name but no content) after unlocking your screen without opening an app in the private space.
    (3) If you want to use biometrics in apps (e.g. banking apps) you need to set up separate biometrics for the private space because otherwise the app won’t offer you to use biometrics. You can set up the same finger as the main profile but you need to set it up separately for the private space (at least this is how it was when the private space feature dropped, maybe it got fixed since).
    (4) You can’t have a shortcut to an app in the private space on the homescreen. All these work fine in a work profile though, so I’d say the work profile has a much better integration with the owner profile.
  • Keyboards: You mention Florisboard, I think AnySoftKeyboard and Heliboard are also good examples for FOSS keyboards with swipe typing and multi-language capabilities. Also FUTO Keyboard though it’s not actually free software.
  • Android Auto works in a work profile, and maybe also in a private space now (it didn’t when the private space feature first appeared but I think they wanted to fix that). I definitely had it working in a work profile and could connect it to my car.
  • “Note that you can always create a non-identifiable account with a burner phone number in the official Play Store instead of using Aurora’s rather unreliable anonymous account feature.” Unfortunately most countries don’t allow you to get a burner number (all SIMs are tied to government ID). Instead, it would be good to know a reliable way to create a Google account without giving them a phone number. My experience was that it worked when creating it in the Play Store app on GOS (in my case with no VPN/Tor but with SIM inserted) - I could skip the phone number step - and then immediately afterwards setting up TOTP 2FA to avoid them asking for a phone number for “security” reasons later on.