fidzu : debian

Half way through the day:

A morning of technical talks:

Vock - Instrumenting, kernel coverage and process tracing

Rebuilding the archive on your desktop

An overview of Secure Boot

An excellent lunch - with thanks to Liv and her Arm catering staff

Three lightning talks - two without slides :)

Excellent day so far :)

07 Nov 2026 2:18pm GMT

There is a new project coming to Open Source Software land these days: OpenAGPS. It is not yet 100% functional, but we are working on it. It is not fully operational, yet, but we are on it.

Let me introduce OpenAGPS to you...

The Situation Today

The domain of assisted geo location services has been left to a few big tech providers. When using GPS on mobile devices, most of us send info on our approximate device location (based on cell tower IDs seen by our devices around us) mostly to Google's SUPL service in order to facilitate a faster GNSS/GPS lock on the satellites flying above us.

Without assistance, retrieving a GNSS/GPS lock on sufficient satellites includes "finding" those satellites and once found retrieving data (in bytes/sec) from them. In some regions, this leads to waiting periods of up to 45 minutes, before a mobile devices has gained a lock on sufficient satellites (3 or more).

In Assisted-GNSS/GPS, "other" information (such as cell tower IDs) gets used to estimate what GNSS/GPS satellites are currently passing over one's location. With AGPS, the mobile devices retrieve information via a so-called SUPL server, containing two details: a list of potential satellites above and their dataframes. Esp. providing those dataframes over the device's internet connection (and not via the GNSS/GPS receiver downloading it from the satellite itself) speeds up the lock-on process of the mobile tremendously (several seconds to a few minutes).

However, for this mechanism to work, your device will share your IMSI (although not needed for AGPS), a list of cell towers around you and their signal strengths with the provider of the SUPL service, revealing your approximate position. In total, this allows SUPL providers to re-identify each mobile device and create motion profiles of each such device (and its owner). If the SUPL service is hosted by one main provider (i.e. Google SUPL), there is a lot of valuable information available to them for free that they can commercialize.

Currently, there is only one mitigation method available to hide one's location info from the SUPL server(s) at e.g. Google: using a SUPL proxy server implementation (available as OSS, provided by and used in e.g. GrapheneOS). A SUPL proxy still depends on the big tech service provider(s) for SUPL as it merely proxies SUPL requests from mobile devices through to the proprietary SUPL services, at e.g. Google, but the mobile device is being camouflaged behind the SUPL proxy in use.

The OpenAGPS Teaser

OpenAGPS, on the contrary, will be a fully independent implementation from proprietary service providers, and it will refrain from collecting and commercializing end users' data. It will be driven by individuals of the OpenAGPS community. There will likely be one central service that the OpenAGPS project plans to host and operate (the Porygon frontend/backend, OpenAGPS's GNSS Almanach service), but except from that SUPL servers can be self-hosted by individuals, companys or other communities. The requesting mobile devices' IDs will be hidden from the Porygon server (like with existing SUPL proxy implementations), so that the only centrally operated component (the Porygon Almanach server) does not know who is requesting what geo position information (and thus cannot collect such data, neither derive info about where requesting devices are located).

In addition, with a large OpenAGPS community, it is imaginable (in theory) that there will also be multiple central Almanach servers available on the internet (with parallel networks of base stations attached to each GNSS Almanach server).

Checkout the OpenAGPS architecture schematics and our website/documentation to learn more.

Collecting Satellite Data

The OpenAGPS project is not simply a software that admins/users can install, it needs kind of a huge and global community to operate/host/house its base station network.

The challenge with providing a community-driven AGPS service on the internet is that up-to-date (real-time!) GNSS/GPS satellite position data is not available for free download. Almanach data can be obtained per region from various organisations, but then their datasets are often days to weeks old, thus too outdated. GNSS/GPS satellites are not geo-stationary, they circulate around the planet. Their position is dependent on the current date-time. A globally spanning network of GNSS/GPS base stations will do the trick here. We will need a community that harvests the needed satellite data in real time and makes it available through the Porygon Almanach server to all OpenAGPS users.

The OpenAGPS project will depend on at least one community member every ~40-50 km² to operate a so-called OpenAGPS base station: These base stations are stationary, need to run 24/7, and they will harvest GNSS/GPS statellite data information from the satellites above in real-time and share this data with the (central) Porygon server, continuously. The Porygon server will create a timestamp-dependent "map" of all seen satellites and extrapolate locations between base stations' Almanach data updates.

Help making OpenAGPS a Success: Host a Base Station

To make OpenAGPS a success, we need volunteers who are willing to host (actually: house) an OpenAGPS base station at their home or work place (or both). Users will only be able to use their self-hosted OpenAGPS SUPL server with their mobile devices (instead of e.g. Google SUPL), if we manage to establish sufficient coverage with those base stations in the area of interest, so that the OpenAGPS Almanach will get populated with sufficient satellite position data.

If you'd like to host/house such a base station, please get in touch and check the docs.

Support this project by Co-Funding it

If you realize that you have an interest in this project and would like to improve your level of digital sovereignty in your government, organization, at your home, etc. then consider sending financial support to the project. If you want to support us, please get in touch with Raoul Kramer at BetaBreak or Mike Gabriel at Fre(i)e Software GmbH. If you are a software developer and would like to contribute to OpenAGPS, also get in touch and let us meet at FOSDEM 2027.

Credits

A huge thanks to the NLnet Foundation for funding this project's bootstrap phase. Follow-up funding has been applied for, so please keep fingers crossed!

07 Nov 2026 9:23am GMT

Recently, I've been noticing something on packaging around my house that I used to glance right past: raised Braille dots on a carton of medicine, and embossed markings on a container of body cream. I've always known what Braille looked like, but I never paid close attention to it. Now that I'm actively working on accessibility testing for the Debian Installer, I see it everywhere.

It made me reflect on how accessibility usually enters our consciousness. In tech, we're taught about accessibility as a best practice when designing user interfaces or web apps. But realistically, you mostly see it implemented well in massive global software, like mobile operating systems or browsers like Firefox. You rarely see accessibility features integrated into local Nigerian physical products or everyday tech. Paying attention to these details made me realize how much care goes into making sure every person is considered, and how vital that mindset really is.

Manual Testing & The openQA Bottleneck

My recent work with Debian has been focused on automating tests for the Debian Installer's accessibility features, specifically validating Braille display emulation.

I started out by manually testing following the official steps on the Debian Installer Accessibility Wiki. Once I understood the manual flow, the next goal was figuring out how to automate it inside openQA.

Initially, the idea was to initialize from the bootloader by adding parameters to the Grub (GRUB="brltty=auto")and it should start the installation with the braille visual. However, this didn't work, the parameters never initiated the brttyl and it was a huge blocker going back and forth. Getting brltty to talk to the test runner in that environment would have required sweeping changes across the main Debian openQA instance configuration.

Instead of pushing for complex system-wide changes on the instance, we started looking for easier alternative approaches and noted the complicated ones, when we advance in the test.

We brainstormed streaming the display output directly to a dedicated file to capture and verify the Braille virtual display output. Ultimately, nested virtualization proved to be the most easiest path forward.

Joining the Conversation

As part of this work, I joined the debian-accessibility mailing list to introduce what we were building and share our progress.

The responses were encouraging. I got some feedback and suggestions and the thread also created a discussion on how accessible the installation process currently feels for blind or visually impaired users, and where they also find issues. It served as a great reminder that test suites aren't just about passing CI checks, they're about serving actual people who rely on these systems every day.

06 Nov 2026 8:25pm GMT