Comment by neilv | Hacker News Reader

Comment by neilv | Hacker News Reader

Like the author, I've tried a ton of open source handheld platforms, and I've recently moved to CalyxOS for my daily driver. (And about to sell a box o' devices to help cost-justify buying a second Pixel for a backup CalyxOS device.)

As Android devices go, CalyxOS seems a good choice, if you're willing to not have all the Google service conveniences. I actually found some of the UX smoother than on iPhone, and e-mail worked better. Though note that CalyxOS is not as polished for privacy out of the box as users might assume.

One big problem is that Android is massive, and also doesn't seem to have been designed or deployed in practice to be privacy-friendly, nor especially open source-friendly. Even back in the FirefoxOS days, if you built that from source, it was clear there was no way you could audit or maintain all its Android dependencies (my hope was that they'd throw out the Android layer as soon as they could).

I have some hopes for Purism's Librem 5 Phosh running atop a mainlined Linux with open drivers (and ideally firmwares) on many devices at many price points. Though available hardware tends to be fundamentally insecure.

There also seems to be an additional barrier of US carriers imminently requiring VoLTE, and in some cases only allowlisting a small number of models.

Honestly, I don't understand the selling point of CalyxOS over LineageOS. Can you explain the differences? The website just seems to be a little mumble about Privacy without explaining the technological differences.

As a daily driver, I'd recommend a setup of an official LineageOS device, combined with a set of Apps to increase the level of privacy:

- AppWarden to check for trackers and loggers

- RethinkDNS as a VPN firewall and adblocker

- Privay Browser (f-droid build)

- Permission Manager X to remove permissions from Apps via AppOps

- OsmAnd for Navigation

- Oeffi for Public Transport Navigation (in Germany)

- Element or Telegram FOSS for chat, because Signal still requires microG or other Google Services for their auto backup, which I don't agree with.

I would also recommend to bet on LineageOS because the community is vast, and it's more likely to survive (given the past with Cyanogen and its company) than other forks that are maintained by 1-3 people.

Personally, I hope that phosh and plasma mobile can be feasible app alternatives and I hope that Purism and the Pine movement can change the ecosystem.

But, as of now, developing a GTK4 or QT5 app (compared to making an Android app) is still PITA and seriously lacks better development tools and IDEs.

I believe the appeal for CalyxOS is attempting to bring more convenience with privacy, where apps you've mentioned are already installed. A major difference is the inclusion of microG, which means you have more freedom to use apps you have no alternative to (e.g. government apps, banking apps, etc).

I'm aware of the LineageOS for microG project, however apart from the aforementioned preinstalled set of apps, CalyxOS includes many system patches shared by other projects such as GrapheneOS, which include privacy enhancements on default AOSP DNS fallbacks, connectivity checks, NTP, and more.

I would also like to mention that Signal does not require microG or Google Play Services for auto backup (or notifications). The backup files are stored locally on the device and can be easily synced with Syncthing, Nextcloud, etc.

Ah, okay, makes sense.

The network connectivity, NTP issues and others are the reason why I have Termux installed (to be able to modify the /system/etc/hosts file, as the network core library ignores VPN settings).

Granted, streamlining these apps makes more sense to the end user. I wish Android would have a package manager that would allow creating a meta package for this kind of stuff.

Beware of Signal: it depends on the proprietary Google Play Services library, so even if you don't have the Play Services on your phone, the app is built with the "client-side" code which speaks with it (or with microG) and checks for its presence.

FreeSignal was a project that aimed to remove this dependency completely but was stopped by the main developer of Signal. It is possible to clone Signal's repo and do this work yourself quite easily if you know Java a bit, but it takes time and it is not convenient.

> Beware of Signal: it depends on the proprietary Google Play Services library, so even if you don't have the Play Services on your phone, the app is built with the "client-side" code which speaks with it (or with microG) and checks for its presence.

That exposes client information to Google but not content. Besides, if my understanding is right, The Signal Protocol is non-repudiable, which means there's no way for an external party to conclusively prove if the communication did indeed take place.

It probably exposes nothing at all to anyone if the Play Services are not on the phone or the relevant feature is not enabled on microG. But it is still a chunk of code that is partly run and that you don't control. It probably just does what it says (check if the service is present), but it is a black box.

What's the problem there? If the code is there but not executed, and no data is sent to Google, is there any risk as a user?

It is executed to test the presence of the Google Play Services on the phone when the app is launched.

Then, it's probably not risky, but it is still proprietary code that you can't inspect and verify. You can't easily know if the library will not silently do something. If you are seeking to avoid running any proprietary code, then it's something you want to avoid.

Right, but you were talking about "even if you don't have the Play Services on your phone", which is what I'm worried about - but OK, if it's just because there's a chance it might be running, then I'm not too afraid of that.

