Grapheneos didn’t support pass keys last year when I checked, so you couldn’t use them at all. There was some APIs broken/missing between the OS to browser comms so you couldn’t use 3rd party apps for pass keys, like proton or bit warden. I have been actively experimenting and adopting passkeys and didn’t want to revert. It sounds like there is support now though, so I will give it a try soon.

Thank you! Idk why I was down voted, I appreciate it. I did a bunch of research on grapheneos last year around this time and it wasn’t supported yet.

What a fucking useless comment

Schools even have Cellebrite devices now, that is how prolific they have become. GrapheneOS has a duress password to wipe the phone and you can block all data or even power to the USB port while the phone is running. If you blocked all power to the USB port while the phone is on the only way to charge it is if it is fully turned off putting your encrypted data at rest. You can just disable data on the USB port options menu in GrapheneOS if you don’t want to completely turn off the whole port.

You probably already know this stuff I was just mentioning it for people reading this comment section. :)

In my country, it’s the law that a cop is allowed to examine a phone during a traffic stop.

One underrated feature of the Graphene OS is that you can set a duress PIN that wipes your entire phone when entered.

As well as all the other security features offered by Pixels, like the Titan M2 secure element, which securely stores encryption keys and makes brute-force attacks basically impossible.

Other OSs let you lock the bootloader too. I know that iodéOS and CalyxOS do, for example.

@RubberElectrons @multi_regime_enjoyer its not actually fully open source, it uses a lot of closed-source libraries, and its not as battle-tested as google’s official one so there really isn’t a reason to use it

but why run it at all?

Because it is unfortunately required by some apps. microG is not a viable alternative, as it requires root access on the device, which drastically reduces the security. It also has worse compatibility than Sandboxed Play services, and doesn’t offer much of a benefit. It still downloads and executes proprietary Google blobs in the background in order to function. Apps that require Google services also include a proprietary Google library, making microG essentially useless. It’s an open source layer that sits between a proprietary library and a proprietary network service, using proprietary binaries and requiring root access. You gain absolutely nothing from using it, and significantly increases the attack surface of your device.

fully open source emulator

This is simply false, as I explained, only a tiny bit of what microG requires to function is open source

You’re far better off using Sandboxed Play services on GrapheneOS

Calyx doesn’t actually support Google Play Services or Google Services Framework. It uses microG, a sometimes buggy workaround that requires root access and has pretty poor compatibility. GrapheneOS on the other hand uses the official Google Play binaries, but isolates them in the Android application sandbox, instead of installing them as system apps with special privileges (like it is the case on stock Android). You can read more about it at https://grapheneos.org/features#sandboxed-google-play

You’re right that it’s pure speculation just based on technical possibilities and I hope you’re right to think it should be dismissed.

But with the way microchip design (it wouldn’t be at the PCB level, it would be hidden inside the SoC) and manufacturing work, I think it’s possible for a small number of people to make this happen, maybe even a single technical actor on the right team. Chips are typically designed with a lot of diagnostic circuitry that could be used to access arbitrary data on the chip, where the only secret part is, say, a bridge from the cell signal to that diagnostic bus. The rest would be designed and validated by teams thinking it’s perfectly normal (and it is, other than leaving an open pathway to it).

Then if you have access to arbitrary registers or memory on the chip, you can use that to write arbitrary firmware for one of the many microprocessors on the SoC (which isn’t just the main CPU cores someone might notice has woken up and is running code that came from nowhere), and then write to its program counter to make it run that code, which can then do whatever that MP is capable of.

I don’t think it would be feasible for mass surveillance, because that would take infrastructure that would require a team that understands what’s going on to build, run, and maintain.

But it could be used for smaller scale surveillance, like targeted at specific individuals.

But yeah, this is just speculation based on what’s technically possible and the only reason I’m giving it serious thought is because I once thought that it was technically possible for apps to listen in on your mic, feed it into a text to speech algorithm, and send it back home, hidden among other normal packets, but they probably aren’t doing it. But then I’d hear so many stories about uncanny ads that pop up about a discussion in the presence of the phone and more recently it came out that FB was doing that. So I wouldn’t put it past them to actually do something like this.

Right, like I said I’ve seen the reasoning. It just seems like giving money to the very company you’re all trying to avoid, which in turn is just funding for Google to be more invasive.

I will admit that I also use Shizuku, but I only enable it for short bursts when I need access for a very select number of precise use cases. Immediately afterwards, I reboot.

I also assume that if I spent any amount of time digging into it, I would realize it’s a bad idea, but nothing’s perfect.

And don’t assume that all apps allowing Shizuku access were developed securely, or that there all developers have good intentions. Really I only use it for Swift, or if I’m really behind on my updates, I’ll briefly allow Droidify access for hands off updating.

out of interest, what use cases do you have in mind that require root access?

I used to use a root based solution to block ads system wide via hosts but now I just use ublock origin in Firefox.

Spot on.

I’ve been arguing this many times with many people, and everybody seems to adopt their own way of interpreting things to suit their preferences.

Here’s my line of thinking:

• If the first buyer buys a Google cellphone new for, say, $500 (no idea of the price, just making it up for the sake of explaining), this buyer gives $500 to Google
• If I then buy this cellphone second-hand for, say, $300, the original buyer gets $300 back, meaning Google now has $300 of my money.

That’s a hard no.

Of course, there’s the argument that Google got $500 no matter what and they don’t know who the money is from. But that’s besides the point: I know Google got my money. I most defintely parted with $300 to acquire a Google cellphome, meaning as far as I’m concerned, I indirectly gave Google $300 of my money. And I refuse to give Google any money, however indirect the transaction might be. The only way I could become the owner of a Google phone is if someone gave one to me, I found it in the trash or I stole it.

There’s also the argument that if I don’t buy the cellphone, it might end up in a landfill, so if I’m environmentally-minded, I should save it from the landfill. That’s true, but my counter-argument to this is that a healthy second-hand market for Google phones gives them more value, therefore makes them more appealing to potential buyers and ultimately supports Google’s business.

I don’t like serviceable stuff being landfilled for no good reason (otherwise I wouldn’t pay extra to buy a Fairphone) but in the case of Google hardware, I reckon it should end up at the landfill as often as possible to diminish its value and hurt Google. Of course, I’m only one meaningless guy, but I reckon boycotting Google is a moral duty for anybody who’s concerned about privacy and civil liberties.

And of course, I don’t want a Google product in my pocket because it would make me nauseous. But that’s entirely subjective.

1. Applies to every phone, smart or simple, can be combatted with a £5 Faraday bag
2. That is about monitoring by your network, nothing to do with the phone manufacturer really
3. A ten year old article about Samsung phones
4. An exploit affecting lots of phones that seems like it was fixed

So a few interesting points, but nothing even slightly like what OP was suggesting.

In my experience, no. Since Google doesn’t apply any battery optimizations in their stock OS, apart from those already present in AOSP, it makes sense that battery life is essentially the same in GrapheneOS.