I installed LineageOS and found I couldn't run some google apps. I reinstalled LineageOS with https://opengapps.org added during the install and made the mistake of transferring from my old phone which brought all the google services and everything back to the phone (mostly).

I then installed CalyxOS - much easier install process than lineage. Really liked the defaults. Could not get many apps that relied on google play services though. If I didn't need so many Google-tied apps I would pick this as my phone OS for basic stuff like messaging and browsing.

Installed LineageOS again, found there were a couple apps I could not get working after all (50 different apps installed).

In the end I gave up and re-flashed Google firmware back onto the phone. I spent about 10 hours on all this stuff and simply ran out of time for now. I though I could get away from Google but I didn't realize how much my apps needed Google.

> I reinstalled LineageOS with https://opengapps.org added during the install and made the mistake of transferring from my old phone which brought all the google services and everything back to the phone (mostly).

I think you have misunderstood what "opengapps" is. Despite the name, it's just a zip that installs Google services and apps (Google framework, play store, etc)

This is done by design to lock developers in and by proxy, lock users to Google flavored Android OS

YouTube can be replaced by NewPipe and these days I'm trying Organic Maps (a layer for OSM with nav and offline maps) to replace Google Maps.

[0] : https://microg.org/ [1] : https://lineage.microg.org/

EDIT: for clarity, by "micro Google apps bundle" I mean the opengapps [1] micro variant.

[1] https://opengapps.org/

That doesn't sound right.

FAQ on using LineageOS with a locked bootloader: https://www.reddit.com/r/LineageOS/comments/n7yo7u/a_discuss...

Some Android distros, including CalyxOS, are only intended to be used with a locked bootloader, and support over-the-air upgrades without needing it to be unlocked.

It started with this rejected PR: https://github.com/TeamNewPipe/NewPipe/pull/3205

1. uBlock Origin 2. Video Background Play Fix add-on

This allows me to use YouTube as a background playback music player.

I still use the Firefox option if newpipe has issues fetching the video (which didn't happened to me for a long time).

It's a preference thing, many options are great.

OsmAnd is much more fully featured, especially if you are using it to contribute data to OpenStreetMap. With OsmAnd Live, you can download hourly updates to OpenStreetMap data, while Organic Maps updates at less frequent intervals. The app supports plugins for additional functionality, including trip recording, Mapillary street view, and various map views (such as nautical and ski views).

There's no harm in having both installed, since they have different strengths.

I used OsmAnd for quite a long time and just wanted to give Organic Maps a try to see other alternatives. Both are quite promising as replacing Google maps IMO.

I'm using SmartTubeNext. It's great. Haven't tried NewPipe, anyone have a comparison?

Lineage might be more privacy respecting than Googles Android, but far behind regarding security.

CalyxOS and GrapheneOS are the only real options (because they support relockable bootloaders) if you dont want to use Googles Android.

MicroG is another really unstable experience. Google bought KaiOS and will buy the next KaiOS too. They moved and continue moving features to their proprietary castle. There's just no way you can win this fight against Google.

Long term the only solution is by some miracle a FOSS phone gets enough popularity for developers to want to make apps for it. I doubt it. My solution is unfortunately using two separates phones. Android and a FOSS one.

SafetyNet) Nothing can legally pass it unless Google certifies it, we can't do much, only Google can enforce it to be used only for security related reasons

Bribing) I wish I got a single cent from any of the OEM I worked on, name it, Motorola, Asus, Huawei, OnePlus, Xiaomi. Not once they threatened us to stop working on their devices, and at the same time didn't help at all ( the only outsider is Asus that is willingly to help ) We simply can't continue supporting every device that enters the door, we don't have any real way to improve it, everyone is doing it voluntarily with no expectation, and so do we as project directors.

PS: I'm one of the directors.

I know that but it was the main selling point of the ROM for me. Also that I didn't even need a firewall because you could block network access.

>SafetyNet

I was commenting from the POV of a user who needs apps that demand SafetyNet access. You're right.

>Bribing

I was talking about ROM developers on e.g. XDA, not LineageOS the "company".

3) Never heard of this happening, and I've heard a lot of stuff.

The LineageOS folks have a very difficult job to do, they must keep up with developments in AOSP while supporting dozens of existing hardware models, each with its own "exciting" quirks. Is it really any wonder that some hardware gets dropped from official support? Usually that just means bugs have turned up which would make LineageOS not fully usable on the hardware, and they don't have the volunteer manpower to address them.

