17 Sep 2026

feedPlanet Mozilla

The Mozilla Blog: Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support

Today at ALL IN, Canada's largest AI and technology event, Mozilla and Mila announced a new initiative and fresh investment to build an open source AI foundation layer that enables organizations and institutions to own and operate advanced AI systems locally, ensuring full control over their technology and data.

Doubling down on its commitment to open source AI, the Government of Canada announced its support for the initiative. Mila will lead the technical delivery and coordination of the project, while Mozilla contributes technical expertise. It also provided the initial $5 million investment to kick off the project. Hypertec is committing an additional $1 million in first-year funding to accelerate initial Canadian deployments of the open source AI foundation layer on Hypertec hardware.

"Canada has a choice: depend on technologies developed elsewhere, or build more of what we need here at home," said The Honourable Evan Solomon, Minister of Artificial Intelligence and Digital Innovation and Minister responsible for the Federal Economic Development Agency for Southern Ontario. "Open source AI gives Canadian businesses and institutions greater control over their technology and data, while making powerful tools more affordable, accessible, and easier to adapt. By supporting this work, we are strengthening Canada's capacity to build and adopt AI on our own terms."

Mila and Mozilla will lead the work together: Mila drawing on a world-class community of close to 2,000 researchers and professionals, Mozilla as technical partner from industry, bringing 25 years of experience stewarding open infrastructure others build on. Mila and Mozilla are actively engaging new partners, inviting companies, research institutions, funders, governments, and developers to join and support this work.

What's being built

The goal is simple: make owning your AI as easy as renting it. Using open source models was never the hard part. Turning a raw open source model into something a small business, a hospital, a local charity, or a government can run in production - secure, reliable, plugged into everything else - takes an engineering team most organizations and institutions do not have and months they can't spare.

The goal is to offer businesses and organizations a ready-to-use AI package that they can run privately and keep under their own control, rather than having to build a complex system themselves or rely entirely on expensive, pay-per-use proprietary AI services.

For example, a small manufacturer could use the system as a private AI assistant for its employees. It could search the company's manuals, procedures, and past project files; help staff draft reports or answer technical questions; and help its software team write and improve code. Because the system is designed to be able to run locally, the company could do this while keeping its proprietary information and data within its own environment.

That also means lower costs. For the vast majority of everyday business tasks, companies will be able to use open source AI running on open source tools instead of paying a commercial provider every time an employee makes a request. But this requires reducing the technical work and expense involved in putting open source AI into practice.

This initiative was founded to solve that problem, building the free layer that makes owning open source AI easy - the same kind of layer the web was built on. It has two halves: An open standard, published as interface contracts, so any part of the stack can be swapped for a better one. And a working "reference implementation" any organization can install on its own machines or the ones it chooses, running the models and controls it chooses against its own data, with governance and access control built in from the start. The ambition is that with the standards and foundation in place, open source AI can be built anywhere, by anyone.

"Six months ago, we announced our partnership with Mozilla to advance open source and sovereign AI. Today, we are bringing that work to a whole new level," said Valérie Pisano, President and CEO of Mila. "By delivering an open, secure AI foundation layer, we empower organizations, from small businesses to non-profits to governments, to own their technological future so they can run, control, and maintain AI models themselves. At Mila, our research community has always believed that for AI to be trustworthy and accessible, it must be built on open standards that keep control in local hands."

The work already underway

Over the last six months, Mila and Mozilla have been designing the architecture, deciding which open source components belong at each layer, and testing that the whole system works end to end. This investment builds on that progress.

Working alongside Mila and Mozilla, Hypertec will help move the initiative from research and reference implementation to real-world adoption by Canadian businesses and institutions, providing a practical, private, and cost-effective path to deploy AI while maintaining greater control over their data and technology.

"AI is advancing at an extraordinary pace and has the potential to transform our economy and society for the better. Canada has an important role to play in ensuring that AI is developed and adopted responsibly, said Simon Ahdoot, CEO of Hypertec Group. "Hypertec is proud to help turn open source innovation into AI that Canadian organizations can deploy securely and under their own control. This is exactly the kind of partnership between government, research, and Canadian industry needed to realize the full potential of AI."

