Hacker News Reader

Comment by _abox | Hacker News Reader

Yeah GrapheneOS is security over privacy, Calyx is privacy over security (and has a bit more mainstream appeal with MicroG, supporting push messaging and location services etc).

GrapheneOS has also pioneered a lot of security measures, a lot of which have been added to Android proper (if you see their feature log, a lot of it says "removed because it was introduced in Android"). I wonder if that wouldn't have been the case without them pioneering it.

Finally, the big guys make a lot of mistakes too. Remember the time when you could sudo on macOS with a blank password :) Or that other time when they showed your actual password instead of the password hint. AFAIK, Graphene and Calyx have never made any mistakes even close to that severity.

View on HN

Don't privacy and security go hand in hand?

I think the distinction is such that with a private (but not secure) application, the only person getting my data is a malicious actor.

With a secure (but not private) application, the only person getting my data is the owner of the code & anyone they are willing to share it with (Governments, Ad-tech, etc.)

So if your hard requirement is 'nobody can know anything about what I do with this software' you are correct. However in-practice, security requirements often exist somewhere between the above two scenarios.

Yeah. Mostly, the difference is whether you're protecting against big tech or smaller hackers.

The only other difference is that computersecurity also protects your computer as a resource say against mining trojans.

I see it as:

Private = not sending data out of my device unless I want it to.

Secure = resistant to someone trying to get into my device.

They do overlap a bit, to be private a device needs some base level of security. But a device can be very secure and still not be private as it's sending data out for analytics, tracking, etc.

No. First, there are security measures that wreck privacy, e.g. sending all your data to some company's servers for virus scanning. Routing all your traffic through some filtering VPN provider. That kind of stuff. There are privacy measures that wreck security, e.g. not using personalized user accounts for certain things.

Security is also mostly up to definition, a secure computer system is a system that only does what it is defined to do. What this definition entails is up to the vendor, which isn't necessarily the same definition a user might want for security or privacy.

But generally, there is a large overlap between privacy and security.

> No. First, there are security measures that wreck privacy, e.g. sending all your data to some company's servers for virus scanning. Routing all your traffic through some filtering VPN provider. That kind of stuff. There are privacy measures that wreck security, e.g. not using personalized user accounts for certain things.

Aren't those examples more examples of bad security by introducing single points of failure?

Maybe, but there are more examples along those lines that don't introduce single points of failure.

E.g. very all-encompassing logging is generally good for security, and if the logs are stored in a secure fashion, there is also no security problem created. However, privacy suffers because one might log things one shouldn't log.

In the other direction, file and traffic encryption is good for privacy, and the less "permeable" you make it, i.e. the less readable for admins, system task, scanners, the better for privacy. However, for security, encrypting just for the user's eyes is a huge problem, because you cannot do malware scanning, you cannot do exfiltration prevention. Having users bring their own device into a work network is good for privacy, because those devices don't have central admin access, but bad for security, because same reason.

Another way of looking at it:

Privacy is what about you're trying to protect, security is about how you are protecting it.

They don't go hand in hand in real life. Can imagine that happening in digital world too.

Yes, they do, and GrapheneOS is heavily focused on both. The purpose of the project and what it provides is being heavily misrepresented by the comment above.

GrapheneOS treats bypasses of privacy features as security vulnerabilities. It offers substantial privacy advantages of CalyxOS and doesn't come with the privacy drawbacks it introduces. See https://news.ycombinator.com/item?id=28095033 (above) for a more in-depth explanation.

Disclaimer: strcat is the GrapheneOS developer.

He's not "the GrapheneOS developer", he's the lead developer and one of many developers. It's a collaborative open-source project which has made a production-grade OS and whose contributions have been upsteamed for AOSP.

I actually praised you here for pioneering important security features into AOSP :) Please don't view my comments as attacks or Calyx fanboi-ism. I'm not using either and I think you're doing great work. I just wanted to highlight the difference in approach as I saw it as a potential user when I was considering buying a pixel phone.

