First online Replicant meeting.

Date and place

In the last blog post ( Replicant status and report of the 37C3 and FOSDEM 2024 conferences ) we mentioned that one of the things to do in the short term would be to:

Setup a Replicant meeting online at a fixed time, on IRC/Big blue button/Jitsi/Mumble. If new people come we would do a short introduction and people would present themselves (especially what they are interested in).

So this meeting will take place the 18 June 2024 at 19:00 CEST (Central European Summer Time).

You can run this command in a terminal to see at what time the meeting starts in your time zone:

date –date=’TZ=”Europe/Paris” 19:00 Jun 18′

It will take place on mumble on the mumble.replicant.us self hosted Mumble server. If for some reasons there are technical issues a backup mumble server will be used instead.

Mumble servers require a client: Mumble on GNU/Linux or Plumble or Mumla on Android.

And at least on GNU/Linux it requires a bit of time (about 10 minutes) for the first setup as on the first run it guides users toward configuring things to improve the audio quality.

So if you could try to configure and test it first, it will means that we’d have less people to help with configuration at the time of the meeting.

We will be available a bit before 19:00 both on mumble.replicant.us and on the #replicant IRC channels to help people having issues with their setups.

Topics

At the time of writing, the current plan for the meeting is to discuss the following:

  • Presentation of people (very short).
  • To have a summary of the current work with (short, ~10min):
    • the conversion from WordPress to a static website (GNUtoo)
    • other tiny infrastructure work (GNUtoo)
    • the work on building 100% free Android SDKs (Wizzard)
    • The status of NLnet work (GNUtoo, dllud)
    • The status of the steering committee (steering committee(GNUtoo,
      Putti, Fil Bergamo?) and dllud), and adding dllud to Steering
      Committee.
  • Discussions / work about the call for the (“community”) Manager.
  • How/when to setup the next meeting
  • Other discussions.

Updates

Some last minutes details like the topics or server address could change between now and the meeting, so make sure to re-check this blog post before the meeting.

Summary

The meeting is summary is published on the Replicant wiki: https://redmine.replicant.us/projects/replicant/wiki/ReplicantProjectOnlineMeetings#Meeting-summary

 

edit1: Fix CEST Wikipedia link.

edit2: Add link to meeting summary.

Replicant status and report of the 37C3 and FOSDEM 2024 conferences.

Replicant current status:

The last Replicant release is still based on Android 6.0.

In the previous years, a lot of work was done to make the Galaxy SIII (GT-I9300) usable with an upstream kernel, both on graphics and on the modem.

While working on this report we also found that the removal of 3G networks was more a serious problem than we originally understood.

As we understand from the Wikipedia article on 2G , GSM networks are also being removed in Europe as well (where most Replicant users probably reside). If somehow we understood it wrong please contact us on the Replicant mailing list as this has big implications for Replicant.

This means that none of the currently supported devices will continue to work on non-community networks in most areas of the world.

About a year ago, the current Replicant maintainer talked with someone that knows well European regulations and that person told him that there was no chance to stop 3G from being removed (for instance through legal activism) due to the low number of users still using 3G. Since we didn’t ask about GSM at the time, we have no idea if that can be blocked or not or how much effort that requires.

In any case it means that the only way forward for Replicant is to make sure it (also) supports devices that work on 4G networks.

Furthermore such devices should also have VoLTE (Voice over 4G networks) ; otherwise, although they would be able to get Internet over 4G networks, they could not to make regular calls or send SMS.

Unfortunately even the Galaxy SIII 4G (GT-I9305) which is a Galaxy SIII (GT-I9300) with a different modem doesn’t support VoLTE. So we cannot reuse most of the Replicant work we did.

Even if in some areas of the world (like some European countries), the devices currently supported will continue to work for very few years, and there was a big amount of work done to make these devices usable with more recent Android versions, a lot more work is needed to make that work usable daily (making power management work, debugging complex issues, etc).

The majority of recent devices (like newer Samsung smartphones) have too many freedom issues, making them unsuitable for Replicant.

Remains the PinePhone:

  • The hardware already works under GNU/Linux.
  • The battery life (in hours) is now almost good enough. Furthermore, it is possible to buy an additional keyboard that has a builtin battery to extend it more.
  • There is an Android distribution (GloDroid) that supports the PinePhone. It has some usability issues that need to be fixed: modem disappearing on some models, no cellular data, no modem isolation, etc.

The PinePhone Pro and Librem 5 could also be supported but they are not high priority right now due to incomplete power management (PinePhone Pro) and high cost (Librem 5).

In light of this, the current Replicant maintainer applied for funding through NLnet (again) to fix some of the PinePhone’s issues and support it in Replicant. This application was accepted but he ended up being sidetracked by another project instead of working on that.

He got involved in what became GNU Boot and planned to have the project in good state by the end of the last summer, in the hope the work could be reused to ship a bootloader for the PinePhone in the next Replicant version.

See the GNU Boot 0.1 RC3 announcement and the NLnet funding application for more details.

Unfortunately the work on GNU Boot took way longer than anticipated, being unfinished yet. Because of that the work on the PinePhone didn’t even start.

In addition to that, the main Replicant maintainer was also demotivated (he did a lot of work that turned out not to be that useful) and he thought that the project was poorly managed by him. He was trying to understand what went wrong and how to fix it. Going to the 37C3 to find help was part of the fixing plan.

Identified issues:

Discussions between GNUtoo, dllud (both Replicant contributors) and several people we met during the 37C3 or on the train going to it converged to the same points and together we identified several issues:

Replicant has not enough people:

  • A diversity of profiles helps solving issues and not be stuck. It also helps keeping the motivation as different people are good in different areas and thus people can more easily work on what they are good at and like to work on.
  • We cannot expect a single person to take care of the community, help new contributors, handle project management, keep relationships with other communities, keep track of what work is getting done elsewhere to improve collaboration, manage the infrastructure (servers) and modernize it a bit, and at the same time work on the code towards new releases. So far the current maintainer has been switching from a set of tasks to another but that didn’t really work out.

It’s too difficult to contribute to Replicant:

  • It requires computers that are not commonly available among people: to build Replicant you need a lot of free space (200+ GiB), a fast internet connection to download more than 50 GiB, 32 GiB of RAM or more (for recent Android versions), and sometimes run specific versions of distributions.
  • It requires specific hardware like a Galaxy SIII (GT-I9300). People can’t help with commonly available emulators or single board computers.
  • There is extensive documentation but it’s scattered around. Documentation is also lacking for the tasks that are the most important for Replicant (porting Replicant to newer Android versions). Though we can also have people helping new contributors again to compensate for documentation issues.
  • We have a list of tasks and required skills for them but we lack information about the importance of the tasks. We also need to organize a bit how to assign tasks to people according to their skills and will. We were also advised to break the important tasks in more details.

Plan forwards:

Very short terms plans:

  • Write this report: As we were not always discussing with the same people at the conference this should help us share information between ourselves and also with all the people that helped Replicant at the conference, to better organize the next steps.
  • Setup a Replicant meeting online at a fixed time, on IRC/Big blue button/Jitsi/Mumble. If new people come we would do a short introduction and people would present themselves (especially what they are interested in).
  • Re-run the call for the Community Manager. We will run almost the same call as before so the work will be less than last time. We will be looking for a candidate that can do a subset of the tasks in the call. As we were told multiple times that “Community Manager” was not describing the job well, we are also looking for a better term but so far no one found one that would feel right.
  • Amend the NLnet proposal to include GNU Boot work as well to solve our dilemma.

Medium term plans:

  • Find a way to get a build server. A KGPE-D16 would be a good idea. The FSF can probably buy it and host it for us.
  • Work on the PinePhone (and on GNU Boot as well).

Long term plans:

While discussing with NLnet we were also told that it might be useful to collaborate more with DivestOS as part of our goals are similar. So we will need to evaluate again if there is enough proximity in our code to collaborate.

In the past people from DivestOS were really helpful as they found nonfree software inside Replicant and reported it to us.

Apart from that we don’t have long term plans yet. Once we have a Replicant release that supports the PinePhone, we will need to decide where to go next.

For instance we could support more devices, reduce the amount of work for adding support for newer Android versions, reduce the differences between GNU/Linux and Android, or simply keep Replicant up to date by supporting more recent Android versions with minimal work.

Right now we also didn’t spend much of the Replicant money and beside paying for a “Community Manager” we don’t have precise plans yet.

We have about $200 000 and so far we relied on funding from NLnet to bring Replicant back on track as it was easier not to mess up this way.

Money goes away fast and spending it all in the wrong direction would prevent Replicant from using it to become more sustainable. Very few projects have an opportunity to use money to grow or achieve more.

