The Rust team has published a new point release of Rust, 1.96.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.96.1 is as easy as:

rustup update stable

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

What's in 1.96.1

• Missing retries / timeouts in Cargo's HTTP client
• Miscompilation in a MIR optimization

It also fixes three CVEs affecting libssh2 (which is compiled into Cargo):

• CVE-2025-15661
• CVE-2026-55199
• CVE-2026-55200

Contributors to 1.96.1

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

Mozilla remains committed to maintaining a secure, trustworthy, and transparent Web PKI. Today we are announcing the publication of Mozilla Root Store Policy (MRSP) version 3.1, effective July 1, 2026.

While previous policy updates focused heavily on certificate revocation, automation, and operational resilience, MRSP v3.1 focuses on a different challenge: ensuring that Certification Authority (CA) operations are sufficiently transparent, understandable, and auditable.

Trust in the Web PKI depends not only on technical requirements, but also on the ability of Mozilla, auditors, and the broader community to understand how CA systems are designed, operated, and assessed. MRSP v3.1 introduces new requirements intended to improve the quality of CA documentation and strengthen independent assurance of the design and effectiveness of controls that protect CA systems.

Improving CP/CPS Documentation

Certification Practice Statements (CPSes) and combined Certificate Policy / Certification Practice Statement documents (CP/CPSes) are among the most important public documents published by a CA. They describe how a CA conducts its operations and meets industry requirements.

Over the years, we have seen significant variation in the quality, structure, and level of detail provided in CP/CPS documentation. Some documents provide extensive implementation detail, while others rely heavily on incorporation by reference or provide only high-level descriptions of CA practices.

The revised policy will continue to require conformance with RFC 3647, as modified by applicable CA/Browser Forum requirements. Improvements to section 3.3 in the MRSP will establish clearer expectations regarding the content and quality of CP/CPS documentation. The new requirements emphasize that documentation must be explicit, bounded, auditable, and sufficiently detailed to describe the CA operator’s certificate issuance and management activities, while also establishing requirements for version control, accessibility, and ongoing maintenance. The objective is to ensure that a technically competent reviewer will be better-able to determine what commitments the CA has made, how those commitments are implemented, and whether the documented practices support technical, operational, and performance oversight.

Mozilla believes that these new CP/CPS requirements will improve transparency, reduce misunderstandings, support more effective audits, and help reduce the risk of certificate misissuance by ensuring that operational practices are documented accurately, consistently, and in sufficient detail to permit meaningful review.

Introducing Detailed Controls Reports

A second major enhancement in MRSP v3.1 is the introduction of Detailed Controls Reports (DCRs). Traditional WebTrust and ETSI audit reports provide valuable independent assurance regarding compliance with established criteria. However, they generally provide only limited visibility into the specific controls, testing procedures, and operational environments that support those conclusions.

Beginning with audit periods starting on or after July 1, 2027, CA operators with root certificates enabled for TLS website authentication will be required to obtain a DCR. The purpose of the DCR is to provide CA management, auditors, and Mozilla with greater visibility into the controls, testing, and operating effectiveness of CA systems that support compliance with the CA/Browser Forum’s TLS Baseline Requirements and Network and Certificate System Security Requirements. Mozilla generally expects to review DCRs only on an as-needed basis, such as during compliance reviews, incident investigations, root inclusion evaluations, or other oversight activities.

A DCR must include:

• The scope and boundaries of the audited CA systems;
• Applicable audit criteria;
• Controls implemented by the CA;
• The auditor’s testing procedures;
• Results of control testing; and
• Information regarding control exceptions or deficiencies.

Mozilla expects that DCRs will complement existing audit reports and strengthen transparency and assurance by providing additional detail regarding system boundaries, control implementation, testing procedures, and control effectiveness that is not typically available in traditional audit reports. Effective compliance requires more than documented policies and successful audits; it also requires management understanding, oversight, and engagement. By providing greater visibility into CA systems, controls, testing activities, and operational risks, DCRs can help reinforce a strong tone at the top regarding compliance expectations, support informed decision-making and resource allocation, enable earlier identification of weaknesses, and promote a culture of continuous improvement. The intent is not to replace existing audit reports, but to provide additional information that supports effective governance, oversight, and informed trust decisions.

Additional Clarifications and Improvements

MRSP v3.1 also includes several targeted clarifications and refinements:

• aligns Mozilla’s mass revocation planning requirements with the corresponding CA/Browser Forum Baseline Requirements, helping ensure consistency across compliance frameworks;
• clarifies audit expectations for root inclusion requests, including requirements relating to audit continuity and root key generation ceremonies;
• requires root CA key pairs submitted for inclusion to have been generated within the previous five years, helping ensure that newly included roots are based on contemporary cryptographic practices and controls; and
• clarifies expectations when ownership or operational control of a CA changes, helping ensure that Mozilla receives timely notice and can evaluate the impact of acquisitions or organizational changes on continued compliance.

Looking Forward

Mozilla recognizes that these changes will require preparation by CA operators, auditors, and other ecosystem participants. To support implementation, Mozilla is publishing accompanying wiki guidance regarding both CP/CPS Documentation and Detailed Controls Reports.

As with previous policy updates, these changes were informed by discussions with CA operators, auditors, and members of the Web PKI community. We appreciate the feedback received during the review process and look forward to continued collaboration as the ecosystem evolves.

Mozilla has a longstanding focus on building confidence in the Web PKI through transparency, accountability, and continuous improvement. By requiring higher-quality CP/CPS documentation and strengthening independent assurance, MRSP v3.1 advances Mozilla’s commitment to protecting its users and maintaining their trust in the systems that help secure the web.

The post Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1 appeared first on Mozilla Security Blog.

Welcome back from the Thunderbird development team!

The past few months have been exceptionally busy across the project. As we approach the midpoint of the year, we’ve been focused on a mixture of delivering user-facing features, investing in long-term architectural improvements, and preparing for the next ESR cycle.

A significant amount of effort has gone into modernizing Exchange support, where the team is now approaching Graph API feature parity with our existing EWS implementation. At the same time, progress has continued on the Account Hub, the Global Message Database, and improvements to the add-ons ecosystem that will help extension developers transition toward a more secure and sustainable future.

Behind the scenes, we’ve also continued the less visible but equally important work of maintaining a large application: adapting to upstream platform changes, improving test reliability, addressing long-standing bugs, and supporting the growing community of contributors who help move Thunderbird forward every day.

