so for boring reasons I have to replace my phone and got a Pixel 3, and what this phone really is is a powerful advertisement for the Pixel 1, which it isn't noticeably better than, in any way that matters to me
Conversation
Replying to
I am not looking forward to October when security updates stop for the P1. Debating whether ill attempt to backport fixes or just get something new. Hard to justify $800 for a phone that I use solely for Gmaps and random internet browsing.
2
1
3
do you have anything supporting Pixel1 still?
2
1
It's a much different kind of project. It doesn't have OS privacy and security improvements and isn't working on developing those. It only uses my update app, not any of the past or current OS hardening work. It's a set of scripts for building AOSP like github.com/dan-v/rattlesn.
1
Both of these projects say that they're inspired by my work, but neither is shipping or developing privacy/security improvements, which is pretty much the entirety of my work. I find it misleading to draw the comparison to it or claim to be a successor to it when it's just AOSP.
1
3
I also never stopped working on it, and my work on it began before Copperhead existed. The fact that I don't have official GrapheneOS builds for the Pixel 1 doesn't mean that someone else can't build it, they just need to deal with building a custom kernel, vboot 1 and getrandom.
1
There are probably memory corruption bugs that get uncovered already and need to be worked around / fixed over time, but that's also the case for the Pixel 2 and Pixel 3. It's an inherent part of supporting each device. The libc, kernel and compiler-based hardening uncovers bugs.
Other than using a hardened allocator, features tending to uncover lots of latent bugs occurring during regular use (not fuzzing) included -fsanitize=bounds,object-size (in trapping mode) and dynamic overflow checks for system calls. helped resolve some of these.
1
1
Type-based CFI and integer overflow checking too, but I moved to letting them expand coverage for those upstream. Downstream XOR-based canaries and automatic local variable init were very easy to deploy across the entire kernel and userspace since they don't uncover any bugs.