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.