New entry: the-problem-with-grapheneos

1 files changed, 30 insertions, 0 deletions

diff --git a/content/entry/the-problem-with-grapheneos.md b/content/entry/the-problem-with-grapheneos.md
new file mode 100644
index 0000000..532d3a0
--- /dev/null
+++ b/content/entry/the-problem-with-grapheneos.md
@@ -0,0 +1,30 @@
+---
+title: "The Problem With GrapheneOS"
+date: 2023-07-06T00:00:00
+draft: false
+---
+[GrapheneOS](https://grapheneos.org) offers far more privacy and security than the Googled vendor-and-carrier-modified versions of Android that most Android users have. This would still be true even if people continued using the same proprietary apps after transitioning to GrapheneOS. For that reason, I don't want this entry to discourage anyone using who already has a Pixel from flashing GrapheneOS.
+
+However, I think the way GrapheneOS is marketed is potentially harmful. GrapheneOS is marketed as private and secure despite it only supporting devices with proprietary firmware and blobs.
+
+"But isn't proprietary firmware a problem with all custom Android roms? Why pick on GrapheneOS?"
+
+Yes it's a problem for all custom Android roms, but I'm picking on GrapheneOS in particular for several reasons:
+
+* It runs *exclusively* on devices with proprietary firmware
+* Its website reaches many in the privacy/security community
+* Its website emphasizes its privacy and security more than any other custom Android rom
+* Its website documents how proprietary components are used to "increase" device security
+* Its website fails to acknowledge that the proprietary firmware that GrapheneOS-supporting phones run is a risk to privacy and security
+
+In my opinion, calling your operating system (OS) "private and secure" while not acknowledging the risk of the proprietary blobs required to run it is misleading. It's one thing if your OS can also run on open hardware or the proprietary firmware it requires is very limited, but it's another thing entirely when your OS only runs on very closed hardware. Free software, privacy, and security go hand in hand. You can't just ignore hundreds of megabytes of unauditable proprietary blobs that run at boot time and still pretend it's a secure device just because you have hardened malloc.
+
+Also, there's another problem with the proprietary firmware which GrapheneOS doesn't sufficiently address in my opinion. Since GrapheneOS requires up-to-date proprietary firmware to support devices, it's entirely dependent on [OEMs](https://www.wikipedia.org/wiki/Original_equipment_manufacturer "Original Equipment Manufacturer") to update that firmware. But it's in the OEM's economic self-interest to stop providing support as soon as they're not legally obligated to.
+
+Why is this GrapheneOS' problem? Well if privacy-conscious people are promoting GrapheneOS, some might purchase new Pixel phones to keep up with GrapheneOS' releases. This funnels more money into proprietary hardware, perpetuating the cycle of endless e-waste rather than funding open hardware, which is less wasteful and clearly the right direction for privacy and security. GrapheneOS could warn people against buying new Pixel phones just to install their OS and instead suggest supporting open hardware.
+
+As for the privacy/security aspect, what I'd like to see on GrapheneOS' website is something like what [Replicant](https://www.replicant.us), another Android fork, has. Replicant has a [lengthy article](https://www.replicant.us/freedom-privacy-security-issues.php "Mobile Freedom, Privacy, and Security Issues") detailing how the proprietary firmware and blobs plaguing modern smartphones threaten mobile privacy and security in the general case and specifically for Replicant-supported devices. It shows that the developers clearly understand [the problem](https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor "Replicant developers find and close Samsung Galaxy backdoor") with proprietary firmware.
+
+In conclusion, GrapheneOS should include a page like Replicant's on their site detailing the potential dangers of the proprietary firmware on their supported devices and encouraging people to purchase maximally open hardware alternatives if possible.
+
+Finally, I know I've used the terms "firmware" and "blobs" interchangeably even though they're not interchangeable. I don't think it affects the point I'm making, but I'm not an expert in this topic. So I'm happy to take criticism from someone who knows more and make corrections or clarifications if necessary.