Instead most of the ones that want to grow and become (bigger) non-profits are stuck in a chicken and egg issue as they need more money (that they don’t have) to achieve more, which in turn leads to a greater need for donations.

As such, getting the project back on track before even starting to evaluate how to use the money to do big changes to the project seems a good idea, as many projects were destroyed after getting too much money and failing to properly use it.

Other advices for medium/long term:

  • One person also told us that businesses have interesting methodologies like “tracer bullets” in Agile methodology, or “Business model canvas” or some emotional approaches to tasks that might be worth looking at as they can work for non-commercial projects as well and can be adapted to a wide variety of cases.
  • One of the people we talked to insisted on the importance of finding a good team and finding ways to divide tasks between people. For that person it was also important to find people that could work well together and that agreed on the same goal (to avoid infightings).
  • We could also delegate more sysadmin work to the FSF: It would require less time from our side without compromising on freedom and with minimal extra work for the FSF sysadmins if we don’t require custom things.
  • We were also warned that delegating tasks among ourselves still require time to organize. According to that person, in many cases if a person delegates a task, only 50% of the time is saved.

Other area of work:

Android SDK:

The main advantage of Replicant over other GNU/Linux distributions certified by the FSF is that it can run Android applications, but that is only relevant if there are 100% free software Android applications.

Somewhat recently we found out that it was no longer possible to know if Android applications shipped by F-Droid are really free, as F-Droid now uses the nonfree Google SDK to build the applications. As such we don’t know if they build with another SDK on FSF certified GNU/Linux distributions. We want to help fix that to make sure the solution really suits our needs.

If there were fully free drop-in replacement SDKs that also build on a 100% free distributions, that issue could be fixed for both F-Droid and Replicant. F-Droid may have further requirements as they probably have higher security demands than Replicant. For instance, they probably won’t like to depend on the (free software) binaries shipped in the SDK source code that are used to build it, and would rather build everything from source.

In the times of Replicant 4.2 (based on Android 4.2) Replicant produced its own SDK. After that several GNU/Linux distributions (Debian and some Debian derivatives) started shipping a fully free SDK for Android 6.0 so Replicant stopped producing newer SDKs.

Nowadays Debian and PureOS still package an Android 6.0 SDK but don’t support more recent versions of Android. They also don’t support the NDK that supports languages like C. F-Droid probably used these SDKs for a while, specially because they are completely built from source from well known distribution(s), but many Android applications don’t build anymore with these old SDKs.

After that, free SDKs for various Android versions started being released at https://android-rebuilds.beuc.net, but the main author of this work at some point moved on.

After that several people tried to continue that work somehow and published source code that can build SDKs but none published the SDK binaries.

In the GNU 40 conference in Switzerland, the current Replicant maintainer met the person behind SDK rebuilds (beuc.net) and also someone interested in giving resources (like server space) to build an SDK.

In the 37C3 we met additional people:

  • Starfish, that wrote potentially 100% free Android applications and that also publishes source code to build a free Android SDK. His applications build with this free SDK.

    Starfish doesn’t publish binaries in order to avoid dealing with license compliance in case something is wrong in the SDK binaries. Replicant is happy to do that.

    Starfish can also accept contributions and bug reports for supporting FSF certified GNU/Linux distributions and for removing nonfree software from the SDK if any if found.

    As a bonus we also reviewed the applications that Starfish wrote so if the SDK works on 100% free distributions we’ll also have 100% free applications to promote to people without any freedom caveats.

  • Another person (wizzard) jumped in to automatize the builds, making them run unattended on each new release.

So thanks to all these people everything is now in motion to get the SDK problem fixed once for good and in a better way than before: one that makes sure people can actually build Android applications with 100% free software.

Conferences:

At the 37C3 we managed to understand Replicant issues and a way forward probably because we started discussing the project issues in advance, which allowed just enough understanding to be able to ask for help. If we didn’t do that we probably would not have managed to get help that is that useful.

37C3 talks and interesting people:

While we (GNUtoo, dllud, and the people that helped us) did a lot at the congress (and even too much since we missed our own lightning talk due to too much cognitive load) at the end we managed to achieve the most important goal: finding a path forward for Replicant.

Alongside our main goal of putting the project back on track, we found time to host a variety of talks and events:

  • We had an official Replicant assembly where people could meet us.
  • We did a presentation named Smartphones freedom status in 2023 which looked at smartphone hardware and operating systems available in 2023. It wasn’t recorded. The slides are available as PDF and source code .

    At the end of the presentation, after the questions, we also got some feedback:

    • We were told that there are more applications for GNU/Linux that work on smartphones than what we assumed. They are referenced in https://linuxphoneapps.org and they also list applications available in PureOS landing (a rolling release version of PureOS) and Guix . Still they probably have less applications available than on F-Droid but things are progressing in the right direction.
  • We also did a talk presenting the Replicant as part of the Critical Decentralization Cluster . Unfortunately it wasn’t recorded due to a technical issue, but we re-did it again the day after on a longer format . The slides source code and PDF are available.
  • We did a presentation on the status of Replicant . It wasn’t recorded so if you want to know what was said, the slides are available , but you also need to read the presentation.txt to understand it.
  • As a follow up to the presentation on the status of Replicant, we also had a meetup on the last day where we had discussions with the people attending the talk.
  • We met someone repurposing smartphones who told us that on some Samsung smartphones/tablets, erasing the PARAM partition (with dd if=/dev/zero) sometimes removes restrictions that prevent the phone from booting custom distributions.
  • Among those helping us, there was someone interested in using Replicant for education. The most problematic issue found is that the current requirements to work on Replicant are too much for students. Supporting single board computers or emulators would be a first step to help here. In general this would help finding new contributors.

OFFDEM / FOSDEM 2024:

The main maintainer of Replicant had already planned to go to an event of OFFDEM (an alternative conference to FOSDEM) on Friday night, and also to FOSDEM 2024 on Saturday and Sunday. Train tickets were already bought before Replicant took the decision to go to the 37C3, so he kept the plan.

As expected it was not as useful as the 37C3 for Replicant (it was way more useful for GNU Boot) but still some interesting things happened:

  • He met Hans-Christoph Steiner from F-Droid and explained the status on having a fully free Android SDK. He detailed our work to provide binaries by setting up an automated build system that reuses the maintained scripts to build the SDK and that runs on a FSF certified distribution (Trisquel) to make this solution also work for Replicant.
  • He was introduced to people working on CalyxOS by Michiel from NLnet.

    Before that he thought that CalyxOS was deeply problematic because even if on paper CalyxOS had the same freedoms as LineageOS, its security system removed users control of the devices (users don’t have root, etc) and didn’t have access to their data.

    But in reality CalyxOS uses SeedVault , a backup application that enables users to backup their data and restore it on any other distribution that may not have the same security model. SeedVault is also used by most Android distributions. It is therefore a good idea to see how it can be integrated into Replicant, as it seems to be made with user’s empowerment in mind. It can backup data (encrypted) to an USB key, so users don’t need a server or external services.

    In addition he was told by a CalyxOS contributor that it is relatively simple for users to build CalyxOS with their own keys, and so be in full control of the device.

    He was also told that newer Android versions don’t need F-Droid privilege extension anymore due to the inclusion of an API for stores inside recent Android versions (thanks to some European regulations).

  • He met someone who is working on understanding the European regulations that aim to standardize digital identity papers and the way to store it. He already met that person at the 37C3 but this time there was more understanding and more time to discuss the issue more in depth. The regulation has requirements for smartphones so it will most likely affect smartphones distributions that use free software drivers (like Replicant, various GNU/Linux distributions, etc.). If done wrong, it would prevent free software users from storing their identity papers in their smartphones with free software (for instance because it could be stored “securely” in areas of the phone inaccessible to users and free software). One of the issue is that this person looks for help to understand the technical parts, and also for some associations to help in the fight to modify the laws to fit free software. Since Replicant has very little time to look at this now, he referred her to the Osmocom project that already analyzes somewhat similar designs like eSIM.
  • He also met with Tiberiu from Technoethical, a shop that sells FSF certified hardware and Replicant compatible smartphones (that aren’t certified by the FSF due to nonfree bootloaders and other issues). Technoethical will be negatively affected by Replicant’s decision to drop support for the current Samsung phones in future versions, as PinePhone will become the major focus.
  • The main maintainer of Replicant also met with Paul Kocialkowski. Before that meeting he thought that on GNU/Linux the eg25-manager program for the PinePhone only did simple things like setting up udev rules and had simple hacks to make the modem work fine. He thought that all stability issues were to be handled by Modem Manager. However the EC 25 Manager may also be monitoring the modem and restarting it when it crashes. This could explain modem stability issues with Android/GloDroid on PinePhones with 3GiB of RAM. The fix may be to port/reimplement that feature to make this model usable.

 