GrapheneOS, lacking MicroG in the default install, is therefore more private than CalyxOS. Keeping Google out of the loop entirely is necessary for true privacy.

On CalyxOS you do get an option to disable microG when setting it up for the first time, see https://calyxos.org/features/microg/#1-microg-disabled

microG being disabled but present is still enough for some apps to work, which makes sense given that you can disable Google Play Services on the stock OS.

It seems to miss my favourite with Lineage - microG enabled, but C2DM disabled, i.e. services present, but no talking to google servers (but maps api, locations and so on still work).

Disclaimer: I've only read the linked webpage.

You're able to enable microG on CalyxOS while disabling Google device registration and Firebase Cloud Messaging (the current push messaging service which has replaced the deprecated C2DM). The microG Services Core app behaves on CalyxOS exactly as it does on LineageOS for microG.

GrapheneOS has https://grapheneos.org/usage#sandboxed-play-services so our users have the option to use Play services too, in a way that will provide more functionality and avoids losing the security checks and key pinning that are missing in microG. We'll be making it easy for users to install via our app repository rather than bundling Google services in the OS.

Google's Play client libraries are still used on CalyxOS by the apps using Play services. The Ads SDK is a fat library and works without Play services. Only the Lite variant of that has a hard dependency on Play. GrapheneOS isn't giving any additional access to Play when it's installed compared to what the client libraries have available.

WhatsApp is clearly a proprietary service too, and CalyxOS is integrating that into the Dialer app. Signal's server source code is not fully public either and went a whole year without even the incomplete releases that are now available again. Both are centralized, third party services integrated in a special way not available to other apps. Isn't that the problem with Play services? It is from our perspective.

> Google's Play client libraries are still used on CalyxOS by the apps using Play services.

They'd also be used on GrapheneOS, and anywhere else basically.

> WhatsApp is clearly a proprietary service too, and CalyxOS is integrating that into the Dialer app.

The integration is entirely done into the open source Dialer app and generic enough that it could be extended to any apps that have phone numbers. Signal and WhatsApp are simply the most popular amongst those.

>They'd also be used on GrapheneOS, and anywhere else basically.

The issue is that you're giving Google services privilege and integration not available to other apps.

GrapheneOS doesn't ship integration of proprietary services like CalyxOS, whether that's WhatsApp or Google services.

GrapheneOS does have https://grapheneos.org/usage#sandboxed-play-services providing a way to use Play services in a sandbox with zero special privileges. This doesn't provide Play with any access beyond what it has in the client libraries within apps using it. Many of those client libraries aren't simply thin clients. The Ads library works without Play services. There's a special Lite variant that's actually a thin client: https://developers.google.com/admob/android/lite-sdk.

GrapheneOS does this by implement the missing fallback code Play services should have itself to work without any invasive OS integration.

We believe these services should be on an equal playing field. Google services shouldn't be built into the OS and shouldn't have capabilities not available to a regular sandboxed app. Our views are counter to a whole lot of what CalyxOS is doing which is bundling third party apps/services and giving them special capabilities. For example, they give special unattended installation privileges to Aurora Store and F-Droid.

F-Droid still targets API 25 (Android 7.1) which wouldn't meet the security requirements of the Play Store (API 29+) if it could be uploaded there. It also lacks modern cryptography and signing with full file signing + key rotation. Lots of attack surface too. They give it the ability to do unattended app installations without user consent. If it gets compromised in any way, it can install mimic apps, etc. tricking the user. It could install ancient API level apps with the weakest possible sandbox.

Android 12 will be providing a far safer way to do this, and that's what the in-development GrapheneOS app repository client will be using rather than being granted special privileges by the OS. F-Droid is still using partial file signing without key rotation for app repositories too. It does many things that we cannot accept for an app bundled into the OS.

I did not want to get into this, but you're simply spread falsehoods.

