Fighting human trafficking with self-contained applications
Brooke Deuson is the developer behind Trafficking Free Tomorrow, a nonprofit organization that produces free software to help law enforcement combat human trafficking. She is a survivor of human trafficking herself. She spoke at RustConf 2025 about her mission, and why she chose to write her anti-trafficking software in Rust. Interestingly, it has nothing to do with Rust's lifetime-analysis-based memory-safety — instead, her choice was motivated by the difficulty she faces getting police departments to actually use her software. The fact that Rust is statically linked and capable of cross compilation by default makes deploying Rust software in those environments easier.
She started by pointing out that no software is going to be able to
single-handedly put an end to human trafficking. Her goal for the programs
Trafficking Free Tomorrow makes is to "raise the cost of selling people
"
to make human trafficking not economically viable. She does this by building
tools for law enforcement, who are often already trying to stop human trafficking.
The problem is that trafficking is profitable, which means that the criminals
who engage in it often have well-funded defenses and expensive lawyers. If there
is any way for the defense to get evidence thrown out, they'll find it and do
so. Before something becomes evidence in a court of law, it starts out as
"stuff from a crime scene
". In order to be usable as
evidence, it needs to be tracked and signed-off-on at every step along the way,
in order to prove that it couldn't have been tampered with.
![Brooke Deuson [Brooke Deuson]](https://static.lwn.net/images/2025/brooke-deuson-rustconf-small.png)
Deuson described FolSum (the web site for which is offline at the time of writing, although Deuson is working on it), which is an MIT-licensed application that helps maintain this chain of custody for digital evidence. It records hashes of folders of digital evidence, and produces a report about what has and hasn't changed since the last run of the tool. This can be used to help prove the chain of custody in court.
This idea isn't recent; Deuson has been working on it for several years, ever
since she had
"a bad experience in college
". Surviving that experience
her "really angry
" and motivated her to start working with law
enforcement to try to ensure it couldn't happen again.
She initially wrote simple Python scripts to
help with chain-of-custody problems. Those scripts worked on her machine, but she had
trouble delivering the software to the people who actually need it.
The users Deuson targets are largely underfunded police departments that can't
afford expensive commercial forensic solutions. The people there are usually
non-technical and more used to working with paper forms for evidence tracking.
They need software that is simple, self-explanatory, and capable of running in a
highly locked-down enterprise environment. Deuson's first attempt at
distributing her software was to bundle it using Kubernetes. That sort of
worked, but it turned out to be hard to get it installed in police departments.
Opening ports in the firewall is also often prohibitively hard.
"Getting software into these environments is really difficult.
"
Eventually, she decided that the only way to make this work would be to write a single, standalone executable that does everything locally. It would need to be able to run on ancient desktop computers, in a variety of environments, without external dependencies. That's why she ultimately chose Rust to write FolSum.
Rust is probably most famous for its approach to memory safety, but she said that those weren't actually too relevant to her choice. It is important that Rust is a memory-safe language, though. Not because of the reliability of the software, but because it lets her point at things like the Biden administration's report on modern computer security or CISA's recommendations for secure software in order to justify her choice to non-technical lawyers. Being able to point at an official report that says a certain language is an approved way producing secure software is actually quite helpful for getting FolSum adopted.
The main reason she chose Rust, though, was developer ergonomics. "I'm just
one person
", she explained. Nobody else is currently working at Trafficking
Free Tomorrow. So if she wants to produce this software, it needs to be in a
language that makes it easy to meet her requirements for producing
self-contained applications.
Ultimately, she's happy that she chose to experiment with Rust. Writing a local application instead of a server-based one let her keep things simple. One thing that users really liked about the Rust version of the application was that it starts quickly, she said. Lots of commercial software is big and bulky, and takes a while to start up, leaving users staring at splash screens. FolSum starts up almost as soon as the user releases the mouse button. That's important, because it builds user trust in the reliability of the application from the beginning, she said.
One of Rust's features is "fearless concurrency" — standard library APIs that
make it impossible to construct data races in safe Rust code. When Deuson
started writing FolSum, she didn't know anything about that. "Starting off, I
didn't really know anything about concurrency. I didn't have formal training.
"
So the first version of the program appeased Rust's concurrency model by using a
single big mutex wrapped around a shared hash map.
That did work, but it led to a lot of difficult-to-debug deadlocks, "which
sucks
". Ultimately, she ended up rewriting the implementation to use
channels, which results in fewer deadlocks. Notably, FolSum doesn't use any
asynchronous code yet — it's all done with synchronous I/O, and the GUI actually
runs in the same thread as the checksumming work.
The GUI is written using
egui, which is an immediate-mode GUI framework, meaning
that the interface is completely redrawn on every frame. Deuson called the
approach "slightly cursed, but easy to reason about
". The interface is
basic, with no frills or animations — it's just a single window with some text
and four buttons.
Deuson wrote it that way as a simple prototype, just to get something working.
"I didn't think that UI would be nice, but the users actually really liked
it.
" Now, she doesn't plan to change the interface. It turns out that
non-technical users like the approach that she has called "GUI as
docs
", where the application puts the explanation of what it does right next
to the individual buttons that do those things. Several users have told her that
they wished other software was written like this, to her bafflement. For-profit
software is often a forest of features, which makes it hard to find the specific
thing one needs, especially if the tool is only rarely used, she said.
Some Rust features that she did really appreciate were the integrated unit tests and benchmarking libraries. They let her focus on what she felt was important, rather than spending time on boilerplate. On the other hand, she felt that people should probably avoid advanced language features and extra dependencies. She's written FolSum with basic for loops and plain imperative code, and it works well for her.
In the future, she would like to add a few carefully chosen new features to FolSum, including a progress bar and code to avoid overwhelming cheap network-attached storage. She also wants to add a crash reporter that gives users a report that they can send to her when something goes wrong. Ultimately, FolSum is a pretty small piece of software. Building it helped her iron out the web-site, continuous-integration, software-packaging, and distribution problems; now that she knows what works, future software from Trafficking Free Tomorrow is on a much firmer foundation.
There was only time for a few questions at the end of the session; one person asked how she had dealt with the social problems of getting police departments to adopt her software. Deuson explained that when talking to stakeholders, she mostly didn't try to convince them of anything technical — instead, she tries to think about who their bosses are, and who assumes the risk from choosing to use FolSum. That's where resources like the White House recommendations are really useful to convince users that it is actually a reasonable way to do things.
I asked what other anti-human-trafficking software she wanted to write in the
future. Deuson responded that she had planned on "tons of stuff
"
including dedicated
perceptual hashes for images, tools for working with
recursively zipped files, a way to organize timelines of conversations, and
open-source intelligence tools.
The goal Deuson has set for herself, of making human trafficking economically
unfeasible, is important but daunting; hopefully, her strategy of producing small,
dependable tools for the most under-resourced law-enforcement agencies will help
achieve it.
Index entries for this article | |
---|---|
Conference | RustConf/2025 |
Posted Sep 15, 2025 20:41 UTC (Mon)
by shironeko (subscriber, #159952)
[Link]
Posted Sep 15, 2025 21:42 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (10 responses)
This is so typical. In theory, the mythical "invisible hand of the market" provides choice and let users pick what they prefer. In reality, oligopolies and vendor lockdowns leave no room for alternatives or experimentations and they only come from unexpected people and places.
Not just with computers.
Posted Sep 16, 2025 7:58 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
Turns out letting users pick what they prefer is very low on the list of things people think will make money (perception counts more than measurements, no human actor is perfectly objective, culture weights more than hard facts). Cornering markets, stuffing your product with useless nice to have features, shortening its life, adding money-earning trackware, lobbying (corrupting) market institutions (ie cheating) are all perceived to have a better effort to profits ratio.
Posted Sep 16, 2025 17:12 UTC (Tue)
by alfille (subscriber, #1631)
[Link] (6 responses)
But the discussion about UI complexity is interesting. I think the push complexity is more fundamental than corporate greed. It's human nature -- easy of use and learning vs customization, options and, frankly, personal greed. We think we want it all.
Not just commercial software, open source tools are often extremely complex too. Look at open source text editors or the command line switches for wget, sed or awk. People use only subset of features, but not always the same subset. And if you are going to invest the time to use a tool, why not the most powerful one. For the developers, adding features is a balance -- enjoying the challenge, pleasing your users, vs simplicity and maintainability. Also it's hard as an expert to see how a new user sees the interface.
Actually the same is true for physical devices -- washing machines, cars, etc. It's hard to invest in something that doesn't have more features, just in case.
Posted Sep 17, 2025 13:34 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
Posted Sep 17, 2025 13:55 UTC (Wed)
by pizza (subscriber, #46)
[Link] (4 responses)
A considerable amount of that "overweight and overfeatured" is driven by government regulation.
For example, any passenger vehicle sold today has to have a pretty long list of safety [1] and emissions/efficiency [2] features that considerably drive up the minimum production cost of any vehicle. (And that's before manufacturers try to game the metrics..)
Additionally, thanks to the joys of competition folks expect an ever-greater degree of baseline sophistication and functionality, and there is an ever-wider gap between what-they-say-they-want vs what-they-actually-purchase.
[1] Half a dozen or so airbags, lane departure detection, adaptive cruise control, forward collision warnings and automatic braking, stability control, camera systems (which effectively mandates having a infotainment screen), etc. Granted some of these aren't required _now_ but will have to be present within the next few years.
Posted Sep 17, 2025 14:39 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (3 responses)
I damn well hope not. The driver is legally obliged to be in full control of the vehicle at all times. How on earth is he supposed to do that if his car accelerates unexpectedly without any driver input whatsoever? And he has no way to over-ride other than to turn the whole damn thing off?
Or equally the car brakes unexpectedly on a motorway without any driver input whatsoever?
(Both usually caused because the car has an internal database and also reads external signs. Throw roadworks into the mix and I've had the car run the pretty much the entire gamut of every legal value between 20mph and 70mph in the distance of maybe 100 yards ... talk about getting confused. Oh, and this is in an area where the City Speed Limit is 50mph.)
My car does both. Fortunately, it's usually on familiar roads and I'm expecting it, but adaptive cruise control is a complete liability. My wife hated the basic cruise control on our previous car. I sure as hell hope she never accidentally activates it on my new car because she'll just lose control ...
Classic feature creep where nobody actually does a risk assessment on each individual creep until we have a major accident ...
Cheers,
Posted Sep 17, 2025 14:44 UTC (Wed)
by jzb (editor, #7867)
[Link]
Posted Sep 17, 2025 14:54 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
You reveal a fundamental misunderstanding of what "adaptive cruise control" actually refers to:
https://mycardoeswhat.org/deeper-learning/adaptive-cruise...
> Classic feature creep where nobody actually does a risk assessment on each individual creep until we have a major accident ...
On the contrary, the regulatory bodies have done _exhaustive_ assessments (including multiple rounds of public comments) to establish the operational requirements for these systems, and after being widely deployed for the better part of a decade data unequivocably shows them to be objectively safer (ie lower accident rate per distance driven).
...I'll leave it at that.
Posted Sep 17, 2025 18:31 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
But unfortunately, my car provides no way to have one without the other :-(
Cheers,
Posted Sep 18, 2025 16:38 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
I agree but just to be clear, the (naive?) "invisible hand" theory does not. That theory says customer pressure is stronger and forces producers _not_ to do all the things you listed. In reality, it's as you wrote just one pressure among others that works sometimes and not that much. Yet it's revered like a religion by some people[*], probably because we love simple answers to complex problems.
FWIW, international trade stopped being entirely based on that theory.
Posted Sep 16, 2025 15:27 UTC (Tue)
by notriddle (subscriber, #130608)
[Link]
The HCI/UX problems, however, seem like a more fundamental tension, not a market failure. Consider the description that the article gave the interface:
> it's just a single window with some text and four buttons.
I've worked on software in a similar situation, where I got feedback from non-technical users and they really liked it because of how self-explanatory it was and how frustrated they were with all the competitors and their complex, clunky interfaces. At least, that's how it was for our first customer.
Then we tried to onboard customer #2, and they liked what they saw, but absolutely needed a feature we didn't already have, and, more importantly, they needed to enforce that their employees were actually using it, so we needed to add a check. Customer #1 could not accept this, so the whole feature needed to be configurable.
Ten customers later, and you wind up in one of two places:
1. Hell of combinatorics: your program is 50% conditional on its settings, and your test suite is either woefully incomplete or enormous. LWN has an article on configuring Linux kernel builds that illustrates this problem.
2. An aggressively limited scope that leaves the product as a compromise that leaves everyone equally annoyed.
Posted Sep 16, 2025 13:53 UTC (Tue)
by karath (subscriber, #19025)
[Link]
Posted Sep 19, 2025 9:45 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link]
prior art
Groupthink
Groupthink
Groupthink
Groupthink
Groupthink
[2] More stringent requirements require more advanced (and expensive, and less reliable) designs.
Groupthink
Wol
End here, please
Groupthink
Groupthink
Wol
Groupthink
> Turns out letting users pick what they prefer is very low on the list of things people think will make money
Mass-market HCI is hard, actually
Thank-you for covering important topics like this
Cryptocurrency and Human Trafficking