Seven Diabetes Patients Die Due to Undisclosed Bug in Abbott's Continuous Glucose Monitors

by Bradley M. Kühn on December 23, 2025

I wrote last month about my diabetes diagnosis this year and my difficult choice to wear a proprietary device (called a CGM) on my arm 24/7 to continuously monitor my glucose levels. Like my friend and colleague, Karen M. Sandler — who previously made a much higher-stakes choice to receive a proprietary implanted defibrillator to keep her safe given her genetic heart condition — I reluctantly chose to attach proprietary hardware and software to my body.

The device itself is quite proprietary, but fortunately the FOSS community has reverse engineered its activation and data collection protocols — creating an Android application that does a better job than the manufacturers' proprietary ones⁰.

Here in the USA, we strangely use capitalism as the center of our health care system. Two major for-profit competing brands of CGM are available here. My diabetes specialist prefers the (ironically named) Freestyle Libre Plus from Abbott. I (also rather strangely) bring a prescription for electronics to a pharmacy every month. On 2025-12-03, that pharmacy sent me an alarming text message (shown here).

Abbott Killed Seven Patients

After reading that text, I found the USA FDA announcement. My spouse cross-referenced the lot numbers while I read them off from all my Freestyle boxes¹. I had indeed recently worn an impacted device!

Only because my diabetes is so early of a stage was I relatively safe. The FDA reports that Freestyle injured over 700 people and killed seven people with this bug. Specifically, the bug caused the device to falsely report an extremely low glucose level. Advanced stage diabetics use low reading information to inform them that they may have too much insulin currently. The usual remedy is to eat something sugary to raise glucose in the blood. Such should be done only with great care, as a false low reading can harm and even kill the patient (who eats a high-sugar-content item while glucose in the blood is, in fact, not low).

Proprietary software in medical devices harming patients is not new. In 1985, the Therac-25 killed three people. In 2020, hundreds of patients who relied on a financially troubled tech startup found their occular implants suddenly unsupported. Some patients went blind as the devices powered down without updates. There are more examples that I could include here, but rereading these horrific stories is frankly more than I can take right now when I think of fellow diabetes sufferers who were “killed by code” recently..

Would FOSS Have Saved Patients' Lives?

It's hubris for activists to guarantee that harm would be prevented if Freestyle had publicly released the hardware specifications and the complete, corresponding source code (CCS). FOSS isn't immune to bugs — even dangerous ones. However, in the centuries since the Enlightenment, we know that the scientific method depends on public disclosure about data and wide-reaching peer review of past work. FOSS (plus a publicly disclosed hardware design) wouid allow the millions of hardware and software engineers to peer-review the integrity, security, and safety of the devices to which patients entrust their lives. We achieve the promise of humanity when we each entrust our safety and health to our entire community — not merely a single for-profit entity.

We also will probably never know whether this issue was in hardware or software. The bug disclosure is incredibly vague, and it remains unclear how much investigation was done (if any) by government regulators into this problem. As a public policy and public health matter, the public deserves to know the technical details (software and hardware) of both the functioning device and the failed devices. NGOs should be permitted to perform their own investigations and confirmations of public safety.

What's Next?

Given that the hardware, software, and medical for-profit industries refuse to put the rights, safety and security of patients first, wrongful death lawsuits are typically the only way to hold these companies accountable. Yet, there are very few people who have not agreed Abbott's toxic terms of their proprietary companion application — I guestimate that fewer than 1% of Freestyle-using patients have used Juggluco from their very start (and thus never agreed to Abbott's terms). This is significant because Abbott includes a comprehensive one-way indemnity for themselves in the terms. I hope that a class action suit begins soon on this matter, but I wonder and worry that so much of the class may have signed this indemnity (which may make the road to justice bumpier).

Finally, I want to offer that if there is anyone out there who does tear-downs of extremely tiny electronic devices, I would be thrilled to find a volunteer who would like to see if we can either extract any software components from the device, or reverse-engineer the hardware. I have saved and sanitized all of my prior CGMs. I'd gladly send one along to anyone who wants to give a try at taking them apart. (Contact SFC or contact me on the Fediverse (via Mastodon) if you're available to do this work.)

