Matthew here from the SpiderMonkey team. As the weather whipsaws from cold to hot to
cold, I have elected to spend some time whipping together a too brief newsletter,
which will almost certainly not capture the best of what we’ve done these last few
months. Nevertheless, onwards!
🧑🎓Outreachy
We hosted an Outreachy intern, Serah
Nderi, for the most recent Outreachy cycle, with Dan
as her mentor. Serah worked on implementing the Iterator.range proposal as well as a
few other things. We were happy to host her, and grateful to her for joining. Read
about her internship project
here.
🥯HYTRADBOI: Have You Tried Rubbing a Database On It
HYTRADBOI is an interesting independent online only
conference, which this year had a strong programming languages track.
Iain from the SpiderMonkey team was able to produce
a stellar video talk called A quick ramp-up on ramping up
quickly,
where he helps the audience reinvent our baseline interpreter in 10 minutes. The talk
is fun and short, so go forth and watch it!
👷🏽♀️ New features & In Progress Standards Work
We have done a whole bunch of shipping work this cycle. By far the most important
thing is that Temporal has now been shipped on
Nightly. We must extend our
enormous gratitude to André Bargull, who has been implementing this proposal for
years, providing reams of feedback to champions, and making it possible for us to
ship so early. We’ve also been working on improving error messages reported to
developers, and have a list of “good first
bugs” available for people
interested in getting started contributing to SpiderMonkey or Firefox.
In addition to Temporal, Dan has worked on shipping a number of our complete proposal
implementations:
But the good news for slacker states is that doing the most work, cranking out the most lines of code, or the most pages of PDFs, or whatever, does not necessarily produce the best results. Given the amount of work that other states, and juridictions like the European Union, have already done on privacy, a slacker state can, right now, get not just the best privacy protection but also save a lot of time and grief for state employees and for business people in your state.
You need two laws. And we know that people are going to print them out, so please keep them short. (Maybe do a printer ink right to refill law next year?)
Focus on the riskiest companies with the most money and staff for compliance—don’t put extra work on small local businesses.
Save your state’s attorney general and their staff a bunch of time. They’re not Big Tech’s support department. If a Big Tech company drops the ball on user support, just suspend their surveillance license until they clean up their act, like a problem bar and their liquor license.
You can define surveillance really briefly in the law and make the big out-of-state companies do the work of describing their surveillance practices in their license application.
That one is pretty easy to do as long as you focus purely on inbound data, the surveillance part, and don’t touch anything that sounds like speech from the company to others. And you can push most of the work off onto Big Tech and a new surveillance licensing board. I’m sure every state has people who would be willing to get on one of those.
Second, copy all the details from other states and countries. The other law would be focused on maximum privacy, minimum effort. The goal is to make a law that small business people can comply with, without even reading it, because they already had to do some privacy thing for somewhere else. Two parts.
Any privacy feature offered in some other jurisdiction must be offered here, too. A company only breaks the law if someone out-of-state gets a privacy feature that someone in-state doesn’t.
This law may be enforced by anyone except a state employee. (Borrow the Texas S.B. 8 legal hack, to protect yourself from Big Tech industry groups trying to block the law by starting an expensive case.)
A small business that operates purely locally can just do their thing. But if they already have some your California privacy rights feature or whatever, they just turn it on for this state too. Easier compliance project for the companies, better privacy for the users, no enforcement effort for the state, it’s a win-win-win. After all, state legislators don’t get paid by the page, and we each only get one set of carpal tunnels.
Meta, Apparently, Really Wants Everyone To Read This Book (By Trying To Ban It) by Mike Masnick. Macmillan showed up just long enough to point out the blazingly obvious: they never signed any agreement with Meta and thus can’t be bound by arbitration. The arbitrator, displaying basic common sense, had to admit they had no jurisdiction over Macmillan.
AI Search Has A Citation Problem by Klaudia Jaźwińska and Aisvarya Chandrasekar. Chatbots were generally bad at declining to answer questions they couldn’t answer accurately, offering incorrect or speculative answers instead. (related: fix Google Search)
How Ukraine integrates machine vision in battlefield drones by Oleksandr Matviienko, Bohdan Miroshnychenko & Zoriana Semenovych. In November 2024, the government procured 3,000 FPV drones with machine vision and targeting technologies. Reports also suggested that the procurement would be expanded to 10,000 units.
Preparing for the next European war by Azeem Azhar. One challenge will be the simple rate of innovation in the actual battlefield. Drone warfare in Ukraine has shown iteration cycles measuring weeks not years. So any systems procured today need to be future-proofed for those dynamics.
Thread by Trent TelenkoThe logistical facts are that the FM-MAG machine gun, the 60 mm & 81mm mortars, LAWS, Javelins, any infantry crew served weapon you care to name are all going to be most to fully replaced with drones and drone operators, because of the logistical leverage drones represent on the battlefield.
Long-range drone strikes weakening Russia’s combat ability, senior Ukrainian commander says by Deborah Haynes. Some of the drones are remotely piloted, others work via autopilot. Russia’s war has forced Ukraine to use technology and innovation to fight back against its far more powerful foe. It has accelerated the use of autonomous machines in an irreversible transformation of the warzone that everyone is watching and learning from. Brigadier Shchygol said: Right now, Ukraine’s battlefield experience is essentially a manual for the world.
Ukraine Drives Next Gen Robotic Warfare by Mick Ryan. Another more interesting trend has arisen which will force policy makers and military strategists to undertake an even more careful analysis of Ukraine war trends, and how these trends apply in other theatres, particularly the Pacific. This trend, robotic teaming, has emerged over the past year with the advent on drone-on-drone combat in the air and on the ground. In particular, several recent combat actions in Ukraine provide insights that need to be studied and translated for their employment in the massive ocean expanses, tens of thousands of kilometres of littoral, thousands of large and small islands and at least three continents that constitute the Pacific theatre.
DEEP DIVE: Taiwan miltech aims to undermine Chinese components by Tim Mak. Taiwan has learnt the central tech lesson from the war in Ukraine: the next global conflicts will heavily feature cheap, small drones—and in large numbers. So as an electronics and hardware component giant—especially relative to its size and diplomatic status—it is trying not only to develop a domestic industry, but also become an arsenal for the free world, building drones and devices for allied militaries worldwide.
Why America fell behind in drones, and how to catch up again by Cat Orman and Jason Lu. Also Building Drones for Developers: A uniquely open architecture on the F-11 means that every part of the drone is truly built around the [NVIDIAn] Orin [GPU]. This enables sophisticated autonomy applications in which ML models are able to not only analyze data obtained in-flight, but actually use that analysis to inform flight actions in real time.
In this month’s Community Office Hours, Laurel Terlesky, Design Manager, is talking about the new Thunderbird Design System. In her talk from FOSDEM, “Building a Cross-Platform, Scalable, Open-Source Design System,” Laurel describes the Thunderbird design journey. If you are interested in how the desktop and mobile apps have gotten their new look, or in the open source design process (and how to take part), this talk is for you!
Next month, we’ll be chatting with Vineet Deo, a Software Engineer on the Desktop team who will walk us through the new Account Hub on the Desktop app. If you want a sneak peak at this new streamlined experience, you can find it in the Daily channel now and the Beta channel starting March 25.
February Office Hours: The Thunderbird Design System
As Thunderbird has grown over the past few years, so has its design needs. The most recent 115 and 128 releases, Supernova and Nebula, have introduced a more modern, streamlined look to the Thunderbird desktop application. Likewise, the Thunderbird for Android app has incorporated Material 3 in its development from the K-9 Mail app. When we begin working on the iOS app, we’ll need to work with Apple’s Human Interface Guidelines. Thus, Laurel and her team have built a design system that provides consistency across our existing and future products. This system’s underlying principles also embrace user choice and privacy while emphasizing human collaboration and high design standards.
Watch, Read, and Get Involved
We’re so grateful to Laurel for joining us! We hope this video helps explain more about how we design our Thunderbird products. Want to know more about this new Thunderbird design system? Want to find out how to contribute to the design process? Watch the video and check out our resources below!
Mozilla remains committed to fostering a secure, agile, and transparent Web PKI ecosystem. The new Mozilla Root Store Policy (MRSP) v3.0, effective March 15, 2025, introduces critical updates to strengthen Certificate Authority (CA) practices and enhance compliance.
A major focus of MRSP v3.0 is tackling the long-standing challenge of delayed certificate revocation—an issue that has historically weakened the security and reliability of TLS certificate management. The updated policy establishes clearer revocation expectations, improved incident reporting, subscriber education by CAs, revocation planning, and automated certificate issuance to ensure that certificate replacement and revocation can be handled promptly and at scale.
Beyond improving revocation, MRSP v3.0 also introduces policies to move CA operators toward dedicated hierarchies for TLS and S/MIME certificates and to enhance CA private key security with improved lifecycle tracking. All of these updates raise the bar for CA operations, reinforcing security and trust across the broader internet ecosystem.
Addressing Delayed Certificate Revocation
One of the most persistent challenges in certificate management has been ensuring that TLS server certificates are revoked quickly when necessary. Many website operators struggle to replace certificates efficiently, while security advocates emphasize the need for rapid revocation and automated certificate lifecycle management to reduce risks.
To strike the right balance between security, stability, and operational feasibility, MRSP v3.0 introduces several key changes towards clearer and more comprehensive revocation expectations.
No Exceptions to Revocation Requirements
Previously, some CA operators expressed uncertainty about whether Mozilla could grant exceptions to revocation timelines in certain situations. MRSP v3.0 explicitly reiterates that Mozilla does not grant exceptions to the TLS Baseline Requirements for revocation. This will promote more consistent enforcement of revocation policy.
Stronger Subscriber Communication and Contractual Clarity
CA operators must proactively warn subscribers about the risks of relying on publicly trusted certificates in environments that cannot tolerate timely revocation. Additionally, Subscriber Agreements must explicitly require cooperation with revocation timelines, ensuring CA operators can act without unnecessary delays.
Mass Revocation Preparedness
Historically, large-scale certificate revocations have been challenging, leading to operational slowdowns, and ecosystem-wide risks when urgent action is required. To prevent revocation delays, MRSP v3.0 mandates mass revocation readiness to help ensure that CA operators proactively plan for such scenarios. CA operators will be required to develop, maintain, and test comprehensive plans to revoke large numbers of certificates quickly when necessary. And, to further strengthen mass revocation preparedness, MRSP v3.0 introduces a third-party assessment requirement. Assessors will verify that CA operators:
Maintain well-documented, actionable plans for large-scale revocation,
Demonstrate feasibility through regular testing, and
Continuously improve their approach based on lessons learned.
These measures ensure CA operators are fully prepared for high-impact security events.
By strengthening mass revocation preparedness–and investing in CRLite–Mozilla is working to make certificate revocation a reliable security control.
Enhancing Automation in Certificate Issuance and Renewal
Automation plays a critical role in ensuring certificates can be replaced in a timely manner. To further encourage adoption of automation, MRSP v3.0 introduces new requirements for CA operators seeking root inclusion with the “websites” trust bit enabled, including: offering automation options for Domain Control Validation (DCV), certificate issuance, and renewal (demonstrated by a publicly accessible test website demonstrating automated certificate replacement at least every 30 days). Test website details must be disclosed in the Common CA Database (CCADB), adding transparency to this requirement. This push for more automation aligns with industry best practices, reducing reliance on manual processes, improving security, and minimizing mismanagement risks.
Phasing Out Dual-Purpose (TLS and S/MIME) Root CAs
A significant change introduced in MRSP v3.0 is the phase-out of dual-purpose root CAs—those with both the “websites” trust bit and the “email” trust bit enabled. The industry is already moving toward separating TLS and S/MIME hierarchies due to their distinct security needs. Keeping these uses separate at the root certificate level ensures more focused compliance, increases CA agility, reduces complexity, and enhances security. Going forward, Mozilla’s Root Store will require that new root CA certificates are dedicated to either TLS or S/MIME, and CA operators with existing dual-purpose roots will need to submit a transition plan to Mozilla by April 15, 2026, and complete a full migration to separate roots by December 31, 2028. This move enhances clarity and security by ensuring TLS and S/MIME compliance requirements remain distinct and enforceable.
Strengthening CA Key Security with “Cradle-to-Grave” Monitoring
Another major enhancement in MRSP v3.0 is the introduction of stricter key lifecycle monitoring to protect “parked” CA private keys. A “parked” key is a private key that the CA operator has generated for future use, but not yet used in a CA certificate. MRSP v3.0 adds mandatory reporting of parked key public hashes (corresponding to the parked CA private key) in annual audits. By enforcing transparency and accountability, Mozilla strengthens protections against undetected key compromise or misuse.
Conclusion
MRSP v3.0 represents a major step forward in ensuring stronger CA accountability with more reliable certificate revocation processes, better automation and operational resilience, and enhanced security for CA private keys. In all, these changes help modernize the Web PKI and ensure that CA operations will remain transparent, accountable, and secure. We encourage you to engage with the Mozilla community and to contribute to these efforts and our shared mission of ensuring a secure and trustworthy online experience for all users.
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 on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request.
Want to get involved? We love contributions.
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.
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.
No Calls for participation were submitted this week.
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 X (formerly Twitter) or Mastodon!
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 X (formerly Twitter) or Mastodon!
This week we had to merge a lot of large rollups due to many problems with our CI infrastructure,
which made analysis harder. Even though the aggregated stats look like there were a lot of regressions,
it is skewed by two large regressions happening on an uncommon optimized incremental build and a
documentation build of a single crate. The documentation regression is being tracked, and fixes to
some other regressions are already in progress.
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.
Treat anything starting with cargo as if it is cargo run. This applies even to commands that do not build anything, such as cargo clean, and third-party plugins, such as cargo audit.
As you scroll through social media, the posts blend together: a heroic cat, a shocking statistic, a breaking news clip. But in a world where AI blurs the line between fact and fiction, how do you tell what’s real from what’s misinformation?
The short answer: Most of the time, you can’t. Generative AI tools have made it faster, cheaper, and easier to create convincing fakes, flooding our feeds with AI-generated content. But here’s what you can do – learn to spot the signs of misinformation.
What should I think about when trying to detect AI?
Just looking out for obvious AI will mean missing a lot of it. Retrain your brain to assess social media on a framework similar to the ones used by AI-misinformation researchers. Consider who’s behind the post, whether the content makes sense, how it’s written, the emotions it evokes and any signs of manipulation.
User
Who is posting this? Is it a reliable source? Is this account tied to a real-world institution that I trust?
What is the username length? Is it a long set of random numbers and letters? Is it a verified account? Does it only have a handful of followers (who also look random or not real)?
Content
Does the framing make sense? What is this content about? Is it especially vague or seems so outrageous that it couldn’t be true? Does this contradict what you already know about the topic?
Are there platform flags that the content could be potentially misleading, or a comment section full of claims that it’s false? Are there AI badges or indicator hashtags such as #AI, #satire, #skit, #spoof or #AD?
Style
How is it written? Is there poor or wooden-sounding grammar? Is it flowery? Is there unnatural repetition, or has the user posted the same thing several times?
Does it repeat often-used AI words such as “elevate,” “captivate,” “tapestry” or “delve”? Does it use known AI phrases such as “provided valuable insights,” an “indelible mark,” or “a rich tapestry”? (Of course, these words and phrases don’t definitively mean that the content is AI-generated misinformation; they’re just reasons to take a closer look.)
Emotion
Is this an especially emotion-laded post? Is the level of emotion appropriate for the situation?
Does the post appear to “weaponize” emotion or tell readers how to feel about the content, such as by using more anger and swear words? (Keep in mind that bots on social media can and do use profanity).
Manipulation
What might someone have to gain by touching on your emotions in this way? What’s the worst-case scenario if this turns out to not be true? What might a user (using AI) be hoping you don’t look up?
How do I spot AI-generated images or videos online?
Gone are the days where every AI image looked like a wacky Pixar knockoff, but it’s still worth checking for these known cues:
Hands and teeth with too many fingers, too many hands, too many teeth or impossibly long arms
Tools like TrueMedia.org scan social posts for false faces, voices, and information, while Mozilla’s Deepfake Detector analyzes text using multiple detection engines and generates a confidence score indicating the likelihood that the content is AI-generated. But while AI detection accuracy is improving, it isn’t perfect.
It always helps to try to verify the information itself — search for it along with “fact check” and look for trusted sources. For images, try a reverse image search using Google Image Search or Bing Image Match.
What can misinformation look like on TikTok?
Every social media site has its own AI landscape. Fake news, images and news clips targeting young voters and consumers are circulated particularly widely on TikTok due to its young user base. “Content farms” spin out inaccurate or misleading videos, often multiple a day in the distinctive TikTok style of on-screen text read by an AI voice.
When scrolling on TikTok, be skeptical — or at least get a second opinion — on any informational videos that aren’t read by real people or only consist of captions to the AI voice (reputable news sites usually show who’s talking to build trust). Profiles that look like news sites but that have no comments or likes (especially for celebrity news) are a red flag — as well as canned phrases like “creepy response” or “finally broke their silence” meant to drive clicks.
What can misinformation look like on X?
Though many AI-generated posts on X are largely innocuous text-based posts, videos in particular are more likely to be political deepfakes. And while the crowdsourced moderation feature, “Community Notes,” allows users to annotate posts with context or warnings, it replaced a more robust monitoring operation that means it’s more likely users will encounter bots.
Stay wary of accounts that only spam replies, or situations where multiple accounts are commenting similar things under a post. If a user only posts replies, especially to inflammatory content, it’s a red flag that it’s a bot searching for certain keywords.
Also, user verificationon X is the least trustworthy of the major social media sites as users can pay for “verified” status (in one Cambridge study, half of synthetic profiles studied had verified status).
What can misinformation look like on Facebook?
It’s especially difficult to silo yourself from AI-generated content on Facebook, even if you’re only interested in posts from family and friends. Over the past three years, there has been a “significant increase” in the rate of users seeing posts they held no “friend” connection to, thanks to the algorithm that surfaces high-engagement posts in users’ feeds.
Being disciplined about clicking “not interested” under the three dots on each post can help stem the flow, as well as staying skeptical of images and being wary of link-outs to “news” sites. Verify posts (even those that appear to be from a harmless, real person) about any news events independently.
Misleading posts on Facebook are also especially focused on trying to get usersoff Facebook — directing them off the platform to content farms, fake stores and other scam sites.
Stay alert and think critically online
Humans often overestimate how good they are at detecting AI — nice art is sometimes AI-generated, and terrible grammar is sometimes very human. It’s not easy to navigate a landscape designed to trick you, but your best call is to improve how you critically consume all information. Stay curious. After all, AI gets better every passing day — right down to drawing those tricky hands.
Sarah Skinner is a senior editor at a NYC tech startup. She holds a degree from Cornell University on AI and empathy, and has previously worked for McKinsey & Company and the Associated Press.
Fixed a regression related to using the mouse to select text inside an extension options page embedded in about:addons – Bug 1939206
Fixed a leak triggered by the private browsing checkbox included in the install dialog (caught by shutdown leaks failure hit by one of our tests) – Bug 1943031
Starting from Firefox 136, users will be able to undo the installation of a new theme directly from the notification popup – Bug 1931402
Thanks to Becca King for contributing this enhancement 🎉
WebExtensions Framework
A new background.preferred_environment manifest property has been introduced in Firefox 136 in order to let cross-browser Manifest V3 extensions use a background service worker on Chrome and a background event page on Firefox with the same manifest file – Bug 1930334
Ahal has stopped the “problem with lint setup, skipping android-api-lint, android-checkstyle, android-findbugs, android-lint, android-test” messages on Desktop builds.
Punam hasmovedanddecoupled a bunch of modules out from the New Tab codebase into shared module directories in browser and toolkit, since other components depend on them
We’re in the midst of a refresh of the stylings for top sites! This isn’t ready to ship yet, but it can still be previewed by setting browser.newtabpage.activity-stream.newtabShortcuts.refresh to true in Nightly.
Performance
Some of the New Tab refactoring and movements have resulted in some memory-wins on our AWSY (“are we slim yet”) memory test as well as startup paint times
Improved feature callout for the Unified Search Button, enabled Scotch Bonnet by default in Beta, and re-enabled scotch bonnet in performance tests. (Bug 1937666, Bug 1942357, Bug 1923381)
Removed redundant default search engine favicon in the Unified Search Button. (Bug 1908929)
Suggest
AMP & Dismissal Fixes: Hooked up AMP-suggestion-matching strategy and fixed dismissals for Merino suggestions when Suggest features are disabled. (Bug 1942222, Bug 1942435)
Address bar
Set deduplication threshold to zero, fixed Ctrl-Alt-b / Ctrl-Alt-f on Mac to properly move the cursor. (Bug 1943946, Bug 1481157)
Added support for exponents for calculator and updated UrlbarUtils icon protocol list. (Bug 1942623, Bug 1943272)
Search
Search improvements with Nimbus: Refactored the Search Nimbus set-up to split Search experiments between two nimbus feature sections – one for search feature related experiments, the other one for search configuration related experiments. (Bug 1830056, Bug 1883685, Bug 1942099, Bug 1942658)
Places
Added support for exporting interactions via CSV and resolved process crash caused by missing chrome/resource URLs. (Bug 1940782, Bug 1945152)
Hello again Thunderbird Community! Despite the winter seeming to last forever and the world being in a state of flux, the Thunderbird team has been hard at work both in development and planning strategic projects. Here’s the latest from the team dedicated to making Thunderbird better each day:
Monthly Releases are here!
The concept of a stable monthly release channel has been in discussion for many years and I’m happy to share that we recently changed the default download on Thunderbird.net to point at our most feature-rich and up-to-date stable version. A lot of work went into this release channel, but for good reason – it brings the very latest in performance and UX improvements to users with a frequent cadence of updates. Meaning that you don’t have to wait a year to benefit from features that have been tested and already spent time on our more experimental Daily and Beta release channels. Some examples of features that you’ll find on the monthly release channel (but not on ESR) are:
As privacy and security legislation evolves, the Thunderbird team often finds itself in the heart of discussions that have the potential to define industry solutions to emerging problems. In addition to the previously-mentioned research underway to develop post-quantum encryption support, we’re also currently considering solutions to EU laws (EU NIS2) that require multi-factor authentication be in place for critical digital infrastructure and services. We’re committed to solving these issues in a way that gives users and system administrators other options besides Google & Microsoft, and we’ll be sharing our thoughts on the matter soon, with the resulting decisions documented in our new ADR process.
For now, you can follow a healthy and colourful discussion on the topic of OAuth2 Dynamic Client Registration here.
Calendar UI Rebuild is underway
The long awaited UI/UX rebuild of the calendar has begun, with our first step being a new event dialog that we’re hoping to get into the hands of users on Daily via a preference switch. Turning the pref on will allow the existing calendar interface to launch the new dialog once complete. The following pieces of work have already landed:
A big focus for February has been to grow our team so we’ve been busy interviewing and evaluating the tremendously talented individuals who have stepped forward to show interest in joining the team. In the remaining time, the team has managed to deliver another set of features and is heading toward a release on Daily that will result in most email features being made available for testing. Here’s what landed and started in February:
Since my last update, tasks related to density and font awareness, the exchange add-on and keyboard navigation were completed, with the details of each step available to view in our Meta bug & progress tracking. Watch out for this feature being rolled out as the default experience for the Daily build this week and on beta after the next merge on March 25th!
Global Message Database
The New Zealand team are in the middle of a work week to shout at the code together, have a laugh and console each other plan out work for the next several weeks. Their focus has been a sprint to prototype the integration of the new database with existing interfaces with a positive outcome meaning we’re a little closer to producing a work breakdown that paints a more accurate picture of what lies ahead. Onward!
In-App Notifications
Phase 3 of the project is underway to finalize our uplift stack and add in last-minute features! It is expected that our ESR version will have this new feature enabled for a small percentage of users at some point in April. If you use the ESR release, watch out for an introductory notification!
As usual, if you want to see things as they land, and help us squash some early bugs, you can always check the pushlog and try running daily, which would be immensely helpful for catching things early.
If you’re interested in joining the technical discussion around Thunderbird development, consider joining one or several of our mailing list groups here.
WebDriver is a remote control interface that enables introspection and control of user agents.As such itcanhelp 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 136 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 136, several contributors managed to land fixes and improvements in our codebase:
Firefox now handles WebSocket port conflicts for the RemoteAgent more efficiently. If the port specified via the --remote-debugging-port command-line argument cannot be acquired within 5 seconds, such as when another Firefox process is already using it, Firefox will now shut down instead of hanging.
Navigations using the HTTP scheme, triggered by the WebDriver:Navigate command in Marionette or browsingContext.navigate in WebDriver BiDi, will no longer be automatically upgraded to HTTPS. These requests will now remain on HTTP, as originally intended.
WebDriver BiDi
Updated: session.subscribe now returns a subscription ID
New: subscriptions parameter for session.unsubscribe
The subscription IDs can be used with the new subscriptions parameters of session.unsubscribe to remove specific event subscriptions. Previously, it was necessary to unsubscribe using the same attributes provided to session.subscribe. And if there were several calls to session.unsubscribe performed from different areas of the test, there could be unexpected side-effects.
With the new subscriptions parameter, only the subscriptions matching the provided subscription IDs will be removed. The parameter must be an array of subscription IDs. If any ID doesn’t match a known (and not yet removed) subscription ID, an InvalidArgumentError is raised.
When subscriptions is provided, the events or contexts parameters should not be present, otherwise an InvalidArgumentError will be raised.
Example: adding a second subscription for a specific context:
Using the subscriptions parameter allows to remove global and context-specific subscriptions simultaneously, without unexpected side effects.
Deprecated: contexts parameter for session.unsubscribe
It remains possible to globally unsubscribe by using only the events parameter. However the additional contexts parameter is now deprecated and will be removed in a future version. To remove context-specific subscriptions, please use the subscriptions parameter instead.
New: userContexts parameter for script.addPreloadScript
Last week the Department of Justice and some state attorneys general filed revised proposed remedies in the U.S. v. Google LLC search case. If the proposed remedies barring all search payments to browser developers are adopted by the court, these misguided plans would be a direct hit to small and independent browsers—the very forces that keep the web open, innovative and free. This case was meant to promote search competition, yet somehow the outcome threatens to crush browser competition, making it even harder for challengers to stand up to dominant players like Google, Apple and Microsoft.
“These proposed remedies prohibiting search payments to small and independent browsers miss the bigger picture—and the people who will suffer most are everyday internet users,” said Mark Surman, President of Mozilla. “Independent browsers like Firefox are on the frontlines of protecting consumer privacy, driving browser innovation, and giving people real choice on how they experience the web. But instead of promoting a fair fight, the DOJ’s remedies would tilt the playing field further into the hands of a few dominant players, diminishing consumer choice and weakening the broader internet ecosystem.”
The DOJ’s proposal hurts, not helps, browser competition
Mozilla agrees that we need to improve search competition, but the DOJ’s proposed remedies unnecessarily risk harming browser competition instead.
Here’s why:
The DOJ wants to ban all search agreements between Google and browsers, even independent browsers that make up a smaller part of the market.
Dominant players that own browsers, like Apple, don’t rely on search deals as they have significant revenue streams from other sources, like hardware, operating systems and app stores.
Meanwhile, independent browsers like Firefox fund the development of their browsers mainly through search revenue––they require this revenue to survive. Search revenue underpins a large part of our work, keeping Firefox competitive and ensuring that web users have privacy-first alternatives.
Punishing independent browsers will not solve the problem. Judge Mehta found that independent browsers account for just 1.15% of U.S. search queries. This means that cutting off our access to search deals won’t fix the issue of search dominance—not by a landslide. Instead, it hurts browser competition.
“The big unintended consequence here is the handing of power from one dominant player to another. So, from Google Search to Microsoft, or Bing for example—while shutting out the smaller, independent challengers that actually drive browser innovation and offer web users privacy and choice,” Surman added.
The last unicorn–the web can’t afford to lose Mozilla’s browser engine
Another thing missing from this conversation is something pretty important—browser engine competition.
You see, browser engines power the web. They are central to a browser’s speed, privacy and security functionality, and the browser’s ability to innovate and do things differently. But they’re very complex and require massive resources and a deep technical expertise to maintain—so much so, that right now only three major browser engines remain: Google’s Chromium, Apple’s Webkit (this engine is really only supported on Apple devices, and isn’t considered “cross-platfrom”), and then there’s Mozilla’s Gecko (which happens to be the only true cross-platform alternative to Chromium).
The DOJ’s proposal to bar search payments to independent browser developers would put Mozilla’s ability to develop and maintain Gecko at risk. If Mozilla is unable to sustain our browser engine, it would severely impact browser engine competition and mean the death of the open web as we know it—essentially, creating a web where dominant players like Google and Apple, have even more control, not less.
“This isn’t just about Firefox,” Surman explained. “If we lose our ability to maintain Gecko, it’s game over for an open, independent web. Look, Microsoft—a $3 trillion company—already gave up its browser engine in 2019 and Opera gave up theirs in 2013. If Mozilla is forced out, Google’s Chromium becomes the only cross-platform browser engine left.”
Mozilla’s role in an open web is BIGGER than our market share
Nevermind our market share, Mozilla has played an outsized role in keeping the web open, private and advocating for choice. Firefox still serves 27 million monthly active users (MAU) in the U.S. and nearly 205 million MAU globally, but our real impact comes from making the internet better by:
Shaping the future of web standards—maintaining our own browser engine, Gecko, gives us a voice in defining how the web works and making decisions that are in support of people, not the bottom-line.
Ensuring interoperability—we fight for a web accessible to all—where anyone can create, access, and share content seamlessly, regardless of the devices or web services they use—not locked into a few ecosystems.
Proving that privacy-respecting technology is possible—we build critical web technologies with security, privacy and user agency at the core.
“This isn’t something we do because it’s profitable or easy,” said Surman. “We do it because it matters. The DOJ’s proposal doesn’t just miss the mark, it risks handing even more power to dominant industry players like Google or Apple, not less.”
Mozilla calls on regulators and policymakers to recognize the vital role of independent browsers and take action to nurture competition, innovation, and protect the public interest in the evolving digital landscape.
Mozilla is committed to ensuring a fair and competitive internet ecosystem, one where independent browsers can compete on a level playing field and consumers have real choice. The future of competition, innovation and the open internet depends on us.
On 14 March a root certificate (the resource used to prove an add-on was approved by Mozilla) will expire, meaning Firefox users on versions older than 128 (or ESR 115) will not be able to use their add-ons. We want developers to be aware of this in case some of your users are on older versions of Firefox that may be impacted.
Rust turns 10 this year. It’s a good time to take a look at where we are and where I think we need to be going. This post is the first in a series I’m calling “Rust in 2025”. This first post describes my general vision for how Rust fits into the computing landscape. The remaining posts will outline major focus areas that I think are needed to make this vision come to pass. Oh, and fair warning, I’m expecting some controversy along the way—at least I hope so, since otherwise I’m just repeating things everyone knows.
My vision for Rust: foundational software
I see Rust’s mission as making it dramatically more accessible to author and maintain foundational software. By foundational I mean the software that underlies everything else. You can already see this in the areas where Rust is highly successful: CLI and development tools that everybody uses to do their work and which are often embedded into other tools1; cloud platforms that people use to run their applications2; embedded devices that are in the things around (and above) us; and, increasingly, the kernels that run everything else (both Windows and Linux!).
The needs of foundational software have a lot in common with all software, but everything is extra important. Reliability is paramount, because when the foundations fail, everything on top fails also. Performance overhead is to be avoided because it becomes a floor on the performance achievable by the layers above you.
Traditionally, achieving the extra-strong requirements of foundational software has meant that you can’t do it with “normal” code. You had two choices. You could use C or C++, which give great power but demand perfection in response3. Or, you could use a higher-level language like Java or Go, but in a very particular way designed to keep performance high. You have to avoid abstractions and conveniences and minimizing allocations so as not to trigger the garbage collector.
Rust changed the balance by combining C++’s innovations in zero-cost abstractions with a type system that can guarantee memory safety. The result is a pretty cool tool, one that (often, at least) lets you write high-level code with low-level performance and without fear of memory safety errors.
Empowerment and lowering the barrier to entry
In my Rust talks, I often say that type systems and static checks sound to most developers like “spinach”, something their parents forced them to eat because it was “good for them”, but not something anybody wants. The truth is that type systems are like spinach—popeye spinach. Having a type system to structure your thinking makes you more effective, regardless of your experience level. If you are a beginner, learning the type system helps you learn how to structure software for success. If you are an expert, the type system helps you create structures that will catch your mistakes faster (as well as those of your less experienced colleagues). Yehuda Katz sometimes says, “When I’m feeling alert, I build abstractions that will help tired Yehuda be more effective”, which I’ve always thought was a great way of putting it.
What about non-foundational software?
When I say that Rust’s mission is to target foundational software, I don’t mean that’s all it’s good for. Projects like Dioxus, Tauri, and Leptos are doing fascinating, pioneering work pushing the boundaries of Rust into higher-level applications like GUIs and Webpages. I don’t believe this kind of high-level development will ever be Rust’s sweet spot. But that doesn’t mean I think we should ignore them—in fact, quite the opposite.
Stretch goals are how you grow
The traditional thinking goes that, because foundational software often needs control over low-level details, it’s not as important to focus on accessibility and ergonomics. In my view, though, the fact that foundational software needs control over low-level details only makes it more important to try and achieve good ergonomics. Anything you can do to help the developer focus on the details that matter most will make them more productive.
I think projects that stretch Rust to higher-level areas, like Dioxus, Tauri, and Leptos, are a great way to identify opportunities to make Rust programming more convenient. These opportunities then trickle down to make Rust easier to use for everyone. The trick is to avoid losing the control and reliability that foundational applications need along the way (and it ain’t always easy).
Cover the whole stack
There’s another reason to make sure that higher-level applications are pleasant in Rust: it means that people can build their entire stack using one technology. I’ve talked to a number of people who expected just to use Rust for one thing, say a tail-latency-sensitive data plane service, but they wound up using it for everything. Why? Because it turned out that, once they learned it, Rust was quite productive and using one language meant they could share libraries and support code. Put another way, simple code is simple no matter what language you build it in.4
“Smooth, iterative deepening”
The other lesson I’ve learned is that you want to enable what I think of as smooth, iterative deepening. This rather odd phrase is the one that always comes to my mind, somehow. The idea is that a user’s first experience should be simple–they should be able to get up and going quickly. As they get further into their project, the user will find places where it’s not doing what they want, and they’ll need to take control. They should be able to do this in a localized way, changing one part of their project without disturbing everything else.
Smooth, iterative deepening sounds easy but is in fact very hard. Many projects fail either because the initial experience is hard or because the step from simple-to-control is in fact more like scaling a cliff, requiring users to learn a lot of background material. Rust certainly doesn’t always succeed–but we succeed enough, and I like to think we’re always working to do better.
What’s to come
This is the first post of the series. My current plan5 is to post four follow-ups that cover what I see as the core investments we need to make to improve Rust’s fit for foundational software. In my mind, the first three talk about how we should double down on some of Rust’s core values:
achieving smooth language interop by doubling down on extensibility;
extending the type system to achieve clarity of purpose;
leveling up the Rust ecosystem by building out better guidelines, tools, and leveraging the Rust Foundation.
After that, I’ll target about the Rust open-source organization and what I think we should be doing there to make it contributing to and maintaining Rust as accessible and, dare I say it, joyful as we can.
Plenty of people use ripgrep, but did you know that when you do full text search in VSCode, you are also using ripgrep? And of course Deno makes heavy use of Rust, as does a lot of Python tooling, like the uv package manager. The list goes on and on. ↩︎
What do AWS, Azure, CloudFlare, and Fastly all have in common? They’re all big Rust users. ↩︎
Well, that’s true if the language meets a certain base bar. I’d say that even “simple” code in C isn’t all that simple, given that you don’t even have basic types like vectors and hashmaps available. ↩︎
We’ve heavily reworked and documented our webview rendering model (@mrobinson, @wusyong, @mukilan, #35522, #35621), moved image output and shutdown logic out of the compositor (@mrobinson, @wusyong, #35538), and removed some complicated logic around synchronous repaints when a window is resized (@mrobinson, #35283, #35277).
These changes should make it a lot clearer how to get Servo’s webviews onto your display.
One part of this model that we’re starting to move away from is the support for multiple webviews in one rendering context (@mrobinson, @wusyong, #35536).
First landed in #31417, this was an expedient way to add support for multiple webviews, but it imposed some serious limitations on how webviews could be interleaved with other app content, and the performance and security was inadequate.
Thanks again for your generous support!
We are now receiving 4363 USD/month (+13.7% over January) in recurring donations.
This helps cover the cost of our self-hostedCIrunners and Outreachy internships.
Servo is also on thanks.dev, and already 21 GitHub users (+5 over January) that depend on Servo are sponsoring us there.
If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.
4363 USD/month
10000
As always, use of these funds will be decided transparently in the Technical Steering Committee.
For more details, head to our Sponsorship page.
switching.software offers Ethical, easy-to-use and privacy-conscious alternatives to well-known software
Pro tip: avoid generative AI images in blog posts (even if your CMS says you should have one for SEO purposes) unless you want to make a political statement: AI: The New Aesthetics of Fascism by Gareth Watkins
The Linux kernel project can’t use code from sanctioned countries. Other projects need to check compliance with sanctions, too. US Blocks Open Source ‘Help’ From These Countries by Steven J. Vaughan-Nichols
p. 3 We do not consider legal arguments for consumer privacy as a fundamental right or concerns about access to personal data by malign actors or governments.
Avoiding malign actors is the big reason for restricting personalized ads. And malign actors are numerous. The high-profile national security threats are already in the news, but most people will encounter miscellaneous malware, scams, rip-offs and other lesser villainy enabled by ad personalization more often than they have to deal with state or quasi-state adversaries. There is no hard line between malign actors and totally legit sellers—not only does the personalized ad business have plenty of halfway crooks, you can find n/m-way crooks for arbitrary values of n and m.
Ad personalization gives a bunch of hard-to-overcome advantages to deceptive sellers. Although scams are generally illegal and/or against advertising platform policies, personalization makes the rules easier to evade, as we see with some ways that Facebook ads are optimized for deceptive advertising. Most personalized ads aren’t clustered at the good (high-quality pair of shoes in your size, on sale, next door!) or bad (malware pre-configured for your system) ends of the spectrum. Advertisers at all levels of quality and honesty are present, so any framework for thinking about ad personalization needs to take that variability into account.
p. 3 Some privacy advocates assume, incorrectly, that personalized marketing based on granular consumer data is automatically harmful…
Treating personalized advertising as harmful by default is not an assumption, but a useful heuristic based on both theoretical models and real-world experience. personally, I don’t pay attention to your ad if it’s personalized to me—it’s as credible as a cold call. But I might pay attention to your ad if it’s run in a place where the editors of sites that cover your industry would see it, or your mom would. Yes, it is possible for professors to imagine a hypothetical world in which personalization is beneficial, but that only works if you make the unrealistic simplifying assumption that all sellers are honest and that the only impact of personalization is to show people ads that are more or less well matched to them. The theoretical arguments in favor of personalized advertising break down as soon as you level up your economic model to consider the presence of both honest and deceptive advertisers in a market.
See Gardete and Bart, Tailored Cheap Talk: The Effects of Privacy Policy On Ad Content and Market Outcomes. Our research suggests that another peril of sharing very high quality targeting information with advertisers is that ad content may become less credible and persuasive to consumers. An advertising medium that allows for personalization is incapable of conveying as much information from an honest seller to a potential buyer as an advertising medium that does not support personalization.
Mustri et al., in Behavioral Advertising and Consumer Welfare, find that products found in behaviorally targeted ads are likely to be associated with lower quality vendors and higher product prices compared to competing alternatives found among search results.
p. 8 Which Consumers Care Most About Privacy, and Do Privacy Policies Unintentionally Favor the Privileged?
Lots of studies show that, basically, some people really want cross-context personalized advertising, some people don’t, and for the largest group in the middle, it depends how you ask. (references at the 30-40-30 rule). But the difference in consumer preferences is not about privilege, it’s about information level. See Turow et. al, Americans Reject Tailored Advertising and Three Activities That Enable It. That study includes a survey of privacy preferences before and after informing the participants about data practices—and people were more likely to say they do not want tailored advertising after getting the additional information.
In the Censuswide study Who’s In the Know: The Privacy Pulse Report, the experienced advertisers surveyed in the USA (people with 5 or more years of ad experience) were more likely than average to use an ad blocker (66% > 52%), and privacy is now the number one reason for people to use one. It is reasonable for policy-makers to consider the preferences of better-informed people—which is already a thing in fields such as transportation safety and public health.
p. 11 Poorer consumers live in data deserts (Tucker 2023), causing algorithmic exclusion due to missing or fragmented data. This exclusion thwarts marketing outreach and may deprive them of offers, exacerbating data deserts and marginalization.
Instead of speculating about this problem, personalized advertising proponents who are concerned about under-tracked consumers can already look at other good examples. Early adopters of privacy tools and preferences are helpfully acting as the experimental group for a study that the surveillance business hasn’t yet run. If people on whom less data is collected are getting fewer win-win offers, then the privacy early adopters should have worse consumer outcomes than people who leave the personalization turned on. For example, Apple iOS users with App Tracking Transparency (ATT) set to allow tracking should be reporting higher satisfaction and doing fewer returns and chargebacks. So far, this does not seem to be happening. (For a related result, see Bian et al., Consumer Surveillance and Financial Fraud. Consumers who deliberately placed themselves in a data desert by changing ATT to disallow tracking reported less fraud.) Click this to buy better stuff and be happier
And there’s little evidence to suggest that if a personalized ad system knows someone to be poor, that they’ll receive more of the kind of legit, well-matched offers that are targeted to the more affluent. Poor people tend to receive more predatory finance and other deceptive offers, so may be better off on average with ads less well matched to their situation.
p. 13 More broadly, without cross-site/app identity, consumers enjoy less free content
This depends on how you measure content and how you define enjoy.The Kircher and Foerderer paper states that, although children’s games for Android got fewer updates on average after a targeted advertising policy change by Google,
Only exceptionally well-rated and demanded games experienced more feature updates, which could be interpreted as a sign of opportunity due to better monetization potential or weakened competition. However, considering that we observed these effects only for games in the highest decile of app quality and demand and given that the median user rating of a game is 4.1 of 5, our findings suggest widespread game abandonment.
By Sturgeon’s Law, a policy change that benefits the top 10% of games but not the bottom 90% (which, in total, account for a small fraction of total installs and an even smaller fraction of gameplay) is a win for the users.
We find that more targeting increases competition and reduces the websites’ profits, but yet in equilibrium websites choose maximum targeting as they cannot credibly commit to low targeting. A privacy protection policy can be beneficial for both consumers and websites.
When both personalized and non-personalized ad impressions are available in the same market, the personalized impressions tend to go for about double the non-personalized. But it doesn’t work to artificially turn off some data collection for a fraction of ad impressions, observe that revenue for those impressions is lower (compared to impressions with the data that are still available), and then extrapolate the revenue difference to a market in which no impressions have the data available.
It is also important to consider the impact of extremely low-quality and/or illegal content in the personalized advertising market. Much of the economic role of ad personalization is not to match the right ad to the right user but to monetize a higher-value user on lower-value content. The surveillance economy is more like the commodification economy. Surveillance advertising companies are willing to pursue content commodification even to the point of taking big reputational risks from feeding ad money to the worst people on the Internet (Hiding in Plain Sight: The Ad-Supported Piracy Ring Driving Over a Billion Monthly Visits - deepsee.io, Senators Decry Adtech Failures as Ads Appear On CSAM Site). If advertising intermediaries were more limited in their ability to put a good ad on a bad site using user tracking, the higher-quality content sites would enjoy significantly increased market power.
p. 14 Restrictions to limit the effectiveness of digital advertising would likely disproportionately disadvantage small businesses, since nine out of ten predominantly use digital advertising, especially on Meta
Are small businesses really better off in the surveillance advertising era? Although personalized Big Tech advertising is the main ad medium available to small businesses today, there is clearly some survivorship bias going on here. The Kerrigan and Keating paper states that, While entrepreneurship has rebounded since the Great Recession and its aftermath, startup activity remains weak by historical standards. This period of time overlaps with the golden age of personalized advertising, after widespread adoption of smartphones but before Apple’s ATT, the EU’s GDPR, and California’s CCPA. If personalized advertising is so good for small businesses, where are the extra small businesses enabled by it? We should have seen a small business boom in the second half of the 2010s, after most people in the USA got smartphones but before CCPA and ATT.
Jakob Nielsen may have provided the best explanation in 2006’s Search Engines as Leeches on the Web, which likely applies not just to search, but to other auction-based ad placements like social media advertising. An auction-based advertising platform like those operated by Google and Meta is able to dynamically adjust its advertising rates to capture all of the expected incremental profits from the customers acquired through it.
Part of the missing small business effect may also be caused by platform concentration. If, instead of an advertising duopoly, small businesses had more options for advertising, the power balance between platform (rentier) and small business (entrepreneur) might shift more toward the latter. See also Crawford et al., The antitrust orthodoxy is blind to real data harms. Policy makers might choose to prioritize pro-competition privacy legislation such as surveillance licensing for the largest, riskiest platforms in order to address competition concerns in parallel with privacy ones.
p. 15 Since PETs are costly for firms to implement, forward-looking regulation should consider how to incentivize PET adoption and innovation further.
In a section about how so-called privacy-enhancing technologies (PETs) have equal perceived privacy violation and bigger competition issues than conventional personalization, why recommend incentivizing PETs? The works cited would better support a recommendation to have a more detailed or informative consent experience for PETs than for cookie-based tracking. Because PETs obfuscate real-world privacy problems such as fraud and algorithmic discrimination, it would be more appropriate to require additional transparency, and possibly licensing, for PETs.
PETs, despite their mathematical appeal to many at Big Tech firms, have a long list of problems when applied to the real world. The creeped-out attitude of users toward PETs is worth paying attention to, as people who grow up in market economies generally develop good instincts about information in markets—just like people who grow up playing ball games can get good at catching a ball without consciously doing calculus. Policymakers should pay more attention to user perceptions—which are based on real-world market activity—than to mathematical claims about developers’ PET projects. PETs should be considered from the point of view of regulators investigating discrimination and fraud complaints, which are often difficult to spot on large platforms. Because PETs have the effect of shredding the evidence of platform misdeeds, enabling the existing problems of adtech, just in a harder-to-observe way, they need more scrutiny, not incentivization.
Coming soon: a useful large-scale experiment
Policymakers may soon be able to learn from what could be the greatest experiment on the impact of ad personalization ever conducted.
If Meta is required to offer Facebook users in the European Union a meaningfully de-personalized ad experience (and not just the less personalized ads option that still allows for personalization using fraud risk factors like age, gender, and location) then there will be a chance to measure what happens when users can choose personalized or de-personalized ads on a service that is otherwise the same.
I put these links and notes together to help myself out when someone drops a link to the Dubé et al. paper into an Internet argument, and put them up here in the hope that they will help others. Hardly anyone will read all the literature in this field, but a lot of the most interesting research is still found in corners of the library that Big Tech isn’t actively calling attention to.
Thanks to Fengyang Lin for reviewing a draft of this post.
Too often, well-intentioned regulation misses the mark. This can be due to poor design, poor implementation, poor compliance, or failure to address unintended consequences. But the EU’s Digital Markets Act (DMA) has the potential to be different.
The DMA is a regulatory framework that came into effect in the EU in March 2024. It covers a range of services, including browsers, where it empowers people in the EU to choose a browser for themselves.
Twelve months later, the verdict’s in, and it proves what 98% of people told us before the DMA even kicked in last year: People want browser choice. And when they are given real choice, they will opt for a browser that serves their needs and preferences.
For many EU consumers, this choice has been Firefox — an independent browser that offers the features they want in terms of privacy, safety, productivity and speed.
Why is the DMA important?
The DMA is a first-of-its-kind regulation. Its aim? Leveling the playing field so that EU consumers can discover and use products from smaller, innovative companies without being blocked by gatekeeper operating systems. In practice? When it comes to browsers, it means putting real choice in the hands of users. The desired outcome? Removing barriers to choice such as the complex device settings consumers have to navigate to change their pre-installed browser — and enabling them to keep their choice.
Under the DMA, certain operating system providers are required to prompt users to actively select their preferred default web browser through a choice screen.
What is a browser choice screen and when will I see one?
Browser choice screens are a seemingly simple solution — a menu of options listed for you to choose your preferred default browser.
The first DMA browser choice screens started rolling out in the EU in March 2024. Since then, they have slowly started appearing for:
New and existing Android smartphones and tablet users with Chrome pre-set as a default browser (though rollout has been fairly inconsistent)
New and existing iOS users with Safari as their default browser, who have iOS 18.2 and iPadOS 18.2 or later iOS versions installed on their device (initial roll out in iOS 17.4 was poorly designed)
Unfortunately, if you’re a smartphone user outside the EU — or a Windows/Mac user anywhere — you won’t have seen the benefit of browser choice screens. Yet.
Why does browser choice matter?
From our research, we know that when well-designed and fully implemented, browser choice screens can be a powerful tool. They can not only provide people with real choice but can also have a huge impact on their levels of satisfaction with their tech by giving them freedom to customize their device experience more easily and quickly. Just as important, browser choice screens can promote user choice without degrading the user experience or causing unintended harm to consumers, competition and innovation.
Browser choice screens also matter because they allow people to opt for independent alternatives like Firefox that are not tied to an operating system or device manufacturer. This makes them a critical intervention against the self-preferencing deployed by device manufacturers and operating systems, which push people to use their own label browsers and services.
What happens when you choose for yourself?
Despite vague compliance plans and some obvious gatekeeper non-compliance preventing the DMA from reaching its full potential, one year on we’re starting to see how targeted regulation can help tackle some of the barriers to competition in the browser space and what can happen if the power of browser choice is in the hands of consumers.
Since the launch of the first DMA browser choice screens on iOS in March 2024, people are making themselves heard: Firefox daily active users in Germany alone have increased by 99%. And in France, Firefox’s daily active users on iOS grew by 111%.
This growth has also been fueled by a number of new features coming to Firefox — from enhanced privacy controls and performance updates to new productivity tools — but the effect of the DMA is clear. When people are given browser choice, they vote with their feet for a product they love and stick with it.
And we’ve found that when people choose Firefox via a DMA choice screen, they stick with it.
Why choose Firefox?
When Firefox was launched 20 years ago, our mission was to provide people with an alternative choice for a browser that prioritises user privacy, transparency and openness.
The internet has changed dramatically since then, but our mission to keep the internet open and accessible to everyone is more important than ever. This is why we’re continuously improving Firefox and working on providing users with real choice, giving them control of their internet experience through privacy and productivity enhancing features.
Hello, everyone, and welcome to the first Android Progress Report of 2025. We’re ready to hit the ground running improving Thunderbird for Android experience for all of our users. Our January/February update involves a look at improvements to the account drawer and folders on our roadmap, an update on Google and K-9 Mail, and explores our first step towards Thunderbird on iOS.
Account Drawer Improvements
As we noted in our last post on the blog, improving the account drawer experience is one of our top priorities for development in 2025. We heard your feedback and want to make sure we provide an account drawer that lets you navigate between accounts easily and efficiently. Let’s briefly go into the most common feedback:
The accounts on the same domains or with similar names are difficult to distinguish from the two letters provided.
It isn’t clear how the account name influences the initials.
The icons seemed to be jumping around, especially obvious with 3–5 accounts.
There is a lot of spacing in the new drawer.
Users would like more customization options, such as an account picture or icon.
Some users would like to see a broader view that shows the whole account name.
With just one account, the accounts sidebar isn’t very useful.
Our design folks are working on some mockups on where the journey is taking us. We’re going to share them on the beta topicbox where you can provide more targeted feedback, but for a sneak peek here is a medium-fidelity mockup of what the new drawer and settings could look like:
On the technical side, we’ve integrated an image loader for the upcoming pictures. We now need to gradually adapt the mockups. We will begin with the settings screen changes and then adapt the drawer itself to follow.
Notifications and Error States
Some of you had the feeling your email was not arriving quick enough. While email delivery is reliable, there are a few settings in Thunderbird for Android and K-9 mail that aren’t obvious leading to confusion. When permissions are not granted, functionality is simply turned off instead of telling the user they actually need to grant the alarms permission for us to do a regular sync. Or maybe the sync interval is simply set to the default of 1 hour.
We’re still in the process of mapping out the best experience here, but will have more updates soon. See the notifications support article in case you are experiencing issues. A few things we’re aiming for this year:
Show an indicator in foreground service notification when push isn’t working for all configured folders
Show more detailed information when foreground service notification is tapped
Move most error messages from the system notifications to an area in-app to clearly identify when there is an error
Make authentication errors, certificate errors, and persistent connectivity issues use the new in-app mechanism
Make the folder synchronization settings more clear (ever wondered why there is “sync” and “push” and if you should have both enabled or not?)
Prompt for permissions when they are needed, such as aforementioned alarms permission
Indicate to the user if permissions are missing for their folder settings.
Better debug tool in case of notification issues.
Road(map) to the Highway
Our roadmap is currently under review from the Thunderbird council. Once we have their final approval, we’ll update the roadmap documentation. While we’re waiting, we would like to share some of the items we’ve proposed:
Listening to community feedback on Mozilla Connect and implementing HTML signatures and quick filter actions, similar to the Thunderbird Desktop
Backend refactoring work on the messages database to improve synchronization
Improving the message display so that you’ll see fewer prompts to download additional messages
Adding Android 15 compatibility, which is mainly Edge to Edge support
Improving the QR code import defaults (relates to notification settings as well)
Making better product decisions by (re-)introducing a limited amount of opt-in telemetry.
Does that sound exciting to you? Would you like to be a part of this but don’t feel you have the time? Are you good at writing Android apps in Kotlin and have an interest in muti-platform work? Well, do I have a treat for you! We’re hiring an Android Senior Software Engineer to work on Thunderbird for Android!
K-9 Mail Blocked from Gmail
We briefly touched on this in the last update as well: some of our users on K-9 Mail have noticed issues with an “App Blocked” error when trying to log into certain Gmail accounts. Google is asking K-9 Mail to go through a new verification process and has introduced some additional requirements that were not needed before. Users that are already logged in or have logged in recently should not be affected currently.
Meeting these requirements depended on several factors beyond our control, so we weren’t able to resolve this immediately.
If you are experiencing this issue on K-9 Mail, the quickest workaround is to migrate to Thunderbird for Android, or check out one of the other options on the support page. For those interested, more technical details can be found in issue 8598. We’re using keys on this application that have so far not been blocked. Our account import feature will make this transition pretty seamless.
We’ve been able to make some major progress on this, we have a vendor for the required CASA review and expect the letter of validation to be shared soon. We’re still hitting a wall with Google, as they are giving us inconsistent information on the state of the review, and making some requirements on the privacy policy that sound more like they are intended for web apps. We’ve made an effort to clarify this further and hope that Google will accept our revised policy.
If all goes well we’ll get approval by the end of the month, and then need to make some changes to the key distribution so that Thunderbird and K-9 use the intended keys.
Our Plans for Thunderbird on iOS
If you watched the Thunderbird Community Office Hours for January, you might have noticed us talking about iOS. You heard right – our plans for the Thunderbird iOS app are getting underway! We’ve been working on some basic architectural decisions and plan to publish a barebones repository on GitHub soon. You can expect a readme and some basic tools, but the real work will begin when we’ve hired a Senior Software Engineer who will lead development of a Thunderbird app for the iPhone and iPad. Interviews for some candidates have started and we wish them all the best!
With this upcoming hire, we plan to have alpha code available on Test Flight by the end of the year. To set expectations up front, functionality will be quite basic. A lof of work goes into writing an email application from scratch. We’re going to be focusing on a basic display of email messages, and then expanding to triage actions. Sending basic emails is also on our list.
FOSDEM
Our team recently attended FOSDEM in Brussels, Belgium. For those unfamiliar with FOSDEM, it’s the Free and Open Source Software Developers’ European Meeting—an event where many open-source enthusiasts come together to connect, share knowledge and ideas, and showcase the projects they’re passionate about.
We received a lot of valuable feedback from the community on Thunderbird for Android. Some key areas of feedback included the need for Exchange support, improvements to the folder drawer, performance enhancements, push notifications (and some confusion around their functionality), and much more.
Our team was highly engaged in listening to this feedback, and we will take all of it into account as we plan our future roadmap. Thunderbird has always been a project developed in tandem with our community and it was exciting for us to be at FOSDEM to connect with our users, contributors and friends.
In other news…
As always, you can join our Android-related mailing lists on TopicBox. And if you want to help us test new features, you can become a beta tester.
This blog post talks a lot about the exciting things we have planned for 2025. We’re also hiring for two positions, and may have a third one later in the year. While our software is free and open source, creating a world class email application isn’t without a cost. If you haven’t already made a contribution in January, please consider supporting our work with a financial contribution. Thunderbird for Android relies entirely on user funding, so without your support we could likely only get to a fraction of what you see here. Making a contribution is really easy if you have Thunderbird for Android or K-9 Mail installed, just head over to the settings and sign up directly from your device.
In October 2024, I joined Outreachy as an Open Source contributor and in December 2024, I joined Outreachy as an intern working with Mozilla. My role was to implement the TC39 Range Proposal in the SpiderMonkey JavaScript engine.
Iterator.range is a new built-in method proposed for JavaScript iterators that allows generating a sequence of numbers within a specified range. It functions similarly to Python’s range, providing an easy and efficient way to iterate over a series of values:
for(constiofIterator.range(0,43))console.log(i);// 0 to 42
In this blog post, we will explore the implementation of Iterator.range in the SpiderMonkey JavaScript engine.
Understanding the Implementation
When I started working on Iterator.range, the initial implementation had been done, ie; adding a preference for the proposal and making the builtin accessible in the JavaScript shell.
The Iterator.range simply returned false, a stub indicating that the actual implementation of Iterator.range was under development or not fully implemented, which is where I came in. As a start, I created a CreateNumericRangeIterator function that delegates to the Iterator.range function. Following that, I implemented the first three steps within the Iterator.range function. Next, I initialised variables and parameters for the NUMBER-RANGE data type in the CreateNumericRangeIteratorfunction.
I focused on implementing sequences that increase by one, such as Iterator.range(0, 10).Next, I created an IteratorRangeGenerator* function (ie, step 18 of the Range proposal), that when called doesn’t execute immediately, but returns a generator object which follows the iterator protocol. Inside the generator function you have yield statements which represents where the function suspends its execution and provides value back to the caller. Additionaly, I updated the CreateNumericRangeIterator function to invoke IteratorRangeGenerator* with the appropriate arguments, aligning with Step 19 of the specification, and added tests to verify its functionality.
The generator will pause at each yield, and will not continue until the next method is called on the generator object that is created.
The NumericRangeIteratorPrototype (Step 27.1.4.2 of the proposal) is the object that holds the iterator prototype for the Numeric range iterator. The next() method is added to the NumericRangeIteratorPrototype, when you call the next() method on an object created from NumericRangeIteratorPrototype, it doesn’t directly return a value, but it makes the generator yield the next value in the series, effectively resuming the suspended generator.
The first time you invoke next() on the generator object created via IteratorRangeGenerator*, the generator will run up to the first yield statement and return the first value. When you invoke next() again, theNumericRangeIteratorNext() will be called.
This method uses GeneratorResume(this), which means the generator will pick up right where it left off, continuing to iterate the next yield statement or until iteration ends.
Generator Alternative
After discussions with my mentors Daniel and Arai, I transitioned from a generator-based implementation to a more efficient slot-based approach. This change involved defining slots to store the state necessary for computing the next value. The reasons included:
Efficiency: Directly managing iteration state is faster than relying on generator functions.
Simplified Implementation: A slot-based approach eliminates the need for generator-specific handling, making the code more maintainable.
Better Alignment with Other Iterators: Existing built-in iterators such as StringIteratorPrototype and ArrayIteratorPrototype do not use generators in their implementations.
Perfomance and Benchmarks
To quantify the performance improvements gained by transitioning from a generator-based implementation to a slot-based approach, I conducted comparative benchmarks using a test in the current bookmarks/central, and in the revision that used generator-based approach. My benchmark tested two key scenarios:
Floating-point range iteration: Iterating through 100,000 numbers with a step of 0.1
BigInt range iteration: Iterating through 1,000,000 BigInts with a step of 2
Each test was run 100 times to eliminate anomalies. The benchmark code was structured as follows:
// Benchmark for Number iterationvarsum=0;for(vari=0;i<100;++i){for(numofIterator.range(0,100000,0.1)){sum+=num;}}print(sum);// Benchmark for BigInt iterationvarsum=0n;for(vari=0;i<100;++i){for(numofIterator.range(0n,1000000n,2n)){sum+=num;}}print(sum);
Results
Implementation
Execution Time (ms)
Improvement
Generator-based
8,174.60
-
Slot-based
2,725.33
66.70%
The slot-based implementation completed the benchmark in just 2.7 seconds compared to 8.2 seconds for the generator-based approach. This represents a 66.7% reduction in execution time, or in other words, the optimized implementation is approximately 3 times faster.
Challenges
Implementing BigInt support was straightforward from a specification perspective, but I encountered two blockers:
1. Handling Infinity Checks Correctly
The specification ensures that start is either a Number or a BigInt in steps 3.a and 4.a. However, step 5 states:
If start is +∞ or -∞, throw a RangeError.
Despite following this, my implementation still threw an error stating that start must be finite. After investigating, I found that the issue stemmed from using a self-hosted isFinite function.
The specification requires isFinite to throw a TypeError for BigInt, but the self-hosted Number_isFinite returns false instead. This turned out to be more of an implementation issue than a specification issue.
Fix: Explicitly check that start is a number before calling isFinite:
// Step 5: If start is +∞ or -∞, throw a RangeError.if(typeofstart==="number"&&!Number_isFinite(start)){ThrowRangeError(JSMSG_ITERATOR_RANGE_START_INFINITY);}
2. Floating Point Precision Errors
When testing floating-point sequences, I encountered an issue where some decimal values were not represented exactly due to JavaScript’s floating-point precision limitations. This caused incorrect test results.
There’s a GitHub issue discussing this in depth. I implemented an approximatelyEqual function to compare values within a small margin of error.
This function ensures that minor precision errors do not cause test failures, improving floating-point range calculations.
Next Steps and Future Improvements
There are different stages a TC39 proposal goes through before it can be shipped. This document shows the different stages that a proposal goes through from ideation to consumption. The Iterator.range proposal is currently at stage 1 which is the Draft stage. Ideally, the proposal should advance to stage 3 which means that the specification is stable and no changes to the proposal are expected, but some necessary changes may still occur due to web incompatibilities or feedback from production-grade implementations.
Currently, this implementation is in it’s early stages of implementation. It’s only built in Nightly and disabled by default until such a time the proposal is in stage 3 or 4 and no further revision to the specification can be made.
Final Thoughts
Working on the Iterator.range implementation in SpiderMonkey has been a deeply rewarding experience. I learned how to navigate a large and complex codebase, collaborate with experienced engineers, and translate a formal specification into an optimized, real-world implementation. The transition from a generator-based approach to a slot-based one was a significant learning moment, reinforcing the importance of efficiency in JavaScript engine internals.
Beyond technical skills, I gained a deeper appreciation for the standardization process in JavaScript. The experience highlighted how proposals evolve through real-world feedback, and how early-stage implementations help shape their final form.
As Iterator.range continues its journey through the TC39 proposal stages, I look forward to seeing its adoption in JavaScript engines and the impact it will have on developers. I hope this post provides useful insights into SpiderMonkey development and encourages others to contribute to open-source projects and JavaScript standardization efforts.
If you’d like to read more, here are my blog posts that I made during the project:
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 on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request.
Want to get involved? We love contributions.
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.
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.
No Calls for participation were submitted this week.
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 X (formerly Twitter) or Mastodon!
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.
EuroRust 2025| 2025-05-15 | Paris | 2025-10-09–2025-10-10
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 X (formerly Twitter) or Mastodon!
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.
The performance impact of moving to Rust – and this is a common theme across everything done when we've moved from C/C++ to Rust – we saw a 5 to 15% performance Improvement.
I'll say that one of the ways that you could attack that kind of stat is say well you rewrote it so whenever you rewrite something you're going to improve it and if you'd rewritten it in C or C++ you would have also seen an improvement like that but the fact is we did not intend to get a performance Improvement. This was purely a porting exercise and we saw this now.
And the other aspect of this is that we never see performance regressions either when we're doing our ports [...]
Moritz fixed a bug where users switching between Fx versions using the same profile were unable to search and saw broken context menus. This affected a small number of users in release, and so his patch landed in a dot release.
Tabs that have been redirected to a moz-extension urls (e.g. through webRequest or DNR) can now be reloaded or navigated back successfully to the moz-extension urls in the tab history – Bug 1826867
WebExtension APIs
Starting from Firefox 136 menus.update and menus.remove API methods will return a rejected promise instead of ignoring non-existing menus – Bug 1688743
Fixed bug in DNR `initiatorDomains` and `requestDomains` conditions – Bug 1939981
Thanks to Arkadiy Tetelman for reporting and contributing a fix for this bug 🎉
DevTools
Alexandre Poirot worked on several fixes for webextensions debugging:
Fixed a regression where webextensions creating iframes would lead to blank devtools (#1941006)
Fixed a bug where content scripts could appear duplicated in the source tree, and would also result in awkward behavior when pausing / stepping (#1941681)
Improved the handling of messages logged from content scripts to avoid duplicated log entries (#1941418)
Show manifest error when reloading an addon from DevTools (#1940079)
An error message is certainly better than silently failing in this case.
Nicolas Chevobbe fixed a few accessibility and High Contrast mode issues:
Fixed the color of the close button used in sourcemap warnings to be correct in dark mode (#1942227)
Updated the netmonitor status codes to be visible in High Contrast mode (#1940749)
Nicolas Chevobbe also made several improvements to autocompletes in DevTools:
The CSS autocomplete will now provide suggestions for variables when used inside calc, for instance in width: calc(var(– (#1444772)
The autocomplete in the inspector search is now handling correctly classnames containing numbers and special characters (#1220387)
Nicolas Chevobbe addressed a long standing issue in the JSON viewer which would always display values after parsing them via JS, which could result in approximate values for big numbers or high precision decimals. The source is now always displayed, and we also show the JS parsed value next to it when relevant. (#1431808)
Julian Descottes fixed a bug with the Debugger local script override which might incorrectly show scripts as being overridden if another DevTools Toolbox previously added an override (#1940998)
Julian Descottes addressed a regression which would lead to blank devtools if any iframe on the page was showing an XML document with an invalid XSLT (#1934520)
Julian Descottes fixed an issue with the Debugger pretty printing feature, which could fail if the file contained windows-style line-breaks (#1932023)
Julian Descottes finalized an old patch to show details about the throttling profiles you can select in the network monitor and RDM (#1770932)
In case you need a reminder of what 2G speed is like.
Hubert Boma Manilla fixed a recent regression with the preview popup in the debugger which would not show the value of the hovered token (#1941269)
Hubert Boma Manilla improved the edit and resend feature in the netmonitor to properly set the security flags for the resent requests and avoid bugs for instance with requests using CORS (#1883380)
Gijs enabled the eslint-plugin-promise rule for valid-params which checks for functions on Promise being called with the correct amount of arguments.
This will protect against cases such as foo.catch() which looks like it should do something, but doesn’t.
Standard8 added a linter for checking that we don’t include package names in unpublished package.json files.
New Tab Page
The New Tab layout update has rolled out to 100% of our US population! We’re aiming to do the rest of the world soon.
Search and Navigation
Address Bar
Mandy fixed a bug so that we now correctly handle a question mark appearing at the end of a search string (1648956)
James landed a patch related to urlbar interaction tracking that ends all interactions after one hour of inactivity (1936956)
Emilio fixed a bug where, when Firefox Translations was used for a page, the address bar wasn’t showing what language the page had been translated to (1938121)
Marco fixed a bug where the search open tabs feature wasn’t finding tabs where the page had loaded with a 4xx or 5xx server status error (1939597)
Scotch Bonnet
Yazan fixed an issue where search mode was defaulting to Google after the browser was restarted (1925235)
Daisuke fixed an issue where screenreaders were failing to narrate secondary actions buttons when in actions mode (1929515)
Daisuke also fixed an issue related to using ctrl+shift+tab to navigate to the previous tab (1933243)
Daisuke fixed an issue where the unified search button dropdown wasn’t being dismissed when a new tab was opened using ctrl+T (1936545)
Marco enabled the not secure label for http for Release 136 (1937136)
Dale fixed an issue so that the search keyword is retained for contextual search mode when the engine is autofilled (1938036)
Daisuke landed a patch so that contextual search works with multiple-word searches (1938040)
Moritz fixed a bug where the unified search button icon wasn’t being refreshed correctly in private browsing windows (1938567)
Jules added support for description and support-page to the moz-radio-group (for the group itself, it was already there for individual radios) Storybook
Hanna added the moz-box-button component that will be used in the Settings redesign and some other settings throughout Firefox Storybook
The monthly Release channel is ready to help you move from annual to monthly updates in Thunderbird. This update lets you know how to switch from the annual update (ESR) to monthly updates (Release), why you might have to wait, and what features you’ll get first!
How do I switch from annual to monthly updates (ESR to Release)?
Right now, you can switch to the Release channel through manual installs only from the Thunderbird website Downloads page. Other installation sources will have the Release version in the future such as Windows Store, 3rd-party sites and various Linux packages such as Snap, Flatpak.
First, back up your profile data, as you should always do before making major changes. And check that your computer meets the System Requirements for version 136. Then go to the Downloads page of the website. If Release Channel does not show “Thunderbird Release” then correct it. Click the ‘Download’ button. For Windows and macOS, run the downloaded file to install the monthly release into the same directory where the ESR is currently installed. (If you have installed Thunderbird ESR into a directory that is different from the default location, then you must do a custom installation to that directory.) For Linux, consult the Linux installation knowledge base (KB) article.
What’s new in 136.0?
Now that you know how to make the switch, here’s some reasons to make the change. Here are some of the key features you’ll get as soon as you upgrade to the Release channel:
Improved Dark Reader
Enable dark reader for the message pane with `mail.dark-reader.enabled` preference
The rustup team is happy to announce the release of rustup version 1.28.1.
Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.
Challenges with rustup 1.28.0
rustup 1.28.0 was a significant release with many changes, and there was a quick response from many
folks that this release broke their processes. While we considered yanking the release, we worried
that this would cause problems for people who had already updated to adopt some of the changes.
Instead, we are rolling forward with 1.28.1 today and potentially further bugfix releases to
address the feedback that comes in.
We value all constructive feedback -- please keep it coming in the issue tracker. In particular,
the change with regard to implicit toolchain installation is being discussed in this issue.
What's new in rustup 1.28.1
This release contains the following fixes:
Automatic install is enabled by default but can be opted out by setting RUSTUP_AUTO_INSTALL
environment variable to 0. pr#4214pr#4227
rustup show active-toolchain will only print a single line, as it did in 1.27. pr#4221
Fixed a bug in the reqwest backend that would erroneously timeout downloads after 30s. pr#4218
If you have a previous version of rustup installed, getting rustup 1.28.1 is as easy as stopping
any programs which may be using Rustup (e.g. closing your IDE) and running:
$ rustup self update
Rustup will also automatically update itself at the end of a normal toolchain update:
$ rustup update
If you don't have it already, you can get rustup from the appropriate page on our website.
Rustup's documentation is also available in the rustup book.
Caveats
Rustup releases can come with problems not caused by rustup itself but just due to having a new release.
As such, we recommend paying attention to the following potential issues in particular:
Anti-malware scanners might be blocking rustup or stopping it from creating or copying files
(especially when installing rust-docs, since it contains many small files).
In your CI environment, rustup might fail when trying to perform a self-update.
This is a known issue,
and in the case where this issue does occur, we recommend applying the following workaround at the beginning of your workflow:
$ rustup set auto-self-update disable
Also, starting from 1.28.0, rustup will no longer attempt to self-update in CI environments,
so this workaround should not be necessary in the future.
These issues should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release,
and the hosted version is updated across all CI runners.
Thanks
Thanks to the rustup and t-release team members who came together to quickly address these issues.
In today’s nightly build of Firefox we introduced a simple three-state toggle for color contrast.
It allows you to choose between these options:
Automatic (use system settings)
Honor the system’s high contrast preferences in web content. If this is enabled, and say you are using a Windows High Contrast theme, the web content’s style will be overridden wherever needed to display text and links with the system’s colors.
Off
Regardless of the system’s settings the web content should be rendered as the content author intended. Colors will not be forced.
Custom
Always force user specified colors in web content. Colors for text and links foreground and background can be specified in the preferences UI.
Who Would Use This and How Would They Benefit?
There are many users with varying degrees of vision impairment that benefit from having control over the colors and intensity of the contrast between text and its background. We pride ourselves in Firefox for offering fine grained control to those who need it. We also try to do a good job anticipating the edge cases where forced high contrast might interfere with a user’s experience, for example we put a solid background backplate under text that is superimposed on top of an image.
But, the web is big and complex and there will always be cases where forced colors will not work. For example, take this Wordle puzzle:
The gold tiles indicate letters that are in the hidden word, and gold tiles represent letters that are in the word and in the right place in the word.
When a user is in forced colors mode, the background of the tiles disappears and the puzzle becomes unsolvable:
What More Can We Expect?
The work we did to add contrast control to the settings is a first step in allowing a user to quickly configure their web browser experience in order to adapt to their current uses. Just like text zoom, there is no one-size-fits-all. We will be working to allow users to easily adjust their color contrast settings as they are browsing and using the web.
The Mozilla Add-ons team is excited to announce that developers can now style content on addons.mozilla.org (AMO) using Markdown.
From the early days of AMO developers have been able to style parts of their add-ons’ listings using basic HTML tags like <b>, <code>, and <abbr>. This has been a great way for developers to emphasize information or add character to their listings. This feature has, unfortunately, also been a common source of mistakes. It’s not unusual to see HTML tags in listings due to closing tags, typos, or developers trying to use unsupported HTML elements.
To address this common source of errors and to better align with other tools that developers use, Mozilla has replaced AMO’s limited HTML support with a limited set of Markdown.
Our flavor of Markdown
AMO supports about a dozen Markdown rules: bold, italic, monospace, links, abbreviations, code blocks, blockquotes, ordered lists, and unordered lists. HTML is not supported. The full list of supported syntax and examples can be found in our documentation.
Currently, Markdown can be used in four areas: an add-on’s description, a custom license, custom privacy policy, and in review replies posted by the developer.
As before, links are automatically replaced by a version that is routed through AMO’s link bouncer.
How this change affects HTML content
AMO’s Markdown does not support HTML content. As a result, any HTML entered in a field that supports Markdown will display as plain text.
This change is not retroactive. Any content authored while HTML was supported will continue to display as originally intended. Only content updated after Markdown support was added will be treated as Markdown.
Mozilla is not the same company it was when I joined.
No one on the C-level is here for as long as I am.
There have been 5 larger reorgs in the past year and two layoffs in different departments, plus the big round of layoffs at the Mozilla Foundation.
My part of the organization was moved around again and for the moment Data Engineering is nested under the Infrastructure Org.
Good colleagues left or were laid off.
Just recently my team shrunk again.
Notably I haven't posted anything under the mozilla tag since 2022, other than my Moziversary blog posts.
All-Hands MozWeek1 Dublin happened.
The next one will be in Washington, D.C.
Probably one of the worst choices given the state of the USA right now, and I might just skip it.
I do hope for a team work week, but that's not decided yet.
The one constant over the past years is my work on Glean, which hasn't stopped.
We're finally putting dedicated effort to move legacy telemetry in Firefox Desktop over to Glean (Are we Glean yet?).
But still Glean isn't where I'd like it to be.
Some of the early decisions in its design are coming back to bite us,
the codebase grew significantly and could use a bit of cleanup,
we never got the time to work on performance and memory improvements and our chosen local data storage desperately needs an update.
Some of that was on my list last year already.
If only there were less distractions that pull me of this work again and again.
It's on my list of goals again this year, so maybe it works out better this time.
But other than that I don't know where Mozilla will be a year from now.
It's going to be a challenging year.
Thank you
I'm in this job for seven years not only because I like the tech I get to work on,
but also because my colleagues make it a delight to come back to work every day.
Thanks to Alessio, Chris, Travis and Abhishek for being the Data Collection Tools team.
Also thanks to Bruno, who was part of the team until recently.
There's countless other people at Mozilla,
inside Data Engineering but also across other parts of the organization,
that I got to connect, chat and work with. Thank you!
Footnotes:
1
Change everywhere. Those Mozilla work weeks were renamed by Marketing.
This is the first Project Goals update for the new 2025h1 period. For the first 6 months of 2025, the Rust project will work towards a slate of 39 project goals, with 3 of them designed as Flagship Goals. This post provides selected updates on our progress towards these goals (or, in some cases, lack thereof). The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository.
Why this goal? This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the dynosaur crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 our plan is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the async-trait crate; (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of Pin, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.
What has happened? The biggest news is that Rust 1.85 is stable and includes two major features that impact Async Rust. The first is async closures, which has been on many people's wish lists for a long time and was expertly moved forward by @compiler-errors over the last year.
The second feature included in 1.85 is the new lifetime capture rules as part of Rust 2024 edition. This should substantially improve the experience of using async Rust anytime a user writes -> impl Future, as it removes the need for + '_ or similar bounds in most cases. It will also lead to an easier to understand language, since those bounds only worked by exploiting the more subtle rules of impl Trait in a way that runs contrary to their actual semantic role in the language. In the 2024 Edition, the subtle rule is gone and we capture all input lifetimes by default, with the ability to use + use<> syntax to opt out. See this blog post for more.
Generators. The lang team also held a design meeting to review the design for generators, with the outcome of the last one being that we will implement a std::iter::iter! macro (exact path TBD) in the compiler, as a lang team experiment that allows the use of the yield syntax. We decided to go in this direction because we want to reserve gen for self-borrowing and perhaps lending generators, and aren't yet decided on which subset of features to expose under that syntax. This decision interacts with ongoing compiler development that isn't ready yet to enable experimentation with lending.
Our hope is that in the meantime, by shipping iter! we will give people the chance to start using generators in their own code and better understand which limitations people hit in practice.
As you may have noticed, I'm not talking about async generators here. Those are the ultimate goal for the async initiative, but we felt the first step should be clarifying the state of synchronous generators so we can build on that when talking about async ones.
Dynosaur.dynosaur v0.1.3 was released, with another release in the works. We think we are approaching a 1.0 release real soon now (tm). At this point you should be able to try it on your crate to enable dyn dispatch for traits with async fn and other -> impl Trait methods. If you need to use it together with #[trait_variant], you may need to wait until the next release when #55 is fixed.
The first update is the release of Rust 1.85, which had at least two major features that impact Async Rust. The first is async closures, which has been on many people's wish lists for a long time and was expertly moved forward by @compiler-errors over the last year.
The second is the new lifetime capture rules as part of Rust 2024 edition. This should substantially improve the experience of using async Rust anytime a user writes -> impl Future, as it removes the need for + '_ or similar bounds in most cases. It will also lead to an easier to understand language, since those bounds only worked by exploiting the more subtle rules of impl Trait in a way that runs contrary to their actual semantic role in the language. In the 2024 Edition, the subtle rule is gone and we capture all input lifetimes by default, with the ability to use + use<> syntax to opt out. See this blog post for more.
Generators
The lang team held two design meetings on generators, with the outcome of the last one being that we will implement a std::iter::iter! macro (exact path TBD) in the compiler, as a lang team experiment that allows the use of the yield syntax. We decided to go in this direction because we want to reserve gen for self-borrowing and perhaps lending generators, and aren't yet decided on which subset of features to expose under that syntax. This decision interacts with ongoing compiler development that isn't ready yet to enable experimentation with lending.
Our hope is that in the meantime, by shipping iter! we will give people the chance to start using generators in their own code and better understand which limitations people hit in practice.
As you may have noticed, I'm not talking about async generators here. Those are the ultimate goal for the async initiative, but we felt the first step should be clarifying the state of synchronous generators so we can build on that when talking about async ones.
dynosaur
dynosaur v0.1.3 was released, with another release in the works. We think we are approaching a 1.0 release real soon now (tm). At this point you should be able to try it on your crate to enable dyn dispatch for traits with async fn and other -> impl Trait methods. If you need to use it together with #[trait_variant], you may need to wait until the next release when #55 is fixed.
Why this goal? May 15, 2025 marks the 10-year anniversary of Rust's 1.0 release; it also marks 10 years since the creation of the Rust subteams. At the time there were 6 Rust teams with 24 people in total. There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust project will be coming together for RustWeek 2025, a joint event organized with RustNL. Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the Rust Vision Doc, a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.
What has happened? Planning is proceeding well. In addition to Rust maintainers, we are inviting all project goal owners to attend the All Hands (note that the accompanying RustWeek conference is open to the public, it's just the All Hands portion that is invitation only). There are currently over 100 project members signed up to attend.
For those invited to the All Hands:
Travel funds may be available if you are unable to finance travel through your employer. Get in touch for details.
Please participate in the brainstorm for how best to use the All Hands time in the all-hands-2025 Zulip stream.
If you do plan to attend, please purchase your travel + hotels in a timely fashion as the discount rates will expire.
Why this goal? This goal continues our work from 2024H2 in supporting the experimental support for Rust development in the Linux kernel. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement RFC #3716 which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).
What has happened? We established the precise set of 2025H1 deliverables and we have been tracking them and have begun making progress towards them. Rustdoc has been updated to support extracting doc tests so that the Kernel can execute them in a special environment (this was previously done with a big hack) and RFL is in the process of trying to use that new support. The first PR towards the implementation of RFC #3716 has landed and the ARM team has begun reading early drafts of the design doc for -Zbuild-core with the cargo team.
We are also working to finalize the stabilization of the language features that were developed in 2024H2, as two late-breaking complications arose. The first (an interaction between casting of raw pointers and arbitrary self types) is expected to be resolved by limiting the casts of raw pointers, which previously accepted some surprising code. We identified that only a very small set of crates relied on this bug/misfeature; we expect nonetheless to issue a forwards compatibility warning. We are also resolving an issue where derive(CoercePointee) was found to reveal the existence of some unstable impls in the stdlib.
re-stabilize CoercePointee -- Alice is looking at this, it's a good opportunity to try out the new template that is being discussed
stabilize arbitrary self types v2 -- @adetaylor left a comment 3 weeks ago indicating that everything was more-or-less landed. RFL is already using it, providing evidence that it works reasonably well. Next steps are then sorting out documentation and moving to stabilize.
asm-goto -- ready for stabilization, not been merged yet, still doing some work on the Rust reference (PRs https://github.com/rust-lang/rust/pull/133870, https://github.com/rust-lang/reference/pull/1693)
ABI-modifying flags
The rust-lang/rfcs#3716 is now in Final Comment Period (FCP). There is a preliminary implementation in #133138 that @petrochenkov is going to be reviewing. Some more work will be needed to test, cleanup, etc after that lands.
We went through a series of flags from that RFL uses and looking into what might be blocking each of them. The process to stabilize one of these is basically to prepare the stabilization PR (minimal, but we need to rename the flag from -Z to -C) with a stabilization report and proper docs and then cc @davidtwco or @wesleywiser to prepare stabilization. In most cases we need to document how the flags can be misused, most commonly by linking against std or other crates not built with the same flags. If there are major correctness concerns as a result we likely want to consider the flag as "ABI-modifying".
ability to extract dependency info, currently using -Zbinary_dep_depinfo=y -- basically ready to stabilize
* tmandry: Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing.
-Zcrate-attr, used to configure no-std without requiring it in the source file -- no real concerns
-Zunpretty=expanded -- have to clearly document that the output is not stable, much like we did for emitting MIR. This is already "de facto" stable because in practice cargo expand uses RUSTC_BOOTSTRAP=1 and everybody uses it.
-Zno-jump-tables -- this should be considered an ABI-modifying flag because we believe it is needed for CFI and therefore there is a risk if incompatible modules are linked.
-Zdwarf-version, -Zdebuginfo-compression -- this should be ready to stabilize, so long as we document that you should expect a mix of debuginfo etc when mixing things compiled with different versions (notably libstd, which uses DWARF4). Debuggers are already prepared for this scenario. zstd compression is supported as of Rust 1.82.0.
stable rustdoc features allowing the RFL project to extract and customize rustdoc tests (--extract-doctests)
@imperio authored https://github.com/rust-lang/rust/pull/134531, which is now up for review. Once PR lands, RFL will validate the design, and it can proceed to stabilization.
clippy configuration (possibly .clippy.toml and CLIPPY_CONF_DIR)
We discussed with clippy team, seems like this is not a big deal, mostly a doc change, one concern was whether clippy should accept options it doesn't recognize (because they may come from some future version of clippy). Not a big deal as of now, RFL only uses (msrv, check-private-items=true, disallowed-macros).
rebuild libcore
ARM team is working on this as part of this project goal, expect updates. 🎉
Arbitrary self types v2: Stabilization PR is open (rust-lang/rust#135881).
Stabilize CoercePointee: RFL is using it now; we are making progress towards completing the stabilization.
2025H1
ABI-modifying flags RFC (rust-lang/rfcs#3716) has completed FCP and needs to be merged. Implementation PR #133138 authored by @azhogin remains under review.
Other compiler flags, we made a prioritized list. One easy next step would be to rename all -Z flags in this list to something stabilizable (e.g., -C) that requires -Zunstable-features.
[ ] -Zdwarf-version -- wesley wiser
[ ] -Zdebuginfo-compression, unblocked
[ ] -Zcrate-attr, used to configure no-std without requiring it in the source file, no real concerns
[ ] -Zunpretty=expanded, unblocked, maybe needs a PR that says "don't rely on this", Linux only uses it for debugging macros (i.e. not in the normal build, so it is less critical). Needs a stable name, e.g., --emit macro-expanded, and we should make sure output cannot be piped to rustc. rustfmt told us (Rust for Linux) that they will try their best to keep rustfmt able to format the output of the expansion.
[ ] -Zno-jump-tables, considered an ABI-modifying flag
[ ] -Zbinary_dep_depinfo=y -- basically ready to stabilize (@tmandry asked "Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing", but we don't understand this point yet, as they were not present in the meeting).
stable rustdoc: PR rust-lang/rust#134531 is under review, should land soon, then next step will be for RFL folks to try it out.
Clippy configuration: no progress, discussed some new options and posted in thread, very minimal work required here.
rebuild libcore: @davidtwco wasn't present so no update, but we know progress is being made
Publicizing this work
We discussed briefly how to better get the word out about this collaboration. Some points:
@Darksonn will be speaking at Rust Nation
We could author a Rust-lang blog post, perhaps once the language items are done done done?
LWN article might be an option
general-regs-only
We discussed the possibility of a flag to avoid use of floating point registers, no firm conclusion yet reached.
Given the recent controversy about Rust usage in the Kernel, the RFL group wrote up a policy document explainer to explain the policy, and there was a write-up on LWN.
Regarding arbitary self types and coerce pointee, we are waiting on rust-lang/rust#136764 and rust-lang/rust#136776. The former is on lang team FCP. The latter has received approval from lang team and is awaiting further impl work by @BoxyUwU.
@ojeda is looking into how to manage dependency information and configure no-std externally.
@GuillaumeGomez's impl of rustdoc features has landed and we are waiting on RFL to experiment with it.
@davidtwco's team at ARM has authored a document regarding a blessed way to build-std and are collecting feedback.
@wesleywiser is preparing a PR to add -Zdwarf-version to help advance compiler flags.
There is an annoying issue related to cfg(no_global_oom_handling), which is no longer used by RFL but which remains in an older branch of the kernel (6.12, LTS).
As a set of "leaf crates" that evolve together in a mono-repo-like fashion, RFL would like to have a solution for disabling the orphan rule.
Help wanted: looking for people that want to help do a bit of refactoring. Please reach out through the project-stable-mir zulip channel or repository.
Help Wanted: Looking for people that want to help do a bit of refactoring. Please reach out through the project-stable-mir zulip channel or repository.
camelid has a PR up which is ~fully finished + reviewed which enables resolving and lowering all paths under min_generic_const_args. It's taken a while to get this bit finished as we had to take care not to make parts of the compiler unmaintainable by duplicating all the logic for type and const path lowering.
An initial update on what we've been up to and some background:
This goal is submitted on behalf of the Rust team at Arm, but primarily worked on by @AdamGemmell. Anyone interested can always contact me for updates and I'll keep this issue up-to-date.
Our team has been trying to make progress on build-std by completing the issues in rust-lang/wg-cargo-std-aware but found this wasn't especially effective as there wasn't a clearly defined scope or desired outcome for most issues and the relevant teams were lacking in the necessary context to evaluate any proposals.
We've since had discussions with the Cargo team and agreed to draft a document describing the use cases, motivations and prior art for build-std such that the Cargo team can feel confident in reviewing any further proposals.
@AdamGemmell shared an initial draft of this in #t-cargo on Zulip and it is undergoing further revisions following feedback.
Following reaching a shared understanding of the context of the feature, @AdamGemmell will then draft a complete proposal for build-std that could feasibly be stabilised. It will describe the use cases which are and are not considered in-scope for build-std, and which will feature in an initial implementation.
@davidtwco is ensuring that whatever mechanism that is eventually proposed to enable build-std to work on stable toolchains will also be suitable for the Rust for Linux project to use when building core themselves.
We had a lang team design meeting about C++ interop today. The outcome was very positive, with enthusiasm for supporting an ambitious vision of C++ interop: One where a large majority of real-world C++ code can have automated bindings to Rust and vice-versa.
At the same time, the team expressed a desire to do so in a way that remains in line with Rust's values. In particular, we would not make Rust a superset of Rust+C++, but instead would define extension points that can be used to express language interop boundaries that go beyond what Rust itself allows. As an example, we could allow template instantiation via a Rust "plugin" without adding templates to Rust itself. Similarly, we could allow calling overloaded C++ methods without adding function overloading to Rust itself. Other interop needs are more natural to enable with features in the Rust language, like custom reference types.
In either case, anything we do to support interop will need to be considered on its merits. Interop is a reason to support a feature, but it is never a "blank check" to add anything we might consider useful.
The discussion so far has been at a high level. Next steps will be:
Discuss what significant-but-realistic milestones we might pursue as part of upcoming project goals, and what it would take to make them happen. Whether this happens as part of another lang team meeting or a more dedicated kickoff meeting for interested parties, I'll be sure to keep the lang team in the loop and will continue posting updates here.
Dive into more specific proposals for use cases we would like to enable in meetings with the language, library, and compiler teams.
There's a PR up https://github.com/rust-lang/rust/pull/134797 which implements the proposed RFC without the optimizations.
The PR is not yet merged and we need to continue now working on addressing comments to the PR until is merged and then start implementing optimizations.
Happy New Year everyone! After a few more rounds of feedback, the next autodiff PR recently got merged: https://github.com/rust-lang/rust/pull/130060
With that, I only have one last PR open to have a fully working autodiff MVP upstream. A few features had to be removed during upstreaming to simplify the reviewing process, but they should be easier to bring back as single PRs.
Beginning next week, I will also work on an MVP for the batching feature of LLVM/Enzyme, which enables some AoS and SoA vectorization. It mostly re-uses the existing autodiff infrastructure, so I expect the PRs for it to be much smaller.
On the GPU side, there has been a recent push by another developer to add a new AMD GPU target to the Rust compiler. This is something that I would have needed for the llvm offload project anyway, so I'm very happy to see movement here: https://github.com/rust-lang/compiler-team/issues/823
The major update so far is the release of PubGrub 0.3. This makes available the critical improvements made to allow the functionality and performance demanded by Cargo and UV. The other production users can now take advantage of the past few years of improvements. Big thanks to @konstin for making the release happen.
Other progress is been stymied by being sick with Covid for a week in January and the resulting brain fog, followed by several high-priority projects for $DAY_JOB. It is unclear when the demands of work will allow me to return focus to this project.
Now that https://github.com/rust-lang/rust/pull/135726 is merged, @jdonszelmann and I will be working on implementing EII.
We have the design for the implementation worked out on our whiteboard. We don't expect any significant blockers at this point. We'll know more once we start writing the code next week.
This is on pause until the implementation for #92 is finished. The rustc side of #92 is under review and then some additional r-a and cargo work before implementation is done and its waiting on testing and stabilization.
No progress. I will be reviewing the existing PR this weekend to see the feasibility of rebasing it versus reapplying patches by hand. My suspicion is that the latter will be preferable.
This is, I believe, mostly waiting on us on the lang team to have a look, probably in a design meeting, to feel out what's in the realm of possibility for us to accept.
Key developments: We have written and verified around 220 safety contracts in the verify-rust-std fork. 3 out of 14 challenges have been solved. We have successfully integrated Kani in the repository CI, and we are working on the integration of 2 other verification tools: VeriFast and Goto-transcoder (ESBMC)
To make it easier to follow bootstrap's test flow going into running compiletest-managed test suites, I've added more tracing to bootstrap in https://github.com/rust-lang/rust/pull/137080.
There are some prerequisite cleanups/improvements that I'm working on first to make it easier to read bootstrap + compiletest's codebase for reference: https://github.com/rust-lang/rust/pull/137224, https://github.com/rust-lang/rust/pull/136474, https://github.com/rust-lang/rust/pull/136542
I'm thinking for the prototype I'm going to experiment with a branch off of rust-lang/rust instead of completely separately, so I can experiment under the context of bootstrap and tests that we actually have, instead of trying to experiment with it in a complete vacuum (esp. with respect to staging and dependency licenses).
I'm very excited to see that this got accepted as a project goal 🥰 🎉
Let me go ahead and start by giving an initial status update of where I'm at right now.
We've already landed the initial implementation for configuring the directory where metrics should be stored which also acts as the enable flag for a default set of metrics, right now that includes ICE reports and unstable feature usage metrics
Implemented basic unstable feature usage metrics, which currently dumps a json file per crate that is compiled showing which metrics are enabled. (example below)
Implemented rust-lang/rust/src/tools/features-status-dump which dumps the status information for all unstable, stable, and removed features as a json file
setup an extremely minimal initial Proof of Concept implementation locally on my laptop using InfluxDB 3.0 Alpha and Graphana (image below)
I have a small program I wrote that converts the json files into influxdb's line protocol for both the usage info and the status info (snippets shown below)
The timestamps are made up, since they all need to be distinct or else influxdb will treat them all as updates to the same row, I'd like to preserve this information from when the metrics were originally dumped, either in the json or by changing rustc to dump via influxdb's line format directly, or some equivalent protocol. (note this is probably only necessary for the usage metrics, but for the status metrics I'd have to change the line format schema from the example below to avoid the same problem, this has to do with how influxdb treats tags vs fields)
I gathered a minimal dataset by compiling rustc with RUSTFLAGS_NOT_BOOTSTRAP="-Zmetrics-dir=$HOME/tmp/metrics" ./x build --stage 2 and ./x run src/tools/features-status-dump/, save the output to the filesystem, and convert the output to the line protocol with the aforementioned program
Write the two resulting files to influxdb
I then setup the table two different ways, once by directly querying the database using influxdb's cli (query shown below), then again by trying to setup an equivalent query in graphana (there's definitely some kinks to work out here, I'm not an expert on graphana by any means.)
from unstable_feature_usage_metrics-rustc_hir-3bc1eef297abaa83.json
Run with influxdb3 query --database=unstable-feature-metrics --file query.sql
SELECT
COUNT(*) TotalCount, "featureStatus".name
FROM
"featureStatus"
INNER JOIN "featureUsage" ON
"featureUsage".feature = "featureStatus".name
GROUP BY
"featureStatus".name
ORDER BY
TotalCount DESC
My next step is to revisit the output format, currently a direct json serialization of the data as it is represented internally within the compiler. This is already proven to be inadequate by personal experience, given the need for additional ad-hoc conversion into another format with faked timestamp data that wasn't present in the original dump, and by conversation with @badboy (Jan-Erik), where he recommended we explicitly avoid ad-hoc definitions of telemetry schemas which can lead to difficult to manage chaos.
I'm currently evaluating what options are available to me, such as a custom system built around influxdb's line format, or opentelemetry's metrics API.
Either way I want to use firefox's telemetry system as inspiration / a basis for requirements when evaluating the output format options
Relevant notes from my conversation w/ Jan-Erik
firefox telemetry starts w/ the question, what is it we want to answer by collecting this data? has to be explicitly noted by whoever added new telemetry, there's a whole process around adding new telemetry
defining metric
description
owner
term limit (expires automatically, needs manual extension)
data stewards
do data review
checks that telemetry makes sense
check that everything adheres to standards
can have downside of increasing overhead to add metrics
helps w/ tooling, we can show all this info as documentation
I have established some regular "office hour" time slots where I am available on jitsi. We landed a few minor PRs and improvements to the parser and oli-obk and tif have been working on modeling of effects for the const generics work. I'm planning to start digging more into the modeling of coherence now that the basic merging is done.
Fixing the opaque types issue breaking wg-grammar is difficult and requires a more in-depth change for which there is now an accepted Types MCP. This likely also unblocks the TAIT stabilization using the old solver.
While waiting on the MCP I've started to look into the errors when compiling nalgebra. @lqd minimized the failures. They have been caused by insufficiencies in our cycle handling. With https://github.com/rust-lang/rust/pull/136824 and https://github.com/rust-lang/rust/pull/137314 cycles should now be fully supported.
We also fully triaged all UI tests with the new solver enabled with @compiler-errors, @BoxyUwU, and myself fixing multiple less involved issues.
Key developments: Further discussions on implementation details of the three major proposed ways forward. Requested a design meeting in https://github.com/rust-lang/lang-team/issues/309.
As a monthly update (previously posted on Zulip): We have some big progress!
rust-clippy#13821 has been open and is currently being reviewed. It moves the MSRV logic out of lint-individualistic attribute extraction and into Clippy-wide MSRV (with a very good optimization, taking into account that only a small percentage of crates use.
A Clippy-exclusive benchmarker has arrived, powered by the existing lintcheck infrastructure and perf. So it's compatible with flamegraph and other such tools. rust-clippy#14194 We can later expand this into CI or a dedicated bot.
As you probably know, rust#125116 has been merged, just as a reminder of how that big goal was slayed like a dragon :dragon:.
We now know what functions to optimize (or, at least have a basic knowledge of where Clippy spends its time).
As some future functionality, I'd love to have a functionality to build cargo and rust with debug symbols and hook it up to Clippy, but that may be harder. It's not perfect, but it's a good start!
Last week at the Safety Critical Rust Consortium meeting in London, Ferrous systems publicly announced to consortium members that they have committed to contributing the FLS to the Rust Project. We are finalizing the details of that process, but we can start FLS integration testing in parallel, in anticipation.
We started the collaboration with the Delft University of Technology. We assembled a small research team with a professor and a MSc student who will be working on this as part of his MSc thesis. We meet weekly in person.
The project kicked off two weeks ago and is now in the literature research phase.
And related to this, someone else is working on an implementation of my #[export] rfc: https://github.com/rust-lang/rust/pull/134767 This will hopefully provide meaningful input for the research project.
Update: We are running behind schedule, but we are up and running nonetheless! Bear with us. The goals RFC finished FCP on Feb 18. The new project goals team has been approved and we've updated the tracking issues for the new milestone.
Project goal owners are encouraged to update the issue body to reflect the actual tasks as they go with github checkboxes or other notation as described here. We're going to start pinging for our first status update soon!
Update so far: I put out a call for volunteers on Zulip (hackmd) and a number of folks responded. We had an initial meeting on Jan 30 (notes here). We have created a Zulip stream for this project goal (vision-doc-2025) and I also did some experimenting in the https://github.com/nikomatsakis/farsight repository for what the table of contents might look like.
Next milestone is to layout a plan. We are somewhat behind schedule but not impossibly so!
An initial update on what we've been up to and some background:
This goal is submitted on behalf of the Rust team at Arm, but primarily worked on by @Jamesbarford. Anyone interested can always contact me for updates and I'll keep this issue up-to-date.
We've scheduled a regular call with @Kobzol to discuss the constraints and requirements of any changes to rust-perf (see the t-infra calendar) and have drafted a document describing a proposed high-level architecture for the service following our changes.
Once we've reached an agreement on the high-level architecture, we'll prepare a more detailed plan with details like proposed changes to the database schema, before proceeding with the implementation.
@amandasystems has continued working on the Sisyphean https://github.com/rust-lang/rust/pull/130227 and has made progress on rewriting type tests, diagnostics issues, fixing bugs, kept up with changes on master, and more.
big thanks to @jackh726 and @matthewjasper on reviews: with their help, all the PRs from the previous update have landed on nightly.
I've opened a couple of PRs on the analysis itself (https://github.com/rust-lang/rust/pull/135290, https://github.com/rust-lang/rust/pull/136299) as well as a few cleanups. With these, there are only around 4 failing tests that still need investigation, and 8-10 diagnostics differences to iron out. This is my current focus, but we'll also need to expand test coverage.
I've also opened a handful of PRs gradually expanding the polonius MIR dump with visualizations. I'll next add the interactive "tool" I've been using to help debug the test failures.
on organization and collaboration:
we've met with one of Amanda's students for a possible Master's thesis on the more engineer-y side of polonius (perf <3)
and have also discussed, with @ralfjung's team, the related topic of modeling the borrowck in a-mir-formality
An initial update on what we've been up to and some background:
This goal is submitted on behalf of the Rust team at Arm, but primarily worked on by myself (@davidtwco) and @JamieCunliffe. Anyone interested can always contact me for updates and I'll keep this issue up-to-date.
@JamieCunliffe been working on supporting Arm's scalable vector extension (SVE) for a couple years - primarily in rust-lang/rfcs#3268 and its implementation rust-lang/rust#118917.
Through this work, we've discovered other changes to the language necessary to be able to support these types without special cases in the type system, which we're also working on (see below).
Jamie is still resolving feedback on this RFC and its implementation, and keeping it rebased. We hope that it can be landed experimentally now that there's a feasible path to remove the special cases in the type system (see below).
The next steps for this RFC and implementation are..
..to continue to respond to feedback on the RFC and implementation.
I've (@davidtwco) been working on rust-lang/rfcs#3729 which improves Rust's support for exotically sized types, and would allow scalable vectors to be represented in the type system without special cases.
We've had two design meetings with the language team about the RFC and had a broadly positive reception.
There is a non-strict dependency on const traits (rust-lang/rfcs#3762) which has created uncertainty as to whether this RFC could be accepted without the specifics of const traits being nailed down.
I've been working on implementing the RFC: an initial implementation of the non-const traits has been completed and adding the const traits is in-progress.
The language team have indicated interest in seeing this land experimentally, but this will depend on whether the implementors of const traits are okay with this, as it would add to the work they need to do to make any syntactic changes requested by the language team in rust-lang/rfcs#3762.
I'm continuing to respond to feedback on the RFC, but as this has largely trailed off, the next steps for this RFC are..
..for the language team to decide to accept, reject, or request further changes to the RFC.
We are happy to announce that the Rust Project will again be participating in Google Summer of Code (GSoC) 2025, same as last year. If you're not eligible or interested in participating in GSoC, then most of this post likely isn't relevant to you; if you are, this should contain some useful information and links.
Google Summer of Code (GSoC) is an annual global program organized by Google that aims to bring new contributors to the world of open-source. The program pairs organizations (such as the Rust Project) with contributors (usually students), with the goal of helping the participants make meaningful open-source contributions under the guidance of experienced mentors.
The organizations that have been accepted into the program have been announced by Google. The GSoC applicants now have several weeks to discuss project ideas with mentors. Later, they will send project proposals for the projects that they found the most interesting. If their project proposal is accepted, they will embark on a several month journey during which they will try to complete their proposed project under the guidance of an assigned mentor.
We have prepared a list of project ideas that can serve as inspiration for potential GSoC contributors that would like to send a project proposal to the Rust organization. However, applicants can also come up with their own project ideas. You can discuss project ideas or try to find mentors in the #gsoc Zulip stream. We have also prepared a proposal guide that should help you with preparing your project proposals.
You can start discussing the project ideas with Rust Project mentors and maintainers immediately, but you might want to keep the following important dates in mind:
The project proposal application period starts on March 24, 2025. From that date you can submit project proposals into the GSoC dashboard.
The project proposal application period ends on April 8, 2025 at 18:00 UTC. Take note of that deadline, as there will be no extensions!
If you are interested in contributing to the Rust Project, we encourage you to check out our project idea list and send us a GSoC project proposal! Of course, you are also free to discuss these projects and/or try to move them forward even if you do not intend to (or cannot) participate in GSoC. We welcome all contributors to Rust, as there is always enough work to do.
Last year was our first time participating in GSoC, and it was a success! This year we are very excited to participate again. We hope that participants in the program can improve their skills, but also would love for this to bring new contributors to the Project and increase the awareness of Rust in general. Like last year, we expect to publish blog posts in the future with updates about our participation in the program.
First, I know that pretty much everyone is (understandably) freaking out about stuff that is getting worse, but I just wanted to share some good news in the form of an old-fashioned open-source success story. I’m a fairly boring person and developed most of my software habits in the late 1990s and early 2000s, so it’s pretty rare that I actually hit a bug.
A helpful developer, Jan Kratochvil, wrote a fix and put in a pull request.
A bot made test packages and commented with instructions for me on how to test the fix.
I commented that the new version works for me
The fix just went into Fedora. Pretty damn slick.
This is a great improvement over how this kind of thing used to work. I hardly had to do anything. These kids today don’t know how good they have it.
story number 2: why support the Linux desktop?
Amazon Chime is shutting down. Did anyone use it? I get invited to a lot of video conferences, and I never got invited to an Amazon Chime meeting. Even though Amazon.com is normally really good at SaaS, this one didn’t take off. What happened?
It looks like Amazon Chime was an interesting example of Nassim Nicholas Taleb’s intransigent minority effect.
The system requirements for Amazon Chime look pretty reasonable, right? Should get 95% of the client systems out there. The number of desktop Linux users is pretty small. But if you have 20 meetings a week, at 95% compatibility you’re going to average a compatibility issue every week. Even worse, the people you most want to make a good first impression on are the people whose client platform you’re least likely to know.
And if you do IT support for a company with 100 people organizing meetings, Amazon Chime is going to cause way too many support issues to put up with. Taleb uses the examples of kosher and halal food—only a small fraction of the population will only eat kosher or halal, but when planning food for a large group, the most practical choice is to satisfy the minority.
The minority rule will show us how it all it takes is a small number of intolerant virtuous people with skin in the game, in the form of courage, for society to function properly.
Anyway, something to keep in mind in the future for anyone considering moving the support desktop Linux or support Firefox tickets to backlog. None of the successul video conferencing platforms give me any grief for my Linux/Firefox/privacy nerdery client-side setup.
Bonus links
Liam Proven and Thomas Claburn cover the latest web browser surveillance drama: Mozilla flamed by Firefox fans after reneging on promises to not sell their dataMozilla doesn’t sell data about you (in the way that most people think about selling data), and we don’t buy data about you, he said. We changed our language because some jurisdictions define sell more broadly than most people would usually understand that word. (Don’t forget to turn off advertising features in Firefox.)
David Roberts interviews Mustafa Amjad and Waqas Moosa about Pakistan’s solar boom. What has prompted this explosion of distributed solar is some combination of punishingly high prices for grid power and solar panels getting very, very, very cheap. A glut of Chinese overcapacity means that the price of panels in Pakistan has gone from 24 cents a watt to 10 cents a watt in just the past year or two. Distributed solar is breaking over Pakistan like a tidal wave, despite utilities and a grid that do not seem entirely prepared for it.
AI and Esoteric Fascism by Baldur Bjarnason. When I first began to look into Large Language Models (LLMs) and Diffusion Model back in 2022, it quickly became obvious that much of the rhetoric around LLMs was… weird. Or, if we’re being plain-spoken, much of what the executives and engineers at the organisations making these systems were saying was outright weirdo cult shit…
It is no longer safe to move our governments and societies to US clouds by Bret Hubert. With all sorts of magic legal spells like DPIAs and DTIAs, organizations attempt to justify transferring our data and processes to the US. There is a whole industry that has been aiding and abetting this process for years. People also fool themselves that special keys and “servers in the EU” will get you “a safe space” within the American cloud. It won’t.
This came out in 2020 but worth re-reading today: Puncturing the Paradox: Group Cohesion and the Generational Myth by Harry Guild. The highest group cohesion by profession is in Marketing. This is advertising’s biggest problem in a single chart. This is the monoculture. How can we possibly understand, represent and sell to an entire country when we exist in such a bubble? We like to style ourselves as free thinkers, mavericks and crazies, but the grim truth is that we’re a more insular profession than farming and boast more conformists than the military.
Tech continues to be political by Miriam Eric Suzanne. Maybe we should consider the beliefs and assumptions that have been built into a technology before we embrace it? But we often prefer to treat each new toy as as an abstract and unmotivated opportunity. If only the good people like ourselves would get involved early, we can surely teach everyone else to use it ethically!
Important reminder at Sauropod Vertebra Picture of the Week. If you believe in “Artificial Intelligence”, take five minutes to ask it about stuff you know wellBecause LLMs get catastrophically wrong answers on topics I know well, I do not trust them at all on topics I don’t already know. And if you do trust them, I urge you to spend five minutes asking your favourite one about something you know in detail. (This is a big part of the reason I don’t use LLMs for search or research. A lot of the material isn’t just wrong, but reflects old, wrong, but often repeated assumptions that you need to know a lot about a field to know not to apply.)
Wendy Davis covers Meta Sued Over Discriminatory College Ads. A civil rights group has sued Meta Platforms over ad algorithms that allegedly discriminate by disproportionately serving ads for for-profit colleges to Black users and ads for public colleges to white users. Situations like this are a big part of the reason why people should stop putting privacy-enhancing advertising technologies in web browsers—they mainly obfuscate discrimination and fraud.)
Cities Can Cost Effectively Start Their Own Utilities Now by Kevin Burke. Most PG&E ratepayers don’t understand how much higher the rates they pay are than what it actually costs PG&E to generate and transmit the electricity to their house. When I looked into this recently I was shocked. The average PG&E electricity charge now starts at 40 cents per kilowatt hour and goes up from there. Silicon Valley Power, Santa Clara’s utility company, is getting power to customers for 17 cents per kilowatt hour. Sacramento’s utility company charges about the same.
Three years on, Europe looks to Ukraine for the future of defense tech by Mike Butcher. But in order to invest in the right technology, Europe will have to look to Ukraine, because that is where future wars are being fought right now. TechCrunch recently put a call out for Ukrainian dual-use and defense tech startups to update us on what they are working on. Below is what they sent us, in their own words. Related: Ukrainian Drones Flew 500 Miles And, In A Single Strike, Damaged 5% Of Russia’s Oil Refining Capacity by David Axe. (Drones are getting longer ranges and better autonomy, fast. Fossil fuel infrastructure is not getting any better protected or faster to repair. In the near future, you’re only going to be in the oil or gas business if nobody who is good at ML and model airplanes has a strong objection to you being in the oil or gas business.)
The rustup team is happy to announce the release of rustup version 1.28.0.
Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.
What's new in rustup 1.28.0
This new release of rustup has been a long time in the making and comes with substantial changes.
Before digging into the details, it is worth mentioning that Chris Denton has joined the team.
Chris has a lot of experience contributing to Windows-related parts of the Rust Project -- expertise we were previously lacking -- so we're happy to have him on board to help address Windows-specific issues.
The following improvements might require changes to how you use rustup:
rustup will no longer automatically install the active toolchain if it is not installed.
To ensure its installation, run rustup toolchain install with no arguments.
The following command installs the active toolchain both before and after this change:
rustup show active-toolchain || rustup toolchain install
# Or, on older versions of PowerShell:
rustup show active-toolchain; if ($LASTEXITCODE -ne 0) { rustup toolchain install }
Installing a host-incompatible toolchain via rustup toolchain install or rustup default will
now be rejected unless you explicitly add the --force-non-host flag.
Rustup now officially supports the following host platforms:
aarch64-pc-windows-msvc
loongarch64-unknown-linux-musl
This release also comes with various quality-of-life improvements, to name a few:
rustup show's output format has been cleaned up, making it easier to find out about your toolchains' status.
rustup doc now accepts a flag and a topic at the same time, enabling quick navigation to specific parts of more books.
rustup's remove subcommands now support more aliases such as rm and del.
Basic support for nushell has been added.
We have additionally made the following internal changes:
The default download backend has been changed from reqwest with native-tls to reqwest with rustls.
RUSTUP_USE_CURL and RUSTUP_USE_RUSTLS can still be used to change the download backend
if the new backend causes issues. If issues do happen, please let us know.
The default backend now uses rustls-platform-verifier to verify server certificates, taking
advantage of the platform's certificate store on platforms that support it.
When creating proxy links, rustup will now try symlinks first and fall back to hardlinks,
as opposed to trying hardlinks first.
A new RUSTUP_LOG environment variable can be used to control tracing-based logging in
rustup binaries. See the dev guide for more details.
Finally, there are some notable changes to our official website as well:
The overall design of the website has been updated to better align with the Rust Project's branding.
It is now possible to download the prebuilt rustup-init.sh installer for the aarch64-pc-windows-msvc host platform via https://win.rustup.rs/aarch64.
If you have a previous version of rustup installed, getting rustup 1.28.0 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:
$ rustup self update
Rustup will also automatically update itself at the end of a normal toolchain update:
$ rustup update
If you don't have it already, you can get rustup from the appropriate page on our website.
Rustup's documentation is also available in the rustup book.
Caveats
Rustup releases can come with problems not caused by rustup itself but just due to having a new release.
As such, we recommend paying attention to the following potential issues in particular:
Anti-malware scanners might be blocking rustup or stopping it from creating or copying files
(especially when installing rust-docs, since it contains many small files).
In your CI environment, rustup might fail when trying to perform a self-update.
This is a known issue,
and in the case where this issue does occur, we recommend applying the following workaround at the beginning of your workflow:
$ rustup set auto-self-update disable
Also, starting from 1.28.0, rustup will no longer attempt to self-update in CI environments,
so this workaround should not be necessary in the future.
These issues should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release,
and the hosted version is updated across all CI runners.
Thanks
Thanks again to all the contributors who made rustup 1.28.0 possible!
On Wednesday we shared that we’re introducing a new Terms of Use (TOU) and Privacy Notice for Firefox. Since then, we’ve been listening to some of our community’s concerns with parts of the TOU, specifically about licensing. Our intent was just to be as clear as possible about how we make Firefox work, but in doing so we also created some confusion and concern. With that in mind, we’re updating the language to more clearly reflect the limited scope of how Mozilla interacts with user data.
Here’s what the new language will say:
You give Mozilla the rights necessary to operate Firefox. This includes processing your data as we describe in the Firefox Privacy Notice. It also includes a nonexclusive, royalty-free, worldwide license for the purpose of doing as you request with the content you input in Firefox. This does not give Mozilla any ownership in that content.
In addition, we’ve removed the reference to the Acceptable Use Policy because it seems to be causing more confusion than clarity.
Privacy FAQ
We also updated our Privacy FAQ to better address legal minutia around terms like “sells.” While we’re not reverting the FAQ, we want to provide more detail about why we made the change in the first place.
TL;DR Mozilla doesn’t sell data about you (in the way that most people think about “selling data”), and we don’t buy data about you. We changed our language because some jurisdictions define “sell” more broadly than most people would usually understand that word. Firefox has built-in privacy and security features, plus options that let you fine-tune your data settings.
The reason we’ve stepped away from making blanket claims that “We never sell your data” is because, in some places, the LEGAL definition of “sale of data” is broad and evolving. As an example, the California Consumer Privacy Act (CCPA) defines “sale” as the “selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer’s personal information by [a] business to another business or a third party” in exchange for “monetary” or “other valuable consideration.”
Similar privacy laws exist in other US states, including in Virginia and Colorado. And that’s a good thing — Mozilla has long been a supporter of data privacy laws that empower people — but the competing interpretations of do-not-sell requirements does leave many businesses uncertain about their exact obligations and whether or not they’re considered to be “selling data.”
In order to make Firefox commercially viable, there are a number of places where we collect and share some data with our partners, including our optional ads on New Tab and providing sponsored suggestions in the search bar. We set all of this out in our Privacy Notice. Whenever we share data with our partners, we put a lot of work into making sure that the data that we share is stripped of potentially identifying information, or shared only in the aggregate, or is put through our privacy preserving technologies (like OHTTP).
We’re continuing to make sure that Firefox provides you with sensible default settings that you can review during onboarding or adjust at any time.
UPDATE: We’ve seen a little confusion about the language regarding licenses, so we want to clear that up. We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example. It does NOT give us ownership of your data or a right to use it for anything other than what is described in the Privacy Notice.
Why now? Although we’ve historically relied on our open source license for Firefox and public commitments to you, we are building in a much different technology landscape today. We want to make these commitments abundantly clear and accessible.
While for most companies these are pretty standard legal documents, at Mozilla we look at things differently. We lay out our principles in our Manifesto:
Your security and privacy on the internet are fundamental and must not be treated as optional.
You deserve the ability to shape the internet and your own experiences on it — including how your data is used.
We believe that practicing transparency creates accountability and trust.
Firefox will always continue to add new features, improve existing ones, and test new ideas. We remain dedicated to making Firefox open source, but we believe that doing so along with an official Terms of Use will give you more transparency over your rights and permissions as you use Firefox. And actually asking you to acknowledge it is an important step, so we’re making it a part of the standard product experience starting in early March for new users and later this year for existing ones.
In addition to the Terms of Use, we are providing a more detailed explanation of our data practices in our updated Privacy Notice. We tried to make these easy to read and understand — there shouldn’t be any surprises in how we operate or how our product works.
We have always prioritized user privacy and will continue to do so. We use data to make Firefox functional and sustainable, improve your experience, and keep you safe. Some optional Firefox features or services may require us to collect additional data to make them work, and when they do, your privacy remains our priority. We intend to be clear about what data we collect and how we use it.
Finally, you are in control. We’ve set responsible defaults that you can review during onboarding or adjust in your settings at any time: These simple, yet powerful tools let you manage your data the way you want.
You deserve that choice, and we hope all technology companies will start to provide it. It’s standard operating procedure for us.
At Mozilla, we know that creating compelling web experiences depends on the ability to test sites across all browsers. This means that enabling excellent cross-browser automation is a key part of how we deliver our vision for the open web.
Today, we are excited to share a significant milestone: Cypress will use WebDriver BiDi as its default automation protocol for Firefox 135 and later, starting with Cypress 14.1.0.
Why WebDriver BiDi?
WebDriver BiDi is a cross-browser automation protocol undergoing standardisation at W3C. It is designed as an update to the existing WebDriver standard that provides the two-way communication and rich feature set required for modern testing tools.
Prior to WebDriver BiDi, browser testing tools such as Cypress often used the Chrome Devtools Protocol (CDP) to gain access to functionality not available in WebDriver. However this comes with a significant disadvantage: as the name suggests the Chrome Devtools Protocol is only available in Chromium-based browsers, significantly limiting its suitability for cross-browser testing. For more information on the relationship between CDP and WebDriver BiDi, see our posts on the hacks blog.
To help bridge this gap, back in 2019 Firefox started to implement a subset of CDP directly in Gecko. This has been used by Cypress as part of their Firefox backend since version 4.0. However with WebDriver BiDi now offering a richer feature set and undergoing continual improvements, we believe that switching to the standard protocol will better serve the needs of Cypress users.
If you use Cypress and run into difficulties, it is temporarily possible to switch back to the CDP backend by setting the environment variable FORCE_FIREFOX_CDP=1. If you need to do this please file a bug. Cypress are planning to deprecate support for this in version 15 and the CDP support in Firefox will be removed after the next ESR release.
This achievement would not have been possible without the close collaboration between Mozilla and Cypress. From initial planning to implementation and testing, we worked together to ensure WebDriver BiDi meets the needs of Cypress users. This underscores our commitment to providing developers with powerful and reliable tools for cross-browser testing.
CDP Support Ends with Firefox 141
As we continue transitioning to WebDriver BiDi, support for the experimental Chrome DevTools Protocol in Firefox will officially end with Firefox 141, set for release on July 22nd. The 140 ESR release will continue to have CDP support for its full support lifecycle. Removing the CDP implementation will allow us to focus our efforts entirely on improving WebDriver BiDi.
What’s Next?
We believe that WebDriver BiDi provides a solid foundation for the future of browser testing and automation. We will continue to work closely with automation tools to ensure that it meets their needs for a robust, feature-rich, cross-browser automation protocol.
Stay tuned for further updates as we continue improving the Firefox automation experience. The future of automation is here, and WebDriver BiDi is leading the way!
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 on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request.
Want to get involved? We love contributions.
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.
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 X (formerly Twitter) or Mastodon!
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 X (formerly Twitter) or Mastodon!
Fairly quiet week with the exception of an improvement to the very often used Iter::next function which can now be inlined in MIR leading to a myriad of performance improvements.
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.
Rust isn't a "silver bullet" that will solve all of our problems, but it
sure will help in a huge number of places, so for new stuff going
forward, why wouldn't we want that?
In one of our projects with NLnet, we were working on adding support for CSS floats and tables in Servo. Once the project was completed, we reached out to Radically Open Security to run a security audit. The focus of the audit was in the code related to that project, so the main components investigated were the CSS code paths in the layout engine and Stylo. As part of this audit, four vulnerabilities were identified:
Servo uses an outdated version of the time crate that is vulnerable to a known issue.
Moderate
CLN-004
Arithmetic underflow
By calling methods on a TableBuilder object in a specific order, an integer underflow can be triggered, followed by an attempted out-of-bounds access, which is caught by Rust, resulting in a panic.
Low
CLN-002
Arithmetic underflow
An arithmetic underflow condition is currently impossible to trigger, but may become accessible as its surrounding logic evolves.
N/A
CLN-007
Unguarded casting
Casting from an unsigned platform pointer-width integer into a fixed-width signed integer may result in erroneous layouts.
N/A
If you want to know more details you can read the full report.
The first issue (CLN-009) was related to a known vulnerability in version 0.1 of the time crate that Servo depended on (RUSTSEC-2020-0071). We had removed this in most of Servo, but there was one remaining dependency in WebRender. We have since addressed this vulnerability by removing it from the version of WebRender used in Servo (@mrobinson, #35325), and we will also try to upstream our changes so that Firefox is unaffected.
We have also fixed the second (CLN-004) and third (CLN-002) issues by making the affected code more robust (@Loirooriol, #34247, #35437), in the event web content can trigger them.
The fourth issue (CLN-007) is not urgent, since the values are constrained elsewhere and it would otherwise only affect layout correctness and not security, but it’s worth fixing at some point too.
Servo has long been highlighted for being a memory-safe and concurrency-safe web rendering engine, thanks to the guarantees provided by the Rust programming language, including its ownership system, borrow checker, and built-in data structures that enable safe concurrent programming. These features help prevent memory and concurrency vulnerabilities, such as use-after-free bugs and data races.
We find it promising that this security audit, although smaller and of limited scope, identified no severe vulnerabilities, especially none of that nature, and that we were able to address any vulnerabilities identified. This was a positive experience for Servo and the web, and we’re keen to explore more security auditing for Servo in the future.
A few years back I proposed view types as an extension to Rust’s type system to let us address the problem of (false) inter-procedural borrow conflicts. The basic idea is to introduce a “view type” {f1, f2} Type1, meaning “an instance of Type where you can only access the fields f1 or f2”. The main purpose is to let you write function signatures like & {f1, f2} self or &mut {f1, f2} self that define what fields a given type might access. I was thinking about this idea again and I wanted to try and explore it a bit more deeply, to see how it could actually work, and to address the common question of how to have places in types without exposing the names of private fields.
Example: the Data type
The Data type is going to be our running example. The Data type collects experiments, each of which has a name and a set of f32 values. In addition to the experimental data, it has a counter, successful, which indicates how many measurements were successful.
There are some helper functions you can use to iterate over the list of experiments and read their data. All of these return data borrowed from self. Today in Rust I would typically leverage lifetime elision, where the & in the return type is automatically linked to the &self argument:
Today, “aggregate” types like Data present a composition hazard
The Data type as presented thus far is pretty sensible, but it can actually be a pain to use. Suppose you wanted to iterate over the experiments, analyze their data, and adjust the successful counter as a result. You might try writing the following:
fncount_successful_experiments(data: &mutData){fornindata.experiment_names(){ifis_successful(data.for_experiment(n)){data.add_successful();// ERROR: data is borrowed here
}}}
Experienced Rustaceans are likely shaking their head at this point—in fact, the previous code will not compile. What’s wrong? Well, the problem is that experiment_names returns data borrowed from self which then persists for the duration of the loop. Invoking add_successful then requires an &mut Data argument, which causes a conflict.
The compiler is indeed flagging a reasonable concern here. The risk is that add_successful could mutate the experiments map while experiment_names is still iterating over it. Now, we as code authors know that this is unlikely — but let’s be honest, it may be unlikely now, but it’s not impossible that as Data evolves somebody might add some kind of logic into add_successful that would mutate the experiments map. This is precisely the kind of subtle interdependency that can make an innocuous “but it’s just one line!” PR cause a massive security breach. That’s all well and good, but it’s also very annoying that I can’t write this code.
Using view types to flag what is happening
The right fix here is to have a way to express what fields may be accessed in the type system. If we do this, then we can get the code to compile today and prevent future PRs from introducing bugs. This is hard to do with Rust’s current system, though, as types do not have any way of talking about fields, only spans of execution-time (“lifetimes”).
With view types, though, we can change the signature from &self to &{experiments} self. Just as &self is shorthand for self: &Data, this is actually shorthand for self: & {experiments} Data.
The idea of this post was to sketch out how view types could work in a slightly more detailed way. The basic idea is to extend Rust’s type grammar with a new type…
T = &’a mut? T
| [T]
| Struct<...>
| …
| {field-list} T // <— view types
We would also have some kind of expression for defining a view onto a place. This would be a place expression. For now I will write E = {f1, f2} E to define this expression, but that’s obviously ambiguous with Rust blocks. So for example you could write…
…to get a reference p that can only access the field 0 of the tuple and a reference q that can only access field 1. Note the difference between &{0}x, which creates a reference to the entire tuple but with limited access, and &x.0, which creates a reference to the field itself. Both have their place.
How would we type check the self.successful += 1 statement? Today, without view types, typing an expression like self.successful begins by getting the type of self, which is something like &mut Data. We then “auto-deref”, looking for the struct type within. That would bring us to Data, at which point we would check to see if Data defines a field successful.
To integrate view types, we have to track both the type of data being accessed and the set of allowed fields. Initially we have variable self with type &mut {successful} Data and allow set *. The deref would bring us to {successful} Data (allow-set remains *). Traversing a view type modifies the allow-set, so we go from * to {successful} (to be legal, every field in the view must be allowed). We now have the type Data. We would then identify the field successful as both a member of Data and a member of the allow-set, and so this code would be successful.
If however you tried to modify a function to access a field not declared as part of its view, e.g.,
implData{pubfnadd_successful(self: &mut{successful}Self,){assert!(!self.experiments.is_empty());// <— modified to include this
self.successful+=1;}}
the self.experiments type-checking would now fail, because the field experiments would not be a member of the allow-set.
We need to infer allow sets
A more interesting problem comes when we type-check a call to add_successful(). We had the following code:
fncount_successful_experiments(data: &mutData){fornindata.experiment_names(){ifis_successful(data.for_experiment(n)){data.add_successful();// Was error, now ok.
}}}
Consider the call to data.experiment_names(). In the compiler today, method lookup begins by examining data, of type &mut Data, auto-deref’ing by one step to yield Data, and then auto-ref’ing to yield &Data. The result is this method call is desugared to a call like Data::experiment_names(&*data).
With view types, when introducing the auto-ref, we would also introduce a view operation. So we would get Data::experiment_names(& {?X} *data). What is this {?X}? That indicates that the set of allowed fields has to be inferred. A place-set variable ?X can be inferred to a set of fields or to * (all fields).
We would integrate these place-set variables into inference, so that {?A} Ta <: {?B} Tb if ?B is a subset of ?A and Ta <: Tb (e.g., [x, y] Foo <: [x] Foo). We would also for dropping view types from subtypes, e.g., {*} Ta <: Tb if Ta <: Tb.
Place-set variables only appear as an internal inference detail, so users can’t (e.g.) write a function that is generic over a place-set, and the only kind of constraints you can get are subset (P1 <= P2) and inclusion (f in P1). I think it should be relatively straightforward to integrate these into HIR type check inference. When generalizing, we can replace each specific view set with a variable, just as we do for lifetimes. When we go to construct MIR, we would always know the precise set of fields we wish to include in the view. In the case where the set of fields is * we can also omit the view from the MIR.
Abstract fields
So, view types allow us to address these sorts of conflicts by making it more explicit what sets of types we are going to access, but they introduce a new problem — does this mean that the names of our private fields become part of our interface? That seems obviously undesirable.
The solution is to introduce the idea of abstract2 fields. An abstract field is a kind of pretend field, one that doesn’t really exist, but which you can talk about “as if” it existed. It lets us give symbolic names to data.
Abstract fields would be defined as aliases for a set of fields, like pub abstract field_name = (list-of-fields). An alias defines a public symbolic names for a set of fields.
We could therefore define two aliases for Data, one for the set of experiments and one for the count of successful experiments. I think it be useful to allow these names to alias actual field names, as I think that in practice the compiler can always tell which set to use, but I would require that if there is an alias, then the abstract field is aliased to the actual field with the same name.
Now the view types we wrote earlier (& {experiments} self, etc) are legal but they refer to the abstract fields and not the actual fields.
Abstract fields permit refactoring
One nice property of abstract fields is that they permit refactoring. Imagine that we decide to change Data so that instead of storing experiments as a Map<String, Vec<f32>>, we put all the experimental data in one big vector and store a range of indices in the map, like Map<String, (usize, usize)>. We can do that no problem:
We would still declare methods like &mut {experiments} self, but the compiler now understands that the abstract field experiments can be expanded to the set of private fields.
Frequently asked questions
Can abstract fields be mapped to an empty set of fields?
Yes, I think it should be possible to define pub abstract foo; to indicate the empty set of fields.
How do view types interact with traits and impls?
Good question. There is no necessary interaction, we could leave view types as simply a kind of type. You might do interesting things like implement Deref for a view on your struct:
structAugmentedData{data: Vec<u32>,summary: u32,}implDereffor{data}AugmentedData{typeTarget=[u32];fnderef(&self)-> &[u32]{// type of `self` is `&{data} AugmentedData`
&self.data}}
OK, you don’t need to integrate abstract fields with traits, but could you?
Yes! And it’d be interesting. You could imagine declaring abstract fields as trait members that can appear in its interface:
You could then define those fields in an impl. You can even map some of them to real fields and leave some as purely abstract:
structOneCounter{counter: u32,}implInterfaceforOneCounter{abstractdata1=counter;abstractdata2;fnget_data1(&{counter}self)-> u32{self.counter}fnget_data2(&{data2}self)-> u32{0// no fields needed
}}
Could view types include more complex paths than just fields?
Although I wouldn’t want to at first, I think you could permit something like {foo.bar} Baz and then, given something like &foo.bar, you’d get the type &{bar} Baz, but I’ve not really thought it more deeply than that.
Can view types be involved in moves?
Yes! You should be able to do something like
structStrings{a: String,b: String,c: String,}fnplay_games(s: Strings){// Moves the struct `s` but only the fields `a` and `c`
lett: {a,c}Strings={a,c}s;println!(“{s.a}”);// ERROR: s.a has been moved
println!(“{s.b}”);// OK.
println!(“{s.c}”);// ERROR: s.a has been moved
println!(“{t.a}”);// OK.
println!(“{t.b}”);// ERROR: no access to field `b`.
println!(“{t.c}”);// OK.
}
Why did you have a subtyping rules to drop view types from sub- but not super-types?
I described the view type subtyping rules as two rules:
{?A} Ta <: {?B} Tb if ?B is a subset of ?A and Ta <: Tb
{*} Ta <: Tb if Ta <: Tb
In principle we could have a rule like Ta <: {*} Tb if Ta <: Tb — this rule would allow “introducing” a view type into the supertype. We may wind up needing such a rule but I didn’t want it because it meant that code like this really ought to compile (using the Strings type from the previous question):
fnplay_games(s: Strings){lett: {a,c}Strings=s;// <— just `= s`, not `= {a, c} s`.
}
I would expect this to compile because
{a,c}Strings<: {*}Strings<: Strings
but I kind of don’t want it to compile.
Are there other uses for abstract fields?
Yes! I think abstract fields would also be useful in two other ways (though we have to stretch their definition a bit). I believe it’s important for Rust to grow stronger integration with theorem provers; I don’t expect these to be widely used, but for certain key libraries (stdlib, zerocopy, maybe even tokio) it’d be great to be able to mathematically prove type safety. But mathematical proof systems often require a notion of ghost fields — basically logical state that doesn’t really exist at runtime but which you can talk about in a proof. A ghost field is essentially an abstract field that is mapped to an empty set of fields and which has a type. For example you might declare a BeanCounter struct with two abstract fields (a, b) and one real field that stores their sum:
structBeanCounter{pubabstracta: u32,pubabstractb: u32,sum: u32,// <— at runtime, we only store the sum
}
then when you create BeanCounter you would specify a value for those fields. The value would perhaps be written using something like an abstract block, indicating that in fact the code within will not be executed (but must still be type checkable):
Providing abstract values is useful because it lets the theorem prover act “as if” the code was there for the purpose of checking pre- and post-conditions and other kinds of contracts.
Could we use abstract fields to replace phantom data?
Yes! I imagine that instead of a: PhantomData<T> you could do abstract a: T, but that would mean we’d have to have some abstract initializer. So perhaps we permit an anonymous field abstract _: T, in which case you wouldn’t be required to provide an initializer, but you also couldn’t name it in contracts.
So what are all the parts to an abstract field?
I would start with just the simplest form of abstract fields, which is an alias for a set of real fields. But to extend to cover ghost fields or PhantomData, you want to support the ability to declare a type for abstract fields (we could say that the default if ()). For fields with non-() types, you would be expected to provide an abstract value in the struct constructor. To conveniently handle PhantomData, we could add anonymous abstract fields where no type is needed.
Should we permit view types on other types?
I’ve shown view types attached to structs and tuples. Conceivably we could permit them elsewhere, e.g., {0} &(String, String) might be equivalent to &{0} (String, String). I don’t think that’s needed for now and I’d make it ill-formed, but it could be reasonable to support at some point.
Conclusion
This concludes my exploration through view types. The post actually changed as I wrote it — initially I expected to include place-based borrows, but it turns out we didn’t really need those. I also initially expected view types to be a special case of struct types, and that indeed might simplify things, but I wound up concluding that they are a useful type constructor on their own. In particular if we want to integrate them into traits it will be necessary for them to be applied to generics and the rest.≈g
In terms of next steps, I’m not sure, I want to think about this idea, but I do feel we need to address this gap in Rust, and so far view types seem like the most natural. I think what could be interesting is to prototype them in a-mir-formality as it evolves to see if there are other surprises that arise.
I’m not really proposing this syntax—among other things, it is ambiguous in expression position. I’m not sure what the best syntax is, though! It’s an important question, but not one I will think hard about here. ↩︎
I prefer the name ghost fields, because it’s spooky, but abstract is already a reserved keyword. ↩︎
Extensions are like apps for your browser, letting you customize and enhance your online experience. Nearly half of all Firefox users have installed at least one extension, from privacy tools to productivity boosters.
To build these extensions, developers rely on a platform called WebExtensions, which provides APIs— the tools that allow extensions to interact with web pages and browser features. Right now, all major browsers — including Firefox, Chrome and Safari — are implementing the latest version of this platform, Manifest V3. But different browsers are taking different approaches, and those differences affect which extensions you can use.
Firefox’s approach to Manifest V3 is shaped by our mission
Principle 5 of the Mozilla Manifesto states: Individuals must have the ability to shape the internet and their own experiences on it. That philosophy drives our approach to Manifest V3.
More creative possibilities for developers — We’ve introduced a broader range of APIs, including new AI functionality that allows extensions to run offline machine learning tasks directly in the browser.
Support for both Manifest V2 and V3 — While some browsers are phasing out Manifest V2 entirely, Firefox is keeping it alongside Manifest V3. More tools for developers means more choice and innovation for users.
Giving people choice and control on the internet has always been core to Mozilla. It’s all about making sure users have the freedom to shape their own experiences online.
No limits on your extensions with Firefox
Google began phasing out Manifest V2 last year and plans to end support for extensions built on it by mid-2025. That change has real consequences: Chrome users are already losing access to uBlock Origin, one of the most popular ad blockers, because it relies on a Manifest V2 feature called blockingWebRequest.
Google’s approach replaces blockingWebRequest with declarativeNetRequest, which limits how extensions can filter content. Since APIsdefine what extensions can and can’t do inside a browser, restricting certain APIs can limit what types of extensions are possible.
Firefox, however, will continue supporting both blockingWebRequest and declarativeNetRequest — giving developers more flexibility and keeping powerful privacy tools available to users. We’ll keep you updated on what’s next for extensions in Firefox. In the meantime, check out addons.mozilla.org to explore thousands of ways to customize your Firefox.
Support for searching the Firefox Developer Edition’s default path on macOS. Implemented by Gatlin Newhouse.
Ability to push a WebExtension archive as created from a base64 encoded string to an Android device.
Added an allowPrivateBrowsing field for POST /session/{session id}/moz/addon/install to allow the installation of a WebExtension that is enabled in Private Browsing mode.
Introduced the --allow-system-access command line argument for geckodriver, which will be required for future versions of Firefox (potentially starting with 138.0) to allow testing in the chrome context.
Added support for preserving crash dumps for crash report analysis when Firefox crashes. If the MINIDUMP_SAVE_PATH environment variable is set to an existing folder, crash dumps will be saved accordingly. For mobile devices, the generated minidump files will be automatically transferred to the host machine. For more details see the documentation of how to handle crash reports.
Changed
Updated the type of the x and y fields of pointer move actions (mouse and touch) from integer to fractional numbers to ensure a more precise input control.
Replaced serde_yaml with yaml-rust because it’s no longer officially supported.
The --enable-crash-reporter command line argument has been deprecated to prevent crash reports from being submitted to Socorro. This argument will be completely removed in the next version. Instead, use the MINIDUMP_SAVE_PATH environment variable to get minidump files saved to a specified location.
Fixed
Fixed route registration for WebAuthn commands, which were introduced in geckodriver 0.34.0 but mistakenly registered under /sessions/ instead of /session/, causing them to be non-functional.
Removed
Removed the -no-remote command-line argument usage for Firefox, which does no longer exist.
Downloads
Geckodriver 0.36.0 can be downloaded for all supported platforms as usual from our GitHub release page.
Today Mozilla has joined an amicus brief in the California Supreme Court defending statutory privacy protections for messages on services such as Snapchat or Facebook. The amicus brief asks the court to overrule a lower court opinion that would significantly reduce the legal privacy protections for users of these widely used services. Mozilla is joined on the brief by the Electronic Frontier Foundation and the Center for Democracy and Technology.
Back in 1986, Congress passed a law called the Stored Communications Act (SCA) to provide privacy protections for stored electronic communications such as email. The SCA prohibits service providers from sharing private messages with the government or other third-parties without authorization. For example, it requires that the government must get a warrant to access recent communications (or at least a subpoena in other circumstances). In the years since 1986, it is fair to say we have developed many new forms of digital communication. Fortunately, the language of the SCA is sufficiently general (it uses the term “electronic communication service”) that courts have applied it to a large array of new products.
Unfortunately, a California court recently narrowed the scope of the SCA. In the case of Snap v. The Superior Court of San Diego County, the California Court of Appeal ruled that the SCA does not protect users of Snapchat and Facebook. The court concluded that the SCA does not apply because, in addition to facilitating transmission of messages and storing backups, these companies also maintain that content for their own business purposes such as targeted advertising. If upheld, this ruling would remove the SCA’s protection not just for users of Snap and Facebook, but for many other modern forms of communication.
While we may criticize some of Snap or Meta’s data practices, it would only compound the privacy harm to their users to hold that their privacy policies take them outside the scope of the SCA, with potential ramifications for the users of other services in the future. Our brief argues that this is both wrong on the law and bad policy. We hope the California Supreme Court will fix the lower court’s error and restore key statutory privacy protections to modern messaging services.
Welcome to my first Cybersecurity Friday (CSF) post.
Almost exactly one week ago I experienced (and had to fight & recover from)
a cybersecurity incident. While that’s a much longer story,
this post series is focused on sharing tips and incident learnings
from an
#indieweb-centric
perspective.
Steps for Cybersecurity
Here are the top three steps in order of importance,
that you should take ASAP
to secure your online presence.
Email MFA/2FA.
Add multi-factor authentication (MFA) using
an actual Authenticator application to all places
where you store or check email.
Some services call this second factor or two factor authentication (2FA).
While checking your email security settings, verify recovery settings:
Do not cross-link your emails as recovery methods for each other,
and do not use a mobile/cell number for recovery at all.
Domain Registrar MFA.
Add MFA to your Domain Registrar(s) if you have any.
Optionally disable password reset emails if possible (some registrars may allow this).
Web Host MFA.
Add MFA to your web hosting service(s) if you have any.
This includes both website hosting and any content delivery network (CDN)
services you are using for your domains.
Do not use a mobile number for MFA,
nor a physical/hardware key if you travel internationally.
There are very good reasons to avoid doing so. I’ll blog the reasons in another post.
Those are my top three recommended cybersecurity steps
for protecting your internet presence.
That’s it for this week. These are the bare minimum steps to take.
There are many more steps you can take to strengthen your personal cybersecurity.
I will leave you with this for now:
Entropy is your friend in security.
Glossary
Glossary for various terms, phrases, and further reading on each.
unsignedHTMLTableCellElement::rowSpan()const{// FIXME: a rowSpan equal to 0 should be allowed, and mean that the cell is to span all the remaining rows in the row group.returnstd::max(1u,rowSpanForBindings());}
The first task is very simple. Understand what are the different renderings in between browsers.
Simon had already created a testcase and Ahmad had created a screenshot for it showing the results of the testcase in Safari, Firefox and Chrome. This work was already done. If they had been missing, that would have been my first step.
Read The Specification
For having a better understanding of the issue, it is useful to read the specification related to this bug. In this case, the relevant information was in the HTML specification, where rowspan attribute on td/th elements is described. This is the text we need:
The td and th elements may also have a rowspan content attribute specified, whose value must be a valid non-negative integer less than or equal to 65534. For this attribute, the value zero means that the cell is to span all the remaining rows in the row group.
This will create a table were the first column will overlap the 3 rows. This is already working as expected in all rendering engines : WebKit, Gecko and Blink. So far, so good.
Think About The Logic
I learned from reading the specification that rowspan had a maximum value: 65534.
My initial train of thoughts was:
compute the number of rows the table.
parse the value rowspan value
when the value is 0, replace it with the number of rows.
It seemed too convoluted. Would it be possible to use the maximum value for rowspan? The specification was saying "span all the remaining rows in the row group".
I experimented with a bigger rowspan value than the number of rows. For example, put the value 30 on a 3 rows table.
We just had to try to change the C++ code. My patch was
diff --git a/Source/WebCore/html/HTMLTableCellElement.cpp b/Source/WebCore/html/HTMLTableCellElement.cppindex 256c816acc37b..65450c01e369a 100644--- a/Source/WebCore/html/HTMLTableCellElement.cpp+++ b/Source/WebCore/html/HTMLTableCellElement.cpp@@ -59,8 +59,14 @@ unsigned HTMLTableCellElement::colSpan() constunsigned HTMLTableCellElement::rowSpan() const
{
- // FIXME: a rowSpan equal to 0 should be allowed, and mean that the cell is to span all the remaining rows in the row group.- return std::max(1u, rowSpanForBindings());+ unsigned rowSpanValue = rowSpanForBindings();+ // when rowspan=0, the HTML spec says it should apply to the full remaining rows.+ // In https://html.spec.whatwg.org/multipage/tables.html#attr-tdth-rowspan+ // > For this attribute, the value zero means that the cell is+ // > to span all the remaining rows in the row group.+ if (!rowSpanValue)+ return maxRowspan;+ return std::max(1u, rowSpanValue);}
unsigned HTMLTableCellElement::rowSpanForBindings() const
The biggest part of fixing the bugs is researching, testing different HTML scenario without even touching the C++ code, etc. I'm not a C++ programmer, but time to time I can find bugs that are easy enough to understand that I can fix them. I hope this makes it easier for you to understand and encourage you to look at other bugs.
Note also, that it is not always necessary to fix until modifying everything. Sometimes, just creating testscases, screenshots, pointing to the right places in the specifications, creating the WPT test cases covering this bug are all super useful.
PS: Doing all this work, I found also about the behavior of colspan which is interoperable (same behavior in all browsers), but which I find illogical comparing to the behavior of rowspan.
So, a little bird told me that Rust 2024 is going to become stable today, along with Rust 1.85.0. In honor of this momentous event, I have penned a little ditty that I’d like to share with you all. Unfortunately, for those of you who remember Rust 2021’s “Edition: The song”, in the 3 years between Rust 2021 and now, my daughter has realized that her father is deeply uncool1 and so I had to take this one on solo2. Anyway, enjoy! Or, you know, suffer. As the case may be.
In ChordPro format, for those of you who are inspired to play along.
{title: Rust 2024}
{subtitle: }
{key: C}
[Verse 1]
[C] When I got functions that never return
I write an exclamation point [G]
But use it for an error that could never be
the compiler [C] will yell at me
[Verse 2]
[C] We Rust designers, we want that too
[C7] But we had to make a [F] change
[F] That will be [Fm]better
[C] Oh so much [A]better
[D] in Rust Twenty [G7]Twenty [C]Four
[Bridge]
[Am] ... [Am] But will my program [E] build?
[Am] Yes ... oh that’s [D7] for sure
[F] edi-tions [G] are [C] opt in
[Verse 3]
[C] Usually when I return an `impl Trait`
everything works out fine [G]
but sometimes I need a tick underscore
and I don’t really [C] know what that’s for
[Verse 4]
[C] We Rust designers we do agree
[C7] That was con- [F] fusing
[F] But that will be [Fm]better
[C] Oh so much [A]better
[D] in Rust Twenty [G7]Twenty [C]Four
[Bridge 2]
[Am] Cargo fix will make the changes
automatically [G] Oh that sure sounds great...
[Am] but wait... [Am] my de-pen-denc-[E]-ies
[Am] Don’t worry e-[D7]ditions
[F] inter [G] oper [C] ate
[Verse 5]
[C] Whenever I match on an ampersand T
The borrow [G] propagates
But where do I put the ampersand
when I want to [C] copy again?
[Verse 6]
[C] We Rust designers, we do agree
[C7] That really had to [F] change
[F] That will be [Fm]better
[C] Oh so much [A]better
[D] in Rust Twenty [G7]Twenty [C]Four
[Outro]
[F] That will be [Fm]better
[C] Oh so much [A]better
[D] in Rust Twenty [G7]Twenty [C]Four
One more time!
[Half speed]
[F] That will be [Fm]better
[C] Oh so much [A]better
[D] in Rust Twenty [G7]Twenty [C]Four
Actually, I had a plan to make this a duet with somebody who shall remain nameless (they know who they are). But I was too lame to get everything done on time. In fact, I may or may not have realized “Oh, shit, I need to finish this recording!” while in the midst of a beer with Florian Gilcher last night. Anyway, sorry, would-be-collaborator-I -was-really-looking-forward-to-playing-with! Next time! ↩︎
The Rust team is happy to announce a new version of Rust, 1.85.0. This stabilizes the 2024 edition as well.
Rust is a programming language empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, you can get 1.85.0 with:
If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
What's in 1.85.0 stable
Rust 2024
We are excited to announce that the Rust 2024 Edition is now stable!
Editions are a mechanism for opt-in changes that may otherwise pose a backwards compatibility risk. See the edition guide for details on how this is achieved, and detailed instructions on how to migrate.
This is the largest edition we have released. The edition guide contains detailed information about each change, but as a summary, here are all the changes:
Language
RPIT lifetime capture rules — Changes the default capturing of parameters by impl Trait types when use<..> is not present.
Rustfmt: Style edition — Introduces the concept of "style editions", which allow you to independently control the formatting edition from the Rust edition.
The guide includes migration instructions for all new features, and in general
transitioning an existing project to a new edition.
In many cases cargo fix can automate the necessary changes. You may even find that no changes in your code are needed at all for 2024!
Note that automatic fixes via cargo fix are very conservative to avoid ever changing the semantics of your code. In many cases you may wish to keep your code the same and use the new semantics of Rust 2024; for instance, continuing to use the expr macro matcher, and ignoring the conversions of conditionals because you want the new 2024 drop order semantics. The result of cargo fix should not be considered a recommendation, just a conservative conversion that preserves behavior.
Many people came together to create this edition. We'd like to thank them all for their hard work!
async closures
Rust now supports asynchronous closures like async || {} which return futures when called. This works like an async fn which can also capture values from the local environment, just like the difference between regular closures and functions. This also comes with 3 analogous traits in the standard library prelude: AsyncFn, AsyncFnMut, and AsyncFnOnce.
In some cases, you could already approximate this with a regular closure and an asynchronous block, like || async {}. However, the future returned by such an inner block is not able to borrow from the closure captures, but this does work with async closures:
let mut vec: Vec<String> = vec![];
let closure = async || {
vec.push(ready(String::from("")).await);
};
It also has not been possible to properly express higher-ranked function signatures with the Fn traits returning a Future, but you can write this with the AsyncFn traits:
use core::future::Future;
async fn f<Fut>(_: impl for<'a> Fn(&'a u8) -> Fut)
where
Fut: Future<Output = ()>,
{ todo!() }
async fn f2(_: impl for<'a> AsyncFn(&'a u8))
{ todo!() }
async fn main() {
async fn g(_: &u8) { todo!() }
f(g).await;
//~^ ERROR mismatched types
//~| ERROR one type is more general than the other
f2(g).await; // ok!
}
So async closures provide first-class solutions to both of these problems! See RFC 3668 and the stabilization report for more details.
Hiding trait implementations from diagnostics
The new #[diagnostic::do_not_recommend] attribute is a hint to the compiler to not show the annotated trait implementation as part of a diagnostic message. For library authors, this is a way to keep the compiler from making suggestions that may be unhelpful or misleading. For example:
pub trait Foo {}
pub trait Bar {}
impl<T: Foo> Bar for T {}
struct MyType;
fn main() {
let _object: &dyn Bar = &MyType;
}
error[E0277]: the trait bound `MyType: Bar` is not satisfied
--> src/main.rs:9:29
|
9 | let _object: &dyn Bar = &MyType;
| ^^^^ the trait `Foo` is not implemented for `MyType`
|
note: required for `MyType` to implement `Bar`
--> src/main.rs:4:14
|
4 | impl<T: Foo> Bar for T {}
| --- ^^^ ^
| |
| unsatisfied trait bound introduced here
= note: required for the cast from `&MyType` to `&dyn Bar`
For some APIs, it might make good sense for you to implement Foo, and get Bar indirectly by that blanket implementation. For others, it might be expected that most users should implement Bar directly, so that Foo suggestion is a red herring. In that case, adding the diagnostic hint will change the error message like so:
#[diagnostic::do_not_recommend]
impl<T: Foo> Bar for T {}
error[E0277]: the trait bound `MyType: Bar` is not satisfied
--> src/main.rs:10:29
|
10 | let _object: &dyn Bar = &MyType;
| ^^^^ the trait `Bar` is not implemented for `MyType`
|
= note: required for the cast from `&MyType` to `&dyn Bar`
See RFC 2397 for the original motivation, and the current reference for more details.
FromIterator and Extend for tuples
Earlier versions of Rust implemented convenience traits for iterators of (T, U) tuple pairs to behave like Iterator::unzip, with Extend in 1.56 and FromIterator in 1.79. These have now been extended to more tuple lengths, from singleton (T,) through to 12 items long, (T1, T2, .., T11, T12). For example, you can now use collect() to fanout into multiple collections at once:
use std::collections::{LinkedList, VecDeque};
fn main() {
let (squares, cubes, tesseracts): (Vec<_>, VecDeque<_>, LinkedList<_>) =
(0i32..10).map(|i| (i * i, i.pow(3), i.pow(4))).collect();
println!("{squares:?}");
println!("{cubes:?}");
println!("{tesseracts:?}");
}
std::env::home_dir() has been deprecated for years, because it can give surprising results in some Windows configurations if the HOME environment variable is set (which is not the normal configuration on Windows). We had previously avoided changing its behavior, out of concern for compatibility with code depending on this non-standard configuration. Given how long this function has been deprecated, we're now updating its behavior as a bug fix, and a subsequent release will remove the deprecation for this function.
Since 2022, Mozilla has been in an active process evolving what we do – and renewing our leadership. Today we announced several updates on the leadership piece of this ongoing work.
We’ve recognized that Mozilla faces major headwinds in terms of both financial growth and mission impact. While Firefox remains the core of what we do, we also need to take steps to diversify: investing in privacy-respecting advertising to grow new revenue in the near term; developing trustworthy, open source AI to ensure technical and product relevance in the mid term; and creating online fundraising campaigns that will draw a bigger circle of supporters over the long run. Mozilla’s impact and survival depend on us simultaneously strengthening Firefox AND finding new sources of revenue AND manifesting our mission in fresh ways. That is why we’re working hard on all of these fronts.
We’ve also moved aggressively to attract new leadership and talent to Mozilla. This includes major growth in our Boards, with 40% new Board members since we began our efforts to evolve and grow back in 2022. We’ve also been bringing in new executive talent, including a new MoFo Executive Director and a Managing Partner for Mozilla Ventures. By the end of the year, we hope to have new, permanent CEOs for both MoCo and Mozilla.ai.
Today we shared two updates as we continue to push forward with this renewal at the leadership level:
1. Mozilla Leadership Council:
We are creating a Mozilla Leadership Council composed of the top executive from each of Mozilla’s organizations. This includes: Jane Silber (Mozilla.ai), Laura Chambers (Mozilla Corporation), Mohamed Nanabhay (Mozilla Ventures), Nabiha Syed (Mozilla Foundation), Ryan Sipes (MZLA/Thunderbird) and myself. I will act as chair. The purpose of this group is to better coordinate work across our organizations to make sure that Mozilla is more than the sum of its parts.
2. New Board Chairs:
Mozilla has built a strong cadre of 16 directors across all of our Boards, bringing an incredible breadth of experience and a commitment to supporting Mozilla in doing the hard and important work ahead. Today we are announcing three new Board chairs:
The new Mozilla Foundation Board Chair is Nicole Wong. Nicole is a respected cross-sector privacy and policy expert and innovator, with leadership roles at Google and Twitter/X, service as Deputy U.S. Chief Technology Officer and positions on multiple corporate and non-profit boards. Nicole has been on Mozilla Foundation’s Board for 8 years.
Kerry Cooper will chair Mozilla Corporation. One of the world’s most respected CMO’s and consumer executives, Kerry has held C-Suite roles at Walmart.com, Rothy’s, Choose Energy and more, and now serves on boards spanning venture, startups and AI innovation. Kerry has been on Mozilla Corporation’s Board for 2 years.
Raffi Krikorian will chair Mozilla.ai. Raffi is a visionary technologist, engineer and leader, who was an early engineering leader at Twitter, headed Uber’s self-driving car lab, and is now CTO at the Emerson Collective where he works at the intersection of emerging technologies and social good. He brings three decades of thoughtful design and implementation within social media and artificial intelligence to Mozilla.
Each of these leaders reflects what I believe will be Mozilla’s ‘secret sauce’ in our next chapter: a mix of experience bridging business, technology and the public interest. Note that these appointments are now reflected on our leadership page.
With these changes, Mitchell Baker ends her tenure as Chair and a member of Mozilla Foundation and Mozilla Corporation boards.In co-founding Mozilla, Mitchell built something truly unique and important — a global community and organization that showed how those with vision can shape the world and the future by building technology that puts the needs of humans and humanity first. We are extremely grateful to Mitchell for everything she has done for Mozilla and we are committed to continuing her legacy of fighting for a better future through better technology. I know these feelings are widely shared across Mozilla — we are incredibly appreciative to Mitchell for all that she has done.
As I have said many times over the last few years, Mozilla is entering a new chapter—one where we need to both defend what is good about the web and steer the technology and business models of the AI era in a better direction. I believe that we have the people—indeed, we ARE the people—to do this, and that there are millions around the world ready to help us. I am driven and excited by what lies ahead.
Recently I got to land a patch which touches a cool optimization, that I had to really make sure I understood deeply. As a result, I wrote a huge commit message. I’d like to expand that message a touch here and turn it into a nice blog post.
This post assumes roughly that you understand how Shapes work in the JavaScript object model, and how prototypical property lookup works in JavaScript. If you don’t understand that just yet, this blog post by Matthias Bynens is a good start.
This patch aims to mitigate a performance cliff that occurs when we have applications which shadow properties on the prototype chain or which mutate the prototype chain.
The problem is that these actions currently break a property lookup optimization called “Shape Teleportation”.
What is Shape Teleporting?
Suppose you’re looking up some property y on an object obj, which has a prototype chain with 4 elements. Suppose y isn’t stored on obj, but instead is stored on some prototype object B, in slot 1.
In order to get the value of this property, officially you have to walk from obj up to B to find the value of y. Of course, this would be inefficient, so what we do instead is attach an inline cache to make this lookup more efficient.
Now we have to guard against future mutation when creating an inline cache. A basic version of a cache for this lookup might look like:
Check obj still has the same shape.
Check obj‘s prototype (D) still has the same shape.
Check D‘s prototype (C) still has the same shape
Check C’s prototype (B) still has the same shape.
Load slot 1 out of B.
This is less efficient than we would like though. Imagine if instead of having 3 intermediate prototypes, there were 13 or 30? You’d have this long chain of prototype shape checking, which takes a long time!
Ideally, what you’d like is to be able to simply say
Check obj still has the same shape.
Check B still has the same shape
Load slot 1 out of B.
The problem with doing this naively is “What if someone adds y as a property to C? With the faster guards, you’d totally miss that value, and as a result compute the wrong result. We don’t like wrong results.
Shape Teleporting is the existing optimization which says that so long as you actively force a change of shape on objects in the prototype chain when certain modifications occur, then you can guard in inline-caches only on the shape of the receiver object and the shape of the holder object.
By forcing each shape to be changed, inline caches which have baked in assumptions about these objects will no longer succeed, and we’ll take a slow path, potentially attaching a new IC if possible.
We must reshape in the following situations:
Adding a property to a prototype which shadows a property further up the prototype chain. In this circumstance, the object getting the new property will naturally reshape to account for the new property, but the old holder needs to be explicitly reshaped at this point, to avoid an inline cache jumping over the newly defined prototype.
Modifying the prototype of an object which exists on the prototype chain. For this case we need to invalidate the shape of the object being mutated (natural reshape due to changed prototype), as well as the shapes of all objects on the mutated object’s prototype chain. This is to invalidate all stubs which have teleported over the mutated object.
Furthermore, we must avoid an “A-B-A” problem, where an object returns to a shape prior to prototype modification: for example, even if we re-shape B, what if code deleted and then re-added y, causing B to take on its old shape? Then the IC would start working again, even though the prototype chain may have been mutated!
Prior to this patch, Watchtower watches for prototype mutation and shadowing, and marks the shapes of the prototype objects involved with these operations as InvalidatedTeleporting. This means that property access with the objects involved can never more rely on the shape teleporting optimization. This also avoids the A-B-A problem as new shapes will always carry along the InvalidatedTeleporting flag.
This patch instead chooses to migrate an object shape to dictionary mode, or generate a new dictionary shape if it’s already in dictionary mode. Using dictionary mode shapes works because all dictionary mode shapes are unique and never recycled. This ensures the ICs are no longer valid as expected, as well as handily avoiding the A-B-A problem.
The patch does keep the InvalidatedTeleporting flag to catch potentially ill-behaved sites that do lots of mutation and shadowing, avoiding having to reshape proto objects forever.
The patch also provides a preference to allow cross-comparison between old and new, however this patch defaults to dictionary mode teleportation.
Performance testing on micro-benchmarks shows large impact by allowing ICs to attach where they couldn’t before, however Speedometer3 shows no real movement.
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 on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request.
Want to get involved? We love contributions.
An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization. The following
RFCs would benefit from user testing before moving forward:
If you are a feature implementer and would like your RFC to appear on the above list, add the new 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.
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 X (formerly Twitter) or Mastodon!
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 X (formerly Twitter) or Mastodon!
This week's results were dominated by the update to LLVM 20 (#135763),
which brought a large number of performance improvements, as usually. There were also two other
significant improvements, caused by improving the representation of const values (#136593) and doing less work when formatting in rustdoc (#136828).
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.
transferControlToOffscreen() is now supported (@webbeef, #34959)
Streams are a lot more useful now, with ReadableStreamBYOBReader now supporting read() (@Taym95, #35040), cancel(), close(), and releaseLock() (@Taym95, #34958).
Servo aims to be an embeddable web engine, but so far it’s been a lot harder to embed Servo than it should be.
For one, configuring and starting Servo is complicated.
We found that getting Servo running at all, even without wiring up input or handling resizes correctly, took over 200 lines of Rust code (@delan, @mrobinson, #35118).
Embedders (apps) could only control Servo by sending and receiving a variety of “messages” and “events”, and simple questions like “what’s the current URL?” were impossible to answer without keeping track of extra state in the app.
Contrast this with WebKitGTK, where you can write a minimal kiosk app with a fully-functional webview in under 50 lines of C.
To close that gap, we’ve started reworking our embedding API towards something more idiomatic and ergonomic, starting with the concept embedders care about most: the webview.
Our new webview API is controlled by calling methods on a WebView handle (@delan, @mrobinson, #35119, #35183, #35192), including navigation and user input.
Handles will eventually represent the lifecycle of the webview itself; if you have one, the webview is valid, and if you drop them, the webview is destroyed.
Servo needs to call into the embedder too, and here we’ve started replacing the old EmbedderMsg API with a webview delegate (@delan, @mrobinson, #35211), much like the delegates in Apple’s WebKit API.
In Rust, a delegate is a trait that the embedder can install its own impl for.
Stay tuned for more on this next month!
Embedders can now intercept any request, not just navigation (@zhuhaichao518, #34961), and you can now identify the webview that caused an HTTP credentials prompt (@pewsheen, @mrobinson, #34808).
Other embedding improvements include:
Adding a trait to allow for alternative rendering contexts that are better suited to certain applications (@dklassic, @wusyong, #35052, #34813, #34780)
Making it easier to build Servo without crown (@jdm, #35055)
Other changes
We’ve reworked Servo’s preferences system, making all prefs optional with reasonable defaults (@mrobinson, #34966, #34999, #34994).
As a result:
The names of all preferences have changed; see the Prefs docs for a list
Embedders no longer need a prefs.json resource to get Servo running
Some debug options were converted to preferences (@mrobinson, #34998)
Devtools now highlights console.log() arguments according to their types (@simonwuelker, #34810).
Servo’s networking is more efficient now, with the ability to cancel fetches for navigation that contain redirects (@mrobinson, #34919) and cancel fetches for <video> and <media> when the document is unloaded (@mrobinson, #34883).
Those changes also eliminate per-request IPC channels for navigation and cancellation respectively, and in the same vein, we’ve eliminated them for image loading too (@mrobinson, #35041).
We’ve continued splitting up our massive script crate (@jdm, #34359, #35157, #35169, #35172), which will eventually make Servo much faster to build.
We now run CI smoketests on OpenHarmony using a real device (@jschwe, @mukilan, #35006), increasing confidence in your changes beyond compile-time errors.
We’ve also tripled our self-hosted CI runner capacity (@delan, #34983, #35002), making concurrent Windows and macOS builds possible without falling back to the much slower GitHub-hosted runners.
Servo can’t yet run WebDriver-based tests on wpt.fyi, wpt.servo.org, or CI, because the servo executor for the Web Platform Tests does not support testdriver.js.
servodriver does, though, so we’ve started fixing test regressions with that executor with the goal of eventually switching to it (@jdm, #34957, #34997).
Donations
Thanks again for your generous support!
We are now receiving 3835 USD/month (−11.4% over December) in recurring donations.
With this money, we’ve been able to expand our capacity for self-hostedCIrunners on Windows, Linux, and macOS builds, halving mach try build times from over an hour to under 30 minutes!
Servo is also on thanks.dev, and already 21 GitHub users (+5 over December) that depend on Servo are sponsoring us there.
If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.
3835 USD/month
10000
As always, use of these funds will be decided transparently in the Technical Steering Committee.
For more details, head to our Sponsorship page.
A fresh start isn’t just for your home — your iPhone or iPad deserves a privacy detox too. With Firefox for iOS, you can block hidden trackers, stop fingerprinting, and keep your browsing history more private with Enhanced Tracking Protection.
How Firefox for iOS protects you
Websites and advertisers often track your activity using cookies, fingerprinting and redirect trackers. Firefox’s Enhanced Tracking Protection helps detox your browsing experience by blocking these trackers, keeping your personal data safe from prying eyes.
Learn moreabout how Enhanced Tracking Protection works in this FAQ.
Privacy features built for iOS
Blocks Social Media Trackers – Prevents social media platforms from monitoring your activity across different sites. Prevents Cross-Site Tracking – Stops advertisers from following your movements from one site to another. Blocks Cryptominers and Fingerprinters – Protects your device from unauthorized cryptocurrency mining and digital fingerprinting attempts. Customizable Protection Levels – Choose between Standard and Strict modes to balance protection and site functionality. Private Browsing Mode – Browse without saving history, cookies, or site data, ensuring your sessions remain confidential. Sync Across Devices – Use Firefox on your iPhone, iPad, and desktop while keeping your privacy settings intact.
How to check your privacy settings on Firefox for iOS
Make sure you’re getting the best privacy protection by following these steps on your iPhone or iPad:
Open the Firefox app.
Tap the menu (☰) button at the bottom of the screen.
Select Settings, then tap Tracking Protection.
Choose your desired protection level:
Standard: Blocks social media trackers, cross-site trackers, cryptominers, and fingerprinters.
Strict: Includes all Standard protections and also stops known tracking content, such as videos, ads, and other elements with tracking code. Pages load faster, but this setting may block some website functionality.
A cleaner, safer way to browse on iOS
Spring cleaning isn’t just about organizing your space—it’s about clearing out digital clutter too. With Firefox for iOS, you can enjoy a faster, safer browsing experience while blocking trackers that slow you down.
Give your privacy a fresh start — join theSpring Detox with Firefoxtoday.
In the Firefox AI Runtime, we can use multiple threads in the dedicated inference process to speed up execution times CPU. The WASM/JS environment can create a SharedArrayBuffer and run multiple threads against its content and distribute the load on several CPU cores concurrently.
Below is the time taken in seconds on a MacBook M1 Pro, which has 10 physical cores, using our PDF.js image-to-text model to generate an alt text, with different levels of concurrency:
So running several threads is a game-changer ! But using more and more threads will start to slow down execution time to a point where it will become slower than not using threads at all.
So one question we have asked ourselves was: how can we determine the best number of threads ?
Physical vs logical cores
According to our most recent public data report, on desktop, 81% of our users are equipped with an Intel CPU, 14% with AMD and the rest are mostly Apple devices.
All modern CPUs provide more logical cores (also called “threads”) than physical cores. This happens due to technologies like Intel’s Hyper-Threading. Or AMD’s Simultaneous Multithreading (SMT).
For example, the Intel Core i9-10900Kchip has 10 physical cores and 20 logical cores.
When you spin up threads equal to the number of logical cores, you might see performance gains, especially when tasks are I/O bound or if the CPU can effectively interleave instructions.
However, for compute-bound tasks (like heavy ML inference), having more threads than physical cores can lead to diminishing returns, or even performance drops, due to factors like thread scheduling overhead and cache contention.
Not all cores are created equal
On Apple Silicon, you don’t just have a quantity of cores; you have different kinds of cores. Some are high-performance cores designed for heavy lifting, while others are efficiency cores that are optimized for lower power consumption.
For instance, Apple M1 Pro chips have a combination of high-performance (8) and efficiency cores (2). The physical cores might total 10, but each performance core is designed for heavy-duty tasks, while efficiency cores typically handle background tasks that are less demanding.
When your machine is under load with ML tasks, it’s often better to fully utilize the high-performance cores and leave some breathing room for the efficiency cores to handle background or system processes.
Similarly, Intel’s processors have different cores, most notably starting with their 12th-generation “Alder Lake” architecture.
These chips feature Performance-cores (P-cores) designed for demanding, single-threaded tasks, and Efficient-cores (E-cores) aimed at background or less intensive workloads. The P-cores can leverage Intel’s Hyper-Threading technology (meaning each P-core can run two logical threads), while E-cores typically run one thread each. This hybrid approach enables the CPU to optimize power usage and performance by scheduling tasks on the cores best suited for them. Like Apple Silicon’s you’d typically want to maximize utilization of the higher-performance P-cores, while leaving some headroom on the E-cores for system processes.
Android is close to Apple Silicon’s architecture, as most devices are using ARM’s big.LITTLE (or DynamIQ) architecture – with 2 types of cores: “big” and “LITTLE”.
On mobile Qualcomm’s CPU, there can be three types: “Prime”, “Performance” and “Efficiency”. Most recently, some phones like Samsung Galaxy S24 have gained a fourth kind of core (Exynos 2400) allowing even more combinations.
To summarize, all CPU makers have cores dedicated to performance, and cores for efficiency:
By combining high-efficiency and high-performance cores, Apple Silicon, Androids, and Intel based devices can strike a better balance between power consumption and raw compute power, depending on the demands of the workload.
But if you try to run all cores (performance + efficiency) at maximum capacity, you may see:
Less optimal thread scheduling, because tasks will bounce between slower efficiency cores and faster performance cores.
Contention for shared resources like the memory bus, cache.
And in extreme cases: thermal throttling if the system overheats, and reaches its Thermal Design Point, in which case the clock speed is throttled to cool down the system.
This is why simply setting the thread count to “all cores, all the time” can be suboptimal for performance.
AMD on the other hand, does not have efficiency cores. Some CPUs like the Ryzen 5 8000 combine two sizes of cores Zen 4 and Zen 4c, but the latter is not an efficiency core and can also be used to run heavy-duty tasks.
This returns the number of logical cores available. Since it’s the only API available on the web, many libraries (including the one we vendor: onnxruntime) default to using navigator.hardwareConcurrency as a baseline for concurrency.
It’s bad practice to use that value directly as it might overcommit threads as we’ve explained in the previous sections. It’s also not aware of the current system’s activity.
For that reason, ONNX formula takes the number of logical cores divided by two and will never set it higher than 4:
That formula works out ok in general, but will not take advantage of all the cores for some devices. For instance, on an Apple M1 Pro, ML tasks could use a concurrency level up to 8 cores instead of 4.
It has 12 logical cores and 10 physical cores that are composed of 8 efficient cores and 2 performance cores. ONNX formula for that chip means we would run with 4 threads, where 2 would be a better value.
navigator.hardwareConcurrency is a good starting point, but it’s just a blunt instrument. It won’t always yield the true “best” concurrency for a given device and a given workload.
MLUtils.getOptimalCPUConcurrency
While it’s impossible to get the best value at any given time without considering the system activity as a whole, looking at the number of physical cores and not using “efficiency” cores, can help to get to a better value.
On any x86_64, it will return the number of performance cores
On Android, and any aarch64-based devices like Apple Silicon it will return the number of performance cores for tri-layered chips.
We’ve implemented something very similar in a C++ API that can be used via XPIDL in our inference engine:
NS_IMETHODIMP MLUtils::GetOptimalCPUConcurrency(uint8_t* _retval) {
ProcessInfo processInfo = {};
if (!NS_SUCCEEDED(CollectProcessInfo(processInfo))) {
return NS_ERROR_FAILURE;
}
#if defined(ANDROID)
// On android, "big" and "medium" cpus can be used.
uint8_t cpuCount = processInfo.cpuPCount + processInfo.cpuMCount;
#else
# ifdef __aarch64__
// On aarch64 (like macBooks) we want to avoid efficient cores and stick with "big" cpus.
uint8_t cpuCount = processInfo.cpuPCount;
# else
// on x86_64 we're always using the number of physical cores.
uint8_t cpuCount = processInfo.cpuCores;
# endif
#endif
*_retval = cpuCount;
return NS_OK;
}
This function is then straightforward to use from JS shipped within Firefox to configure concurrency when we run inference:
let mlUtils = Cc["@mozilla.org/ml-utils;1"].createInstance(Ci.nsIMLUtils);
const numThreads = mlUtils.getOptimalCPUConcurrency();
We’ve moved away from using navigator.hardwareConcurrency, and we’re now using this new API.
Conclusion
In our quest to find the optimal number of threads, we’re closer to reality now, but there are other factors to consider. The system will use the CPU for other applications so it’s still possible to overload it.
Using more threads is also going to use more memory in our WASM environment, which can become a real issue. Depending on the workload, each additional thread can add up to 100MiB of physical memory usage in our runtime. We’re working on reducing this overhead but on devices that don’t have a lot of memory, limiting concurrency is still our best option.
For our Firefox ML features, we are using a variety of hardware profiles in our performance CI to make sure that we try them on devices that are close to what our users have. The list of devices we have is going to grow in the next few months to make sure we cover the whole spectrum of CPUs. We’ve started collecting and aggregating metrics on a dashboard that helps us understand what can be expected when our users run our inference engine.
The hardware landscape is also evolving a lot. For example, the most recent Apple devices introduced a new instruction set, called AMX, which used to be proprietary, and gave a significant boost compared to Neon. That has now been replaced by an official API called SME. Similarly, some phones are getting more core types, which could impact how we calculate the number of cores to use. Our current algorithm could be changed the day we leverage these new APIs and hardware in our backend.
Another aspect we have not discussed in this post is using GPU or even more specialized units like NPUs, to offload our ML tasks, which will be a post on its own.
I was slack on doing the Firefox 128ESR platform rebase for TenFourFox, but I finally got around tuit, mostly because I've been doing a little more work on the Quad G5 and put some additional patches in to scratch my own itches. (See, this is what I mean by "hobby mode.")
The big upgrade is a substantial overhaul of Reader Mode to pick up interval improvements in Readability. I remind folks that I went all-in on Reader Mode for a reason: it's lightweight, it makes little demands of our now antiquated machines (and TenFourFox's antiquated JavaScript runtime), and it renders very, very fast. That's why, for example, you can open a link directly in Reader Mode (right-click, it's there in the menu), the browser defaults to "sticky" Reader Mode where links you click in an article in Reader Mode stay in Reader Mode (like Las Vegas) until you turn it off from the book icon in the address bar, and you can designate certain sites to always open in Reader Mode, either every page or just subpages in case the front page doesn't render well — though that's improved too. (You can configure that from the TenFourFox preference pane. All of these features are unique to TenFourFox.) I also made some subtle changes to the CSS so that it lays out wider, which was really my only personal complaint; otherwise I'm an avid user. The improvements largely relate to better byline and "fluff" text detection as well as improved selection of article inline images. Try it. You'll like it.
I should note that Readability as written no longer works directly on TenFourFox due to syntactic changes and I had to do some backporting. If a page suddenly snaps to the non-Reader view, there was an error. Look in the Browser console for the message and report it; it's possible there is some corner I didn't hit with my own testing.
In addition, there are updates to the ATSUI font blacklist (and a tweak to CFF font table support) and a few low-risk security patches that likely apply to us, as well as refreshed HSTS pins, TLS root certificates, EV roots, timezone data and TLDs. I have also started adding certain AI-related code to the nuisance JavaScript block list as well as some new adbot host aliases I found. Those probably can't run on TenFourFox anyway (properly if at all), but now they won't even be loaded or parsed.
The source code can be downloaded from Github (at the command line you can also just do git clone https://github.com/classilla/tenfourfox.git) and built in the usual way. Remember that these platform updates require a clobber, so you must build from scratch. I was asked about making TenFourFox a bit friendlier with Github; that's a tall order and I'm still thinking about how, but at least the wiki is readable currently even if it isn't very pretty.
With more work and education happening online (and at home) you may find yourself needing new ways to juice your productivity. From time management to organizational tools and more, the right Firefox extension can give you an edge in the art of efficiency.
I need help saving and organizing a lot of web content
Gyazo
Capture, save, and share anything you find on the web. Gyazo is a great tool for personal or collaborative record keeping and research.
Clip entire pages or just pertinent portions. Save images or take screenshots. Gyazo makes it easy to perform any type of web clipping action by either right-clicking on the page element you want to save or using the extension’s toolbar button. Everything gets saved to your Gyazo account, making it accessible across devices and collaborative teams.
On your Gyazo homepage you can easily browse and sort everything you’ve clipped; and organize everything into shareable topics or collections.
<figcaption class="wp-element-caption">With its minimalist pop-up interface, Gyazo makes it easy to clip elements, sections, or entire web pages. </figcaption>
Evernote Web Clipper
Similar to Gyazo, Evernote Web Clipper offers a kindred feature set—clip, save, and share web content—albeit with some nice user interface distinctions.
Evernote places emphasis on making it easy to annotate images and articles for collaborative purposes. It also has a strong internal search feature, allowing you to search for specific words or phrases that might appear across scattered groupings of clipped content. Evernote also automatically strips out ads and social widgets on your saved pages.
Print Edit WE
If you need to save or print an important web page — but it’s mucked up with a bunch of unnecessary clutter like ads, sidebars, and other peripheral content — Print Edit WE lets you easily remove those unwanted elements.
Along with a host of great features like the option to save web pages as either HTML or PDF files, automatically delete graphics, and the ability to alter text or add notes, Print Edit WE also provides an array of productivity optimizations like keyboard shortcuts and mouse gestures. This is the ideal productivity extension for any type of work steeped in web research and cataloging.
Focus! Focus! Focus!
Anti-distraction and decluttering extensions can be a major boon for online workers and students…
Block Site
Do you struggle avoiding certain time-wasting, productivity-sucking websites? With Block Site you can enforce restrictions on sites that tempt you away from good work habits.
Just list the websites you want to avoid for specified periods of time (certain hours of the day or some days entirely, etc.) and Block Site won’t let you access them until you’re out of the focus zone. There’s also a fun redirection feature where you’re automatically redirected to a more productive website anytime you try to visit a time waster
<figcaption class="wp-element-caption">Give yourself a custom message of encouragement (or scolding?) whenever you try to visit a restricted site with Block Site</figcaption>
LeechBlock NG
Very similar in function to Block Site, LeechBlock NG offers a few intriguing twists beyond standard site-blocking features.
In addition to blocking sites during specified times, LeechBlock NG offers an array of granular, website-specific blocking abilities—like blocking just portions of websites (e.g. you can’t access the YouTube homepage but you can see video pages) to setting restrictions on predetermined days (e.g. no Twitter on weekends) to 60-second delayed access to certain websites to give you time to reconsider that potentially productivity killing decision.
Tomato Clock
A simple but highly effective time management tool, Tomato Clock (based on the Pomodoro technique) helps you stay on task by tracking short, focused work intervals.
The premise is simple: it assumes everyone’s productive attention span is limited, so break up your work into manageable “tomato” chunks. Let’s say you work best in 40-minute bursts. Set Tomato Clock and your browser will notify you when it’s break time (which is also time customizable). It’s a great way to stay focused via short sprints of productivity. The extension also keeps track of your completed tomato intervals so you can track your achieved results over time.
Tabby – Window & Tab Manager
Are you overwhelmed by lots of open tabs and windows? Need an easy way to overcome desktop chaos? Tabby – Window & Tab Manager to the rescue.
Regain control of your ever-sprawling open tabs and windows with an extension that lets you quickly reorganize everything. Tabby makes it easy to find what you need in a chaotic sea of open tabs — you can not only word/phrase search for the content your looking for, but Tabby also has a visual preview feature so you can get a look at each of your open tabs without actually navigating to them. And whenever you need a clean slate but want to save your work, you can save and close all of your open tabs with a single mouse click and return to them later.
<figcaption class="wp-element-caption">Access all of Tabby’s features in one convenient pop-up. </figcaption>
Tranquility Reader
Imagine a world wide web where everything but the words are stripped away—no more distracting images, ads, tempting links to related stories, nothing—just the words you’re there to read. That’s Tranquility Reader.
Simply hit the toolbar button and instantly streamline any web page. Tranquility Reader offers quite a few other nifty features as well, like the ability to save content offline for later reading, customizable font size and colors, add annotations to saved pages, and more.
We hope some of these great extensions will give your productivity a serious boost! Fact is there are a vast number of extensions out there that could possibly help your productivity—everything from ways to organize tons of open tabs to translation tools to bookmark managers and more.
Someone asked me recently how to contribute to the WebKit project and more specifically how to find the low hanging fruits. While some of these are specific to WebKit, they can be easily applied to other browsers. Every browser engines projects have more bugs than they can handle with their teams.
In no specific orders, some ideas for contributing.
Create simplified test case when there is none and add them as an attachment.
If they show differences in between the browsers, take a screenshot when it’s visual in Safari (WebKit), Firefox (Gecko), Chrome (Blink).
If there is no difference in between browsers, CC: me on the bug, and probably we will be able to close it.
This might help reveal some old fixable bug or make it easier to fix it for another engineer. Some of them might be easy enough that you can start fix them yourself.
Sometimes these Quirks are not needed anymore. The site has made a silent fix. They didn't tell us about it.
They need to be retested and flagged when there are not necessary anymore. This can lead to patches on removing the quirk when it is not needed anymore.
Some of these quirks do not have the remove quirk bug counterpart. It would be good to create the bug for them. Example of a Remove Quirk Bug.
Again, this is strongly explaining how to help from the side of WebKit. But these type of participation can be easily transposed for Gecko and Blink. If you have other ideas for fixing bugs, let me know.
The Interop Project is a collaboration between browser vendors and other platform implementors to provide users and web developers with high quality implementations of the web platform.
Each year we select a set of focus areas representing key areas where we want to improve interoperability. Encouraging all browser engines to prioritize common features ensures they become usable for web developers as quickly as possible.
Progress in each engine and the overall Interop score are measured by tracking the pass rate of a set of web-platform tests for each focus area using the Interop dashboard.
Interop 2024
Before introducing the new focus areas for this year, we should look at the successes of Interop 2024.
The Interop score, measuring the percentage of tests that pass in all of the major browser engines, has reached 95% in latest browser releases, up from only 46% at the start of the year. In pre-release browsers it’s even higher — over 97%. This is a huge win that shows how effective Interop can be at aligning browsers with the specifications and each other.
Each browser engine individually achieved a test pass score of 98% in stable browser releases and 99% in pre-release, with Firefox finishing slightly ahead with 98.8% in release and 99.1% in Nightly.
Building on Interop 2024’s success, we are excited to continue the project into 2025. This year we have 19 focus areas; 17 new and 2 from previous years. A full description of all the focus areas is available in the Interop repository.
From 2024 we’re carrying forward Layout (really “Flexbox and Grid”), and Pointer and Mouse Events. These are important platform primitives where the Interop project has already led to significant interoperability improvements. However, with technologies that are so fundamental to the modern web we think it’s important to set ambitious goals and continue to prioritize these areas, creating rock solid foundations for developers to build on.
The new focus areas represent a broad cross section of the platform. Many of them — like Anchor Positioning and View Transitions — have been identified from clear developer demand in surveys such as State of HTML and State of CSS. Inclusion in Interop will ensure they’re usable as soon as possible.
In addition to these high profile new features, we’d like to highlight some lesser-known focus areas and explain why we’re pleased to see them in Interop.
Storage Access
At Mozilla user privacy is a core principle. One of the most common methods for tracking across the web is via third-party cookies. When sites request data from external services, the service can store data that’s re-sent when another site uses the same service. Thus the service can follow the user’s browsing across the web.
To counter this, Firefox’s “Total Cookie Protection” partitions storage so that third parties receive different cookie data per site and thus reduces tracking. Other browsers have similar policies, either by default or in private browsing modes.
However, in some cases, non-tracking workflows such as SSO authentication depend on third party cookies. Storage partitioning can break these workflows, and browsers currently have to ship site-specific workarounds. The Storage Access API solves this by letting sites request access to the unpartitioned cookies. Interop here will allow browsers to advance privacy protections without breaking critical functionality.
Web Compat
The Web Compat focus area is unique in Interop. It isn’t about one specific standard, but focuses on browser bugs known to break sites. These are often in older parts of the platform with long-standing inconsistencies. Addressing these requires either aligning implementations with the standard or, where that would break sites, updating the standard itself.
One feature in the Web Compat focus area for 2025 is CSS Zoom. Originally a proprietary feature in Internet Explorer, it allowed scaling layout by adjusting the computed dimensions of elements at a time before CSS transforms. WebKit reverse-engineered it, bringing it into Blink, but Gecko never implemented it, due to the lack of a specification and the complexities it created in layout calculations.
Unfortunately, a feature not being standardised doesn’t prevent developers from using it. Use of CSS Zoom led to layout issues on some sites in Firefox, especially on mobile. We tried various workarounds and have had success using interventions to replace zoom with CSS transforms on some affected sites, but an attempt to implement the same approach directly in Gecko broke more sites than it fixed and was abandoned.
The situation seemed to be at an impasse until 2023 when Google investigated removing CSS Zoom from Chromium. Unfortunately, it turned out that some use cases, such as Microsoft Excel Online’s worksheet zoom, depended on the specific behaviour of CSS Zoom, so removal was not feasible. However, having clarified the use cases, the Chromium team was able to propose a standardized model for CSS Zoom that was easier to implement without compromising compatibility. This proposal was accepted by the CSS WG and led to the first implementation of CSS Zoom in Firefox 126, 24 years after it was first released in Internet Explorer.
With Interop 2025, we hope to bring the story of CSS Zoom to a close with all engines finally converging on the same behaviour, backed by a real open standard.
WebRTC
Video conferencing is now an essential feature of modern life, and in-browser video conferencing offers both ease of use and high security, as users are not required to download a native binary. Most web-based video conferencing relies on the WebRTC API, which offers high level tools for implementing real time communications. However, WebRTC has long suffered from interoperability issues, with implementations deviating from the standards and requiring nonstandard extensions for key features. This resulted in confusion and frustration for users and undermined trust in the web as a reliable alternative to native apps.
Given this history, we’re excited to see WebRTC in Interop for the first time. The main part of the focus area is the RTCRtpScriptTransform API, which enables cross browser end-to-end encryption. Although there’s more to be done in the future, we believe Interop 2025 will be a big step towards making WebRTC a truly interoperable web standard.
Removing Mutation Events
The focus area for Removing Mutation Events is the first time Interop has been used to coordinate the removal of a feature. Mutation events fire when the DOM changes, meaning the event handlers run on the critical path for DOM manipulation, causing major performance issues, and significant implementation complexity. Despite the fact that they have been implemented in all engines, they’re so problematic that they were never standardised. Instead, mutation observers were developed as a standard solution for the use cases of mutation events without their complexity or performance problems. Almost immediately after mutation observers were implemented, a Gecko bug was filed:
“We now have mutation observers, and we’d really like to kill support for mutation events at some point in the future. Probably not for a while yet.”
That was in 2012. The difficulty is the web’s core commitment to backwards compatibility. Removing features that people rely on is unacceptable. However, last year Chromium determined that use of mutation events had dropped low enough to allow a “deprecation trial“, disabling mutation events by default, but allowing specific sites to re-enable them for a limited time.
This is good news, but long-running deprecation trials can create problems for other browsers. Disabling the feature entirely can break sites that rely on the opt-out. On the other hand we know from experience that some sites actually function better in a browser with mutation events disabled (for example, because they are used for non-critical features, but impact performance).
By including this removal in Interop 2025, we can ensure that mutation events are fully removed in 2025 and end the year with reduced platform complexity and improved web performance.
Interop Investigations
As well as focus areas, the Interop project also runs investigations aimed at long-term interoperability improvements to areas where we can’t measure progress using test pass rates. For example Interop investigations can be looking to add new test capabilities, or increase the test coverage of platform features.
Accessibility Investigation
The accessibility testing started as part of Interop 2023. It has added APIs for testing accessible name and computed role, as well as more than 1000 new tests. Those tests formed the Accessibility focus area in Interop 2024, which achieved an Interop score of 99.7%.
In 2025 the focus will be expanding the testability of accessibility features. Mozilla is working on a prototype of AccessibleNode; an API that enables verifying the shape of the accessibility tree, along with its states and properties. This will allow us to test the effect of features like CSS display: contents or ::before/::after on the accessibility tree.
Mobile Testing Investigation
Today, all Interop focus areas are scored in desktop browsers. However, some features are mobile-specific or have interoperability challenges unique to mobile.
Improving mobile testing has been part of Interop since 2023, and in that time we’ve made significant progress standing up mobile browsers in web-platform-tests CI systems. Today we have reliable runs of Chrome and Firefox Nightly on Android, and Safari runs on iOS are expected soon. However, some parts of our test framework were written with desktop-specific assumptions in the design, so the focus for 2025 will be on bringing mobile testing to parity with desktop. The goal is to allow mobile-specific focus areas in future Interop projects, helping improve interoperability across all device types.
Driving the Web Forward
The unique and distinguishing feature of the web platform is its basis in open standards, providing multiple implementations and user choice. Through the Interop project, web platform implementors collaborate to ensure that these core strengths are matched by a seamless user experience across browsers.
With focus areas covering some of the most important new and existing areas of the modern web, Interop 2025 is set to deliver some of the biggest interoperability wins of the project so far. We are confident that Firefox and other browsers will rise to the challenge, providing users and developers with a more consistent and reliable web platform.
The Rust Survey Team is excited to share the results of our 2024 survey on the Rust Programming language, conducted between December 5, 2024 and December 23, 2024.
As in previous years, the 2024 State of Rust Survey was focused on gathering insights and feedback from Rust users, and all those who are interested in the future of Rust more generally.
This ninth edition of the survey surfaced new insights and learning opportunities straight from the global Rust language community, which we will summarize below. In addition to this blog post, we have also prepared a report containing charts with aggregated results of all questions in the survey.
Our sincerest thanks to every community member who took the time to express their opinions and experiences with Rust over the past year. Your participation will help us make Rust better for everyone.
There's a lot of data to go through, so strap in and enjoy!
Participation
Survey
Started
Completed
Completion rate
Views
2023
11 950
9 710
82.2%
16 028
2024
9 450
7 310
77.4%
13 564
As shown above, in 2024, we have received fewer survey views than in the previous year. This was likely caused simply by the fact that the survey ran only for two weeks, while in the previous year it ran for almost a month. However, the completion rate has also dropped, which seems to suggest that the survey might be a bit too long. We will take this into consideration for the next edition of the survey.
Community
The State of Rust survey not only gives us excellent insight into how many Rust users around the world are using and experiencing the language but also gives us insight into the makeup of our global community. This information gives us a sense of where the language is being used and where access gaps might exist for us to address over time. We hope that this data and our related analysis help further important discussions about how we can continue to prioritize global access and inclusivity in the Rust community.
Same as every year, we asked our respondents in which country they live in. The top 10 countries represented were, in order: United States (22%), Germany (14%), United Kingdom (6%), France (6%), China (5%), Canada (3%), Netherlands (3%), Russia (3%), Australia (2%), and Sweden (2%). We are happy to see that Rust is enjoyed by users from all around the world! You can try to find your country in the chart below:
We also asked whether respondents consider themselves members of a marginalized community. Out of those who answered, 74.5% selected no, 15.5% selected yes, and 10% preferred not to say.
We have asked the group that selected “yes” which specific groups they identified as being a member of. The majority of those who consider themselves a member of an underrepresented or marginalized group in technology identify as lesbian, gay, bisexual, or otherwise non-heterosexual. The second most selected option was neurodivergent at 46% followed by trans at 35%.
Each year, we must acknowledge the diversity, equity, and inclusivity (DEI) related gaps in the Rust community and open source as a whole. We believe that excellent work is underway at the Rust Foundation to advance global access to Rust community gatherings and distribute grants to a diverse pool of maintainers each cycle, which you can learn more about here. Even so, global inclusion and access is just one element of DEI, and the survey working group will continue to advocate for progress in this domain.
Rust usage
The number of respondents that self-identify as a Rust user was quite similar to last year, around 92%. This high number is not surprising, since we primarily target existing Rust developers with this survey.
Similarly as last year, around 31% of those who did not identify as Rust users cited the perception of difficulty as the primary reason for not using Rust. The most common reason for not using Rust was that the respondents simply haven’t had the chance to try it yet.
Of the former Rust users who participated in the 2024 survey, 36% cited factors outside their control as a reason why they no longer use Rust, which is a 10pp decrease from last year. This year, we also asked respondents if they would consider using Rust again if an opportunity comes up, which turns out to be true for a large fraction of the respondents (63%). That is good to hear!
Closed answers marked with N/A were not present in the previous version(s) of the survey.
Those not using Rust anymore told us that it is because they don't really need it (or the goals of their company changed) or because it was not the right tool for the job. A few reported being overwhelmed by the language or its ecosystem in general or that switching to or introducing Rust would have been too expensive in terms of human effort.
Of those who used Rust in 2024, 53% did so on a daily (or nearly daily) basis — an increase of 4pp from the previous year. We can observe an upward trend in the frequency of Rust usage over the past few years, which suggests that Rust is being increasingly used at work. This is also confirmed by other answers mentioned in the Rust at Work section later below.
Rust expertise is also continually increasing amongst our respondents! 20% of respondents can write (only) simple programs in Rust (a decrease of 3pp from 2023), while 53% consider themselves productive using Rust — up from 47% in 2023. While the survey is just one tool to measure the changes in Rust expertise overall, these numbers are heartening as they represent knowledge growth for many Rustaceans returning to the survey year over year.
Unsurprisingly, the most popular version of Rust is latest stable, either the most recent one or whichever comes with the users' Linux distribution. Almost a third of users also use the latest nightly release, due to various reasons (see below). However, it seems that the beta toolchain is not used much, which is a bit unfortunate. We would like to encourage Rust users to use the beta toolchain more (e.g. in CI environments) to help test soon-to-be stabilized versions of Rust.
People that use the nightly toolchain mostly do it to gain access to specific unstable language features. Several users have also mentioned that rustfmt works better for them on nightly or that they use the nightly compiler because of faster compilation times.
To use Rust, programmers first have to learn it, so we are always interested in finding out how do they approach that. Based on the survey results, it seems that most users learn from Rust documentation and also from The Rust Programming Language book, which has been a favourite learning resource of new Rustaceans for a long time. Many people also seem to learn by reading the source code of Rust crates. The fact that both the documentation and source code of tens of thousands of Rust crates is available on docs.rs and GitHub makes this easier.
In terms of answers belonging to the "Other" category, they can be clustered into three categories: people using LLM (large language model) assistants (Copilot, ChatGPT, Claude, etc.), reading the official Rust forums (Discord, URLO) or being mentored while contributing to Rust projects. We would like to extend a big thank you to those making our spaces friendly and welcoming for newcomers, as it is important work and it pays off. Interestingly, a non-trivial number of people "learned by doing" and used rustc error messages and clippy as a guide, which is a good indicator of the quality of Rust diagnostics.
In terms of formal education, it seems that Rust has not yet penetrated university curriculums, as this is typically a very slowly moving area. Only a very small number of respondents (around 3%) have taken a university Rust course or used university learning materials.
In terms of operating systems used by Rustaceans, Linux was the most popular choice, and it seems that it is getting increasingly popular year after year. It is followed by macOS and Windows, which have a very similar share of usage.
As you can see in the wordcloud, there are also a few users that prefer Arch, btw.
Rust programmers target a diverse set of platforms with their Rust programs. We saw a slight uptick in users targeting embedded and mobile platforms, but otherwise the distribution of platforms stayed mostly the same as last year. Since the WebAssembly target is quite diverse, we have split it into two separate categories this time. Based on the results it is clear that when using WebAssembly, it is mostly in the context of browsers (23%) rather than other use-cases (7%).
We cannot of course forget the favourite topic of many programmers: which IDE (developer environment) they use. Although Visual Studio Code still remains the most popular option, its share has dropped by 5pp this year. On the other hand, the Zed editor seems to have gained considerable traction recently. The small percentage of those who selected "Other" are using a wide range of different tools: from CursorAI to classics like Kate or Notepad++. Special mention to the 3 people using "ed", that's quite an achievement.
You can also take a look at the linked wordcloud that summarizes open answers to this question (the "Other" category), to see what other editors are also popular.
Rust at Work
We were excited to see that more and more people use Rust at work for the majority of their coding, 38% vs 34% from last year. There is a clear upward trend in this metric over the past few years.
The usage of Rust within companies also seems to be rising, as 45% of respondents answered that their organisation makes non-trivial use of Rust, which is a 7pp increase from 2023.
Once again, the top reason employers of our survey respondents invested in Rust was the ability to build relatively correct and bug-free software. The second most popular reason was Rust’s performance characteristics. 21% of respondents that use Rust at work do so because they already know it, and it's thus their default choice, an uptick of 5pp from 2023. This seems to suggest that Rust is becoming one of the baseline languages of choice for more and more companies.
Similarly to the previous year, a large percentage of respondents (82%) report that Rust helped their company achieve its goals. In general, it seems that programmers and companies are quite happy with their usage of Rust, which is great!
In terms of technology domains, the situation is quite similar to the previous year. Rust seems to be especially popular for creating server backends, web and networking services and cloud technologies. It also seems to be gaining more traction for embedded use-cases.
You can scroll the chart to the right to see more domains. Note that the Automotive domain was not offered as a closed answer in the 2023 survey (it was merely entered through open answers), which might explain the large jump.
It is exciting to see the continued growth of professional Rust usage and the confidence so many users feel in its performance, control, security and safety, enjoyability, and more!
Challenges
As always, one of the main goals of the State of Rust survey is to shed light on challenges, concerns, and priorities on Rustaceans’ minds over the past year.
We have asked our users about aspects of Rust that limit their productivity. Perhaps unsurprisingly, slow compilation was at the top of the list, as it seems to be a perennial concern of Rust users. As always, there are efforts underway to improve the speed of the compiler, such as enabling the parallel frontend or switching to a faster linker by default. We invite you to test these improvements and let us know if you encounter any issues.
Other challenges included subpar support for debugging Rust and high disk usage of Rust compiler artifacts. On the other hand, most Rust users seem to be very happy with its runtime performance, the correctness and stability of the compiler and also Rust's documentation.
In terms of specific unstable (or missing) features that Rust users want to be stabilized (or implemented), the most desired ones were async closures and if/let while chains. Well, we have good news! Async closures will be stabilized in the next version of Rust (1.85), and if/let while chains will hopefully follow soon after, once Edition 2024 is released (which will also happen in Rust 1.85).
Other coveted features are generators (both sync and async) and more powerful generic const expressions. You can follow the Rust Project Goals to track the progress of these (and other) features.
In the open answers to this question, people were really helpful and tried hard to describe the most notable issues limiting their productivity. We have seen mentions of struggles with async programming (an all-time favourite), debuggability of errors (which people generally love, but they are not perfect for everyone) or Rust tooling being slow or resource intensive (rust-analyzer and rustfmt). Some users also want a better IDE story and improved interoperability with other languages.
This year, we have also included a new question about the speed of Rust's evolution. While most people seem to be content with the status quo, more than a quarter of people who responded to this question would like Rust to stabilize and/or add features more quickly, and only 7% of respondents would prefer Rust to slow down or completely stop adding new features.
Interestingly, when we asked respondents about their main worries for the future of Rust, one of the top answers remained the worry that Rust will become too complex. This seems to be in contrast with the answers to the previous question. Perhaps Rust users still seem to consider the complexity of Rust to be manageable, but they worry that one day it might become too much.
We are happy to see that the amount of respondents concerned about Rust Project governance and lacking support of the Rust Foundation has dropped by about 6pp from 2023.
Each year, the results of the State of Rust survey help reveal the areas that need improvement in many areas across the Rust Project and ecosystem, as well as the aspects that are working well for our community.
If you have any suggestions for the Rust Annual survey, please let us know!
We are immensely grateful to those who participated in the 2024 State of Rust Survey and facilitated its creation. While there are always challenges associated with developing and maintaining a programming language, this year we were pleased to see a high level of survey participation and candid feedback that will truly help us make Rust work better for everyone.
If you’d like to dig into more details, we recommend you to browse through the full survey report.
With Mozilla’s migration from hg.mozilla.org to Github drawing near, the clock
is ticking for developers still using Mercurial to find their new workflow. I
previously blogged about how Jujutsu can help here, so please check that post
out first if you aren’t sure what Jujutsu is, or whether it’s right for you. If
you know you want to give it a shot, read on for a tutorial on how to get
everything set up!
We’ll start with an existing Mercurial clone of mozilla-unified, convert it to
use git-cinnabar and then set up Jujutsu using the co-located repo method.
Finally I’ll cover some tips and tricks for using some of the tooling that
relies on version control.
<figcaption class="wp-element-caption">Emily Liu is the head of special projects at Bluesky.</figcaption>
Here at Mozilla, we are the first to admit the internet isn’t perfect, but we know the internet is pretty darn magical. The internet opens up doors and opportunities, allows for human connection, and lets everyone find where they belong — their corners of the internet. We all have an internet story worth sharing. In My Corner Of The Internet, we talk with people about the online spaces they can’t get enough of, the sites and forums that shaped them, and how they would design their own corner of the web.
We caught up with Emily Liu, head of special projects at Bluesky, as the open-source platform celebrates its first year launching to the public (you can follow Firefox on Bluesky here). She talks about how social media has changed over the last decade, her love for public forums and how her path started with a glitter cursor.
What is your favorite corner of the internet?
I’m at the two extremes on the spectrum of private to public content:
Firstly, I love a good iMessage group text, especially when it’s moving at 100 miles per hour. I strongly believe that everyone needs a good group chat.
At the same time, I love public web forums. This feels like something that’s increasingly rare on the internet as more of us move to private group apps, and I worry that this is equivalent to pulling the ladder up behind us for those who haven’t found those private spaces yet. So I try to do my part by chiming in on public forums when I can offer something useful.
What is the one tab you always regret closing?
I live by Google Calendar and have widgets for it on probably every digital surface — my desktop, my phone lock screen, my laptop side menu, and of course, multiple tabs simultaneously. If something’s not on my calendar, it’s probably not happening.
What can you not stop talking about on the internet right now?
I’m super excited about Bluesky. Obviously I’m unbiased (I work here). We launched the Bluesky app publicly in just February 2024, and under a year later, we crossed 30M people on the network. But the real measure of Bluesky’s growth is that my family has started sending me news articles and asking, “Hey, isn’t this where you work?”
Social networks have become vital public infrastructure, whether it’s to get the latest breaking news, find jobs and opportunities, or stay in touch with our friends and family. Yet over the last decade, closed networks have locked users in, preventing competition and innovation in social media as their services deteriorate. On the other hand, Bluesky is both a social app where your experience online is yours to customize, and an open network that reintroduces competition to social media. This also means that the social network isn’t defined by whoever the CEO is, however capricious they might be.
What was the first online community you engaged with?
In middle school, I ran an anonymous fashion blog on Tumblr. This was before Tumblr had group chats, so internet friends and I co-opted the product by creating a makeshift group DM — a private blog with multiple owners, where every message we sent was really just a post on a private blog. Where there is a will, there is a way, and people are infinitely creative; this is where I learned that the product you design may not be the product that users adopt.
Tumblr was also where I wrote my first lines of code out of desperation for a better blog theme than what the default marketplace provided. Who would’ve thought that adding a visitor counter and a glitter cursor would’ve led me to this point!
If you could create your own corner of the internet, what would it look like?
I feel lucky that in a sense, I am doing this right now through Bluesky. On one hand, there’s the Bluesky app itself. There’s still a bunch of low-hanging fruit to reach feature parity with other social networks, but on top of that, I’m excited about tweaks that might make social media less of a “torment nexus” that other apps haven’t tried yet. Maybe I shouldn’t share them here just yet since I know a certain other company likes to implement Bluesky’s ideas.
And on the other hand, Bluesky is already so customizable that I can configure my experience to be what I want. For example, I’m a big fan of the Quiet Posters custom feed, which shows you posts from people you follow who don’t often post that much, giving you a cozier feel of the network.
What articles and/or videos are you waiting to read/watch right now?
I have so many open tabs and unread newsletters about China and AI that I need to get to.
What role do you see open web projects like Bluesky playing in shaping the future of the web?
I see Bluesky as just one contributor in the mission of building an open web — we’re not the first project to build an open social network, and we won’t be the last. The collaboration and constructive criticism from other players has been immensely useful. Recently, some independent groups have begun building alternative ATProto infrastructure, which I’m particularly excited about. (ATProto, or the AT Protocol, is the open standard that Bluesky is built upon.) Bluesky’s vision of a decentralized and open social web only comes to fruition when users actually have alternatives to choose from, so I’m rooting for all of these projects too.
Emily Liu is the head of special projects at Bluesky, an open social network that gives creators independence from platforms, developers the freedom to build, and users a choice in their experience. Previously, Emily built election models and visualizations at The Washington Post, archival tooling at The New York Times, and automated fact-checking at the Duke Reporters’ Lab.
Hello again Thunderbird Community! As January drew to a close, the team was closing in on the completion of some important milestones. Additionally, we had scoped work for our main Q1 priorities. Those efforts are now underway and it feels great to cross things off the list and start tackling new challenges.
A modest contingent from the Thunderbird team joined our Mozilla counterparts for an educational and inspiring weekend at Fosdem recently. We talked about standards, problems, solutions and everything in between. However, the most satisfying part of the weekend being standing at the Thunderbird booth and hearing the gratitude, suggestions and support from so many users.
With such important discussions among leading voices, we’re keen to help in finding or implementing solutions to some of the meatier topics such as:
OAuth 2.0 Dynamic Client Registration Protocol
Support for unicode email addresses
Support for OpenPGP certification authorities and trust delegation
Exchange Web Services support in Rust
With a reduction in team capacity for part of January, the team was able to complete work on the following tasks that form some of the final stages in our 0.2 release:
We completed the second and final milestone in the First Time User Experience for email configuration via the enhanced Account Hub over the course of January. Tasks included density and font awareness, refactoring of state management, OAuth prompts, enhanced error handling and more which can be followed via Meta bug & progress tracking. Watch out for this feature being unveiled in daily and beta in the coming weeks!
Global Message Database
With a significant number of the research and prototyping tasks now behind us, the project has taken shape over the course of January with milestones and tasks mapped out. Recent progress has been related to live view, sorting and support for Unicode server and folder names.
Next up is to finally crack the problem of “non-unique unique IDs” mentioned previously, which is important preparatory groundwork required for a clean database migration.
In-App Notifications
Phase 2 is now complete, and almost ready for uplift to ESR, pending underlying Firefox dependencies scheduled in early March. Features and user stories in the latest milestone include a cache-control mechanism, a thorough accessibility review, schema changes and the addition of guard rails to limit notification frequency. Meta Bug & progress tracking.
New Features Landing Soon
Several requested features and fixes have reached our Daily users and include…
More folder compaction fixes and performance improvements!
To see things as they land, and help squash early bugs, you can check the pushlog and try running daily. This would be immensely helpful for catching things early.
I believe that AI-powered development tools can be a game changer for Rust—and vice versa. At its core, my argument is simple: AI’s ability to explain and diagnose problems with rich context can help people get over the initial bump of learning Rust in a way that canned diagnostics never could, no matter how hard we try. At the same time, rich type systems like Rust’s give AIs a lot to work with, which could be used to help them avoid hallucinations and validate their output. This post elaborates on this premise and sketches out some of the places where I think AI could be a powerful boost.
Perceived learning curve is challenge #1 for Rust
Is Rust good for every project? No, of course not. But it’s absolutely great for some things—specifically, building reliable, robust software that performs well at scale. This is no accident. Rust’s design is intended to surface important design questions (often in the form of type errors) and to give users the control to fix them in whatever way is best.
But this same strength is also Rust’s biggest challenge. Talking to people within Amazon about adopting Rust, perceived complexity and fear of its learning curve is the biggest hurdle. Most people will say, “Rust seems interesting, but I don’t need it for this problem”. And you know, they’re right! They don’t need it. But that doesn’t mean they wouldn’t benefit from it.
One of Rust’s big surprises is that, once you get used to it, it’s “surprisingly decent” at very large number of things beyond what it was designed for. Simple business logic and scripts can be very pleasant in Rust. But the phase “once you get used to it” in that sentence is key, since most people’s initial experience with Rust is confusion and frustration.
Rust likes to tell you no (but it’s for your own good)
Some languages are geared to say yes—that is, given any program, they aim to run it and do something. JavaScript is of course the most extreme example (no semicolons? no problem!) but every language does this to some degree. It’s often quite elegant. Consider how, in Python, you write vec[-1] to get the last element in the list: super handy!
Rust is not (usually) like this. Rust is geared to say no. The compiler is just itching for a reason to reject your program. It’s not that Rust is mean: Rust just wants your program to be as good as it can be. So we try to make sure that your program will do what you want (and not just what you asked for). This is why vec[-1], in Rust, will panic: sure, giving you the last element might be convenient, but how do we know you didn’t have an off-by-one bug that resulted in that negative index?1
But that tendency to say no means that early learning can be pretty frustrating. For most people, the reward from programming comes from seeing their program run—and with Rust, there’s a lot of niggling details to get right before your program will run. What’s worse, while those details are often motivated by deep properties of your program (like data races), the way they are presented is as the violation of obscure rules, and the solution (“add a *”) can feel random.
Once you get the hang of it, Rust feels great, but getting there can be a pain. I heard a great phrase from someone at Amazon to describe this: “Rust: the language where you get the hangover first”.3
AI today helps soften the learning curve
My favorite thing about working at Amazon is getting the chance to talk to developers early in their Rust journey. Lately I’ve noticed an increasing trend—most are using Q Developer. Over the last year, Amazon has been doing a lot of internal promotion of Q Developer, so that in and of itself is no surprise, but what did surprise me a bit is hearing from developers the way that they use it.
For most of them, the most valuable part of Q Dev is authoring code but rather explaining it. They ask it questions like “why does this function take an &T and not an Arc<T>?” or “what happens when I move a value from one place to another?”. Effectively, the LLM becomes an ever-present, ever-patient teacher.4
Scaling up the Rust expert
Some time back I sat down with an engineer learning Rust at Amazon. They asked me about an error they were getting that they didn’t understand. “The compiler is telling me something about ‘static, what does that mean?” Their code looked something like this:
error[E0521]: borrowed data escapes outside of function
--> src/lib.rs:2:5
|
1 | async fn log_request_in_background(message: &str) {
| ------- - let's call the lifetime of this reference `'1`
| |
| `message` is a reference that is only valid in the function body
2 | / tokio::spawn(async move {
3 | | log_request(message);
4 | | });
| | ^
| | |
| |______`message` escapes the function body here
| argument requires that `'1` must outlive `'static`
This is a pretty good error message! And yet it requires significant context to understand it (not to mention scrolling horizontally, sheesh). For example, what is “borrowed data”? What does it mean for said data to “escape”? What is a “lifetime” and what does it mean that “'1 must outlive 'static”? Even assuming you get the basic point of the message, what should you do about it?
The fix is easy… if you know what to do
Ultimately, the answer to the engineer’s problem was just to insert a call to clone5. But deciding on that fix requires a surprisingly large amount of context. In order to figure out the right next step, I first explained to the engineer that this confusing error is, in fact, what it feels like when Rust saves your bacon, and talked them through how the ownership model works and what it means to free memory. We then discussed why they were spawning a task in the first place (the answer: to avoid the latency of logging)—after all, the right fix might be to just not spawn at all, or to use something like rayon to block the function until the work is done.
Once we established that the task needed to run asynchronously from its parent, and hence had to own the data, we looked into changing the log_request_in_background function to take an Arc<String> so that it could avoid a deep clone. This would be more efficient, but only if the caller themselves could cache the Arc<String> somewhere. It turned out that the origin of this string was in another team’s code and that this code only returned an &str. Refactoring that code would probably be the best long term fix, but given that the strings were expected to be quite short, we opted to just clone the string.
You can learn a lot from a Rust error
An error message is often your first and best chance to teach somebody something.—Esteban Küber (paraphrased)
Working through this error was valuable. It gave me a chance to teach this engineer a number of concepts. I think it demonstrates a bit of Rust’s promise—the idea that learning Rust will make you a better programmer overall, regardless of whether you are using Rust or not.
Despite all the work we have put into our compiler error messages, this kind of detailed discussion is clearly something that we could never achieve. It’s not because we don’t want to! The original concept for --explain, for example, was to present a customized explanation of each error was tailored to the user’s code. But we could never figure out how to implement that.
And yet tailored, in-depth explanation is absolutely something an LLM could do. In fact, it’s something they already do, at least some of the time—though in my experience the existing code assistants don’t do nearly as good a job with Rust as they could.
What makes a good AI opportunity?
Emery Berger is a professor at UMass Amherst who has been exploring how LLMs can improve the software development experience. Emery emphasizes how AI can help close the gap from “tool to goal”. In short, today’s tools (error messages, debuggers, profilers) tell us things about our program, but they stop there. Except in simple cases, they can’t help us figure out what to do about it—and this is where AI comes in.
When I say AI, I am not talking (just) about chatbots. I am talking about programs that weave LLMs into the process, using them to make heuristic choices or proffer explanations and guidance to the user. Modern LLMs can also do more than just rely on their training and the prompt: they can be given access to APIs that let them query and get up-to-date data.
I think AI will be most useful in cases where solving the problem requires external context not available within the program itself. Think back to my explanation of the 'static error, where knowing the right answer depended on how easy/hard it would be to change other APIs.
Where I think Rust should leverage AI
I’ve thought about a lot of places I think AI could help make working in Rust more pleasant. Here is a selection.
Deciding whether to change the function body or its signature
Consider this code:
fnget_first_name(&self,alias: &str)-> &str{alias}
This function will give a type error, because the signature (thanks to lifetime elision) promises to return a string borrowed from self but actually returns a string borrowed from alias. Now…what is the right fix? It’s very hard to tell in isolation! It may be that in fact the code was meant to be &self.name (in which case the current signature is correct). Or perhaps it was meant to be something that sometimes returns &self.name and sometimes returns alias, in which case the signature of the function was wrong. Today, we take our best guess. But AI could help us offer more nuanced guidance.
Translating idioms from one language to another
People often ask me questions like “how do I make a visitor in Rust?” The answer, of course, is “it depends on what you are trying to do”. Much of the time, a Java visitor is better implemented as a Rust enum and match statements, but there is a time and a place for something more like a visitor. Guiding folks through the decision tree for how to do non-trivial mappings is a great place for LLMs.
Figuring out the right type structure
When I start writing a Rust program, I start by authoring type declarations. As I do this, I tend to think ahead to how I expect the data to be accessed. Am I going to need to iterate over one data structure while writing to another? Will I want to move this data to another thread? The setup of my structures will depend on the answer to these questions.
I think a lot of the frustration beginners feel comes from not having a “feel” yet for the right way to structure their programs. The structure they would use in Java or some other language often won’t work in Rust.
I think an LLM-based assistant could help here by asking them some questions about the kinds of data they need and how it will be accessed. Based on this it could generate type definitions, or alter the definitions that exist.
Complex refactorings like splitting structs
A follow-on to the previous point is that, in Rust, when your data access patterns change as a result of refactorings, it often means you need to do more wholesale updates to your code.6 A common example for me is that I want to split out some of the fields of a struct into a substruct, so that they can be borrowed separately.7 This can be quite non-local and sometimes involves some heuristic choices, like “should I move this method to be defined on the new substruct or keep it where it is?”.
Migrating consumers over a breaking change
When you run the cargo fix command today it will automatically apply various code suggestions to cleanup your code. With the upcoming Rust 2024 edition, cargo fix---edition will do the same but for edition-related changes. All of the logic for these changes is hardcoded in the compiler and it can get a bit tricky.
For editions, we intentionally limit ourselves to local changes, so the coding for these migrations is usually not too bad, but there are some edge cases where it’d be really useful to have heuristics. For example, one of the changes we are making in Rust 2024 affects “temporary lifetimes”. It can affect when destructors run. This almost never matters (your vector will get freed a bit earlier or whatever) but it can matter quite a bit, if the destructor happens to be a lock guard or something with side effects. In practice when I as a human work with changes like this, I can usually tell at a glance whether something is likely to be a problem—but the heuristics I use to make that judgment are a combination of knowing the name of the types involved, knowing something about the way the program works, and perhaps skimming the destructor code itself. We could hand-code these heuristics, but an LLM could do it and better, and if could ask questions if it was feeling unsure.
Now imagine you are releasing the 2.x version of your library. Maybe your API has changed in significant ways. Maybe one API call has been broken into two, and the right one to use depends a bit on what you are trying to do. Well, an LLM can help here, just like it can help in translating idioms from Java to Rust.
I imagine the idea of having an LLM help you migrate makes some folks uncomfortable. I get that. There’s no reason it has to be mandatory—I expect we could always have a more limited, precise migration available.8
Optimize your Rust code to eliminate hot spots
Premature optimization is the root of all evil, or so Donald Knuth is said to have said. I’m not sure about all evil, but I have definitely seen people rathole on microoptimizing a piece of code before they know if it’s even expensive (or, for that matter, correct). This is doubly true in Rust, where cloning a small data structure (or reference counting it) can often make your life a lot simpler. Llogiq’s great talks on Easy Mode Rust make exactly this point. But here’s a question, suppose you’ve been taking this advice to heart, inserting clones and the like, and you find that your program is running kind of slow? How do you make it faster? Or, even worse, suppose that you are trying to turn our network service. You are looking at the blizzard of available metrics and trying to figure out what changes to make. What do you do? To get some idea of what is possible, check out Scalene, a Python profiler that is also able to offer suggestions as well (from Emery Berger’s group at UMass, the professor I talked about earlier).
Diagnose and explain miri and sanitizer errors
Let’s look a bit to the future. I want us to get to a place where the “minimum bar” for writing unsafe code is that you test that unsafe code with some kind of sanitizer that checks for both C and Rust UB—something like miri today, except one that works “at scale” for code that invokes FFI or does other arbitrary things. I expect a smaller set of people will go further, leveraging automated reasoning tools like Kani or Verus to prove statically that their unsafe code is correct9.
From my experience using miri today, I can tell you two things. (1) Every bit of unsafe code I write has some trivial bug or other. (2) If you enjoy puzzling out the occasionally inscrutable error messages you get from Rust, you’re gonna love miri! To be fair, miri has a much harder job—the (still experimental) rules that govern Rust aliasing are intended to be flexible enough to allow all the things people want to do that the borrow checker doesn’t permit. This means they are much more complex. It also means that explaining why you violated them (or may violate them) is that much more complicated.
Just as an AI can help novices understand the borrow checker, it can help advanced Rustaceans understand tree borrows (or whatever aliasing model we wind up adopting). And just as it can make smarter suggestions for whether to modify the function body or its signature, it can likely help you puzzle out a good fix.
Rust’s emphasis on “reliability” makes it a great target for AI
Anyone who has used an LLM-based tool has encountered hallucinations, where the AI just makes up APIs that “seem like they ought to exist”.10 And yet anyone who has used Rust knows that “if it compiles, it works” is true may more often than it has a right to be.11 This suggests to me that any attempt to use the Rust compiler to validate AI-generated code or solutions is going to also help ensure that the code is correct.
AI-based code assistants right now don’t really have this property. I’ve noticed that I kind of have to pick between “shallow but correct” or “deep but hallucinating”. A good example is match statements. I can use rust-analyzer to fill in the match arms and it will do a perfect job, but the body of each arm is todo!. Or I can let the LLM fill them in and it tends to cover most-but-not-all of the arms but it generates bodies. I would love to see us doing deeper integration, so that the tool is talking to the compiler to get perfect answers to questions like “what variants does this enum have” while leveraging the LLM for open-ended questions like “what is the body of this arm”.12
Conclusion
Overall AI reminds me a lot of the web around the year 2000. It’s clearly overhyped. It’s clearly being used for all kinds of things where it is not needed. And it’s clearly going to change everything.
If you want to see examples of what is possible, take a look at the ChatDBG videos published by Emery Berger’s group. You can see how the AI sends commands to the debugger to explore the program state before explaining the root cause. I love the video debugging bootstrap.py, as it shows the AI applying domain knowledge about statistics to debug and explain the problem.
My expectation is that compilers of the future will not contain nearly so much code geared around authoring diagnostics. They’ll present the basic error, sure, but for more detailed explanations they’ll turn to AI. It won’t be just a plain old foundation model, they’ll use RAG techniques and APIs to let the AI query the compiler state, digest what it finds, and explain it to users. Like a good human tutor, the AI will tailor its explanations to the user, leveraging the user’s past experience and intuitions (oh, and in the user’s chosen language).
I am aware that AI has some serious downsides. The most serious to me is its prodigous energy use, but there are also good questions to be asked about the way that training works and the possibility of not respecting licenses. The issues are real but avoiding AI is not the way to solve them. Just in the course of writing this post, DeepSeek was announced, demonstrating that there is a lot of potential to lower the costs of training. As far as the ethics and legality, that is a very complex space. Agents are already doing a lot to get better there, but note also that most of the applications I am excited about do not involve writing code so much as helping people understand and alter the code they’ve written.
We don’t always get this right. For example, I find the zip combinator of iterators annoying because it takes the shortest of the two iterators, which is occasionally nice but far more often hides bugs. ↩︎
The irony, of course, is that AI can help you to improve your woeful lack of tests by auto-generating them based on code coverage and current behavior. ↩︎
I think they told me they heard it somewhere on the internet? Not sure the original source. ↩︎
Personally, the thing I find most annoying about LLMs is the way they are trained to respond like groveling serveants. “Oh, that’s a good idea! Let me help you with that” or “I’m sorry, you’re right I did make a mistake, here is a version that is better”. Come on, I don’t need flattery. The idea is fine but I’m aware it’s not earth-shattering. Just help me already. ↩︎
Inserting a call to clone is actually a bit more subtle than you might think, given the interaction of the async future here. ↩︎
Garbage Collection allows you to make all kinds of refactorings in ownership structure without changing your interface at all. This is convenient, but—as we discussed early on—it can hide bugs. Overall I prefer having that information be explicit in the interface, but that comes with the downside that changes have to be refactored. ↩︎
I also think we should add a feature like View Types to make this less necessary. In this case instead of refactoring the type structure, AI could help by generating the correct type annotations, which might be non-obvious. ↩︎
My hot take here is that if the idea of an LLM doing migrations in your code makes you uncomfortable, you are likely (a) overestimating the quality of your code and (b) underinvesting in tests and QA infrastructure2. I tend to view an LLM like a “inconsistently talented contributor”, and I am perfectly happy having contributors hack away on projects I own. ↩︎
The student asks, “When unsafe code is proven free of UB, does that make it safe?” The master says, “Yes.” The student asks, “And is it then still unsafe?” The master says, “Yes.” Then, a minute later, “Well, sort of.” (We may need new vocabulary.) ↩︎
My personal favorite story of this is when I asked ChatGPT to generate me a list of “real words and their true definition along with 2 or 3 humorous fake definitions” for use in a birthday party game. I told it that “I know you like to hallucinate so please include links where I can verify the real definition”. It generated a great list of words along with plausible looking URLs for merriamwebster.com and so forth—but when I clicked the URLs, they turned out to all be 404s (the words, it turned out, were real—just not the URLs). ↩︎
This is not a unique property of Rust, it is shared by other languages with rich type systems, like Haskell or ML. Rust happens to be the most widespread such language. ↩︎
I’d also like it if the LLM could be a bit less interrupt-y sometimes. Especially when I’m writing type-system code or similar things, it can be distracting when it keeps trying to author stuff it clearly doesn’t understand. I expect this too will improve over time—and I’ve noticed that while, in the beginning, it tends to guess very wrong, over time it tends to guess better. I’m not sure what inputs and context are being fed by the LLM in the background but it’s evident that it can come to see patterns even for relatively subtle things. ↩︎
Is it just me or is it all about Europe right now? Put on some Kraftwerk and follow along I guess.
Fedora Chooses Forgejo! This is GitHub-like project hosting software with version control, issues, pull requests, all the usual stuff. I have a couple of small projects on Codeberg, which is the (EU) hosted nonprofit instance and it works fine as far as I can tell. Also a meissa GmbHpresentation at FOSDEM 2025You know X, Facebook, Xing, SourceForge? What about GitHub? It is time to de-risk OpenSource engagement!
Scott Locklin lists Examples of group madness in technology. One of the worst arguments I hear is that thing X is inevitable because the smart people are doing it. As I’ve extensively documented over the last 15 years on this blog, smart people in groups are not smart and are even more subject to crazes and mob behavior as everyone else.
Also international, not Europe-specific: Postgres full-text search is Good Enough! by Rachid Belaid. (But there is a tech autonomy angle, and an active PostgreSQL Europe, so for practical purposes PostgreSQL is part of the Eurostack.)
Good advice from tante/Jürgen Geuter: Innovation is a distractionThe demand for more Innovation (and sometimes even the request for more research) has become a way to legitimize not doing anything. A way to say the unpleasant solutions we have are not perfect but in the future there might be a magic solution that doesn’t bother us and everyone gets a fucking unicorn.
Marloes de Koning interviews Cristina Caffarra. ‘We have to get to work and put Europe first. But we are late. Terribly late’You really don’t have to buy everything in Europe, says the competition expert, who is familiar with the criticism that the American supply is simply superior. But start with 30 percent of your procurement budget in Europe. That already makes a huge difference. (That seems like an easy target. Not only are way more than 30 percent of the European Alternatives up to a servicable level by now, but unfortunately a lot of the legacy US vendors are having either quality or compliance problems, or both. The risks, technical and otherwise, keep going up.
Greg Nojeim and Silvia Lorenzo Perez cover Trump’s Sacking of PCLOB Members Threatens Data PrivacyAside from its importance in protecting civil liberties, the PCLOB cannot play its key role in enforcing U.S. obligations under the EU-U.S. Data Privacy Framework (DPF) while it lacks a quorum of members. The European Commission would lose a key oversight tool for which it bargained, and the adequacy decision that it issued to support the DPF could be struck down under review at the Court of Justice of the European Union (CJEU), which struck down two predecessor EU-U.S. data privacy arrangements, the Safe Harbor Agreement and the Privacy Shield.
Sarah Perez covers Report: Majority of US teens have lost trust in Big Tech. Common Sense says that 64% of surveyed U.S. teens don’t trust Big Tech companies to care about their mental health and well-being and 62% don’t think the companies will protect their safety if it hurts profits. Over half of surveyed U.S. teens (53%) also don’t think major tech companies make ethical and responsible design decisions (think: the growing use of dark patterns in user interface design meant to trick, confuse, and deceive. A further 52% don’t think that Big Tech will keep their personal information safe and 51% don’t think the companies are fair and inclusive when considering the needs of different users. (What if the Eurostack becomes the IT version of those European food brands that sell well in other countries too?)
UPDATE (March 4, 2025): The Release Channel is now default! See our update post on how to make the switch with a manual install and what’s new in 136.
We have an exciting announcement! Starting with the 136.0 release in March 2025, the Thunderbird Desktop Release channel will be the default download.
If you’re not already familiar with the Release channel, it will be a supported alternative to the ESR channel. It will provide monthly major releases instead of annual major releases. This provides several benefits to our users:
Frequent Feature Updates: New features will potentially be available each month, versus the annual Extended Support Release (ESR).
Smoother Transitions: Moving from one monthly release to the next will be less disruptive than updating between ESR versions.
Consistent Bug Fixes: Users will receive all available bug fixes, rather than relying on patch uplifts, as is the case with ESR.
We’ve been publishing monthly releases since 124.0. We added the Thunderbird Desktop Release Channel to the download page on Oct 1st, 2024.
The next step is to make the release channel an officially supported channel and the default download. We don’t expect this step alone to increase the population significantly. We’re exploring additional methods to encourage adoption in the future, such as in-app notifications to invite ESR users to switch.
One of our goals for 2025 is to increase daily active installations on the release channel to at least 20% of the total installations. At last check, we had 29,543 daily active installations on the release channel, compared to 20,918 on beta, and 5,941 on daily. The release channel installations currently account for 0.27% of the 10,784,551 total active installations tracked on stats.thunderbird.net.
To support this transition and ensure stability for monthly releases, we’re implementing several process improvements, including:
Pre-merge freezes: A 4-day soft code freeze of comm-central before merging into comm-beta. We continue to bake the week-long post-merge freeze of the release channel into the schedule.
Pre-merge reviews: We evaluate changes prior to both merges (central to beta and beta to release) where risky changes can be reverted.
New uplift template: A new and more thorough uplift template.
For more details on these release process details, please see the Release section of the developer docs.
Brussels came alive this weekend as Mozilla joined FOSDEM 2025, Europe’s premier open-source conference. FOSDEM wasn’t just another tech gathering. It is a representation of a vibrant community, open source innovation, and the spirit of collaboration. And we’re proud of being part of this amazing event since its inception.
This year, FOSDEM is celebrating its 25th anniversary. And unlike previous years’ gloomy weather, this year, we were blessed with surprising sunshine, almost as if the universe was applauding a quarter-century of open-source achievements.
As for Mozilla, our presence this year was extra special as we introduced our new brand. Over the weekend, we ran a bingo challenge in Mozilla’s and Thunderbird’s stands, where participants could play to win exclusive Mozilla t-shirts any many more special swag. It was a really fun way to introduce many projects from across pan-Mozilla.
We also showcased a sneak peek of Firefox Nightly’s new tab group feature in the Mozilla booth and gave away 2300 free cookies to participants on Saturday.
Here are some more highlights from our presence this year:
Highlights from Saturday
Mozilla engineering manager Marco Casteluccio presented a talk about the usage of LLM’s to support Firefox developers with code review in the main track.
Firefox engineer Valentin Gosu also presented a talk in the DNS track about his journey on using the getaddrinfo API in Firefox.
Another Firefox engineer who’s working on Firefox Profiler, Nazim Can Altinova also presented a talk in the Web Performance track. It’s also worth mentioning that the Web Performance devroom was co-run by some Mozillians.
Danny Colin, one of Mozilla’s active contributors, hosted a WebExtension BoF session featuring representatives from Mozilla Firefox (Rob Wu & Simeon Vincent) and Google Chrome’s extensions team (Oliver Dunk). This was the first time the team ran a Birds Of a Feather session, and it’s very likely that we’re going to do the same next year.
Danny Colin also hosted the Community Gathering where old and new contributors got together to discuss the future of Mozilla’s community. It was really nice to have an interactive session like this where all of us can share our perspective, so thank you to all of you who attended the session!
Highlights from Sunday
Mitchell Baker kicked off Sunday with a keynote session that offered a thought-provoking exploration of Free/Libre Open Source Software (FLOSS) in the age of artificial intelligence and demonstrated how Mozilla plays a role in defining principled approach to AI that prioritizes transparency, ethics, and community-driven innovation. It was a perfect opening for the talks that we presented at the Mozilla devroom later that day.
Around the same time as Mitchell’s session, Mozilla engineer Max Inden also delivered a presentation in the Network devroom, showcasing various techniques the Firefox team uses to enhance Firefox performance.
Then on the second half on Sunday, we also hosted the Mozilla devroom where we covered a wide range of Mozilla’s latest innovations from Mythbusting to Mozilla’s AI innovations and Firefox developments. Recordings will be available soon at FOSDEM’s website and via our YouTube channel. So stay tuned!
We’re grateful for the enthusiasm, conversations, and curiosity of attendees at FOSDEM 2025. And big thanks to our amazing volunteers and Mozillians for co-hosting our booth and the Mozilla devroom this year.
We sure had a blast, and we can’t wait to see you again next year!
Back in July 2024, we published a blog post about the ongoing development of crates.io. Since then, we have made a lot of progress and shipped a few new features. In this blog post, we want to give you an update on the latest changes that we have made to crates.io.
Crate deletions
In RFC #3660 we proposed a new feature that allows crate owners to delete their crates from crates.io under certain conditions. This can be useful if you have published a crate by mistake or if you want to remove a crate that is no longer maintained. After the RFC was accepted by all team members at the end of August, we began implementing the feature.
We created a new API endpoint DELETE /api/v1/crates/:name that allows crate owners to delete their crates and then created the corresponding user interface. If you are the owner of a crate, you can now go to the crate page, open the "Settings" tab, and find the "Delete this crate" button at the bottom. Clicking this button will lead you to a confirmation page telling you about the potential impact of the deletion and requirements that need to be met in order to delete the crate:
As you can see from the screenshot above, a crate can only be deleted if either: the crate has been published for less than 72 hours or the crate only has a single owner, and the crate has been downloaded less than 500 times for each month it has been published, and the crate is not depended upon by any other crate on crates.io.
These requirements were put in place to prevent abuse of the deletion feature and to ensure that crates that are widely used by the community are not deleted accidentally. If you have any feedback on this feature, please let us know!
OpenAPI description
Around the holiday season we started experimenting with generating an OpenAPI description for the crates.io API. This was a long-standing request from the community, and we are happy to announce that we now have an experimental OpenAPI description available at https://crates.io/api/openapi.json!
Please note that this is still considered work-in-progress and e.g. the stability guarantees for the endpoints are not written down and the response schemas are also not fully documented yet.
You can view the OpenAPI description in e.g. a Swagger UI at https://petstore.swagger.io/ by putting https://crates.io/api/openapi.json in the top input field. We decided to not ship a viewer ourselves for now due to security concerns with running it on the same domain as crates.io itself. We may reconsider whether to offer it on a dedicated subdomain in the future if there is enough interest.
The OpenAPI description is generated by the utoipa crate, which is a tool that can be integrated with the axum web framework to automatically generate OpenAPI descriptions for all of your endpoints. We would like to thank Juha Kukkonen for his great work on this tool!
Support form and "Report Crate" button
Since the crates.io team is small and mostly consists of volunteers, we do not have the capacity to manually monitor all publishes. Instead, we rely on you, the Rust community, to help us catch malicious crates and users. To make it easier for you to report suspicious crates, we added a "Report Crate" button to all the crate pages. If you come across a crate that you think is malicious or violates the code of conduct or our usage policy, you can now click the "Report Crate" button and fill out the form that appears. This will send an email to the crates.io team, who will then review the crate and take appropriate action if necessary. Thank you to crates.io team member @eth3lbert who worked on the majority of this.
If you have any issues with the support form or the "Report Crate" button, please let us know. You can also always email us directly at help@crates.io if you prefer not to use the form.
Publish notifications
We have added a new feature that allows you to receive email notifications when a new version of your crate is published. This can be useful in detecting unauthorized publishes of your crate or simply to keep track of publishes from other members of your team.
This feature was another long-standing feature request from our community, and we were happy to finally implement it. If you'd prefer not to receive publish notifications, then you can go to your account settings on crates.io and disable these notifications.
Miscellaneous
These were some of the more visible changes to crates.io over the past couple of months, but a lot has happened "under the hood" as well.
RFC #3691 was opened and accepted to implement "Trusted Publishing" support on crates.io, similar to other ecosystems that adopted it. This will allow you to specify on crates.io which repository/system is allowed to publish new releases of your crate, allowing you to publish crates from CI systems without having to deal with API tokens anymore.
Slightly related to the above: API tokens created on crates.io now expire after 90 days by default. It is still possible to disable the expiry or choose other expiry durations though.
The crates.io team was one of the first projects to use the diesel database access library, but since that only supported synchronous execution it was sometimes a little awkward to use in our codebase, which was increasingly moving into an async direction after our migration to axum a while ago. The maintainer of diesel, Georg Semmler, did a lot of work to make it possible to use diesel in an async way, resulting in the diesel-async library. Over the past couple of months we incrementally ported crates.io over to diesel-async queries, which now allows us to take advantage of the internal query pipelining in diesel-async that resulted in some of our API endpoints getting a 10-15% performance boost. Thank you, Georg, for your work on these crates!
Whenever you publish a new version or yank/unyank existing versions a couple of things need to be updated. Our internal database is immediately updated, and then we synchronize the sparse and git index in background worker jobs. Previously, yanking and unyanking a high number of versions would each queue up another synchronization background job. We have now implemented automatic deduplication of redundant background jobs, making our background worker a bit more efficient.
The final big, internal change that was just merged last week is related to the testing of our frontend code. In the past we used a tool called Mirage to implement a mock version of our API, which allowed us to run our frontend test suite without having to spin up a full backend server. Unfortunately, the maintenance situation around Mirage had lately forced us to look into alternatives, and we are happy to report that we have now fully migrated to the "Industry standard API mocking" package msw. If you want to know more, you can find the details in the "small" migration pull request.
Feedback
We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!
WebDriver is a remote control interface that enables introspection and control of user agents.As such itcanhelp 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 135 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 135, several contributors managed to land fixes and improvements in our codebase:
To make user events more realistic and better simulate real user interactions in the browser, we have moved the action sequence processing of the Perform Actions commands in both Marionette and WebDriver BiDi from the content process to the parent process. While events are still sent synchronously from the content process, they are now triggered asynchronously via IPC calls originating from the parent process.
Due to this significant change, you might experience some regressions. If you encounter any issues, please file a bug for the Remote Agent. If the regressions block test execution, you can temporarily revert to the previous behavior by setting the Firefox preference remote.events.async.enabled to false.
With the processing of actions now handled in the parent process the following issues were fixed as well:
When dispatching actions, the input cancel list is now correctly updated only after the action has been successfully dispatched. Previously, if an action failed to execute, a reverse action could be left in place, leading to unexpected side effects when resetting the state of the input source.
New: format argument for browsingContext.captureScreenshot
Thanks to Liam’s work, the browsingContext.captureScreenshot command now supports the format argument. It allows clients to specify different file formats ("image/png" and "image/jpeg" are currently supported) and define the compression quality for screenshots.
The argument should follow the browsingContext.ImageFormat type, with a "type" property which is expected to be a string, and an optional "quality" property which can be a float between 0 and 1.
In December 2024, in the lead up to the AI Action Summit, Mozilla, Fondation Abeona, École Normale Supérieure (ENS) and the Columbia Institute of Global Politics gathered at ENS in Paris, bringing together a diverse group of AI experts, academics, civil society, regulators and business leaders to discuss a topic increasingly central to the future of AI: what does openness mean and how it can enable trustworthy, innovative, and equitable outcomes?
The workshop followed the Columbia Convenings on Openness and AI, that Mozilla held in partnership with Columbia University’s Institute of Global Politics. These gatherings, held over the course of 2024 in New York and San Francisco, have brought together over 40 experts to address what “openness” should mean in the AI era.
Over the past two years, Mozilla has mounted a significant effort to promote and defend the role of openness in AI. Mozilla launched Mozilla.ai, an initiative focused on ethical, open-source AI tools, and supported small-scale, localized AI projects through its Builders accelerator program. Beyond technical investments, Mozilla has also been a vocal advocate for openness in AI policy, urging governments to adopt regulatory frameworks that foster competition and accountability while addressing risks. Through these initiatives, Mozilla is shaping a future where AI development aligns with public interest values.
This Paris Openness workshop discussion — part of the official ‘Road to the Paris AI Summit’ taking place in February 2025 — looked to bring together the European AI community and form actionable recommendations for policymakers. While it embraced healthy debate and disagreement around issues such as definitions of openness in AI, there was nevertheless broad agreement on the urgency of crafting collective ideas to advance openness while navigating an increasingly complex commercial, political and regulatory landscape.
The stakes could not be higher. As AI continues to shape our societies, economies, and governance systems, openness emerges as both an opportunity and a challenge. On one hand, open approaches can expand access to AI tools, foster innovation, and enhance transparency and accountability. On the other hand, they raise complex questions about safety and misuse. In Europe, these questions intersect with transformative regulatory frameworks like the EU AI Act, which seeks to ensure that AI systems are both safe and aligned with fundamental rights.
As in software development, the goal of being ‘open’ in AI is a crucial one. At its heart, openness, we were reminded in the discussion, is a holistic outlook. For AI in particular it is a pathway to getting to a more pluralistic tool – one that can be more transparent, contextual, participatory and culturally appropriate. Each of these goals however contain natural tensions within them.
A central question of this most recent dialogue challenged participants on the best ways to build with safety in mind while also embracing openness. The day was broken down into two workshops that examined these questions from a technical and policy standpoint.
Running through both of the workshops was the thread of a persistent challenge: the multifaceted nature of the term openness. In the policy context, the term “open-source” can be too narrow, and at times, it risks being seen as an ideological stance rather than a pragmatic tool for addressing specific issues. To address this, many participants felt openness should be framed as a set of components — including open models, data, and tools — each of which has specific benefits and risks.
Examining Technical Perspectives on Openness and Safety
A significant concern for many in the open-source community is getting access to the best existing safety tools. Despite the increasing importance of AI safety, many researchers can find it difficult or expensive to access tools to help identify and address AI risks. In particular the discussion surfaced an increasing tension between some researchers and startups who have found it difficult to access datasets of known CSAM (Child Sexual Abuse Material) hashtags. Accessing these data sets could help mitigate misuse or clean training datasets. The workshop called for broader sharing of safety tools and more support for those working at the cutting edge of AI development.
More widely, some participants were frustrated by perceptions that open source AI development is not bothered by questions of safety. They pointed out that, especially when it comes to regulation, focusing on questions of safety makes them even more competitive.
Discussing Policy Implications of Openness in AI
Policy discussions during the workshop focused on the economic, societal, and regulatory dimensions of openness in AI. These ranged over several themes, including:
Challenging perceptions of openness: There is a clear need to change the narrative around openness, especially in policymaking circles. The open-source community must both act as a community and present itself as knowledgeable and solution-oriented, demonstrating how openness can be a means to advancing the public interest — not an abstract ideal. As one participant pointed out, openness should be viewed as a tool for societal benefit, not as an end in itself.
Tensions between regulation and innovation are misleading: As one of the first regulatory frameworks on AI to be drafted, many people view the EU’s AI Act as a test bed to get to smarter AI regulation. While there is a widespread characterisation of regulation obstructing innovation, some participants highlighted that this can be misleading — many new entrants seek out jurisdictions with favourable regulatory and competition policies that level the playing field.
A changing U.S. Perspective: In the United States, the open-source AI agenda has gained significant traction, particularly in the wake of incidents like the Llama leaks, which showed that many of the feared risks associated with openness did not materialize. Significantly, the U.S. National Telecommunications and Information Administration emphasized the benefits of open source AI technology and introduced a nuanced view of safety concerns around open-weight AI models.
Many participants also agreed that policymakers, many of whom are not deeply immersed in the technicalities of AI, need a clearer framework for understanding the value of openness. Considering the focus of the upcoming Paris AI Summit, some participants felt one solution could lie in focusing on public interest AI. This conceptresonates more directly with broader societal goals while still acknowledging the risks and challenges that openness brings.
Recommendations
Embracing openness in AI is non-negotiable if we are to build trust and safety; it fosters transparency, accountability, and inclusive collaboration. Openness must extend beyond software to broader access to the full AI stack, including data and infrastructure, with a governance that safeguards public interest and prevents monopolization.
It is clear that the open source community must make its voice louder. If AI is to advance competition, innovation, language, research, culture and creativity for the global majority of people, then an evidence-based approach to the benefits of openness, particularly when it comes to proven economic benefits, is essential for driving this agenda forward.
Several recommendations for policymakers also emerged.
Diversify AI Development: Policymakers should seek to diversify the AI ecosystem, ensuring that it is not dominated by a few large corporations in order to foster more equitable access to AI technologies and reduce monopolistic control. This should be approached holistically, looking at everything from procurement to compute strategies.
Support Infrastructure and Data Accessibility: There is an urgent need to invest in AI infrastructure, including access to data and compute power, in a way that does not exacerbate existing inequalities. Policymakers should prioritize distribution of resources to ensure that smaller actors, especially those outside major tech hubs, are not locked out of AI development.
Understand openness as central to achieving AI that serves the public interest. One of the official tracks of the upcoming Paris AI Action Summit is Public Interest AI. Increasingly, openness should be deployed as a main route to truly publicly interested AI.
Openness should be an explicit EU policy goal: As one of the furthest along in AI regulatory frameworks the EU will continue to be a testbed for many of the big questions in AI policy. The EU should adopt an explicit focus on promoting openness in AI as a policy goal.
We will be raising all the issues discussed while at the AI Action Summit in Paris. The organizers hope to host another set of these discussions following the conclusion of the Summit in order to continue working with the community and to better inform governments and other stakeholders around the world.
The list of participants at the Paris Openness Workshop is below:
Linda Griffin – VP of Global Policy, Mozilla
Udbhav Tiwari – Director, Global Product Policy, Mozilla
Camille François – Researcher, Columbia University
Tanya Perelmuter – Co-founder and Director of Strategy,, Fondation Abeona
Yann Lechelle – CEO, Probabl
Yann Guthmann – Head of Digital Economy, Department at the French Competition Authority
Adrien Basdevant – Tech lawyer, Entropy Law
Andrzej Neugebauer – AI Program Director, LINAGORA
Thierry Poibeau – Director of Research, CNRS, ENS
Nik Marda – Technical Lead for AI Governance, Mozilla
Andrew Strait – Associate Director, Ada Lovelace Institute (UK)
Paul Keller – Director of Policy, Open Future (Netherlands)
Guillermo Hernandez – AI Policy Analyst, OECD
Sandrine Elmi Hersi – Unit Chief of “Open Internet”, ARCEP
Two weeks ago I published an article on 63 malicious Chrome extensions. In most cases I could only identify the extensions as malicious. With large parts of their logic being downloaded from some web servers, it wasn’t possible to analyze their functionality in detail.
However, for the Download Manager Integration Checklist extension I have all parts of the puzzle now. This article is a technical discussion of its functionality that somebody tried very hard to hide. I was also able to identify a number of related extensions that were missing from my previous article.
Update (2025-02-04): An update to Download Manager Integration Checklist extension has been released a day before I published this article, clearly prompted by me asking adindex about this. The update removes the malicious functionality and clears extension storage. Luckily, I’ve saved both the previous version and its storage contents.
Contents
The problematic extensions
Since my previous article I found a bunch more extensions with malicious functionality that is almost identical to Download Manager Integration Checklist. The extension Auto Resolution Quality for YouTube™ does not seem to be malicious (yet?) but shares many remarkable oddities with the other extensions.
Name
Weekly active users
Extension ID
Featured
Freemybrowser
10,000
bibmocmlcdhadgblaekimealfcnafgfn
✓
AutoHD for Twitch™
195
didbenpmfaidkhohcliedfmgbepkakam
Free simple Adult Blocker with password
1,000
fgfoepffhjiinifbddlalpiamnfkdnim
Convert PDF to JPEG/PNG
20,000
fkbmahbmakfabmbbjepgldgodbphahgc
Download Manager Integration Checklist
70,000
ghkcpcihdonjljjddkmjccibagkjohpi
✓
Auto Resolution Quality for YouTube™
223
hdangknebhddccoocjodjkbgbbedeaam
Adblock.mx - Adblock for Chrome
1,000
hmaeodbfmgikoddffcfoedogkkiifhfe
✓
Auto Quality for YouTube™
100,000
iaddfgegjgjelgkanamleadckkpnjpjc
Anti phising safer browsing for chrome
7,000
jkokgpghakemlglpcdajghjjgliaamgc
✓
Darktheme for google translate
40,000
nmcamjpjiefpjagnjmkedchjkmedadhc
✓
Additional IOCs:
adblock[.]mx
adultblocker[.]org
autohd[.]org
autoresolutionquality[.]com
browserguard[.]net
freemybrowser[.]com
freepdfconversion[.]com
internetdownloadmanager[.]top
megaxt[.]com
darkmode[.]site
“Remote configuration” functionality
The Download Manager Integration Checklist extension was an odd one on the list in my previous article. It has very minimal functionality: it’s merely supposed to display a set of instructions. This is a task that doesn’t require any permissions at all, yet the extension requests access to all websites and declarativeNetRequest permission. Apparently, nobody noticed this inconsistency so far.
Looking at the extension code, there is another oddity. The checklist displayed by the extension is downloaded from Firebase, Google’s online database. Yet there is also a download from https://help.internetdownloadmanager.top/checklist, with the response being handled by this function:
This is what I flagged as malicious functionality initially: part of the response is used to add declarativeNetRequest rules dynamically. At first I missed something however: the rest of the data being stored as checklist is also part of the malicious functionality, allowing execution of remote code:
There is a tabs.onUpdated listener hidden within the legitimate webextension-polyfill module that will run this function for every web page via tabs.executeScript API.
This function looks fairly unsuspicious. Understanding its functionality is easier if you know that checklist.core is "onreset". So it takes the document element, fills its onreset attribute with some JavaScript code from checklist.info, triggers the reset event and removes the attribute again. That’s how this extension runs some server-provided code in the context of every website.
The code being executed
When the extension downloads its “checklist” immediately after installation the server response will be empty. Sort of: “nothing to see here, this is merely some dead code somebody forgot to remove.” The server sets a cookie however, allowing it to recognize the user on subsequent downloads. And only after two weeks or so it will respond with the real thing. For example, the list key of the response looks like this then:
No surprise here, this is about removing Content Security Policy protection from all websites, making sure it doesn’t interfere when the extension injects its code into web pages.
As I already mentioned, the core key of the response is "onreset", an essential component towards executing the JavaScript code. And the JavaScript code in the info key is heavily obfuscated by JavaScript Obfuscator, with most strings and property names encrypted to make reverse engineering harder.
Of course this kind of obfuscation can still be reversed, and you can see the entire deobfuscated code here. Note that most function and variable names have been chosen randomly, the original names being meaningless. The code consists of three parts:
Marshalling of various extension APIs: tabs, storage, declarativeNetRequest. This uses DOM events to communicate with the function f() mentioned above, this function forwards the messages to the extension’s background worker and the worker then calls the respective APIs.
In principle, this allows reading out your entire browser state: how many tabs, what pages are loaded etc. Getting notified on changes is possible as well. The code doesn’t currently use this functionality, but the server can of course produce a different version of it any time, for all users or only for selected targets.
There is also another aspect here: in order to run remote code, this code has been moved into the website realm. This means however that any website can abuse these APIs as well. It’s only a matter of knowing which DOM events to send. Yes, this is a massive security issue.
Code downloading a 256 KiB binary blob from https://st.internetdownloadmanager.top/bff and storing it in encoded form as bff key in the extension storage. No, this isn’t your best friend forever but a Bloom filter. This filter is applied to SHA-256 hashes of domain names and determines on which domain names the main functionality should be activated.
With Bloom filters, it is impossible to determine which exact data went into it. It is possible however to try out guesses, to see which one it accepts. Here is the list of matching domains that I could find. This list looked random to me initially, and I even suspected that noise has been added to it in order to hide the real target domains. Later however I could identify it as the list of adindex advertisers, see below.
The main functionality: when active, it sends the full address of the current page to https://st.internetdownloadmanager.top/cwc2 and might get a “session” identifier back. It is likely that this this server stores the addresses it receives and sells the resulting browsing history. This part of the functionality stays hidden however.
The “session” handling is visible on the other hand. There is some rate limiting here, making sure that this functionality is triggered at most once per minute and no more than once every 12 hours for each domain. If activated, a message is sent back to the extension’s background worker telling it to connect to wss://pa.internetdownloadmanager.top/s/<session>. All further processing happens there.
The “session” handling
Here we are back in the extension’s static code, no longer remotely downloaded code. The entry point for the “session” handling is function __create. Its purpose has been concealed, with some essential property and method names contained in the obfuscated code above or received from the web socket connection. I filled in these parts and simplified the code to make it easier to understand:
This receives instructions from the web socket connection on what requests to make. Upon success the extension sends information like response text, HTTP headers and HTTP status back to the server.
What is this good for? Before I could observe this code in action I was left guessing. Is this an elaborate approach to de-anonymize users? On some websites their name will be right there in the server response. Or is this about session hijacking? There would be session cookies in the headers and CSRF tokens in the response body, so the extension could be instrumented to perform whatever actions necessary on behalf of the attackers – like initiating a money transfer once the user logs into their PayPay account.
The reality turned out to be far more mundane. When I finally managed to trigger this functionality on the Ashley Madison website, I saw the extension perform lots of web requests. Apparently, it was replaying a browsing session that was recorded two days earlier with the Firefox browser. The entry point of this session: https://api.sslcertifications.org/v1/redirect?advertiserId=11EE385A29E861E389DA14DDA9D518B0&adspaceId=11EE4BCA2BF782C589DA14DDA9D518B0&customId=505 (redirecting to ashleymadison.com).
The server handling api.sslcertifications.org belongs to the German advertising company adindex. Their list of advertisers is mostly identical to the list of domains matched by the Bloom filter the extension uses. So this is ad fraud: the extension generates fake link clicks, making sure its owner earns money for “advertising” websites like Ashley Madison. It uses the user’s IP address and replays recorded sessions to make this look like legitimate traffic, hoping to avoid detection this way.
I contacted adindex and they confirmed that sslcertifications.org is a domain registered by a specific publisher but handled by adindex. They also said that they confronted the publisher in question with my findings and, having found their response unsatisfactory, blocked this publisher. Shortly afterwards the internetdownloadmanager.top domain became unreachable, and api.sslcertifications.org site no longer has a valid SSL certificate. Domains related to other extensions, the ones I didn’t mention in my request, are still accessible.
Who is behind these extensions?
The adindex CEO declined to provide the identity of the problematic publisher. There are obvious data protection reasons for that. However, as I looked further I realized that he might have additional reasons to withhold this information.
While most extensions I list provide clearly fake names and addresses, the Auto Quality for YouTube™ extension is associated with the MegaXT website. That website doesn’t merely feature a portfolio of two browser extensions (the second one being an older Manifest V2 extension also geared towards running remote code) but also a real owner with a real name. Who just happens to be a developer at adindex.
There is also the company eokoko GmbH, developing Auto Resolution Quality for YouTube™ extension. This extension appears to be non-malicious at the moment, yet it shares a number of traits with the malicious extensions on my list. Director of this company is once again the same adindex developer.
And not just any developer. According to his website he used to be CTO at adindex in 2013 (I couldn’t find an independent confirmation for this). He also founded a company together with the adindex CEO in 2018, something that is confirmed by public records.
When I mentioned this connection in my communication with adindex CEO the response was:
[He] works for us as a freelancer in development. Employees (including freelancers) are generally not allowed to operate publisher accounts at adindex and the account in question does not belong to [this developer]. Whether he operates extensions is actually beyond my knowledge.
I want to conclude this article with some assorted history facts:
The two extensions associated with MegaXT have been running remote code since at least 2021. I don’t know whether they were outright malicious from the start, this would be impossible to prove retroactively even with source code given that they simply loaded some JavaScript code into the extension context. But both extensions have reviews complaining about malicious functionality going back to 2022.
Darktheme for google translate and Download Manager Integration Checklist extensions both appear to have changed hands in 2024, after which they requested more privileges with an update in October 2024.
Download Manager Integration Checklist extension used to be called “IDM Integration Module” in 2022. There have been at least five more extensions with similar names (not counting the official one), all removed from Chrome Web Store due to “policy violation.” This particular extension was associated with a website which is still offering “cracks” that show up as malware on antivirus scans (the installation instructions “solve” this by recommending to turn off antivirus protection). But that’s most likely the previous extension owner.
Convert PDF to JPEG/PNG appears to have gone through a hidden ownership change in 2024, after which an update in September 2024 requested vastly extended privileges. However, the extension has reviews complaining about spammy behavior going back to 2019.
Welcome to the latest edition of the Performance Testing Newsletter! The PerfTools team empowers engineers with tools to continuously improve the performance of Mozilla products. See below for highlights from the changes made in the last quarter.
This quarter also saw the release of perf.compare! It’s a new tool used for making comparisons between try runs (or other pushes). It is now the default comparison tool used for these comparisons and replaces the Compare View that was in use previously. Congratulations to all the folks involved in making this release happen! Feel free to reach out in #perfcompare on Matrix if there are any questions, feature requests, etc.. Bugs can be filed in Testing :: PerfCompare.
If you have any questions, or are looking to add performance testing for your code component, you can find us in #perftest on Element, or #perf-help on Slack.
Two years after the renewed activity on the project we can confirm that Servo is fully back.
If we ignore the bots, in 2024 we’ve had 129 unique contributors (+143% over 54 last year), landing 1,771 pull requests (+163% over 673), and that’s just in our main repo!
Including bots, the total number of PRs merged goes up to 2,674 (+144% over 1094). From all this work, 26% of the PRs were made by Igalia, 40% by other contributors and the rest by the bots (34%). This shows how the Servo community has been growing and becoming more diverse with new actors participating actively in the project.
2018
2019
2020
2021
2022
2023
2024
Merged PRs
1,188
986
669
118
65
776
1,771
Unique contributors
142
141
87
37
20
54
129
Average unique contributors per month
27.33
27.17
14.75
4.92
2.83
11.33
26.33
Now let’s take a look to the data and chart above, which show the evolution since 2018 in number of merged PRs, unique contributors per year and average contributors per month (excluding bots). We can see the project is back to numbers of 2018 and 2019 when it was been developed in full speed!
It’s worth noting that Servo popularity keeps growing, with many folks realizing there has been new activity on the project last year, and we have more and more people interested in the project.
<figcaption>Servo GitHub stars haven't stopped growing, surpassing now 25K threshold.</figcaption>
If we focus on development there has been many things moving forward during the year. Servo main dependencies (SpiderMonkey, Stylo and WebRender) have been upgraded, the new layout engine has kept evolving adding support for floats, tables, flexbox, fonts, etc. By the end of 2024 Servo passes 1,515,229 WPT subtests (79%). Many other new features have been under active development: WebGPU, Shadow DOM, ReadableStream, WebXR, … Servo now supports two new platforms: Android and OpenHarmony. And we have got the first experiments of applications using Servo as a web engine (like Tauri, Blitz, QtWebView, Cuervo, Verso and Moto).
With this money we have now 3 servers that provides self-hosted runners for Linux, macOS, and Windows reducing our build times from over an hour to under 30 minutes.
Talking about the future, the Servo TSC has been discussing the roadmap for 2025 which has been updated on the Servo’s wiki. We have many plans to keep Servo thriving with new features and improvements. Let’s hope for a great 2025!
The Thunderbird Mobile team are crafting the newest chapter of the Thunderbird story. In this month’s office hours, we sat down to chat with the entire mobile team! This includes Philipp Kewisch, Sr. Manager of Mobile Engineering (and long-time Thunderbird contributor), and Sr. Software Engineers cketti and Wolf Montwé (long-time K-9 Mail maintainer and developer, respectively). We talk about the journey from K-9 Mail to Thunderbird for Android, what’s new and what’s coming in the near future, and the first steps towards Thunderbird on your iOS devices!
Next month, we’ll be chatting with Laurel Terlesky, Manager of the UI/UX Design Studio! She’ll be sharing her FOSDEM talk, “Thunderbird: Building a Cross-Platform, Scalable Open-Source Design System.” It’s been a while since we’ve chatted with the design team, and it will be great to see what they’re working on.
January Office Hours: The Thunderbird Mobile Team
In June 2022, we announced that K-9 Mail would be joining the Thunderbird family, and would ultimately become Thunderbird for Android. After two years of development, the first beta release of Thunderbird for Android debuted in October 2024, shortly followed by the first stable release. Since then, over 200 thousand users have downloaded the app, and we’ve gotten some very nice reviews in ZDNet and Android Authority. If you haven’t tried us on your Android device yet, now is a great time! And if, like some of us, you’re waiting for Thunderbird to come to your iPhone or iPad, we have some exciting news at the end of our talk.
Want to know more about the Android development process and find out what’s coming soon to the app? Want the first look into our plans for Thunderbird on iOS? Let our mobile team guests provide the answers!
Watch, Read, and Get Involved
We’re so grateful to Philipp, cketti, and Wolf for joining us! We hope this video helps explain more about Thunderbird on Android (and eventually iOS), and encourages you to download the app if you haven’t already. If you’re a regular user, we hope you consider contributing code, translations, or support. And if you’re an iOS developer, we hope you consider joining our team!
The Rust team has published a new point release of Rust, 1.84.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.84.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.84.1
1.84.1 resolves a few regressions introduced in 1.84.0:
This post lays out the idea of preview crates.1 Preview crates would be special crates released by the rust-lang org. Like the standard library, preview crates would have access to compiler internals but would still be usable from stable Rust. They would be used in cases where we know we want to give users the ability to do X but we don’t yet know precisely how we want to expose it in the language or stdlib. In git terms, preview crates would let us stabilize the plumbing while retaining the ability to iterate on the final shape of the porcelain.
Nightly is not enough
Developing large language features is a tricky business. Because everything builds on the language, stability is very important, but at the same time, there are some questions that are very hard to answer without experience. Our main tool for getting this experience has been the nightly toolchain, which lets us develop, iterate, and test features before committing to them.
Because the nightly toolchain comes with no guarantees at all, however, most users who experiment with it do so lightly, just using it for toy projects and the like. For some features, this is perfectly fine, particularly syntactic features like let-else, where you can learn everything you need to know about how it feels from a single crate.
Nightly doesn’t let you build a fledgling ecosystem
Where nightly really fails us though is the ability to estimate the impact of a feature on a larger ecosystem. Sometimes you would like to expose a capability and see what people build with it. How do they use it? What patterns emerge? Often, we can predict those patterns in advance, but sometimes there are surprises, and we find that what we thought would be the default mode of operation is actually kind of a niche case.
For these cases, it would be cool if there were a way to issue a feature in “preview” mode, where people can build on it, but it is not yet released in its final form. The challenge is that if we want people to use this to build up an ecosystem, we don’t want to disturb all those crates when we iterate on the feature. We want a way to make changes that lets those crates keep working until the maintainers have time to port to the latest syntax, naming, or whatever.
Editions are closer, but not quite right
The other tool we have for correct mistakes is editions. Editions let us change what syntax means and, because they are opt-in, all existing code continues to work.
Editions let us fix a great many things to make Rust more self-consistent, but they carry a heavy cost. They force people to relearn how things in Rust work. The make books oudated. This price is typically too high for us to ship a feature knowing that we are going to change it in a future edition.
Let’s give an example
To make this concrete, let’s take a specific example. The const generics team has been hard at work iterating on the meaning of const trait and in fact there is a pending RFC that describes their work. There’s just one problem: it’s not yet clear how it should be exposed to users. I won’t go into the rationale for each choice, but suffice to say that there are a number of options under current consideration. All of these examples have been proposed, for example, as the way to say “a function that can be executed at compilation time which will call T::default”:
const fn compute_value<T: ~const Default>()
const fn compute_value<T: const Default>()
const fn compute_value<T: Default>()
At the moment, I personally have a preference between these (I’ll let you guess), but I figure I have about… hmm… 80-90% confidence in that choice. And what’s worse, to really decide between them, I think we have to see how the work on async proceeds, and perhaps also what kinds of patterns turn out to be common in practice for const fn. This stuff is difficult to gauge accurately in advance.
Enter preview crates
So what if we released a crate rust_lang::const_preview. In my dream world, this is released on crates.io, using the namespaces described in [RFC #3243][https://rust-lang.github.io/rfcs/3243-packages-as-optional-namespaces.html]. Like any crate, const_preview can be versioned. It would expose exactly one item, a macro const_item that can be used to write const functions that have const trait bounds:
const_preview::const_item!{constfncompute_value<T: ~constDefault>(){// as `~const` is what is implemented today, I'll use it in this example
}}
Interally, this const_item! macro can make use of internal APIs in the compiler to parse the contents and deploy the special semantics.
Releasing v2.0
Now, maybe we use this for a while, and we find that people really don’t like the ~, so we decide to change the syntax. Perhaps we opt to write const Default instead of ~const Default. No problem, we release a 2.0 version of the crate and we also rewrite 1.0 to take in the tokens and invoke 2.0 using the semver trick.
const_preview::const_item!{constfncompute_value<T: constDefault>(){// as `~const` is what is implemented today, I'll use it in this example
}}
Integrating into the language
Once we decide we are happy with const_item! we can merge it into the language proper. The preview crates are deprecated and simply desugar to the true language syntax. We all go home, drink non-fat flat whites, and pat ourselves on the back.
User-based experimentation
One thing I like about the preview crates is that then others can begin to do their own experiments. Perhaps somebody wants to try out what it would be like it T: Default meant const by default–they can readily write a wrapper that desugars to const_preview::const_item and try it out. And people can build on it. And all that code keeps working once we integrate const functions into the language “for real”, it just looks kinda dated.
Frequently asked questions
Why else might we use previews?
Even if we know the semantics, we could use previews to stabilize features where the user experience is not great. I’m thinking of Generic Associated Types as one example, where the stabilization was slowed because of usability concerns.
What are the risks from this?
The previous answers hints at one of my fears… if preview crates become a widespread way for us to stabilize features with usability gaps, we may accumulate a very large number of them and then never move those features into Rust proper. That seems bad.
Shouldn’t we just make a decision already?
I mean…maybe? I do think we are sometimes very cautious. I would like us to get better at leaning on our judgment. But I also seem that sometimes there is a tension between “getting something out the door” and “taking the time to evaluate a generalization”, and it’s not clear to me that this tension is an inherent complexity or an artificial artifact of the way we do business.
But would this actually work? What’s in that crate and what if it is not matched with the right version of the compiler?
One very special thing about libstd is that it is released together with the compiler and hence it is able to co-evolve, making use of internal APIs that are unstable and change from release to release. If we want to put this crate on crates.io, it will not be able to co-evolve in the same way. Bah. That’s annoying! But I figure we still handle it by actually having the preview functionality exposed by crates in sysroot that are shipping along the compiler. These crates would not be directly usable except by our blessed crates.io crates, but they would basically just be shims that expose the underlying stuff. We could of course cut out the middleman and just have people use those preview crates directly– but I don’t like that as much because it’s less obvious and because we can’t as easily track reverse dependencies on crates.io to evaluate usage.
A macro seems heavy weight! What other options have you considered?
I also considered the idea of having p# keywords (“preview”), so e.g.
#[allow(preview_feature)]p#constfncompute_value<T: p#constDefault>(){// works on stable
}
Using a p# keyword would fire off a lint (preview_feature) that you would probably want to allow.
This is less intrusive, but I like the crate idea better because it allows us to release a v2.0 of the p#const keyword.
What kinds of things can we use preview crates for?
Good question. I’m not entirely sure. It seems like APIs that require us to define new traits and other things would be a bit tricky to maintain the total interoperability I think we want. Tools like trait aliases etc (which we need for other reasons) would help.
Who else does this sort of thing?
Ember has formalized this “plumbing first” approach in their version of editions. In Ember, from what I understand, an edition is not a “time-based thing”, like in Rust. Instead, it indicates a big shift in paradigms, and it comes out when that new paradigm is ready. But part of the process to reaching an edition is to start by shipping core APIs (plumbing APIs) that create the new capabilities. The community can then create wrappers and experiment with the “porcelain” before the Ember crate enshrines a best practice set of APIs and declares the new Edition ready.
Java has a notion of preview features, but they are not semver guaranteed to stick around.
I’m not sure who else!
Could we use decorators instead?
Usability of decorators like #p[const_preview::const_item] is better, particularly in rust-analyzer. The tricky bit there is that decorates can only be applied to valid Rust syntax, so it implies we’d need to extend the parser to include things like ~const forever, whereas I might prefer to have that complexity isolated to the const_preview crate.
So is this a done deal? Is this happening?
I don’t know! People often think that because I write a blog post about something it will happen, but this is currently just in “early ideation” stage. As I’ve written before, though, I continue to feel that we need something kind of “middle state” for our release process (see e.g. this blog post, Stability without stressing the !@#! out), and I think preview crates could be a good tool to have in our toolbox.
Hat tip to Yehuda Katz and the Ember community, Tyler Mandry, Jack Huey, Josh Triplett, Oli Scherer, and probably a few others I’ve forgotten with whom I discussed this idea. Of course anything you like, they came up with, everything you hate was my addition. ↩︎
We thank everyone who dedicated their time to share valuable responses and suggest potential features for us to consider implementing!
Each user could give each feature 1 to 5 votes. A total of 154 Pontoon users participated in the survey, 68 of which voted on all features. The number of participants is lower than in the past years, since we only reached out to users who explicitly opted-in to email updates.
We look forward to implementing these new features and working towards a more seamless and efficient translation experience with Pontoon. Stay tuned for updates!
Mariana Olaizola Rosenblat covers How Meta Turned Its Back on Human Rights for Tech Policy Press. Zuckerberg announced that his company will no longer work to detect abuses of its platforms other than high-severity violations of content policy, such as those involving illicit drugs, terrorism, and child sexual exploitation. The clear implication is that the company will no longer strive to police its platform against other harmful content, including hate speech and targeted harassment.
Sounds like a brand-unsafe environment. So is another rush of advertiser boycott stories coming? Not this time. Lara O’Reilly reports that brand safety has recently become a political hot potato and been a flash point for some influential, right-leaning figures. In uncertain times, marketing decision-makers are keeping a low profile. Most companies aren’t really set up to take on the open-ended security risk of coming out against hate speech by users with friends in high places. According to the Fraternal Order of Police, the January 6 pardons send a dangerous message, and that message is being heard in marketing departments. The CMOs who boycotted last time are fully aware that stochastic terrorism is a thing, and that rage stories about companies spread quickly in Facebook groups and other extremist media. If an executive makes the news for pulling ads from Meta, they would be putting employees at risk from lone, deniable attacks. So instead of announcing a high-profile boycott, marketers are more likely to follow the example of Federal employees and do the right thing, by the book, and quietly.
And it’s possible for advertisers to reduce support for Meta without making a stink or drawing fire. Fortunately, Meta ads are hella expensive, and results can be unrealistic and unsustainable. Like all the Big Tech companies these days, Meta is coping with a slowdown in innovation by tweaking the ad rules to capture more revenue from existing services. As Jakob Nielsen pointed out back in 2006, in Search Engines as Leeches on the Web, ad platforms can even capture the value created by others. A marketer doesn’t have to shout ¡No Pasarán! or anything—just sharpen your best math pencil, quietly go through the numbers, spot something that looks low-ROAS or fraudulent in the Meta column, tweak the budget, repeat. If users can dial down Meta, so can marketers. (Update: Richard Kirk writes, Brands could be spending three times too much on social. You read that right. Read the math, do the math.) And if Meta comes out with something new and risky like the adfraud in the browser thing, Privacy-Preserving Attribution, it’s easy to use the fraud problem as the reason not to do it—you don’t have to stand up and talk politics at work.
From the user side
It’s not that hard to take privacy measures that result in less money for Big Tech. Even if you can’t quit Meta entirely, some basic tools and settings can make an impact, especially if you use both a laptop and a phone, not just a phone. With a few minutes of work, an individual in the USA can, in effect, fine the surveillance business about $50/month.
My list of effective privacy tips is prioritized by how much I think they’ll cost the surveillance business per minute spent. A privacy tips list for people who don’t like doing privacy tips but also don’t like creepy oligarchs. (As they say in the clickbait business, number 9 will shock you: if you get your web browser info from TV and social media, you probably won’t guess which browsers have built-in surveillance and/or fraud features.) That page also has links to more intensive privacy advice for those who want to get into it.
A lawyer question
As an Internet user, I realize I can’t get to Meta surveillance neutral just with my own privacy tools and settings. For the foreseeable future, companies are going to be doing server-to-server tracking of me with Meta CAPI.
So in order to get to a rough equivalent of not being surveilled, I need to balance out their actual surveillance by introducing some free speech into the system. (And yes, numbers can be speech. O, the Tables tell!) So what I’d like to do is write a surrogate script (that can be swapped in by a browser extension in place of the real Meta Pixel, like the surrogate scripts uBlock Origin uses) to enable the user to send something other than valid surveillance data. The user would configure what message the script would send. The surrogate script would then encode the message and pass it to Meta in place of the surveillance data sent by the original Meta script. There is a possible research angle to this, since I think that in general, reducing ad personalization tends to help people buy better products and services. An experiment would probably show that people who mess with cross-context surveillance are happier with their purchases than those who allow surveillance. Releasing a script like that is the kind of thing I could catch hell for, legally, so I’m going to wait to write it until I can find a place to host it and a lawyer to represent me. Anyone?
After Big Social. Dan Phiffer covers the question of where to next. I am going into this clear-eyed; I’m going to end up losing touch with a lot of people. For many of my contacts, Meta controls the only connection we have. It’s a real loss, withdrawing from communities that I’ve built up over the years (or decades in the case of Facebook). But I’m also finding new communities with different people on the networks I’m spending more time in.
It's been 3 years since I started working on Dawnmaker full-time with Alexis. The creation of our first commercial game coincided with the creation of Arpentor Studio, our company. I've shared a lot of insights along the way on this blog, from how we made our first market research (which was incredibly wrong) to how much we made with our game (look at the difference between the two, it's… interesting). I wrote a pretty big piece were I explained how we built Arpentor Studio. I wrote a dozen smaller posts about the development of Dawnmaker. And I shared a bunch of my feelings, mistakes and successes in my yearly State of the Adrian posts (in French only, sorry).
But today, I want to take a step back and give a good look at these last 3 years. It's time for the Dawnmaker post-mortem, where I'm going to share what I believe we did well, what we did wrong, and what I've learned along the way. Because Dawnmaker and Arpentor Studio are so intertwined, I'm inevitably going to talk about the studio as well, but I think it makes sense. Let's get started!
What we did
Let's get some context first. Dawnmaker is a solo strategy game, mixing city building and deckbuilding to create a board game-like experience. It was released in July 2024 on Steam and itch.io. The team consisted of 2 full-time people, with occasional help from freelancers. My associate Alexis took care of everything related to graphics, and I did the programming and game design of the game. If you're interested in how much the game sold, I wrote a blog post about this: 18 days of selling Dawnmaker.
I created the very first prototype of what would become Dawnmaker back in the summer of 2021, but we only started working on the game full-time in December of that year. We joined a local incubator in 2022, which kind of shook our plans: we spent a significant portion of our time working on administrative things around the game, like making pitch decks and funding briefs. We had to create a company earlier than we had planned to ask for public funding. So in 2022 we only spent about half our time actually working on developing the game. In 2023, after having been rejected our main source of funding, we shrunk down our ambitions and focused on just making the game. We still spent time to improve our pitch deck and contacted some publishers, but never managed to secure a deal. In early 2024, we decided to self-publish, started our Steam page and worked on promoting the game while polishing what we had.
Because we never found a publisher, we never had the money to do the production phase of Dawnmaker. That means the game shipped with about half the content we wanted it to have. Here are my definitions of the different phases of a game project, as I'll refer to them later on in this article:
Ideation — The phase where we are defining the key concepts of the game we want to make. There's some early prototyping there, as well as research. The goal is to have a clear picture of what we want to build.
Pre-production — The phase where we validate what the core of the game is, that it is fun, and that we will be able to actually deliver it. It can be cut down into three steps: prototyping, pre-production and vertical slice. In prototyping we validate the vision of the game. In pre-production (yes, it's the same name as the phase, but that's what I was taught) we build our production pipeline. During the vertical slice, we validate that the pipeline works and finalize the main systems of the game.
Production — The phase where we build the content of the game. This phase is supposed to be one that can be planned very precisely, because the pre-production has supposedly removed almost all the unknowns.
Post-production — The phase where we polish our game and take it through the finish line.
Now that you have some context, let's get into the meat of this article!
What we did right
Let's start this post-mortem on a positive note, and list the things that I believe we did well. First and foremost, we actually shipped a game! Each game that comes out is a little miracle, and we succeeded there. We kept our vision, we pushed it as far as we could, and we did not give up. Bravo us!
Good game quality
What's more, our game has been very well received: at the time of writing, we have a 93% positive review ratio on Steam, from 103 reviews. I am of course stoked that Dawnmaker was liked by that many reviewers. I think there are 3 main reasons why we had such positive reviews (other than the game being decently fun, of course):
We kept a demo up at all times, even after the release, meaning that tentative customers could give it a try before buying. If they didn't like the demo, they didn't buy the game — not good for us — but then they were not disappointed by a product they bought — good for them and for our reviews!
We were speaking to a very small niche, but provided something that was good for them. The niche is a weird intersection of deckbuilding, city building and board game fans. It was incredibly difficult to find and talk to, probably because it is, as I said, very small, but we made something that worked very well for those players.
We under-priced the game aggressively (at $9.99) to lower the players' expectations. That actually transpired in the reviews, where a few people mentioned that the game had flaws, but they tolerated them because of the price tag. (Note: the game has since been moved up to a $14.99 price point by our new publisher.)
Of course, had the game been bad, we would not have had those reviews at all. So it goes to say that Dawnmaker is a fine game. For all its flaws, it is fun to play. I've played it a lot — as I guess do all game creators with their creation — and it took me a while to get bored with it. The median playtime on Steam is 3 hours and 23 minutes, with an average playtime of 8 hours and 17 minutes. Here's a stat that blows my mind: at the time of writing, 175 people (about 10% of our players) have played Dawnmaker for more than 20 hours. At least 15 people played it for more than 50 hours. I know this is far from the life-devouring monsters that are out there, like Civilization, Skyrim, Minecraft or GTA, but for our humble game and for me, that's incredible to think about.
So, we made a fun game. I think we succeeded there by just spending a lot of time in pre-production. Truth be told, we spent about 2 years in that phase, only 6 months in post-production, and we did not really do a real production phase. For 2 years, we were testing the game and making deep changes to its core, iterating until we found the best version of this game we could. Mind you, 2 years was way too long a time, and I'll get back to that in the failures section. But I believe the reason why Dawnmaker was enjoyed by our players is because we took that time to improve it.
Lesson learned
Make good games?
The art of the game was also well received, and here again I think time was the key factor. It took a long time to land on the final art direction. There was a point where the game had a 3D board, and it was… not good. I think one of our major successes, from a production point of view, was to pivot into a 2D board. That simplified a lot of things in terms of programming, of performance, and made us land on that much, much better art style. It took a long time but we got there.
<figcaption>The first prototype of Dawnmaker, which had sound for some reason…</figcaption>
There's one last aspect that I think mattered in the success of the game, and for which I am particularly proud: the game had very few bugs upon release, and none were blocking. I've achieved that by prioritizing bug fixing at all times during the development of the game. I consider that at any point in time, and with very few exceptions, fixing a known bug is higher priority than anything else. Of course this is easier done when there is a single programmer, who knows the entire code base, but I'm convinced that, if you want to ship bug-free products, bug fixing must not be an afterthought, a thing that you do in post-production. If you keep a bug-free game at all times during development, chances are very high that you'll ship a bug-free game!
Lesson learned
Keeping track of bugs and fixing them as early as possible makes your life easier when you're nearing release, because you don't have to spend time chasing bugs in code that you wrote months or years before. Always reserve time for bug fixing in your planning!
Custom tooling
Speaking of programming, a noticeable part of my time was spent creating a custom tool to handle the game's data. Because we're using a custom tech stack, and not a generic game engine, we did not have access to pre-made tooling. But, since I was in control of the full code of the game, I have been able to create a tool that I'm very happy with.
First a little bit of context: Dawnmaker is coded with Web technologies. What it means is that it's essentially a website, or more specifically, a web app. Dawnmaker runs in a browser. Heck, for most of the development of the game, we did our playtests in browsers! That was super convenient: you want someone to test your game? They can open their favorite browser to the URL of the game, and tada, they can play! No need to download or install anything, no need to worry about updates, they always have the latest version of the game there.
Because our game is web-based, I was able to create a content editor, also web-based, that could run the game. So we have this editor that is a convenient way to edit a database, where all the data about Dawnmaker sits. The cool thing is that, when one of us would make a change to the data, we could click a button right there in the editor, and immediately start playing the game with the changes we just made. No need to download data, build locally, or such cumbersome steps. One click, and you're in the game, with all the debug tools and conveniences you need. Another click, and you're back to the editor, ready to make further changes.
<figcaption>Screenshot of the Dawnmaker content editor</figcaption>
That tool evolved over time to also handle the graphical assets related to our buildings. Alexis was able to upload, for each building, its illustration and all the elements composing its tile. I added a spritesheet system that could be used in buildings as animations, with controls to order layers, scale and position elements, and even change the tint of sprites.
Lesson learned
Tooling is an investment that can pay double: it makes you and your team go faster, and can be reused in future projects. Do not make tools for the sake of making tools of course. Do it only when you know that it will save you time in the end. But if you're smart about it, it can really pay off in the long run.
Long-term company strategy
There's one last thing I believe we did well, that I want to discuss, and it's related to our company strategy. Very early on in the creation of Arpentor Studio, we thought about our long-term strategy: what does our road to success look like? Where do we want to be in 5 to 10 years? Our answer was that we wanted to be known for making strategy games (sorry, lots of strategies in this paragraph) that were deep, both in mechanics and meaning. The end game would be to be able to realistically be making my dream competitive card game — something akin to Magic: the Gathering, Hearthstone or Legends of Runeterra.
What we did well is that we did not start by the end, but instead drafted a plan to gather experience, knowledge and money, to put ourselves in a place where we would be confident about launching such an ambitious project. We aimed to start by making a solo game, to avoid the huge complexities of handling multiplayer. We aimed to make a simple strategy game, too, but there we missed our goal, for the game we made was way too original and complex. But still, we managed to stay on track: no multiplayer, simple 2D (even though we went 3D for half a year), and mechanics that were not as heavy as they could have been.
We failed on the execution of the plan, and I'll expand on that later in this post, but we did take the time to make a plan and that's a big success in my opinion.
Lesson learned
Keep things as simple as possible for your first games! We humans have a tendency to make things more complex as we go, increasing the scope, adding cool features and so on. That can be a real problem down the line if you're trying to build a sustainable business. Set yourself some hard constraints early on (for example, no 3D, no narration, no NPCs, etc. ) and keep to them to make sure you can finish your game in a timely manner.
What we did wrong
It's good to recognize your successes, so that you can repeat them, but it's even more important to take a good look at your failures, so that you can avoid repeating them. We made a lot of mistakes over these past 3 years, both related to Dawnmaker and to Arpentor Studio. I'll start by focusing on the game's production, then move on to the game itself to finally discuss company-related mistakes.
Production mistakes
Scope creep aka "the Nemesis of Game Devs"
The scope of Dawnmaker exploded during its development. It was initially supposed to be a game that we wanted to make in about a year. We ended up working on it for more than two years and a half instead! There are several reasons why the scope got so out-of-control.
<figcaption>Dawnmaker in July 2022 — called "Cities of Heksiga" at the time</figcaption>
The first reason is that we were not strict enough in setting deadlines and respecting them. During our (long) preproduction phase, we would work on an iteration of the game, then test it, then realize that it wasn't as good as we wanted it to be, and thus start another iteration. We did this for… a year and a half? Of course, working on a game instead of smaller prototypes didn't help in reaching the right conclusions faster. But we also failed in having a long-term planning, with hard dates for key milestones of the game's development. We were thinking that it was fine, that the game would be better if we spent more time on it. That is definitely true. What we did not account for was that it would not sell significantly better by working more. I'll get back to that when discussing the company strategy.
Lesson learned
Setting deadlines and respecting them is one of the key abilities to master for shipping games and making money with them. Create a budget and assign delivery dates to key milestones. Revisit these often, to make sure you're on track. If not, you need to reassess your situation as soon as possible. Cut the scope of your work or extend your deadlines, but make sure you adapt the budget and that you have a good understanding of the consequences of making those changes.
The second reason the scope exploded is that we were lured into thinking that getting money was easy, especially public funding, and that we should ask for as much money as we could. To do that, we had to increase the scope of what we were presenting, in the hope that we would receive big money, which would enable other sources of money, and allow us to make a bigger game. The problem we faced was that we shifted our actual work to that new plan, that bigger scope, long before we knew if we would get the money or not. And so instead of working on a 1-year production, insidiously we found ourselves working on a 2 to 3-year production. And then of course, we did not get the money we asked for, and were on a track that required a few hundred thousands of euros to fund, with just our personal savings to do it.
I think the trick here is to have two different plans for two different games. Their core is the same, but one is the game that you can realistically make without any sort of funding, and the other is what you could do if you were to receive the money. But, we should never start working on the "dream" game until the money is on our bank account. I think that's a terribly difficult thing to do — at least it was for me — and a big trap of starting a game production that relies on external funding.
Lesson learned
Never spend money you do not have. Never start down a path until you're sure you will be able to execute it entirely.
The third reason why the scope got out of control is a bit of a consequence of the first two: we saw our game bigger than it ended up being, and did not focus enough on the strength of our core gameplay. We were convinced that we needed to have a meta-progression, a game outside the game, and struggled a lot to figure out what that should be. And as I discussed in the previous section, I think we failed to do it: our meta-progression is too shallow and doesn't improve the core of the game.
Looking back, I remember conversations we had were we justified the need for this work with the scope of the game, with the price we wanted to sell the game for, and thus with the expectations of our future players. The reasoning was, this is a $20 game, players will expect a lot of replayability, so we need to have a meta-progression that would enable it. I think that was a valid line of thought, if only we were actually making a $20 game. In the end, Dawnmaker was sold for $10. Had we realigned earlier, had we taken a real step back after we realized that we were not getting any significant funding, maybe we would have seen this. For a $10 game, we did not need such a complex meta-progression system. We could have focused more on developing the core of the game, building more content and gameplay systems, and landed on a much simpler progression.
Lesson learned
Things change during the lifetime of a game. Take a step back regularly to ask yourself if the assumptions you made earlier are still valid today.
Prototyping the wrong way
I mentioned earlier that we spent a lot of time in preproduction, working on finding the best version of the core gameplay of our game. I said it was a good thing, but it's also a bad one because it took us way too long to find it. And the reason is simple: we did prototyping wrong.
<figcaption>Dawnmaker in January 2023</figcaption>
The goal of prototyping is to answer one or a few questions as fast as possible. In order to do that, you need to focus on building just what you need to answer your question, and nothing else. If you start putting actual art in your gameplay prototype, or gameplay in your art prototype, then you're not making a prototype: you're making a game. That's what we did. Too early we started working on adding art to our gameplay prototype. Our first recorded prototype, which we did in Godot, had some art in it. Basic one, sure, but art anyway. The time it took to integrate the art into that prototype is time that was not spent answering the main question the prototype was supposed to answer — at that time: was the core gameplay loop fun?
It might seem inconsequential in a small prototype, but that cost quickly adds up. You're not as agile as you would be if you focused on only one thing. You're solving issues related to your assets instead of focusing on gameplay. And then you're a bit disappointed because it doesn't look too great so you start spending time improving the art. Really quickly you end up building a small game, instead of building a small prototype. Our first prototype even had sound! What the hell? Why did we put sound in a prototype that was crap, and was meant to help us figure out that the gameplay was crap?
Lesson learned
Make your prototypes as small and as focused as possible. Do not mix gameplay and art prototypes. Make sure each prototype answers one question. Prototype as many things as possible before moving on to preproduction.
Not playing to our strengths
I mentioned earlier that we had a 3D board in the game for a few months. Going 3D was a mistake that cost us a lot of time, because I had to program the whole thing, in an environment that had little tools and conveniences — we were not using an engine like Godot or Unity. And I was not good at 3D, I had never worked on a 3D game before, so I had a learn a lot in order to do something functional. The end result was something that worked, but wasn't very pleasant to look at. It had performance issues on my computer, it had bugs that I had no clue how to debug. We ended up ditching the whole 3D board after a lot of discussions and conflicts. The ultimate nail in the coffin came from a publisher who had been shown the game, and who asked: "what is the added value of 3D for this game?" Being unable to give a satisfying answer, we moved back to a 2D board, and were much better for it.
<figcaption>Dawnmaker in June 2023, with a 3D board</figcaption>
So my question is: why did we go 3D for that period of time? I think there were two reasons working together to send us in that trap. The first one is that we did not assess our strengths and weaknesses enough. Alexis's strength was making 3D art, while I had no experience in implementing 3D in a game, and we knew it, but we did not weight those enough. The second reason is that we did not know enough about our tools to figure out that we could find a good compromise. See, we thought that we could either go 3D and build everything in 3D, from building models in blender to integrating on a 3D board in the game, or we could go 2D, which would simplify my work but would force Alexis to draw sprites by hand.
What we figured out later on was that there were tools that allowed Alexis to work in 3D, creating models and animations in blender, but export everything for a 2D environment very easily. There was a way to have the best of both worlds, exploiting our strengths without requiring us to learn something new and complex — which we definitely did not want to do for our first commercial game. Our mistake was to not take the time to research that, to find that compromise.
Lesson learned
Research the tools at your disposal, and always look for the most efficient way to do things. Play to the strengths of your team, especially for your first games.
Building a vertical slice instead of a horizontal one
We struggled a lot to figure out what our vertical slice should be. How could we prove that our game was viable to a potential investor? That's what the vertical slice is supposed to do, by providing a "slice" of your game that is representative of the final product you intend to build. It's supposed to have a small subset of your content, like a level, with a very high level of polish. How do you do that for a game that is systemic in nature? How do you build the equivalent of a "level" of a game like Dawnmaker?
We did not find a proper answer to this question. We were constantly juggling priorities between adding systems, because we needed to prove that the game worked and was fun, and adding signs, feedback and juice, because we believed we had to show what the final product would look and feel like. We were basically building the entire game, instead of just a slice of it. This was in part because we had basically no credentials to our name, as Dawnmaker was our first real game, and feared publishers would have trouble trusting that we would be able to execute the "icing" part of the game. I still think that's a real problem, and the only solution that I see is to not try to go for funding for your first games. But I'll talk more about that in the Company strategy section below.
<figcaption>Dawnmaker in November 2023</figcaption>
However, I recently came across the concept of horizontal slice, as opposed to the vertical slice, and that blew my mind. The idea is, instead of building a small piece of your game with final quality, to build almost all of the base layers of the game. So, you would build all the systems, a good chunk of the content, everything that is required to show that the gameplay works and is fun. Without working on the game's feel, its signs and feedback, a tutorial, and so. No icing on the cake, just the meat of it. (Meat in a cake? Yeah, that sounds weird. Or British, I don't know.) The goal of the horizontal slice is to prove that the game as a whole works, that all the systems fit together in harmony, and that the game is fun.
I believe that this is a much better model for a game like Dawnmaker. A game like Mario is fun because it has great controls, pretty assets and funny situations. That's what you prove with a vertical slice. But take a game like Balatro. It is fun because it has reached a balance between all the systems, because it has enough depth to provide a nearly-endless replayability. Controls, feedback and juice are still important of course, but they are not the core of the game, and thus when building such a game, one should not focus on those aspects, but on the systems. We should have done the same with Dawnmaker, and I'll be aiming for a horizontal slice with my next strategy game for sure.
Lesson learned
Different types of games require different processes. Find the process that best serves the development of yours. If you're making some sort of systemic game, maybe building a horizontal slice is a better tool than going for the commonly used vertical slice?
Game weaknesses
Let's now talk about the game itself. Dawnmaker received really good reviews, but I still believe it is lacking in many ways. There are many problems with the gameplay: it lacks some form of adjustable difficulty, to make it a better challenge for a bigger range of players. It lacks a more rewarding and engaging meta-progression. And of course it lacks content, as we never actually did our production phase.
Weak meta-progression
As I wrote earlier, I am very happy about the core loop of Dawnmaker. However, I think we failed big with its meta-progression. We decided to make it a roguelike, meaning that there is no progression between runs. You always start a run from the same state. Many players disliked that, and I now understand why, and why roguelites have gained in popularity a lot.
I recently read an article by Chris Zukowski where he discusses the kind of difficulty that Steam players like. I agree with his analysis and his concept of the "Easy-Hard-Easy (but variable)" difficulty, as I think that's part of a lot of the big successes on Steam these last few years. To summarize (read the article for more details), players like to have an easy micro-loop (the core actions of the game, what you do during one turn), a hard macro-loop (the medium-term goals, in our case, getting enough Eclairium to level up before running out of Luminoil), and on top of that, a meta-progression that they have a lot of control over, and that allows them to adjust the difficulty of the challenge. An example I like a lot is Hades and its Mirror of Night: playing the game is easy, controls are great, but winning a run is very hard. However, by choosing to grind darkness and using it to unlock certain upgrades in the mirror, you get to make the challenge a lot easier. But someone else might decide to not grind darkness, or not spend, and play with a much greater challenge. The player has a lot of control over the difficulty of the game.
<figcaption>Dawnmaker's world map</figcaption>
I think this is the biggest miss of Dawnmaker in terms of gameplay. Players cannot adjust the difficulty of the game to their tastes, which has been frustrating for a lot of them. Some complained it was way too hard while others have found the game too easy and would have enjoyed more challenge. All of them would have enjoyed the game a lot more had they had a way to control the challenge one way or another. Our mistake was to have some progression inside a run, but not outside. A player can grow stronger during a run, improving their decks or starting resources, but when they lose a run they have to start from scratch again. A player who struggles with the challenge has no way to smooth the difficulty, they have to work and learn how to play better. The "git gud" philosophy might work in some genres, but evidently it didn't fit with the audience of Dawnmaker.
This is not something that would have been easy to add though. I think it's something that needs to be thought about quite early in the process, as it impacts the core gameplay a lot. We tried to add meta-progression to our game too late in the process, and that's a reason we failed: it was too difficult to add good progression without impacting the careful balance of the core gameplay, and having to profoundly rework it.
Lesson learned
Offering an adaptative challenge is important for Steam players, and meta-progression is a good tool to do that. But it needs to be anticipated relatively early, as it is tightly tied to your core gameplay.
Lack of a strong fantasy
I believe the biggest cause for Dawnmaker's financial failure is that it lacks a strong fantasy. That gave us a lot of trouble, mostly in trying to sell the game to players. Presenting it as a "city building meets deckbuilding" is not a fantasy, it's genres. We tried to put forth the "combo" gameplay, telling that cards and buildings combine to create powerful effects, but as I just wrote, that's gameplay and not a fantasy. Our fantasy was to "bring life back to a dead world", but that's not nearly strong enough: it's not surprising nor exciting.
<figcaption>Dawnmaker in February 2024</figcaption>
In hindsight, I believe we missed a huge opportunity in making the zeppelin our main fantasy. It's something that's not often seen in games, it's a great figure for the ambiance of the game, and I think it would have helped create a better meta-progression. We have an "Airship" view in the game, where players can improve their starting state for the next region they're going to explore, but it's a very basic UI. There was potential to make something more exciting there.
The reason for this failure is that we started this project with mechanics and not with the fantasy. We spent a long time figuring out what our core gameplay would be, testing it until it was fun. And only then did we ask ourselves what the fantasy should be. It turns out that putting a fantasy and a theme on top of gameplay is not easy. I don't mean to say it's impossible, some have successfully done it, but I believe it is much harder than starting with an exciting fantasy and building gameplay on top of it.
Lesson learned
Marketing starts day 1 of the creation of a game. The 2 key elements that sell your game are the genre(s) of the game, and its fantasy or hook. Do not neglect those if you want to make money with your game.
This mistake was in part caused by me being focused primarily on mechanics as a game designer. I often start a project with a gameplay idea, a gimmick or a genre, but rarely with a theme, emotion or fantasy. It's not a problem to start with mechanics, of course. But the fantasy is what sells the game. My goal for my next games, as a designer, is to work on finding a strong fantasy that fits my mechanics much earlier in the process, and build on it instead of trying to shove it into an advanced core loop.
Company strategy
Oooo boy did we make mistakes on a company level. By that I mean, with managing our money. We messed up pretty bad — though seeing stories that pop up regularly on some gamedev subreddits, it could have been way worse. Doesn't mean there aren't lessons to be learned here, so let's dive in!
Hiring too soon, too quick
Managing money is difficult! Or at least, we've not been very good at it. We made the mistake of spending money at the wrong time or for the wrong things several times. That mainly happened because we had too much trust in the future, in the fact that we would find money easily, either by selling our game or by getting public money or investors. If we did get some public funding, that was not nearly enough to cover what we spent, and so Dawnmaker was mostly paid for by our personal savings.
The biggest misplacement of money we made was to poorly hire people. We made two different mistakes here: on one occasion, we hired someone without properly testing that person and making sure they would fit our team and project. On the other, we hired someone only to realize when they started that we did not have work to give them, because we were way too early in the game's development. Both recruitments ended up costing us a significant amount of money while bring very little value to the game or the company.
But those failed recruitments had another bad consequence: we hurt people in the process. Our inexperience has been a source of pain for human beings who chose to trust us. That is a terrible feeling for me. I don't know what more to write about this, other than I think I've learned and I hope I won't be hurting others in the future. I'll do my best anyway.
Lesson learned
Hiring is freaking hard. Do not rush it. It's better to not hire than to hire the wrong person.
Too much investment into our first game
I've talked about it already in previous sections, but the biggest strategic mistake on Dawnmaker was to spend so much time on it. Making games is hard, making games that sell is even harder, and there's an incredible amount of luck involved there. Of course, the better your game, the higher your chances. But making good games requires experience. Investing 2.5 years into our first commercial game was way too risky: the more time we spent on the game, the more money it needed to make out, and I don't believe a game's revenue scales with the time invested in it.
Side note: we made a game before Dawnmaker, called Phytomancer — it's available on itch.io for 3€ — but because it had no commercial ambition, I don't think it counts much on the key areas of making games that sell.
Here are facts:
Dawnmaker cost us about 320k€ to make — read my in-depth article about Dawnmaker's real cost for more details — and only made us about 8k€ in net revenue. That is a financial catastrophe, only possible because we invested a lot of our time and personal savings, and we benefited from some French social welfare.
Most indie studios close after they release their first game. It's unclear what the exact causes are, but from personal experience, I bet it's in big part because those companies invest too much in there first game and have nothing left when it comes to making the second one — either money or energy. We tend to burn cash and ourselves out.
And there's an economic context too: investments in games and game companies have slowed down to a trickle the past couple years, and they don't seem to be going back up soon. Games are very expensive to make, and the actors that used to pay for their production (publishers, investors) are not playing that role anymore.
Considering this, I strongly believe that today, investing several years into making your first game is not a valid company strategy. It's engaging in an act of faith. And a business should not run on faith. What pains me is that we knew this when we started Arpentor Studio, and we wanted to make Dawnmaker in about a year. But we lacked the discipline to actually keep that deadline, and we lost ourselves in the process. We got heavily side-tracked by thinking we could get some funding, by growing our scope to ask for more money, etc. We didn't start the project with a clear objective, with a strict deadline. So we kept delaying and delaying. We had the comfort of having decent money reserves. We never thought about what would happen after releasing Dawnmaker, never asked ourselves what our situation would be if the game took 3 years to release and didn't make any money. We should have.
Lesson learned
Start by making small games! Learn, experiment, grow, then go for bigger games when you're in a better position to succeed.
Here are my arguments for making several small games instead of investing too much into a single bigger game. Note that these are targeted to folks trying to create a games studio, to make a business of selling games. If your goal is to create your dream game, or if you're in it for the art but don't care about the money, this likely does not apply to you.
By releasing more games, you gain a lot of key experience in the business of making games that sell. You receive more player feedback. You have the opportunity to try more things. You learn the tricks of the platform(s) you're selling on — Steam is hard!
By releasing more games, you give yourself more chances to break out, to hit that magic moment when a game finds its audience, because it arrives at the right moment, in the right place. (For more on this, I highly recommend this article by Ryan Rigney: Nobody Knows If Your Game Will Pop Off, where the authors talks about ways of predicting a hit and the correlation between the number of hits and the number of works produced.)
By releasing more games, you build yourself a back catalog. Games sell more on their first day, week or month, for sure, but that doesn't mean they stop selling afterwards. Games on Steam keep generating revenue for a long time, even if a small one. And a small revenue is infinitely better than no revenue at all. And small revenues can pile up to make, who knows, a decent revenue?
By releasing more games, you grow your audience. Each game is a way to reach new people and bring them to your following — be it through a newsletter, a discord server or your social networks. The bigger your audience, the higher your chances of selling your next game.
By releasing more games, you build your credibility as a game developer. When you go to an investor to show them your incredible new idea, you will make a much better impression if you have already released 5 games on Steam. You prove to them that you know how to finish a game.
Keep in mind that making small games is really, really hard. It requires a lot of discipline and planning. This is where we failed: we wanted to make our game in one year, but never planned that time. We never wrote down what our deadline was, never budgeted that year into milestones. If you want to succeed there, you need to accept that your game will not be perfect, or even good. That's fine. The goal is not to make a great game, it's to release a game. However imperfect that game is, the success criteria is not its quality, or its sales numbers. The number one success criteria is that people can buy it.
I wanted to end here, because I think this is the most important thing to learn from this post-mortem. If you're trying to build a sustainable game studio, if you're in it for the long run, then please, please start by making small games. Don't gamble on a crazy-big first game. Garner experience. Learn how the market works. Try things in a way that will cost you as little as possible. Build your audience and your credibility. Then, when the time is right, you'll be much better equipped to take on bigger projects. That doesn't mean you will automatically succeed, but your chances will be much, much higher.
As for myself? Well, I'm trying to learn from my own mistakes. My next project will be a much shorter one, with strict deadlines and milestones. I will capitalize on what I made for Dawnmaker, reusing as many tools and wisdom as possible. Trying to make the best possible game with what time, money and resources I have. All I can say for now is that it's going to be a deckbuilding strategy game about an alchemist trying to create the Philosopher's Stone. I will talk about it more on my blog and on Arpentor's newsletter, so I hope you'll follow me into that next adventure!
Subscribe to Arpentor Studio's Newsletter!One email about every other month, no spams, with insights on the development of our games and access to early versions of future projects.
Thanks a lot to Elli for their proofreading of this very long post!
(update 2 Feb 2025) This site has some pages with inline styles, so I can’t use that CSP line right now. This is because I use the SingleFile extension to make mirrored copies of pages, so I need to move those into their own virtual host so I can go back to using the version without the unsafe-inline.
(update 23 Feb 2025) The Pagefind site search requires ‘unsafe-eval’ in CSP in order to support WASM. This should be wasm-unsafe-eval in the future.
To do WASM and inline styles, the new value for the Content-Security-Policy header is:
Why is Big Tech hellbent on making AI opt-out? by Richard Speed. Rather than asking we’re going to shovel a load of AI services into your apps that you never asked for, but our investors really need you to use, is this OK? the assumption instead is that users will be delighted to see their formerly pristine applications cluttered with AI features. Customers, however, seem largely dissatisfied. (IMHO if the EU is really going to throw down and do a software trade war with the USA, this is the best time to switch to European Alternatives. Big-time proprietary software is breaking compatibility while independent alternatives keep on going. People lined up for Microsoft Windows 95 in 1995 and Apple iPhones in 2007, and a trade war with the USA would have been a problem for software users then, but now the EuroStack is a thing. The China stack, too, as Prof. Yu Zhou points out: China tech shrugged off Trump’s ‘trade war’ − there’s no reason it won’t do the same with new tariffs. I updated generative ai antimoats with some recent links. Even if the AI boom does catch on among users, services that use AI are more likely to use predictable independently-hosted models than to rely on Big Tech APIs that can be EOLed or nerfed at any time, or just have the price increased.)
California vs Texas Minimum Wage, 2013-2024 by Barry Ritholtz. [F]or seven years–from January 2013 to March 2020–[California and Texas quick-service restaurant] employment moved almost identically, the correlation between them 0.994. During that seven year period, however, TX had a flat $7.25/hr minimum wage while CA increased its minimum wage by 50%, from $8/hr to $12. Related: Is a Big Mac in Denmark Pricier Than in US?
What’s happening on RedNote? A media scholar explains the app TikTok users are fleeing to – and the cultural moment unfolding there Jianqing Chen covers the Xiaohongshu boom in the USA. This spontaneous convergence recalls the internet’s original dream of a global village. It’s a glimmer of hope for connection and communication in a divided world. (This is such authentic organic social that the Xiaohongshu ToS hasn’t even been translated into English yet. And not only does nobody read privacy policies (we knew that) but videos about reuniting with your Chinese spy from TikTok are a whole trend on there. One marketing company put up a page of Rules & Community Guidelines translated into English but I haven’t cross-checked it. Practice the core socialist values. and Promote scientific thinking and popularize scientific knowledge.)
Bob Sullivan reports Facebook acknowledges it’s in a global fight to stop scams, and might not be winning (The bigger global fight they’re in is a labor/management one, and when moderator jobs get less remunerative or more stressful, the users get stuck dealing with more crime.) Related: Meta AI case lawyer quits after Mark Zuckerberg’s ‘Neo-Nazi madness’; Llama depositions unsealed by Amy Castor and David Gerard. (The direct mail/database/surveillance marketing business, get-rich-quick schemes, and various right-wing political movements have been one big overlapping scene in the USA for quite a while, at least back to the Direct Mail and the Rise of the New Right days and possibly further. People in the USA get targeted for a lot of political disinformation and fraud (one scheme can be both), so the Xiaohongshu mod team will be in for a shock as scammers, trolls, and worse will follow the US users onto their platform.)
A refreshed New Tab layout is being rolled out to users in the US and Canada, featuring a repositioned logo and weather widget to prioritize Web Search, Shortcuts, and Recommended Stories at the top. The update includes changes to the card UI for recommended stories and allows users with larger screens to see up to four columns, making better use of space.
Making better use of the space on the New Tab page!
dao enabled the ability to search for closed and saved tab groups (Bug 1936831)
Fixed about:addons blocklist state message-bars not refreshed when the add-on active state doesn’t change along with the blocklist state (Bug 1936407)
Fixed a moz-toggle button related visual regression in about:addons (regression introduced from Bug 1917305 in Nightly 135 and fixed in the same release by Bug 1937627)
Adjusted popup notification primary button default string to match the Acorn style guide (Bug 1935726)
WebExtensions Framework
Fixed an add-on debugging toolbox regression on resending add-ons network requests from the DevTools Network panel (regression introduced in Nightly 134 from Bug 1754452 and fixed in Nightly 135 by Bug 1934478)
Thanks to Alexandre Poirot for fixing this add-on debugging regression
WebExtension APIs
Fixed notification API event listeners not restarting suspended extension event pages (Bug 1932263)
As part of the work for the MV3 userScripts API (currently locked behind a pref in Nightly 134 and 135):
Introduced permission warning in the Firefox Desktop about:addons extensions permissions view (Bug 1931545)
Karan Yadav fixed Offline simulation in Responsive Design Mode (#1873929) and added overflow to the device list popup (#1932455)
GWDx fixed a rendering issue in the Search sidebar of the Network Panel Search (#1938771)
Julian Descottes fixed a rendering issue in the Debugger panel Search sidebar when there was no results (#1924732)
Alexandre Poirot improved display of WebExtension content script, referencing the WebExtension name in the Console and the Debugger (#1413872). He also did something similar for worker, using the worker name instead of its URL when it has one (#1589908, #1935025)
Hubert Boma Manilla made the Call Stack panel in the Debugger accessible, in particular making sure it can be navigated with the keyboard only (#1843324)
Nicolas Chevobbe made the Storage Panel to display cookies from unpartitioned and partitioned cookie jars (#1907570), and added a column for the partition key (#1895215)
Liam (:ldebeasi) added support for the format argument to the browsingContext.captureScreenshot command. Clients can use it to specify an image format with a type such as “image/jpg” and a quality ranging between 0 and 1 (#1861737)
Spencer (:speneth) created a helper to check if a browsing context is a top-level browsing context (#1927829)
Internal:
Sasha landed several fixes to allow saving minidump files easily with geckodriver for both Firefox on desktop and mobile, which will allow to debug crashes more efficiently (#1882338, #1859377, #1937790)
Henrik enabled the remote.events.async.enabled preferences, which means we now process and dispatch action sequences in the parent process (#1922077)
Henrik fixed a bug with our AnimationFramePromise which could cause actions to hang if a navigation was triggered (#1937118)
Information Management
We’re delaying letting the new sidebar (sidebar.revamp pref) ride the trains while we address findings from user diary studies, experiments and other feedback. Stay tuned!
We’re focusing on fixing papercuts for the new sidebar and vertical tabs.
Migration Improvements
We’ve concluded the experiment that encouraged users to create or sign-in to Mozilla accounts to sync from the AppMenu and FxA toolbar menu. We’re currently analyzing the results.
Before the end of 2024, we were able to get some patches into 135 that will let us try some icon variations for the signed-out state for the FxA toolbar menu button. We’ll hopefully be testing those when 135 goes out to release!
We added a new way to filter the profile to only include the data that is related to the tab you would like to see, by adding tab selector. You can see this by clicking the “Full Profile” button on the top left corner. This allows web and gecko developers to only focus on a certain website.
We implemented a new way to control the profiler using POSIX signals on macOS and Linux. You can send SIGUSR1 to the Firefox main process to start the profiler and SIGUSR2 to stop and dump the profile to disk. We hope that this feature will be useful for cases where Firefox is completely frozen and using the usual profiler buttons is not an option. See our documentation here.
Lots of performance work to make the profiler itself faster.
Search and Navigation
Scotch Bonnet
Mandy enhanced restricted search keywords so that users can use both their own localized language as well as the English shortcut Bug 1933003
Daisuke fixed an issue where pressing ctrl+shift+tab while the Unified Search Button was enabled and the address bar is focused would not go to the previous tab Bug 1931915
Daisuke also fixed an issue where focusing the urlbar with a click and pressing shift tab wouldn’t focus the Unified Search Button Bug 1933251
Daisuke enabled the keyboard focus of the Unified Search Button using Shift + Tab after focus using CTRL + L Bug 1937363
Daisuke changed the behavior of the Unified Search Button to show when editing a URL instead of initial focus Bug 1936090
Lots of other papercuts fixed by the team
Search
Mandy initiated the removal of old application provided search engine WebExtensions from a users profile as they no longer require them due to the usage of search-config-v2 Bug 1885953
Suggest
Drew implemented a new simplified UI treatment for Weather Suggestions Bug 1938517
Drew removed the Suggest JS Backend as the Rust based backend was enabled by default in 124 Bug 1932502
Storybook/Reusable Components
Anna Kulyk added new –table-row-background-color and –table-row-background-color-alternate design tokens Bug 1919313
Anna Kulyk added support for the panel-item disabled attribute Bug 1919122
Collected here are the most recent blog posts from all over the Mozilla community.
The content here is unfiltered and uncensored, and represents the views of individual community members.
Individual posts are owned by their authors -- see original source for licensing information.
On 14 March a 
Blocks Social Media Trackers – Prevents social media platforms from monitoring your activity across different sites.
Give your privacy a fresh start — join the Spring Detox with Firefox today.
<figcaption class="wp-element-caption">With its minimalist pop-up interface, Gyazo makes it easy to clip elements, sections, or entire web pages. </figcaption>
<figcaption class="wp-element-caption">Give yourself a custom message of encouragement (or scolding?) whenever you try to visit a restricted site with Block Site</figcaption>
<figcaption class="wp-element-caption">Access all of Tabby’s features in one convenient pop-up. </figcaption>
<figcaption class="wp-element-caption">Emily Liu is the head of special projects at Bluesky.</figcaption>
<figcaption>The first prototype of Dawnmaker, which had sound for some reason…</figcaption>
<figcaption>Screenshot of the Dawnmaker content editor</figcaption>
<figcaption>Dawnmaker in July 2022 — called "Cities of Heksiga" at the time</figcaption>
<figcaption>Dawnmaker in January 2023</figcaption>
<figcaption>Dawnmaker in June 2023, with a 3D board</figcaption>
<figcaption>Dawnmaker in November 2023</figcaption>
<figcaption>Dawnmaker's world map</figcaption>
<figcaption>Dawnmaker in February 2024</figcaption>