Complaining about SafetyNet and microG is even less understandable, as these will always amount to unsupported hacks and we don't really need them for a usable device. Just get your apps from F-Droid, and you won't have to care about either.

Lineage is also so frigging annoying how they just drop old phones. They won't even provide the last good build or previous builds. Really bad thinking over there in general I guess.

:(

https://github.com/microg/GmsCore/issues

In case I run into a similar issue as you - what turned out to be Google-tied apps you weren't able to do without?

If anyone is interested in building their own custom android OS in the cloud (AWS) with same ability to lock your bootloader like CalyxOS, you can checkout my project I've been maintaining for a few years now called RattlesnakeOS: https://github.com/dan-v/rattlesnakeos-stack.

And if you prefer to not build in the cloud, there is also a really great project called robotnix (https://github.com/danielfullmer/robotnix) which provides a way to build many flavors of OS (AOSP, GrapheneOS, LineageOS, etc).

Now granted, those were heavyweight specs when Android came out in 2007, but I'd figure about half of us probably have a similar box sitting around today, and the other half would just need to beef one up with some additional RAM.

The idea might seem daunting, but assuming midrange hardware and a decent net connection, it's very much doable in under a day without resorting to cloud services.

The build process supports the -j option just like make. You can use -j N+1 if you want to keep all your cores busy, or -j N-1 to keep your machine more responsive during the build, or nice and -j 1 if you're in no hurry and your machine has more important tasks. (Actually, I think reasonable defaults for these might already be part of the build scripts, but it has been a while since I looked.)

When you want to build again, create the instance and then recreate the EBS volume from the snapshot and attach it to the new instance. Pull the latest set of changes from the git repo and build with the old cache!

Obviously there are cache purging considerations (e.g. starting from scratch once per week/month) you could optimise as well.

https://source.android.com/setup/build/downloading

Although, an answer at https://stackoverflow.com/questions/33053615/how-to-download... from October 2020 says that even a partial clone is still 73 GB in size!? That’s insane! How the heck come it’s so big?

I just ran the command here and my AOSP 11.0 checkout is 54GB, minus any git history, since I clone from a local mirror and use '--reference' to avoid having to copy objects.

A lot of the size here is from the various prebuilts, AOSP build is quite self-contained (jdk, clang, etc) and barely uses anything from the host.

Access to the network is only possible through wifi pucks. I asked if I could register the IMEI of my ThinkPad's modem/radio, but they wouldn't allow it citing the usual "we are responsible for the behavior of the devices on the network so you have to use our certified device". Sadly, these phones do not participate in Calyx's data network, they require a traditional carrier. Maybe it's part of their roadmap to eventually offer their data services on these handset form factor devices? But until then, I don't see a huge point. It would be really awesome to say "I get my network access through a privacy oriented non-profit" (:

I got the impression when signing up that it was Sprint's terms that limited their ability to offer to other devices but they would if they could.

Looks like $500-$600 for 4G, and $750 for 4G/5G. Could be a good deal for certain people. But yes, it's lame you have to use the puck.

If this is true, I’m not surprised there’s a pivot to an unlocked phone without a bundled subscription with Mobile Citizen/Calyx.

Why is T-Mobile shutting down Sprint’s old LTE equipment a problem? They say that the hotspots will "roam to T Mobile when Sprint is not available"

I've said it before and saying it again on here for those that don't know: microG breaks the security model on android and adds in package signature spoofing. It's the only way to add a fake Google Play Services without needing to pull Google blobs. This is why projects like LineageOS are against using this method, it weakens overall package security.

However, it is still possible for the tinfoil hat crew to not use Google play services with OS like LineageOS. This will of course break some functionality (apps will have to poll instead of relying on push) but it will not break the security model.

I'd like a different, better set of options to choose from but we don't have it at this time. Most users should probably choose a minimal Google Play distribution if they value things like battery life and working apps while still maintaining protections against spoofed apps.

The microG creator goes into more detail about signature spoofing at https://github.com/microg/GmsCore/issues/1467#issuecomment-8... The concerns usually raised against that are due to the "default" patch included in their repository, which has a specific purpose.

We don't use that, https://calyxos.org/about/tech/microg/ are the precautions we take to try and prevent "weakening overall package security"

In addition, microG is optional and can be disabled on first install, see https://calyxos.org/features/microg/#1-microg-disabled

As someone who also accidentally pastes my local dev URLs from time to time, I feel your pain ;)

For everyone else: that's https://calyxos.org/features/microg/#1-microg-disabled

I would like if there was stronger privacy laws or antitrust orders that force Google to open their service provider API's so people can choose alternative location/push providers, but this doesn't seem like it will exist soon.

For many users, it's going to be the best usability compromise to use minimal play services and use apps that don't send content over the push networks (signal is like this, element can be configured this way).

It does not, you can update system-apps out of band just fine.

Google does it with Play Services (and many other apps), and we have our microG builds in our F-Droid repos for out of band updates.

In fact, that is one of the big selling point of Play Services - the fact that it gets updated outside of OS updates, which means that you have a recent / the latest version on all devices regardless of their update record.

And therefore anything implemented in Play Services can be used even on older Android versions.

Everyone knows that.

I'd like to see people make their own apps that don't rely on Google services (or faked Google services) of course, like the Linux ecosystem.

Also, for this reason I shy away from alternatives to LineageOS which include microg by default. I don't want it.

It seems like what we really want here is for the app to implement its own notifications without going through Firebase. All you need for push rather than polling is an open socket...

Do push notifications require microg/google? A communications device (as opposed to a media player) that didn't have push notifications would be missing something required, in my use.

It's my understanding that alternatives to google's location services exist.

I'd just like a phone that allows me to chat/use apps/gps (let's put cell service to the side of a second) without being an OS-wide, logged-in, analytics tracker.

