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


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

Replicant at FOSDEM 2020

As happens every year, FOSDEM is taking place on the first weekend of February. Several Replicant contributors will be at the event, eager to meet with other people interested in the project.

During Saturday Replicant will share a little corner on Technoethical’s stand. There will be flyers, stickers and some phones running demo versions of Replicant 9.

Later that day, Replicant is having a Birds of a Feather (BoF) meeting:

The meeting is open for everyone interested in the Replicant project (users, developers, devices vendors, etc.). Access is public and free as in beer.

Here’s a non-exhaustive list of the topics that will be up for debate:

  • Replicant 9 status on the i9300/i9305: bootloader, modem, LCD, audio, graphics.
  • Future targets: PinePhone, Librem5.
  • WebView dependency on non-free Chromium.
  • Android build system.
  • Replicant infrastructure: servers, test benches, build machines.
  • Long term project sustainability.
  • Supported mainline kernel phones, what kernel versions brought what support and what is upcomming in the next kernel versions.
  • How the endorsement of stores selling Replicant devices should work.
  • Wiki migration from Redmine to MediaWiki.
  • Upstream and maintainership of the code of Replicant 9 that enables to use an upstream kernel.
  • Relationship with LineageOS on supporting the Galaxy SIII.

If there’s any other topic you deem as relevant please let us know in the comment section, mailing list or IRC. Everyone’s point of view is welcomed.

On Sunday’s afternoon, there will be a talk at the Hardware Enablement devroom on the topic of “Extending the lifetime of smartphones with Replicant”:

Replicant @ 36C3

Starting on December 27th, the 36th Chaos Communication Congress (36C3) is taking place in Leipzig. Replicant will be there as part of the Critical Decentralization Cluster.

Replicant’s assembly will feature demos of the current Replicant 6 as well as the upcoming Replicant 9. It is the place to come by if you need some 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 key.

Location: L4, Exhibition Hall 2, Level 0
DECT: 6506

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

Graphics support for Replicant 9

Thanks to volunteer effort and NLnet funding we have had developers working hard the past couple weeks on making graphics work on the Samsung Galaxy S3 for the upcoming Replicant 9 release. Three different software renderers have been successfully used with the current Replicant 9 development version: softpipe (Mesa), llvmpipe (Mesa), and SwiftShader.

The Linux kernel and Mesa required some small tweaks to allow using the Exynos DRM driver for software rendering. For the Linux kernel we had to allow in the DRM subsystem the creation of dumb buffers for render nodes as discussed previously on LKML. The devfreq module was also disabled as a workaround for graphics corruption issue that happened due to too low clock speeds. Mesa on the other hand required us to whitelist Exynos DRM driver to be used with a software rendering driver called kms_swrast. After these tiny changes we were already able to use the Mesa’s software rendering backend called softpipe! Unfortunately, softpipe turned out to be unusably slow even after using HW overlay planes to offload some of the buffer compositions to the Exynos 4412 display controller found on the Samsung Galaxy S3.

Next the community members Putti, dllud and GrimKriegor worked on a new revision for a patch originally used in the Android-x86 project for enabling llvmpipe support in Mesa. When the compilation fixes and slight adjustments for the rebased original patch were done we had yet another software renderer to use. The new revision of the patch enabling llvmpipe is now submitted again to Mesa and hopefully this time around it will go through.

The rendering speed with llvmpipe turned out to be only slightly faster than softpipe and still unusable for everyday usage. There are plans optimize llvmpipe for the ARM Cortex-A9 processor in Exynos 4412 so hopefully soon it will be usable for everyday usage.

Before diving into the world of NEON optimization for llvmpipe and so forth, we decided to give SwiftShader software renderer a go together with hwcomposer.ranchu and gralloc.default. Other than having to add support for UDIV and SDIV instruction emulation in the Linux kernel, we got it running by simply setting some system properties and adding the SwiftShader and hwcomposer.ranchu modules to the system image. The speed of SwiftShader felt like it was at least twice as fast compared to llvmpipe and softpipe but still just a tiny bit too slow to be enjoyable for everyday usage. We are now hoping to find people that could work with us to replace hwcomposer.ranchu with drm_hwcomposer. Using drm_hwcomposer with SwiftShader would allow us to take advantage of HW overlay planes to speed up the compositions.

If you are interested in helping or want to learn more you can get in touch with us on IRC on the #replicant channel on Freenode, or via our mailing list.

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.

Meeting Point at FOSDEM

The Replicant Community Meeting will take place on Sunday, the 3rd of February at 11:00 AM in room J.1.106 at ULB, Brussels Belgium.
We have successfully booked a BoF room at FOSDEM, so we will have a quiet, heated and comfortable place where we can all sit together.

Access is public and free as in beer.
We encourage everyone to participate and contribute their opinion.
This meeting will be essential to the future arrangement of Replicant as a structured Project.

Any schedule update or other info can be tracked on the event’s dedicated page on FOSDEM’s website.
Replicant’s blog will also be updated accordingly.

