Conversation

Months ago my phone died and now I need 1+ man-week to de-backdoor my new Pixel 4. Being mostly phoneless warms me up to a simple device that respects my rights out of the box. Continuing phone detox until I get a Pinephone or Librem 5. I'm done funding #SurveillanceCapitalism twitter.com/ashk4n/status/

This Tweet is unavailable.

This Tweet is from a suspended account. Learn more

Replying to

and

Neither of the devices is open hardware and neither has open firmware, despite misconceptions created by misleading marketing. The Librem 5 is deliberately locked down to prevent updating the firmware. Neither is close to the security requirements for official GrapheneOS support.

Replying to

See grapheneos.org/faq#device-sup for an overview of device support including the requirements for official support. We can't provide official support for insecure devices with vulnerabilities that can't be patched. Similarly, the hardware needs to provide the standard hardware-based

Replying to

security features including the hardware-backed keystores used by the OS and apps, support for real verified boot and attestation, modern mitigations, proper IOMMU integration / setup for the components, hardware key derivation support, Wi-Fi anonymity beyond just MAC rand, etc.

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

But to get all those you also have to trust yet another closed stack of components and piles of privileged binary blobs you have to sort through tediously on every single new device. All current options suck in very different ways.

Replying to

and

The Librem 5 and Pinephone are closed hardware with closed firmware. The complexity in the entirely closed source SoC and other hardware components / firmware completely dwarfs the complexity in userspace libraries. You're also grouping things that are open source in with blobs.

6:20 AM · Apr 15, 2020Twitter Web App

Replying to

You think wpa_supplicant and all of the other largely open source code in vendor is closed source? Lack of interest from people in building code from source let alone replacing the closed source components (many of which have working open source alternatives already) says a lot.

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

I never thought wpa_supplicant etc was closed. After going through the actually closed blobs in the pixel 4 I realize they just keep adding more and more. It is a very time consuming task and so far no one has the time. I truly hope that changes. You are the closest of anyone.

Show replies

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

Yeah most of the vendor blobs can be compiled from open code. With a ton of work AOSP can be made tolerable but as it is major corners are cut due to lack of cycles. All Pixel devices are closed hardware too. Mac address rand and some security/privacy features can be ported.

Replying to

and

You're misrepresenting this as something to do with AOSP when it has to do with the hardware. AOSP runs on hardware using entirely open drivers already. Pixel 3 can largely be supported using open drivers: linaro.org/blog/dragonboa. You're just more interested in causing harm.

linaro.org

DragonBoard 845c in AOSP

In this article, John Stultz takes a detailed look at the DragonBoard 845c in AOSP (Android Open Source Project). Read about his findings here!

Show replies