Is this really true? The Mullvad report a year or so ago was that they didn’t want to turn on no exceptions mode because it breaks network connectivity until reboot if you don’t pause it when updating the app, not that the feature doesn’t exist. They also recently shipped it anyway, opt in and behind a warning.
MacOS has had instances where their own apps could bypass always-on VPN. I'm not sure if there have been exploits or gaps where traffic could go to arbitrary destinations directly.
this is not an ocassional bug this is still the system design today. privacy gateways upstream of big tech are the way to go on this because privacy isn't their profit center
Terminology like "private" and "trust" differ in meaning from computer land to human convention.
It's a concern to me, because humans often extend their trust to computer trust based upon misunderstanding of the identically spelled words and lack of recognition of differing context.
The technical detail that makes this egregious is that the leak happens in system_server, a privileged process. Android’s
own lockdown mode explicitly promises that no traffic bypasses the VPN. When the system itself sends the packet over the physical interface, that promise is broken at the kernel level, not in userspace. Calling this “not security bulletin class” is hard to defend.
VPNs, at least originally, were designed to provide access to private/business networks across another network. Office to office, home to office, that sort of thing. VPNs were only later turned into some kind of (supposed) security tool.
If your take on VPN code is "as long as your phone can reach the office printer over 5G" then this is a tiny bug. QUIC connections aren't being shut down properly, like they weren't before the introduction of the feature.
If your take on VPN code is "this wireguard tunnel must keep my identity safe no matter what" or "my security relies on this wireguard tunnel being an exact copy of all traffic exchanged over the internet" then this is a massive problem.
I don't think Android VPNs, or any VPN to be honest, were ever designed as a privacy or security measure. Especially not against apps with code execution on the device. The device itself will do all kinds of network interactions, some happening from within the modem chip itself.
Closing the bug was a mistake on Google's part, but I can see why they don't consider this a security bug in their bug bounty programme.
First motorola grapheneos phone i am buying to get fully off the google pain train. Grapheneos tides me over until a real linux smart phone shows up or i die of old age. Now if home assistant could get thread network join*ng working without an android phone with a google account i could ve fully ris of those eh holes.
Yeah requires a free Bluetooth radio and has a bit of setup, but in my opinion, it's well worth it to not be reliant on Android or iPhone, which has always given me problems.
And typically security is very bad, no good sandboxing, MAC (through e.g. SELinux), etc. I know that doesn't matter to everyone, but in the context of a discussion about GrapheneOS it does.
That's debatable. Pretty much every generation of the Pixel phones have had some major issues. They've even had to do multiple extended repair/replace programs due to some of them. Heck there is even an ongoing issue where one of their updates has caused multiple generations of their devices to be bricked (and that still hasn't been fixed) - https://www.androidauthority.com/google-pixel-march-update-b...
On a technical level, yea, it may be great hardware but in practice, I don't think it is. As an Android user, I wish it were but it's not. Samsung is so much more reliable as an end user (even with their own issues).
Motorola devices with GrapheneOS support will arrive in 2027 or later, not 2026. Likely, the 2027 Signature, Razr fold, and Razr flip, will meet GOSs hardware security requirements.
Carrier-sold Pixels generally don't have "OEM-unlockable" bootloaders.
Your best bet for now is to buy a new Pixel direct from Google, or a used one from eBay that the seller advertises as already having GrapheneOS on it (or otherwise guarantees that the bootloader is unlockable). These ones are worth a lot more than the ones that can only run Google/carrier Android.
I own two GrapheneOS Pixel 7 units, which should get any Google blob security updates (which GrapheneOS incorporates) through October 2027, and GrapheneOS may still support it with source updates after that. So in a year or so, I might get the GrapheneOS Motorola if it's available, or a later Pixel. (I never buy these new, since I don't want to carry a several hundred dollar phone when a 2 gen old one is still great, thanks to GrapheneOS.)
OEM/carrier locking tends to only happen in the US. Many carriers permit unlocking after the contract has concluded, but Verizon has always blocked it. Used devices also run the risk of being improperly unlocked and making OEM unlocking remain unavailable. (Used devices may also be Verizon devices.)
Is this true for all carriers? Or just Verizon? Several Reddit threads say that it's just Verizon. T-Mobile users report being able to bootloader unlock after getting their phones carrier unlocked by T-Mobile.
OEM/carrier locking tends to only happen in the US. Many carriers permit unlocking after the contract has concluded, but Verizon has always blocked it. Used devices also run the risk of being improperly unlocked and making OEM unlocking remain unavailable. (Used devices may also be Verizon devices.)
I finally left Verizon after nearly 20 years. I had it with their enshittification, couldn't stand it anymore. I switched to US Mobile and on the Darkstar (AT&T) network. I have no regrets. I caught it on a black friday deal, so I'm paying basically $20/mo for top tier service. You wouldn't have caught me dead with an AT&T service or MVNO years ago because I'd seen so many bad experiences second-hand, but these days it's been a breeze knock on wood
I also did the math and determined buying a new unlocked phone outright on this plan was far cheaper than paying Verizon monthly for one.
+1 for US Mobile. Verizon was also good, but a few months ago my cofounder and I discovered we were absurdly overpaying for our decade-old small business plan and found that US Mobile offered a better end product for a fraction of the price.
Currently running my Pixel on Warp (Verizon) with zero practical difference, and starting Monday I'll also have a backup iPhone with a small $8/mo Darkstar line. The money I've saved since switching more or less paid for the iPhone, and I'll be getting 2x reliability for way less ongoing cost. The better app/website/support and extra features are just a bonus.
Yep, Pixels for them are entry points to Google One subscriptions, etc. The Pixel 9a is currently 350 Euro in my country, it has the same CPU/GPU (modem differs) that the expensive 9 Pro/Pro XL/Pro Fold had. Factoring in development costs, etc. at that price I cannot imagine it being more than break-even.
Also, even Pixel 9a has all the security functions of the flagship that many other Android phones do not have or are just getting, such as the Memory Tagging Extension (MTE), the Titan M2 security processor (no need to rely on TrustZone for secrets), etc.
I don't see a problem with supporting their legitimate hardware or cloud business models. But of course I see a problem supporting their illegitimate adware and spyware business models.
At some point digital security turns into physical security, and there are national security interests that have fine-tuned their detection logic on these kinds of "buggy" behavior.
If you patch it, you'd need to find another way to de-anonymize those users.
The issue reported on lowlevel.fun [0] and discussed on GrapheneOS forums [1] does seem like a security issue. It isn't clear why engineers in charge would mark it infeasible as the breach demonstrates more than one failure.
1. A new (albeit "hidden" [2]) network API registerQuicConnectionClosePayload(fd, payload) lets a process set any byte array for the OS to send on its behalf.
2. No ("panaroid networking") permission checks against the calling uid/process when sending that byte array out on a OS-owned UDP socket.
3. Bypassing ("panaroid android") permission checks [3] by simply calling network-related syscalls (or libc/bionic functions) as opposed to Android SDK APIs.
These steps essentially amount to app sandbox escape (2,3) and privilege escalation (1,2). I am utterly confused why the Android security team at Google won't take this more seriously.
[2] In as much the code mmap'd into your own process can be "hidden" away. For their exploit though, the author cleverly abuses Binder IPC primitives to reach the "hidden" parts.
[3] This bypass probably only works for this one scenario because of #2.
I bought a used Pixel 6 for cheap to try out grapheneos. Can't say I like it. UX of lineageos is much better. There is a weird russian doll kind of situation with the package managers going on. There is one builtin "App Store" with only a few basis programs, one of which is another package manager, accrescent, which offers a few more apps, but still not comprehensive at all, so another package manager is needed for which grapheneos people seem to favor obtainium over f-droid, which I find is another strange decision. I much prefer a fully OSS package manager and there is real value in having people compile from the sources externally, maybe even reproducibly so, instead of trusting the github packages. The grapheneos security model seems oddly centralized to me. I can't really comment on the reported privacy and security benefits.
> so another package manager is needed for which grapheneos people seem to favor obtainium over f-droid, which I find is another strange decision
So just download f-droid yourself? Why the fixation on having a definitive, preloaded app store?
>I much prefer a fully OSS package manager and there is real value in having people compile from the sources externally, maybe even reproducibly so, instead of trusting the github packages.
Operating an app store is almost as much work as maintaining an Android fork, and it's hard to fault the authors for not sinking massive amounts of effort into doing it, when there's already f-droid, play store (plus aurora store), obtanium, and many others.
First of all, I would like to state that just because a piece of software is free and open source, does not mean it is inherently more secure or private. "Open source" is merely just a licensing term.
GrapheneOS has the "App Store" to get the most basic apps required for general usage. Accrescent is distributed there because it follows Android's security baseline for being an actual app repository while F-Droid and Aurora Store do not.
There really isn't a value in having third parties compiling apps to check for any malicious activity, which F-Droid does. These checks are not reliable and have been bypassed. It's one of the reasons why Wireguard is no longer on F-Droid. If you don't trust an app enough to get it directly from the developer, then don't use the app at all.
The privacy and security benefits of GrapheneOS are supposed to be nearly invisible to the average user. Examples include a hardened memory allocator and memory tagging extension to protect from memory corruption bugs, and the ability to install sandboxed Google Play to use Google services without Google having complete control of your device.
Please study the https://en.wikipedia.org/wiki/XZ_Utils_backdoor That is the supply chain attack I know and it was discovered in debian with their outdated build system. Your arguments, which copy exactly those of the "grapheneos people", seem ignorant and arrogant to me. F-droid people are doing a lot of work for free, I think they deserve more respect than you give them.
I trust F-Droid. I don't trust millions of developers. I don't have time everytime I need an app to go investigate, especially now with quick LLM scam app developer
Developers are not geniuses at every aspect of security or app deployment. They can sell their projects. Get compromised. Or can get tricked like the xz exploit
Having an app store making any effort to prevent or correct problems, especially as transparent as F-Droid, is better
Wireguard app dev wanting to bypass the store and push an executable to your phone every day is ridiculous. No user of app/package manager expects it to be bypassed
GrapheneOS inherits the user interface of the Android Open Source Project, which is what Pixels stock operating system uses, along with many other OEM forks of android.
GrapheneOSs App Store is present to fulfil the role of the first party appstore that AOSP requires. It also serves to provide updates to first party apps out-of-band, and mirror apps for various case-by-case reasons.
Accrescent is mirrored due to it having a focus on privacy and security. It is currently in alpha and app submissions are closed. They will be open Soon:tm:.
Google play is mirrored for app compatibility with apps that require google play, and for access to the playstore.
The GrapheneOS community favors Obtanium due to its ability to fetch developer-signed apps from places like Github. Fdroid signs and builds nearly every app on the main repository with outdated build infrastructure and poor moderation.
GrapheneOSs security model inherits and builds upon the AOSP security model.
I'm really glad calyxos is starting up again. Grapheneos has a lot of cool technical implementation but there are a lot of things that Calyx seems to do in a simpler, more vanilla Android manner.
Not sure where you got Calyx doing stuff in a "simpler, more vanilla Android manner". It's quite the opposite, actually. CalyxOS bundles a whole bunch of useless third party apps which connect to third party services. If you opt-in to installing microG (which is privileged, not in a sandbox), you aren't avoiding Google in the slightest. You're actually opening yourself up more because of how much of a sloppy interpretation microG is while trying to fill in the role of Google Play services. microG exposed location data to apps, even if the permission was explicitly denied. The developers knew about this for years without doing anything about it.
You're safer using a standard Android phone than using an OS as duct-taped together as CalyxOS.
microG exposed location data to apps, even if the permission was explicitly denied. The developers knew about this for years without doing anything about it.
GrapheneOS is more simple and vanilla than CalyxOS. GrapheneOS puts substantial effort into seamless/passive privacy and security features, as well as maintaining feature parity with the Android Open Source Project and with Googles stock Pixel operating system.
CalyxOS is not a private or secure operating system. They have added several 3rd party apps and services, which includes several 3rd party connections. On top of this, several of these services are given problematic, privileged access.
A notable example of this is Android Auto. CalyxOS grants substantial privileged access to this component by default, while GrapheneOS sandboxes it, and exposes 4 opt-in toggles for privileged access. The user may granularly decide what privileged access they wish to grant.
Not using it currently but they recently released some test builds of android 16. And yeah aiui bootloader relocking is supported for devices that are compatible.
F droid is known to be highly insecure. It has many many bad practises that totally compromise security and they have proven to be woefully incompetent and ignorant to concepts as basic as the purpose of app signing.
The all apps stemming from app stores in the builting App Store is to provide a minimalist experience by default whilst keeping google play apps accessible. GrapheneOS has a majour focus on accessibility. They avoid users having to be technical to install an app store to get their apps.
We all agree. But what's the solution? We know 99% of the users don't care. So, the only pressure point is phone manufacturers. I don't have any power to influence anybody significant in this space. I feel helpless.
For me, it's litigation, because the nature of GMS and Play Integrity is highly anticompetitive and these shouldn't even be legal (and most likely already aren't)..
See, mobile phone vendors have their hands tied - they can offer bootloader unlocking, but they can't touch Google spyware, otherwise they won't be "certified", won't be able to use Google Play or even the name Android.. That's of course not enough for Google, they also want to go after users which of such systems / modified systems (with unlocked bootloader) - that's what "Play Integrity" is about, they work hard to make sure the phone gets as useless as possible.. Together those two basically prevent vendors from making the mobile privacy landscape any better.
In the EU, we should outlaw Play Integrity first, by mandating that security level attestation might only be done in a way there's an independent auditing body that might certify alternative operating systems (these could use standard Android attestation) based on objective security criteria, not the Google spyware criteria. I heard about the "UnifiedAttestation" initiative but I'm not sure what's the progress on that.. not that I'm a fan of attestation at all, but you need to understand that it's a different thing when you attest the security model of the system, and a different thing where a system being "secure" actually implies Google spyware must be installed. For banking apps, I'd just want a secure OS, like GrapheneOS - without GMS.
Howver, the main antitrust investigation should happen in the US, only US courts can bring relevant Google executives to justice.
I don't think it's going to be a savior... the same things that make Android hard to modify can happen just as easily when GNU/Linux phones become popular.
Well one way would be just like how Android phone manufacturers are doing it now... with locked bootloaders and binary blobs. Even current GNU/Linux phones still largely need blobs to work properly.
This is misleading. The blobs are only in the firmware, not in the OS, not in the bootloader, not running on the CPU.
Having a technical possibility to lock down GNU/Linux phones in principle in undefined future by undefined entity that doesn't even produce them yet is a FUD argument.
Oh wait they released "Liberty Phone" - still low end(!), this time with absurdly high price.. You can get true linux phone 10x cheaper by buying something that supports PostmarketOS
Your post sounds like you're trying to spread FUD.
Librem says the Liberty phone is the same, it just costs more because it is assembled in the U.S. for people, companies, or governments that don't want it intercepted and modified by a bad actor.
Side question: what's a good way of getting a GrapheneOS phone?
I have been interested in using GrapheneOS but hesitant about actually getting a Pixel phone. Used phone prices are usually >$300 even for "a" series unless I go back several generations. Whether the device bootloader can be unlocked is also a question. I am definitely not ready to spend $449 on a new Pixel 10a.
This won't help you right now, but GrapheneOS did recently announce a partnership with Motorola, so presumably in a year or so support will start showing up for some Motorola devices.
Side note: I did get the 10a on launch from Google Fi for ~300.
Pixel 10a is essentially a proper Pixel 9a. It uses the Pixel 9 SoC and Pixel 9 cellular radio compared to the Pixel 9a using the cellular radio used by 8th gen Pixels. The 9th gen Pixel cellular radio was a huge upgrade for connectivity and power efficiency so it's a major advantage for the Pixel 10a over the Pixel 9a. They're budget devices and definitely have significant compromises for the display, wireless charging and other areas.
No, GrapheneOS adheres to the same support period that the OEM provides. End of life devices are insecure and should not be used. Only the OEM can provide the firmware updates necessary for proper support, because the firmware images are signed by the OEM/component manufacturers. All GrapheneOS can do is push the updated firmware.
GrapheneOS has a requirement of a 5-7 year support window from an OEM.
Graphene OS only supports devices for as long as the manufacturer is providing security updates for the phone's firmware. Firmware is binary blob, so there'd be no practical way for anyone else to provide/develop security updates once the manufacturer is no longer providing official updates.
Their partnership with Motorola, I think, involves some ability of Graphene OS devs to access/harden/update the firmware, but I'm not 100% sure. Firmware on phones, especially for the baseband processor, often involves a nasty confluence of copyright, trade secrets, patents, and government rules/demands.
It can be done, fairphone rather famously did it once.
But it is vastly uneconomical, and I doubt anyone is going to start doing it regularly.
We really need some kind of regulation demanding firmware support for longer. The EU seems the most likely entity to achieve something like that. Phone vendors can't even control how long they support their own hardware, because the SoC is almost always Qualcomm, and once they drop support, there aren't any good options left.
> It can be done, fairphone rather famously did it once.
No, they ported a new major Android release beyond what the SoC officially supported. They had already stopped providing firmware, kernel or driver security patches long before that point. They did what LineageOS regularly does by porting a new major Android release to hardware not officially supporting it. Unlike LineageOS, they had to convince a company to certify it as meeting the CDD/CTS requirements. Most OEMs including Fairphone have major CDD/CTS violations but yet still get certified in practice so that doesn't really mean as much as you'd think. It's common for Android OEMs to break functionality tested by the CTS and yet somehow they have certification. This is part of why the Play Integrity API's flimsy justification for the highly anti-competitive approach it uses is such nonsense.
Even the Fairphone 5 already lacks standard Linux kernel security patches due to having an end-of-life kernel branch. Fairphone doesn't provide anything close to proper updates.
Qualcomm offers up to 8 years of major Android version updates and basic security patches for their firmware and drivers. They charge money for each year of support. It's there if OEMs are willing to pay for an up-to-date SoC and pay for many years of support.
GrapheneOS will stop releasing updates when Google stops supporting a device. They put an emphasis on security and unpatched drivers or firmware (which they can't/won't/don't have the resources to patch) are a major security risk.
Luckily, Google's support periods are actually quite long, and very clear (stated on the website on launch date, unlike iOS or even Windows these days).
Basically, buy a Pixel 6 or later (I suggest Pixel 7 or later, since Pixel 6 will be minimal support soon) that you are sure has an unlockable bootloader. The majority you'll see don't have an unlockable bootloader.
Which mostly means either buy direct from Google, or buy one on eBay that already has GrapheneOS/CalyxOS/LineageOS on it or for which the seller expressly says it has an unlockable bootloader.
(IME, don't bother trying to ask a seller to check bootloader, if they haven't already said. Almost no one is going to go through the process to check, the answer is probably no anyway, they might misunderstand your question and answer that it's "unlocked", and they may be tired of people asking.)
If you have time and the ebay listing is unclear, I would definitely ask. That way if they say you can unlock the boatloader and in reality you can't, you can return it to them as an item "not as described" at no cost.
I tried asking, years ago, with the rationale of I'm not wasting people's time, since they could get more money if they knew about bootloader unlocking.
Then I decided everyone who knows about bootloader unlocking would've already checked and mentioned if it was unlockable (but not if it wasn't, since why confuse normal buyers with a fringe thing), and I've never gotten a positive response trying to tell any seller about it, so I think I'm just wasting everyone's time.
An 8 series device or higher is recommended. Getting new from non-carrier stores or google store is reliable.
Used is a gamble due to improper OEM unlocking practices, so make sure it has a good return policy and try to verify OEM unlocking is accessible if you purchase used.
Refurbished phones are cheap and even going back 3, 4, 5 years you have great hardware, indistinguishable from what you would pay 1000$ new now. 200 or 300$ for a high quality refurbished pixel is really not that bad.
Not damaging their relationship with Google as a vendor most likely. For better or worse, GrapheneOS is depend on Android which is controlled by Google.
"In its latest release, GrapheneOS says it has "disable[d] registerQuicConnectionClosePayload optimization to fix VPN leak," effectively neutralizing the attack vector on supported Pixel devices."
"GrapheneOS responded by disabling the underlying optimization entirely in release 2026050400."
GrapheneOS "fixed" the leak by disabling the optimisation
Some HN commenters in the past have praised QUIC and downvoted comments that questioned who QUIC stands to benefit the most
Using QUIC may serve the interests of others but for me the tradeoffs are not worth it; I block QUIC traffic
QUIC is sometimes on by default in software distributed by Google, like Android, and in some cases there is no option to disable it
QUIC still works fine on GrapheneOS. GrapheneOS only removed a way to ask the OS to close a QUIC connection automatically in case the app dies, etc. It's an optimization from a server perspective since it avoids the server thinking the connections are still open and keeping resources assigned to them until the idle timeout it has configured followed by having to go through a connection shutdown process. It's not an optimization from a client perspective.
GrapheneOS also has fixes for around 5 other VPN leaks and more fixes on the way. Android currently implements VPNs in a way that's prone to leaks due to VPNs being per-profile but profiles not using their own network namespaces yet and also depending on central services for the DNS resolver and various other things which have to properly handle VPN support. We have plans to improve the VPN architecture in the future to make it very resistant to leaks. There will also be support for running apps or groups of apps in VMs which can have even stronger protection against it.
You make a lot of claim yet gives no source or material to back up your claim.
Beside, what would be a great distribution beyond grapheneos. iOS isn't, stock Android is much worst, calyxos ? Lineageos ? They are much worst on the security.
For Motorola the management changed while government customers remained the same, perhaps now adding also the Chinese gov into the mix which certainly will "approve" the hardware within. You know this quite well.
I'd happily talk in detail about donors when you first make public the values and donor list for the bigger ones, which you don't for some shady reason and only reveal a few. Even from those few, your biggest public donor are the people well known to dodge real privacy in crypto faster than vampires dodging holy water. Please disclose how much money you pay to the blog/media to shill this project so frequently.
You won't do any of this. You know that, I know that, you know that I know that and still you will continue to profit on those who will never read these comments.
The developers of each have engaged in a few flamewars and the commenter I replied to was critical of GrapheneOS using similar language, so I made a (tongue in cheek comment) implying the commenter was starting the flamewar back up
I wouldn't call it a honeypot, but it's probably compromised by the feds.
It was shown a few years back that if you control enough of the exit nodes (more than some specific % that I don't remember off the top of my head) then you can associate traffic across most/all of the Tor network. Since running exit nodes is relatively cheap the assumption was that the feds (or some other state actor) were already doing so.
I'd call that materially different than a honeypot though since it wasn't designed for that purpose.
> Because system_server operates with elevated networking privileges and is exempt from VPN routing restrictions
So a VPN isn't a VPN on Android? Regardless of this bug. Do other locked down operating systems act the same?
Ios does the same, only way around it is if you have an ?enterprise? licence (250+ devices)
Mullvad and others reported on that one ages ago
Is this really true? The Mullvad report a year or so ago was that they didn’t want to turn on no exceptions mode because it breaks network connectivity until reboot if you don’t pause it when updating the app, not that the feature doesn’t exist. They also recently shipped it anyway, opt in and behind a warning.
a VPN enabled wifi router would suffice as a fallback tho right?
For the very specific case where you are connected to that router, yes.
MacOS has had instances where their own apps could bypass always-on VPN. I'm not sure if there have been exploits or gaps where traffic could go to arbitrary destinations directly.
this is not an ocassional bug this is still the system design today. privacy gateways upstream of big tech are the way to go on this because privacy isn't their profit center
Terminology like "private" and "trust" differ in meaning from computer land to human convention.
It's a concern to me, because humans often extend their trust to computer trust based upon misunderstanding of the identically spelled words and lack of recognition of differing context.
How hard would it be to fix the system_server (and any other) bypass?
The technical detail that makes this egregious is that the leak happens in system_server, a privileged process. Android’s own lockdown mode explicitly promises that no traffic bypasses the VPN. When the system itself sends the packet over the physical interface, that promise is broken at the kernel level, not in userspace. Calling this “not security bulletin class” is hard to defend.
Thanks, Claude! Or perhaps Codex? Which type of AI spambot are you?
Just like manifest v3, it's not in their best interests to disallow snooping. It hurts their business model.
[dead]
I know there are bad business reasons, but how can someone classify a VPN leak as "not a security issue" and keep their pride?
Depends on how you see the role of a VPN.
VPNs, at least originally, were designed to provide access to private/business networks across another network. Office to office, home to office, that sort of thing. VPNs were only later turned into some kind of (supposed) security tool.
If your take on VPN code is "as long as your phone can reach the office printer over 5G" then this is a tiny bug. QUIC connections aren't being shut down properly, like they weren't before the introduction of the feature.
If your take on VPN code is "this wireguard tunnel must keep my identity safe no matter what" or "my security relies on this wireguard tunnel being an exact copy of all traffic exchanged over the internet" then this is a massive problem.
I don't think Android VPNs, or any VPN to be honest, were ever designed as a privacy or security measure. Especially not against apps with code execution on the device. The device itself will do all kinds of network interactions, some happening from within the modem chip itself.
Closing the bug was a mistake on Google's part, but I can see why they don't consider this a security bug in their bug bounty programme.
That assumes there is pride they have to bother to keep.
Interestingly GrapheneOS being so good brings more money to Google as only Pixel phones are supported.
First motorola grapheneos phone i am buying to get fully off the google pain train. Grapheneos tides me over until a real linux smart phone shows up or i die of old age. Now if home assistant could get thread network join*ng working without an android phone with a google account i could ve fully ris of those eh holes.
> Now if home assistant could get thread network join*ng working without an android phone with a google account
There is already a way to do this. It's fiddly, but not by much. Once set up it's a much better experience, though.
https://www.matteralpha.com/how-to/how-to-use-home-assistant...
It needs to work theough bluetooth proxy and be a button click, not massive pain like the articlec
Yeah requires a free Bluetooth radio and has a bit of setup, but in my opinion, it's well worth it to not be reliant on Android or iPhone, which has always given me problems.
> real linux smart phone shows up
What’s most glaringly missing, for you specifically, from the plethora of options available?
It seems like plenty of options are getting 7/10 things right.
Have you tried any of them? The software is painful or the hardware they work on is painfully underpowered.
And typically security is very bad, no good sandboxing, MAC (through e.g. SELinux), etc. I know that doesn't matter to everyone, but in the context of a discussion about GrapheneOS it does.
You’re going to struggle with that with most distros.
Indeed. Though in Europe is common for banking apps/auth, government ID apps, etc. to be phone-based, so they are the more interesting target.
I am patiently waiting for that one. I have been willing to move to GrapheneOS for a while, but I don't feel like buying Google hardware.
Fwiw the pixel phones are excellent hardware.
That's debatable. Pretty much every generation of the Pixel phones have had some major issues. They've even had to do multiple extended repair/replace programs due to some of them. Heck there is even an ongoing issue where one of their updates has caused multiple generations of their devices to be bricked (and that still hasn't been fixed) - https://www.androidauthority.com/google-pixel-march-update-b...
On a technical level, yea, it may be great hardware but in practice, I don't think it is. As an Android user, I wish it were but it's not. Samsung is so much more reliable as an end user (even with their own issues).
They have consistently the worst battery endurance of any relevant phone maker since forever.
I don't care. I don't want Google hardware because I despise the company and I'm actively trying to reduce my dependence on Google.
There should be at least one Motorola phone before end of the year that has GrapheneOS support.
Motorola devices with GrapheneOS support will arrive in 2027 or later, not 2026. Likely, the 2027 Signature, Razr fold, and Razr flip, will meet GOSs hardware security requirements.
Sadly, Verizon Pixel phones, even after carrier unlocking, seem to be forever blocked from using GrapheneOS.
Carrier-sold Pixels generally don't have "OEM-unlockable" bootloaders.
Your best bet for now is to buy a new Pixel direct from Google, or a used one from eBay that the seller advertises as already having GrapheneOS on it (or otherwise guarantees that the bootloader is unlockable). These ones are worth a lot more than the ones that can only run Google/carrier Android.
https://grapheneos.org/install/web#prerequisites
I own two GrapheneOS Pixel 7 units, which should get any Google blob security updates (which GrapheneOS incorporates) through October 2027, and GrapheneOS may still support it with source updates after that. So in a year or so, I might get the GrapheneOS Motorola if it's available, or a later Pixel. (I never buy these new, since I don't want to carry a several hundred dollar phone when a 2 gen old one is still great, thanks to GrapheneOS.)
https://support.google.com/pixelphone/answer/4457705
OEM/carrier locking tends to only happen in the US. Many carriers permit unlocking after the contract has concluded, but Verizon has always blocked it. Used devices also run the risk of being improperly unlocked and making OEM unlocking remain unavailable. (Used devices may also be Verizon devices.)
Is this true for all carriers? Or just Verizon? Several Reddit threads say that it's just Verizon. T-Mobile users report being able to bootloader unlock after getting their phones carrier unlocked by T-Mobile.
OEM/carrier locking tends to only happen in the US. Many carriers permit unlocking after the contract has concluded, but Verizon has always blocked it. Used devices also run the risk of being improperly unlocked and making OEM unlocking remain unavailable. (Used devices may also be Verizon devices.)
I finally left Verizon after nearly 20 years. I had it with their enshittification, couldn't stand it anymore. I switched to US Mobile and on the Darkstar (AT&T) network. I have no regrets. I caught it on a black friday deal, so I'm paying basically $20/mo for top tier service. You wouldn't have caught me dead with an AT&T service or MVNO years ago because I'd seen so many bad experiences second-hand, but these days it's been a breeze knock on wood
I also did the math and determined buying a new unlocked phone outright on this plan was far cheaper than paying Verizon monthly for one.
> I also did the math and determined buying a new unlocked phone outright on this plan was far cheaper than paying Verizon monthly for one.
On any plan.
There’s a reason that as soon as you walk into a cell store they immediately try to schmooze you into signing contracts and leasing phones.
It’s the way they make the most margin!
+1 for US Mobile. Verizon was also good, but a few months ago my cofounder and I discovered we were absurdly overpaying for our decade-old small business plan and found that US Mobile offered a better end product for a fraction of the price.
Currently running my Pixel on Warp (Verizon) with zero practical difference, and starting Monday I'll also have a backup iPhone with a small $8/mo Darkstar line. The money I've saved since switching more or less paid for the iPhone, and I'll be getting 2x reliability for way less ongoing cost. The better app/website/support and extra features are just a bonus.
I’ve seen this repeated here, but:
Google's Pixel hardware division likely operates at a loss - or breaks even.
and even if every active HN user bought $100-$400 used Pixels from Swappa, meaningless money to them.
Yep, Pixels for them are entry points to Google One subscriptions, etc. The Pixel 9a is currently 350 Euro in my country, it has the same CPU/GPU (modem differs) that the expensive 9 Pro/Pro XL/Pro Fold had. Factoring in development costs, etc. at that price I cannot imagine it being more than break-even.
Also, even Pixel 9a has all the security functions of the flagship that many other Android phones do not have or are just getting, such as the Memory Tagging Extension (MTE), the Titan M2 security processor (no need to rely on TrustZone for secrets), etc.
I don't see a problem with supporting their legitimate hardware or cloud business models. But of course I see a problem supporting their illegitimate adware and spyware business models.
I agree, especially when you are buying for the used market.
So far. Other companies surely will make their devices compatible if the market share increases for it
We need to bring back shame.
Step one… completely reform MBA programs.
It's a feature for them not a bug. Google is an ad company and an offense contractor they want VPN users leaking packets for both reasons.
How can someone consider unwanted disclosure of personal information a security issue, and work at Google?
At some point digital security turns into physical security, and there are national security interests that have fine-tuned their detection logic on these kinds of "buggy" behavior.
If you patch it, you'd need to find another way to de-anonymize those users.
So, somewhere, some government or organization might want to blow the user into kibble, and that's an important use case?
I feel like this should be toward the top of the terms of service for the phone, even above the mandatory arbitration clause.
They're paid not to.
Corporations have no pride. They are soulless, psychopathic accountability sinks.
What planet are you from?
The issue reported on lowlevel.fun [0] and discussed on GrapheneOS forums [1] does seem like a security issue. It isn't clear why engineers in charge would mark it infeasible as the breach demonstrates more than one failure.
1. A new (albeit "hidden" [2]) network API registerQuicConnectionClosePayload(fd, payload) lets a process set any byte array for the OS to send on its behalf.
2. No ("panaroid networking") permission checks against the calling uid/process when sending that byte array out on a OS-owned UDP socket.
3. Bypassing ("panaroid android") permission checks [3] by simply calling network-related syscalls (or libc/bionic functions) as opposed to Android SDK APIs.
These steps essentially amount to app sandbox escape (2,3) and privilege escalation (1,2). I am utterly confused why the Android security team at Google won't take this more seriously.
[0] https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypas...
[1] https://discuss.grapheneos.org/d/35152-android-always-on-vpn...
[2] In as much the code mmap'd into your own process can be "hidden" away. For their exploit though, the author cleverly abuses Binder IPC primitives to reach the "hidden" parts.
[3] This bypass probably only works for this one scenario because of #2.
I bought a used Pixel 6 for cheap to try out grapheneos. Can't say I like it. UX of lineageos is much better. There is a weird russian doll kind of situation with the package managers going on. There is one builtin "App Store" with only a few basis programs, one of which is another package manager, accrescent, which offers a few more apps, but still not comprehensive at all, so another package manager is needed for which grapheneos people seem to favor obtainium over f-droid, which I find is another strange decision. I much prefer a fully OSS package manager and there is real value in having people compile from the sources externally, maybe even reproducibly so, instead of trusting the github packages. The grapheneos security model seems oddly centralized to me. I can't really comment on the reported privacy and security benefits.
> so another package manager is needed for which grapheneos people seem to favor obtainium over f-droid, which I find is another strange decision
So just download f-droid yourself? Why the fixation on having a definitive, preloaded app store?
>I much prefer a fully OSS package manager and there is real value in having people compile from the sources externally, maybe even reproducibly so, instead of trusting the github packages.
Operating an app store is almost as much work as maintaining an Android fork, and it's hard to fault the authors for not sinking massive amounts of effort into doing it, when there's already f-droid, play store (plus aurora store), obtanium, and many others.
> there's already f-droid, play store (plus aurora store), obtanium
Also Neo Store, Accrescent
App store is about as much as you need to decide what to do/where to go for the apps.
Out of the box it has only a launcher and the minimal OS. All the minimalist needs.
If you want more, you get to decide where to go for that.
I call it empowering users, you call it inconvenience, but maybe in that case it's not the best OS for you?
First of all, I would like to state that just because a piece of software is free and open source, does not mean it is inherently more secure or private. "Open source" is merely just a licensing term.
GrapheneOS has the "App Store" to get the most basic apps required for general usage. Accrescent is distributed there because it follows Android's security baseline for being an actual app repository while F-Droid and Aurora Store do not. There really isn't a value in having third parties compiling apps to check for any malicious activity, which F-Droid does. These checks are not reliable and have been bypassed. It's one of the reasons why Wireguard is no longer on F-Droid. If you don't trust an app enough to get it directly from the developer, then don't use the app at all. The privacy and security benefits of GrapheneOS are supposed to be nearly invisible to the average user. Examples include a hardened memory allocator and memory tagging extension to protect from memory corruption bugs, and the ability to install sandboxed Google Play to use Google services without Google having complete control of your device.
Please study the https://en.wikipedia.org/wiki/XZ_Utils_backdoor That is the supply chain attack I know and it was discovered in debian with their outdated build system. Your arguments, which copy exactly those of the "grapheneos people", seem ignorant and arrogant to me. F-droid people are doing a lot of work for free, I think they deserve more respect than you give them.
I trust F-Droid. I don't trust millions of developers. I don't have time everytime I need an app to go investigate, especially now with quick LLM scam app developer
Developers are not geniuses at every aspect of security or app deployment. They can sell their projects. Get compromised. Or can get tricked like the xz exploit
Having an app store making any effort to prevent or correct problems, especially as transparent as F-Droid, is better
Wireguard app dev wanting to bypass the store and push an executable to your phone every day is ridiculous. No user of app/package manager expects it to be bypassed
GrapheneOS inherits the user interface of the Android Open Source Project, which is what Pixels stock operating system uses, along with many other OEM forks of android.
GrapheneOSs App Store is present to fulfil the role of the first party appstore that AOSP requires. It also serves to provide updates to first party apps out-of-band, and mirror apps for various case-by-case reasons.
Accrescent is mirrored due to it having a focus on privacy and security. It is currently in alpha and app submissions are closed. They will be open Soon:tm:.
Google play is mirrored for app compatibility with apps that require google play, and for access to the playstore.
The GrapheneOS community favors Obtanium due to its ability to fetch developer-signed apps from places like Github. Fdroid signs and builds nearly every app on the main repository with outdated build infrastructure and poor moderation.
GrapheneOSs security model inherits and builds upon the AOSP security model.
I'm really glad calyxos is starting up again. Grapheneos has a lot of cool technical implementation but there are a lot of things that Calyx seems to do in a simpler, more vanilla Android manner.
Not sure where you got Calyx doing stuff in a "simpler, more vanilla Android manner". It's quite the opposite, actually. CalyxOS bundles a whole bunch of useless third party apps which connect to third party services. If you opt-in to installing microG (which is privileged, not in a sandbox), you aren't avoiding Google in the slightest. You're actually opening yourself up more because of how much of a sloppy interpretation microG is while trying to fill in the role of Google Play services. microG exposed location data to apps, even if the permission was explicitly denied. The developers knew about this for years without doing anything about it.
You're safer using a standard Android phone than using an OS as duct-taped together as CalyxOS.
microG exposed location data to apps, even if the permission was explicitly denied. The developers knew about this for years without doing anything about it.
Care to source this claim?
GrapheneOS is more simple and vanilla than CalyxOS. GrapheneOS puts substantial effort into seamless/passive privacy and security features, as well as maintaining feature parity with the Android Open Source Project and with Googles stock Pixel operating system.
CalyxOS is not a private or secure operating system. They have added several 3rd party apps and services, which includes several 3rd party connections. On top of this, several of these services are given problematic, privileged access.
A notable example of this is Android Auto. CalyxOS grants substantial privileged access to this component by default, while GrapheneOS sandboxes it, and exposes 4 opt-in toggles for privileged access. The user may granularly decide what privileged access they wish to grant.
CalyxOS claims releases are paused[1] and the best you can get is Android 15. How recent are security patches you're getting?
Can you even lock the bootloader on your device? [2]
[1] https://calyxos.org/
[2] calyxos.org/lock
Not using it currently but they recently released some test builds of android 16. And yeah aiui bootloader relocking is supported for devices that are compatible.
https://old.reddit.com/r/CalyxOS/comments/1t3tdt6/calyxos_pr...
F droid is known to be highly insecure. It has many many bad practises that totally compromise security and they have proven to be woefully incompetent and ignorant to concepts as basic as the purpose of app signing.
The all apps stemming from app stores in the builting App Store is to provide a minimalist experience by default whilst keeping google play apps accessible. GrapheneOS has a majour focus on accessibility. They avoid users having to be technical to install an app store to get their apps.
F-Droid has arguably produced more value than GrapheneOS for open source community, independent ROM users, and android in general
Stock Android is spyware and adware, back in the day we called such software malicious and removed it, now it's the default.
We all agree. But what's the solution? We know 99% of the users don't care. So, the only pressure point is phone manufacturers. I don't have any power to influence anybody significant in this space. I feel helpless.
The phones without tracking are so rare that I don't think we can even say that the users do not care, they simply never had the option
For me, it's litigation, because the nature of GMS and Play Integrity is highly anticompetitive and these shouldn't even be legal (and most likely already aren't)..
See, mobile phone vendors have their hands tied - they can offer bootloader unlocking, but they can't touch Google spyware, otherwise they won't be "certified", won't be able to use Google Play or even the name Android.. That's of course not enough for Google, they also want to go after users which of such systems / modified systems (with unlocked bootloader) - that's what "Play Integrity" is about, they work hard to make sure the phone gets as useless as possible.. Together those two basically prevent vendors from making the mobile privacy landscape any better.
In the EU, we should outlaw Play Integrity first, by mandating that security level attestation might only be done in a way there's an independent auditing body that might certify alternative operating systems (these could use standard Android attestation) based on objective security criteria, not the Google spyware criteria. I heard about the "UnifiedAttestation" initiative but I'm not sure what's the progress on that.. not that I'm a fan of attestation at all, but you need to understand that it's a different thing when you attest the security model of the system, and a different thing where a system being "secure" actually implies Google spyware must be installed. For banking apps, I'd just want a secure OS, like GrapheneOS - without GMS.
Howver, the main antitrust investigation should happen in the US, only US courts can bring relevant Google executives to justice.
The truly independent solution is GNU/Linux. Sent from my Librem 5.
I don't think it's going to be a savior... the same things that make Android hard to modify can happen just as easily when GNU/Linux phones become popular.
How? Linux development is not steered by a monopolist acting to gain the maximal profit. It is distributed over many entities.
Well one way would be just like how Android phone manufacturers are doing it now... with locked bootloaders and binary blobs. Even current GNU/Linux phones still largely need blobs to work properly.
This is misleading. The blobs are only in the firmware, not in the OS, not in the bootloader, not running on the CPU.
Having a technical possibility to lock down GNU/Linux phones in principle in undefined future by undefined entity that doesn't even produce them yet is a FUD argument.
Not true, current GNU/Linux have OS-level blobs
PureOS running on my phone is endorsed by the FSF, i.e., has no blobs whatsoever: https://news.ycombinator.com/item?id=25504641
Why is there no Librem 6? Librem 5 is 7 years old, it's a low-end smartphone with a flagship price tag :(
Oh wait they released "Liberty Phone" - still low end(!), this time with absurdly high price.. You can get true linux phone 10x cheaper by buying something that supports PostmarketOS
Your post sounds like you're trying to spread FUD.
Librem says the Liberty phone is the same, it just costs more because it is assembled in the U.S. for people, companies, or governments that don't want it intercepted and modified by a bad actor.
This might justify the price of Liberty Phone, but doesn't invalidate my claim that these phones are low-end by todays standards.
Why no hardware upgrade after 7 years?
You can't easily find vendors supporting free drivers: https://puri.sm/posts/breaking-ground/
Also this: https://puri.sm/posts/the-danger-of-focusing-on-specs/
Even more so, just like meta removing end to end encryption.
"Nah dog, we like watching everything you say and do."
[dead]
Side question: what's a good way of getting a GrapheneOS phone?
I have been interested in using GrapheneOS but hesitant about actually getting a Pixel phone. Used phone prices are usually >$300 even for "a" series unless I go back several generations. Whether the device bootloader can be unlocked is also a question. I am definitely not ready to spend $449 on a new Pixel 10a.
This won't help you right now, but GrapheneOS did recently announce a partnership with Motorola, so presumably in a year or so support will start showing up for some Motorola devices.
Side note: I did get the 10a on launch from Google Fi for ~300.
Upcoming Amazon Prime Day?
https://www.zdnet.com/article/my-sleeper-phone-deal-for-prim...
Don't buy Pixel 10a, 9a is almost exactly the same thing and still sold new.
Pixel 10a is essentially a proper Pixel 9a. It uses the Pixel 9 SoC and Pixel 9 cellular radio compared to the Pixel 9a using the cellular radio used by 8th gen Pixels. The 9th gen Pixel cellular radio was a huge upgrade for connectivity and power efficiency so it's a major advantage for the Pixel 10a over the Pixel 9a. They're budget devices and definitely have significant compromises for the display, wireless charging and other areas.
10a will get longer support, so why not (unless 9a is significantly cheaper)?
Isn’t part of the point of wanting GrapheneOS is that the official support periods don’t matter?
No, GrapheneOS adheres to the same support period that the OEM provides. End of life devices are insecure and should not be used. Only the OEM can provide the firmware updates necessary for proper support, because the firmware images are signed by the OEM/component manufacturers. All GrapheneOS can do is push the updated firmware.
GrapheneOS has a requirement of a 5-7 year support window from an OEM.
Graphene OS only supports devices for as long as the manufacturer is providing security updates for the phone's firmware. Firmware is binary blob, so there'd be no practical way for anyone else to provide/develop security updates once the manufacturer is no longer providing official updates.
Their partnership with Motorola, I think, involves some ability of Graphene OS devs to access/harden/update the firmware, but I'm not 100% sure. Firmware on phones, especially for the baseband processor, often involves a nasty confluence of copyright, trade secrets, patents, and government rules/demands.
It can be done, fairphone rather famously did it once.
But it is vastly uneconomical, and I doubt anyone is going to start doing it regularly.
We really need some kind of regulation demanding firmware support for longer. The EU seems the most likely entity to achieve something like that. Phone vendors can't even control how long they support their own hardware, because the SoC is almost always Qualcomm, and once they drop support, there aren't any good options left.
> It can be done, fairphone rather famously did it once.
No, they ported a new major Android release beyond what the SoC officially supported. They had already stopped providing firmware, kernel or driver security patches long before that point. They did what LineageOS regularly does by porting a new major Android release to hardware not officially supporting it. Unlike LineageOS, they had to convince a company to certify it as meeting the CDD/CTS requirements. Most OEMs including Fairphone have major CDD/CTS violations but yet still get certified in practice so that doesn't really mean as much as you'd think. It's common for Android OEMs to break functionality tested by the CTS and yet somehow they have certification. This is part of why the Play Integrity API's flimsy justification for the highly anti-competitive approach it uses is such nonsense.
Even the Fairphone 5 already lacks standard Linux kernel security patches due to having an end-of-life kernel branch. Fairphone doesn't provide anything close to proper updates.
Qualcomm offers up to 8 years of major Android version updates and basic security patches for their firmware and drivers. They charge money for each year of support. It's there if OEMs are willing to pay for an up-to-date SoC and pay for many years of support.
Ah righteo. Thanks for updating my understanding.
GrapheneOS will stop releasing updates when Google stops supporting a device. They put an emphasis on security and unpatched drivers or firmware (which they can't/won't/don't have the resources to patch) are a major security risk.
Luckily, Google's support periods are actually quite long, and very clear (stated on the website on launch date, unlike iOS or even Windows these days).
I answered this in another thread: https://news.ycombinator.com/item?id=48076522
Basically, buy a Pixel 6 or later (I suggest Pixel 7 or later, since Pixel 6 will be minimal support soon) that you are sure has an unlockable bootloader. The majority you'll see don't have an unlockable bootloader.
Which mostly means either buy direct from Google, or buy one on eBay that already has GrapheneOS/CalyxOS/LineageOS on it or for which the seller expressly says it has an unlockable bootloader.
(IME, don't bother trying to ask a seller to check bootloader, if they haven't already said. Almost no one is going to go through the process to check, the answer is probably no anyway, they might misunderstand your question and answer that it's "unlocked", and they may be tired of people asking.)
I'd say buy Pixel 8 or later, Pixel 8 is the first version with support for MTE, which is a significant security improvement.
Pixel 8 is also the first generation of Pixels to be officially supported, both security and OS updates, for 7 years (until 2030)
If you have time and the ebay listing is unclear, I would definitely ask. That way if they say you can unlock the boatloader and in reality you can't, you can return it to them as an item "not as described" at no cost.
I tried asking, years ago, with the rationale of I'm not wasting people's time, since they could get more money if they knew about bootloader unlocking.
Then I decided everyone who knows about bootloader unlocking would've already checked and mentioned if it was unlockable (but not if it wasn't, since why confuse normal buyers with a fringe thing), and I've never gotten a positive response trying to tell any seller about it, so I think I'm just wasting everyone's time.
Your mileage may vary.
You could wait it out for a bit. There is work underway to support more phone hardware. Which brand was a bit up for speculation.
It was announced a while ago to be Mororola: https://motorolanews.com/motorola-three-new-b2b-solutions-at...
I doubt Motorola will give him a phone cheaper than 449$ though.
An 8 series device or higher is recommended. Getting new from non-carrier stores or google store is reliable.
Used is a gamble due to improper OEM unlocking practices, so make sure it has a good return policy and try to verify OEM unlocking is accessible if you purchase used.
I bought a Pixel 7 from BackMarket to test out GrapheneOS. I have previous positive comments and conversations in my account history.
> unless I go back several generations
Yeah, do that.
It’ll still be the snappiest phone you’ve ever used.
Refurbished phones are cheap and even going back 3, 4, 5 years you have great hardware, indistinguishable from what you would pay 1000$ new now. 200 or 300$ for a high quality refurbished pixel is really not that bad.
> Google maintained its position, authorizing public disclosure on April 29.
I'm surprised they honored the embargo at that point, and delayed the fix until May. Why not just release immediately?
Not damaging their relationship with Google as a vendor most likely. For better or worse, GrapheneOS is depend on Android which is controlled by Google.
The researcher who discovered the bug is not affiliated with Graphene
"In its latest release, GrapheneOS says it has "disable[d] registerQuicConnectionClosePayload optimization to fix VPN leak," effectively neutralizing the attack vector on supported Pixel devices."
"GrapheneOS responded by disabling the underlying optimization entirely in release 2026050400."
GrapheneOS "fixed" the leak by disabling the optimisation
Some HN commenters in the past have praised QUIC and downvoted comments that questioned who QUIC stands to benefit the most
Using QUIC may serve the interests of others but for me the tradeoffs are not worth it; I block QUIC traffic
QUIC is sometimes on by default in software distributed by Google, like Android, and in some cases there is no option to disable it
QUIC still works fine on GrapheneOS. GrapheneOS only removed a way to ask the OS to close a QUIC connection automatically in case the app dies, etc. It's an optimization from a server perspective since it avoids the server thinking the connections are still open and keeping resources assigned to them until the idle timeout it has configured followed by having to go through a connection shutdown process. It's not an optimization from a client perspective.
GrapheneOS also has fixes for around 5 other VPN leaks and more fixes on the way. Android currently implements VPNs in a way that's prone to leaks due to VPNs being per-profile but profiles not using their own network namespaces yet and also depending on central services for the DNS resolver and various other things which have to properly handle VPN support. We have plans to improve the VPN architecture in the future to make it very resistant to leaks. There will also be support for running apps or groups of apps in VMs which can have even stronger protection against it.
This is the path for the graceful closing on the QUIC connection via (IMO) illegitimate/exploitative call, GOS is not disabling QUIC as a whole.
QUIC as it is is brilliant, and this is not a feature of the protocol, it's a feature of the surveillance OS (Google's Android).
Other than that I checked on the OS before the latest release, and it didn't work anyway.
Great, now to go and buy a Google phone so I can use it.
[flagged]
[flagged]
You make a lot of claim yet gives no source or material to back up your claim.
Beside, what would be a great distribution beyond grapheneos. iOS isn't, stock Android is much worst, calyxos ? Lineageos ? They are much worst on the security.
Seems like volunteers and donations? Is there something else I can read to be more informed on this?
> NSA long time contractor
Motorola Mobility LLC, a US-headquartered, entirely Chinese owned subsidiary of the Chinese computer manufacturer Lenovo, is an NSA contractor?
That’s news.
Project member here.
> A distro with shady revenue sources (check for yourself)
Do me a favor and tell me about our apparent shady revenue sources. We are run entirely by donations, there are large donors too.
> with shady hardware restrictions that only permits to use spyware phones from google
We cover this topic literally everywhere on a daily basis, with a thorough list of requirements found on our website.
> after years of complaints now permits you to use hardware from an NSA long time contractor.
Motorola Solutions and Motorola Mobility are entirely different companies. We've partnered with the latter.
> No, claiming that some magic hardware makes you more secure is not a valid reason
To bring you a rather extreme but also straightforward example, leaked documents from forensic software show we're holding up incredibly well.
> when you are using hardware where they have every reason to track you even further. Saying "nothing was found so far" is no excuse
Okay, so nothing we say will encourage you to change your thinking then.
> Now claims to solve a VPN leak when not long ago this same group were exposed promoting a governamental VPN and honeypot, a.k.a. Tor.
What?
> Just don't expose yourself to bait distros that forces you into spyware.
Strong claims like yours should ideally be backed up with equally strong sources and evidence, otherwise you quickly run out of steam.
> (not even complaining about their shady software choices).
Which are?
For Motorola the management changed while government customers remained the same, perhaps now adding also the Chinese gov into the mix which certainly will "approve" the hardware within. You know this quite well.
I'd happily talk in detail about donors when you first make public the values and donor list for the bigger ones, which you don't for some shady reason and only reveal a few. Even from those few, your biggest public donor are the people well known to dodge real privacy in crypto faster than vampires dodging holy water. Please disclose how much money you pay to the blog/media to shill this project so frequently.
You won't do any of this. You know that, I know that, you know that I know that and still you will continue to profit on those who will never read these comments.
Is the CalyxOS Vs GrapheneOS shitflinging about to start up again?
Not sure where CalyxOS came up in this?
The developers of each have engaged in a few flamewars and the commenter I replied to was critical of GrapheneOS using similar language, so I made a (tongue in cheek comment) implying the commenter was starting the flamewar back up
> a governamental VPN and honeypot, a.k.a. Tor.
Why is tor a honeypot?
I wouldn't call it a honeypot, but it's probably compromised by the feds.
It was shown a few years back that if you control enough of the exit nodes (more than some specific % that I don't remember off the top of my head) then you can associate traffic across most/all of the Tor network. Since running exit nodes is relatively cheap the assumption was that the feds (or some other state actor) were already doing so.
I'd call that materially different than a honeypot though since it wasn't designed for that purpose.
[dead]