For my part, I look forward (after the Vizio trial) to sending some patches to Juggluco and also getting Juggluco available in F-Droid. Our best option in the face of these powerful medical device companies curtailing our rights is to invest our volunteer time into the edges where FOSS has resiliently worked around the constant roadblocks erected by bad actors.

⁰My prior post about CGMs discussed the GPLv3'd Juggluco in more detail.

¹ In a fascinating turn of events, at least one of my past monitors (of which I fortitously saved all the boxes with the lot/serial number on them) is listed in the FDA's spreadsheet as recalled lot, yet the serial number is listed as “ safe to use” on Abbott's webform 🤔 … I'm left wondering how I can trust Abbott to write reliable software stuck into my arm if they can't even write a web form that cross-references serial numbers to lots correctly 😬.

[permalink]

Managing Diabetes in Software Freedom

by Bradley M. Kühn on November 6, 2025

Our member project representatives and others who collaborate with SFC on projects know that I've been on part-time medical leave this year. As I recently announced publicly on the Fediverse, I was diagnosed in March 2025 with early-stage Type 2 Diabetes. I had no idea that that the diagnosis would become a software freedom and users' rights endeavor.

After the diagnosis, my doctor suggested immediately that I see the diabetes nurse-practitioner specialist in their practice. It took some time get an appointment with him, so I saw him first in mid-April 2025.

I walked into the office, sat down, and within minutes the specialist asked me to “take out your phone and install the Freestyle Libre app from Abbott”. This is the first (but, will probably not be the only) time a medical practitioner asked me to install proprietary software as the first step of treatment.

The specialist told me that in his experience, even early-stage diabetics like me should use a Continuous Glucose Monitor (CGM). CGM's are an amazing (relatively) recent invention that allows diabetics to sample their blood sugar level constantly. As we software developers and engineers know: great things happen when your diagnostic readout is as low latency as possible. CGMs lower the latency of readouts from 3–4 times a day to every five minutes. For example, diabetics can see what foods are most likely to cause blood sugar spikes for them personally. CGMs put patients on a path to manage this chronic condition well.

But, the devices themselves, and the (default) apps that control them are hopelessly proprietary. Fortunately, this was (obviously) not my first time explaining FOSS from first principles. So, I read through the license and terms and conditions of the ironically named “Freestyle Libre” app, and pointed out to the specialist how patient-unfriendly the terms were. For example, Abbott (the manufacturer of my CGM) reserves the right to collect your data (anonymously of course, to “improve the product”). They also require patients to agree that if they take any action to reverse engineer, modify, or otherwise do the normal things our community does with software, the patient must agree that such actions “constitute immediate, irreparable harm to Abbott, its affiliates, and/or its licensors”. I briefly explained to the specialist that I could not possibly agree. I began in real-time (still sitting with the specialist) a search for a FOSS solution.

As I was searching, the specialist said: “Oh, I don't use any of it myself, but I think I've heard of this ‘open source’ thing — there is a program called xDrip+ that is for insulin-dependent diabetics that I've heard of and some patients report it is quite good”.

While I'm (luckily) very far from insulin-dependency, I eventually found the FOSS Android app called Juggluco (a portmanteau for “Juggle glucose”). I asked the specialist to give me the prescription and I'd try Juggluco to see if it would work.

CGM (3.75cm Ø)

CGM's are very small and their firmware is (by obvious necessity) quite simple. As such, their interfaces are standard. CGM's are activated with Near Field Communication (NFC) — available on even quite old Android devices. The Android device sends a simple integer identifier via NFC that activates the CGM. Once activated — and through the 15-day life of the device — the device responds via Bluetooth with the patient's current glucose reading to any device presenting that integer.

