利用自包含应用程序打击人口贩卖
Fighting human trafficking with self-contained applications

原始链接: https://lwn.net/SubscriberLink/1036916/2b10f1356b7ab0e7/

## 为了一个关键的事业:无人口贩运的明天 布鲁克·迪森,一位人口贩运幸存者,创立了“无人口贩运的明天”——一个利用软件帮助执法部门打击人口贩运的非营利组织,其目标是“提高贩卖人口的成本”。她在RustConf 2025上发表演讲,解释了他们选择Rust用于关键应用FolSum的原因——一个用于维护数字证据可验证的保管链的工具。 令人惊讶的是,Rust的内存安全性并非首要驱动因素。迪森面临的最大挑战是*部署*到资金不足且技术有限的警察部门。Rust能够静态链接并交叉编译成单个、独立的、可在较旧系统上运行的可执行文件,而无需复杂的安装,这一点至关重要。 FolSum的简单性——使用egui构建的基本GUI——是故意为非技术用户设计的,并在界面内直接镜像文档。迪森强调Rust的开发者体验、集成的测试/基准测试,以及引用安全建议(例如来自拜登政府的建议)的能力是关键优势。虽然最初在并发方面遇到困难,但她最终发现Rust的功能有助于构建一个可靠且值得信赖的工具。FolSum的成功为未来旨在破坏人口贩运经济可行性的工具奠定了基础。

与人口贩卖作斗争,使用自包含应用程序 (lwn.net) 5 分,由 chmaynard 1小时前发布 | 隐藏 | 过去 | 收藏 | 1 条评论 mx7zysuj4xew 7分钟前 [–] 嗯哼,这就像为了阻止达尔富尔的种族灭绝而提供游泳课程一样。 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文
By Daroc Alden
September 15, 2025
RustConf

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]

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."

The staff here at LWN.net really appreciate the subscribers who make our work possible. Is there a chance we could interest you in becoming one of them?

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.





联系我们 contact @ memedata.com