This month we’d especially like to recognize one of those contributors, Maxe, whose sustained efforts tackling decades-old MIME bugs have been making a meaningful impact across the codebase.

Exchange Email Support

One of the largest efforts underway in Thunderbird continues to be our modernization of Exchange support.

Over the past several months, the team has pushed through multiple Graph API implementation phases and is now entering the final stretch toward feature parity with our existing EWS implementation. At the time of writing, only a small number of remaining email features separate the two implementations, with completion expected imminently.

Reaching this point has involved considerably more than simply implementing new API calls. The work required substantial investment in shared understanding, protocol abstractions, automated code generation, testing frameworks, request batching, synchronization mechanisms, and interoperability between legacy and modern components. Many of these improvements will continue to benefit future protocol work long after Graph support itself is complete.

A notable development came from our ongoing engagement with Microsoft, and following discussions around Graph API permissions, Microsoft confirmed that approved mail clients such as Thunderbird will continue to be able to obtain user consent for permissions that were previously unavailable to third-party applications. This removed a significant long-term uncertainty around Graph support and helps to ensure Thunderbird users can continue connecting Exchange accounts without requiring administrator intervention.

With email functionality nearing completion, the team has already begun planning the next stage of Exchange support, including calendar integration work that will build upon the foundation established over the past year.

Keep track of our Graph API implementation here. 

20+ year old MIME bugs?! – Contributor Spotlight

This month we’d like to highlight Maxe, who has been on an impressive run tackling some of Thunderbird’s oldest and most stubborn MIME issues.

Open source projects often benefit from contributors who quietly and consistently improve areas of the codebase that most people would rather avoid. Over the past several months, Maxe has become one of those contributors for Thunderbird.

What began as a handful of fixes has grown into a sustained effort to tackle some of the oldest MIME-related bugs in our tracker. Many of these issues date back decades, touching parts of the mail stack that have accumulated years of edge cases, historical assumptions, and compatibility quirks.

MIME handling sits at the heart of how Thunderbird interprets messages, attachments, encodings, and content types. While users rarely think about it when everything works correctly, it is often involved when messages display incorrectly, attachments behave unexpectedly, or unusual emails expose long-standing inconsistencies. Fixing these issues requires a deep understanding of both email standards and Thunderbird’s historical behavior.

What has impressed us most is not any single patch, but the consistency. Over the past few months Maxe has continued to identify issues, develop fixes, respond to review feedback, and refine solutions until they work reliably across platforms and message types. Along the way, several fixes have uncovered additional problems and improved behaviour in places that weren’t originally expected.

This kind of work is rarely flashy. It involves patiently navigating decades-old code, reproducing obscure bugs, and developing enough confidence to modify systems that affect virtually every Thunderbird user. Yet these are exactly the sorts of contributions that make open source software better over the long term.

On behalf of the team, thank you Maxe for the energy, persistence, and technical skill you’ve brought to Thunderbird this year. Your work is making a real difference.

Add-ons, Extensions and Ecosystem

The add-ons ecosystem remains an important part of Thunderbird, and over the last few months we’ve continued working toward a safer and more maintainable extension platform.

One significant decision was the postponement of experiment deprecation on the Monthly Release channel for an additional year. Feedback from extension developers made it clear that many maintainers needed more time to migrate away from legacy experiment APIs, and we want to ensure that transition is successful rather than disruptive.

This extra time allows us to focus on expanding official WebExtension APIs, improve migration paths, and work directly with extension developers to understand their priorities. To support this effort, we’re preparing a broader outreach initiative later this year that will gather feedback from experiment maintainers and help guide future API development.

A great deal of this work has been driven by John, who has been balancing ecosystem improvements alongside onboarding new team members and supporting several other strategic projects. Ensuring that extension developers have a sustainable path forward remains a key investment area for Thunderbird.

Authentication and OAuth

Over the past several months we’ve continued modernizing Thunderbird’s authentication experience, with a particular focus on OAuth and account setup.

One of the most visible improvements has been the continued rollout of browser-based OAuth flows. Instead of embedding authentication within Thunderbird itself, users can now complete sign-in using their system browser, providing a more familiar experience while benefiting from the security features and account state already present in their preferred browser.

As we expanded support for these flows, we also uncovered an interesting interoperability challenge. RFC 8252, the standard commonly used by native applications, recommends the use of loopback redirects with dynamically assigned local ports. While most providers support this approach correctly, several major providers have historically handled these redirects differently. As a result, we’ve been working directly with providers including Yahoo!/AOL, Comcast/Xfinity, and Yandex/Mail.ru to improve compatibility and ensure Thunderbird users continue to enjoy a smooth sign-in experience as authentication requirements evolve.

We’ve also been simplifying account setup for users of Thunderbird’s growing ecosystem of services. Recent work allows users to launch authentication for a Thundermail account directly from Thunderbird without first manually entering account details. This significantly streamlines onboarding and lays the groundwork for similar experiences with other major providers in the future.

Another important addition has been the introduction of a Thunderbird-specific protocol handler. This enables web-based account dashboards, management interfaces, and enterprise deployment tools to communicate directly with Thunderbird and complete account configuration automatically. For Thundermail users, this creates a much smoother path from account creation to a fully configured desktop client. Looking ahead, the same technology opens the door to deeper integration opportunities for enterprise deployments and other hosted services.

While much of this work happens behind the scenes, it represents an important investment in making account setup faster, more reliable, and more secure for both individual users and organizations deploying Thunderbird at scale.

Panorama – Global Message Database

Behind the scenes, work continues on one of Thunderbird’s most ambitious long-term architectural projects: the Global Message Database.

Recent months have focused on strengthening the foundations needed to connect Panorama’s user experience with the underlying storage architecture. Geoff has resumed significant front-end work following ESR-related priorities, while Brendan has joined the project to help accelerate development and planning efforts. At the same time, Ben has been refactoring portions of the IMAP codebase to establish cleaner interfaces that will simplify integration with the new database architecture.

While much of this work remains infrastructural and therefore less visible to users today, it represents important progress toward a more modern foundation capable of supporting future performance, search, and organizational improvements throughout Thunderbird.

Maintenance, Upstream adaptations, Recent Features and Fixes

While major features tend to attract the most attention, a significant portion of Thunderbird’s engineering effort continues to be devoted to maintenance and adaptation work required to keep pace with our upstream platform.

This period is traditionally one of the busiest times of the ESR cycle. As Firefox prepares its next ESR release, large volumes of platform changes land in a relatively short period of time. While these improvements benefit Thunderbird in the long term, they can also introduce unexpected regressions, styling inconsistencies, test failures, and compatibility issues that require immediate attention.