At the risk of laboring the point, I'm talking about the piece of code embedded in the Signal application, that tries to talk to the Play Services. Not the Play Services themselves. This piece of code is definitely running whenever Signal is launched, "even if you don't have the Play Services on your phone". It probably does nothing significant when the Play Services are not present but still, it's there and (a small) part of it runs.

Now you have several options:

- you trust Google and trust this code not to do anything when the Play Services are not running

- you don't trust Google on this, but you don't care neither

- you don't trust Google and care, but you are willing to take the risk

- you don't trust Google and care, and are worried, or are not willing to run any proprietary code out of principle: you need to adapt Signal's code or dish the app entirely

> It probably does nothing significant when the Play Services are not present

Right, that's the part I care about. I think there are two possible situations:

- Signal's own open source code can detect the absence of Play Services and not call out to Google's proprietary code in the first place. Great, no problem there.

- Google's proprietary code attempts to use Play Services and doesn't do anything when it's not present. In that case I do indeed trust Google enough that I wouldn't expect it to actually do anything else, i.e. the first option you mention.

CalyxOS doesn't change the default connectivity checks and NTP. GrapheneOS does (NTP isn't used though [1]).

[1] https://grapheneos.org/faq#default-connections

> because Signal still requires microG or other Google Services for their auto backup, which I don't agree with.

I never used Signal with GServices, so I don't know what you mean with auto backup, nevertheless I simply use the backup function and sync the backup folder with my cloud and it works fine for several years now. For me it seems like a hard constrain to use Telegram which is obviously less secure over Signal only because of an auto backup function. Using Android without GServices always has a compromise part.

Signal auto-backup works fine without Google services. Just point it to some local folder.

By far the most important difference is that with CalyxOS, you can relock the bootloader. This means that probably one of the most important security features, verified boot, works on CalyxOS, but not on Lineage.

I too was wondering why LineageOS's forks were being discussed but not LineageOS itself, I assumed the author had made some remarks on it but after reading the article it seems the author made no attempts to explain why forks of LineageOS were chosen over itself.

I'm all in for android forks, I strongly believe improvements in such forks can be up-streamed for the benefit of the entire ecosystem but I'm yet to see a valid justification for recommending something other than LineageOS for someone new to aftermarket android scene.

> There also seems to be an additional barrier of US carriers imminently requiring VoLTE, and in some cases only allowlisting a small number of models.

Is this all carriers, or just some? I know that AT&T is the main one since I'm affected by it (their whitelist arbitrarily removes my OnePlus 6 from being supported this February despite the phone supporting VoLTE), but I heard that other carriers such as T-Mobile are still working without VoLTE. Either way, the whole "requiring VoLTE" thing could even be a problem for some custom ROMs (not even GNU/Linux phones) since I believe VoLTE support is something that ROMs sometimes miss, which will be pretty bad. While I'm not a full "privacy" user (yet), I use custom ROMs for extending the lifetime of my phone and getting newer updates than I would on the stock ROM, and carrier limitations could seriously threaten a lot of things.

As I understand it, US carriers already turned off 2G and are turning 3G off real soon now. If your phone doesn't do VoLTE and wants to do a voice call, that won't work when 3G is turned off.

AT&T takes it a step further. Only if my phone does do VoLTE and AT&T puts it on their magic whitelist (which you can bet, for example, is not going to have the PinePhone on it) am I going to be able to use my phone at all on AT&T's network (well, at least that's my understanding). Other carriers might not have a whitelist though—but I'm not sure.

I recall T-Mobile used to be pretty uptight about using band X for LTE only for VoLTE phones because they wouldn't be able to go from data to dialing 911 if they only had band X coverage (it was better for TMo if the user had no coverage in that case for regulatory reasons), but I think TMo is less strict about what phones they'll provision for VoLTE. I only remember trouble getting my first LTE phone to work, but LTE was newish; once I got a TMo firmware on it, it would provision and unlock whatever band it was I was trying to use, even though the IMEI would have been for an ATT model.

I want to say T-Mobile is requiring VoLTE (I recall discussion about this because it effectively mean the Nokia N900 cannot be used on T-Mobile or its NVMOs anymore).

I will comment that the Pinephone works with VoLTE on many carriers (I know it works with T-Mobile), and Purism is actively working on VoLTE for the Librem 5 (I remember seeing them actively working it a few months ago, so I guess they have it working now?).

How are cross-distro Linux app packages looking these days? Not so much the packaging aspect but the sandbox environment they set up to run third-party apps in peace. Is this something librem is working on?

I would expect lots of mobile apps to ship via Flatpak these days.

Does flatpak create a sandbox comparable to iOS?

Reply on news.ycombinator.com