I think about it this way: Should I trust

A. The company which has thousands of developers working on it and wants to avoid their brand being dirtied by failures in security and privacy.

B. The small group of people who have formed an organization which may or may not be another Anom like FBI controlled software.

Don't get me wrong, I absolutely want to pick B, but I consider it much more risky since there are a lot more unknowns around that. At least with A I know what I'm getting (basically a free flow of my info to whichever government asks for it, but cross my fingers they don't ask for it or that A doesn't want too broad of a breach of trust).

Let's say I do have the infinite amount of time necessary and the technical expertise to conduct an audit of a custom ROM. Is every single person who's interested in privacy and security required to do their own audit?

If I publish my findings, why should anybody ever believe me? Who am I to tell anybody how safe it is? If you think it's so safe, why don't you do an audit and prove it to those of us with doubts instead of expecting us to do it?

Oh, right. You're operating on faith on these groups of people that you don't know who don't have any processes in place to ensure that what they're doing is safe for their users.

I'd very much like my next phone to run Linux (i.e. be a Pinephone) though.

I like the idea, but it's a deeply frustrating experience right now. Basic table-stakes features I have come to assume from both Android and iOS platforms just aren't there yet.

It's a frustrating chicken egg problem... I want the thing to succeed, but my smartphone is so critical to my day-to-day that I can either wait for it to get better or invest the time into having it suck on toast while I improve it.

I'd also have to figure out some more specifically personal stuff like alternatives or Matrix bridges for apps I 'need to' use to communicate with certain people.

Why again? Android is already free and open source and Linux doesn't have good answers for the proprietary goodies

It's not without trying either, I've worked on and off on a terraform provider for Android - currently apps only but with some vague intention to try to manage as much of settings as possible (not much, AIUI). It's just not meant to be used like that though, of course, and I wish Linux was a viable enough option that, at least among nerds already using Linux for work if nothing else, it didn't need to be justified for use on phones.

It doesn't need to. The feasible short-term target is feature parity with de-googled AOSP roms, which would still make it plenty useful in a "daily driver" scenario.

Nevermind that many of the apps that Google ships as part of Google Play are not receiving security audits outside of Google, Google is not committing to regularly audit their apps or publish the results, and these apps function as black boxes on your phone, with privileges that most other apps do not have.

This is the real problem, not the lack of security audits.

It is depressing, but phones are unique in that they need to work flawlessly in an emergency which I think is a factor in preventing people from straying from the path "well-travelled".

This is much to my lament as well, because I would love to feel more free to experiment with phone operating systems and hardware addons.

The reputation of Nick Calyx (worth a look his Wikipedia page), or GrapheneOS team, etc, is so much easier lost than that of, say, Google's Android team.....or iOS security team.