Why now

Mozilla's State of Open Source AI report found that while 79% of developers adding AI functionality use open models, only 53% of teams ever reach production, stopped by cost, security, integration, and maintenance. This work aims to change that.

"AI today is at a crossroads, where it could be closed and owned by a few, or open and available to every coder, developer, enterprise, and nation," said Mark Surman, President of Mozilla. That's what we're building - an open source AI ecosystem that fits together as seamlessly as the web, and that anyone, anywhere can build on. We're so grateful to Canada for scaling this work, and call on partners across sectors - from enterprises and governments to coders and startups - to join us in building this future."

Within six months, Mozilla and Mila expect to publish working reference implementations for enterprise, government and public-interest use cases. The two-year ambition is bigger: to have solved this problem outright, so that open source AI can be adopted fully and easily, anywhere, by anyone.

The post Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support appeared first on The Mozilla Blog.

17 Sep 2026 7:30pm GMT

Firefox Nightly: High-speed Release Trains – These Weeks in Firefox: Issue 209

Highlights

The multi-context address bar for New Tab displaying various search results

Stylesheet editor within the DevTools JavaScript Debugger pane

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

DevTools

Emulation panel within the DevTools Rules view.

WebDriver

Lint, Docs and Workflow

New Tab Page

"Plus" button located to the right of New Tab shortcuts.

Stocks widget in the New Tab page listing prices for SPY, DIA, ONEQ, and IWM.

Privacy widget in the New Tab page showing how many trackers were blocked across two sites.

Layout variant for the New Tab page, with the Widgets column situated on the left side of the page.

Picture-in-Picture

Search and Urlbar

Nova UI refresh
Suggest
Adaptive autofill
Quick actions
Multi Context Address Bar
Other notable Address Bar fixes
Search
Places

17 Sep 2026 5:14pm GMT

Mozilla Open Policy & Advocacy Blog: Pragmatic principles for more rights-respecting age assurance architectures

This is the second part of a two-part series in which we explore approaches to protecting children online while safeguarding privacy, security and the open web. Part one covers our concerns regarding age gates, and suggests alternative policy proposals that address the root causes of online harms. Part two explores better ways to build age assurance architectures that respect users' rights and autonomy.

Across the world, legislation to introduce age gates and social media bans is proliferating. Many governments are still considering age restrictions a straight-forward and cost-effective tool to achieve their child safety goals. However, evidence is mounting that age assurance mandates pose risks to users' privacy, security, free expression and access to information, threaten the open web and competition, and undermine policymakers' goals: enabling young people to have safe and trustworthy experiences online, while enabling the digital economy to grow.

As we have said before, we believe that blunt tools like social media bans are overly broad, undermine users' rights and do not address the root causes of online harm. Reducing risks to young people online requires a holistic, privacy-first approach to online harms emphasizing enforcement of existing rules, addressing harmful design, and equipping all users with better defaults, more choice and granular controls over their experiences online.

Age gates alone are insufficient to address online harms, but age signals can contribute to more holistic approaches by helping achieve age-appropriate experiences online. Where age assurance obligations are considered as one tool out of many to foster age-appropriate experiences, their potential benefits must be balanced against their negative implications for users' privacy and security, access to services, and the openness of the web.

From the service to the device - taking stock of regulatory models

Implementing age assurance is not a single intervention, but a series of steps. A user's age is first assessed, which can happen through a variety of sources of age information and with varying degrees of accuracy. That signal is secondly shared with the actor responsible for age-appropriate experiences, and thirdly acted upon or enforced by that actor.

Dominant approaches to age assurance obligations focus on online platforms - given that this is where many risks encountered by young people unfold. In practice, this has led to online services - websites or apps - turning to third-party age assurance providers to perform age assurance, whether through biometric age estimation, age inference based on users' behavioral data, ID-based checks, or other methods.

In this model, third-party age assurance companies both assess users' ages and share that signal with the platforms responsible for implementing it. To retain access to social media platforms, messaging services and many other online offerings, users are thus forced to surrender their sensitive personal data to these age brokers, often a different one for each service.