One particularly notable example has been Mozilla’s ongoing Nova initiative, which introduces substantial visual and styling changes throughout Firefox. Without intervention, many of these changes would create inconsistencies across Thunderbird’s user experience. Richard (Paenglab) has done exceptional work identifying, triaging, and adapting these upstream changes to ensure Thunderbird continues to present a coherent and polished interface. Much of this work goes unnoticed when done well, which is perhaps the highest compliment for maintenance engineering.

Alongside these adaptation efforts, the team and contributor community have continued landing a steady stream of reliability, stability, and usability improvements across the application. Recent highlights include:

• Improvements to threaded message handling and sorting behaviour.
• Fixes for long-standing IMAP synchronization and data integrity issues.
• Improvements to POP3 reliability, including protections against queue deadlocks.
• Multi-monitor and mixed-DPI fixes for mail notifications.
• Continued migration work to Fluent as part of our localization modernization efforts.
• and many more which are listed in release notes for beta.

If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.

—

Toby Pilling

Senior Manager, Desktop Engineering

The post Thunderbird Monthly Development Digest: June 2026 appeared first on The Thunderbird Blog.

This is another post in our series covering what we learned through the Vision Doc process. We previously described the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

Learning to work with the borrow checker

The compiler as teacher

Learning by doing

Letting go of "clone guilt"

Multi-paradigm, but not the OOP some are used to

Teaching Rust in academia

Learning using LLMs

Organizational considerations for Rust learners

Silent attrition

Feedback on near-bounces from survey

Need more focused work on silent attritrion

Conclusions

What seems worth trying

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

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

Foundation

• Rust Foundation Welcomes OpenAI As Platinum Member
• Rust Commercial Network Launches to Unite Commercial Users of Rust
• Mainmatter Is Bringing Hands-On Rust Training

Newsletters

• The Embedded Rustacean Issue #74

Project/Tooling Updates

• Bevy 0.19
• Rust PNG crate gets even faster, used by GNOME and Chromium
• kache 0.7.0: caching real-world C/C++ trees
• New Feature in GuardianDB: Introducing the ODM (Object Document Mapper) Layer
• Safe SIMD in Rust, even on the inside
• Ratatui 0.30.2 is released - a Rust library for cooking up terminal user interfaces
• Adding a post-quantum hybrid handshake to a Rust VPN
• From Julia to Rust: a differentiable tensor stack for scientific computing in the agentic AI era
• hotpath-rs 0.18: Profiling Async and Concurrent Rust - Channels and Lock Contention

Observations/Thoughts

• How we found a bug in the hyper HTTP library
• ClickHouse with Alexey Milovidov and Austin Bonander
• Deep dive into iroh: A replacement for WireGuard or a peer-to-peer layer for your application?
• Optimizing #[sqlx::test] rebuild time
• Rewriting the world in Rust

Rust Walkthroughs

• Migrating LiteLLM to Rust - Building the Fastest and Litest AI Gateway
• Safe SIMD in Rust, even on the inside
• Learn Rust Async/Await, Tokio, and TCP Networking by Building an HTTP/1.1 Server
• Building Breakout in Bevy: Step by Step
• Porting 300,000 Lines of C++ and Perl to Rust: A Dual-Oracle Media Metadata Engine
• A data race that doesn't compile
• [video] RustCurious lesson 9: Traits are Interfaces
• [Video] BAML: a new programming language (created in Rust)
• [Video] The Future of Version Control
• [Video] Borrowing Beauty: My Beginner's Quest to Create Approachable Bevy & Rust Code

Crate of the Week

This week's crate is cargo-rdme, a cargo command to create your README from your crate’s documentation.

Thanks to Diogo Sousa for the 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.

• AimDB - Non-blocking fallible try_produce for bounded / non-overwriting buffers
• AimDB - Add minimal example: hello-mailbox-async

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

515 pull requests were merged in the last week

Compiler

• implement #[diagnostic::on_unknown] for modules
• outline part of evaluate_goal_raw into its own #[cold] function
• preserve track_caller for by-value dyn vtable shims

Library

• add io::Read::read_le and io::Read::read_be
• constify TryFrom<Vec> for array
• impl [const] Default for BTreeMap
• stabilize str_from_utf16_endian
• stabilize strip_circumfix
• stabilize substr_range and subslice_range

Cargo