Having said that: Calyx shouldn't be considered much more secure than Android Open Source Project (AOSP). That's where GrapheneOS shines.

Calyx should, however, be considered more private than AOSP, less dodgy & exploitable than Samsung etc Android "enhancements", aka UI/UX bloatware.

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.

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.

Aren't those examples more examples of bad security by introducing 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.

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.

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.

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

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.

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

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.

> 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'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.

> 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.

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.

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.

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.

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.

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

Disclaimer: I've only read the linked webpage.

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.

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.

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

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.

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 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...

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.

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.

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!)

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.

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.

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!

For those struggling to do this: "Nicholas Merrill" is the name you'll need to look up on Wikipedia.

For example: Calyx provides MicroG. This means you can talk to Google Play services, though in a better, more privacy-conscious way. MicroG is an open implentation of Google Play Services.

However, MicroG requires signature spoofing: You need to install a fake Google certificate so that it can trick official apps into thinking they're talking to Google Play Services directly. This could technically be abused, though Calyx takes lots of precautions to prevent that. GrapheneOS with their security-first approach don't deem this worth the risk. So with apps requiring play services you don't get push messages and network-based location checks, among others.

So, do you want an allround phone to use everyday (and use things like Uber, Facebook, etc) but more private and secure than AOSP, take Calyx. Do you want security over everything and are willing to compromise a bit on functionality and app compatibility (some apps will refuse to run without google play), pick Graphene.

Either way you'll need a Google Pixel by the way.

The concerns usually raised against that are due to the "default" patch included in their repository, which has a specific purpose.

We don't use that, https://calyxos.org/about/tech/microg/ are the precautions we take to try and prevent abuse.

I made it a privileged permission because that's a standard Android thing to gate things (such as reading of IMEI) - My thought process being that if you somehow managed to get around privileged permissions, we have much bigger problems than signature spoofing.

I just wanted to highlight the difference in focus, GrapheneOS will always pick the security side when a compromise needs to be made. Another example is the "We don't lie about security features" stance about SafetyNet. Even though a GrapheneOS phone is arguably more secure than a random manufacturer-modified Android rom. I agree that signature spoofing has an unnecessarily bad name. Probably because some mainstream roms like Lineage eschewing it. Personally I think it's a great tradeoff between privacy and functionality.

I want a phone that respects my privacy and is secure, but I also want to use apps like Google Photos (my favorite app that I use more than anything, aside from Firefox), Lyft, Netflix, Slack, banking apps, airline apps, and, critically, Google Pay.