Once in the hands of these providers, peoples' data is at risk of being sold, repurposed or accessed by law enforcement. The recent data breach of a ID and age verification provider that exposed more than 153 million IDs underscores that this is not a theoretical concern, but a significant risk for anyone asked to prove their age online. Rather than being asked to trust companies, some of which have already been exposed for their harmful data practices, people deserve verifiable guarantees that their data is safe and secure.

Emerging regulatory models are considering the role that device intermediaries, like operating systems, device manufacturers, and app stores, can play in age assurance. In such models, these actors are either required to communicate an age signal to the actor responsible for acting on it, or to restrict access to services themselves, based on an age signal created at the device level.

Device intermediary focused approaches, too, come with significant challenges: Given the significant concentration of power among (mobile) operating systems and app stores, such a legislative design can easily further entrench the dominance of Apple and Google, disadvantage open source competitors, and undermine users' privacy and control, including over their devices. These implications must be carefully mitigated.

Principles for better age assurance architectures

Every approach to age assurance comes with important trade-offs, and we maintain that there is no age assurance system that mitigates all risks to users' fundamental rights, access to services, competition and the open web, while being effective in avoiding every instance of under-age access. However, we do believe that better age assurance architectures are possible. In many situations, unverified age signals may be sufficient to provide age -appropriate experiences without undermining fundamental rights. Where stronger assurances are considered necessary, zero knowledge architectures can help protect users' privacy.

Better age assurance architectures must be private, secure, accessible to all users, and, crucially, must provide them with autonomy, choice and control. Designing age assurance obligations that live up to these values is a question of governance, not technology. Hence, policymakers have a crucial role to play in defining requirements for rights-respecting age assurance systems.

1. Assign responsibilities deliberately.

From people's devices, to operating systems, app stores and websites or apps, many actors can be involved in age assurance processes. Some of these actors will be better suited to be responsible for certain steps of age assurance processes than others to avoid negative outcomes for fundamental rights and the open web.

Given that websites and apps know most about their services, their features and content hosted, we argue that they are in the best place to act on age signals to provide age-appropriate experiences. Implementing age signals at this level allows for more granular choices for creating age appropriate experiences. Other actors, like network operators or device vendors, simply do not have the necessary information.

While websites or apps are best placed to create age appropriate experiences, device intermediaries like operating systems are well-placed to facilitate the privacy-preserving sharing of age signals created locally. Moving age assessments to the device-level allows users to interact with an age provider once, rather than having their age assessed by a different age provider for every service they use. If such approaches are pursued, strong protections need to be in place for open source operating system providers, as well as mandates for the development of open and free standards to avoid fragmentation and competition harms, and to strengthen transparency and user consent

2. Ensure choice, equity and accessibility.

Age can be attested to, approximated or verified in many ways. Every age assessment method comes with important trade-offs, but people should not be forced to take risks on their personal data and safety to retain access to services and information. Users should thus always have a choice between multiple age providers that are privacy-preserving, non-discriminatory and accessible. This is especially important for young people who often don't have access to more privacy-preserving age assurance methods, and are expected to hand over their biometric data to stay online.

The question of which providers are deemed trustworthy enough to participate in such a system is a crucial one. Policymakers must ensure that the options available to people protect their privacy and security, and that a diverse list of providers prevents people from being locked out. Only if everyone has the ability to access age assurance systems through privacy-preserving and rights-respecting providers, will the web remain accessible and open. People should be able to rely on a plurality of institutions, government or private, that can either attest to their age, including face-to-face, or have existing knowledge of their ages that they can share through the use of anonymous credential technology. Examples might be banks, public health and educational institutions, libraries, or services like phone providers, ISPs, subscription services or other services that are able to attest to a user's age.

3. Put people in control.

We should always be in control over what information is shared about us, and to whom. Once an age signal is created, age assurance architectures should empower users to hold that signal - in the form of a credential - on their device. Whether an age signal is shared with an app or website by the operating system or the browser, users must be in control of the decision whether and to whom that information is shared with.

