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

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

Replicant contributors meeting the 27,28 July in France

A Replicant contributors meeting will take place in or near Paris in France the 27 and 28 July 2019.

As we are still looking for a place to host the meeting, we don’t have a definitive address yet.

It will be open to anyone who contributes or wants to contribute to the Replicant project.

The meeting will most likely be in English as not all the Replicant contributors who plan to attend speak French.

More details will be posted on the wiki page dedicated to this event over time.

Last minute information, if any, will also be posted on that wiki page.

The Replicant project will receive a mobile device from Necuno Solutions

The Replicant project has been looking forward to support devices with free software bootloaders. While Replicant is a fully free software Android distribution, many freedom, privacy and security issues are orthogonal to the operating system. The hardware design of each computer (smartphone, tablet, laptop, etc.) people use, and the architecture of the cellular network also have their set of issues. For more information on these issues, the Replicant project has some documentation on the topic.

So far all the devices that are (or have been) supported by Replicant use a nonfree boot software (the bootloader). These devices also use hardware restrictions to deny users the freedom to replace them completely with free software, effectively forcing them to run nonfree software. This is a very serious freedom issue that prevents users from being in control of their devices.

There were several attempts to add support for devices with free software bootloaders in Replicant:

  • The LG Optimus black: this smartphone doesn’t prevent users from replacing the bootloader. Paul Kocialkowsky did a lot of work to add support for this device in upstream u-boot (a free software bootloader) and added minimal support for it in the upstream Linux kernel. However support for some of its most important hardware components like the display are still missing in the Linux kernel. This device can probably still be found second hand
  • The GTA04 smartphone from Golden Delicious: this smartphone has a free software bootloader which is based on u-boot. The smartphone was designed to run GNU/Linux and has almost complete support in upstream Linux. There were attempts to add support for it in Replicant 6.0, however a lot of time was spent to try to make suspend to RAM work with Android. However older Replicant 4.2 images are available. Several hardware revisions of the GTA04 have been made and shipped to customers and developers over the years. However this has stopped due to manufacturing issues. Another issue is that the revisions before A5 only have 512M of RAM and a high DPI display: This combination makes running Android 9 potentially challenging. Fortunately the A5 revision has 1G of RAM, but not a lot of working units were produced.

There is also some ongoing work to specifically add support for smartphones that are currently supported by Replicant like the Galaxy SIII (i9300), the Galaxy Note 2 (n7100) and their 4G versions (i9305 and n7105). The 4G versions could also be supported by Replicant if the work to support their modem (through QMI-RIL) is resumed.

The Replicant project will receive a mobile device, the NC_1 (formerly called Necuno Mobile) from its manufacturer (Necuno Solutions), which will have a free software bootloader

This device has the size of a smartphone, but doesn’t have a broadband modem: while users will not be able to use a built-in modem for phone calls, SMS or to access the Internet, it is still the best way to be completely sure of avoiding any freedom privacy and security issues related to broadband modems and the cellular network. It will also require less work to add support for this device in Replicant.

Even if it’s possible to disable the modem on some of the mobile devices currently supported by Replicant by not loading the modem’s code, some nonfree software still run on these mobile devices. This includes the bootloader and potentially any other nonfree software that it may load. Because of that we cannot be 100% sure that the modem is completely disabled.

The Necuno Mobile will use an I.MX6 Quad system on a chip (which is a chip that contains the main CPU, the microSD card controller, the GPU, etc.). Its free software support is better than for many other system on a chip: the only functionality of the I.MX6 Quad that requires nonfree software is the video decoding acceleration. The article on single board computers has more details on freedom issues affecting various system on a chip and by extension the single board computers that use such components.

A Replicant developer (Joonas Kylmälä) will receive a Necuno Mobile to work on it.

The Necuno Mobile should have a Linux kernel that is very close to upstream: this is a good opportunity for a new attempt to enable Replicant to use upstream kernels. This has many advantages. One of them is that in the long run, it should decrease the amount of work required to maintain the devices and potentially increase their lifetime.

This should also enable the Replicant project to more easily add support for other devices that can use an upstream kernel, like the GTA04, or devices like the Galaxy SIII (i9300) and the Galaxy Note 2 (n7100) that are starting to have good support in upstream Linux.

It is also very interesting in the long run as we could share some of the work with other smartphones projects like postmarketOS who are also trying to support mobile devices with upstream kernels. It could also enable the Replicant project to more easily support future mobile devices that will have free software bootloaders, as some of them will also use kernels that are meant to run GNU/Linux.

Third Replicant 6.0 release

A new version (0003) of Replicant 6.0 has been released a few weeks ago.

It fixes an important issue that makes devices end up in a boot loop (the devices were crashing during boot, endlessly) when installing certain applications.

It also fixes a security issue that enables attackers to decrypt and/or modify WiFi traffic.
This can be problematic if your security is relying on the WiFi encryption. This can be the case if you are using WiFi to connect to your device to use applications like Remote Keyboard over telnet. This can also be problematic if you share your Internet connection through WiFi and some services of the phone operator you use are available without authentication.

Because of the above, updating to this new version is strongly recommended.
See the update instructions on the wiki for that.

If your device is affected by the boot loop issue mentioned above, the update instructions won’t work, as they expect you to be able to easily reboot to recovery.
In that case, to reboot to the recovery you have to first boot in safe mode, and then to follow the update instructions to reboot to recovery.

