eos — julian

UnifiedPush -- Wider Developments

Wed, 27 Nov 2024 14:48:00 +0000

An article about Building the Self-Agency Mobile Ecosystem: Push Messaging

Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently. But Who Cares Who Delivers Our Notifications? Our answer is: we care, and we do not like being locked in to depending on one mega-corp's system.

Therefore, in our libre mobile computing devices, we require a push-messaging infrastructure built from open standard technology that gives us freedom to choose our service providers and authority over them.

How We Get There

How can we build this? What is needed to get widespread UnifiedPush support in /e/ and other mobile OS?

The big picture involves several areas of work.

OS integration of the distributor, including how it's configured, auto-detected, optimised, etc.
Server Software: Making sure a suitable server-side component is available, supported, optimised for this use case.
Server hosting: making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems.
Apps: Working with other apps to make sure they connect and work with UP out-of-the-box.
Sharing this work among other mobile OS projects (microG, CalyxOS, GrapheneOS, PostmarketOS, ...) .
Consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa.

(Links in this and the following sections lead to relevant issues or discussions, where I could find any.)

OS Integration of the UP Distributor

Including how the UP distributor is configured, auto-detected, optimised, Android permissions, etc.

I recently analysed how /e/OS 2.5 has started the ball rolling

Server Software

Making sure a suitable server-side component is available, supported, optimised for this use case

Nextcloud: UnifiedPush Provider — exists
It could alternatively begin with a fork of ntfy-server for example.

Server Hosting: Technical

Making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems, ranging from hobbyist to serious commercial systems.

Docker ntfy — exists
K8s ntfy helm-chart — exists
Nextcloud: UnifiedPush Provider — exists
Matrix-Docker-Ansible-Deploy: ntfy-server — exists
Yunohost: ntfy-server — exists
SelfHostBlocks — not yet
CoopCloud — not yet
Fediversity (an upcoming hosting project) — not yet

Work out and write up (shareable) policies about who hosts, terms and conditions, privacy, rate limiting and other special measures, etc.?

Apps

Working with other apps to make sure they connect and work with UP out-of-the-box.

Category 1: default apps in /e/OS etc., like...