Users must also retain control over - and trust in - their devices. Digital devices are the interface through which we all navigate increasingly large parts of our lives; they are our trust anchors. Enforcing restrictions at the device level on what people can or cannot do online would undermine the already fragile trust relationship between the two - pushing people toward less secure workarounds, rather than addressing the underlying policy concern.

This means that it is best when responsibility for sharing the results of age assessments is performed by users and their devices.

4. Assess risks end-to-end.

Many jurisdictions require age assurance systems to be "highly effective". We believe that the effectiveness of an age assurance system should be considered end-to-end, and not be limited to the assessment step: After all, where an older relative or friend is willing to help a child circumvent a block, no technical mechanism can be effective.

Given these considerations, we think there is value in considering age assurance approaches that empower parents to attest to their child's age when setting up their device. Coupled with barriers to resetting the age once set, such an age signal would provide a high degree of confidence without requiring invasive proofs of age through biometric analysis or ID document checks. As noted above, such approaches need to ensure that age attestation is not another factor cementing the dominance for a few actors, and that open source projects are meaningfully protected from being locked out of participating in a market.

Despite those challenges, we believe that it is crucial to not only consider the potential risks young people could encounter online, but also the risks flowing from age assurance systems themselves. Given those risks, parental age attestation can be a lower-risk approach suitable in many contexts.

5. Leverage zero-knowledge architectures.

Where high-assurance age credentials are used, zero-knowledge architectures are the right step towards sharing age signals in a privacy preserving way. Such approaches allow users to verify the truth of a statement about them, like their age or age range, without having to reveal the information on which the statement is based.

While zero-knowledge architectures are promising, they do not solve every issue. Beyond limiting disclosure of information about people (such as attributes other than their age), hiding the issuer of age credentials (like a bank, public service or educational institution) is key to preserving users' privacy and choice of assessment methods. This prevents discrimination against users of smaller or less common age providers.

Likewise, the issuer of an age credential should not know which service or feature someone is accessing with an age proof. The example of Spain's Catera Digital, or "porn passport", shows why: The Spanish age verification system created tokens that the verifying authority could use to infer a user's browsing history, undermining users' privacy, trust, and ultimately the adoption of the system.

Zero-knowledge proofs themselves also do not prevent abuse of age information, such as by using age data in ad targeting. Beyond strict prohibitions on repurposing age data, we believe that any age assurance system should be open source to facilitate trust, accountability and transparency.

To prevent the sharing of age tokens, we believe rate limits, which restrict how often an age token can be used, are the best and most effective solution. We strongly caution against linking tokens to attested hardware, such as trusted platform modules (TPMs). Hardware-bound tokens force users to use specific, approved hardware. Hardware attestations can leak details about the device's configuration and location, thus enabling tracking or unjustified discrimination at the moment of certification issuance. Attestations undermine users' freedom over their own devices, including what software they can install and run. People who run older or unsupported devices might be excluded as old, weak hardware is routinely found to be compromised, such that it needs to be revoked. Rate limits offer a far simpler and more robust answer to these challenges.

6. Don't break the internet.

The open internet - and the web built on top of it - is a global public resource that millions depend on every day, and that has become a cornerstone of our societies. This openness thrives on open standards, shared protocols, and interoperability. Age checks risk fragmenting the web in more ways than one: Incompatible requirements will create a patchwork of age-gated communities, and age gates in the hands of a few will push people further into closed ecosystems, undermining the wider digital competition and the decentralization that gives the internet its strength.

To avoid the hollowing out of fundamental rights online, and the undermining of the open internet, international collaboration and free and open standards are urgently needed to govern age assurance across borders.

***

We believe the principles set out above can help mitigate the large-scale erosion of privacy, security, and agency that the first wave of age assurance laws and social media bans has introduced.

But improved legislative mandates and technical fixes alone are not enough to improve young people's online experiences in a rights-respecting way. Enabling young people to develop positive relationships with digital technologies is foremost a societal issue, not a technical one. Changing norms around how we engage with technology, what we ask of companies seeking our attention, and how we have conversations about what safety means beyond abstinence and control will require a whole-of-society approach to digital well-being.