I get that using many of those apps might increase my exposure to tracking and privacy leaks, but I just want an OS behind them that I know I can trust in isolation, and that may have measures in place that at least try to mitigate some of the worst privacy abuses from the apps. (And if it can't always succeed at that, that's fine, I'll live.)

Meanwhile, my only real choices are stock Android, which I know I can't trust to protect my privacy (since Google's business model depends on that), and iOS, which will treat me like a child and not let me do what I want with my phone unless Apple approves. (I'm also really concerned about the privacy implications of Apple's plan to do client-side scanning for CSAM material, assuming that's true.)

So I just don't feel like there's anything out there right now that will let me run the apps I want, that is built in top of an OS that I feel I can trust. Calyx seems to be one of the few I've seen that looks like they're actually trying to be that.

Alternatives seem to be Owncloud and Nextcloud, which have hosted options. I don't really want to self host but nice to have the option. Does anyone have experience with their android apps for photo storage as compared to Google photos? In particular autobackup and image scaling/compression would be nice.

I use ProtonMail and have started fiddling with their new calendar offering, I was half hoping they might have some encrypted storage service in the offing...

Some non-Twitter prose about the Play Services support (though it doesn't include the tweeted info about dynamite support being nearly finished): https://grapheneos.org/usage#sandboxed-play-services

Upgrading to a new-to-you few-hundred dollars Pixel every 2-4 few years isn't anywhere close to the expense of a new $600-$900 phone every 1-3yrs, the way people used to (and the way iPhone users still seem to).

(disclosure: I co-develop a FOSS TrackerControl alternative)

TrackerControl has a tad better UX; is built on top of the super-stable NetGuard and hence inherits its flaws and merits.

For instance, it does not support DoH/DoT/DNSCrypt.

It also leaks DNS connections over TCP (this happens when a DNS question or answer payload is too big to fit in a single UDP packet). In fact, all userspace DNS clients on Android I have taken a look at, leak DNS queries over TCP.

TrackerControl does not trap all packets over port 53, which RethinkDNS does by default.

TrackerControl isn't geared towards bypassing censorship. RethinkDNS can bypass stateless firewalls employing a similar trick to GreenTunnel, and we plan to implement a couple more such mitigations.

Unimplemented but soon, RethinkDNS would let users block connections if apps don't resolve DNS with a resolver of their choosing.

RethinkDNS has open-sourced both its client app and a pi-hole like stub resolver: https://github.com/serverless-dns/serverless-dns

There's three of us working on RethinkDNS full-time, so it is likely to see feature development at a faster clip than TrackerControl and NetGuard (the latter's been put under maintanence mode by its original developer).

This should be advertised as major feature.

I'd be interested to see how you draw this conclusion. I have been in the CalyxOS rooms for quite a long time and have never seen anything of the sort. In fact, when GrapheneOS is mentioned, users are told to change the topic.

> In fact, when GrapheneOS is mentioned, users are told to change the topic.

Yes, people get banned when they defend GrapheneOS from attacks. Nothing is done when they spread misinformation about it as long as they don't do it too blatantly. Action is quickly taken if someone there tries to counter it.

You've said this a number of times, but you've yet to provide any material evidence this has taken place.

From what I've seen as an impartial bystander, the CalyxOS community doesn't want anything to do with you or your (frankly hostile) community.

I've taken the liberty of doing a little digging and asking around, and it looks like you've even tied in CalyxOS to the recent Bromite impersonation incident. Judging by the chat log you shared on GitHub, it looks like the user was told to change the topic.

I really don't think it's appropriate to be downgrading and "attacking" (as you so vehemently protest) open-source projects like CalyxOS with similar goals. It's a shame such hostility is taking place, when both Calyx and Graphene are doing excellent work in the privacy sector.

I've done that all this time, the only time I comment on something is when somebody asks us to integrate it into CalyxOS, and that's only within our context.

You're the one here who're responding in a hostile manner, and doing exactly what you're accusing us of. Please stop.

>I would trust MicroG a lot more than Google, even if it's sandboxed :)

This is the reason that GrapheneOS sandboxes it. You can disable permissions however you'd like, nothing stops you. You don't want it to send certain data? Then don't give it that permission. Disabling INTERNET will prevent it from sending anything (it's used to privilege, so it likely won't use another app to bypass, but you can use a different profile anyway).

>Play Services are still closed-source google components that I don't want on my phone.

microG is just a reimplementation (a partial one) of Play Services. The privacy benefits are negligible.

>I just wanted to express that I generally see GrapheneOS pick the security side over privacy if there is a choice to be made between both (and only then). And with privacy I mainly mean big data tracking from the likes of Google.

I'm guessing you're referring mainly to microG.

Privacy is not just not sending data. It's far more than that. It needs to be able to blend in with others, and needs a certain decent level of security to avoid simply bypassing privacy features through vulnerabilities.

microG doesn't protect data in transit even close to the way Play Services does. How do you expect to have privacy when apps can simply intercept microG data?

Signature spoofing as microG needs, ruins the security model. It bypasses signature checks by apps. Even in CalyxOS's slightly less bad implementation, vulnerabilities in microG can be used to break out of the sandbox. How do you expect to build a security model on this? Vulnerabilities in microG are very likely, considering how the project disregards security.

How do you expect privacy with such little security? You'll not have any privacy if an app can bypass your privacy features.

It also only reimplements a portion of the APIs and breaks when apps need new ones. How is it supposed to keep up with the APIs anyway? It's tens of thousands of lines of code. It's certainly not a viable option.

Using Play Services as a sandboxed app, on the other hand, avoids this. It doesn't require the microG patch which erodes security, it protects data in transit, and it actually gets the majority of APIs and functionality working. The only functionality that doesn't work is SafetyNet attestation and functionality which depends on privilege. SafetyNet enforces using the stock OS, so you'll never get it with microG. Privileged functionality would need invasive OS integration.

It's clearly a much better solution that preserves the security model. It does it right.

GrapheneOS also optionally blends in with stock Android users. This isn't a bad thing and increases privacy. Connections made are just things like connectivity checks, nothing special.

Besides, CalyxOS isn't particularly good for this either. Their Netguard firewall that they bundle doesn't implement it properly and apps can still bypass it. They aggressively integrate Google services, and have Facebook integration as well.

I doubt strcat disagrees with that. He's responding to specific statements comparing GrapheneOS and CalyxOS. I don't think we would have seen those comments if nobody had mentioned GrapheneOS.

We're working on fixing the one bypass. I don't know what you mean by leaky VPN tethering implementation.

We have a patch (from LineageOS) that allows tethered devices to connect over the VPN. By default in AOSP a tethered device ignores the VPN.

Wouldn't this be the opposite of leaky? It prevents leaks, especially when you have always-on VPN enabled.

> GrapheneOS has a Network toggle without those leaks and prefers the approach of fine-grained VPNs rather than using the same tunnel for everything.

We evaluated the network toggle and found it to cause crashes in apps when the permission got taken away from them unexpectedly, which is why we've gone with the solely network-level implementation.

We also do not have anything that'd make you think 'use the same tunnel for everything'. Multiple users work just fine, and in fact we now have a built-in work profile feature which lets you run another VPN in that (since that's how Android works) out of the box.

