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