Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave and multiyear commitments from the vendor to firmware security updates (I think 7 years of updates now for the newest Pixels). Those seem to be the big two things that no other Android vendor achieves together.
The GrapheneOS devs are serious about security, probably more focused on it than 99% of end users. That they manage to release a project with the high level of usability that GrapheneOS achieves is impressive, even if it isn't as convenient to the end user as stock Android. Ultimately, nothing will ever be as convenient to the end user as stock Android or iOS, but that's not the point of the project.
> Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave
That's my point, though. The projects security requirements don't need to be that stringent. By all means, take advantage of the hardware security on devices that offer it like pixel, but even on devices without that hardware security it would still be the most secure Android based OS available, and orders of magnitudes more people would benefit from having access to that.
> The projects security requirements don't need to be that stringent.
GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. Have something that is maximally secure within the most aggressive limits of what is possible today.
It targets end users who either have an acute threat model (e.g. journalists, dissidents) or are willing to tolerate some level of inconvenience (compared to stock Android) to gain the security advantages. Not everyone is willing to make that trade-off, and that's okay. I don't want my daily use phone OS to adopt a more permissive security model to appeal to a broader audience. I suspect most GrapheneOS users share that stance.
There are other AOSP custom distributions that benefit from the security improvements GrapheneOS is able to get accepted upstream (though Google is making this more difficult than it used to be). I think, for people who aren't willing to make the trade-off, a better path is to use another AOSP distribution on the hardware they prefer, or to establish a separate project to build a downstream version of GrapheneOS (under a clearly distinct name) for other, less secure hardware... Trying to shadow each release as closely as possible and make best use of Graphene's generally excellent software customizations (e.g. storage scopes, deny network permission, etc) without pursuing a hard fork.
I'd certainly like something similar for NVIDIA Shield Devices, for example. But I know that's not what Graphene's mission is.
The GrapheneOS devs absolutely will not listen to anyone asking them to loosen their security model. And thank goodness they don't! That's why I use GrapheneOS. It's why many do.
>Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available.
Yes.
And the correct course of action is a separate, downstream project with a different name doing exactly that and shadowing the GrapheneOS releases. Not a weakening of the GrapheneOS security model. If you don't want a maximally secure build of AOSP, you don't want GrapheneOS: you want something else. Maybe something substantially similar, but not GrapheneOS.
>They don't though, that's just a nonsense claim.
I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The statement is closer to tautological than it is to nonsensical.
> And the correct course of action is a separate, downstream project
Except that there is explicitly no need for that.
> Not a weakening of the GrapheneOS security model.
There is no weakening for those people like yourself that feel they need the extra security provided by using pixel devices.
> I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements.
The fact that you are claiming a weakening is happening at all is ridiculous. If it was made available for more devices, you, using it on a pixel, would be exactly 0% less secure.
Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
>Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
Do you understand that a security model includes allocation of finite developer resources? How much time a project's developers will spend on each class of problems?
The GrapheneOS developers have chosen a narrow set of devices that meet their hardware requirements, and that narrow list of devices allows also them to focus their resources, tightly integrate software hardening with the functioning of the hardware, and makes the project logistically manageable at all. Each clause in that sentence is part of the security model, not just the hardware requirements.
Have you ever tried to get a new build of something like LineageOS (or, once upon a time, CyanogenMod) running on a new device at all? Each ARM SoC (i.e. almost every smartphone) has numerous bespoke customizations, and its own set of largely binary-blob firmware, and often necessitates per board builds of an OS.
Adding even another half dozen devices is highly nontrivial. If you want it that badly, do the work and port GrapheneOS to those devices. Release your work downstream of the project, and benefit from its security improvements in software. It would be a good, worthy project with its own goal of bringing better security to a broader audience who are only using stock Android. That isn't the GrapheneOS project's goal.
Do you understand the purpose of the GrapheneOS project?
Its developers are in an ongoing cyber-arms-race against companies like Cellebrite and against state-level actors. The extreme hardware requirements (the primary two being Titan chips and multiyear firmware update guarantees from the vendor) are chosen with those adversaries in mind. That's their goal.
You and I are incidental users of the project. We are not its intended user: the person who needs a device that is as secure as possible against focused, well-resourced, state-level adversaries.
My stance is that I'm grateful to have access to a top-tier security tool, free and open source, way beyond my actual needs or threat model. I'm grateful it is so easy to use that the compromise (specific hardware required, 3-5% of apps I try not working) is well worth it. My stance is also that I'm against the broadening of project scope for the convenience of people who, like me, don't actually need this level of security but who, unlike me, are unwilling to make the compromise.
I'm not repeating things I've heard. I've built versions of Cyanogen and Lineage for phones I've owned over the years. I have a good idea of the work involved just getting things running at all, before even approaching the question of security. And all I'm saying is, "if you want support on devices beyond the project's scope that badly, do that work yourself and share it with the community."
> Do you understand that a security model includes allocation of finite developer resources?
You went out of your way to avoid answering the question, so it seems the answer was no.
I don't think you have a clue what you're talking about, and are indeed just repeating things you've heard. I don't see this discussion progressing further because of that, instead devolving into an is-too/is-not back and forth.
Your claim the idea that allowing Graphene on a wider array of devices would somehow weaken it's model remains nonsense, and you certainly can't support it, although if you wanted to make an effort that was more than you just asserting and repeating things, I'd be interested to consider it.
I don't see this discussion progressing either, because you haven't added anything to it, and it's harder and harder to assume you are acting in good faith.
You haven't actually made any specific arguments. Nor refuted any specific arguments I've made. You've just repeated, over and over, everything what I say is nonsense and I must be repeating things I've heard. I'd agree that sort of repetition tends to stall out discourse.
I do hope you end up with (or have already) a smartphone that is secure to your satisfaction, on the hardware that is most convenient to you, whoever ends up doing the work to make that possible. Have a good day also, and best of luck in the search for such a solution.
You're making a claim; I've asked you to support it with more than preaching, and you've been unable to do so. The lack of the discussion progressing is entirely due to that, and nothing more.
> To me it seems like fighting teen pregnancy by preaching abstinence.
More like fighting teen pregnancy by mandating chastity belts... With the same ultimate problems too: those most determined to overcome the block will make use of bolt cutters or their digital equivalent.
Apologies. I misread. Yeah, it sucks that Google Pay doesn't work on GrapheneOS.
Though Google Pay is also probably the least private of the major tech-company payment platforms (the others being Apple Pay, Samsung Pay, and Garmin Pay). It is, I think, the only one that actually requires an open network connection on the phone to work. The others all generate one-time codes that get sent through the payment machine's network for verification by Apple/Samsung/Garmin on the backend (i.e. you can tap an Apple Watch to pay with all its radios off, but you can't do that with Google Pay).
From what I gather, Garmin Pay can work with GrapheneOS if you have one of their smartwatches. And Privacy.com works, but not with tap-to-pay.
As an aside - I think the Paypal app in Germany offers HCE tap-to-pay, and In the UK/Europe 'Curve' is a Google pay replacement that runs fine on GrapheneOS (and they have first-party support for huawei phones that don't even ship Google play services anymore)
> The author has some valid points, but dismissing this entire class of arguments so flippantly is intellectually lazy.
Agree 100%. And generally programmers have a poor understanding of the law, especially common law as it applies in America (the country whose legal system most software licenses have been written to integrate with, especially copyleft principles).
American Common Law is an institution and continuity of practice dating back centuries. Everything written by jurists within that tradition, while highly technical, is nonetheless targeted at human readers who are expected to apply common sense and good faith in reading. Where programmers declare something in law insufficiently specified or technically a loophole, the answer is largely: this was written for humans to interpret using human reason, not for computers to compile using limited, literal algorithms.
Codes of law are not computer code and do not behave like computer code.
And following the latest AI boom, here is what the bust will look like:
1. Corporations and the state use AI models and tools in a collective attempt to obfuscate, diffuse, and avoid accountability. This responsibility two-step is happening now.
2. When bad things happen (e.g. a self-driving car kills someone, predictive algorithms result in discriminatory policy, vibe coding results in data leaks and/or cyberattacks), there will be litigation that follows the bad things.
3. The judges overseeing the litigation will not accept that AI has somehow magically diffused and obfuscated all liability out of existence. They will look at the parties at hand, look at relevant precedents, pick out accountable humans, and fine them or---if the bad is bad enough---throw them in cages.
4. Other companies will then look at the fines and the caged humans, and will roll back their AI tools in a panic while they re-discover the humans they need to make accountable, and in so doing fill those humans back in on all the details they pawned off on AI tools.
The AI tools will survive, but in a role that is circumscribed by human accountability. This is how common law has worked for centuries. Most of the strange technicalities of our legal system are in fact immune reactions to attempts made by humans across the centuries to avoid accountability or exploit the system. The law may not be fast, but it will grow an immune response to AI tools and life will go on.
> It seems like the AI revolution hit as interest rates went insane...
> ...I'm wondering if we would be having the same conversation if money for startups was thrown around (and more jobs were being created for SWEs) the way it was when interest rates were zero.
The end of free money probably has to do with why C-level types are salivating at AI tools as a cheaper potential replacement for some employees, but describing the interest rates returning to nonzero percentages as going insane is really kind of a... wild take?
The period of interest rates at or near zero was a historical anomaly [1]. And that policy clearly resulted in massive, systemic misallocation of investment at global scale.
I'm cautiously optimistic. It's certainly the most realistic business plan their leadership has put forward in a long time.
And a Mozilla/Thunderbird based email service is well timed. Microsoft's upgrade (read: downgrade) of the newest version of Outlook, making it a glorified web app, has pissed of a lot of users who aren't the sort to browse hacker spaces but do have to use serious email and calendaring every day for their work.
Even if those folks don't see Thunderbird as an alternative to what Outlook/Exchange was, it'll absolutely be an alternative to what Microsoft is turning Outlook into... [1][2][3]
And there's something devilishly funny about the fact that, because DDG uses Bing on the backend, when I search for articles to cite... Everything that comes up trashing the new Outlook is from MSN.
Browser engines have become so complex that each ultimately represents a massive attack surface. I think, rather than trying to pick the most secure browser (which may change over time) instead:
* Stick to one browser engine per device as much as possible. Two at the most.
* Isolate installed browser engines as much as possible (i.e. Qubes or mobile operating system levels of sandboxed or virtualized isolation, not just containers or flatpaks for dev-environment tidiness and separation).
* Connect end-user devices with browser engines installed to the Internet only while actively using the Internet.
There's an extension called floccus [1] that can sync bookmarks between numerous different browsers (including both Firefox/Gecko and Chromium/Blink based browsers, mobile and desktop) and plug into a user-controlled NextCloud [2] or Linkwarden [3] instance running on a local homelab server for backups.
However, I try to minimize the number of installed extensions to reduce my own browser fingerprint. As others have replied, Firefox Sync works across most of today's popular downstream shadow-forks of Firefox (as in, forks that shadow the Firefox releases rather than truly forking the code). If you don't want to give Mozilla's enshittified corpse your email (I don't), just use an email service that supports aliases to sign up for Firefox Sync... Which is in any case a good idea generally: no two of your important online accounts should point to the same email, even if behind the scenes the aliases are all routing emails back to you.
The authoritative bullshit isn't what society is running on, it's what society is giving as an excuse for enshittification that enriches interested parties.
Your landlord (I'm guessing based on having seen it before) gets kickbacks from the ISP to force all tenants onto a specific (probably overpriced) Internet plan. The interest in keeping you from configuring your own router is in allowing the ISP's enshittifying further monetization tactics to proceed unopposed. The two big ones I've seen in this kind of setup are:
Using DNS enforced by the router to gather data and place ads on any 404 error.
Sharing their WiFi network that you lease with the ISP's other customers nearby.
I'm not even confident they get kickbacks. They probably just believe that either negotiating service details or providing infrastructure for competitive options would require more work from them. They are probably right about that: I'm not hassling them over it. I'm really not in a good position to anyway. As much as I would like to attribute malice to this behavior, it's most likely to be no more than laziness.
If I moved into a house, I could get 1gbit symmetric from Google Fiber or UTOPIA at half the price. But that doesn't matter because I cannot remotely afford a mortgage.
The real problem is Monopoly. Not the market dominance kind: the no one gets to compete kind. We have it in real estate, where every piece of the market is overvalued so far that very few individual people can meaningfully participate. We have it with ISPs who get to literally own the last mile infrastructure, so their customers can't physically connect to a competitor.
There were large swathes of Americans in those generations who stopped using German publicly because of World Wars One and Two. German was at the time the second most commonly spoken language at home in America. You still see vestiges of it in recorded data about ancestry [1].
I suspect many among them would've largely forgotten a functional knowledge of German by the ends of their lives, even though it was their mother tongue and kitchen table language growing up.
In the heart of Pennsylvania Dutch Country was a town that Bismark that changed its name to Quentin after Quentin Roosevelt died in the Great War (WW I).
The GrapheneOS devs are serious about security, probably more focused on it than 99% of end users. That they manage to release a project with the high level of usability that GrapheneOS achieves is impressive, even if it isn't as convenient to the end user as stock Android. Ultimately, nothing will ever be as convenient to the end user as stock Android or iOS, but that's not the point of the project.
reply