Edits:

  1. Refrased Technoethical paragraph.

Replicant @ 37C3

Since yesterday, December 27th, the 37th Chaos Communication Congress (37C3) is taking place in Hamburg. Replicant is present as part of the Critical Decentralization Cluster (CDC).

Replicant’s assembly is the place to come by if need help installing Replicant or general advice regarding software freedom on smartphones and tablets. You can also take the opportunity to verify the release signing PGP.

Location: G5, Hall 3, Level 0
DECT: 8652

As Replicant is struggling with structural problems, first and foremost lack of contributors on key areas (development, sysadmining, communication, coordination, documentation), we are looking to onboard new people with fresh ideas. Please drop by if you feel keen to help on any of these field.

There will also be a few talks and gatherings about Replicant and related topics in several spots around the congress:

Replicant at FOSDEM 2023

This year the FOSDEM will take place in Brussels the 4 and 5 February.

This year there will be a talk about Guix evaluation and usage for/by the Replicant project: How Replicant, a 100% free software Android distribution, uses (or doesn’t use) Guix, by the current Replicant maintainer.

As not everybody is familiar with Replicant or free software on smartphones, it will also have some background information on hardware and software of freedom in smartphones with a focus on FSF certified distributions.

We hope to also use this occasion to build collaboration with other projects, especially other Android distributions that use kernels based on upstream Linux.

We may update this blog post if there are last minute changes (if the talk is moved) or if we have new interesting information (like interesting talk to attend, other events, etc).

New Replicant 6.0 0004 release and Replicant 11 status.

Replicant 6.0 0004 is now officially released. If you want to upgrade from Replicant 6.0 version 0003 or earlier you need to follow the data migration procedure that is documented in the Release notes page on the Replicant wiki.

Even if we released the images back in January 2022, we didn’t announce it officially at the time because the data migration procedure wasn’t complete yet.

What is new in this release

Replicant is in the list of distributions that are recommended by the FSF. As such, Replicant needs to follow strict criteria that ensures that the distribution does its best not to violates its users’ freedom.

However fixing the issues and making new releases can sometime take a long time. The last Replicant 6.0 release was from December 2017.