• diag: Support build.warnings for cargo lints
• add: list too-new versions and how to override
• host-config: dont apply target config to host artifacts
• install: Run cargo lints like rustc lints
• resolver: hint how to resolve too-new versions
• test: skip dwp uplift test without packed debuginfo
• add Solaris fcntl file locking
• -Zmin-publish-age (RFC #3923)
• improved the test error messages when 'rustc -V' fails
• remove windows-sys dependencies older than 0.61

Clippy

• add lint to suggest as_chunks over chunks_exact with constant
• new unnecessary_unwrap_unchecked: lint
• extra_unused_type_parameters: don't suggest an autofix
• let_underscore_future: skip bindings with an explicit type annotation
• avoid ICE when evaluating constants containing unsized type args
• avoid map_unwrap_or fix when default is adjusted
• do not check for unused lifetimes in expanded code
• don't trigger unnecessary_box_returns when the size depends on generics
• find a shared context for the format string and the format! call
• fix OOM panic for large types on uninit check
• fix std_instead_of_core: false positives for core::io/MSRV
• manual_slice_fill detect for in loops over &mut [T; N] slices
• merge comment and cfg checking in matches lint pass
• perf: check the method name first in or_fun_call
• perf: compare method names before type queries in three lint passes
• perf: run structural checks before const context queries in question_mark, manual_clamp and ranges
• perf: skip match_same_arms work when the lint is allowed
• perf: skip tokenizing in span_contains_cfg when no '#' is present
• treat ! the same as - in unnecessary_cast

Rust-Analyzer

• assists/replace_match_with_if_let: don't parenthesize if-let guards
• implements_trait_unique_with_infcx: only forbid the self type from being an error type
• bye bye ted
• do not visit nodes in GC multiple times
• MIR eval mixed bit and byte sizes
• check for #[cfg]s in tail expression macros
• crash on static constants in array length positions
• don't complete .await on receivers of unknown type
• don't panic on out-of-range integer literals in const positions
• migrate merge imports to editor

Rust Compiler Performance Triage

This week had a lot of big swings, with two significant perf regressions that are accepted because they unlock future features and perf improvements. We also saw large improvements in the next trait solver due to the performance optimization work happening there.

Triage done by @JonathanBrouwer with help from @Kobzol. Revision range: b5d46ecb..8b6558a0

Summary:

5 Regressions, 3 Improvements, 2 Mixed; 4 of them in rollups 30 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:

• No RFCs were approved 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

• rustc_lint: Allow scoped non_ascii_idents lint levels
• Stabilize #[my_macro] mod foo; (part of proc_macro_hygiene)
• Implement IntoIterator for [&[mut]] Box<[T; N], A>
• Tracking Issue for string_from_utf8_lossy_owned
• Infer all anonymous lifetimes in assoc consts as 'static
• consider subtyping when checking if an infer var is sized
• remove box_patterns
• enable eager param_env norm in new solver
• Lint against iterator functions that panic when N is zero

• Start a t-project-structure/t-comprehensibility

No Items entered Final Comment Period this week for Cargo, Compiler Team (MCPs only), Language Reference, Language Team, Rust RFCs 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

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-06-24 - 2026-07-22 🦀

Virtual

• 2026-06-25 | Virtual (Girona, ES) | Rust Girona
  • Rust Girona Weekly Session
• 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-07-02 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-02 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Learning Game Development the Hard Way with Rust and Bevy
• 2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-04 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-07-07 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
  • July 2026 Rustacean Meetup

Europe

• 2026-06-24 | Manchester, UK | Rust Manchester
  • Rust Manchester June Talks
• 2026-06-24 | Trondheim, NO | Rust Trondheim
  • The Chaos of Time and Time Intervals
• 2026-06-25 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-25 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #69
• 2026-06-25 | Toulouse, FR | Rust Toulouse
  • Rust Toulouse Meetup - Bevy & ESP32
• 2026-06-27 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #27
• 2026-07-02 | Edinburgh, UK | Rust and Friends
  • Bevy, Bits, & Cats (Rust July Talks)
• 2026-07-02 | Enschede, NL | Baseflow Tech Meetups
  • AI Summit
• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 262
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva

North America

• 2026-06-24 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies
• 2026-06-25 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-06-25 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-06-26 | New York, NY, US | Rust NYC
  • Rust NYC's Big Summer Social
• 2026-06-27 | Boston, MA, US | Boston Rust Meetup
  • Somerville Union Square Rust Lunch, June 27
• 2026-07-02 | Saint Louis, MO, US | STL Rust
  • Git is easy?
• 2026-07-04 | Boston, MA, US | Boston Rust Meetup
  • Boston University Rust Lunch, July 4
• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
  • MIT Rust Lunch, July 11
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
  • North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!

Oceania

• 2026-06-25 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne June 2026
• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup

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

I think this is the wrong decision, and I wish the lang team had stabilized the Late type instead. Better Late than Never.

– /u/CouteauBleu on /r/rust

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Earlier this month, we officially stood up Mozilla.org: a new 501(c)(3) nonprofit created to steward the long term success of the Mozilla Project. 

Over the last year or so, I’ve said a lot about how AI is reshaping the web — and how we need to simultaneously stand up for the open internet Mozilla helped build and shape what the internet is becoming in the AI era. This is a huge and urgent challenge.

Mozilla has evolved and grown a great deal in order to step up to this challenge. 

We are still a high impact philanthropic foundation and a browser company focused on user choice. But we are also: an email company built around privacy; an open source AI startup focused on developers; a place for people to create and share data on their own terms; and an investor in responsible tech startups. 

These are all pieces of Mozilla today, and are all important levers as we try to shape where the internet is headed for the better. 

We have created Mozilla.org to pull all of the different pieces of Mozilla together. It will act like a strategic endowment — allocating funding, managing our brands and shaping long term strategy — to ensure every part of Mozilla is well set up to advance the vision outlined in the Mozilla Manifesto. And, if we’re successful, it will help all of the pieces of Mozilla add up to more than the sum of their parts.

This is an important milestone for Mozilla. The challenge of fusing the values of the Mozilla Manifesto into this next era of the internet is huge. This updated structure will make it easier to nimbly direct our resources and orchestrate our actions to step up to this challenge. 

At the same time, what we love about Mozilla stays the same. All of Mozilla’s organizations remain under the umbrella of the 501(c)(3) Mozilla Foundation, with the new non-profit operating the Mozilla portfolio of organizations on its behalf. Our mission — and our commitment to nonprofit ownership at the top — remain steadfast. 

For more information on the new Mozilla.org non profit including an FAQ, see wiki.mozilla.org/mozilla_org

The post The web is evolving. So are we. appeared first on The Mozilla Blog.

Over the past several weeks, we have been welcoming early users from our waitlist into Thundermail, a few waves at a time. Many of you are now setting up your accounts, trying things out, and sharing your thoughts with us.

Naming updates

You may have noticed that we are now saying Thundermail more often, and Thunderbird Pro less.

Thunderbird Pro started as the name for our subscription services, including Thundermail, Appointment, and Send. But early feedback made two things clear: people cared most about Thundermail, and “Pro” created confusion about whether Thunderbird itself was becoming a paid or limited product.

So, to clarify things, Thunderbird Pro is now simply Thundermail: the email service from Thunderbird, with features like Appointment and Send included.

The Thunderbird Desktop and Mobile apps remain exactly what they are today: powerful, compatible with any email service, and free.

What we learned so far

Every day, members of our team are reading through your survey responses, your messages in the Thundermail Early Bird community chat, your support requests, and every new idea and vote on the board. We discuss what we are hearing, and we sort it into what we can address right away and what we want to plan for. Then we keep working in the open, where you can see what we are up to and tell us when something is not quite right.

Here are some of the things we’ve learned so far:

• Custom domains matter a lot. Many called this out directly, along with support for unlimited custom domain aliases. Several responses said these features stood out compared to other email providers.
• Multi-factor Authentication saw a lot of requests on the ideas board, and we listened. This is now in progress and will be available soon.
• Users appreciate that Thundermail is open and works with any email app. It has always been our intention to stick to open standards so Thundermail stays easy and open to use with Thunderbird or any other app. 
• A bit of surprise that calendar and contacts are included. Apparently we should probably talk about that more.
• DNSSEC and DANE support picked up a lot of votes and is now on the roadmap.
• Requests for more pricing tiers and plans were frequently mentioned, which we will be adding once Thundermail is out of beta and open to the general public.
  • https://ideas.tb.pro/p/additional-pricing-tiers
  • https://ideas.tb.pro/p/a-la-carte-pricing

However, there was one request which came through louder than any other…

Webmail

Webmail was, by a wide margin, the most requested idea from our community, and whereas we had it in the plans for down the road, many people expected this to be a feature available from day one.

We moved webmail to the top of the list, shifted resources into the work behind it and we are excited to share that an early alpha version of it is coming next month. As with most early releases, it will have some rough edges, but will also allow for a much more interactive user experience for our beta testers. Everyone will have a vote in how it’s shaped for the future.

A look at what is coming next

• Webmail! Arriving soon.
• Two factor authentication is now in progress.
• More reliable email, as we keep fine tuning things behind the scenes, training global mail servers and spam filters.
• Onboarding improvements for a smoother first time sign-up flow.

Send and Appointment

Our scheduling and secure file sharing tools are still here, and they are still part of your subscription. Our main focus right now is Thundermail and webmail, but we are continuing to care for both with steady improvements along the way.

• Send: Improved Thundermail integration, providing end-to-end encrypted file attachments without the need for a separate add-on. Users on our Daily version can already test this feature today.
• Appointment: Streamlined the sign up flow, added an easy one click connection with the Thundermail calendar, and refreshed the calendar view design.

We’re looking for more ideas

If you are an Early Bird, we would love for you to visit our ideas board to share your suggestions and vote on the ones you would most like to see. We really do read every single one.

And if you have not been invited yet, you can join the waitlist. More waves are going out soon, and we are looking forward to welcoming you onboard.

Thank you for helping us build Thundermail.

The post Thundermail June 2026 update: what we learned after the first few waves of invites appeared first on The Thunderbird Blog.

If you’ve been running into endless CAPTCHAS or website login requests lately, you’re not imagining things. 

Websites, facing a rising tide of abusive traffic from bots, are adopting increasingly aggressive countermeasures, damaging user’s experience of the web, their privacy and open access to the web.   

In this post, we’ll talk about a new initiative we’re launching with Cloudflare, other web browsers, and web stakeholders to address this challenge while keeping the web anonymous by default.

Privacy and access in tension

The fight for privacy on the web has made real progress. Browsers that put privacy first are eliminating third-party cookies, restricting fingerprinting, and hiding IP addresses, pushing back against the trackers.

But every step forward has come with a cost.

Users are seeing more CAPTCHAs, more demands to log in, and more outright block pages than ever before. Building privacy into the browser means dismantling the passive signals, like IP addresses and browser fingerprints that are used to profile users, but are also relied on by anti-abuse systems. 

At the same time, sites are facing large increases in bot traffic. The response from websites is understandable; volumetric abuse like credential stuffing and spam can do real damage. But the result is a lose-lose: users face mounting friction and reduced privacy, while sites drive away the legitimate visitors they wanted to serve.

If nothing changes, users will increasingly be forced to choose between their privacy and their access to the web. 

Proposals have been made to tackle this dilemma, by asking users to prove to sites that their devices and software are ‘trusted’. These proposals, such as Web Environment Integrity (WEI), transfer control of devices away from users and to a small handful of operating system and hardware vendors. This deprives users of choice and control and gives those gatekeepers control over which devices and software can access the web, the opposite of the open web, which Mozilla is working to protect.   

Finding a better way forward

We think there’s a better way forward. It starts from a simple observation: bots cause harm because they operate at scale. To stop that kind of abuse, a site doesn’t need to know who you are, or that your device is restricted to running approved software. It only needs to know whether you’re staying within a reasonable rate limit.

To make a rate limit work, it must be hard for attackers to create new identities and reset their allowance. That’s one reason why sites demand an email address, a federated login or a device fingerprint: obtaining a new one is just costly enough to make the rate limit stick. The challenge is whether we can make rate limits work, without giving sites access to hard-to-change identifiers that also enable tracking. 

Some sites naturally have a relationship with their users, like a subscription or a long-standing account. What if one of those existing relationships could quietly vouch for you elsewhere, so a site you’ve never visited could trust that you’re a real person within its limits, without learning who you are or even where the vouch came from?

For example, consider a VPN service. Many websites block VPN traffic entirely due to the high rates of abusive traffic blended with legitimate traffic. What if a VPN service could vouch for each of its subscribers? This would let sites manage a per-subscriber rate limit, meaning users get fewer roadblocks and sites get more of the legitimate traffic they want. Of course, this requires that the vouching system doesn’t enable sites to track VPN users, which would otherwise defeat the very purpose of using the VPN. 

Enabling this kind of privacy-preserving vouching is already possible in a limited sense. Apple’s Private Access Tokens, built on a cryptographic protocol called Privacy Pass, let  Apple devices receive single use tokens they can later present to websites without those visits being linked together. 

However, Private Access Tokens have some critical shortcomings. First, like WEI, they rely on device attestation, the very hardware gatekeeping we are determined to avoid. Second, there’s no easy way to open up the system to let more parties vouch for users without compromising on user privacy, which means concentrating control in the hands of a few. To keep the web open, we need a system where any site can vouch for users, and where other sites can decide who they trust to vouch for users responsibly.

This is a much harder problem, but we think the cryptographic foundations exist to deliver it. Anonymous credentials let one party issue you a credential that you can later present to a site a limited number of times, whilst preventing sites and issuers from tracking its use. It’s even possible to hide which party issued it, proving only that it came from a set of trusted issuers. 

A fix is both essential and possible

Building this into a system for the open web, where any site could vouch and any site could set its own limits is challenging, but we believe it’s both possible and essential in order to defuse the tension between privacy and access, while avoiding centralising control in a small number of gatekeepers.

Working with other web stakeholders, including Cloudflare and other browsers, we’ve started designing such a system. For a deeper dive, read our post on Hacks, which goes into more detail about the problem space and the approach we’re working on. 

Our goal is simple: fewer CAPTCHAs, fewer unnecessary blocks and fewer demands to identify yourself, without compromising on privacy. This is the kind of web that Mozilla built Firefox to offer: easy to use, private and open to all. 

The post Keeping the web open and private in the bot era appeared first on The Mozilla Blog.

This is the technical companion to our update on Distilled, “Keeping the web open and private in the bot era.” Here we take a deeper look at the problem space, the design we’re proposing, and the problems still left to solve.

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

Two years ago, the Digital Markets Act was the first of its kind: an ex ante competition framework introducing contestability and supporting innovation. But, as much as its critics try to cast it as a European experiment, it was never alone. In 2019, expert reports across the US, EU, UK and elsewhere studied the competitive dynamics of digital platforms. Today, the conversation has moved on to how to restore competition and choice within digital markets.

That shift was on display at Mozilla’s event in Brussels on 2 June, “Rebalancing Digital Markets: Delivering Competition, Choice, and the Road Ahead.” Regulators and policymakers from the EU, UK, Japan, and Brazil came together to assess what two years of reform have delivered and what still needs to happen. The answer was clearer than expected: ex ante competition regulation works, but only where it has been properly enforced.

The proof of concept holds

The DMA’s browser choice screen obligations have produced real, measurable results. We have written about the data in detail. The headline numbers: Firefox has been selected via a DMA choice screen over six million times in two years, once every ten seconds. Daily active users in the EU have grown to double those in comparable countries. People who choose Firefox through a choice screen are five times more likely to stick with it than those who arrive organically. The core finding is simple: this is what competition looks like when it is allowed to work. When users are given a genuine, well-designed choice, they take it. That was not a given. Earlier choice screens resulting from ex post antitrust processes produced no measurable impact. What changed was rigour and enforcement: working with behavioural economists, testing interfaces carefully, focusing on outcomes rather than checkbox compliance.

The lesson extends well beyond browsers. Desktop remains largely untouched, leaving roughly 310 million desktops and laptops in the EU without an equivalent level of browser choice. Windows users are still frequently steered towards Microsoft’s own services through design choices that override user choice or make switching more difficult than it should be. Ensuring that users of all gatekeeper services can easily change default settings, free from manipulative practices or undue influence, remains a critical test for DMA implementation. Choice screens can help, but they are not a silver bullet. Ecosystem lock-in, interoperability barriers and entrenched defaults continue to limit competition and innovation. The window to address these issues before new forms of digital gatekeeping become entrenched remains open, but it will not stay open indefinitely.

Reform is going global and fast

The institutional approaches across jurisdictions may differ, but the direction of travel is increasingly similar. Policymakers are recognising the need to address concentrated power in digital markets, expand user choice, and create conditions for competition and innovation to flourish.

The UK has opted for a flexible, case-by-case model and has already designated Google and Apple in respect of their mobile platforms. Japan scoped its legislation tightly to mobile, moved quickly, and is now seeking to ensure effective compliance for Japanese smartphone users. Brazil is building a framework calibrated to its own market realities.

None of these jurisdictions is simply copying the EU’s DMA. All of them are drawing on their experience and developing ex ante frameworks that work for their people and their economies: what a good choice screen looks like in practice, what regulatory capacity is needed before a law enters into force, and what happens when the large tech companies seek to undermine rather than facilitate choice and competition.

What the momentum demands

The consistent lesson is unglamorous: the staff, expertise, and industry relationships needed to enforce these rules have to be built before the law arrives, not after.

A clearer consensus is also forming around what enforcement needs to deliver. Rules that look good on paper but do not change what users experience every day are not enough. Technical expertise matters, particularly as AI raises questions that economists and lawyers alone cannot answer. The European Commission’s ongoing proceedings in AI distribution are a test of exactly this: whether regulators can move fast enough to ensure competing AI services are able to reach users before vertical integration entrenches dominance. And regulators need to be clear-eyed about a pattern that has emerged across jurisdictions: gatekeepers framing incomplete compliance as a deliberate policy choice, rather than acknowledging it as a failure to meet their obligations.

These are sophisticated companies, and they will keep testing what regulators will accept. The measure of this generation of digital market frameworks is not whether they passed through legislatures, but whether they can deliver real impact for people.

For Mozilla, that means ensuring the lessons travel: to desktop, to AI, and to every jurisdiction building its own version of these rules. Competition, choice, and true innovation in digital markets should be the norm, not the exception.

The post Building Competitive Digital Markets: From Rules to Results appeared first on Open Policy & Advocacy.

Highlights

• Dao added a new Eyedropper quick action! Check it out by typing “color” or “eyedropper” in the URL bar (Bug 1803575) on Nightly.

• Henrik Skupin released geckodriver 0.37.0, which includes support for several new APIs and various bug fixes. See the release page for details.
• Starting from Firefox 153, access to local file: URLs is being restricted by default.
  • Extensions now require an explicit “Access local files on your computer” permission, separate from broad host permissions, that users must grant.
  • Extensions can call the extension.isAllowedFileSchemeAccess() API to determine whether they have been granted access to file: URLs (Bug 2034168).

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• :Vincent
• Chris Vander Linden
• DrSeed
• Khalid AlHaddad
• Sam Johnson

New contributors (🌟 = first patch)

• Francis :mckenfra: tld service for webextensions
• any1here: about:preferences#privacy is broken with MOZ_DATA_REPORTING false
• pullmana8: Fix protocol/Actor.js to throw an Error instead of an Actor
• RAN1: Firefox Crashes on Quit When Running Two Browsers With Separate Profiles

Project Updates

Accessibility

• Morgan added a new accessibility-specific, front-end review skill to mozilla central! 🎉 You can read about it, and learn how to use it in the accessibility review source docs.

Add-ons / Web Extensions

Addon Manager & about:addons

• Migrated addon-page-header and addon-card action buttons to the reusable moz-button web component as part of the ongoing Nova restyling of about:addons – Bug 2042200 / Bug 2042204
• Extended moz-page-nav-button with a forwarded title property to fix an accessibility issue where the component lacked a label in collapsed state; Landed in Firefox 153, and uplifted to Firefox 152 for about:settings which was already riding the 152 release train – Bug 2040971
• Fixed a shutdown-timing bug where a pending GMP update-check timer could fire after XPCOMShutdownThreads started, causing a pref write assertion; Fixed in Firefox 153 – Bug 2043803

WebExtensions Framework

• Fixed MV2 content scripts incorrectly injecting into guarded hosts because MozDocumentMatcher::MatchesURI was not consulting CheckGuarded when mCheckPermissions was false; Fixed in Firefox 153 – Bug 2041393
• Added support for accessing ObservableArray attributes (such as adoptedStyleSheets) from XrayWrappers and extension content scripts, unblocking extensions that rely on this Web API; Fixed in Firefox 153 – Bug 1751346
• Wired runtime_blocked_hosts and runtime_allowed_hosts enterprise policy settings through ExtensionSettings to allow administrators to restrict extension host permissions on managed devices, starting in Firefox 153 – Bug 1805205
  • Thanks to Mike Kaply for implementing this enterprise policy enhancement.

WebExtension APIs

• Fixed promiseTabWhenReady blocking indefinitely on discarded tabs, preventing cleanup of associated resources and potentially causing memory leaks; Fixed in Firefox 153 – Bug 1653876
• Fixed webNavigation.onCommitted being dispatched twice for cross-origin iframes loaded under Fission, caused by a redundant OnStateChange trigger firing in addition to OnLocationChange; Fixed in Firefox 153 – Bug 1750196

DevTools

• Chris Vander Linden made the Search input component shared as we plan to use it in the Netmonitor as well (#2019260, #2027580, #2027582)
• pullmana8 improved error management in the DevTools protocol (#2031735)
• Chris H-C :chutten removed Legacy Telemetry devtools instrumentation (#2039650)
• :glob ✱ fixed an issue in the Inspector where the swatch color for variable in @starting-style rule could have the wrong color (#2016778)
• Nicolas Chevobbe [:nchevobbe] exposed heading level more clearly in the accessibility tree (#1588784) and in the accessibility highlighter (#2044904)

• Julian Descottes [:jdescottes] migrated the markup view to HTML (from XHTML) to fix an issue when editing the markup (CodeMirror 6 does not support XHTML) (#2028058)
• Nicolas Chevobbe [:nchevobbe] fixed an issue in Netmonitor search where it could appear the the search stalled (#2042405)
• Hubert Boma Manilla (:bomsy) added more connection information (ECH, Delegated Credentials, OCSP, Private DNS, …) in Netmonitor Security tab (#2036404)

WebDriver

• Khalid AlHaddad improved the window manipulation commands in Marionette and WebDriver BiDi to allow individual window geometry properties, such as x, y, width, and height, to be adjusted independently.
• Khalid AlHaddad updated our codebase to use constants instead of hardcoded strings for all our session data types.
• Alexandra Borovova updated the “emulation.setLocaleOverride” command to also apply a locale emulation in dedicated and shared workers.
• Alexandra Borovova fixed a regression when there would be no “script.realmCreated” events after the cross-origin navigation.

Search and Urlbar

• Dharma updated context search actions to trigger search instead of entering search mode @ 1945080
• Daisuke and Drew worked on a lot of Nova updates, including ensuring Nova is tested @ 2041255, 2030183, 2019168, 2044849, 2033583
• Moritz has worked on several refactorings to allow the urlbar to be used in content @ 2039828, 2039298, 2041280
• Middle click paste replaces content was fixed by Moritz @ 2042893
• Michel added feature to show registrable domain on desktop after its implementation on mobile @ 1986161

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

Project/Tooling Updates

• cuTile Rust - Fearless Concurrency on the GPU, memory-safe, data-race-free GPU kernels, B200 benchmarks
• Iroh 1.0 - Dial Keys, not IPs
• Diplomat - Multi-language FFI for Rust libraries
• I built EVM from scratch. Again.
• processkit 1.0 - async process tree management
• litchee: Rust Lichess API client
• Basin - Numerical Optimization in Rust
• Carboxyl 0.1.0-rc - A servo-based browser for the terminal
• kache 0.6.0 - a shareable Rust + C/C++ build cache
• numax v0.1.0 - first stable release of the numax distributed WASM runtime
• ZamSync - offline-first Rust sync engine
• Ktav - a quote-free config format

Observations/Thoughts

• zlib-rs in Firefox
• Rust Prevents Data Races, Not Race Conditions
• Build your project Zig-style
• How memory safety CVEs differ between Rust and C/C++
• Why stdx is not on crates.io
• [videos] RustWeek 2026 by RustNL, all talks playlist
• The iPad was on Tailscale

Rust Walkthroughs

• Learn Rust Concurrency By Building a Thread Pool
• There Is Life Before Main in Rust
• Async Task Locals From Scratch
• Fearless Embedded Rust: Driving a Lego Car with a Pico W
• Building a provider-agnostic LLM layer in Rust with Rig

Miscellaneous

• [video] RustWeek 2026 talk recordings

Crate of the Week

This week's crate is marser, a parser combinator library with a twist.

Thanks to Arne Code for the 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.

• solana-infra-doctor - List exit codes in sol-doctor --help
• solana-infra-doctor - Make the invalid-URL error suggest the expected scheme
• solana-infra-doctor - Add a glossary of RPC readiness terms
• openslate - add unit tests for slugify() in api/src/notes.rs
• openslate - add integration tests for notes CRUD in api/src/notes.rs
• openslate - add integration tests for auth flow in api/src/users.rs
• openslate - add unit tests for build_fts_query() in api/src/search.rs
• openslate - add integration tests for auth middleware and logout in api/src/auth.rs
• openslate - add integration tests for media endpoints (DB layer) in api/src/media.rs
• openslate - add unit tests for ext_from_mime() and filename_from_url() in api/src/media.rs

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

527 pull requests were merged in the last week

Compiler

• obligations_for_self_ty: skip irrelevant goals (recompute sub_root from stalled_vars)
• codegen_ssa: peel trans. wrappers on scalable vecs
• add a check for impossible predicates to trivial_const
• add unstable loop unrolling hint attributes
• improve polymorphization of raw pointer formatting
• introduce #[diagnostic::on_type_error(message)]
• perf: reuse green-marking's edge walk when promoting a node

Library

• add or_try_* variants for HashMap and BTreeMap Entry APIs
• make BorrowedBuf and BorrowedCursor generic over the data
• replace printables table with unicode_data.rs tables
• stabilize #![feature(box_as_ptr)]
• stabilize core::range::{legacy, RangeFull, RangeTo}
• stabilize int_format_into feature
• stabilize nonzero_from_str_radix
• stabilize feature float_algebraic

Cargo

• trim-paths: emit CARGO_TRIM_PATHS_REMAP for build.rs
• diag: Give diagnostics the same display path behavior as rustc
• diag: Report all errors, in order
• publish: avoid false deadlock when to_confirm is non-empty
• resolver: move yank policy to resolver layer

Rustdoc

• also run lint unused_doc_comments
• cleanup and (micro-)optimize print_where_clause
• correct doctest span for trailing semicolon after item
• don't strip hidden items in AliasedNonLocalStripper
• some more lazy formatting

Rustfmt

• add doc_comment_code_block_small_heuristics, to override use_small_heuristics in doc code
• stabilize hex_literal_case

Clippy

• new by_ref_peekable_peek lint
• add with_capacity_zero lint
• mem_replace_with_default: also emit inside macros
• infallible_destructuring_match: clean-up, split off the suggestion from the main message
• manual_is_variant_and: lint result.ok().is_some_and(f)
• needless_borrow: same-name methods false positive
• unnecessary_lazy_evaluations: handle closure ->
• deprecate the from_iter_instead_of_collect lint
• remove is_integer_const
• do not trigger ref_patterns lint on automatically derived code
• enhance never loop
• add profile-specific configuration for disallowed methods and types
• fix collapsible_match suggests wrongly when match body has no braces
• fix unnecessary_sort_by reverse suggestion using wrong closure parameter name
• fix redundant closure call async false positive
• perf: check is_in_test last in incompatible_msrv
• perf: check the token kind before extracting source in early literal lints
• perf: match expression shape before MSRV check in cloned_ref_to_slice_refs
• perf: skip doc_markdown text collection and word scan when the lint is allowed
• perf: skip single_component_path_imports module walk when nothing to lint

Rust-Analyzer

• create directory for cargo xtask metrics rustc_tests
• don't count C-variadic ... as a parameter for fn pointers
• support flyimport exclude variants
• fix destructuring assignments not introducing moves
• offer inline macro in macro call and proc macro
• prefer bench command when target is bench to avoid cargo run
• supports inline variable in macro
• use package id as argument to --package if package is not unique
• assist inline_type_alias work on ADT definitions
• perf: defer initial workspace flycheck until cache priming completes
• remove docs about removed analysis-bench command
• remove unnecessary feature flags from tests
• use ASCII lowercase for dylib extensions check

Rust Compiler Performance Triage

This week we had quite a lot of changes, a few small regressions that were a bit tough to diagnose, but the week is largely positive, overall. Notably, we got one massive improvement on the next-solver benchmark in #156187, and a nice speedup for incremental in #157781.

Triage done by @panstromek. Revision range: f3ef3bd8..b5d46ecb

Summary:

1 Regression, 4 Improvements, 8 Mixed; 5 of them in rollups 28 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:

• No RFCs were approved 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

• Fix trait method resolution on an adjusted never type
• Tracking Issue for atomic_from_mut
• stabilize never type
• Lint against iterator functions that panic when N is zero

• Single-byte counter support in coverage instrumentation
• Rename the compiler files containing struct diagnostics to diagnostics.rs

• Delegate Project Grants to the Funding team
• Allocate budget to the Funding team

• Named Fn trait parameters

• Structs with no fields or all-ZST fields are ZSTs

No Items entered Final Comment Period this week for Cargo, Language Team 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

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-06-17 - 2026-07-15 🦀

Virtual

• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-06-17 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-18 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-06-23 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: What the heck are monads - and how do we fake them in Rust
• 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-07-02 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-02 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Learning Game Development the Hard Way with Rust and Bevy
• 2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-07-07 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Jiff

Europe

• 2026-06-18 | Aarhus, DK | Rust Aarhus
  • Talk Night at Danske Commodities
• 2026-06-18 | Edinburgh, GB | Rust and Friends
  • Rust and Friends comes to Glasgow! (daytime coffee)
• 2026-06-18 | Edinburgh, GB | Rust and Friends
  • Rust and Friends comes to Glasgow! (evening pub)
• 2026-06-18 | Barcelona, ES | BcnRust
  • 21st BcnRust Meetup
• 2026-06-19 | Dresden, DE | Rust Dresden
  • Second Meetup
• 2026-06-23 | Paris, FR | Rust Paris
  • Rust meetup #86
• 2026-06-23 | Warsaw, PL | Rust Warsaw
  • Rust Warsaw Meetup: June 2026
• 2026-06-24 | Manchester, GB | Rust Manchester
  • Rust Manchester June Talks
• 2026-06-25 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-25 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #69
• 2026-07-02 | Edinburgh, GB | Rust and Friends
  • Bevy, Bits, & Cats (Rust July Talks)
• 2026-07-02 | Enschede, OV, NL | Baseflow Tech Meetups
  • AI Summit
• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 261
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva

North America

• 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • June, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-06-18 | Nashville, TN, US | Music City Rust Developers
  • Community Meetup
• 2026-06-20 | Boston, MA, US | Boston Rust Meetup
  • Northeastern Rust Lunch, June 20
• 2026-06-24 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies
• 2026-06-25 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-06-26 | New York, NY, US | Rust NYC
  • Rust NYC's Big Summer Social
• 2026-06-27 | Boston, MA, US | Boston Rust Meetup
  • Somerville Union Square Rust Lunch, June 27
• 2026-07-02 | Saint Louis, MO, US | STL Rust
  • Git is easy?
• 2026-07-04 | Boston, MA, US | Boston Rust Meetup
  • Boston University Rust Lunch, July 4
• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
  • MIT Rust Lunch, July 11

Oceania

• 2026-06-25 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne June 2026

South America

• 2026-06-18 | Florianópolis, BR | Rust SC
  • Rust Floripa

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

"The never type is named after the date of its stabilization" was a good joke while it lasted.

– Sergey "Shnatsel" Davidoff on /r/rust

Thanks to Dos Moonen for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

WebDriver is a remote control interface that enables introspection and control of user agents. As such, it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional).

This newsletter gives an overview of the work we’ve done as part of the Firefox 152 release cycle.

Contributions

Firefox is an open source project, and we are always happy to receive external code contributions to our WebDriver implementation. We want to give special thanks to everyone who filed issues, bugs and submitted patches.

In Firefox 152, multiple WebDriver bugs were fixed by contributors:

• Khalid AlHaddad extended the webExtension.install command to support installing web extensions enabled in Private Browsing mode.
• Sameem improved the Marionette and WebDriver BiDi screenshot commands to enforce maximum allowed dimensions.
• Amin Amir fixed a bug in browsingContext.sys.mjs where a private field was incorrectly assigned without the # prefix.

WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues for Marionette, or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started!

General

• Improved the Marionette and WebDriver BiDi screenshot commands to enforce maximum allowed dimensions.

WebDriver BiDi

• Extended the webExtension.install command to support installing web extensions in Firefox enabled in Private Browsing mode.
• Improved the browser.setDownloadBehavior command to allow overriding the download target folder before the temporary file is created.
• Fixed network events to only forward in-memory cached JavaScript responses when there is a matching network event collector, avoiding unnecessary data forwarding.

Marionette

• Improved the WebDriver:Navigate and WebDriver:Refresh commands to properly report errors when triggering the navigation fails, instead of silently ignoring them.