> CalyxOS includes a lot more proprietary services (Google, WhatsApp, etc.)

We do not include any proprietary services. We have microG which is open source, and the WhatsApp integration is done in open source code in the Dialer, it does not rely on anything proprietary.

In fact, you're the one who's brought up your play services approach which involves running the proprietary binary. Don't you see the irony?

I simply wanted to explain that you will always pick the security side if a balance has to be made between security and privacy. I don't mean this as a bad thing. It's a good point and a good differentiator between both IMO.

> GrapheneOS has https://grapheneos.org/usage#sandboxed-play-services which is able to provide much better app compatibility, far more functionality and without the privacy/security sacrifices of microG. microG lacks the same security checks and key pinning of Play. It doesn't avoid trusting Play because the apps using Play are using the Play client libraries. microG is an additional trusted party.

I don't agree with this. I would not want any google play stuff on my phone, sandboxed or not.

> Those apps work fine on GrapheneOS. CalyxOS isn't more private and more secure than AOSP. CalyxOS includes a lot more proprietary services (Google, WhatsApp, etc.) than AOSP. For the most part, they're making changes which quite easily hurt privacy and security.

Does Calyx really include WhatsApp out of the box? That would indeed be a very negative point for me. As I mentioned I haven't used either.

> This is a highly inaccurate portrayal of what GrapheneOS provides and the decision making process. GrapheneOS values privacy and usability very highly. It balances those with security.

As far as I understand your website you do always pick security if a tradeoff has to be made. I don't think this is a bad thing. I think it's a good option. It's just not the choice I would make but it's nevertheless a good stance for those who care about security the most.

Anyway like I said in my other post I'm sorry you view my post as an attack. If you look at my other posts you will see I praised you for promoting security features that were incorporated into AOSP after you had initially developed them.

We do not, we would never ship a proprietary app like that.

What we have is a small patch to the open source Dialer / Phone application that lets you make WhatsApp calls directly.

It only shows WhatsApp as an option if you have it installed already, if you don't you won't see it, we don't want to promote using proprietary services.

This was done after a lot of back and forth with our UX team.

GrapheneOS has an easy to use web installer: https://grapheneos.org/install/web which is based on the fastboot.js library created with our funding.

We also now has a sandboxed Play services compatibility layer implementing a no compromises approach to providing app compatibility:

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

This will provide much more functionality than microG with better security and without sacrificing privacy by not giving Play any additional access than it has via the client libraries used by apps. It runs as a normal, sandboxed app and we provide fallback code for it to work that way. We return placeholder values for most of the privileged APIs and implement certain APIs like dynamite modules in an unprivileged way.

No need to bypass security checks in apps as has to be done to make microG work. That's a problem because microG doesn't uphold the same security model and checks as Play services. For example, it's not pinning component and server keys for important cases.

GrapheneOS currently has a much more barebones fresh install, but it's easier to install due to the web installer. The barebones installer is by design. We don't bundle proprietary services. We also don't bundle 3rd party apps and services unnecessarily rather than leaving it up to the user. We'll be providing a first party app repository with modern metadata signing, key rotation, delta update, stable/beta release channels, etc. within the next few months to make it easy for users to install an initial set of apps. High standards will be applied to the apps we choose to build for our repository.