IMPORTANT NOTICE: This announcement is about the community meeting. The time schedule for the workshop hasn’t been decided yet.
Interested people are encouraged to write to the mailing list to help organize it.
Also, the related poll is still open.


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.

Replicant meeting at FOSDEM 2019

Call for participants

Like every year, FOSDEM will take place the first weekend of february in Brussels, Belgium.

Replicant is organizing a community meeting and a workshop that will take place alongside FOSDEM events.
The main intention behind this is to gather Replicant enthusiasts and contributors together in order to share ideas and discuss Replicant-related key topics.
This is a call for the community to participate and propose arguments to discuss.
A wiki page has been prepared, to collect proposals and schedules.
Proposals and questions can be presented to the mailing list.

Examples topics that have been proposed are:

  • What directions should the project take, what work to prioritize
  • How to fix f-droid to keep Replicant FSDG compliant

Together with the following workshop arguments:

  • How to setup the build environment
  • Hands on libsamsung-ipc and samsung-ril
  • Answer various questions about contributing to Replicant
  • Help contributors who are stuck with specific issues


Two free-software-powered polls have been published, to help us chose the best day and time:

We invite whoever might be interested, to indicate their preferred schedule for the events, in order to help us set up a sensible timetable.

The official meeting point and timetables will be published on this blog and on the mailing list.

Stay tuned!

EDIT:
The meeting report is available: https://redmine.replicant.us/attachments/download/1597/formatted-report.pdf

Final days for the upstream Linux Allwinner VPU support crowdfunding campaign

A crowdfunding campaign was launched over a month ago by Bootlin in order to fund the development of an upstream Linux kernel driver for the Allwinner CedarX VPU. The VPU (Video Processing Unit) is in charge of offloading video decoding and encoding to a dedicated hardware block, relieving the main CPU. While Replicant does not support Allwinner devices at this point, the project has acquired a number of Allwinner tablets a few years ago, that helped with the advancements of Allwinner platforms support in upstream projects such as the U-Boot bootloader and the Linux kernel.

Recently, Replicant was a candidate for the Google Summer of Code program and we came up with a list of tasks for the occasion. Although our application was not accepted, we are still interested in completing the tasks that we picked up. We put a deliberate focus on supporting mobile devices in mainline U-Boot and Linux, with a particular emphasis on Allwinner devices, the Optimus Black and the Kindle Fire (first generation). We believe that supporting mobile devices and using standard driver interfaces in the upstream Linux kernel is the only sustainable way for freedom on mobile devices. Instead of writing device-specific code specifically for Android for each of the supported devices, this would allow using generic Hardware Abstraction layers (HALs), reducing the amount of work for hardware support on the Replicant side in the long run. This also allows running other operating systems that integrate the upstream Linux kernel interfaces, such as standard GNU/Linux distributions.

In spite of this, I have been dedicating more and more time to contributing to upstream projects such as coreboot, U-Boot and Linux for supporting devices of various form factors, including mobile devices, laptops and single-board computers. Thus, I became less and less active on the technical side for Replicant, where Wolfgang and others have picked-up the work. There is still a lot of room for contributions and everyone is warmly encouraged to join-in and help with the upstreaming effort for devices, especially regarding the Optimus Black, Kindle Fire (first generation) and Allwinner devices.

As a student approaching graduation, I have joined Bootlin (formerly Free Electrons) in Toulouse, France for an internship focused on supporting the Allwinner VPU in upstream Linux and userspace. It definitely fits perfectly with the logic behind focusing Replicant towards upstream Linux support. In order to accelerate the development of the driver, Bootlin has decided to start a crowdfunding campaign in order to fund Maxime Ripard, who has been working for the company and maintaining Allwinner platforms in the Linux kernel for a while.

As the main goal of the campaign was reached within its first week, Maxime will be able to work with me on the VPU. His in-depth understanding of the sun4i DRM video driver’s innards will also reveal very useful for accelerating the processing of the frames coming from the VPU (without unneeded copies of buffers) and implementing scaling in hardware. In order to support the VPU hardware efficiently, a number of changes have to be introduced to the Linux kernel. It currently lacks an interface to provide coherency between setting specific controls for the media stream and the input/output buffers that these controls are related to and should apply to. This API has been implemented by Alexandre Courbot (who’s working at Google on the Chromium OS project) as the V4L2 request API, that fits the requirements for the Allwinner VPU driver. Other VPU drivers, such as the tegra-vde driver that supports the Tegra 20 video decoder engine, also require this API in order to implement a proper V4L2 mem2mem driver.

The crowdfunding campaign still has 10 days to go and two stretch goals to meet (while the first stretch goal, about supporting newer Allwinner SoCs was already met):

  • H265 video decoding support
  • H264 encoding support

As I am not directly impacted by the funding received through the crowdfunding campaign, we believe that there is no direct conflict of interest writing this blog post on the Replicant blog.