> GrapheneOS doesn't ship integration of proprietary services like CalyxOS, whether that's WhatsApp or Google services.

We do not ship anything proprietary. We ship microG, which is "A free-as-in-freedom re-implementation of Google’s proprietary Android user space apps and libraries." - see https://microg.org/

We ship an integration with WhatsApp in the Dialer, which is entirely open source code. It is based on the existing contacts mechanism (anyone who has WhatsApp or Signal on any Android will see entries for those in the Contacts app - that is what we expose to the Dialer to make it easy to use those to make end-to-end encrypted calls.

In fact, WhatsApp is not listed by default, it only shows up if you have it installed. We believe that end-to-end encrypted calls are important, and while this would leak some metadata, if one has it installed already presumably they're fine with that. The network effect is strong!

In fact, you're the one who's promoting your approach of being able to run the proprietary Play Services - and yet you say you don't ship integration of proprietary services. Which is it? You can't ship Play Services legally anyway.

> or example, they give special unattended installation privileges to Aurora Store and F-Droid.

Aurora Store does not get unattended installation permission, it never has. It can only update installed apps, which is what Google is allowing in Android 12.

F-Droid Privileged Extension is extended, and both that and F-Droid have received security audits in the past which haven't found issues - and the Privileged Extension itself hasn't changed much since then. We're very careful about making any changes there.

It is one thing to give constructive criticism to projects, it's another to attack them directly based on falsehoods.

> I did not want to get into this, but you're simply spread falsehoods.

I'm not spreading any falsehoods.

> We do not ship anything proprietary.

You ship integration of proprietary services including Google services and WhatsApp. You provide them with privileged integration unavailable to other apps.

> We ship microG, which is "A free-as-in-freedom re-implementation of Google’s proprietary Android user space apps and libraries." - see https://microg.org/

i.e. an implementation of proprietary Google services.

> We ship an integration with WhatsApp in the Dialer, which is entirely open source code. It is based on the existing contacts mechanism (anyone who has WhatsApp or Signal on any Android will see entries for those in the Contacts app - that is what we expose to the Dialer to make it easy to use those to make end-to-end encrypted calls.

i.e. integration of proprietary services into the OS in a way that isn't available to other apps.

> In fact, you're the one who's promoting your approach of being able to run the proprietary Play Services - and yet you say you don't ship integration of proprietary services. Which is it?

GrapheneOS does not include any form of Play services and has no support for the OS using it. If a user installs Play services, the OS detects it and intercepts the attempts it makes to use privileged APIs and instead returns placeholder data.

With microG, the Play services code is still present in each app using it. microG is an additional trusted party, not implementing the same level of transport security or other security checks and does not avoid trusting the Play services code to exactly the same extent.

> You can't ship Play Services legally anyway.

Not actually true. Do you claim that stuff like firmware cannot be shipped too?

> Aurora Store does not get unattended installation permission, it never has. It can only update installed apps, which is what Google is allowing in Android 12.

No, they're allowing it in a more secure, restricted way rather than what is implemented in CalyxOS. Look at the list of requirements for an unattended app update via the Android 12 API.

> F-Droid Privileged Extension is extended, and both that and F-Droid have received security audits in the past which haven't found issues - and the Privileged Extension itself hasn't changed much since then. We're very careful about making any changes there.

Shallow security audits in the past is meaningless. F-Droid is an API 25 app (Android 7.1) with a a metadata signing system with the same weaknesses as Android's deprecated v1 signature scheme and massive attack surface. It bypasses the standard OS security model for determining sources of apps rather than respecting it. This is incompatible with the expected the security model for unattended app updates in Android 12.

> It is one thing to give constructive criticism to projects, it's another to attack them directly based on falsehoods.

I'm not doing that. Rather, that is what you folks have been doing at every opportunity in these threads. I've only posted here to defend us from malicious misinformation being spread by you folks. You're engaging in that yourself and can't claim to be uninvolved.

I'm really tired of this.

> GrapheneOS does not include any form of Play services and has no support for the OS using it. If a user installs Play services, the OS detects it and intercepts the attempts it makes to use privileged APIs and instead returns placeholder data.

Isn't that shipping an integration for a proprietary service?

How can you claim that we're the ones shipping proprietary service integrations when we ship an open source implementation, and you're the ones shipping an integration for the proprietary implementation.

I'm done here, there's no point arguing with you, you don't see reason.

> Not actually true. Do you claim that stuff like firmware cannot be shipped too?

There is precedent here, https://phandroid.com/2009/09/25/cyanogen-gets-cd-from-googl...

It's the sole reason why there exists the concept of flashing gapps are installing other custom ROMs, and that cannot be supported without verified boot.

The other way is what you're doing, which is impressive, not questioning the code / implementation, just the way you're trying to present it here.

>How can you claim that we're the ones shipping proprietary service integrations when we ship an open source implementation, and you're the ones shipping an integration for the proprietary implementation.

Play Services is not integrated into GrapheneOS at all. It only has a few shims that, as strcat explained several times, return placeholder data. Play Services has no special permissions, and using it on GOS is the same as installing any other app.

microG is integrated into your OS. It's a partial reimplementation of proprietary Play Services.

>There is precedent here, https://phandroid.com/2009/09/25/cyanogen-gets-cd-from-googl...

That was for distributing Google apps, not for shipping firmware updates. You're making a false comparison.

As you could see if you had read strcat's comments and the documentation, GrapheneOS doesn't ship Play Services but only some compatibility shims, otherwise Play wouldn't know how to work. Users must manually install Play and associated apps.

//GrapheneOS is security over privacy// Is this just in philosophy or are there actual concrete privacy features/things I can't do with Graphene?

> Yeah GrapheneOS is security over privacy

No, GrapheneOS is heavily focused on both privacy and security. See https://grapheneos.org/features for a list of the enhancements compared to the latest Android Open Source Project. GrapheneOS offers substantial privacy advantages over CalyxOS. It has a bunch of nice privacy improvements, carefully designed to work against real adversaries. Bypasses of privacy features are taken very seriously and prioritized as security vulnerabilities. GrapheneOS also doesn't integrate proprietary apps/services into the OS. We'd never stick WhatsApp support in the Dialer or ship Google services integrated into the OS in a special way not available to other apps. Services should be on an equal playing ground. That's the real issue with Play services and with iOS too.

GrapheneOS has full MAC randomization, DHCP anonymity and doesn't reuse IPv6 addresses across networks.

GrapheneOS has the Network permission toggle for disallowing both direct and indirect network access. Calyx takes an approach that allows apps to bypass it via APIs gated by the INTERNET permission. It also has other bypasses. They present it as a firewall app with a fancy name, but it's just a UI for the AOSP firewall and it doesn't really work as they present it. https://gitlab.com/CalyxOS/calyxos/-/issues/454 acknowledges the issue but presents an unworkable plan to address it. The approach doesn't work. Similarly, fine-grained filtering of domains/addresses in most firewalls even as a whitelist doesn't work due to DNS acting as 2-way communication via a permitted IP to arbitrary third parties. These indirect forms of access can't simply be ignored.

GrapheneOS has the Sensors toggle to disallow apps from accessing the miscellaneous sensors usable for coarse movement (which can map to location) and audio recording among other things.

It has substantially privacy improvements beyond these things, but they're some nice examples. I strongly recommend looking through https://grapheneos.org/features and keep in mind it does not list AOSP features as most projects would. Avoiding bundling third party apps and services is explicitly listed as a feature rather than listing out integrating proprietary services and assorted apps.

GrapheneOS is also focused on usability, and it's hard to deny that https://grapheneos.org/install/web is a very nice way of performing the install. The fastboot.js library powering it is a project we funded.

> and has a bit more mainstream appeal with MicroG, supporting push messaging and location services etc

Location works properly on GrapheneOS, as do notifications.

https://grapheneos.org/faq#notifications

GrapheneOS has a sandboxed Play services compatibility layer for running Play services with zero special privileges:

https://grapheneos.org/usage#sandboxed-play-services

Despite being very new, it's already rapidly moving beyond what microG supports. It doesn't require making the security sacrifices of microG by losing the standard security checks and key pinning. It also doesn't make privacy sacrifices: it provides Play with zero additional access. Apps using Play include the Play client libraries. Many of these fully work without Play services installed, including Google's Ads library. That only has a hard dependency on Play services if apps use the Lite variant: https://developers.google.com/admob/android/lite-sdk. The claims about microG privacy/security benefits are not just overstated but backwards. It also only implements a tiny subset of the API.

Sandboxed Play services compatibility layer is another much more broadly application project funded by us, among others.

> GrapheneOS has also pioneered a lot of security measures, a lot of which have been added to Android proper (if you see their feature log, a lot of it says "removed because it was introduced in Android").

We're also implemented a lot of substantial privacy measures. There aren't really distinctions between these things. GrapheneOS helped get substantial app sandbox restrictions into AOSP restricting the information available to apps.

Can you please stop attacking another Android distro under the umbrella of a project (the Calyx Institute) that has done a lot of good for others? It makes you look like an a**hole.

There's plenty of room in this space for multiple visions of what a more-secure, more-private Android OS looks like. There's gradations of privacy and security and some users might prefer your gradient, whereas others might prefer CalyxOS'.

You might try getting your act together and reach across the aisle so the world can benefit rather than this frankly stupid and childish infighting.

And to pre-empt your honestly terrible, "but they started it", I don't see anyone from Calyx giving the mouth you're giving them, repeatedly, in this thread about their product. So please just stop.

Your comment leaves out the danger of advertising security and privacy when you cripple those things.

All open source projects should be able to take GP's criticism, dev of "competitor" or otherwise — specifically because they're not products — they're public projects.

Both projects should absolutely be encouraged — and steered, if a user knows a better way.

> Your comment leaves out the danger of advertising security and privacy when you cripple those things.

Nobody is doing this. Calyx is taking a measured approach, as they see it, and is making commensurate claims: "CalyxOS is an Android mobile operating system that puts privacy and security into the hands of everyday users." Right on their website.

I am vehemently against absolutisms on security. Where that road goes is straight into a dick measuring contest and it's ugly. You only have to look at Moxie's terrible public behavior to see what the fallout from that approach looks like.

It's a poison in the security industry and it needs to be called out and stopped now. It rewards grown adults for acting like children. It's enough now.

> You only have to look at Moxie's terrible public behavior to see what the fallout from that approach looks like.

Cite Torvalds' absolutism on not breaking userspace, too, while you're at it..

These projects are all forwarding their missions; it's not because they listened to your criticism about being too absolutist on goals they are passionate about.

The "dick measuring" you're seeing is how any niche group quickly scrambles to sift out the "truth". Geopolitics research threads, when airplanes go down mysteriously, new longboard gets released, whatever — the smartest people go back and forth with (at?) each other¹ until some form of consensus is reached, and the "herd immunity" or general knowledge of the community is improved.

¹(sometimes with far less civility than in this case!)

> about being too absolutist on goals they are passionate about.

Not at all what I mean when I say I am vehemently against absolutisms on security. Any claim to superiority on security and subsequent trashing of others is rotten because it's not kind, not compassionate, not conducive to cooperation, the single greatest tool we have as humankind. We don't need more division in this space and we don't need people with a headful of their egos being affirmed for bad human behavior.

There are better ways of being critical of others without being an a**hole in public. That's the thrust of my argument. We'd all do well to hold these people to a better standard of behavior.

It can be plainly see that we were responding to the brigade of attacks from the CalyxOS group involved in spreading misinformation about GrapheneOS across platforms. You're responding to one of them above.

You don't see LineageOS, /e/ or countless other operating systems constantly spreading misinformation about GrapheneOS. It's only CalyxOS. Others are not doing this. I' not sure why you folks can't resist the urge to attack us with false claims any time either OS is mentioned anywhere.

See https://github.com/bromite/bromite/discussions/1186 for an example of what is being done on a regular basis. These impersonation attacks are currently ongoing on Reddit and Telegram.

All you've done is expose your paranoia with this (and the other down thread) comment. I'm not affiliated with the vast conspiracy you've concocted in your head.

I'll tell you what though: I see people who think they can throw their clout around (DevOps Engineer from Denmark, hi) every day in my line of work. I make a habit of telling them they better act like adults if they hope to cut it.

Look through my comments history and you'll see I don't take kindly to people like Moxie, like you, thinking you get to push people around because you think you're better. That time is over. You can lord over your tiny fiefdom all you want but the rest of the industry is done taking it.

The future is human cooperation and dignity, not this paranoid, egoic trip you're wrapped up tight in.

I suggest you work together with the broader community and don't fall into useless, divisive attacks on people engaged in the shared enterprise of a more-secure, more-private OS.

No, giving criticism of an OS is not attacking it. You'll see that strcat only responded to places where GrapheneOS was mentioned. You'll see that there was misinformation being spread about GrapheneOS, whether intentionally or unintentionally, that originates from the Calyx community. Just look at their Matrix rooms and what their supporters/influencers say about GrapheneOS.

Bundling a bunch of apps and integrating proprietary corporate services with privileges unavailable to other apps is not privacy, sorry.

If you have the ear of strcat, I urge you to to talk to them about this kind of paranoid conspiracy thinking that leads them to directly accuse me (and others in this thread) of being a co-conspirator in a vast plot to undermine GrapheneOS. It's fantastic thinking and it damages the reputation of what is otherwise a gift to the community.

I have been on Hacker News a long time, posting on everything from sex worker rights to Telegram to Emacs. I don't know about your Matrix room, I've never visited it. I have no interest in impersonating anyone save myself.

> You'll see that there was misinformation being spread about GrapheneOS, whether intentionally or unintentionally, that originates from the Calyx community.

I don't see that anywhere here in this thread. I see a thread that should have been a space for celebrating a cool more-private, more-secure Android project being hijacked because its competitor's lead developer believes themselves to be the target of a conspiracy. A conspiracy that isn't even occurring in the very thread they're engaged in:

> I've only posted here to defend us from malicious misinformation being spread by you folks.

From who? Nobody here is doing this! Especially maliciously.

If you think CalyxOS is implementing a feature that is harming users, you might try and communicate with their community in a cooperative, direct way, rather than this self-destructive crusade GrapheneOS is airing publicly.

I think you and strcat owe everyone here in this thread an apology.

>If you have the ear of strcat, I urge you to to talk to them about this kind of paranoid conspiracy thinking that leads them to directly accuse me (and others in this thread) of being a co-conspirator in a vast plot to undermine GrapheneOS. It's fantastic thinking and it damages the reputation of what is otherwise a gift to the community.

It's not conspiratoral thinking. It's plainly obvious if you go into the CalyxOS Matrix rooms that the leaders often spread misinformation about GrapheneOS or allow it to flourish. They also spread misinformation about CalyxOS to promote it, such as claiming signature spoofing has no security drawback as implemented on CalyxOS.

You don't see other OSes and projects spreading misinformation. Likewise, GrapheneOS doesn't attack LineageOS, /e/, etc. we don't discourage people from using them, except saying that yes, they are insecure, so be aware of that. We don't spread attacks and other projects are free to criticize GrapheneOS for legitimate things.

However, criticizing it for legitimate things is far different from concern trolling in the GrapheneOS rooms, getting banned, and then portraying it in the Calyx rooms as GrapheneOS being toxic, which is a common tactic. You can see this using the Logbot service: just look up "concern troll" in the GrapheneOS rooms, see what comes up, and compare it with the messages around the same time in the Calyx rooms. It's quite evident. Of course, I highly doubt you'll sincerely do that considering you're simply calling us paranoid, but to anyone watching that's what you should do.

>I have been on Hacker News a long time, posting on everything from sex worker rights to Telegram to Emacs. I don't know about your Matrix room, I've never visited it. I have no interest in impersonating anyone save myself.

No one said that you impersonated anyone. The point strcat brought about impersonation was that a person from the Calyx community went and impersonated the Bromite developer, attempting to start conflict between Bromite and GrapheneOS.

>I don't see that anywhere here in this thread. I see a thread that should have been a space for celebrating a cool more-private, more-secure Android project being hijacked because its competitor's lead developer believes themselves to be the target of a conspiracy. A conspiracy that isn't even occurring in the very thread they're engaged in:

CalyxOS isn't particularly secure but that's beside the point. That's not the issue and it's fine to not be security-focused. The issue is that the Calyx community and developers consistently spreads misinformation. Just look at what one of them is doing right now with microG.

>From who? Nobody here is doing this! Especially maliciously.

Says the person calling people paranoid for trying to stop misinformation being spread. You can see what people are doing in this thread whether maliciously or nonmaliciously.

>If you think CalyxOS is implementing a feature that is harming users, you might try and communicate with their community in a cooperative, direct way, rather than this self-destructive crusade GrapheneOS is airing publicly.

And people have, and they get banned from their community.

> The point strcat brought about impersonation was that a person from the Calyx community went and impersonated the Bromite developer, attempting to start conflict between Bromite and GrapheneOS.

The chat logs[0] say different.

I don't see how one person joining a room on Telegram somehow implicates the whole project in some sort of conspiracy to attack / spread misinformation about Bromite or GrapheneOS.

[0]: https://github.com/bromite/bromite/discussions/1186#discussi...

You can easily see that this person was welcomed in the rooms. No one went against it and the CalyxOS developers started going along with it.

* the founder Nick participated in it, the developers didn't.

He was told to stop talking. Not sure what else there is to say.

> They present it as a firewall app with a fancy name, but it's just a UI for the AOSP firewall and it doesn't really work as they present it.

There is no AOSP Firewall, this is all based on code which originated in LineageOS, and we've been maintaining and extending it since about a year now. We make changes, send patches back upstream (LineageOS), and are talks in that developer.

The bypass is serious, we're looking into it and will have a working patch available shortly. It will work.

We do not muck around with the INTERNET permission and change the android permission model since that has known to crash apps, we did evaluate it before putting effort into this.

The beauty of doing this network side is that apps are unaware and keep working, unlike some apps which crash when you take away their INTERNET permission - that is why we didn't go with that approach.

What use is a toggle if it crashes the app and makes it unsable.

> The fastboot.js library powering it is a project we funded.

Thank you for funding that!

Remember the time when you could sudo on macOS with a blank password :)

Apple paid out a lot of free sandwiches on that one [0] Internationalization on that command was a mess though. Defaults were based on OS settings and the flags to override were based on a combination of country & postal code rather than the localized name of the ingredient.

So, if I didn't want the default of an American cheese sandwich on white bread with mayo, I had to research each bread, meats, and cheese lineage to get, for example, provolone using the switches -c IT -r 26100. It got worse if you wanted multiple cheese types.

In the end I just aliased a bunch of options. My favorite was meatloaf w/ swiss cheese... I have no idea where Apple sources their meatloaf for the US region, but I haven't had anything like it since. The cafeteria staff at Apple HQ have stopped taking my calls.

[0] https://xkcd.com/149/

Reply on news.ycombinator.com