Conversation

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

You're misinterpreting what I've said. The fact is that the ROM community at large has little interest in meeting basic security standards in terms of securing their builds, signing keys and not rolling back the standard security model / features. It's the opposite of helpful.

Replying to

AOSP is better before they mess with it. The work they do isn't useful for privacy and security. It's harmful, especially with how they choose to be dishonest about the security patches they're shipping. Most are aware they aren't providing what they claim. It's not a mistake.

Replying to

AOSP can easily run on any devices launched with Android 8+ not just Pixels. However, even among the ones offering decent security, that doesn't necessarily apply to using an alternative OS. I'm not aware of another phone supporting standard security features for an alternate OS.

Replying to

I can't list a single other option other than a Nexus 5X / 6P (which are nearly end-of-life) or a Pixel where hardware security features are not unnecessarily restricted to the stock operating system, and most have lackluster support for it going beyond security.

Replying to

If you don't want to use iOS or stock Android with Google services, the only decently secure option is using AOSP on a Pixel phone. That's the reality. I won't support using insecure devices and I have little / no interest in making an OS losing security compared to the stock OS.

Replying to

There are phones that would be viable targets if they decided to properly support alternative operating systems including making the basic hardware-based security features work. I'm not aware of a single alternative doing that. It's beyond them just missing some fancier security.

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

A fork of AOSP isn't AOSP. I mean AOSP itself with github.com/anestisb/andro for device support. I'm not aware of anyone releasing production AOSP builds signed with release keys, so you would need to build from source and deal with securing keys, etc. on your own.

github.com

GitHub - anestisb/android-prepare-vendor: Set of scripts to automate AOSP compatible vendor blobs...

Set of scripts to automate AOSP compatible vendor blobs generation from factory images - GitHub - anestisb/android-prepare-vendor: Set of scripts to automate AOSP compatible vendor blobs generation...

Replying to

I wouldn't recommend using releases from some random anonymous person on the internet even if there were any available. If people want that, they'll need to fund the work and infrastructure. It would be one small part of what would be required to make a hardened mobile OS again.

Daniel Micay

@DanielMicay

Replying to

@DanielMicay

And as I've said, I'm going to be doing privacy and security work, not maintaining an OS. I want to make a hardened mobile OS, but doing that requires a team to share the maintenance burden, even if I'm the one doing the vast majority of the privacy and security hardening work.

8:44 PM · Nov 2, 2018Twitter Web Client

Replying to

It takes a huge time investment to run the full CTS and VTS over and over again and investigate every failing test case to determine if it's a problem caused or uncovered by the hardening features, followed by fixing many upstream bugs that are uncovered by mitigations.

Replying to

This kind of project isn't something reasonable for one person, and one person attempting to do it means a massive workload that eliminates nearly any time that could have been spent on privacy/security hardening. I can't do the real work if I do that... so I won't do it alone.

Show replies