This new release fixes some very serious freedom and privacy issues:

  • We found an issue within the phone application: it was leaking the phone numbers of both inbound and outbound calls to third parties as part of a feature called phone lookup providers. More details are available in the bug report. Even if it was not trivial to reproduce and find the bug it’s now fixed as the feature has been completely disabled with 3 patches ([1], [2], [3]).
  • F-Droid has been removed as many applications shipped in it are not compliant with the guidelines for distributions recommended by the FSF. It was kept so long because we expected to get it fixed upstream fast enough, but that didn’t happen for various reasons. We have setup a wiki page and a forum section for more information about the issue and how to deal with it.
  • Several binary firmwares (without source code) related to the back and home “touch” buttons were found and removed with 4 patches ([1], [2], [3], [4]). The firmwares seem to have only been used for factory testing, so the buttons should still work on the devices that have them.
  • The touchscreen firmware for the Galaxy Note 8.0 was also lacking any corresponding source code (bug #2194). That was fixed by removing it ([1]).
  • On all the currently supported devices with a modem, when users set the device in flight mode, the modem is only asked to go in low power mode. Because of that the modem is probably still on and its OS is probably still running. Because of that we fixed the wiki and added scripts to disable (and enable back) the modem to the new Replicant images. They work by preventing Replicant to load the modem OS.
  • We also got a report on the mailing list that a nonfree ambient SDK was added in CyanogenMod and was not removed either by LineageOS 13 or Replicant 6. So we removed it as well.

This release may also fix several bug(s) which made some SIM cards not recognizable by Replicant 6.0: we have now merged a fix for one of the bug (#1909) but as we don’t know if all the “SIM card not recognized” bugs are related. We would highly appreciate if those that opened the original bug report could confirm if it also fixes their issues as well.

Several issues still need to be fixed, but we didn’t want to delay even more this release, as that would prevent users from getting the fixes mentioned above:

  • It’s still not possible to build Replicant 6.0 from a distribution that is recommended by the FSF (bug #1861).
  • While removing the firmware of the Galaxy Note 8.0 touchscreen driver, many more firmwares without corresponding source code were found in the driver/touchscreen directory in the kernel used by most of the devices supported by Replicant 6.0. However they weren’t removed yet. Help is more than welcome to help with that.
  • While investigating if it was possible to upgrade WebView, the Android builtin web browser component (bug #1786) we also discovered that, because Android build system doesn’t use a package manager, finding the license of each repository wasn’t trivial (bug #1973).
  • More investigations are needed as well to replace WebView with a free software and up to date implementation (bug #1786).
  • The bug related to a bad sound quality during calls in some circumstances (bug #1773) is not fixed yet, but there is a workaround that works for some use cases.
  • The Let’s Encrypt certificates probably stopped working in Replicant 6.0 the first September 2021. Some browsers like IceCat should normally continue to work fine. See the Standing on Our Own Two Feet blog post by letsencrypt for more details.

As the internal WiFi doesn’t work with free software, some new network related features improving usability were merged :

  • RepWiFi has been removed as it’s now possible to use the stock Android menus to handle the WiFi. This was done by patching Android to also accept external dongles. It is less reliable than with RepWiFi because in some cases reboots are needed for the WiFi to be recognized, and enabling the WiFi most probably also powers on the Internal WiFi chip as well, increasing the power consumption. However it should reduce the probability of applications like F-Droid being broken in the future, as it’s better integrated in Android. In the event that Replicant 6.0 stops being maintained and that Replicant 11 doesn’t get support for all the Replicant 6.0 devices, this patch should increase the lifetime of the affected devices.
  • Ethernet support has been added but it doesn’t work on all the devices.
  • The USB networking scripts were also been added to the devices.
  • Support for some rt2500-usb dongles that don’t need the OS to load a firmware has been added to the Galaxy SIII 4G (i9305), which is an uncompleted device. It wasn’t added to the other devices to make the release happen a bit faster.

Other improvements were also made:

  • llvmpipe is now the default OpenGL renderer. On devices with an Exynos CPU / System on a chip, this allows running many applications that weren’t working before. Unfortunately llvmpipe significantly slows down some system components used in the graphical interface. This has been catered for by patching Android to use the old libagl renderer for those system components.
  • Scripts to switch between OpenGL implementations globally have been added to the image as well. Thus, if you want to revert back to the old behaviour, just run “graphics.sh faster” in a root terminal. To switch back to the new behavior you can instead use “graphics.sh compatible”. Note that “graphics.sh compatible” will still keep the old OpenGL implementation for the system components mentioned above, so there is little risk in trying the scripts.
  • It’s now easier to build Replicant as there is a new script that wraps part of the building process. It’s also more convenient as it stores build logs. The script has been used to build the release, and the build instructions also use it now.
  • It has became easier to modify the installation instructions as they now apply to all devices, and were split into parts that are reusable. This way if the instructions needs to be modified, it requires a single modification instead of 10 or 30 modifications like before.
  • Instructions to backup the modem data partition have been added. The modem partition can become corrupted in some conditions. As it can be very difficult or impossible to recreate that partition, and that it’s required for the modem to work, we very strongly advise users to do a backup.
  • A new wipe command has been added to wipe partitions, however it is not very well suited for wiping files. To efficiently wipe files another application or utility would need to be integrated.

Many of the improvements and fixes were also made possible thanks to the work of new contributors.

Replicant 11 status and policy changes for supported devices

Work on Replicant 9 has now shifted to Replicant 10 and then Replicant 11, and has been ongoing in parallel. As it will use a kernel closely based on upstream Linux, it has some implications:

  • The work on Replicant 11 is made with the Galaxy SIII (i9300), so it should be supported.
  • The Galaxy Note II (N7100) is very similar to the Galaxy SIII but requires a bit more work to be supported.
  • The Galaxy SIII 4G (I9305) and Galaxy Note II 4G (N7105) could also be added if work is done to add support for their modem in Replicant.
  • We don’t know yet how much work is needed to add support for the other devices that are currently supported by Replicant 6.0, so we don’t know yet if they will be compatible with Replicant 11 or not. We would need to find or get more information on the upstream status of theses devices before having a rough idea.
  • It will be easier to add support for devices using a mainline kernel.

We also take advantage of this release to announce some policies changes:

  • As Replicant 6 only supports devices with somewhat isolated modems, subsequent Replicant versions will also only support devices with isolated modems.
  • As Replicant 6 only supports devices with replaceable batteries, subsequent Replicant versions will also only support devices with replaceable batteries.

The Replicant developers chose not to support these devices officially in Replicant for good reasons.

Supporting devices with non removable batteries ourselves has a lot of challenges:

  • As Replicant 11 requires more work and working to upstream devices support in Linux takes more time than adding devices in Replicant 6:
    • if we start adding support for a device, we want to be able to spend the time required to do it right and to work with upstream projects like Linux to add support for it in theses projects as well. The advantage is that it makes Replicant and the device being added more sustainable. However if the device has a battery that is not replaceable by experienced users, developers, repair shops, or repair café, the device would have a very short lifetime which is incompatible with making Replicant sustainable.
    • Users would need to buy the device new in order to make sure that the battery lasts enough for a daily use. Buying the device second hand would be way more complicated as users would need to make sure that the battery last enough time. Developers would still be able to work on the device for a very long time, assuming that they are not users as well that want to use the device. But their work would not be very useful without usable devices.
    • In addition, being able to remove the battery of a device increase trust: for devices with a single battery, it’s easy to understand that without a battery, the device is really off. For devices with an additional backup battery, some background information on chip energy consumption is enough to understand what the device cannot do with such backup battery.

As for non isolated modems, if Replicant only support devices with isolated modems, it’s way easier for users and developers to remember that the devices they are using have a somewhat isolated modem.

However, as Replicant 11 is using a kernel closely based on upstream Linux, there is already some interest in adding support for devices already supported by Linux which have a non-isolated modem and/or a non-replaceable battery, and it would be sad to not be able to leverage all the work done in Replicant with these devices.

So practically speaking we are willing to help people and/or projects that are willing to support such devices. We are also accepting contributions in the Replicant source code for such devices provided that we can maintain the code without too much effort without having the devices.

So while anybody could test if the code still compiles fine, It will then be up to the people that have such devices to test if the code is still working over time. The code quality of such contributions may also have to be high as we want to keep maintaining that code over time without having the devices. The Linux kernel is already using a similar approach to be able to maintain support a lot of devices (including devices that the maintainers don’t have) without removing support for older devices.

We could even provide access to the Replicant infrastructure (for instance by creating Redmine sub-projects, opening new git repositories namespaces, and so on) to the people wanting to support such devices, but they would at least need to:

  • Find a name that is different from Replicant for the project (to not confuse both projects, else it defeats the point of having some separation).
  • Stay compatible with the strict FSF criteria as Replicant doesn’t want to host projects that are incompatible with such criteria. Though we already collaborate with other projects (which we don’t host) that aren’t compatible with such criteria.
  • Take care of users support (as Replicant developers will probably not have these devices, so they won’t be able to test things to properly support users).
  • Take care of the releases (as Replicant developers will probably not have these devices, they would not be able to test the releases).

As for the details on what constitute a “replaceable battery”, all the smartphones currently supported by Replicant 6.0 have removable batteries, so the batteries are very easy to replace. Compatible batteries can still be found in several cities and/or countries.

And for the tablets supported by Replicant 6.0:

  • They all have batteries that are not removable in the usual meaning, but they can still be replaced by opening the device.
  • It is easy enough for experienced users, developers, repair shops, and repair café to open the device and remove the battery, so it is probably possible to replace it as well.
  • It would be interesting to know more about the availability of compatible batteries.
  • It might also be possible to use tablets with batteries that last way less than when the device is new, as many people have them off most of the time. But even in that case it still shortens a lot the lifetime of the device, as they probably still needs a working battery to boot.

Replicant is looking for volunteers to add support for the “GSD4t” GPS chip.

Over the years, none of the Replicant contributors have been able to find the time to add support for this chip,and at the time of writing this chip is still not supported by Replicant despite being relatively easy to add support for it compared with the Broadcom GPS chips that are present in the other supported devices.

Over time, contributions from other people and projects made it easier to add support for the GSD4t chip.

There is now some documentation of that protocol in the form of some Perl source that can probably decode the protocol, and there has also been some people doing research on it.

In addition it’s also easier to do some tests on GNU/Linux: there is now some support in upstream Linux for the Galaxy SII (GT-I9100) thanks to the postmarketOS contributor(s) who worked on that. The nonfree bootloader of the Galaxy SII (GT-I9100) might requires some patches on top of that, but we also maintain patches for the Galaxy SIII (GT-I9300 and GT-I9305) bootloaders in our kernel_replicant_linux repository that might also work on the Galaxy SII (GT-I9100).

The Replicant developers are mostly available on the Replicant mailing and on IRC (#replicant on the hackint, libera.chat and OFTC networks). See the CommunityAndContacts wiki page for more details.

As for how to integrate the work, we already have an example of GPS library that was used in Replicant 4.2 for the GTA04.

As postmarketOS is also interested in making this chip work with free software, it might be a good strategy to also consult them to see how that work could also benefit GNU/Linux distributions.

edit1: removed duplicated title.

License: CC-BY-SA 3.0 Unported

Presenting Replicant’s Community Manager

The Replicant Steering Committee has concluded the second round of evaluations of the applications for the community manager role.

We would like to thank all the candidates that have applied for the role. It has been a greatly encouraging experience to receive so many valuable proposals and to observe such a responsiveness to our call.

Selecting one candidate among all participants has been no easy task, given the interesting variety of valuable profiles we had the pleasure to evaluate.

The key aspects that have been considered are, in no particular order:

  • the candidate having been actively participating in the community’s activities and discussions, in the forum, the wiki, the mailing list and the official IRC channel, as well as in-person meetings
  • the candidate’s experience in installing Replicant and in solving problems related to this activity
  • the candidate’s overall confidence with the practical aspects of using Replicant and helping users with related issues, doubts and information requests
  • the candidate’s involvement with other free-software projects similar to Replicant and/or with interesting points of contact with the work being done in Replicant
  • the candidate’s ability to write useful and comprehensible periodical reports to keep the community informed about the project’s activities
  • the candidate’s ability to contribute to Replicant’s technical documentation
  • the differences with typical free software backgrounds (to be able to bring more diverse perspectives to the project)

All these aspects considered, Kurtis Hanna emerged as the most suitable candidate for the role.

Kurtis has been a very active community member since at least 2016, successfully helping users in various occasions with different issues and enquiries.
He is well informed about various free-software projects and has often acted as a link between some of those projects and Replicant.
He participated in and/or helped organise many of the gatherings that have been held by Replicant members throughout the last 4 years, either in person or remotely, contributing his thoughts, impressions and valuable proposals.

In the next few weeks, we will be coordinating with Kurtis and the FSF to work out the applicable funding conditions and to define the contract that will regulate the Community Manager’s duties.

Once again, we thank all applicants and the whole community in general.

Cordially,

The Replicant Steering Committee

Call for a community manager

The Replicant project is looking for a community manager.

The role of the community manager is to fill the gap between Replicant developers and users, making sure that users’ concerns are properly addressed while at the same time freeing the developers from the burden of running the community.
The community manager should also foster collaborations between
Replicant and other free software projects.

Tasks

The range of tasks will be very diverse. For instance:

  • Interact with users through our various channels: IRC, forum, mailing list, bug tracker and blog comments.
  • Help users fix common problems by pointing them to the relevant documentation.
  • Help users write proper bug reports.
  • Explain the design decisions that were taken during Replicant’s development as well as the philosophical stand of the project.
  • Improve the wiki documentation, especially the end-user part.
  • Reach out to other free software projects in order to share work and reuse code between them and Replicant.
  • Keep an eye on work being done on other free software projects that may benefit Replicant.
  • Represent Replicant at conferences/events and coordinate the organization of such events.
  • Promote Replicant and free software both online and offline, through promotional material, blog posts and likes.
  • Supervise and promote fund-raising activities in collaboration with the FSF.
  • Manage applications for paid development work and help developers with paperwork and bureaucratic fullfilments.

It will be up to the community manager to decide which tasks to prioritize to best help the Replicant project.

Profile

In order to accomplish these tasks we believe that the community manager should be an individual with an extensive knowledge of Replicant and free software in general, probably acquired through years of usage and research. It should also be someone with good communication skills and ability to handle conflicts. Availability to travel long-distance in order to represent Replicant at events is also taken into account.

Accountability

Tracking each single action is not desirable nor an efficient use of time. Therefore, accountability will be mostly handled through a newsletter that should be prepared by the community manager. The content and periodicity of this newsletter will be up for the community manager to decide. It should not be focused on what the community manager has been doing, but rather on what is going on in the Replicant community and in other relevant free software projects.

In case any issues arise, the Steering Committee will decide on the continuation of the role by taking into account input from the developers, users and the community manager.

Funding

The community manager will engage in a contracting agreement with the FSF and be paid from the Replicant funds.

We expect that the workload will be around 80 hours per month. Although, it should be noted that this will be highly variable. Some months, like those when conferences take place, may require extra hours of work, while others may require much less.

How to apply

If you want act as the Replicant project’s community manager please send your proposal to the public replicant@osuosl.org mailing list and tell us shortly (max ~300 words) why you would be the ideal fit for this role.

We can be contacted privately at the Replicant contact address but at the end of the day a formal proposal will need to be made publicly on the mailing list.

Please submit your proposal by latest 15th of December 2020, 21:00 UTC.

The Replicant Steering Committee (with help from dllud)

Late report from FOSDEM 2020

On the 1st and 2nd of February 2020, 4 Replicant contributors (FilBerg, GNUtoo, GrimKriegor and dllud) attended FOSDEM 2020 in Brussels.

FOSDEM (Free and Open source Software Developers’ European Meeting) is an annual conference organized by volunteers, to enable users and contributors to meet and promote the widespread use of free and open source software. This helps communities take decisions and also enables various communities and people to collaborate together.

Part of this comes from FOSDEM allowing projects to book rooms in order to have meetings and presentations (dubbed as a BoF, Birds of a Feather). Replicant contributors held such a BoF, and also gave a talk at another room and wandered around the exhibition’s rooms talking to people at the stands of relevant projects.

As it is a conference, the FOSDEM also features talks by various members and contributors of the free software and open source communities which range across many different projects and areas. Listening to the talks (which are often recorded as well) is a way to get the latest news of what’s happening in the free software world.

This is a (late, sorry for that) report with the relevant information that Replicant contributors leaned during the event, alongside with a summary of the discussions that took place during the BoF. This report is published both here in the blog and in the mailing list. Comments are gladly welcomed on both mediums.

Before Replicant BoF

Technoethical

Technoethical is a store that sells devices pre-installed withofficial versions of Replicant and also Replicant merchandise. It is featured at Replicant’s website and donates a percentage of its sales to Replicant.

We went to the Technoethical stand to discuss the idea of only requiring a percentage of the sales for bigger companies, which wouldn’t include Technoethical. According to Tiberiu from Technoethical, Technoethical didn’t agree toformally give any percentages of the sales to Replicant, but they instead do it voluntarily.

Wikidata

We had a discussion with someone involved in Wikidata about how to describe hardware like smartphones in Wikidata.

For instance there is an entry for Replicant in Wikidata, and we want to be able to more precisely express that a given software, like Replicant 6.0 0004, or the Lima Linux driver, is compatible with a given smartphone or GPU.

Right now this seems to be done through the Platform property. Unfortunately, this property by itself cannot tell precisely which version of Replicant is compatible with say the Galaxy Nexus (GT-I9250). We were told to look into the qualifier to see if we can find a way to express that.

After looking at it we found that it’s possible to add a platform qualifier for a given version, for instance to tell that Replicant 6.0 is compatible with the Galaxy SII (GT-I9100). However, after this, it is not possible to add an extra layer of qualifiers to tell for instance that the Galaxy SIII 4G (GT-I9305) is compatible with Replicant 6.0 except for its modem.

The goal here is to be able to use Wikidata as a database for storing information about hardware and software. This way we could reuse that information easily in various tools and/or in MediaWiki after having migrated to it. We already have a very rough tool to experiment with that and print some information about Replicant versions and the devices they support.

Replicant BoF

Like last year we also had a Replicant BoF this year.

Organization

This year we improved the organization of the Replicant BoF:

  • Most of the people in the room seemed really engaged and interested in it, whereas last year we got the impressions that people were less engaged and interested.
  • While things were more organized than last year we still need to improve on it. For instance we lacked a precise schedule for the BoF in order to properly cover all the topics we needed to. The consequence is that we usually try to rush at the end in order to cover some topics we didn’t have covered yet.
  • We also had the ability to remotely listen to the BoF through Mumble and participate through IRC. At the beginning we tried a setup that was too complex, with speakers, to enable remote participants to speak. This setup took too much time, so when enough people were in the room, we started without that and fell back on IRC for participation instead. As we were late to start, and were rushing to make the more complex setup work, we also forgot to record the meeting.
  • Properly organizing a BoF is not that easy as we typically are short on time and also need to organize many other things in parallel such as the talks we give in other rooms.
  • For next year, we need to decide on weather or not we could fund or reimburse travel costs for someone from the Replicant community, like Kurtis Hanna, that has a deep enough knowledge of what is going on in Replicant, to help us with the organization of the BoF.

Build system

During the BoF, we did a quick presentation of the issues we were having with the Android build system. More details on the issues are available on the “Android’s build system is messier than your distro’s” talk that was presented at 36C3.

GeckoView

We also did a quick presentation of the freedom issues we were having with WebView. As with the build system, more details are also available in a presentation (“The Chromium mess meets Android”) that was held at 36C3.

We then got questions and ideas on how to solve that issue.

One of the ideas was to go for the lowest hanging fruit and implement the easiest part of the WebView API with GeckoView, which should suffice for some applications.

Once this is done we would still have the problem of making the F-Droid applications use it: the application developers will probably not include GeckoView in their applications as it would increase the size of the package by around 20M (which is a lot).

But even if they do, it would still be an issue as each package using WebView (and there are many) would have its own GeckoView, which would probably increase RAM consumption.

There are kernel features like CONFIG_KSM which reduce the RAM usage by finding duplicate regions and making the duplicated pages point to the same region until the data is modified. However, this may not be a proper solution, especially if the GeckoView builds shipped with each app are not exactly the same. It may also increase CPU consumption as CONFIG_KSM has to scan the RAM for duplicated pages.

Several solutions were proposed by Replicant contributors and people attending the BoF:

  • Make Replicant ship a GeckoView that is ABI compatible with WebView (even if not all of the WebView is implemented).
  • Use F-Droid to build and distribute GeckoView.
  • Develop software that would automatically recompile all the F-Droid applications that link against WebView to link against GeckoView instead, and automatically publish the result in a dedicated F-Droid repository.
  • Applications could potentially be tagged with supporting or not supporting a given incomplete WebView implementation implemented through GeckoView.

Upstream

Replicant only wants to supports devices that reduce the amount of harm for users freedom, privacy and security. For instance all device supported by Replicant 6.0 and onward have some form of modem isolation.

However some people might still want to support devices that attack users freedom, privacy, and security more than the ones already supported by the current Replicant release. So we explained that while such devices could not be supported by Replicant, the Replicant project is open to collaboration with other projects like LineageOS to add support for such devices.

This is relevant to Replicant because Replicant 9 uses a Linux kernel that has very few patches on top of the upstream Linux. So while Replicant 9 is not ready yet, when it will be, most of the Replicant 9 code will probably be reused to support smartphones and tablets that have good support in upstream Linux. So, even if for smartphones with different modems, more work would be needed to support the modem, there will probably be some people interested in reusing the Replicant 9 code.

This means that we would need to work with other upstreams to find the best ways to deal with it and share the maintenance of the code. Unfortunately there weren’t any contributors from other Android distribution in the room.

Galaxy SIII (GT-I9300), Replicant 9 and LineageOS

As ChronoMonochrome is also working on porting the Galaxy SIII to LineageOS, we collaborated together when it was possible, as we were both trying different approaches.

On Replicant 9 we were focusing more on the 2D graphics, and on the modem, which doesn’t work yet with LineageOS.

Once we have something usable on Replicant 9, it would also be very interesting to find time to work on upstreaming the modem driver as well:

  • In several cases the kernel maintainers refused patches for drivers lacking free software userspace for using them.
  • As Replicant has a free software implementation, it shouldn’t be a problem.
  • Similar modems are already supported by the Linux kernel, like the N900 modem, but the kernel interface is different from the one exposed by the kernel shipped by Samsung.
  • As LineageOS functional requirements to support a device are more strict than Replicant, if the Galaxy SIII modem driver is merged upstream, and LineageOs wants to use libsamsung-ipc (and libsamsung-ril) to use that driver, they would probably have some interest in helping to complete the libsamsung-ipc implementation as well.

F-Droid

We have already removed F-Droid from Replicant 6.0 after the 0003 version. This is due to the F-Droid repository not being compliant with the Free System Distributions Guidelines, because of applications like Yalp.

If there were no means for users to collaborate on workarounds, each user would need to review by themselves each application they are considering to install.

So we created the F-DroidAndApplications wiki page to share the work on reviewing F-Droid applications that meet or don’t meet the Free System Distributions Guidelines.

We started reviewing some applications. Unfortunately, even when the source code should be fully free, we are not sure if the resulting builds meet the guidelines, as we would need to make sure that it’s possible to compile the same application with a distribution that meets the FSDG guidelines.

We need to look more into it and/or to write to the licensing team at the FSF.

Documentation and migration to MediaWiki

We briefly talked about the rationale of migrating the wiki from Redmine to MediaWiki. The main advantage is that it will avoid duplication of information. For instance, the fact that the Galaxy SIII has a MAX6673 chip is mentioned in many different wiki pages such as:

This happens because that chip is involved in many different things, ranging from power management to managing the switch behind the USB connector which enables to get access to the serial port.

It is therefore relevant to know about that chip in many different contexts.

MediaWiki has ways to avoid the duplication of some information through templates, and it’s also possible to interface it with Wikidata in various ways.

Someone mentioned that Sphinx handles such requirements. However, as not everyone that contributes to the wiki knows how to program, and as the contributions of such people are quite substantial (many edits, creation of pages, etc), and that we do want to enable people not knowing programming to edit the wiki, we will probably consider switching to MediaWiki instead of tools like Sphinx.

Release schemes

Someone pointed out that upstream Android continuously gets security updates. To keep up with that, we would need to do Replicant 9 releases very often.

While some people pointed issues with rebasing our work, it’s probably still achievable to do that, as porting our work forward from Android 9 to the next Android versions is supposed to be easier.

Someone also pointed out that, for a given Android version, LineageOS was backporting security fixes longer than the Android Open Source Project (AOSP).

This information made us reconsider some design choices in Replicant: once Replicant 9 has been released, the fact that LineageOS doesn’t have stable tags for releases becomes less relevant as we will need to find ways to rebase and release often, in order to have the latest security fixes.

Vulkan

Someone mentioned that the Vulkan graphics API will become mandatory after Android 10. This would mean that the graphics stack we’re developing for Replicant 9 would no longer suffice. Both Lima, the free software driver for the Mali GPU present on the Galaxy SIII (GT-I9300), and llvmpipe, the software rasterizer planned to be used as fallback on all other devices, only support OpenGL ES.

A possible workaround would be switching the fallback software rasterizer from llvmpipe to SwiftShader, or using it just for apps that need Vulkan support. We are actively making sure that SwiftShader works on Replicant 9, therefore this should be doable without much effort.

Note: someone suggested using a translation layer that runs Vulkan on top of OpenGL ES, but that does not exist and probably never will. Vulkan is a lower-level API than OpenGL, with finer-grained control of the GPU memory and likes, making it really hard to implement OpenGL on top of it.

A nice tip we got is to keep using a compositor (SurfaceFlinger) that works with OpenGL ES. Current SurfaceFlinger still doesn’t have Vulkan support. Acceleration is still done through OpenGL ES or an hardware composer. As such, compositor performance and compatibility won’t bean issue for the time being.

After the Replicant BoF

Replicant contact address

We found that Fil Bergamo, who is part of the Replicant Steering Committee, didn’t receive emails from the Replicant contact address.

We need to setup a new email infrastructure in order to properly address this issue. Currently the contact address is hosted at PaulK’s personal email server. Paul no longer has time to maintain it and thus we must transition to a new server, hosted in a VM at the FSF servers, that can be administered by several Replicant contributors, in order to avoid a single point of failure.

Legal advice

The FSFE is helping NLnet by giving legal advice to the people beingfunded by NLnet to work on free software.

After the Replicant BoF, we met Lucas Lasota from the FSFE who offered legal advice, probably through the ifrOSS institute, to the people being funded by NLnet to work on Replicant (or the Replicantproject at large?).

The Replicant project is already getting legal advice through the FSF, and the FSF also has a very big expertise on compliance with certifications like the Free Software Distribution Guidelines, but the FSFE legal team and/or ifrOSS legal team probably also have some very interesting knowledge about European law.

For instance Till Jaeger who is/was involved in the ifrOSS institute made a very interesting talk years ago on what constituted derivative work under the European laws and directives.

Necuno

After the the Replicant BoF, we discussed a bit with someone from Necuno. They were supposed to make a device that could be used with only free software. The hardware only had the following issues:

  • On the I.MX6 System-On-a-Chip they chose, the firmware for the audio/video decoding offload is nonfree, but in many cases that can simply be ignored as that kind of thing is done by default on the main CPU.
  • The I.MX6 DMA engine probably had a nonfree firmware but it was completely optional, as the Linux kernel knows how to use the builtin DMA engine ROM instead.

So the device would have been completely usable with fully free software. They also stated in several places on their website that it would have been possible to run fully free software on the device.

This was also made possible because the device wasn’t a smartphone and would not have any modem or WiFi chip.

But they are now are planning to add a WiFi chip, and to ourknowledge, all the WiFi chips made for smartphones and tablets require a nonfree firmware.

While Replicant is not redistributing any nonfree software, it still loads the modem firmware into the modem. In addition, all the devices currently supported have many more freedom issues, from forcing users to run nonfree software at boot, to having their location tracked by the network, at all times, with a precision of 10 or 20 meters.

In the long run, for the WiFi firmwares, it would be a good idea to have people working to get free WiFi firmwares and really solve the issue for good, instead of finding workarounds that don’t solve the problem.

In the mean time, the workarounds still have the benefit of making clear what is free software and what is not; this clear separation enables us to claim at the same time that Replicant itself is fully free software while the devices it currently supports do not respect users freedom, and do run nonfree software as well.

Necunos also told us that they had some underlying issues because their devices would be “dual use” devices. This is related to the fact that they are also targeting some markets like the Finish defense or secret services, but we didn’t understood what it meant practically speaking.

NLnet and the Android build system

We discussed with Michiel from NLnet the issues we were having with the Android build system. He pointed again to us that NixOS is working on being able to build Android components.

At some point we would need to look more into it as we want to mix Android and GNU/Linux components together. If we want Replicant to scale and be able to support more devices, it would be a good idea to be able to reuse some GNU/Linux userspace components that make hardware work, like oFono, BlueZ, etc. This would also allow us to share more work with GNU/Linux.

There are more details on the Replicant wiki about issues GNU/Linux distributions are having for packaging Android components like adb, which depend on the Android build system and libc.

Maemo Leste

On the last day we also met someone from Maemo Leste. At first when hearing of Maemo Leste, we feared that nonfree components from Maemo would be reused, as Maemo had a lot of nonfree components. However, according to the people we met, only the free software ones werere used. Still, nonfree software not coming from Maemo, like thenonfree WiFi firmwares or nonfree GPU drivers for some phones, were still used.

We also saw Maemo Leste on a PinePhone. On this device, the graphics stack was using the free software Lima driver and the graphics were fast enough. We can’t remember if Lima was stable enough for daily use but it looks really promising at least, because the whole graphical interface used it, and we saw no rendering artifacts while briefly testing it.

GitLab

GitLab was first built upon a framework that did most of the work on the server side, but at some point they switched to a framework thatdoes client-side rendering with JavaScript.

As we had an opportunity to talk with people from the GitLab team, weasked them whether they would be open to accept patches that fix this. They explained us that such would require to double the UI work for everything, but that it might be possible to do server side rendering with the same JavaScript that’s used on the client. The issue is that it cannot make requests from buttons like that, so in addition to the page rendering that could happen through server-side JavaScript, introspection could be used to rewrite the buttons.

Batteries report

In Paris (France), last year, batteries for phones compatible with Replicant could easily be found in second hand shops, and in a chain of shops specialized in replacement batteries. But we got a more recent report that it was not the case in similar shops in a smaller city.

Talks

Extending the lifetime of smartphones with Replicant

This talk was held at the Hardware Enablement devroom.

It quickly introduced Replicant and the smartphones ecosystem, and then proceed to look at what affects smartphones’ and tablets’ lifetime and how to increase it by making Replicant more sustainable.

There was also a small, satirical play in the middle this talk. Its goal was to show how the current market trends in smartphone design and construction severely impair those that look for privacy, software freedom, and reduction of electronic waste.

Video and slides are available at the talk’s page in FOSDEM’s website.

Extra

Fun

Fil Bergamo started making a song about Replicant.

Previous conferences

If you enjoyed reading this report, you may wish to take a look at the reports from previous conferences that were (only) published on the mailing list:

There’s also a wiki page that lists all talks about Replicant that happened in several conferences throughout the years.


Edit1: Fixed “ssupported” typo

Edit2: Fixed the “onthe” typo

GNUtoo and dllud

What could go wrong with devices that have non replaceable batteries ?

Edit1: Added forgotten link for rooting devices

Edit 2: Fixed wrong link location for rooting devices

Edit 3: Added Epilogue

In the summer 2019, in the Replicant contributors conference in Paris, the people present were all in favor of not supporting devices with battery that can’t easily be replaced, because it would make the use and development of Replicant for these devices too complicated.

In subsequent conference like the FOSDEM 2020, and in discussions with other Replicant users and/or contributors, people didn’t have objections to the decision.

Even if we don’t want to support such devices in Replicant, we are still open to collaborate with people wanting to add support for such devices in other projects. For instance we still support the Galaxy S and the Nexus S in libsamsung-ipc while the devices are not supported anymore in Replicant, and we also do accept patches for devices we don’t want to support in Repliant.

So in practice, some tablets like the Galaxy Tab 2 have battery that are not removable in the usual sense as you cannot remove the battery, without any tools, while walking, but the battery can still be replaced with the help of basic tools like tweezers and screwdrivers. In addition people don’t necessarily expect tablets to last one full day. So we still intend to support such devices.

However some smartphones, which are typically used during a full day without necessarily having the ability to recharge, cannot be opened with regular tools. For such smartphones you need a heat gun, and using that also damage the device along
the way. When the battery is glued with very strong glue, it makes it even more complicated and even more dangerous to change the battery as you need to use very dangerous chemicals to remove the glue. So we decided to not support devices like that.

Given the impact of the decision (most newer phones don’t have non removable batteries), even if that decision seem sound in theory, we also wanted to test it in practice, to be really sure it was the right decision.

To do that we decided to do a very quick experiment and see what would happen when adding support for a smartphone that has a non replaceable battery.

We also wanted to measure how much time was needed to add support for a device as fast as possible, because if we supported devices without a replaceable battery, we would need to rush to add support for the device while it’s still being sold new in order to maximize the lifetime of the device under Replicant. Otherwise, people would need to buy the device second hand, where the battery would potentially not last a full day anymore.

Choosing a device

We didn’t want to spend too much time on that experiment, so we didn’t do much research and choose the first phone that would match what we were looking for.

We wanted the most recent device device with:

  • A non replaceable battery
  • An Exynos system on a chip
  • Android 6
  • A stylus and a big display
  • A lot of RAM

The device also had to be very similar to the ones we already support to spend the least amount of time possible on that experiment, so we also wanted the device to be made by Samsung, and to have a similar bootloader that is compatible with Heimdall.

So we choose a Samsung SM-N930F which meets all the requirements above. It also has an Exynos 8890, 4GiB of RAM, a stylus and runs Android 6. We wanted to have a stylus and a lot of RAM because as we didn’t really intend to add official support for it in Replicant, we still wanted the work to also be potentially useful for GNU/Linux distributions that might be interested in supporting this device or similar devices:

  • The amount of RAM and the stylus makes it more easy to run GNU/Linux
    on the device:
    • As the stylus is more precise than big fingers, you can more easily use software that is less well adapted to the very small display, the very high pixel density, and big fingers.
    • Having 4GB of RAM should be good enough to run many common applications and desktops. It also means that the phone could be supported for a longer time if there weren’t other factors like the non-removable battery that would prevent that.

As for Replicant, the software support for this device is very similar to the Galaxy S7 which is supported by LineageOS.

Unfortunately, the device we chose has shared memory between the modem and the system on a chip[1] but as this was just for a quick experiment and that we didn’t intend to add support for it in libsamsung-ipc, we just ignored that issue in order to spend the last amount of time possible.

References:

[1]https://github.com/RegaliaEzz/Hexa-N930F/blob/master/arch/arm64/configs/exynos8890-gracelte_defconfig

Getting the device

The first problem we had was finding the device. We started looking locally, including in second hand websites, but we didn’t manage to find any. So after that we started looking in international second hand websites, and we found one.

The strange thing is that, while the device is very hard to find, there were many many offers for accessories for that device. At this stage we suspected that this was somewhat related to the non-replaceable battery, though some Galaxy S7 could still be found.

However for some reasons, even if the device was shipped, as we have proof that it was sent to the post office, we didn’t receive it. We are still investigating why, but we didn’t manage to get a conclusive answer yet from the shipping company as we were redirected from service to service and no one seem to know why the device didn’t reach its destination. The issue is also unrelated to COVID-19 as it was shipped by the person many months before it was declared a pandemic.

So we started again to look for a device and finally found a second device. The offer was really strange. It tell that they disguised the device to look like another one to make shipping work.

This didn’t surprise us, as some customs are already actively fighting against the right to repair devices[1]. So at the time we though it was because they decided to fight against the second hand market as well.

In that offer, the person giving the device away also had a strange request: she would not charge for the phone but she wanted us to get the data out of the phone. The person explained to us that she didn’t trust nor Google nor Samsung with her data, which included private pictures but didn’t manage to get her data out of the device. As the request seemed legitimate we agreed to try but as we are not expert in rooting that it might have failed. The data was not encrypted so it also would have made things easier.

References:

[1]https://boingboing.net/2018/10/20/louis-rossman.html

Working on the device

Working with that device was not easy. The first issue we got was that the battery would not charge at all, and the battery indication was at 0%.

This explained why the person wasn’t able to extract her data from the device.

We found on XDA that it was possible to get the battery charge again if we managed to downgrade the phone OS. This looked very strange. We also learned that the phone was fusing the OS versions somewhere. This was probably in the RPMB (Replay Protected Memory Block) partition of the eMMC.

As the device was on fuse version 1, we managed to downgrade it. All that was very strange. The 0% battery charging problem seemed to be a well known issue that is supposed to only affect the the devices fused with the version 2. Maybe it was because the battery was already very discharged that it did that, and that the bootloader and OS refused to charge it.

As we didn’t have a lot of time to spent on all that, we didn’t want to investigate more and proceeded to download OS images for older versions of the devices. We are also not sure if this was legal or not as the images weren’t hosted by Samsung, and so we don’t know
if the website we downloaded them from had some arrangement with Samsung or not.

As official repair shops need to have the images, we assumed that there might be a way for websites to get the images through legal means, especially in countries that have laws that are meant to guarantee the right to repair in practice.

Extracting the data

Before downgrading the images we still wanted to try to extract the data for the person that sent us the device. So as we were unsure if installing a recovery would erase the user data, we tried to find free software root exploits for the device.

We have summarized our attempts in the RootingDevices[1] page of the Replicant wiki. We still need to update it to add information about our attempts with the SM-N930F.

As we didn’t find any rooting application in F-Droid, and that we didn’t want to use nonfree applications to root the device, we instead started looking at vulnerabilities that enabled us to get root. For each vulnerability we looked if the kernel version of the device was affected, and if so we looked for free software versions of the exploits, that were often published without any license.

At the end we failed to find something that worked quickly so we resorted to just flashing a recovery and hoping that it would not erase the user data. According to the find command, the user files seemed to have been intact.

We then sent the ex-owner all the data, strongly encrypted with GPG, and when we got the confirmation that everything was fine we proceeded to erase all the data.

References:

[1]https://redmine.replicant.us/projects/replicant/wiki/RootingDevices

Working on Replicant

At this point, we found that the battery was just very old, this is why it was reporting a 0% capacity.

Each time we wanted to flash an image with Heimdall, we had to wait for hours for the device to charge a tiny bit.

The stress of the developer working on the device increased a lot because the device was potentially always on, and we didn’t know when it had the ability to record conversations or not, as we didn’t do a review of its freedom, privacy and security issues.

The developer’s passwords could be revealed as well, by recording the noise of his keyboard, and even GPG keys can be reconstructed through noise if they are used intensively.

In order to preserve the developer’s sanity and the security of the Replicant project, the device was kept in the fridge most of the time.

This was very weird for the people visiting that developer as he had to put the device in the fridge each time people came by.

Sometimes he forgot to put the device in the fridge and started to have political and/or intimate conversation and at some point he remembered the device and had to go put it in the fridge in the middle of the conversations. That was very weird. Especially the “Can you wait a second? I’ve to put the phone in the fridge.” part.

In addition to all these issues, we also had the device crash during development, however we couldn’t wait until the battery was fully depleted as the battery didn’t charge. We had to hope that the device wound not go in some mode where we were stuck. However it didn’t happen, and we always managed to recover.

Then one day, around when the COVID-19 confinement started, when he was away doing some sports outside, the neighbors heard an explosion. Apparently, besides the table where it was charging and and the wall around it, nothing was damaged.

As some of the neighbors called the police, that developer was then arrested and all his equipment was seized.

He was charged with:

  • the possession of an explosive device
  • reverse engineering
  • theft
  • counterfeiting
  • violation of trade secrets
  • refusing to give encryption key of his hard disks
  • refusing to hand over his account details
  • refusing to give his fingerprint and his DNA
  • resisting arrest and insulting police officers
  • destroying evidence

He plead innocent for all of the charges, and most of the charges were dismissed:

  • The “explosive device” was in fact the Samsung SM-N930F, which is best known as Galaxy Note 7. As many other people also had one at some point, the court dismissed that charge, especially because this wasn’t done on purpose. The judge also said that they couldn’t condemn people for being stupid, not remembering about the issue, and relying on the outdated offline version of Wikipedia through Kiwix to do research on hardware.
  • The reverse engineering charges were also dismissed as it was done for interoperability, and that the developer never agreed to any user license agreement that prevented that.
  • Theft was quickly dismissed as it did not apply to the violation of copyright.
  • The violation of trade secrets was also dismissed, even if printed schematics were found on the developer’s table. As the schematics were published online in many forums like XDA, they were also considered as fair use. Various leaked documents like the Snowden documents, or Wikileaks revelations were also used during the case to prove that some leaked documents could be considered as fair use. The fact that the documents had “proprietary” markings was also not sufficient as many public documents also still bear markings that were just not removed.
  • Counterfeiting was also dismissed because no proof of violation of copyright could ever be found, and that the use of leaked schematics was considered as fair use.
  • Refusing to give encryption key of his hard disks: with a lot of pressure from many associations, this was dismissed as it was merely an excuse to get access to the developer’s data and it was not relevant to the case. The same applied with his refusal of handling any of this account data (which also includes the passwords giving access to the Replicant infrastructure).
  • Destroying evidence by erasing the data of most of his computers was also dismissed. First only the boot partitions were erased and it was again not relevant to the case.
  • Resisting arrest and insulting police officers: there were no proofs that this ever occurred, and rambling against non-removable battery was not deemed strong enough to constitute resisting arrest and/or insulting police officers.

Sentences

However he was still charged with the following:

  • Refusing to give his fingerprints.
  • Refusing to give his DNA: the police still got his DNA even if he refused.

Subpoena and other declarations:

  • The court also gave him a subpoena “Be more careful next time and work on more constructive things like adding support for phones with a removable battery only.” to which the developer agreed.
  • He also declared that rushing to add support for a phone wasn’t a good idea either, as because of that, he didn’t realize that the device was a Galaxy Note 7.

He got a suspended sentence of 3 months for all that.

Getting the equipment back

As the court was very friendly he also got all his equipment back which usually never happens. Getting it back was still very challenging but it also turned out to be very fun.

As the developer had to sign a document with all the hardware on it, to get it back, the following conversations occurred when filling the list of hardware:

  • Employee: What’s this thing?
  • Developer: It’s a UART adapter for smartphone, you know behind the USB connector there is [very long technical explanations].
  • Employee: Let’s write “UART adapter for smartphone”.
  • Developer: It also probably works on tablets you know, and it can also do many other things other than UART, like power on the phone and switch modes [very long technical explanations].
  • Employee: Let’s write “complicated computer hardware”.

Or:

  • Employee: What’s this thing?
  • Developer: It’s a hardware to trace the protocol between the SIM card and the phone modem, there is a standard called terminal profile which has many privacy implications like [very long explanations].
  • Employee: Let’s write “SIM card tracker”.
  • Developer: It can’t track SIM cards at all, but it can trace the protocol [very long explanation again].
  • Employee: Sigh, let’s write “complicated computer hardware” again.

Or:

  • Employee: What’s this laptop? It’s a laptop, right?
  • Developer: It’s a Thinkpad X200, which is a computer capable of running Libreboot, this has many freedom implications like [very long explanations].
  • Employee: Let’s write “vintage computer”.
  • Developer: But I use that computer you know [very long explanations].
  • Employee: Sigh, let’s write “complicated computer hardware” again.

Or:

  • Employee: What’s that? Is it a very complicated smartphone?
  • Developer: It’s just a usual Galaxy S II (GT-I9100G).
  • Employee: Let’s write “Galaxy S II”.
  • Developer: I’ve also a Galaxy S II (GT-I9100) which has a very different system on a chip [very long explanations].
  • Employee: Sigh, let’s write “complicated computer hardware” again.

Or even:

  • Employee: What’s that?
  • Developer: I don’t know
  • Employee: You don’t know? Is it yours?
  • Developer: Yes, but I don’t know how to describe what it is, you can think of it like an Arduino running GNU/Linux, back in the days before any of the single board computer had systems to automatically detect hardware [very long explanations].
  • Employee: What’s an Arduino [interrupting the developer]?
  • Developer: [very long explanations starting].
  • Employee: Sorry [interrupting the developer], bad idea, forget about my question, let’s again write “complicated computer hardware”.

At the end the developer got it all back, and the staff said it was the strangest set of seized equipment they ever seen.

He then was unavailable during a full week, as he was reflashing all the “complicated computer hardware” for security reasons. That meant that in practice he had to reinstall Libreboot[1] or other fully free versions of Coreboot that he used, Parabola[2] on all the desktops, laptops, servers, single board computers and smartphones that weren’t fully encrypted, reinstalling Replicant on some other smartphones and tablets, reinstalling LibreCMC[3] on various devices like WiFi access points, reinstalling various microcontroller projects like frser-duino[4] on his flasher, ralim/ts100[5] on his soldering iron, PedRom[6] on his calculator, Simrtace 1.0[6] on his SIM card tracer 1.0[7], etc

At least he could still trust his hardware and continue to use it after reinstalling everything. If the hardware had to run nonfree software, it would have been a different story.

Besides about 1 month of Apache logs, and the phone number of his contacts,
not much was exposed. We also hope that Android “Factory erase” worked fine on the SM-N930F but we can’t know as we didn’t try to recover any data.

The only device he didn’t got back was the Samsung SM-N930F, as it was probably kept or disposed by the Justice Department.

About the lost of the device, the developer commented: “I lost weeks [of work] because of that shitty phone”, “I don’t want that phone anywhere near me.”.

It turned out that, in addition to his allergy to nonfree software, freedom and privacy violations, that developer now became allergic to non-replaceable batteries as well. “Deciding to make devices with non-repleacable batteries is completely insane, it would be very important to ask ourselves how we got there.” that developer commented.

References:

[1]https://libreboot.org
[2]https://parabola.nu/
[3]https://librecmc.org/
[4]https://github.com/urjaman/frser-duino
[5]https://github.com/Ralim/ts100
[6]https://git.osmocom.org/simtrace/
[7]https://osmocom.org/projects/simtrace/wiki/SIMtrace

Epilogue

This blog post is a fictional political satire written by a Replicant developer for the first of April 2020. It may or may not represent the positions of the Replicant project. The story has been very strongly inspired by several real events.

  • It contains several logic flaws that might have been spotted by attentive readers or people used to the zététique techniques. For instance the device was chosen to enable sharing work with GNU/Linux, yet, support for Replicant 6 is added in a way that doesn’t benefit at all code sharing with GNU/Linux at all as no support for that device is added in libsamsung-ipc. The fact that it was not clearly marked as a fiction was intended to help people test their critical thinking.
  • It’s meant to criticize the systemic causes that resulted in the issue with the Samsung Galaxy Note 7 smartphone. The Wikipedia article on the Samsung Galaxy Note 7 has very interesting information on the impacts of the issue.
  • It’s interesting to see how Samsung used the control it had on such devices, to remotely disable them. That control could be abused. This could also be an issue if people have important private data in it, that they weren’t willing to share with companies with huge track record of users abuse. So instead of having to adapt to every design choice of the smartphone industry, like non-replaceable battery, it’s sometimes better to start from limiting as much as possible the damage to users freedom and the environment, and try to adapt that to various uses cases instead. Here, having user removable batteries would be way more efficient than control over users devices for avoiding such issues or dealing with batteries that explodes or catch fire. Many manufacturers had to recall batteries over the years, and the impact weren’t as bad as with the Galaxy Note 7.
  • As far as we know, that event didn’t make smartphone manufacturers switch back to user removable batteries. Samsung didn’t even add back non-removable batteries to the Galaxy Note 8 , which is the next model in the Galaxy Note series. If software or hardware that was threatening some economic or political power was the cause of issues that big, the reaction would most probably have been very different.
  • In general, giving too much power to the manufacturers over the users is a very bad idea. For instance in the Volkswagen emissions scandal, if users had more control over their cars, an issue of that scale could have been avoided. In contrast, if users had total control over their cars, more users would probably do various modifications, including polluting more to gain more performance or tune their cars to pollute even less. It would have preserved users freedom and probably have a positive impact than with such scandal. The same reasoning apply to the radio lockdown directive, which Replicant took position against.

Copyrights