12 Nov 2026

feedPlanet Mozilla

Firefox Tooling Announcements: Nov 12th Deploy

The latest version of PerfCompare is now live!

:police_car_light: New view alert! :police_car_light:

The cross-platform view in PerfCompare!

How it started: Matthew Gaudet sought to answer one question that keeps coming up for engineers looking at a performance change: "Do these improvements or regressions agree across platforms?" Until now, answering that meant opening each platform's results one at a time and comparing them by hand. He saw that gap and filed Bug 2069050 asking for an official cross platform view in PerfCompare.

What we have now and how it works: The new cross-platform subtests view is live now! It shows each subtest as a row and each platform as a column. An Agreement column sums up the result at a glance, like "3/3 improved", "2/3 regressed" or "Mixed". Regressions are sorted to the top by default, and you can sort and filter by agreement. You can also click any cell to go to that platform's detailed results. You get there from the new "Compare across platforms" link in a test's header, which appears whenever two or more platforms have subtest data.

Please feel free to leave feedback or file bugs through the links below.

Screenshot 2026-11-12 at 11.23.26
Screenshot 2026-11-12 at 11.22.45

Check out the change-log below to see the updates:

Highlights:

[kala-moz]:

[moijes]: Bug-2003889: Show Lando try-push status instead of a blank-revision error

Other changes:

[kala-moz]:

Thank you for the contributions!

Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Matrix. Come and chat!

1 post - 1 participant

Read full topic

12 Nov 2026 7:28pm GMT

The Mozilla Blog: An open letter to every family’s designated IT support

Almost every family has one. They're the only ones who know which remote turns on the TV and which controls the volume and channels. They know what an HDMI cable actually does and where to plug it in. They've even fixed multiple phone issues within seconds through a little-known, well-kept secret procedure (turning it off and back on).

Perhaps they are a parent, tech-savvy sibling, cool aunt or uncle, or close family friend. Whatever the relation, the role stays the same. They are the unpaid, on-call tech specialist for every relative's forgotten password, printer jam, and device settings update.

If this sounds like you, we would first like to thank you for doing a job you never signed up for. Second, we would like to share a simple way you can help your family and friends protect their privacy and security without adding more to your plate.

A small settings change that makes a big difference

With Android and iPhone's latest releases, and Black Friday deals rapidly approaching, many people are upgrading their current phone to a newer model. As the family's go-to tech helper, you'll likely be setting up a few new devices in the near future. You already know the routine: connect to Wi-Fi, choose a language, and transfer data from the old phone to the new one. But beyond the steps you are prompted to take when setting up a new phone lies a quiet decision many people never think twice about: their default browser.

While people in some regions, like Europe and Japan, get to choose their default browser when setting up a new phone, this is not the case everywhere. Most phones ship with a browser preinstalled and set as the default, ready to start collecting data and monetizing off user activity the minute it's opened. Unless deliberately changed, that's the browser that will be used moving forward. Not because it's the best option, but because it's already there.

But remember, everyone can choose the browser they use, and as the designated tech whiz of the family, you can help inspire others to choose the right one.

Choosing Firefox means choosing privacy from the very first tap.

The browser is where the data lives

A browser is the door to everything you do online, and depending on how it's designed, it can see a lot. Every site visited. Every phrase searched. Every link tapped. As we socialize, work, and explore on our phones, the browser can be the biggest funnel of personal data leaving that device, and how it's built determines who collects that data, who can sell it, and how long it sticks around.

Privacy is the starting point for our browser, not an afterthought. Firefox is built on the principle that not even Mozilla should know which websites you visit or what you do there.

Why Firefox is the right call

Firefox is backed by Mozilla, a nonprofit-backed company with no shareholders to report to. Instead of chasing financial returns for a small group, Mozilla aims to provide an internet that truly puts people first. This means we limit the data we know about you and give you more choice about what data you share and when.

This commitment to user privacy is built into the browser itself. On both Android and iOS, Enhanced Tracking Protection (ETP) is enabled by default, blocking known trackers every time you browse. This helps prevent advertisers and data brokers from following people across sites, no setup required. You can also adjust ETP to fit different needs, including turning it off altogether or activating Strict mode for even stronger protection.

Control and choice are built in, too. Firefox has an easily accessible AI controls section where people can customize how AI features show up in the browser, or turn them off entirely - because AI should always be a choice, not a requirement.

To carry these principles and protections across every link opened on a new phone, set Firefox as the default mobile browser in just a few taps.

How to set Firefox as the default browser on Android and iOS

Downloading the Firefox mobile app isn't enough on its own, since most phones will keep opening links in whatever browser came preinstalled unless told otherwise. Here's how to make Firefox the browser that actually opens by default. Make sure Firefox is installed on the device you're working with before you begin.

On Android:

On iOS:

Once Firefox has been selected as the default browser, links tapped from messages, email, social media, or anywhere else will open in Firefox automatically. No additional steps required by your less tech-savvy family members and friends, and no relying on them to open the "right" browser every time they want to access the internet.

A little help on day one, lasting benefits later