The post Pragmatic principles for more rights-respecting age assurance architectures appeared first on Open Policy & Advocacy.

17 Sep 2026 10:08am GMT

The Rust Programming Language Blog: Be alert: targeted attacks on prominent Rustaceans

We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware.

What we've seen

A video call is set up for something positive - maybe for a job, maybe for a project, maybe for a contract opportunity - and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard).

These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection.

What you can do

Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust - ideally, try to be the one who sets up the call on a platform you already use.

Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on.

If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help.

17 Sep 2026 12:00am GMT

16 Sep 2026

feedPlanet Mozilla

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

Github Link

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

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

16 Sep 2026 6:03pm GMT

Firefox Tooling Announcements: MozPhab 2.19.1 Released

Bugs resolved in Moz-Phab 2.19.1:

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

1 post - 1 participant

Read full topic

16 Sep 2026 2:28pm GMT

The Mozilla Blog: Mozilla and Mistral: Partnering to expand AI competition and preserve user choice

The AI race is shifting. Again. Practically overnight, competition has expanded from "which AI model is best?" to a new high-stakes battle over which models people can access, through which products, and whether people have meaningful choice about AI at all.

In response, Mozilla and Mistral today announced a partnership built on a shared idea: a new, open-source AI model alternative to Big Tech-default browser ecosystems. The intent: a model deliberately designed to keep the web open to technological diversity, competition, and choice.

And we're putting this idea into practice in Firefox.

Mistral Small 4 is coming to Firefox Smart Window beta (learn more about Firefox Smart Window here), becoming a new AI model for Smart Window users in the US and Canada, while expanding Smart Window beta access and French-language support to Firefox users in France. Across all markets where Smart Window beta is available, Firefox users can still choose from a multitude of other AI models.

"AI is becoming part of how people experience the web every day. We want to make sure that doesn't mean people are chained to one company's self-serving pipeline. With the browser sitting at the heart of the web and online experience, it should be a place where different AI providers can compete and open source has a seat at the table.

This isn't just a product partnership. A browser shouldn't be a one-way funnel. It should preserve what made the internet powerful to begin with: the freedom to explore, discover different ideas and tech, and decide for ourselves where to go next," said Anthony Enzor-DeMeo, CEO of Mozilla Corporation.

Choice and competition are worth protecting

As AI integration becomes increasingly concentrated, we are in jeopardy of a handful of closed-model companies controlling the browser, the search engine, the AI model, and the surrounding services that connect them. Mozilla and Mistral are betting that independent and interoperable models can offer an alternative to global tech monopolies controlling the next digital era.

"This partnership represents two open source advocates working together to bring Mistral's scientific innovations to Mozilla's consumers around the world. Together, we are bringing privacy, control, and choice to AI-powered web browsing," said Arthur Mensch, Co-founder and CEO of Mistral.

Meaningful choice isn't confined to personal preference for one AI model over another. Web products need to be able to work with different AI providers, and people deserve the option of switching without being locked into a single company's ecosystem. When a tech layer as far-reaching and influential as AI is controlled by a small handful of players, it risks creating closed systems and closed doors, making it harder for new ideas and better technologies to grow, reach users, and compete on merits.

Mozilla and Mistral aim to keep that door open. The combination of an independent browser with a frontier European AI company gives people and institutions greater access to useful, responsible AI, the opposite of locking them into one company's singular technology ecosystem.

Selecting Mistral, and expanding to France

Mozilla selected Mistral Small 4 after evaluating its performance for Smart Window Beta, including multilingual performance, an important part of the fit. The companies approached multilingual and multicultural tuning as a core model feature, rather than simply adapting an English-first experience for a new market.

For Firefox users, Mistral access starts with Smart Window Beta, a browsing experience designed to turn AI into a useful assistant for the things we do online: making sense of complex search trails, finding something valuable you clicked away from, presenting data sources, and generally picking up where day-to-day internet use got left off.

France is the first new market for Smart Window with official French-language support. Mozilla is planning additional European expansion later this year.

A different kind of AI competition

