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.

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!

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

Replying to

You skipped over what I actually talked about a chose to make misleading claims and spin instead. You respond to what I said about MAC randomization ignoring that the point was it doesn't work by itself. Not sure how you expect to port hardware security in software either.

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

Replying to

and

I only cherry picked Mac randomization. IOMMU and lack of secure boot can't be solved on librem/pinephone. That is clear. I am just trying to find the least bad path given very limited time. If Pixel 4 is a sign of things to come... AOSP deblobbing is only going to get harder.

Show replies

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

Replying to

and

I am not interested in causing harm. In fact I truly hope to be proven wrong and enough people find the time to do blob-free AOSP without ending up generations behind. My experiences with the Pixel 4 were a huge time sink and pretty discouraging. I may get try again.

Replying to

and

Blob-free AOSP doesn't need to be created. It existed already. AOSP runs on real hardware using entirely open drivers. You're painting an issue with mainstream mobile devices as an AOSP issue when the drivers (both open and closed) aren't different for AOSP vs. other OS families.