The way a device is initially set up tends to stick. Whichever browser is already selected as default and whatever privacy settings are (or aren't) adjusted on day one often just…stay that way. That's a lot of reliance on whatever defaults the phone is purchased with.

So this fall, whether you are setting up a shiny new Google Pixel 11 for your aunt, an iPhone 18 Pro for your brother, or any other model for any one of your non-paying tech support "clients," take an extra five minutes to help them download Firefox and set it as their default browser. They can start their new device journey browsing with privacy, choice, and control built in. And you can check one more thing off your unofficial family IT to-do list.

The post An open letter to every family's designated IT support appeared first on The Mozilla Blog.

12 Nov 2026 2:00pm GMT

About:Community: A little Firefox inspo (and a pun)

Hi Mozillian,

We're quite late, but there's still time to join the fun! In this edition, we're sharing an online hackathon you can take part in from anywhere, a nostalgic campaign to invite people to come back to Firefox, reminder of what makes Firefox different, and a contributor's journey to landing three DevTools fixes. As a bonus, we've tucked in a little Firefox wordplay to give you something to puzzle over.

Grab your favorite drink and catch up with us!

Couldn't make it to Barcelona? Join Developers Wilding online instead!

Got a side project you've been meaning to finish? Join Developers Wilding: Online, a two-week hackathon running from October 28 to November 11. Build with Otari, Mozilla.ai's open-source AI platform, using your choice of models and tools.

Compete for up to $1,200 in prizes and opportunities to work directly with Mozilla.ai engineers! The first 200 people to sign up on Otari.ai also get $20 in tokens. Ready to join? Join the Discord to grab the devs-wilding role and get started!

Want to join in?

Remember how the internet used to feel like?

Firefox is bringing familiar faces from the early web together in a new campaign celebrating the creativity, curiosity, and community that made the internet feel personal. It's an invitation for former users to come back and a reminder that privacy, independence, and a little internet weirdness are still worth celebrating.

Check out the campaign

Still here, still yours

What makes Firefox different? Mozilla's latest blog post highlights five reasons to choose Firefox, from its nonprofit backing and privacy features to AI controls, its independent browser engine, and Kit, Firefox's friendly companion. It's a reminder of the values behind the browser our community helps support: privacy, independence, and choice.

Read more

Firefox wordplay

Let's take a quick break from product and community updates for a little Firefox wordplay to brighten your day. Someone on Reddit shared a question that might put your pun skills to the test: What do you call a large number of Firefox users?

Check out the answer

Community Spotlight

Community spotlight is back in this edition and this time, we want you to meet Ahmed E. In his original post, Ahmed shares how he landed 3 DevTools fixes, including a keyboard accessibility fix for a bug first reported in 2016. This story showed us that you don't need to understand the entire Firefox codebase to start contributing.

Check out the story

P.S.

Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.

12 Nov 2026 7:26am GMT

The Rust Programming Language Blog: Announcing Rust 1.100.0

The Rust team is happy to announce a new version of Rust, 1.100.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.100.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.100.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.100.0 stable

Never type

After 10 years and 5 failed stabilization attempts, the never type is finally stable! This also completes the project goal for this work.

The never type, spelled ! in code, is the canonical uninhabited type. It represents the type of diverging computations - computations which never resolve to any value - where any code that follows is unreachable. Expressions that terminate control flow, such as return, break, and std::process::exit, also have the type !.

Since having a value of the never type is impossible, Rust permits a never-to-any coercion, allowing to turn ! into any other type (this is what distinguishes it from any other uninhabited types). This can be used, for example, to not return a value from one of the branches of a match or an if:

fn mrrrow(option: Option<u32>) {
    let value = match option {
        // `x` has type `u32`
        Some(x) => x,
        // `return` has type `!`, which is then coerced to `u32`,
        // allowing the `match` to pass type checking.
        None => return,
    };
    // ...
}

While the never type could already be used and observed this way, and even named in the return type of functions (-> !), this release allows naming the never type anywhere:

fn infallible_unwrap<T>(res: Result<T, !>) -> T {
    // ^^ writing `Result<_, !>` was not allowed before
    let Ok(v) = res;
    v
}

Additionally this release changes Infallible to be an alias to the never type. That makes all old APIs that used Infallible be compatible with using !. This was the plan ever since the introduction of Infallible and is one of the reasons why the never type stabilization was so hard (waffle gave a talk about some of the troubles of the stabilization).

Unfortunately, to allow changing Infallible, we had to introduce a breaking change. This release changes the "never type fallback" from () to ! in editions before 2024 (i.e. 2015, 2018, and 2021), similarly to what has already been done in edition 2024. This should largely be unnoticeable, but can affect code in some rare cases (for example when ignoring a result of a function returning a generic parameter). Note that this change might also make the compiler detect more code as unreachable.

We tried to minimize the impact of this breaking change as much as possible, by providing future compatibility warnings far in advance and releasing fixes to public crates that have been broken by this. If a dependency is failing due to issues with the never type, consider updating it, as a fix might have already been released for it.

Allocator API

This release brings about the stabilization of the core parts of allocator_api, enabling library authors to define custom allocators that can be used together with certain standard library types - currently Vec and Box. These are enabled through the newly-stabilized Allocator trait.

This is the foundation of the Allocators 1.0 project goal. A lot remains to be done still, including expanding the API surface usable with custom allocators and stabilizing their use on more collections and pointer types; with the core trait and design out of the way though, expect to see more being stabilized soon!

DropGuard: run a closure on every exit path

The Drop trait in Rust makes it possible to run code when a variable goes out of scope, regardless of whether we return, ?, or panic. Drop being a part of types means that in Rust you never have to close a socket.

Implementing Drop can however feel a little inconvenient when all you want is to run some code unconditionally when a function exits. This is why we're introducing core::mem::DropGuard: a new helper type that runs a closure when dropped.

DropGuard takes two arguments: a variable and a closure. It implements Deref and DerefMut so you can keep working with the variable as normal. But when dropped it runs the closure and consumes the variable.

DropGuard also implements a dismiss method which returns the variable from the guard without running the destructor. This makes it possible to quickly implement all-or-nothing transaction-like APIs with a rollback. Here is an example implementing a parser which uses a guard to roll back mutations in case of failure:

use std::mem::DropGuard;
use std::num::ParseIntError;

/// Attempt to parse all `strings` and push them into `nums`.
/// If parsing any of them fails, `nums` remains unchanged.
fn parse_all(nums: &mut Vec<u32>, strings: &[&str]) -> Result<(), ParseIntError> {
    let len = nums.len();
    let mut nums = DropGuard::new(nums, move |nums| {
        nums.truncate(len);    // ← 1. Reset the vec on failure
    });

    for s in strings {
        nums.push(s.parse()?); // ← 2. If `?` returns an error, roll back
    }

    DropGuard::dismiss(nums);  // ← 3. Parsing successful, dismiss the guard
    Ok(())
}

Conjuring zero-sized types

As Rust's unsafe code guidelines are still being decided, it became clear that it would be very useful to decide what exactly it means to create zero-sized types in an unsafe way, and what we should recommend for people to do this.

This question is answered in Rust 1.100 with a single function: std::mem::conjure_zst.

Instead of transmuting (), MaybeUninit::uninit().assume_init(), or various other incantations, this is the dedicated way to create a value of a zero-sized type when you know that doing so is safe to do. If an inhabited type has no size, we know exactly what value it must be: nothing.

Of course, APIs often rely on the inability to construct such types for safety, and that's why this function is unsafe. For example, PyO3's Python<'py> is a zero-sized marker token that represents holding the Python GIL (global interpreter lock). Many of Python's APIs require holding this lock to be safe, but conjuring a token from thin air would allow safe PyO3 calls to violate that precondition.

Reporting unused dependencies in Cargo

Building dependencies that are no longer used or are only needed for specific platforms can slow down builds. Rustc has the unused_crate_dependencies lint for this but it has false positives when used with Cargo because dependencies may be shared between multiple build targets, e.g. dependencies.tracing-subscriber being available for every bin in a package when only some may use it.

Cargo now reports unused dependencies to users, e.g.

warning: unused dependency `tracing-subscriber`
  --> Cargo.toml:23:1
   |
23 | tracing-subscriber.workspace = true
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: `cargo::unused_dependencies` is set to `warn` by default
help: consider removing the dependency on `tracing-subscriber`

A limitation of this warning is that it will only appear when building every build target that may use an entry in a dependencies table. For example, running cargo check --bin foo won't show warnings for unused [dependencies] because another bin may be present that uses them. No warning will be shown for unused dev-dependencies because there isn't a way to ensure every development build target is built.

This warning is being introduced as part of a new linting system for Cargo, controlled by the [lints.cargo] table in Cargo.toml, completing this project goal. See also the other lints that have been introduced.

Reducing Cargo cache collisions

Cargo builds all libraries and binaries in the build-dir and then uplifts final artifacts to the target-dir. At this time, these share a common parent directory. Different build configurations, like --features, can lead to different copies of libraries and binaries in the build-dir. These copies are kept unique by a build-configuration hash but this hash was not always applied due to platform constraints. This can lead to extra rebuilds, missed rebuilds, confusion over what binaries or libraries are used, and so on. These problems get exacerbated when sharing a build-dir across git worktrees.

The build-dir now consistently applies the build-configuration hash to all content by organizing the directories around their build step, rather than their file type, and moving the hash from a file's name to the parent directory.

This work began with the build directory layout project goal in 2025, and its stabilization is a milestone toward a new project goal, unblocking future improvements such as cache garbage collection, cross-workspace cache de-duplication, cross-workspace caching, and fine grain locking.

We previously published a call for testing for the changes that are now taking effect. While this is an internal change, this may break build processes and tests that had workarounds for missing or incomplete features. In some cases, the workaround is no longer needed. See cargo#17287 for possible solutions and to add any new use cases.

Cargo min-publish-age a.k.a. dependency cooldowns

Malicious versions of packages are often caught within hours or days after being published, by either automated scanners or by the community. Rust 1.100 stabilizes Cargo's min-publish-age aware dependency resolution, which lets you wait for that window before it picks up newly published versions. This practice is also known as dependency cooldowns.

You can opt in via .cargo/config.toml:

[registry]
global-min-publish-age = "3 days"

When selecting versions, Cargo now skips any version published more recently than that, and tells you what it held back:

$ cargo update
    Updating crates.io index
     Locking 2 packages to highest compatible version as of min-publish-age
      Adding cc v1.11.0 (available: v1.18.0, published 3 hours ago)
      Adding clap 4.6.7 (available: 4.6.9, published 2 days ago)

When a new version is needed right away, you can override the check for a single update:

$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9
    Updating crates.io index
    Updating clap 4.6.7 -> clap 4.6.9 (published 2 days ago, minimum age 3 days)

The newer version will be recorded in Cargo.lock and kept from then on until a later cargo update re-resolves it.

A few things to keep in mind:

Further work to protect the ecosystem is planned under the crates.io supply chain hardening project goal, including quarantine support and automated detection of suspicious releases.

Stabilized APIs

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.100.0

Many people came together to create Rust 1.100.0. We couldn't have done it without all of you. Thanks!

12 Nov 2026 12:00am GMT

11 Nov 2026

feedPlanet Mozilla

The Rust Programming Language Blog: Google Summer of Code 2026 results

The Rust Project participated in Google Summer of Code (GSoC) for the third time this year. This time we had 13 projects, and our dear contributors have been working very hard on them for several months. As usual, the projects had various durations, so while some of them have ended in August, the last one has only finished in November, so we have been waiting until we have all the results before publishing this blog post.

We are very happy to announce that all 13 projects were successful and passed their final evaluation! We consider it to be a testament to the diligence of our contributors, and the helpfulness of our mentors, that we are able to keep a very high rate[1] of successful GSoC projects several years in a row.

At the start of summer, we had a video call with our contributors, so that we could all get to know each other a bit, and learn about their projects. Over the following few months, we continuously communicated with the contributors, provided guidance and answered their questions and reviewed their pull requests. And most importantly, we learned many new things together! It was an overall great experience. We are grateful for all Rust contributions done by our GSoC participants and for the time we spent working together, and we hope that we will continue seeing at least some of them around in the future.

We would like to thank all our Rust GSoC 2026 contributors. You did a great job!

Even though this year we had fewer projects than in 2025, mostly due to limited mentoring capacity, Google Summer of Code 2026 was again a success for the Rust Project. We think that GSoC is a great way of introducing new contributors to our community, and we are looking forward to participating in GSoC (and other mentorship programs, such as Outreachy) again in the near future. If you are interested in becoming a (GSoC) contributor, check out our GSoC project idea list and our guide for new contributors.

Below you can find a brief summary of our GSoC 2026 projects. You can find more information about the original goals of the projects here. For easier navigation, here is an index of the project descriptions in alphabetical order:

And now strap in, as there is a ton of great content to read about here!

A Frontend for Safe GPU Offloading in Rust

Marcelo worked on improving the usability of cross-vendor GPU programs in Rust using the std::offload module. At the start of the project, the offload prototype was only a proof of concept. It assumed that the offloaded code was bug-free, and it required users to write a lot of boilerplate code. Marcelo resolved both issues over the summer.

First, he implemented proper type checking. Marcelo extended the compiler to verify that the arguments passed to any offload call are of the correct type, as expected by the GPU kernel. Kernel launches are thus now safe.

After that, he added support for generic kernels. The compiler now collects all generic instantiations launched from the CPU side, and loads that info later when compiling GPU kernels to make sure we instantiate them as needed. Marcelo also added support to select which GPU to use, which is helpful for laptops with both an integrated and a dedicated GPU, as well as for servers with multiple GPUs. He also added two macros that removed the need for any boilerplate when writing and launching GPU kernels.

The hardest part of this project by far was dealing with references. Due to Rust semantics, we cannot just map types containing mutable references to GPUs and then process them using multiple threads. Previous Rust GPU projects used raw pointers as a workaround, but we obviously wanted to avoid those. Marcelo managed to implement a sound abstraction so that users can now safely declare how their kernels will access mutable arguments.

As a cherry on top, Marcelo also ported the RajaPerf performance suite from C++ to Rust and used it to benchmark his pull requests. His safe Rust version matches the performance of the original C++ code, and is now described in a GPU offload paper that he is working on together with his mentor, Manuel. This was Marcelo's second Rust GSoC project, and same as last year, we are very happy with the results. Great job!

Adding WebAssembly Linking Support to Wild

The goal of this project was simple on paper: teach the Wild linker to link WebAssembly (Wasm) programs. However, adding support for a new linker target is of course far from simple. Luckily, Kei already had a lot of experience with Wild, as this was his second GSoC project working on the Wild linker.

And as expected, Kei did a great job! Prior to GSoC 2026, Wild had no Wasm output support. Now, the Wasm support is sufficiently good that Wild can link a range of complex programs to Wasm. For example, it is able to link itself, SQLite, ripgrep, CPython and even the SpiderMonkey JavaScript engine.

And the linking performance is excellent! When compared to wasm-ld, the de-facto standard Wasm linker, which is based on the LLD linker, Wild is 2-15x faster, and uses 2-5x less memory. You can find more benchmarks in his final report, where he also explains that achieving this performance took quite some work, because Wild's ELF linking performance did not immediately translate to being fast when linking Wasm.

Even after this GSoC project ended, Kei has continued improving Wild's Wasm support, as well as contributing to other parts of Wild. Thank you for bringing fast linking to a new set of use-cases, Kei! You are a valued member of the Wild team.

Bringing autodiff and offload into Rust CI

The goal of this project was to build the experimental std::autodiff module, which implements automatic differentiation of Rust code, and the std::offload module, which allows offloading Rust code to GPUs, in the CI of the Rust compiler.

Shota has already been contributing to this area in the months leading up to this year's GSoC, so he had no issues getting started. After valiantly fighting with our CI, he made both modules available in the official nightly compiler channel. Rust users can thus now simply install them with a single rustup command, rather than having to compile rustc from source! This is a huge benefit for gathering feedback on these features in the wild, as it makes it much easier to experiment with them.

Beyond making these projects available via rustup, he also worked on making it simpler to build projects that use std::offload. The original compilation pipeline was derived from Clang's support for GPU offload, so it involved calling clang helper binaries. That is clearly not optimal, so Shota worked on replacing it by directly calling the underlying LLVM APIs from rustc.

The last piece of his project was enabling testing in CI for both offload and autodiff, which already helped prevent multiple regressions. Right now, the GPU offload pipeline only tests the CPU setup side, but his work allowed us to talk to GPU hardware vendors, two of which already agreed to provide the Rust Project with GPU hardware so that in the future we can also run those tests on dedicated GPUs.

Overall, the project was a success. Shota had to show a lot of patience and endurance when working with various CMake quirks and CI challenges. We would like to extend a special thank you for that!

Debugger for Miri

miri is a tool that can detect undefined behavior (UB) in unsafe Rust code. It used to have a prototype of an interactive debugger called priroda, but it became unmaintained some time ago. The goal of this project was to re-establish priroda, to make it easier to use miri interactively, debug how and why is UB introduced in Rust programs, and also help rustc developers analyse MIR, one of the intermediate representations of Rust programs.

Mohamed successfully reached both main goals of this project. He created a miri interface for the gdb debugger, which allows debugging programs executed by miri. You can set breakpoints, step through individual instructions, analyse MIR local variables and inspect the debugged program's state, with miri acting as a "virtual CPU". So when you encounter your next miri UB report, you can actually debug the program state that caused UB by running priroda! Mohamed also created a command-line interface for priroda, which is used to test it in miri's CI. This will ensure that it keeps working properly and will not bitrot again.

Mohamed also added basic support for the Debugger Adapter Protocol, which allows using priroda together with IDEs such as Visual Studio Code. Currently, connecting priroda to an IDE is a bit involved, so the next step would be to build a plugin for an IDE that would allow showing all the extra state that miri has, which gdb doesn't know how to interpret.

Debugging programs executed by miri is very exciting. Thank you for all your work!

Implementing impl and mut restrictions

The goal of this project was to implement two new language features that were accepted in RFC 3323:

Ryosuke had to familiarize himself with the compiler's codebase and do a lot of implementation work to get both features working. This included implementing parsing of the new syntax, recording its metadata in the compiler's Abstract Syntax Tree, implementing resolution of the restricted crate paths, and finally adding checks to enforce both restriction rules. This all amounted to around five thousand lines of Rust code!

Once the new features were implemented and available on nightly, Ryosuke wrote a Call for Testing blog post. It had to be very exciting to announce to the world that he implemented two new features from scratch, and people can now play with them on the nightly channel! After the blog post was published, users reported a few issues, which Ryosuke promptly fixed. He also contributed to rustdoc to improve how the impl and mut restrictions are rendered in the generated documentation pages.

Now that the features are available on nightly, feedback is being gathered on them, with the plan being to stabilize them in 2027. If you would like to provide feedback on the impl and mut restrictions, you can do so in this issue.

The goal of this project was clear, and Ryosuke achieved it completely. Awesome work!

Improving Ergonomics and Safety of serialport-rs

The goal of this project, which was done in collaboration with the Rust Embedded Working Group, was to improve the API ergonomics and type safety of the serialport-rs crate.

The serialport project is a bit different from some other projects which participated in this year's Google Summer of Code. It is more on the side of "facility management" than rocket science. Its challenges are taming finicky operating system APIs and making good abstractions, rather than full-blown software engineering.

Tanmay led many fruitful discussions about potential design decisions, and did a lot of field research on how other crates that depend on serialport actually use its API, to figure out how to make the upcoming breaking API changes less disruptive and painful for them.

Tanmay also worked on sanding off some rough edges of the serialport API, such as replacing Boxed trait objects with enums, and making errors explicit in places where the legacy API used to panic. Some of the work still waits for integration. It is targeting the upcoming serialport 5.0 release.

Christian (Tanmay's mentor) found working alongside Tanmay very motivational, and he was able to catch up with a lot of other unrelated work in order to integrate Tanmay's changes. He noted that working with Tanmay was fun and productive, and that it was pure joy to see him grow from his first contribution in the bonding phase to seasoned contributions. Thank you, Tanmay!

This was my first Google Summer of Code as well. It was challenging, motivating, fun and definitely worth it. I would show up again.

Christian Meusel

libc: transition differing bit-width time and offset variants and deprecate bug-prone constants

libc is a foundational crate that is used by thousands of other crates across the Rust ecosystem. For the past several years, its maintainers have been attempting to publish a stable 1.0 release of the crate. Because this crate has to support interoperating with C on many compilation targets with weird quirks, this requires an enormous amount of work. We already had a GSoC project for moving libc towards 1.0 last year, and the goal of Adam's project was to make more progress in that direction.

And we can happily say that progress was indeed made! The original goal of Adam's project was to deprecate a number of constants that were difficult to maintain and cleanup inconsistencies in handling 32-bit/64-bit variants of file and time handling functions[2]. Adam was able to resolve that in a few weeks, and then he moved on to resolve a number of various issues blocking the 1.0 milestone.

Saying that Adam was productive would be… an understatement. We could follow his work in real-time, because he was posting daily GSoC reports for 116 days (!) in a row. The diligence and consistency with which he tackled so many complicated issues was an inspiration to us. In fact, sometimes the libc reviewers were not able to keep up!

You can find all Adam's libc pull requests here. You might notice that many of them have lots of comments, and even more discussions happened in GitHub issues and on Zulip. In addition to implementing the necessary code, making changes that affect interesting C platforms and architectures also required him to do a ton of research, and a lot of considerations of edge cases and possible backwards compatibility breakages. His work also took him on a whirlwind tour of diverse platforms; Adam's contributions spanned FreeBSD, NetBSD, Android, Hurd, NuttX, AIX, VxWorks, Fuchsia, L4Re and more.

Even though more work will still be required to get libc to 1.0, Adam's contributions made a significant dent in this effort. Thank you very much for all your work!

Link Linux kernel and its Modules with Wild

Linker scripts are arcane commands that can be used to instruct a linker to construct the final binary in a custom way. The Wild linker used to implement only basic linker script functionality, which Vishruth greatly expanded during his GSoC project.

Thanks to that, Wild can now successfully link Linux kernel modules, and it's even close to being able to link the Linux kernel itself! Vishruth's work involved greatly expanding expression evaluation support, location counters, program headers, etc. In addition to adding support for many missing bits of linker script support, Vishruth implemented support for partial linking (-r) as this is needed in order to link Linux kernel modules. You can find all the linker script features that he implemented here.

Adding all those peculiar features to Wild required performing many cross-cutting changes to its codebase, which Vishruth managed to do really well. And it was not at the cost of performance! Wild now manages to link Linux kernel modules such as btrfs or amdgpu 2-4x faster than the BFD (GNU ld) or LLD linkers[3]. You can find more benchmarks in his final report.

Vishruth has continued to contribute to Wild even after his GSoC project ended and has become a valued contributor to the project. Thank you very much for making Wild better, Vishruth!

Migrating rust-analyzer assists to SyntaxEditor

rust-analyzer uses rowan for its syntax trees, a library for Concrete Syntax Trees. rowan has served us well over the years, but it has some downsides that cause major performance problems and also smaller convenience issues. In particular, memory fragmentation causes rust-analyzer to consume much more memory than it actually needs (in the order of redundant gigabytes).

We wanted to rewrite rowan to change that. The problem was that many parts in rust-analyzer touch syntax trees, and in particular assists (code actions) of which we have a lot. They also use mutable tree editing, a feature of rowan that can be convenient but was a major obstacle in rewriting it to be more efficient.

During his project, bit-aloo first migrated all rust-analyzer code from mutable tree editing to SyntaxEditor, a new abstraction that was created specifically to avoid mutation. After that, he removed mutable editing from rowan altogether.

The migration process is incremental and rowan is still inefficient in various aspects. However, we believe that the parts which required changes to large amounts of code are behind us, and we can complete the migration with more focused changes. bit-aloo is continuing to work on that even after his GSoC project ended. And he was also accepted as a member of the rust-analyzer team, so congratulations! We would like to thank him for his work, and hope to continue working with him to improve rust-analyzer for everyone.

Port std::arch test suite to rust-lang/rust

The std::arch module of the Rust standard library contains various intrinsic functions that provide architecture and vendor-specific functionality. Their implementation lives in the stdarch repository, which is included as a Josh subtree in the main compiler repo (rust-lang/rust).

When someone changes the intrinsics in the main repo, breakages can silently creep in, because the main repo does not execute all the stdarch tests in its CI. That can cause friction when we synchronize the changes between the two repositories. Ideally, we would run all of stdarch's tests in the main repo to detect any issues as soon as possible.

And that is where Sumit came in! Over the course of his GSoC project, he examined the (very!) complex ways the intrinsics are tested in stdarch, and started porting them over to the main repo. But this was not a matter of copying over a few lines of YAML. The compiler repo uses its own build system (called bootstrap) and a CI workflow structure that is quite different from the stdarch repository. Sumit thus had to first understand what is each test suite doing, reimplement it as a part of bootstrap and finally integrate it into the compiler's CI workflows.

We run ~90 CI jobs across several hardware architectures, operating systems and OS versions. Getting all that to work while testing vendor-specific intrinsics required a lot of diligent work… and a lot of patience. It took five months for one of the test suites to finally succeed on the main repo's CI, and it required Sumit to completely refactor how the suite worked, for it to be more compatible with bootstrap. As another example, a different test suite that Sumit also got to work required running the tests in an Intel CPU emulator on CI.

Sumit ported most of the stdarch test suites to bootstrap, including intrinsics verification against reference C implementations, checks for automatically generated source code being up-to-date, and various unit tests for individual intrinsics and CPU feature detection logic. There is one remaining test suite to port, but the ported tests are already helping us find issues, which is great.

You can check Sumit's rust-lang PRs here; notice that he was also contributing to other parts of Rust in the meantime! Sumit's work will help us make LLVM upgrades and land intrinsics changes more easily. Thank you, Sumit!

Reorganizing tests/ui/issues

The goal of this project was to get rid of a very scary place in the Rust compiler's test suite: a directory called tests/ui/issues. It contained thousands of test files based on historical Rust issues, dating back all the way to 2012. The problem with those tests was that they were named only with an issue number (e.g. issue-37291). When such a test would break, it was quite difficult to figure out what was it even supposed to test, because there was little context attached to it.

Even though we already had a GSoC project to tackle this problem last year, due to the sheer amount of uncategorized tests, there were still over four hundred tests left in this directory by the time zedddie started working on this project.

For each test in this directory, zedddie had to first understand what was the test doing and dig through its original GitHub issue and any other related issues and pull requests. Then they had to figure out what would be the best location to move the test under, search for any possible duplicates, come up with a descriptive name for the test (that tends to be very difficult!), and finally add a short description to the test that explains the context of why the test was added in the first place. Rinse and repeat, for hundreds of tests.

zedddie rolled up their sleeves, and categorized over 300 tests in 30 pull requests. Together with other contributors helping out over this summer, zedddie was finally able to remove the last batch of uncategorized tests at the start of August. As zedddie said in their final report: "What is left to do: nothing, tests/ui/issues is gone".

While this work might sound a bit bland, its positive effect on the maintainability of our test suite, and improving the lives of Rust compiler contributors, is considerable. It is also apparently a great way to learn about cool niche edge cases of Rust that most Rust developers might not know about! After migrating the remaining uncategorized UI tests, zedddie continued contributing to the next trait solver and const generics. Thank you very much for helping us finally get rid of tests/ui/issues, zedddie!

Utilize debugger APIs to improve debug info test accuracy and error reporting

The Rust debugging experience leaves a lot to be desired. One reason why we struggled to improve it is that many of our debuginfo test suites did not even run in CI for the past few years, as they were difficult to maintain. When something changed in the type visualizers, the implementation details of a standard library type or in debugger internals, someone had to go through tens of tests and manually update them. This was not sustainable, so the test suite rotted.

Luckily for us, Anthony took that affront personally. Even before his GSoC project, he spent considerable effort on improving the quality of debug visualizers of various Rust standard library types, and gained an impressive amount of knowledge about debuggers.

During his GSoC project, he completely overhauled how our debuginfo test infrastructure works, both for LLDB and GDB. Thanks to his improvements, we can now easily "rebless" the reference output when something changes, which makes it much easier to keep our test suite up-to-date. The new tests also record much more information about the internal state of the debugger recorded during the test, which helps with diagnosing issues that cause type visualizers to stop working.

In addition to redesigning the test suite, Anthony also actually managed to re-enable the LLDB tests on both Windows and Linux in our CI again (after several years of being skipped there!). This will allow us to avoid debuginfo regressions and make it easier to improve the Rust debugging experience. Oh, and it goes without saying that while doing all that, he also made numerous improvements to Rust type visualizers. You can find his PRs here.

Anthony's amazing contributions and his deep expertise in debuggers led to him being invited to the Rust Compiler team, which was much deserved. What else can we add, other than: thank you for your awesome work!

XDG path support for rustup

The support for platform-specific directories (platformdirs) has been a long-standing feature request for rustup, to have more fine-grained filesystem directory choices. This project investigated how that issue could be resolved.

The real complexity of this feature request lies within a decade worth of different assumptions that previous iterations of rustup and cargo have made: it turns out that quite a lot of them are no longer true if we were to implement platformdirs support truly faithfully.

Guicheng first worked on cleaning up the interactions between rustup self uninstall and $CARGO_HOME/bin as a warmup. This issue itself is a very good demonstration of all that compatibility baggage: somehow $CARGO_HOME/bin has become the default binary directory for all things Rust, so rustup ended up installing itself and all its proxies into it. As a result, it has been super annoying to many that everything in $CARGO_HOME is gone with rustup self uninstall.

After that, he started the actual implementation of platformdirs support in rustup. This was no easy task! Not because the code itself was hard to write, but because it takes a lot of effort to figure out what should be the desired behavior in the first place. Also, in order to determine the appropriate platformdirs semantics, some prior research is often required to see how things became what they are today, so the decoupling of different concerns could proceed, and migration paths could be designed accordingly. It was in this sense that this is different from a typical GSoC project, and luckily thanks to the effort he has put into this project, we have not only come up with the final patch, but also discovered and fixed some tiny preexisting issues with this long-untouched aspect of the rustup codebase along the way.

Thank you for digging into this complex topic, Guicheng!

Conclusion

We would like to thank all contributors who have participated in Google Summer of Code 2026 with us! Your contributions helped make Rust better, and introduced you as new members of our community, which is a reason to celebrate. We are looking forward to participating in GSoC again next year!

We would also like to thank Google for organizing the Google Summer of Code program and for allowing us to host a large number of projects every year. And last, but not least, we would like to thank all the Rust mentors who were tirelessly helping our contributors to complete their projects. Without you, Rust GSoC would not be possible.

  1. 97.5% over a three-year period, if you are wondering (40 out of 41 projects were successful so far). ↩

  2. If you were wondering, then yes, this is actually related to the famous 2038 problem :) ↩

  3. In case you were wondering, the mold linker does not support linker scripts required to link Linux kernel modules at the moment, so Vishruth did not compare the performance of Wild against mold here. ↩

11 Nov 2026 12:00am GMT

10 Nov 2026

feedPlanet Mozilla

Mozilla Security Blog: Open research, stronger privacy: Making Firefox users harder to fingerprint

Firefox is strengthening protection against trackers that recognize you across websites, even when they don't use cookies. The latest fingerprinting protections shipped in Firefox reduce the extractable distinguishing details, making more Firefox users look alike to tracking scripts and strengthening individuals' privacy in everyday browsing.

These protections build on our research into browser and device fingerprinting, a technique that combines details about your browser and device to identify you across websites. We investigated which details contribute most to make users uniquely identifiable, turned those findings into practical protections for Firefox users, and shared our results openly so the wider web security and privacy community can build stronger defenses.

Our findings are documented in the research paper Large-Scale Measurement and Real-World Mitigation of Web Browser Fingerprinting in the Wild, which has been accepted for publication at Computer and Communications Security (CCS) 2026, a leading international conference on computer security and privacy. We've also created an easier-to-digest website and browser test suite to help explore the findings in the paper.

Cookie-less Tracking

Browser fingerprinting combines details about your browser and device, such as available fonts, screen dimensions, and graphics hardware, to build a uniquely recognizable profile. Each piece may seem ordinary, but together, they can enable trackers to single you out across websites, even without storing a cookie.

Effective fingerprinting protection starts with understanding which browser details trackers rely on most. Our research found that protecting just a handful of browser features can significantly weaken popular fingerprinting techniques. That finding enabled us to focus on Firefox's protections where they can make the biggest difference and bring those benefits to all Firefox users.

To evaluate these techniques, we simulated the browser measurements collected by fingerprinting scripts from Fingerprint Pro, Signifyd, and Akamai and examined how their combinations distinguish users. The study used measurements collected from nearly 25 million Firefox users, with additional privacy safeguards beyond Mozilla's existing data collection policies.

Those safeguards included OHTTP, which routed encrypted requests through a relay. The relay sees the user's IP address but not the request contents, while Mozilla receives the contents without the user's IP address. We also tightly limited data access and retention: individual telemetry records were deleted several months ago and only aggregate results were retained and published for open science. Our research paper explains the method, safeguards and ethical considerations in detail.

Less distinctive, more private

Our approach reduces unnecessary differences in the information Firefox exposes to websites. For example, Firefox limits the information exposed through screen resolution APIs to hide the size and position of the system taskbar or dock, preventing that desktop layout detail from contributing to a fingerprint. As another example, it can report processor counts as either 4 or 8 instead of exposing the exact count, which can make a browser more distinctive.

Our goal is to make more users' browsers look similar to fingerprinting scripts while preserving the information websites need to function correctly, like language and timezone settings. Firefox also uses randomization to make other fingerprinting signals less useful to trackers, though the benefits of these techniques are harder to quantify and fall outside the measurements reported here.

In our evaluation, these protections (the most recent of which shipped in Firefox 145) substantially degraded the precision of fingerprinting in Firefox both by reducing the number of users with unique fingerprints and increasing the size of the groups of users that share a fingerprint.

The research also enabled us to identify why certain measurements differed between users. Addressing these differences produced more consistent outputs for image rendering, Web Audio, and mathematical operations on Android, reducing the distinguishing details available to fingerprinters.

These results show that substantial reductions in browser fingerprint uniqueness are achievable and provide meaningful progress toward stronger online privacy. These do not make fingerprinting impossible as trackers can surely adapt. But our research provides a concrete, measurable improvement in browser defenses against online tracking.

The built-in privacy protections in Firefox are complemented with capabilities and options to further strengthen the protection against online fingerprinters. Built-in and always-on Total Cookie Protection in Firefox segments stateful identifiers and prevents trackers from following you across your browsing using cookies. Firefox Relay provides you with unique email masks, preventing websites from linking your subscriptions to other sites via data brokers. And Firefox now integrates a free VPN that masks your IP address to protect against tracking and fingerprinting. Together with Firefox's enhanced fingerprinting protections, these capabilities provide everyone a very strong foundation to take back control of their privacy online.

Research that improves everyday browsing

Privacy protections need to work on the websites people use every day. These findings allow us to prioritize changes that deliver measurable privacy benefits while keeping those websites working.

Some of Firefox's fingerprinting protections, such as hiding the size of your taskbar or dock, are on by default in all browsing modes. Others are introduced first in Private Browsing and Strict Enhanced Tracking Protection (ETP) mode, while we work toward enabling them by default, following the same strategy we've used for years. To enable these additional protections in all your Firefox windows, select Strict in the Enhanced Tracking Protection settings. Follow the steps here if the "Strict" protections get in the way of any website functionality.

Want to explore browser fingerprinting yourself? Visit the research project page to try the fingerprinting test and learn more about our findings. For a closer look at what we measured and how we turned those insights into Firefox protections, explore our paper: Large-Scale Measurement and Real-World Mitigation of Web Browser Fingerprinting in the Wild.

We'll keep strengthening Firefox's privacy protections while continuing to work in the open. By sharing our research, our code, and what we learn, we're shaping the web we envision: free, private, secure, and accessible to all.

The post Open research, stronger privacy: Making Firefox users harder to fingerprint appeared first on Mozilla Security Blog.

10 Nov 2026 6:36pm GMT

Thunderbird Blog: From Research to Prototype: Testing the New Desktop Settings

New appearance settings page, changing the accent colour

In the last update, the team shared ongoing work around removing technical jargon and adopting plain language so everyone can navigate settings with ease. Those initial content refinements have rolled out into Thunderbird already (v160).

Following those copy updates, the team ran research to evaluate how settings information is structured. Below is a breakdown of what the data revealed, how those findings shaped an interactive prototype, and the plan for incremental rollout.

If you don't have time to read the full research summary, here are the key points. We had an overwhelming response to the research study, so we have feedback from many different perspectives and use cases. Some of the new organization of categories weren't as easy to find because of the language or because it was too hidden, so we've updated those and it's reflected in the new prototype linked below.

Tree testing survey for the new information structure

Research overview

Who took part in the study

About the structure of the study

To evaluate the proposed information architecture, the team conducted a tree test.

A tree test evaluates a text-only hierarchy with no visual styling. It isolates structure from visual design, reveals the exact navigation paths taken to complete a task, and saves development effort by validating organization before code is written. The scenarios that we tested alongside the tree test focused on key areas users have been bringing up as things they change often or have been confused about in the past.

However, there are trade-offs: without visual cues (icons, layout, color), success rates in tree tests are often artificially lower than in a functional app. Crucially, a tree test cannot simulate an active search bar, a primary navigation method for many participants. That is why testing an interactive prototype is the next step.

Key research insights

What worked well

What needs improvement

Feedback from participants who provided detailed qualitative comments:

Turning feedback into design decisions

Preview of the desktop settings prototype

We've taken all that feedback into consideration and designed a lightweight prototype that uses a new way to structure the information. Some folks might not notice the new changes, but we hope this makes discovery easy for new users while maintaining the flexibility our user base values.

You'll also notice the prototype doesn't have all the functionality built in so some things might not work, nor does it adapt to your operating system so it displays specific language appropriate for macOS, Windows or Linux.

➡ Test the prototype

What's next

One area deliberately not tackled in this prototype is the split between Account Settings and Global Settings. Bridging that gap requires deeper architectural changes. To avoid over-complicating this iteration, changes are being kept incremental.

Overhauling settings across a mature application cannot happen in a single, disruptive release. Each functional piece will include direct avenues for testing and feedback before graduating to beta and stable channels.

Thank you to everyone who took part and contributed such thoughtful feedback.

The post From Research to Prototype: Testing the New Desktop Settings appeared first on The Thunderbird Blog.

10 Nov 2026 3:10pm GMT

The Mozilla Blog: Firefox’s free built-in VPN uncaps data limit through January 2027

Whether you're heading home to see family this winter or taking a well-earned break before the year wraps up, we want you to browse with a little more peace of mind. That's why, as our gift to you, everyone using Firefox's free built-in VPN gets unlimited data starting today, November 10, through January 31, 2027. Sign in with a Mozilla account and unlock extra privacy for all that shopping, travel planning, and everyday browsing, no gift receipt required.

Using Firefox's free built-in VPN makes it harder for websites to use your IP address to determine where you are, or connect your visits across the web. Most importantly, you're not trading your browsing data for that protection: Firefox doesn't sell your browsing data, interrupt you with ads, or keep a record of the websites you visit.

You can use VPN to:

Two things to remember:

  1. VPN doesn't make you anonymous online or hide browsing history on your device. Websites can recognize you through cookies or when you sign into an account. Use Private Window to browse without logging new visits in your Firefox history.
  2. Firefox's built-in VPN only covers browsing within Firefox. For protection across other apps on your device, check out Mozilla VPN (a separate, paid subscription service).

Firefox's free built-in VPN is available to people using Firefox on desktop and Android (iOS is coming soon!). To start using the service:

You can check for availability in your region and review full instructions for using VPN on desktop and Android in our Help Center.

Download Firefox to try it out today.

The post Firefox's free built-in VPN uncaps data limit through January 2027 appeared first on The Mozilla Blog.

10 Nov 2026 2:00pm GMT

05 Nov 2026

feedPlanet Mozilla

The Servo Blog: September in Servo: , rounded rectangles, and more!

Servo 0.7.0 contains all of the changes we landed in September, spanning 527 commits!

a black and white cat named Gary showing off new visual web platform features

The developer tools console now eagerly evaluates JS inputs, allowing faster feedback (@freyacodes, #47527).

We've shipped new web platform features:

Plus a bunch of new DOM APIs:

Security

We upgraded to SpiderMonkey v153.3 and mozangle v0.7, both of which included fixes for security bugs reported upstream (@sagudev, #48176, #47655, #48259).

Real world compat

The egui.rs demo now works as expected with --pref dom._webegpu_enabled.

http://egui.rs rendering in Servo

This Candy Crush game is now playable.

A Candy Crush game rendering in Servo

We're interested to hear how well your favourite websites run in Servo! Report successes in this Zulip thread or this Github discussion, and failures in our GitHub issues.

Work in progress

Our accessibility tree (--pref accessibility_enabled) now reports geometry bounds for inline elements (@alice, #47905) and does much less work when responding to DOM changes (@alice, @mrobinson, #47690). Additionally, elements with display: none are reported as hidden (@alice, #47772).

We had lots of conformance improvements for our WebGL2 implementation (--pref dom_webgl2_enabled) (@mxmgorin, #48423, #48441, #48470, #48479, #48495, #48473, #48536).

Support for WSIWYG editors (which rely heavily on contenteditable) is going very well: keyboard inputs are now hooked up when --pref dom_exec_command_enabled is present, so many editors are now usable (example).

Closed captioning for video elements is making progress. Text tracks now fire enter, exit, and cuechange events (@TimvdLippe, #47725). Media elements now return the full sorted list of text tracks (@TimvdLippe, #47785), and adding cues to a text track now sets that track correctly (@TimvdLippe, #48012). Text track objects now reflect the attributes of the associated <track> element. Text track URLs are fetched at the correct time (@TimvdLippe, #48325), and active cues are computed correctly (@TimvdLippe, #48305), while text track cues are ordered as expected (@TimvdLippe, #48368). Additionally, WebVTT parsing can now recover from errors (@TimvdLippe, #48391).

The Sanitizer API (--pref dom_sanitizer_enabled) now accepts the javascriptURLs property (@skyz1, #47867).

IndexedDB continues to improve: tables no longer error if unrelated tables contain duplicate index names (--pref dom_indexeddb_enabled) (@leowatts, #47936). Additionally, we implemented openCursor() and openKeyCursor() on IDBIndex (@kuntal-devrat, #48281), as well as advance(), continue(), and continuePrimaryKey() on IDBCursor (@kuntal-devrat, #48400).

We implemented the getTimeline() and setTimeline() methods for the Animation interface (--pref dom_web_animations_enabled) (@simonwuelker, #48122).

Embedding API

There's a new API for events originating from accessibility tools: Servo::forward_accessibility_action (@alice, @mrobinson, #48512).

There is also an API to clear session history: WebView::clear_session_history (@Narfinger, #47483).

The WebView::set_throttled API has been removed (@mrobinson, #39923). Throttling automatically occurs when a WebView is hidden and is stopped when shown.

The WebViewDelegate::notify_focus_changed method was removed, along with the Servo methods focus and blur (@mrobinson, #48364). Embedders must call WebView::set_focused whenever a WebView has gained or lost system focus.

The webgl feature has been added to the default_web_features feature (@janeoa, #47866). If an embedding does not want to ship with WebGL support they will now need to disable default features.

Multiprocess mode is enabled at build time with the new Cargo feature multprocess (@Narfinger, #47360). To remove support for this feature (reducing binary size by ~2MB), build Servo with default features disabled.

Two new preferences exist to tune garbage collector behaviour: js_mem_gc_malloc_threshold_base_mb and js_mem_gc_urgent_threshold_mb (@mxmgorin, #47999). These can help on memory-constrained devices, and more information is available in the SpiderMonkey source (base, urgent).

The JVM compatibility target was raised to 11 on Android (@veyndan, #48414).

For users and developers

It is now possible to cross-compile the OpenHarmony build from Windows hosts (@jschwe, #48392).

Unhandled promise rejections are reported to the JS console (@TTyChud, #48486), making it easier to narrow down web compatibility issues in Servo.

The OpenHarmony SDK was updated to API level 23 (@Narfinger, #48505).

Pressing Control+A (or Command+A on macOS) now selects all the content in a document (@dzfrias, @mrobinson, #48025). It is no longer possible to copy text inside of password inputs (@dzfrias, #48404).

Embedder-originating JS (e.g. devtools console or embedding APIs) will always execute, even in documents that disable scripting via sandboxing or CSP (@derdilla, #48394).

Performance and stability

We improved performance by removing unnecessary allocations (@Narfinger, @TimvdLippe, @yezhizhen, #47689, #47839, #47838, #47982, #48006, #48036, #48099, #48204, #48127, #48218, #48357, #48386, #48422, #48440, #48452, #48508), preallocating more when building vectors (@jschwe, @Narfinger, @sagudev, @webbeef, #47455, #47613, #48026, #48398), and avoiding IPC in single process mode (@leowatts, @Narfinger, @Uiniel, @TTyChud, #47691, #47718, #48002, #48073, #48476, #48435).

We also sped up Servo by reducing interactions with the GC (@TimvdLippe, @Narfinger, #47818, #48257, #48396), and doing less work when modifying selections (@SimonSapin, #47579), dispatching events (@webbeef, #48078), calculating font metrics (@RichardTjokroutomo, #48238), and indexing window frames (@mrobinson, #47832).

We reduced memory usage in common cases by reusing buffers (@Narfinger, #47751), clearing more page-specific data (@Radeonares32, @Narfinger, @jschwe, @mrobinson, @mxmgorin, #47651, #47806, #47805, #48166, #48295, #48297, #48016), compacting data structures (@Narfinger, @webbeef, @SimonSapin, @mrobinson, #47776, #48039, #48050, #47742, #48301, #48296, #48105), and sharing more buffers (@jdm, #47998). We also fixed a memory leak involving <audio> and <video> elements (@TTyChud, #48371).

We turned on thread affinity boosting on Linux, which can improve performance on some CPU architectures (@jschwe, #47058).

We're working on statically preventing a footgun that can lead to uncollectible GC cycles and leaking memory (@Gae24, @jdm, @lumiscosity, @SilvioPilato, @sahilnyk, @TTyChud, @kuntal-devrat, @MohamedAli00949, #47941, #48013, #48021, #48035, #48033, #48051, #48072, #48171, #48209, #48248, #48246, #48264, #48285, #48311, #48408, #48053, #48156, #48186, #48223, #48315, #47872, #47698, #47682, #47735, #47816, #47817, #47794, #47909, #47934, #47935, #47954, #48022, #47955, #48058, #48228, #48247, #48261, #48280, #48302, #48316, #48328, #48346, #48355, #48262, #48377, #48304, #48378, #48388, #48432).

We fixed panics in WebRTC (@MunishMummadi, #4772), execCommand() on Document (@TimvdLippe, #47784), <video> (@calvaris, #46148), <iframe> (@jdm, #48465), SharedWorker (@mrobinson, #47940), ancestorOrigins on Document (@mrobinson, #48009), about:memory (@mxmgorin, #47686, #48001), and EGL 1.4 configurations (@mxmgorin, #47803).

We also fixed a very ironic panic triggered by the about:crash page that loads when a normal page triggers a panic (@mrobinson, #48055)

The JS console no longer hangs when primitive values as thrown as exceptions (@FatCat560, #47629). Servo no longer hangs on shutdown in multiprocess mode (@Narfinger, #48523), when certain pages use IntersectionObserver (@mxmgorin, #47693), when closing a browsing context with pending WebDriver commands (@yezhizhen, #48131, #48172), or when closing SharedWorkers (@nicoburns, #48477).

about:memory got more improvements: we measure more memory for SVG rendering (@Narfinger, @mrobinson, #47061), WebAudio (@jdm, #47996), and identify globals that have been leaked (@jdm, #48237).

More on the web platform

CSS images now delay the load event, leading to more consistent behaviour for engine users performing visual rendering (@TimvdLippe, #48199).

Interactive selections in documents continued to improve! They now can span shadow trees (@mrobinson, @SimonSapin, #47931, #47694, #47895), and have consistent heights and positions (@mrobinson, #47937), plus there are new context menu entries to copy and select all (@mrobinson, #48101). Additionally, image-based content shows when it is part of a selection (@mrobinson, #48149).

Window.open() respects sandbox flags that prevent popups (@mrobinson, #47653).

LargestContentfulPaint now reports the loadTime for image content (@shubhamg13, #48286), ignores cross-origin frames (@shubhamg13, #48094), ignores invisible text (@shubhamg13, #48010), and reports null elements when they are removed from the tree (@shubhamg13, #48125).

select() on a text input now focuses the control (@dzfrias, @mrobinson, #48475).

Our WebDriver server now automates setting permissions (@xbwwj, @yezhizhen, #47623), while sending click events and keyboard actions uses fewer delays (@yezhizhen, #48066).

There are more useful error messages for methods on Document (@eachra-bawn, #47835) and CSS-related interfaces (@eachra-bawn, @jdm, #47746).

We upgraded our stylo dependency, which improves compatibility with contrast-color(), color-mix(), vertical-align, list-style, place-items, at-rule(), calc(), alpha(), attr(), content: attr(), and named-feature() (@Loirooriol, #46987, #47942).

We also fixed bugs related to visibilityState on Document (@yezhizhen, #47908), containsNode() on Selection (@mrobinson, #47938), setKeyframes on KeyframeEffect (@simonwuelker, #48103), selections when focusing a text input (@mrobinson, #48107), AudioParam clamping and automation (@kevlu93, #48351, #48347), PannerNode outputs (@kevlu93, #48510), the muted attribute on HTMLMediaElement (@TimvdLippe, #48403), placeholders in text inputs (@jdm, #47761, #47797), animations when modifying document stylesheets (@SharanRP, #48000), gradient color stops (@BudiArb, #48288), sticky table rows (@TTyChud, #48380), ::first-letter (@Loirooriol, #48307), text-wrap-mode (@mrobinson, #48469), OTF fonts (@wood-ghost, #47904), CSS and nosniff (@sahvx655-wq, #45481), Sec-Fetch- headers and redirects (@TimvdLippe, #48203), moveBefore() on Node (@mrobinson, #47692), supports() on WebCrypto (@kkoyung, #47768, #47891, #47953, #47984, #48410, #47545), cross-origin windows (@mrobinson, @jdm, #47632, #48411, #48038), origins of about:blank and about:srcdoc (@mrobinson, #47630), keypress events (@mrobinson, #48324), text and media documents (@SilvioPilato, #47823), body() on Response (@TTyChud, #48409), <details> with <summary> (@TimvdLippe, #48224), editing hidden inputs (@dzfrias, #48165), attribute nodes in XPath (@leowatts, @mrobinson, #47912), absolutely positioned boxes (@mxmgorin, #48081), CSS Grid containers with absolutely positioned nodes (@nicoburns, #47519), WebDriver wheel/pointer actions (@yezhizhen, #48143), and blob: URLs (@Gae24, #47910).

New contributors

A special thanks to the following people for landing their first patch in Servo:

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Donations

Thanks again for your generous support! We are now receiving 8144 USD/month (+1% from August) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.

Servo is also on thanks.dev, and already 37 GitHub users (+1 from August) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you're interested in this kind of sponsorship, please contact us at join@servo.org.

8128 USD/month
10000

Use of donations is decided transparently via the Technical Steering Committee's public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

05 Nov 2026 12:00am GMT

04 Nov 2026

feedPlanet Mozilla

Firefox Tooling Announcements: Firefox Profiler Deployment (November 4, 2026)

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed:

Changes:

Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!

1 post - 1 participant

Read full topic

04 Nov 2026 1:13pm GMT

This Week In Rust: This Week in Rust 676

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Foundation
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs

Crate of the Week

This week's crate is tellus, a tokio-based actor framework that can be used without writing async code.

Thanks to Sean Kwak for the partial-self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

597 pull requests were merged in the last week

Compiler
Library
Cargo
Rustdoc
Rustfmt
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

This week a 0.4% increase in instructions is traded for a 33% reduction in rmeta size on some real benchmarks. Even with that regression, this week's average is still very positive thanks to a refactoring around AttrTokenStream, by using Symbols instead of Strings in the lint infrastructure, and by avoiding an extra AST walk for lang item collection, among other things. A lot of noise this week, which is mostly caused by two large rollups whose base PR was noise.

Triage done by @JonathanBrouwer. Revision range: 019b59d8..4c46afa6

3 Regressions, 11 Improvements, 27 Mixed; 2 of them in rollups 195 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Compiler Team (MCPs only)

No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-11-04 - 2026-12-02 🦀

Virtual
Asia
Europe
North America
South America
Oceania:

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Think about how your contributions may be received before you send them. This kind of thought, true thought, with real emotion and reasoning, is the only thing that you, a human, are guaranteed to be able to contribute.

- Jubilee on rust-users

Thanks to Jonas Fassbender for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

04 Nov 2026 5:00am GMT

03 Nov 2026

feedPlanet Mozilla

Firefox Tooling Announcements: Happy BMO Push Day! (20261103.1)

Github Link

The following changes have been pushed to bugzilla.mozilla.org:

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

03 Nov 2026 10:05pm GMT

Firefox Tooling Announcements: MozPhab 2.24.0 Released

Bugs resolved in Moz-Phab 2.24.0:

Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.

1 post - 1 participant

Read full topic

03 Nov 2026 2:49pm GMT

The Rust Programming Language Blog: Announcing rustup 1.29.3

The rustup team has published a new point release of rustup, 1.29.3.

Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

What's new in rustup 1.29.3

This new patch release has fixed some minor regressions over the previous one:

Further details are available in the changelog!

How to update

If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

$ rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

$ rustup update

For this particular release, if you have encountered any issues during self-update, you may try to update rustup manually by following the steps below:

  1. Download the corresponding rustup-init binary for your platform.
  2. Make double sure that no other rustup processes are running.
  3. Replace your existing rustup binary with the downloaded rustup-init renamed to rustup.
    • As a reminder, this binary is often located at $HOME/.cargo/bin/rustup, or $CARGO_HOME/bin/rustup if you have overridden the $CARGO_HOME environment variable.

If you don't have it already, you can get rustup from the appropriate page on our website.

Rustup's documentation is also available in the rustup book.

Caveats

Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

Thanks

Thanks again to all the contributors who made this rustup release possible!

03 Nov 2026 12:00am GMT

02 Nov 2026

feedPlanet Mozilla

Firefox Application Security Team: Firefox Security & Privacy Newsletter 2026 Q3

Welcome to the Q3 2026 edition of the Firefox Security & Privacy Newsletter.

Security and privacy are core principles of Mozilla's Manifesto and remain at the heart of Firefox's development. This edition highlights key initiatives from Q3 2026 across three areas:

Preface

Note: Some of the bugs linked below might not be accessible to the general public and restricted to specific work groups. We de-restrict fixed security bugs after a grace-period, until the majority of our user population have received Firefox updates. If a link does not work for you, please accept this as a precaution for the safety of all Firefox users.

Firefox Security

Rapid Releases, Now Even Faster: Since September 2026, Firefox has followed a faster release cycle, bringing improvements, including security fixes, to users more quickly. We also invite you to see and shape what's next for Firefox, including upcoming security and privacy features.

Many recent releases have included more security fixes. We continue to use frontier LLMs to identify and fix security bugs in Firefox to always keep you safe online. We have also changed how we publish advisories: instead of grouping internally identified memory safety vulnerabilities under a single CVE, we now publish a separate advisory for each bug, anticipating a potential change to the CVE Numbering Rules. CVE counts alone are not a reliable measure of security, as software vendors are not required to assign CVEs to vulnerabilities they discover internally.

Know when your TLS is broken: Starting with Firefox 157, you will see warnings in the site information panel (the shield icon in the address bar) and in Settings when your connection may not be completely private. For example, if an administrator configures your Firefox to record its encryption keys, you will be able to catch that. Recording these keys could allow another software to read all of your encrypted web traffic without your knowledge.

Mozilla Root Store Policy v3.1: We are strengthening transparency and assurance in the WebPKI with Root Store Policy v3.1, which introduces stricter transparency, documentation, and audit requirements for public certificate authorities.

Email Client Spam Prevention: Firefox now treats mailto: links as popups, requiring explicit user action before opening the email client. This prevents websites from repeatedly opening email composition windows through JavaScript and overwhelming the user.

Restricting Local File Access for Extensions: Starting in Firefox 153, extensions need your explicit permission to access local files through `file://` URLs. Access is off by default for all extensions, including those already installed, so you decide which extensions can access files on your device.

Firefox Privacy

Fingerprinting Protections: Following a report on Alibaba's use of audio fingerprinting, Tom Ritter published a data-backed analysis explaining how Firefox's protections reduce the accuracy of fingerprinting through the Web Audio API. The story received coverage from Ars Technica, The Register, and others.

Preventing Link Tracking: Right-clicking a link and selecting Copy Clean Link will now strip tracking parameters across arbitrary subdomains, along with 130 additional tracking parameters.

Bringing Containers Directly into Firefox: Previously available as extension, Firefox 153 introduces built-in Containers, helping you keep work, personal browsing, and other activities separate. Each container maintains its own cookies and login sessions, so you could use containers for multiple accounts on the same site, or to limit online tracking by isolating certain websites in their respective containers. Firefox 155 also adds the ability to reorder containers.

Tracker Blocking Information on Android: Starting in Firefox 153, the Privacy Dashboard on Android shows which types of trackers Firefox blocks, giving you a clearer view of how Firefox protects your privacy as you browse.

Built-in Ad Blocking to iOS: Introduced on September 1, Firefox's built-in Ad Blocker on iOS blocks many third-party ads and ad-related trackers, reducing clutter and distractions. It works alongside Enhanced Tracking Protection and can be enabled in the 'Browsing' settings in your Firefox on iOS.

Community Engagement

Advancing Web Security at Dagstuhl: Firefox security experts joined researchers and other browser vendors at the Dagstuhl Seminar on Web Application Security in July, presenting on LLM-assisted vulnerability detection, XSS protections, and web-scale security measurements.

Mozilla Security Research Summit: Mozilla's Security-Engineering University Relationship Framework (SURF) is back. On November 20, 2026, we will host another invitation-only summit at TU Delft in the Netherlands, bringing together Mozilla engineers and academic researchers to explore security and privacy challenges and spark new collaborations. The summit takes place immediately after the ACM Conference on Computer and Communications Security (CCS).

TLS, QUIC, HTTP/3, and Happy Eyeballs: Max Inden gave a guest lecture at TU Dresden on modern networking protocols, covering the technologies behind fast, secure web connections.

Looking Ahead

Firefox users receive the security and privacy improvements highlighted in this newsletter through regular updates. If you haven't tried Firefox yet, download it to experience a fast, secure browser and support Mozilla's mission to keep the web open, safe, healthy, and accessible to everyone.

Thank you to everyone who helps make Firefox and the web more secure and privacy-focused, by reporting bugs, conducting research, contributing code, or sharing feedback.

We look forward to sharing more updates in the Q4 2026 edition.

- The Firefox Security & Privacy Teams

02 Nov 2026 11:00pm GMT

30 Oct 2026

feedPlanet Mozilla

Niko Matsakis: 'Trust but verify'; or, 'the correctness ratchet'

The name of the game in agentic development is figuring out how to clearly tell agents what you want- and then how to be sure they follow through. Lately I've been tinkering with an interesting technique around this that I'd like to share.1 I call it "trust but verify"2.

The basic idea is that sometimes you have things you want to "verify" but they can't really be mechanistically checked. In that case, you let your agent do its best. But you also have it create an evidence file that contains the inputs it drew on to make that decision along with its rationale. Then you gate your CI on checking that these evidence files exist and that the inputs are accurate. Those checks are deterministic and cheap. The rationale itself is natural language and can't be checked.

Doing this "trust but verify" technique on its own is helpful. It creates a kind of hill-climbing towards correctness that is stronger than (e.g.) tests alone. It helps to check meta-reasoning like "is the set of tests sufficient to show this requirement is true". Documenting the input also means that if any input should change, the CI check will start to fail, and the agent will be forced to revalidate its reasoning.

What I find most interesting though is that "trust but verify" can be used to create a kind of correctness ratchet over time. The idea is that, now that the inputs + rationale are documented, you can have other agents come back and double-check that reasoning, even when the inputs have not otherwise changed. As agents naturally improve, or just due to the randomness inherent in how agents work, they will naturally find things the original rationale overlooked, and you'll be able to address them.

When you say "hill climbing towards correctness", what do you mean by "hill-climbing"?

Agents are none too smart, but they can be awfully dogged and persistent. If you ask them to climb a hill, they are going to find a way to do it. The tricky bit of course is that they don't always climb that hill in the way you intended. Also, they may not exactly climb it so much as find a route to the top: they may be persistent, but they are also lazy f!@#kers4, and they love to take shortcuts.

What if the hills are propositions about your program?

The fact that agents are good at climbing hills has got a lot of people in the automated reasoning community5 very excited. After all, what better way could there be to make sure your program does what you expect than to formally prove that it is true? And we've seen that when you set a model loose with a Lean theorem, it can be quite adept at proving things6.

But there are a few caveats…

Myself, I'm quite excited about tools like Lean but also Verus, Aeneas, and Creusot. I think we're going to be using them a lot more. And yet, I also think that proving propositions is not the end of the story.

Who writes those propositions?

Let's start with the obvious problem. An agent may be good at proving a proposition, but who is actually writing it? Even when something can be formalized, doing that formalization is a fair bit of work. Consider this random example of a requirement from a project I am working on7:

A Fleet using Functionality A must be attributed to every Functionality reachable through any number of recorded deprecation steps, while being counted only once when routes converge.

This is part of a project that is analyzing fleets across Amazon and looking at how much DRAM they consume. Our goal is to make sure that every large fleet at Amazon has Rust versions of every library it would need to be rewritten into Rust. We want to be able to go to the maintainers of those libraries and say, "there are fleets accounting for X% of Amazon's total DRAM consumption that use your library; you should make a Rust version".

The point is, while the concept of this DRAM accounting is not complex, formulating it in a precise, mathematical way is not at all trivial. You have to have some notion of transitive closure, talk about the graph of dependencies, etc. There is no way that the lazy, spoiled programmers of the future are going to write a formula like that by hand.

Much more likely is that they are going to give high-level direction to the agent and ask it to connect the dots. After all, this is what agents are good for! And in this case, I would trust an agent to get it right. As I said, it's not really complex, just… tedious.

Can they say what you want?

And of course this leaves aside that there are many things that are just plain hard to formalize. Consider a requirement like, "a warning must be displayed on every relevant form in a prominent fashion". Checking this requirement requires a notion of what is "prominent", which is unlikely to be a mathematical property one can write down. And while I would not trust an agent's judgment over an actual graphic designer, it is also the kind of thing where the agent can likely do a "good enough" job to catch many failures.

And what does it cost to do the proof?

The other point is that while agents are good at authoring proofs, it still takes them tokens - and more importantly, time - to do it. And sometimes quite a bit. If developers have to wait a while for the agent to find a proof to a complex property, that better be worth it. If the property you are proving is key to your system, it probably is. But if the cost of a mistake is less than the cost of a proof, people won't bother, so it's worth thinking about leaner, easier ways to gain confidence.

And what about when you are iterating?

One final point is that applying too much rigor too early in the process can be a real problem. This one is tricky because rigor can surface problems earlier, too. But it's often helpful to start by defining your requirements and things at a higher level and gradually get more precise as you go, tolerating a bit of "looseness" early on when you know there are details you have to nail down, but it's not important to do so yet.8

A key point for me is that just because you haven't formalized your requirement all the way to a mathematical proposition doesn't mean that you've got nothing at all. You can often phrase a high-level version of what you want, perhaps one that is overly simplified. In fact, it's pretty useful to do so, because when you find that your rule doesn't quite work, that helps you figure out how to refine it into the more precise rule you actually want.

Evidence and "trust but verify"

The key idea of the "trust but verify" technique is that leaning on agentic reasoning is good, fine actually. But when you do so, you should have the agent explain itself and also have it lay out what inputs and evidence it used to reach that conclusion. Basically, leave yourself a trail so that you (or another agent…) can come back and audit what decisions were reached and on what basis.

Following this approach helps in two ways:

  1. In the short term, it forces the agent to at least acknowledge your requirement, which generally means they will do a better job at meeting it.
  2. In the long term, it lets you go back and double-check the agent's reasoning, leading to a kind of "correctness ratchet" in which you are generally improving the alignment of "what you have" with "what you asked for".

One example: Habeas Codicem

Probably the simplest example of this "trust but verify" technique is Habeas Codicem. This is a small project I made in part as an experiment. The idea is that you write requirements into your docs and then Habeas Codicem adds a test into your system that can only be passed if an agent has written an explanation of why each of those requirements is satisfied. Those explanations are recorded as evidence files that are committed into your repository along with the code.

The interesting bit about Habeas Codicem is that the evidence files contain not only the agent's rationale and judgement, but also a list of the inputs it used to reach that conclusion. And these inputs have to have certain contents. For example, if you have a function that is labeled as part of the requirement's implementation, or a test that is tied to a requirement, then the agent must include that function or that test in its evidence.

The final part of Habeas is some skills that instruct the agent to always check with you, the human, before editing requirements, and to confirm agreement on requirements before implementing.

Another example: an internal data store

Early in the post I mentioned an internal project I am working on at Amazon to analyze which missing dependencies might block fleets from migrating to Rust. This system involves a lot of agent-driven investigation. For example, perhaps there is a Rust version of a Java library, but it only handles some of the features (this is pretty common). Then we need to know whether the fleet's code cares about those features that aren't included.

My early attempts at gathering this data were pretty crude. I basically just sat there telling Amazon Quick "try harder, make no mistakes". Not great. I didn't really trust the result.

My newer attempts are much more thorough. I ask the agents to produce an evidence record of what data points they looked at and to include a written rationale for how those data points connect. I then test that the data points hold. For example, to determine if the method convertData in some library is called, the agent might register specific lines from .java files showing a call like value.convertData(). Or it might show the results from a grep that show no matches for convertData.

The interesting bit is that while the rationale from the agent can't really be evaluated in an automated fashion, the evidence can be. So before we accept any agent-created conclusion, we run a deterministic checker that ensures the evidence is valid (those lines really do appear where the agent said they would) and then records a receipt that the check was done. So the agent cannot just hallucinate evidence.

What we are asserting: the agent has done work

Habeas Codicem does not prove your code obeys its requirements; nor does my inventory system prove that a given Java feature is used. But it does prove that the agent actually considered the question enough to write out some evidence + a justification. And assuming your agent is not actively malicious, that's actually quite a bit.

One thing that we've seen is that agents often "lie" about what work they did. They'll claim to have carefully read through a document when an examination of their tool invocations shows that they've just looked at a few random bytes.

Tightening and revalidating rationale

One of the ideas I find most interesting in this space is the idea of revalidating rationale. Now that we have evidence files committed to git, we can absolutely have another adversarial agent that periodically pulls up those files and gives them another look. That agent can go looking for holes in the original logic and produce modified and improved proofs or counterexamples. I find this particularly compelling when you think about new and better models that might be more adept at finding holes.

Applying this idea to propositions

I think this technique suggests how we can begin to tackle the problem of converting "high-level requirements" into formal theorems. Instead of expecting humans to write and review logical formulae, we can ask an agent to do the conversion - and to record its thinking process (with verifiable evidence). Then we keep that evidence around and we periodically revisit it, looking for potential edge cases. We wind up with a kind of 'confidence score' - the more reviews that have approved a given "requirement->formula" translation, the more likely it is to be accurate.

The risk of ping-ponging and what it means

That said, I've not really put this into practice yet, and I anticipate it may be tricky to get it working right. People have told me to expect that agents may ping-pong a bit: for example, maybe one of them translates your plain English into logic, and then another says "that translation doesn't look right" and takes a new approach. But then yet another agent reverts that and goes back to the original. This seems very plausible- I suspect it can be resolved by adding enough history to recognize that it actually reflects ambiguity in your original statement, and to surface the problem up to you.

  1. I do not claim this technique is novel. I am quite sure people have been doing variants of it forever. But it's novel to me, and I don't think I've heard people talk about some of the potential long-term implications around "the correctness ratchet". ↩︎

  2. I know this phrase from Reagan, of course, but when I started reading into its background I found it had a more interesting history than I expected. Apparently it is a Russian proverb and was suggested to Reagan as a way to communicate with Gorbachev in familiar idioms. As with "less is more", it's always had that delightfully contradictory feeling ("if you have to verify, are you really trusting?") - and at least the way I interpret it, it's really more like "trust through verification". In other words, I know I can trust you because we've set up the means for me to verify your logic. ↩︎

  3. I had written, "I don't usually curse at computers", but my daughter (reading over my shoulder) told me, "That is not true, you curse at computers all the time". And she's right! But I realized that it feels different. When I am using some restaurant website that seems purposefully designed not to tell me their opening hours or show me a menu, I certainly say "oh f!@#k you!", but in that case, I am actually cursing at the person who designed that website. I am not cursing at the website itself; it's just an inert vessel. In contrast, when I curse at a model, I am not cursing at the people who trained it. I am cursing at the dang model, because it just seems to be going out of its way to be annoying. Anthropomorphizing is a pain. ↩︎

  4. God, agents have gotten me so frustrated lately. I'm not usually prone to cursing when sober3 but more than once lately I've found myself typing, "I have no idea what the f!#! you are talking about". This seems to happen slightly more often with Claude than GPT. Claude really likes to develop a kind of cryptophasic shorthand where it drops random words that I used 3 weeks ago as if that will mean anything to me now. "You still have to handle the first-cut case!" ↩︎

  5. Automated reasoning is the same thing as formal methods, just more appealingly branded. As an aside, lately I've been hearing people talk about Neurosymbolic AI, which I believe is a shameless (and brilliant) way for your SAT solver to jump on the LLM hype train. I suppose it's also a reasonable way to push back against "AI scope creep". While I'm on the topic: it seems to me that John McCarthy's quip ("as soon as it works, no one calls it AI anymore") has been proven false. I would rather people stopped saying "AI" and just said "LLM", but nobody really cares what I want, do they? ↩︎

  6. Even if they aren't actually true. ↩︎

  7. I did not actually write this text, of course, an agent did. It's pretty convoluted. Sigh. ↩︎

  8. This feels reminiscent of Terry Tao's classic post outlining how an experienced mathematician leans on instinct informed by rigor rather than just one or just the other. ↩︎

30 Oct 2026 9:40am GMT