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.
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.
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
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
"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
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.
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 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.
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.
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.
A distro with shady revenue sources (check for yourself) with shady hardware restrictions that only permits to use spyware phones from google, or recently, after years of complaints now permits you to use hardware from an NSA long time contractor. No, claiming that some magic hardware makes you more secure is not a valid reason when you are using hardware where they have every reason to track you even further. Saying "nothing was found so far" is no excuse, NSA takes pride that their bugged devices run that way for decades until finally admitting.
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.
Just don't expose yourself to bait distros that forces you into spyware. It is already difficult enough to preserve some sense of privacy on modern tech. Consider other distros which are also popular and without this hardware non-sense (not even complaining about their shady software choices).
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.
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.
Just like manifest v3, it's not in their best interests to disallow snooping. It hurts their business model.
> 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.
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.
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
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.
Even more so, just like meta removing end to end encryption.
"Nah dog, we like watching everything you say and do."
> 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
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...
> 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.
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.
There should be at least one Motorola phone before end of the year that has GrapheneOS support.
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
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.
> 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!
So far. Other companies surely will make their devices compatible if the market share increases for it
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.
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.
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.
They're paid not to.
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.
Corporations have no pride. They are soulless, psychopathic accountability sinks.
What planet are you from?
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.
Don't buy Pixel 10a, 9a is almost exactly the same thing and still sold new.
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?
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.
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.
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.
"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
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.
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.
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?
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.
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...
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.
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 truly independent solution is GNU/Linux. Sent from my Librem 5.
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.
It wasn't patched by Google because it's a backdoor. For various reasons, modern mainline Android is substantially hazardous to use.
A distro with shady revenue sources (check for yourself) with shady hardware restrictions that only permits to use spyware phones from google, or recently, after years of complaints now permits you to use hardware from an NSA long time contractor. No, claiming that some magic hardware makes you more secure is not a valid reason when you are using hardware where they have every reason to track you even further. Saying "nothing was found so far" is no excuse, NSA takes pride that their bugged devices run that way for decades until finally admitting.
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.
Just don't expose yourself to bait distros that forces you into spyware. It is already difficult enough to preserve some sense of privacy on modern tech. Consider other distros which are also popular and without this hardware non-sense (not even complaining about their shady software choices).
Stay safe.
> 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.
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?
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.