Play Store requires API 29+ at the moment and that will be required to use the much safer unattended upgrade approach in Android 12 as opposed to the risky approach used by the Play Store, Aurora Store and F-Droid. We'll likely require API 30+ though.

F-Droid itself if API 25 (Android 7.1). The API level is the privacy/security level of an app. API 28 introduces a much stronger SELinux sandbox with per-app SELinux MLS domains protecting the app from others and other apps from it. There are many other improvements, with each API level making things better. For apps not distributed via the Play Store, this is a simple health check to see how much an app prioritizes privacy and security compared to simply getting it working.

Could a someone at an open source project slip in an obfuscated backdoor in some esoteric area of the OS? Of course. But the risks of being found out are so much higher, after the fact that all changes at an open source project are logged, diffed, and public (normally), even if only 10% of the userbase looks at the code, runs packet capture or an SSL bump on the network traffic, etc, that is 10% more than for products by Microsoft, Apple, Google, and unlike an insider with access who discovers something highly questionable at a massively powerful corporation, an open source project has almost no leverage to compel them to keep their mouth shut, meanwhile the risk for developers of an open source project that does something like that (even if they aren't in the know) is total loss of trust, forever.

Couple all of that with targeting a highly technical audience (drug kingpins looking for secure comms are more c-suite than engineers, they are still caught up on a good sales pitch more than hard technical details e.g. Anom ) and you'd be fairly stupid to try to pull the wool over their eyes and expect it to not eventually get discovered.

... But they are also heavily incentivized to know where your booze is, care for your booze, and make sure it doesn't get stolen or poisoned. Because if something happens to you, where are they going to get the sip?

Where else are customers going to go? All phones in stores right now run OSes from either Apple or Google. Both companies can forsake their customers' trust and people will still buy phones that run their software.

That incentive doesn't really exist in a market that's ruled by a two company mobile operating system cartel.

I wish Replicant was able to catch up. Having blobs at the baseband is awful, but having the baseband accessing all RAM is just game over for privacy. There isn't what to trust in that setting.

From a consumer perspective, going with A and trusting the company is by far the safest option.

No, that's not true. GrapheneOS is the continuation of the project by the original development team. There aren't any developers who stuck with Copperhead. The project was created 1 year before Copperhead existed as a company.

https://grapheneos.org/history

> The security mitigations developed for those were incorporated upstream into Android, decreasing the attack surface.

https://grapheneos.org/features is a list of the current features differentiating it from AOSP. It doesn't list the many things we've gotten into upstream projects, since they aren't differences anymore.

"Two People created CopperheadOS, they had a disagreement. One of them continues to work on it under the name GrapheneOS."

Would this describe it better?

A better description would be "One person handled development of the project and other person CEO'd the sponsor company. The CEO attempted to hijack the project and the developer eventually resumed the project under the name GrapheneOS."

A little longer, but more accurate :)

Google endlessly spies on everyone.

I really don't think anyone could be worse, than a big corp.

Might they miss something because they're a smaller team? Yeah, maybe. Will they sell out? I don't think so.

[0]: https://en.wikipedia.org/wiki/American_Civil_Liberties_Union...

B. CalyxOS is a project of the non-profit Calyx Institute, founded by https://en.wikipedia.org/wiki/Nicholas_Merrill

Um, this project is 100% open source, unlike Google's flavor of Android. If there are backdoors to the FBI they will be exposed in due time.

https://gitlab.com/CalyxOS

That said I'd love to understand how it compares to LineageOS.

Upstream being AOSP helps a lot.

When it's locked (which is the entire point of custom verified boot), this is not allowed.

I pay $120-$350 for used Pixels.

What I guess I'm trying to say is: Huh?

Could you please explain?

You do miss out on some other pixel-specific features (Hold for Me for example), but camera quality should be unaffected.

This new wave of privacy branding, without 3P verification, open sourcing, or even means of recourse seems to be the new frontier for these used car salesman "trust me, it's private" pitches.

If you're hoping market forces would keep companies competitive and secure, well, people don't have much of a choice when it comes to mobile operating systems. Free market dynamics that should correct this problem don't really come into play when a two company cartel has 99.7% of the mobile operating system market nearly split in half between them.

They don’t seem to be too much concerned about failures in security and privacy… Their entire business is based on dismantling of privacy, why should they be trusted more than companies that have alternative business models?

Why are you looking for alternatives ? or are you even

Lets keep using known flawed alternatives instead?