Fortunately, I quickly discovered that the FOSS community was already “on this”. The NFC activation worked just fine, even on the recently updated “Freestyle Libre 3+”. After the sixty minute calibration period, I had a continuous readout in Juggluco.

Juggluco — 21-hour period

CGM's lower latency feedback enables diabetics to have more control of their illness management. one example among many: the patient can see (in real time) what foods most often cause blood sugar spikes for them personally. Diabetes hits everyone differently; data allows everyone to manage their own chronic condition better.

Juggluco — long period

My personal story with Juggluco will continue — as I hope (although not until after FOSDEM 2026 😆) to become an upstream contributor to Juggluco. Most importantly, I hope to help the app appear in F-Droid. (I must currently side-load or use Aurora Store to make it work on LineageOS.)

Fitting with the history that many projects that interact with proprietary technology must so often live through, Juggluco has faced surreptitious removal from Google's Play Store. Abbott even accused Juggluco of using their proprietary libraries and encryption methods, but the so-called “encryption method” is literally sending an single integer as part of NFC activation.

Juggluco's summary stastics

While Abbott backed off, this is another example of why the movement of patients taking control of the technology remains essential. FOSS fits perfectly with this goal. Software freedom gives control of technology to those who actually rely on it — rather than for-profit medical equipment manufacturers.

Juggluco's average graph

When I returned to my specialist for a follow-up, we reviewed the data and graphs that I produced with Juggluco. I, of course, have never installed, used, or even agreed to Abbott's licenses and terms, so I have never seen what the Abbott app does. I was thus surprised when I showed my specialist Juggluco's summary graphs. He excitedly told me “this is much better reporting than the Abbott app gives you!”. We all know that sometimes proprietary software has better and more features than the FOSS equivalent, so it's a particularly great success when our community efforts outdoes a wealthy 200 billion-dollar megacorp on software features!

Please do watch SFC's site in 2026 for more posts about my ongoing work with Juggluco, and please give generously as an SFC Sustainer to help this and our other work continue in 2026!

[permalink]

Join SFC for a Q&A on how to keep your sideloading, and other phone freedom tips

by Denver Gingerich on September 3, 2025

You may have heard that Google will be limiting sideloading in the next few months, which is likely to be enforced through Google Play Services, something that runs on virtually all Android phones. Google plans include blocking sideloading of apps where the developer has not shown their ID to Google. Many people have been asking us how they can support app developers who will not or cannot be involved in a Google-run identity verification program.

In particular, we've been increasingly hearing that Android users want to remove their dependence on Google, for this and many other reasons, including the tracking and surveillance that come with using Google Play Services and other Google apps. As a result, we will be hosting a Q&A session this week, in conjunction with folks from F-Droid, to discuss how to best remove proprietary Google code from your phone, and ensure that you control how your phone operates, and which apps can run on it (and from whom).

"Phone freedom tips, and related Q&A" video chat details:

• Friday, Sep 5 (2025), at 15:00 UTC (08:00 US/Pacific, 11:00 US/Eastern, 17:00 CEST)
• https://bbb.sfconservancy.org/b/den-i3x-a5u-vkq

We will cover the basics of which Google apps and other code you might be using, which of that you can remove while maintaining the use cases you have for your phone, and how to adapt use cases to potentially further reduce reliance on other non-free tools that prevent you from using your phone as you wish.

Among other options, we'll talk about how to use LineageOS on your phone, or another phone you might have already, what you can expect from alternate OSes in general, and how you can keep doing what you need, while giving yourself more control over what you can do in the future. Alongside participants from F-Droid, we will also discuss the F-Droid project, which hosts free apps that provide alternatives for non-free apps from Google Play, as well as classifying apps by how your data is handled, so you can maintain as much say over your privacy and freedom as possible.

We're excited to chat about how to improve your phone experience through the tools and expertise that software right to repair enthusiasts have created to ensure your phone and what you do on it is truly in your own hands!

[permalink]

Tags: conservancy, events, resources

Everyone is asking the wrong questions about TikTok