Replicant 6.0 early work, upstream work and F-Droid issue

Replicant 6.0 early work and associated efforts: At Replicant, things are moving again: Replicant is being updated from Android 4.2 to Android 6.0 by Wolfgang Wiedmeyer. The status and feedback takes place in the forums before it is reviewed and integrated in the official Replicant repositories. This work is currently being done for the Galaxy S 3 (I9300).

At the same time, Wolfgang Wiedmeyer is also working on the following for Replicant 6.0:

  • Graphics acceleration with mesa and llvmpipe: while this still uses the CPU, it should be faster and more feature-complete than the default implementation. This will hopefully fix some of the previously non-working applications in F-Droid.
  • Building the toolchains: Replicant has always used some pre-built toolchains and utilities. Building such tools and/or using the ones from GNU/Linux distributions will make Replicant more trustworthy.

Replicant 6.0 should also bring full device encryption and SELinux support.

Future directions: In the future we also want to be able to support the upstream Linux kernel for devices with a minimal amount of effort. This was made possible thanks to:

  • Android becoming more standard: it now requires very few changes to the upstream Linux to work. Linux also received changes that made it possible.
  • The fact that the amount of work required to mainline a device in Linux has drastically been reduced, for some of the devices we target.

Devices such as the GTA04 and the Optimus Black are good targets for upstream Linux kernel support. They also allow running free bootloaders.

In a similar fashion, we also want to be able to support upstream bootloaders, such as U-Boot.

We hope that this will allow us to have longer term support for such devices. Even if Replicant is unable to continue to support such devices in the future, having them supported by upstream software will potentially enable users to use them with other free software distributions.

We have thus started the work to support devices such as the Optimus Black and the Kindle Fire (first generation) in upstream Linux and U-Boot. Other projects and individuals are also very actively adding support for other devices, such as Allwinner tablets, that will benefit Replicant eventually.

Helping Replicant by contributing to F-Droid: Replicant is supported, recommended by the FSF and listed as a fully free software distribution that respects the GNU Free System Distribution Guidelines, along with other GNU/Linux distributions such as Trisquel or Parabola. Replicant
ships the F-Droid package manager in its images.

F-droid is committed to distributing only free software, and it does. However some of it does not comply with the GNU Free System Distribution Guidelines.

Practically speaking some of the applications F-Droid distributes:

While the list of such anti-features is displayed in red when selecting an application in F-Droid, applications with anti-features are still listed aside compliant ones. This is also quite confusing since free software isn’t expected to contain
such anti-features in the first place.

It took Replicant a long time to realize the issue, this is due
to its developers being very busy, to the fact that the anti-feature
display is confusing and that there was no clear smoking gun.

After an investigation, that was delayed due to the lack of time, a
smoking gun was finally found, and a bug report was opened on the Replicant side.

At FOSDEM 2016, the issue was discussed with F-Droid developers in order to find a way to fix it. On their side, F-Droid developers also opened a bug report. Due to various reasons, progress was very slow and we recently learned that efforts to fix this issue came to a stall.

Replicant developers are more dedicated and used to working on system programming than writing or modifying Android applications. They are also really busy doing so. However, some individuals wanting to help Replicant may be able to work on Android applications, with some time to do so. This is exactly the kind of skills required to solve this issue in F-Droid. Getting it fixed is crucially important for Replicant.

If you’re interested to jump-in and help resolve this issue, please get in touch with us or with F-Droid developers directly to get directions on how to get started.

Replicant lacks tracking antifeatures

Recently there was a lot of hype about mobile operating systems spying the users: Apple iOSPalm WebOS, Google Android.

Since Replicant is based on Android someone could be concerned about our operating system too.

According to Magnus Eriksson on github:

The files are named cache.cell & cache.wifi and is located in /data/data/com.google.android.location/files on the Android device.

Well we are proud to confirm that on Replicant (tested both on htc dream and nexus one) those files are missing,  even with "Settings -> Location & Security -> Use wireless networks" enabled.

The directory that should contain those files( /data/data/com.google.android.location/files ) doesn’t even exist  in Replicant.

But beware: even if Replicant itself doesn’t track its users’ position, this doesn’t mean that the phone can’t spy on you.

A smartphone usually has two components that talk to each other: a cpu and a modem. If the modem gets a call, it tells the CPU about it and viceversa for outbound calls, the CPU will order the modem to make a call (if you are curious about how it works there is a paper about how mobile phones work).

The modem and the CPU running Replicant are separated, and while we are trying to do our best to ship a fully free mobile os, the code running on the modem is proprietary software and can’t be changed. Since we don’t know what it does, we have no way to be sure that it doesn’t spy.

Also note that on the HTC Dream and the nexus one mobile phones,  GPS and audio parts are controlled by the modem.

The cellphone network can also spy, in fact in order to work it has to know your location.

This is just to remind you that every mobile phone is a tracking device and if you don’t want to be spied at all you should not use one.

So why do people invest time on Replicant?

Here are some reasons:

  • The modem or the network has no access to the CPU where replicant is running. That opens up some possibilities such as VPN, TOR,SSH, etc…
  • If mobile phones become the computers of the future we want to run free software on them.

Edit: I learned that the Modem’s CPU has access to the memory(the RAM chips) of the CPU running replicant, in other words the modem CPU can spy replicant’s CPU.

That will force us to port replicant to some devices that don’t have this problem, such as the nokia n900 for instance.