*In terms of privacy, customisation, camera quality, and battery time.
For the longest time I have only used either iPhone or Samsung. I plan on switching to Android for the next phone I get, but I find that Samsung phones are often too big for me and put too much energy on camera quality (I don’t take many photos). I have started to look into brands such as Nokia and Motorola, and I would like to know what you guys think of them. Additionally, do you suggest any other phone brands aside from them? My biggest priorities are privacy and long battery time. Bonus if the phone can run LineageOS (I have excluded Graphene as they are only compatible with Pixel phones).
Thank you for any answers. Cheers!
IDK, seems like it. But that still has nothing to do with the product itself. As long as the product is good and is FOSS, I can look past the people behind it.
That’s a good thing IMO. The more an Android ROM deviates from AOSP, the more difficult maintenance becomes and the more problematic a toxic core contributor is.
That doesn’t match with what I’m reading online. This comparison table lists a number of differences between the various projects, and many of those are important to me. That source claims to not be affiliated with any of the projects (I haven’t done much due diligence though).
I don’t really care if these changes were made by GrapheneOS themselves or pulled in from other projects, the end result is a more interesting product that has a fast response to security updates.
Look at Linux distributions, most aren’t anything more than a set of configuration changes, packaging policies, and maybe a home grown package manager. Yet there are interesting differences between Ubuntu, Debian, Fedora, Arch, openSUSE (my preference), and others. It’s all mostly the same code underneath, just packaged differently. That’s what I want from an Android ROM, a secure, privacy-focused configuration.
It’s not snake oil if the difference between ROMs/OSes are tangible.
I never said I liked him, I said the website has valuable information. I don’t really care who makes the recommendation provided the statements are independently verifiable, and they do a way better job of linking sources than PrivacyTools.
At the end of the day, I’m not blindly trusting anyone’s advice and I’m looking at a variety of sites. I actually disagree with some of the recommendations, especially omissions, but I can usually find those when searching “X vs Y” with two recommendations from their site. Privacy Tools includes some odd suggestions, and it seems like they just throw a bunch of stuff that claims to be privacy-focused without doing much research (or at least they don’t link anything).
That’s not my takeaway, in fact it’s the opposite.
I don’t believe in trusting developers, I believe in a mix of security audits, reproducible builds, eyeballs, code signing, and cryptographic hashes. Developers can be bought, accounts can be hacked, etc, but code can’t. For example, I don’t think Linus Torvalds would intentionally break Linux security, but that’s not why I trust Linux, I trust is because it’s the subject of a lot of security researchers, large organizations, and a team of proven-capable subsystem maintainers. If I trust the developers, they could sneak in a malicious Trojan horse like Ken Thompson mentioned and I’d just roll with it.
As the Russian proverb goes, “trust, but verify.”
Well, you certainly talk about it a lot. Maybe you’re genuine, but that’s kind of irrelevant. I trust technical sources, not personal attacks.
I’m not suggesting you create a wiki at all, I’m saying that having a community effort for a wiki could be valuable. The place for a mod, imo, is to police rule violations (ideally mostly responding to reports, not active policing), and those rules should come from the community they operate in. Issues arise when the police make the rules. Maybe it makes sense for a mod to coordinate that effort, but contributions should come from the community with proper sources and whatnot.
And that’s commendable, I prefer transparency when I can get it.
My issue here is that I think you’re letting your distaste for individuals (however well founded) supercede technical discussions. I think it’s reasonable to put a footnote on the technical discussions noting potential conflicts of interest (e.g. Microsoft’s push for TPM is commendable from a security standpoint, but there are concerns about NSA backdoors, chilling effect on alternative OSes, etc), but not reject projects entirely just because of an association with a distasteful entity. For example, most here don’t trust Google, but that doesn’t mean Chromium-based browsers are automatically bad. Doing so is just poisoning the well. Provide 2-3 points of independently verifiable, technical evidence of BS and that makes a pretty strong case to avoid something.
But that’s my 2c. I absolutely thank you for your efforts and intentions, and I appreciate the transparency. However, that doesn’t necessarily mean I agree with your conclusions, though I could be persuaded with technical arguments. Since you seem to believe GOS is all marketing fluff, perhaps we could start a community initiative (I’m willing to help) to verify claims of various projects. At the end of the day, citations and methodologies should carry the day.
Removed by mod
I read a few of those, and I didn’t see any kind of pressure, just clarifications. And they provided information on not just GrapheneOS, but LineageOS and AOSP.
That’s exactly how I would handle things as well if I was working on a project and someone publishes a comparison table that gets posted a few places.
As for why GrapheneOS is mostly green, I guess there are three explanations:
But it’s also not all green, GrapheneOS gets red for Google Pay compatibility and device support, which are two pretty important categories for many people.
If you know of categories where GrapheneOS doesn’t do well, by all means, suggest them in an issue or open a PR. It’s the best comparison I’ve seen, and seems worthwhile to contribute to.
Well yeah, Linus Torvalds does almost no actual development, but he’s involved in merging patches. That job has value, and the end result is that people trust his branch.
That’s the same way I see GrapheneOS or any Linux distro, it’s just a handful of patches and configurations on top of a common core. AOSP is a high quality OS and there are lots of independent researchers looking at it, so it’s a good base to build on, with the main problem being integration with Google services. Forking it is a huge task, so they should stay as close to AOSP as they can while achieving their goals.
And yeah, if GrapheneOS is an embargo partner, that’s has a lot of value, and I hope other ROMs are able to get that as well. Faster access to patches is a good thing.
Sure, and that would likely be pretty obvious, and can happen to pretty much any project. But the community could easily fork it and move on if that happens. That’s what GrapheneOS did when they split from CopperheadOS, and that’s what’ll happen if GrapheneOS is bought or compromised.
So the real concern isn’t with copyright, but with Trojan Horse inclusions, which is where security researchers come in. GrapheneOS has documented how to audit their changes vs AOSP, and they share code with other projects, which apparently has uncovered more bugs. That sounds pretty responsible to me.
But Chrome is superior to Firefox on mobile in terms of security because Mozilla hasn’t ported many of the security features from the desktop browser. That’s a fact. There’s also an argument that Chrome is more secure on desktop as well, but there are tradeoffs to that.
I don’t see any evidence that Micay prefers closed source code (most of Chrome is open source btw), so I’m not sure where this is coming from.
Well yeah, Fuchsia is incredibly interesting and mikrokernels have fantastic security and isolation properties. If Google can pull it off, it’ll be a really interesting kernel to use.
However, there’s a reason mikrokernels aren’t very popular: they’re kind of difficult to work with. It just so happens that having your drivers in kernel space is incredibly convenient and performant. RedoxOS is another interesting mikrokernels project, and both Windows and macOS’ kernels are moving that direction (both are hybrid kernels).
So it’s only natural for him to be excited by it, I’m excited too. I don’t like Google much, but their FOSS R&D side is really interesting. I don’t know if he’s a “fanboy” (I haven’t bothered to do more than a cursory read of the links you’ve provided), but that’s only relevant if it impacts his security choices (e.g. trusts Google with user data “for security”).
Sane defaults has a ton of value. Most people don’t know how to configure an OS to be secure.
It’s not the only option obviously, that’s just stupid dogmatism, but it is a good option, and perhaps the best option out of the box. There are also security features that Pixels have that other phones either don’t or lock away from users, so GrapheneOS can have even better defaults than others due to the hardware it’s limited to (e.g. the open bootloader). Whether that matters to you depends on what you’re looking for.
So I’ll agree that dogmatism should be policed, but ideally with reminders and not comment removals. Maybe have a three strikes policy or something if you’re worried about repeat, intentional offenders.
I’m guessing most phones are, or at least compromised by the NSA. The NSA’s job is to maintain backdoors to go after national security threats, so there’s no reason to expect any default configuration to protect you.
Projects like GrapheneOS try to protect you as much as they can, but at the end of the day, anything that touches a network is going to risk.
That’s why I’m so excited about Linux phones, the Pinephone and Librem 5 both have hardware kill switches for times when you’re worried about surveillance.
Yet Snowing allegedly recommends GrapheneOS. Unless you think Micay is bullying Snowdon as well…
That said, I don’t put a ton of stock into what Snowdon has to say. He’s not a security expert, he’s just a contractor who got away with government documents. He’s careful, but fairly average.
Sure, that’s going to happen because they’re a big target. That said, it’s unlikely to impact regular users because those attacks are quite sophisticated and often caught by security researchers pretty quickly. The Android market is more sketchy because there’s so much more diversity to the point where security researchers are going to miss a lot.
Regardless, staying up to date on security patches is the best line of defense, and sandboxing everything is the next line. GrapheneOS provides both.
Ok, you lost me here. What they’re providing is security by layers (sandboxing, reducing attack surface by having less stuff running, etc) and rapid security updates from upstream.
The proper solution is to completely open source the telephony stack, but that’s not happening for any phone (though the Pinephone community is reverse-engineering theirs, so that’s cool).
Removed by mod
I read or skimmed each of your links each time. I’d quote from them, but it’s incredibly annoying since that particular link is an image and the others are massive walls of text (that mostly attack the character of individuals, not technical work).
I’ll quote one particular part that relates to what I’m talking about:
You seem to do the opposite. I agree those people suck, but I don’t agree that implies their work sucks.
Out of the box means what you get right after installing the ROM. It’s the set of defaults. Like on a Linux distro, it’s the firewall configuration, default apps, memory allocator, etc.
It’s still not going to get you everything GrapheneOS, DivestOS, or CalyxOS provide. A firewall isn’t going to protect you from an app accessing files it shouldn’t, memory exploits from an attacker, or fingerprinting with your MAC and IP address.
Custom ROMs provide a level of protection that users messing with permissions and firewall settings won’t get. Here’s how I see it, using the Pareto principle:
As you go further down that list, you get more painful tradeoffs. So you need to decide how far down that list you want to go.
I think GrapheneOS has the best trade-off of usability vs security and privacy, but everyone is different. For some people, even LineageOS has too many tradeoffs.
I don’t see how that’s relevant at all. Linux was incredibly insecure, had very liked hardware support, etc until others joined. These days, most code comes from manufacturers building drivers or large tech companies (like RedHat) driving subsystem development (BTRFS, systemd, etc).
These days, the value of a Linux distro has very little to do with the developers (people who write code) and everything to do with the maintainers (people who build, test, and publish packages).
Yeah, cost.
I don’t know the requirements, but I know there’s a trust system there. If you break the embargo and release early, that gives attackers who didn’t know about the vulnerability a window to attack participating projects (i.e. the rest of the Android ecosystem) before the embargo is lifted. Here’s an example of OpenBSD getting in trouble for patching before the embargo was lifted.
Perhaps those other projects just don’t have the manpower, organization, or funds to get a partnership. Partnering with Google on security embargoes likely has no impact to the privacy of a given project’s users, it merely has expectations on the participant.
Tor cares more about privacy and anonymity than security, and Firefox likely provides a stronger base for that. But security is another issue entirely.
After a brief review of that linked Tor page, here’s what I saw:
Here’s DivestOS’s take, which ships Gecko-based Mull on why Android Chrome has superior security. The big one is per-site process isolation:
That said, I agree with DivestOS devs here:
I also care more about per-site data isolation:
It’s a trade-off between security and privacy, and Chrome arguably has better security, while Firefox arguably has better privacy. Both are quite secure, so I prefer Firefox.
That’s not a security or privacy issue, and is essentially the same across custom ROM vendors.
He’s neither. He was a contractor for the NSA who had way more access than he needed (NSA fail), and was under less scrutiny vs full time employees. I think he largely got lucky and only got away once. I’ve read both his account and an alternative perspective and that’s my assessment.
I think he has valuable things to say (and should be protected as a whistleblower), but I do verify what he says.
From your link (edit to post concerning the OpenCamera alternative):
OpenCamera doesn’t have as good of quality as either the system camera or Pixel Camera included in GrapheneOS (both seem to be based on upstream code).
My guess is that this shutter sound issue is from upstream, and likely only takes effect in Japan. It’s a miss for sure, but the GrapheneOS docs make it clear that the goal is to have the same features as the original camera, but with some privacy and security features on top (stripping of metadata, fewer permissions, etc).
But you really shouldn’t be using the built-in camera anyway for OPSec, there’s too much risk of OTA updates, metadata (tons of sensors), etc. There are smaller cameras if you need something discrete, and OpenCamera may be good enough for even sensitive uses.
That said, good example of a miss by GrapheneOS, I’m interested in any more you might have. That’s an odd one I wouldn’t have thought of (I rarely use my camera).
This is an unfair comparison imo. Android gives users and apps a lot more system features, so the attack surface is much larger. I’d have to look at the report, but it’s probably counting all costs across vendors as well, which have a lot of different hardware.
I’d be interested in narrowing it to just Pixels (or any other phone line) vs iPhones. That’s a bit more charitable toward Android since Pixels aren’t nearly as popular as iPhones, but it’s at least fair from a number of supported models standpoint.
Both are sketchy. Apple is sketchy because it’s closed, Android is sketchy because it’s run by an ad firm and tons of data is run through Google’s servers (notifications, Play services, etc).
I’d much prefer a Linux phone (Pinephone Pro ideally) to Android, but usability counts too, and Linux phones just aren’t there yet.
Every phone has proprietary hardware they won’t open up, the most important of which is the modem. Even Linux phones have this issue.
So I have to ask myself what Google gets out of screwing me with their security chip. It doesn’t help them get more ad revenue, and if there’s a breach, it could scare customers away from using their hardware. So I don’t see any special motivations for Google to compromise this and other phone vendors not to. Google surely doesn’t need the NSA’s money either.
If you’ll look, you’ll find Google getting into hardware security tokens (Titan), offering FIDO U2F on their products, etc. They want more people trusting their security so they can collect more interesting data, so it’s more likely for them to fingerprint through things like Play services (to serve more relevant app recommendations) than to compromise security.
That said, if you know of a provably more secure device, I’m so ears.
That’s a good question for the other custom Android projects. I’m guessing they haven’t put in the effort needed or don’t have the infrastructure to comply with whatever Google needs to include them.
I’ll have to ask their maintainers.