by Bradley M. Kühn and Karen M. Sandler on January 18, 2025

As we write this, everyone is wondering what will happen with TikTok in the next 48 hours. Social media as a phenomenon was designed to manufacture drama to sell advertising, and in this moment, the meta-drama is bigger than the in-App drama.

The danger of pervasive software is clear: powerful entities — be they governments or for-profit corporations — should not control the online narrative and remain unregulated in their use of personal data generated by these systems. However, the approach taken by Congress and upheld by SCOTUS remains fundamentally flawed. When there is power imbalance between a software systems' users and its owners, the answer is never “pick a different owner”.

Whoever owns ByteDance, the fundamental problem remains the same: users never really know what data is collected about them, and they don't know how the software manipulates that data when deciding what they are shown next. The problem can only be solved if users can learn, verify, and understand how that software works.

TikTok is a software system — implemented in two parts: somewhere, there is a server (or, likely, a group of servers), running the software that gathers and aggregates posts, and then there is the client software — the App — installed on users' devices. In both cases, ByteDance likely owns and controls both pieces of technology and is the only entity with access to the “source code” — the human readable software that can be studied and understood by human beings. When users download the TikTok App, they don't get that source code for the App, and certainly get no information about the software running on the servers.

If the USA operations of TikTok are sold to another entity, quite likely the software itself will remain in control of ByteDance. While the wording in the Act is expansive about the required divestment, it's likely the new USA owners wouldn't themselves receive the right to review or modify the source code — they could just receive a binary (non-source form) of that software. In that case, no one in the USA will have permission to review and verify that software behaves in a way that is in the interest of its USA users. The Act is vague on these details. Will complete, corresponding source code ultimately be considered part of “a qualified divestiture”? The Act simply leaves "an interagency process", with no guidance (to our knowledge) on the issue of server or App source code. (We have seen similar failures where government agencies with a duty to examine software found in medical devices do not actually even have access to the source code.)

The root problem is that the act doesn't require an action that would truly resolve the biggest threat to TikTok users in the USA. Users (and our government) should instead insist that, to operate in the USA, that ByteDance respect the software rights and freedoms of their users by releasing both the server and App components of the software under a “free and open source” (FOSS) license. FOSS respects the software rights of all by allowing everyone to review, modify, improve, and reinstall their own versions of the software. By technical necessity, this means that everyone could understand the communication protocol between the App and the servers. Users (or third-party App makers) could, for example, modify the App to no longer send users down the rabbit hole of toxic recommended posts, or refuse to transmit user usage data back to the servers in China. FOSS is the best method we have to democratize technology and its algorithms.

Industry will, of course, ask how could a new company, build around a purely FOSS platform, ever generate the revenue necessary to run the network of servers and implement needed improvements to the App? The answer to that is, in fact, part of the beauty to this solution. The primary reasons that sites like TikTok are so toxic is inherent in their business model: privacy-unfriendly data gathering to sell targeted advertising. Indeed, these issues are raised as serious concerns by individuals from all over the political spectrum and they are the primary reason the initial bill passed the House so easily. If we demanded a FOSS and transparent business model, TikTok would have little choice but to move to subscription-based revenue instead of advertising.

As we continue on the dystopian path where most of our technological solutions are funded primarily by advertising and massive, privacy-invading data collection, we must decide if the price that we pay for this technology is just too high. From our perspective, $14.99/month (plus full transparency and software rights) looks a lot better than $0 (plus no privacy and a daily dose of advertisements and occasional CCP propaganda). As the saying goes, if you don't pay for the product, you are the product.

Furthermore, a mandated FOSS release more directly exposes the true problem that the mandated sale tried to solve. We are not politically naïve; we know ByteDance would resist releasing TikTok (server and App) as FOSS just as much as they resisted the mandated sale. But the real problem we have is that we simply don't know if the Chinese government has undue influence over TikTok or not. We have that problem primarily because we cannot examine their opaque technology. Transparent technology leads the only way to the truth in our software-controlled world.

[permalink]