Our Mistral partnership puts an ambitious new AI model approach into practice: a multilingual, globally competitive European AI company reaching people through an independent browser, leveraging openness to create more room for new technologies to compete and succeed. Mistral can reach Firefox users without owning the browser, and Mozilla can integrate and recommend Mistral without removing user choice.

It is a natural extension of the principles that have shaped Firefox and the open web, and the kind of AI ecosystem we intend to continue building.

The post Mozilla and Mistral: Partnering to expand AI competition and preserve user choice appeared first on The Mozilla Blog.

16 Sep 2026 8:00am GMT

Jonathan Almeida: Checkout a Github pull request from one-off contributions

EDIT: Updated to reference gh correctly. Thanks flod!

Sometimes on Github, I need to fetch a patch from a fork I don't typically see everyday so I can try it out locally. I use the line at the top of the patch which has a copy button next to it because it's convenient.

The common steps for this are:

  1. Click the contributor's branch and go to their github fork repository.
  2. Copy the repository link.
  3. Add a new git remote with an alias (typically their username).
  4. git fetch <alias>
  5. git checkout <alias>/<branch>

Here is a one-liner for it that you can add to your gitconfig:

[alias]
  co = "!f() { PNAME=$(basename `git rev-parse --show-toplevel`); OWNER=$(echo $1 | cut -d':' -f1); BRANCH=$(echo $1 | cut -d':' -f2); git fetch git@github.com:$OWNER/$PNAME.git $BRANCH; git checkout FETCH_HEAD; }; f"

You might ask, why do all of this when the github gh CLI does this for you? While it does simplify some tasks, I wanted a solution that was independant to a specific git host. The git@github.com remote that is used in the alias can be changed or made configurable if desired. This is something that I wouldn't be able to do with platform-dependant gh.

The fetch also works well with jj too because the fetch and checkout remain headless.

Formatted and commented, it looks less intimidating:

f() {
  # Get the repository name from your checkout (assuming it is the
  # original directory name as the remote).
  PNAME=$(basename `git rev-parse --show-toplevel`);

  # Parse out the fork's owner.
  # Example: `<owner>:<branch>`
  OWNER=$(echo $1 | cut -d':' -f1);

  # Parse out the branch name.
  # Example: `<owner>:<branch>`
  BRANCH=$(echo $1 | cut -d':' -f2);

  # Do a fetch of that particular branch using the extracted
  # information from above.
  # This assumes the remote is hosted on github.
  git fetch git@github.com:$OWNER/$PNAME.git $BRANCH;

  # Checkout using the alias `FETCH_HEAD` which git provides.
  git checkout FETCH_HEAD;
};

# Execute the function!
# It's easier to build a function that holds variables and execute
# rather than in-line it.
f

Comments

With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below.

Learn how this was implemented from the original source here.

<noscript><p>Loading comments relies on JavaScript. Try enabling JavaScript and reloading, or visit <a href="https://mindly.social/@jonalmeida/117279142568496801">the original post</a> on Mastodon.</p></noscript>
<noscript>You need JavaScript to view the comments.</noscript>

16 Sep 2026 5:38am GMT

This Week In Rust: This Week in Rust 669

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

Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Rust Walkthroughs
Research

Crate of the Week

This week's crate is zenjpeg, a pure Rust JPEG encoder and decoder.

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

Cargo

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

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

Updates from the Rust Project

523 pull requests were merged in the last week

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

There were almost no regressions this week, and several performance improvements! Though some of them were reverts of regressions from a previous week. #162422 improved the performance of Polonius, whose performance is getting closer to the previous NLL borrow checker.

Triage done by @Kobzol. Revision range: 656a9da1..20d35a3a

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 0.4% [0.1%, 0.9%] 3
Improvements ✅
(primary)		 -0.7% [-4.4%, -0.1%] 199
Improvements ✅
(secondary)		 -0.9% [-2.7%, -0.1%] 222
All ❌✅ (primary) -0.7% [-4.4%, -0.1%] 199

0 Regressions, 5 Improvements, 5 Mixed; 2 of them in rollups 40 artifact comparisons made in total

Full report here.

Approved RFCs

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

Final Comment Period

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