Mail: K9/Thunderbird-andriod #5165 and UnifiedPush for IMAP (NGI proposal 2024-10-535)
Nextcloud -uppush #17 -notifications #1225 -android #8684
Accounts/Calendar/Contacts (DAVx5 #36 + DAV-push)

Category 2: other popular apps like...

HomeAssistant #446344
Fluffychat — exists
Element — exists
Signal forks
Telegram-FOSS #577
Conversations.im — exists
Pixelfed #86

Standardising UP client-server protocol?

Should we consider standardising the UP client-server protocol? At present, by design, one must choose a UP distributor and UP server together as a pair. If we standardised the protocol between them, so any distributor would work with any server, this would certainly have some benefits, but also down-sides, and is not necessarily the right thing to do. UP was designed this way on purpose and achieves its goals without needing to standardise there. No ordinary person needs to be able to change their UP implementation. Only techies and service providers might like to do that.

Therefore this is an exploration rather than a development. I discuss this further in a separate article.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

Follow/Feedback/Contact: RSS feed · Fedi follow this blog: @julian@wrily.foad.me.uk · matrix me · Fedi follow me · email me · julian.foad.me.uk Donate: via Liberapay All posts © Julian Foad and licensed CC-BY-ND except quotes, translations, or where stated otherwise

UnifiedPush: Standardise UP Client-Server Protocol?

Tue, 26 Nov 2024 20:00:00 +0000

This is a technical article. For a more general introduction to UnifiedPush you might read the first half of Going Google-Free with UnifiedPush in /e/OS or my other articles about UnifiedPush .

Should we consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa?

Not necessarily, and I will attempt to explain why.

UnifiedPush High Level Architecture

Look at the diagrams on the unifiedpush.org home page. There are four connections involved, shown arranged in a square. UP standardises the protocol for one of the connections, the bottom one (UP distributor <–> app). It also standardises something about how the whole system works.

The protocol on the top connection (App server –> UP server) has recently been upgraded to be compatible with WebPush.

The other two (App <–> app-server and UP <–> UP-server) are two other, separate, independent protocols. The protocol the app developer uses for app <–> app-server is not relevant to UnifiedPush. At present, UnifiedPush standards also do not specify a protocol to be used for the connection between the UP server and the UP distributor (shown on the left).

The ntfy distributor requires a ntfy server, whereas the nextpush distributor requires a nextpush server, and so on. They use different protocols for that link in the chain.

Multiple Protocols or Standardised Protocol

It would be possible to make a UP server that supports (for example) both the NextPush and ntfy protocol(s). In fact ntfy supports two different protocols (the “json” one and the “websocket” one) and you choose one in the settings. The ntfy server supports both of those.

The point is, UP achieves its goals without needing to standardise there. In some respects it's beneficial that the user and/or service provider can choose those components and protocol that best suit their needs, while the end-user apps and app servers all still remain completely compatible (standardised) no matter what UP components are used.

Additionally standardising the UP <–> UP-server protocol could make different UP servers and distributors interoperable. It could potentially help with users bringing their own choice of device (assuming it has a UP distributor built in) from one service provider to another, for example.

But that's more of a deployment-level standard: something that service providers might want to standardise. Android-compatible mobile OS's (for example) might get together and declare “we” (as a loose group) like to standardise on (let's say) ntfy-websocket protocol here, because (suppose) it works best with android's OS network layer and sleep optimisations. (Just examples; I have not researched what protocol actually works best in each scenario.) Then, Linux-based mobile OS's might choose a different protocol that works better with Linux's networking and sleep optimisations. Then, if a certain libre mobile service provider wanted to support both android-compatible and linux-based devices, they might choose to support two protocols. Or would standardising on one protocol be more helpful in such a scenario? It's not clear.

No ordinary person needs to be able to change their UP implementation. Only techies and service providers might like to do that.

So, at this stage this is perhaps the least important of all the areas to work on.

First explained in #unifiedpush:matrix.org.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

Going Google-Free with UnifiedPush in /e/OS

Tue, 19 Nov 2024 12:00:00 +0000

Congratulations UnifiedPush! Congratulations Murena!

Murena's /e/OS 2.5 ships with UnifiedPush support included as announced by a small note in the 2.5-t release notes .

This exciting development brings Google-free push messaging to the regular users of an important player in the freedom mobile OS space.

So What?

Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently.

To achieve this, the phone operating system keeps a single network connection open to a push messaging server. The apps don't need to keep running in the background: they can go to sleep. When a push message arrives, the OS wakes up the relevant app and hands it the message.

All our apps share this push service — even the “private” ones — if they want push messaging.

That's great, except... Who Cares Who Delivers Our Notifications?

Until now, most people's phones run Google or Apple software. The Big Techs operate and control those phones. Along with everything else, they provide the push messaging service. And so they, Big Tech, control it.

The UnifiedPush public open standard changes this. With UnifiedPush, we are no longer merely “users” of our devices but are in charge of them. With UnifiedPush, we can choose which service provider will deliver our push messaging. Thereby we are in control of who has the ability to monitor or block our push messaging.

UnifiedPush has been available to those interested, for a while now, but until now it has required installing extra software.

Putting the support for push messaging into the operating system means ~~users~~ people who choose not to be operated by Big Tech will now be able to simply install the apps they care about and immediately have the alternative system working for them.

Technical

I'm going to delve into the technical side of this initial release, because it's a big interest area of mine. If you are a regular user, I suggest at this stage you might concentrate on switching to /e/OS or another freedom mobile OS and expect this functionality will be maturing quickly from now on and soon be seamless. If you're an early adopter or interested in its development, read on.

I am trying it out. I already run /e/OS on my main phone and upgrading to version 2.5 was simple with the built-in upgrader.

The OS embeds a custom fork of ntfy, calling itself “foundation.e.ntfy 1.17.0”. So, congratulations also to ntfy! At this stage the developer of ntfy, Philip Heckel, told me in #ntfy room he was “not yet involved” in this development and this is the “First I'm hearing about it.”

ntfy is a notification system that can also provide UnifiedPush service. It is so good at this job that it has for some time been the UnifiedPush implementation recommended for most people. One can install the ntfy app and it provides UnifiedPush service to our other apps.

When we install the ntfy app ourself, we may either let it use the creator's default server (at ntfy.sh) or configure it to use our choice of ntfy server, if we know of one or if we run our own. As with anything, using someone else's server comes with conditions and restrictions, especially if we don't pay for the service, so we need to think about that.

Let's see what /e/OS does.

If not Google's then Whose Server?

In this push service built in to /e/OS, there is no configuration UI. There is a tiny settings UI where we have to “enable” the service — see below. Technically, the full ntfy UI is also available, but not accessible through the normal system UI — neither the app launcher nor the settings. But as curious techies we can hack in to it if we like. See below.

What we can do is install and use the UP-example app. Click the “REGISTER” button, and we discover it's preconfigured to connect to... . o O (their own ntfy server?) No! It connects to ntfy.sh, the server run by the author of ntfy. Hmm.

I should say that I found this while not signed in to Murena's “e cloud” services. It's possible and would make some sense if it would point to a different server if signed in. I will be interested to find out.

The first thing to comment on, then, is Murena will surely need to run their own push server, for privacy and scaling and economic reasons, or else make an agreement with ntfy. In the short term, to get things started, it may be acceptable for everyone to be subject to the free (gratis) ntfy service's rate limits and other conditions. That's something that can be changed later, seamlessly, because UnifiedPush doesn't require app (server) developers to know or care which service provider they will eventually be connecting to.

Secondly, for privacy and self-determination reasons, there should be a way to use our own choice of server, but not necessarily as a dedicated configuration option. A better way might be to tie it to the main Nextcloud account through a single-sign-on, so that when we set up the phone we have only to make that one choice of service provider and expect it to cover all services. That would give people the advantage of simplicity which is how the Big Techs play that game, but now with open standard technologies enabling us to have a choice among service providers.

When an app registers for UnifiedPush service, if more than one distributor is installed, it asks which to use. A normal user would have only one, and would not see this. Here as an experimentor and developer I already had both ntfy and NextPush installed:

It's not ideal that it identifies as “ntfy”, exactly the same as the official ntfy app. I expect this will soon be changed to /e/OS branding.

The tiny settings UI is found a the bottom of the system settings menu.

It's disabled by default. In this state, the UnifiedPush service is still advertised to apps, and they can register, but push messages are not delivered. (I suspect this isn't how we want the disabled state to be. Probably it should not advertise as available.)

That's all the configuration we get in this version of /e/OS.

(Aside: I couldn't find this in settings, to begin with. Searching in settings for “ntfy” or “push” or “unifiedpush” doesn't return any results, for me.)

Let's Hack In

As a developer we can access the ntfy UI through the system terminal, for example through an ADB shell (running this command on a USB-connected computer with “adb” tool installed, with ADB USB debugging enabled in the phone's developer settings):

adb shell am start -n foundation.e.ntfy/io.heckel.ntfy.ui.MainActivity

Just the same as in the user-installed ntfy app. (I can compare them side by side because I also have it installed, because I was already using it before this upgrade.)

We first notice this screen prominently shows some warnings about battery optimisation and choice of connection protocol. Are these warnings relevant to this version?, I wonder. (At first it showed only the first, and later both.)

And it lets us open its settings. In the ntfy settings we can choose our own server, and I can confirm this takes effect and works.

This screen also shows the currently subscribed topics — here, the “example” one — and after configuring it to use my own server, the displayed URL confirms that. (Generally one “topic” corresponds to one app.)

Ntfy Not NextPush?

I'm a little surprised Murena chose ntfy, seeing as their system is closely coupled to Nextcloud: there is also Nextpush (source on Codeberg, yay!), a Nextcloud-hosted UnifiedPush server module and its client app, that could be used instead. Perhaps they found ntfy is more stable or refined than Nextpush.

UnifiedPush developer S1m says the “Next version of NextPush will be a lot more stable, and I've rewritten the UI.”

The Future

While UnifiedPush is pretty good standard already, it is still maturing. Some important, recent improvements are making their way into the standard and into implementations like ntfy right now. These include full compatibility with the WebPush standard, and a better way to wake an app without it needing permission for unrestricted battery usage.

An adjacent recent development is DAV Push, an open standard for pushing instant updates to our shared files, calendars and contacts through CalDAV, CardDAV and WebDAV, which can also work through UnifiedPush.

To ensure people can exercise their right NOT to depend on Google, we have wider work to do. Integrating a UnifiedPush distributor is one useful step towards it. Beyond this, we need to be working with the developers of popular apps to get them supported, sharing this development across the freedom mobile OS ecosystem, deploying servers, ensuring reliability, and more. I write about this in a follow-up post: UnifiedPush — Wider Developments .

Conclusion

The details of this initial implementation seem to me to indicate an early preview release, with significant changes still needed. But that's OK: these technical implementation details can be changed.

Leaving that aside, the social side of this is amazing: it's making UP available to main-stream users. That's a big deal for the libre mobile ecosystem. Hurray!

Add UnifiedPush to /e/OS to make it possible for developers to avoid FCM and better support F-Droid applications — an /e/ community forum thread requesting UP support.
Source code of /e/ fork of ntfy: https://gitlab.e.foundation/e/os/ntfy-android
“Integrate ntfy in /e/OS” —merge request, including a simple settings UI (just enable/disable).
Romain Hunault of Murena is presenting it at Capitole du Libre 2024 this afternoon.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

My Freedom Phone Cover Design

Fri, 20 Sep 2024 12:00:00 +0000

I designed a back cover to show people mine is no ordinary phone, it's a Freedom Phone.

Share and re-use the design if you like. Replace my face and website with your own.

Fits a OnePlus-6 phone, when printed at 76 x 152 mm. (This phone model can run a wide range of freedom software.)

Paired with the lock screen I designed last year...


Lock Screen	Back Cover

Concept Development

Began as a paper sketch, 2024-09-15.


1	2	3	4	5	to share

Finished in time for Software Freedom Day 2024-09-21.

Licence and Credits

The final design to share:

Download: freedom-phone-back-cover-julian-foad-2024-v5.0.svg
SVG format (Inkscape flavour)
Excludes my face and website
Licensed as Creative Commons CC-BY-SA 4.0 “share-alike” with attribution required
Copyright © Julian Foad 2024

Created using Inkscape (freedom software)

Attributions for art work used:

“Ada and Zangemann” by David Revoy, 2023, based on “Ada & Zangemann” written by Matthias Kirschner and illustrated by Sandra Brandstätter − CC-BY-SA 4.0
rainbow umbrella shared by Lisa Cornell, 2011 − public domain
bitten apple shared by Dan Gerhards, 2011 − public domain
type fonts: Liberation Sans, cmmi10
image of my own face, shown in derivative examples here, © Julian Foad, 2016

#fossGadgets #degoogled #lineageOS #eOS

Odin and Heimdall: Free Your Samsung Android

Fri, 24 May 2024 15:00:00 +0000

This article is about one particular step of the procedure for “flashing” a new android-compatible operating system onto a Samsung device to create a Freedom-Respecting Smart Phone or Tablet.

(For the rest of the procedure, see for example the instructions to install e-OS or install LineageOS .)

Main article: Degoogling a Samsung Galaxy Tab A7 (2020)

Tools for Flashing Samsung: Odin and Heimdall

Samsung Android devices are tightly locked down. My impression is they perhaps allow re-flashing only to fulfil some legal concession. It does not seem to be an option that they want us to use. Nevertheless, it is possible. At least on some models. (I read that some models sold in the USA are completely locked; maybe there is no legal concession to allow changing the software there.)

Samsung do not seem to make available the tools needed to “flash” the software. The instructions I find all reference either “Odin” or “Heimdall”.

Odin is apparently a Samsung internal tool that has been leaked, many years ago, as a Windows-only executable with no source code. This, widely referenced as the way to go, is useless for non-customers of Microsoft-Windows. In 2022 a leaked Odin v4 for Linux was reported, also executable only. Without source code, nobody (outside Samsung) can reasonably make improvements or adaptations. (Also, many instructions including LineageOS's say to download the Odin executable from some unattested third-party web site, not even giving a checksum to verify. This is dangerous.)

Heimdall is a cross-platform open source tool developed independently. Heimdall can replace Odin, but many instructions either do not mention it at all, or point to an out-of-date version such as v1.4.2 that lacks important updates and bug fixes.

Both Odin and Heimdall work with Samsung's “download” mode, and are needed to get an alternative (freedom) operating system onto the device.

Heimdall, Open Source Samsung Flashing Tool (Odin Alternative)

An open-source flashing tool for Samsung devices, called Heimdall, was developed by Benjamin Dobell (https://glassechidna.com.au/heimdall/) around 2010 to 2017. That version is most commonly referenced.

Some bug fixes and updates have been made by other people since then, but not merged back to that version. Some of these can be found inside Microsoft's GitHub, but the best version is not there: it rightly lives on a Freedom software forge called Source Hut.

Heimdall up to v1.4.2, the latest “original” version (from Benjamin Dobell or “glassechidna”) at the time of this writing, did not work for me. See Troubleshooting: Heimdall Fails at Initialising Protocol.

Henrik Grimler now maintains a version of Heimdall at https://git.sr.ht/~grimler/Heimdall .

I recommend using Grimler's version. It has fixes and updates needed for more recent devices.

It is available as source code. You could ask around for someone to provide a build, or build it yourself following the included instructions.

Building Heimdall

Referring to Appendix B at the bottom of the instructions page for Linux, on Ubuntu 22.04, on which I already had most of the dependencies installed, I built Heimdall like this:

$ sudo apt install libusb-1.0-0-dev  # you may need more: see below
$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Release -DDISABLE_FRONTEND=ON ..
$ make
$ # The executable is then found at `./bin/heimdall`
$ ./bin/heimdall version
v2.0.2

Required dependency packages are listed in the doc linked above, and also machine-readably in the source tree in the files .builds/{alpine.yml,archlinux.yml,ubuntu.yml}.

I used 'DISABLE_FRONTEND' because I was not interested in building a GUI, and could omit installing 'qtbase5-dev' and its several sub-dependencies.

Using Heimdall in place of Odin

To flash a recovery image, Odin wants to be given a “tar” file (a similar concept to a zip file) with the image file inside it. For example, we have to create recovery.tar which contains recovery.img. By contrast, Heimdall takes the image file directly, e.g. recovery.img.

Where instructions for Odin say to select the “AP” (Android Partition) button and choose the recovery.tar file, the Heimdall translation is to run heimdall flash --RECOVERY recovery.img . For flashing a different kind of image such as “vbmeta”, we write heimdall flash --VBMETA vbmeta.img. We can give more than one pair of command-line arguments to flash more than one image.

Referring to this XDA post, the command needed for this device is:

$ heimdall flash --VBMETA vbmeta.img --RECOVERY recovery.img

Or, if we prefer not to reboot immediately (equivalent of disabling Odin's “Auto-Reboot” option), add the '—no-reboot' flag:

$ heimdall flash --VBMETA vbmeta.img --RECOVERY recovery.img --no-reboot

#fossGadgets #android #degoogled #lineageOS #eOS

Troubleshooting: Heimdall Fails at Initialising Protocol

Fri, 24 May 2024 14:00:00 +0000

This is about flashing a custom operating system ROM in a Samsung Android device using the tool named Heimdall.

We may encounter a failure mode in which heimdall detect succeeds but heimdall flash and heimdall print-pit both fail, printing this:

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
ERROR: Failed to send handshake!ERROR: Protocol initialisation failed!

Releasing device interface...

Additional diagnostics if we give the --verbose option:

"ERROR: libusb error -7 whilst sending bulk transfer"

(This message is repeated several times, before the final failure.)

Errors like this have been reported many times: e.g. here and duplicates, here, here

Here are two scenarios in which this error can occur.

Scenario 1: Only The First Heimdall (Flash, Print-Pit) Command Works

Some people report that some Samsung devices only accept one Heimdall command in the bootloader mode. Further attempts fail. Rebooting is required before another command can succeed.

This may be a bootloader limitation in certain devices. (I have not yet seen a report with enough detail to satisfy me it is definitely the case.) In other cases, using Heimdall's options “—no-reboot” (on each command) and “—resume” (on subsequent commands, since v1.4.0) may overcome this.

(In this description, “heimdall flash” and “heimdall print-pit” count towards the limit of one command, while “heimdall detect” doesn't count towards the limit and can be used freely.)

Scenario 2: Every Heimdall (Flash, Print-Pit) Command Fails

This happens only when running Heimdall on certain linux distributions, notably Ubuntu.

Some people fixed this in their forks of Heimdall, e.g. Jesse Chan's fix is in Grimler's version of Heimdall and in several other forks. (This fix works by resetting the USB device on the Linux end. The main work in developing the fix seems to be recorded in PR #478 .)

My suggestion: build and use Grimler's Heimdall. I explain a bit about Heimdall and how to build and use it in my article Odin and Heimdall: Free Your Samsung Android .

Scenario 3: Heimdall With Resume Option Fails First Time

If the first Heimdall command after booting into download mode is given the '—resume' option, Heimdall fails for me (on Ubuntu 22.04) like this, even when using a version with the Scenario 2 bug fixed:

$ heimdall print-pit --resume --no-reboot --verbose
...
Beginning session...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
...
ERROR: Failed to begin session!
Releasing device interface...

From what I can tell, this seems to be expected, and so a usage error. The '—resume' option should not be used on the first command.

#fossGadgets #android #degoogled #lineageOS #eOS

Freedom-Respecting Gadget: Degoogling a Samsung Tablet

Mon, 20 May 2024 19:00:00 +0000

This is about buying a Samsung Android tablet and replacing the privacy-invading proprietary Google and Samsung software with privacy-respecting Freedom Software: “degoogling” for short.

Why? In “The Problem” section below, we take a look back at how much we're giving up when we accept Google's and Samsung's terms.

I would like ordinary people, with a little technical skill, to be able to do this. The process unfortunately is currently far too difficult, especially so on Samsung devices.

My goals:

Install a privacy-preserving freedom-software operating system on my tablet
Make it easier for others to do the same

The tablet I bought:

Name: Samsung Galaxy Tab A7 10.4 2020 (Wi-Fi)
Model: SM-T500
Device code: gta4lwifi

Yes, it's a few years old already. One of the benefits of Freedom Software is the community at large has the option to maintain up-to-date software on older devices, for as long as anyone considers it worth the effort. This is in contrast with the original maker's vested interest in stopping updates of their proprietary software after a small number of years. A nod to the right-to-repair and sustainability movements.

The Problem

Have you bought a tablet or phone recently? Perhaps even a Samsung?

IF We are buying a new or second-hand tablet,

THEN We might look at a Samsung Android device. They do make nice hardware!

BUT Oh! The set-up screens! — Screen after screen of, Yes, I agree to let Them scan my house for other devices and report back anything they find... Yes, I agree to let Them install or change or delete anything on “my” device... Yes, I agree to let Them scan all my contacts and data so they can make me feel happy by feeding it back to me in different ways, no, wait, they mean mining it for profit and trapping me in their systems. Yes, Agree To All because that's the easy option (and notice there's no “Agree to None” option).

Aaargh! No way, not me. Unfriendly system, Be Gone!

THEREFORE We want to turn it into a Freedom-Respecting Smart Phone or Tablet by “flashing” a Freedom Software operating system onto the device.

The New Software

I want to install an android-compatible, privacy-friendly, Freedom-Tech operating system. Nowadays I favour e-OS by Murena. e-OS is near main-stream user-friendly, with a nice blend of privacy by default along with a choice of optional (privacy-invading) google support for those that want it. e-OS is available on a wide range of phone hardware from cheap to premium, and you can either buy it or self-install it. If you're not wanting to develop tech skills in this area, buy it pre-installed.

Android-compatible Freedom Tech Operating Systems

Android as most people know it is a proprietary product, which contains inside it some open-source software (including some of Linux), leading to eternal confusion about whether “it” itself is open-source. No. Only the people who go looking for it get an open-source system built around the Android Open Source Project (AOSP). (That's us, yay!) Everyone who buys an Android device from the usual sort of phone maker is getting a heavily proprietary product that spies on them.

For this reason I often use long-winded descriptions like “android-compatible freedom-tech operating systems” to clearly differentiate these from proprietary Android.

Murena's “e-OS” is built around AOSP, using Freedom Tech to replace all the proprietary Google pieces, in a similar way to other android-compatibles such as LineageOS (a minimal android-compatible base OS) and LineageOS-for-MicroG (LineageOS plus F-Droid and some optional google support).

See my Freedom-Respecting Smart Phone post for other Freedom Tech alternatives you might consider.

Choosing a Well Supported Tablet

I bought this tablet after checking it was supported by e-OS and by LineageOS (and therefore also by LineageOS-for-MicroG).

What I didn't realise until too late is the installation instructions say I should download and run this, that and the other from various “random” (unofficial/unverified) sources — and it turns out those instructions are intended for running on MS Windows. Ugh.

There is a Freedom software alternative for this step: Heimdall. See Odin and Heimdall: Free Your Samsung Android.

I found this part of the procedure to be a deep rabbit-hole and spent a long time getting through it, reading a lot of dead-ends along the way.

For this reason I want to document what works, and also make it easier for others to do it, by attempting to automate this procedure in the Open Android Installer.

As the procedure is similar for many devices so working on the solution for my device should, I hope, also help others.

On Choosing a Well Supported Tablet, if you have limited time and experience for working through a complex installation procedure, then I would advise only choosing a Samsung phone or tablet in the following cases:

if the Open Android Installer or e-OS Easy Installer supports it, or
if you can get one that is already running a Freedom Software OS.

(Once it is running a Freedom Software OS, it is easier to upgrade or change it from that point.)

Installing

Installing is a challenge. The procedure is fraught with difficulties. Some people report that they “simply” followed the instructions and succeeded within an hour, while many others apparently spent days, encountered problems or gave up.

The starting point is the semi-official instructions published by the likes of LineageOS and e-OS. Note that these are basically the best efforts so far of volunteer groups, and are not necessarily accurate or complete, and far from foolproof.

See:

e-OS install guide and e-OS forum thread
LineageOS install guide and XDA forum thread (also relevant for LOS-for-microG)

After many hours of trial and research I got LineageOS installed, and some notes taken, several improvements implemented in my local copy of Open Android Installer, and a first couple of blog posts posted about parts of the procedure.

After reaching that stage, it was relatively easy to replace plain LineageOS with LineageOS-for-MicroG (both at version 21).

I also tried replacing it with e-OS (version T equivalent to 20) but that failed:

Installing update...
Comparing TZ version XF.5.1-01015-1 to XF.5.1-638149-3
ERROR: This package requires firmware from an Android 12 based stock ROM build. Please upgrade firmware and retry!
ERROR:   recovery: Error in /sideload/package.zip (status 1)

The tablet was running Samsung Android version 12 before I started. Never mind that for now. I'll come back to e-OS later.

So, I can claim success on one score: my tablet is now running LineageOS-for-microG.

Oh! You wanted all the details of how I did it and what went wrong? I'm not planning to write that up in that form (it was messy), but rather to work out improvements and write them up. I'll post them here once I've got something.

Making it easier for others to do the same

Taking hours to achieve this feat just for myself does not make me feel good.

I want to make it feasible for people with just a little technical skill to install an alternative operating system. It really should not and need not be so hard.

I can:

improve the installer apps (Open Android Installer, e-OS Easy Installer)
improve the installation instructions

In particular I want to do things that help whole classes of problems, across multiple devices and multiple operating systems, such as making the installers and instructions more automatic, more consistent, more foolproof, easier to diagnose.

To these ends, I have been keeping notes on what's missing, and have started making improvements to Open Android Installer.

#fossGadgets #android #degoogled #lineageOS #eOS

You Too Can Have a Freedom-Respecting Smart Phone!

Tue, 05 Dec 2023 12:28:11 +0000

Are you asking yourself,

“What's it to be: Android or iPhone?”

Actually, NO! There is another way.

Time I Learned: there are freedom-respecting phones.

I'll tell you which one you need.

What's the problem?

What's so bad about choosing either Google or Apple?

It's about who controls our use of the device after we “bought” it. Do “they” remain in control of what we do, or are we in control?

It's not about the hardware. Well, there are certainly important issues about the hardware — and you might want to discover PinePhone and FairPhone. But I'm here to talk about our freedom in using the product.

Many of us today are increasingly concerned about the vendor lock-in, advertising and data mining perpetrated by Apple and Google. They are so pervasive that it's hard at first to see all the avenues of social human interaction and creativity in which we could be harnessing the power of our computers and our electronic connection to others, all these avenues from which Big Tech have cut us off, as they steer us through their own product pathways according to their own commercial objectives.

In short, we are carrying around general purpose computers but we are artificially locked in to using their power only within the vendor's own playground. Read: The General Purpose Computer in Your Pocket. Those mega-corporations ensure everything we do is steered toward making their advertisers and shareholders richer: attention grabbing, commercial subscriptions, ads and so on. Not towards what's best and nicest for us as people.

We've been subjected so completely to their way that it's hard to imagine any other way. Hard to see that the nuggets of convenience we'd have to give up would be as nothing compared to the adventures we'd gain by switching. We can't see the wood for the trees.

Yet, the alternatives are here. We don't have to accept it's a choice between a rock and a hard place.

What we can do instead is choose tech that unlocks the power of these personal computers we carry around, and lets us use them for purposes that make no profits but enhance our own social lives. Gentle technology. Small Tech as opposed to Big Tech.

Once we make the leap and begin exploring the previously untapped possibilities, we begin to appreciate what it feels like to be released from Big Tech's constraints. It's not a stretch to say those companies had pressed us into their servitude, and now we can be free. That's what I'm feeling, and I want us all to have that opportunity.

Which Freedom-respecting Phone?

The one that stands out to me as best suited for most people is built upon a degoogled operating system compatible with Android:

Murena /e/OS smartphones
- deGoogled, Android-compatible phone
- with deGoogled “cloud” suite: email, docs, storage, etc. (free or €2~20 /month)
- choice of phone models (€300~600) including Fairphone

Being freedom-software (open source), the maker guarantees your freedom to use the tools they provide or change to others. What does that mean in practice? For example, if you don't like the terms and conditions of the Murena cloud software suite, you can use a different one provided by someone else, be it an independent commercial provider, or run by your school or club, or at your best techie friend's home. And then you don't even need a Murena account.

How is this degree of freedom possible? First, with the slogan “my data is my data”, Murena is committed to these principles. It was founded by Gaël Duval, the creator of Mandrake Linux. Second, in contrast to Google's Android which merely contains some open-source software components, this technology stack is designed around open source principles. Their cloud service is not only based on Nextcloud, but is designed to be compatible and interoperable with similar services run by lots of other providers and individuals. Together, and in stark contrast to the Big G and the Big A, these mean there is neither a practical lock-in nor a legal lock-in.

How to get one?

The no-fuss solution: buy one
The techie friend option: ask the friend to set it for you on a second-hand phone.

“But I'm Not Average”: Other Freedom Phones

If you are not the average person, or if you want to learn more about the alternatives, read on.

I recommend Murena for the average person because their offering is so inclusive: the phone hardware, the cloud services, the freedom to take or leave parts of the system and adapt it to your needs, compatibility with most smart phone apps, and working in a way that is broadly familiar to a lot of people already. I hope we will soon see other providers like them offering a no-fuss all-included solution too.

These alternatives will appeal more to techies and to people with particular preferences or needs, and the ability to spend a bit more effort instead of buying an all-in package. With most of these, you or a techie friend will need to do one or more of: install the operating system software on a suitable phone, setting up any “cloud” services you want, or using apps that are currently less mainstream.

That said, these are quality and important alternatives.

Linux-based Phones

By Linux-based phones, I mean operating systems aligned with GNU/Linux rather than with Android. There are a few.

Purism in particular is an outstanding company dedicated to making freedom and privacy centred devices. If their Librem phone isn't for you, check out their laptop, server, security key.

Purism's Librem 5
- Linux-based phone OS
- convergence with Linux desktop: run desktop apps on the phone, or plug into a monitor and use as a desktop computer
- company dedicated to software and hardware freedom and privacy at all levels, and working with wider FOSS community
Jolla with its SailfishOS is the favourite of The Opt Out Project's Janet Vertesi.

Android-Compatibles

Android compatibles can be partially or completely degoogled, giving privacy from spying megacorps including not only the big G but others too. Most give you a choice of how far you want to distance yourself.

Shiftphones in Germany sells modular repairable phones (and laptops, headphones, etc.). While their current SHIFT6mq comes with a Google Android pre-installed, the interesting thing is they offer an easy and built-in way to install an “upgrade” to a degoogled android version. Much easier than degoogling any other phone.

Shiftphone SHIFT6mq detailed Review including thorough instructions on degoogling it, and suggestions for additional settings and apps.

Iodé is a small company in France selling phones pre-installed with deGoogled Android, with extra privacy features.

Iodé's new or refurbished phones
- deGoogled, Android-compatible phone
- choice of phone models (€210~730) including Fairphone

For techies, there are more deGoogled Android distributions that you can download and install yourself on a suitable phone:

Many of the phone operating systems from the vendors mentioned, being based on freedom software, can be self-installed too:

How About an iOS-compatible Freedom Phone?

An iOS-compatible Freedom Phone? That's an oxymoron! Apple locks its users into its own walled garden completely. See The Neighborhood and The Nursing Home.

What Does Julian Use?

Personally, for myself and family I am currently using LineageOS-for-MicroG. I chose that option because I am a techie, experimenting with the various options on a budget, so I tended towards those I can install myself on a wide range of old and new phones. And because it is quite close to mainstream Android so a majority of mainstream apps run on it. And because my less techie family members needed the reassurance of being able to continue using their familiar Google apps to begin with, and only gradually migrating to freedom-software, one app at a time when they are ready, from Chrome to Firefox for example.

I have experimented with others. I really admire what Murena is doing, and have self-installed /e/OS on older and newer phones. I am considering switching over to it on my main phone, and to use it for family members, as it is more readily maintainable and more user-friendly, and supports the widest range of apps from proprietary locked-down banking apps through to fully open freedom software, all on a wonderfully freedom-valued platform.

I would want to use /e/OS with my own compatible cloud service rather than using Murena's cloud, because I will not compromise on using my own domain name as the key to my own data services. I believe Murena and other companies offering “your own data” services should for this reason always offer “bring your own domain”. For now, the situation is that Murena's service is open source with the source code repository ecloud-selfhosting in “beta” status. That means it is possible to set up one's own infrastructure, just not as easy as it really needs to be. (It is however to be congratulated that they host their software forge on their own domain rather than using the anti-freedom Microsoft-Github.)

This article is part of my Open Source Gadgets series.

Originally published as All I Want for Christmas is... a Smart Phone?, 2022-11-09. This revised version published December 2023.

More articles tagged... #fossGadgets #android #degoogled #lineageOS #eOS

All I Want for Christmas is... a Smart Phone?

Wed, 09 Nov 2022 21:05:09 +0000

“What's it to be: Android or iPhone?”

Actually, NO! There is another way.

Time I Learned: there are freedom-respecting phones.

I'll tell you which one you need.

(For the literal minded: It's just a title. I don't really think Christmas is about buying gadgets. This article is about freedom in technology.)

What's the problem?

What's so bad about choosing either Google or Apple?

Yet, the alternatives are here. We don't have to accept it's a choice between a rock and a hard place.

Which Freedom-respecting Phone?

The one that stands out as best suited for ordinary people is built upon a deGoogled version of Android:

Murena /e/OS smartphones
- deGoogled, Android-compatible phone
- with deGoogled “cloud” suite: email, docs, storage, etc. (free or €2~20 /month)
- choice of phone models (€300~600) including Fairphone

How to get one?

The no-fuss solution: buy one
The techie friend option: ask the friend to set it for you on a second-hand phone.

“But I'm Not Average”: Other Freedom Phones

If you are not the average person, or if you want to learn more about the alternatives, read on.

That said, these are quality and important alternatives.

Purism in particular is an outstanding company dedicated to making freedom and privacy centred devices. If their Librem phone isn't for you, check out their laptop, server, security key.

Purism's Librem 5
- Linux-based phone OS
- convergence with Linux desktop: run desktop apps on the phone, or plug into a monitor and use as a desktop computer
- company dedicated to software and hardware freedom and privacy at all levels, and working with wider FOSS community

Shiftphone SHIFT6mq detailed Review including thorough instructions on degoogling it, and suggestions for additional settings and apps.

Iodé is a small company in France selling phones pre-installed with deGoogled Android, with extra privacy features.

Iodé's new or refurbished phones
- deGoogled, Android-compatible phone
- choice of phone models (€210~730) including Fairphone

For techies, there are more deGoogled Android distributions that you can download and install yourself on a suitable phone:

The phone operating systems from the vendors mentioned, all being based on freedom software, can be self-installed too:

(Where are the iOS-based freedom phones? That's not going to happen: Apple locks its users into its own walled garden completely. See The Neighborhood and The Nursing Home.)

What Does Julian Use?

I have experimented with others. I really admire what Murena is doing, and have self-installed /e/OS on an older phone. I am considering switching over to it on my main phone. I would want to set up my own compatible cloud service rather than using Murena's, because I will not compromise on using my own domain name as the key to my own data services. I believe Murena and other companies offering “your own data” services should for this reason always offer “bring your own domain”. For now, the situation is that Murena's service is open source with the source code repository ecloud-selfhosting in “beta” status. (It is to be congratulated also that they host their software forge on their own domain rather than using the anti-freedom github.)

This article is part of my Open Source Gadgets series.

Revised version published as Freedom-Respecting Smart Phone: Want, Get, Have!, 2023-12-05.

#fossGadgets #android #degoogled #lineageOS #eOS

eos — julian

UnifiedPush -- Wider Developments

How We Get There

OS Integration of the UP Distributor

Server Software

Server Hosting: Technical

Server Hosting: Social/Business Aspects

Apps

Sharing with other mobile OS projects

Standardising UP client-server protocol?

UnifiedPush: Standardise UP Client-Server Protocol?

UnifiedPush High Level Architecture

Multiple Protocols or Standardised Protocol

Going Google-Free with UnifiedPush in /e/OS

So What?

Technical

If not Google's then Whose Server?

Let's Hack In

Ntfy Not NextPush?

The Future

Conclusion

My Freedom Phone Cover Design

Concept Development

Licence and Credits

Odin and Heimdall: Free Your Samsung Android

Tools for Flashing Samsung: Odin and Heimdall

Heimdall, Open Source Samsung Flashing Tool (Odin Alternative)

Building Heimdall

Using Heimdall in place of Odin

Troubleshooting: Heimdall Fails at Initialising Protocol

Scenario 1: Only The First Heimdall (Flash, Print-Pit) Command Works

Scenario 2: Every Heimdall (Flash, Print-Pit) Command Fails

Scenario 3: Heimdall With Resume Option Fails First Time

Freedom-Respecting Gadget: Degoogling a Samsung Tablet

The Problem

The New Software

Android-compatible Freedom Tech Operating Systems

Choosing a Well Supported Tablet

Installing

Making it easier for others to do the same

You Too Can Have a Freedom-Respecting Smart Phone!

What's the problem?

Which Freedom-respecting Phone?

“But I'm Not Average”: Other Freedom Phones

Linux-based Phones

Android-Compatibles

How About an iOS-compatible Freedom Phone?

What Does Julian Use?

All I Want for Christmas is... a Smart Phone?

What's the problem?

Which Freedom-respecting Phone?

“But I'm Not Average”: Other Freedom Phones

What Does Julian Use?