Tracking Issues & PRs

Rust

Cargo

Leadership Council

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

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-09-16 - 2026-10-14 🦀

Virtual
Europe
North America
Oceania

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

Jobs

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

Quote of the Week

Every so often I am told about some maths fact that I can only assume someone went to prison for discovering

- Simon Buchan

Thanks to Chayim Refael Friedman for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

16 Sep 2026 4:00am GMT

15 Sep 2026

feedPlanet Mozilla

The Servo Blog: Your Donations at Work: One Year of Sponsored Servo Development

Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub. In his own words, here is a look back over the past year!

First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about. Some highlights from that funded work that I'm proud of:

On top of that, I spent time diagnosing unexpected failures in others' PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.

A few pieces of work from this period that stand out to me:

This role I've carved out means a lot to me-I've found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others. A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference! I'm excited to see what's possible in the coming year.

15 Sep 2026 12:00am GMT

11 Sep 2026

feedPlanet Mozilla

Firefox Nightly: The Need for Speed Controls – These Weeks in Firefox: Issue 208

Highlights

Playback speed settings panel in a Picture-in-Picture window.

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons
WebExtensions Framework

DevTools

::picker rules for a pseudo element within the DevTools Inspector pane.

A tooltip showing a breakdown of a CSS var function

WebDriver

New Tab Page

A layout variation for the New Tab page with the Widgets column on the left and Popular Today column on the right.

Picture-in-Picture

Search and Urlbar

The Firefox New Tab page with an unstyled in-page search bar in the center, showing Google search suggestions for "what's a scotch bonnet"

11 Sep 2026 5:32pm GMT

Mozilla Data YouTube Channel: Data Club: Jan-Erik Rediger - Little Bobby Tables - from metrics.yaml to data-filled columns

A short story about Little Bobby Tables and how we know what data to fill in where.

11 Sep 2026 11:25am GMT

Mozilla Data YouTube Channel: Last Lecture: Writing the Data Docs

Will Lachance gives a last lecture on writing data documentation at Mozilla.

11 Sep 2026 10:42am GMT

Mozilla Data YouTube Channel: Data Club Talk: Jan-Erik Rediger - The Glean UniFFI migration and how no one noticed

Given at the Mozilla Data Club on August 12th, 2022.

11 Sep 2026 6:45am GMT

Mozilla Data YouTube Channel: Monitoring Sensitive Data: How do we monitor data we don't store?

We try to be responsible with data. For example, we: - store as little sensitive data as possible - monitor changes in incoming data on which we've built models But what happens when those two approaches conflict? How do we monitor changes in incoming data that we don't want to store? This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.

11 Sep 2026 12:19am GMT

Jonathan Almeida: Perf wins from relocating MOZ_OBJDIR have a dev experience cost

This is the opposite of what I wanted to write about: relocating your MOZ_OBJDIR outside of your source directory will make your IDE faster.

In mozilla-central (the firefox monorepo), a default object files directory is created within the same source directory. This is equivalent to the build/ directory you would typically see in other projects.

While this is typically fine, I've found that Android Studio indexes many of these files and that can be slow when you're not working across all the layers in Gecko and Firefox. I ended up with these build directories that grew over time:

Directory Last touched Size Files
obj-aarch64-unknown-linux-android 2025-11-04 29 G 113,116
objdir-desktop 2025-11-04 19 G 41,010
objdir-frontend 2026-09-09 6.3 G 66,930
obj-aarch64-apple-darwin24.5.0 2025-06-16 4 K 1

That's a lot to index! I figured a way around this problem is to move the OBJDIRs out of the source directory and into something like ~/.mozbuild:

mk_add_options MOZ_OBJDIR="$HOME/.mozbuild/objdir-frontend"

While this does speed up IDE indexing, it's at the cost of developer experience, because now our generated code (e.g. FxNimbus) shows up as red symbols everywhere.

[insert sad trombone sound clip]

I'm uncertain if trimming what we index in these OBJDIRs is worth a large enough performance win, so for now I'll ensure I clean-up my stale copies which I'm not actively using.

11 Sep 2026 12:00am GMT