fidzu : Mozilla

In this month's Community Office Hours, we're chatting with our director Ryan Sipes. This talk opens with a brief history of Thunderbird and ends on our plans for its future. In between, we explain more about MZLA and its structure, and how this compares to the Mozilla Foundation and Corporation. We'll also cover the new Thunderbird Pro and Thundermail announcement And we talk about how Thunderbird put the fun in fundraising!

And if you'd like to know even more about Pro, next month we'll be chatting with Services Software Engineer Chris Aquino about our upcoming products. Chris, who most recently has been working on Assist, is both incredibly knowledgeable and a great person to chat with. We think you'll enjoythe upcoming Community Office Hours as much as we do.

April Office Hours: Thunderbird and MZLA

The beginning is always a very good place to start. We always love hearing Ryan recount Thunderbird's history, and we hope you do as well. As one of the key figures in bringing Thunderbird back from the ashes, Ryan is ideal to discuss how Thunderbird landed at MZLA, its new home since 2020. We also appreciate his perspective on our relationship to (and how we differ from) the Mozilla Foundation and Corporation. And as Thunderbird's community governance model is both one of its biggest strengths and a significant part of its comeback, Ryan has some valuable insights on our working relationship.

Thunderbird's future, however, is just as exciting a story as how we got here. Ryan gives us a unique look into some of our recent moves, from the decision to develop mobile apps to the recent move into our own email service, Thundermail, and the Thunderbird Pro suite of productivity apps. From barely surviving, we're glad to see all the ways in which Thunderbird and its community are thriving.

Watch, Read, and Get Involved

The entire interview with Ryan is below, on YouTube and Peertube. There's a lot of references in the interview, which we've handily provided below. We hope you're enjoying these looks into what we're doing at Thunderbird as much as we're enjoying making them, and we'll see you next month!

VIDEO (Also on Peertube):

Resources

• The untold history of Thunderbird: https://blog.thunderbird.net/2023/11/the-untold-history-of-thunderbird/
• The Mozilla Foundation: https://wiki.mozilla.org/Foundation
• Thunderbird's New Home at MZLA: https://blog.thunderbird.net/2020/01/thunderbirds-new-home/
• Community Office Hours with the Thunderbird Council: https://blog.thunderbird.net/2024/09/video-learn-about-the-thunderbird-council/
• The Mozilla Manifesto: https://www.mozilla.org/about/manifesto/
• Thundermail and Thunderbird Pro Announcement: https://blog.thunderbird.net/2025/04/thundermail-and-thunderbird-pro-services/
• Get Involved: https://www.thunderbird.net/participate/

The post VIDEO: Talking MZLA with Ryan Sipes appeared first on The Thunderbird Blog.

20 May 2025 1:05pm GMT

Hi folks,

I'm so excited to share that Flavius Floare joined our team recently as a Technical Writer. He's working alongside with Dayani to handle the Knowledge Base articles. Here's a bit more from Flavius himself:

Hi, everyone. My name is Flavius, and I'm joining the SUMO team as the new Technical Writer. I'm really excited to be here and look forward to collaborating with you. My goal is to be as helpful as possible, so feel free to reach out to me with suggestions or feedback.

Please join me to welcome Flavius into the team. He will also join our community call this week, so please make sure to join us tomorrow to say hi to him!

20 May 2025 8:22am GMT

Time for some horseshoe theory. Right-wing surveillance oligarchy has looped all the way back around to left-wing central economic planning.

Cory Doctorow sums up some recent news from Meta, in Pluralistic: Mark Zuckerberg announces mind-control ray (again). Zuck has finally described how he's going to turn AI's terrible economics around: he's going to ask AI to design his advertisers' campaigns, and these will be so devastatingly effective that advertisers will pay a huge premium to advertise on Meta.

Or, as Nilay Patel at The Verge put it, Mark Zuckerberg just declared war on the entire advertising industry. What Mark is describing here is a vision where a client comes to Meta and says I want customers for my product, and Meta does everything else. It generates photos and videos of those products using AI, writes copy about those products with AI, assembles that into an infinite number of ads with AI, targets those ads to all the people on its platforms with AI, measures which ads perform best and iterates on them with AI, and then has those customers buy the actual products on its platforms using its systems.

But the mind-control ray story, if true, would affect more companies, and functions within companies, than just advertising. Myles Younger writes, Zuck Says AI Will Make Advertising So Good Its Share of GDP Will Grow. Is That Really Possible? In the Meta version of the future, somehow the advertising share of the economy grows to include media, sales, and customer service. And a business that wants to sell a product or service would be able to change the number of units sold with one setting-the amount of money sent to Meta. That means the marketing department within the business can also be dramatically reduced. Or do you even need a marketing department when the one decision it has to make is how much money to send to Meta to move how many units? That could be handled as part of some other job.

TheZvi, in Zuckerberg's Dystopian AI Vision, writes,

When asked what he wants to use AI for, Zuckerberg's primary answer is advertising, in particular an ultimate black box where you ask for a business outcome and the AI does what it takes to make that outcome happen. I leave all the do not want and misalignment maximalist goal out of what you are literally calling a black box, film at 11 if you need to watch it again and general dystopian nightmare details as an exercise to the reader.

Such rightsizing, much futuristic! But wait a minute, this has been done. Centrally planned economies are already a thing, and have had well-known challenges for a while. On paper, the central planers decide up front how much of each product or service will be produced and consumed, but in reality the system ends up with everyone faking their numbers and gaming the system. For surveillance capitalism, that's already happening. A majority of US teens have lost trust in Big Tech, and advertisers are starting to walk away from platforms' AI solutions that once promised them everything. The top-down AI-driven social media story is less of a nightmare and more just more slop.

Related

Antitrust Policy for the Conservative by FTC Commissioner Mark R. Meador. (This is basically a good memo but is not going to have much impact in a political environment where a powerful monopoly can avoid government action by showing up at Mar-A-Lago to invest in a memecoin or settle a lawsuit. If we get to the point where there is a reasonably powerful honest conservative movement in the USA, then Meador's work will be useful, probably with not too many updates.)

Bonus links

Even a Broken Clock Can Lower Drug Prices by Joan Westenberg. The CBO has repeatedly found that negotiated drug pricing-including international benchmarking-can save significant amounts of public money.

Crypto Is Still for Criming by Paul Krugman. (Will cryptocurrencies go mainstream, or will they be stuck as just a crime thing? Turns out the answer is both because crime is going mainstream.)

The AI Slop Presidency by Matthew Gault. (This kind of thing is a good reason to avoid generative AI header images in blog posts. The AI look has become the signature style of the pro-oligarch, pro-surveillance side. This is particularly obvious on LinkedIn. An AI-look image tends to mean a growth hacking or pro-Big Tech post, while pro-human-rights or pro-decentralization posters tend to use original graphics or stock photos.)

Monopoly Round-Up: China Is Not Why America Is Sputtering by Matt Stoller. Simply put, modern American law is oriented towards ensuring very high returns on capital to benefit Wall Street and hinder the ability to make things. (fwiw, surveillance capitalism is probably part of the problem too. Creepy negative-sum games to move more units of existing products have higher and more predictable ROI than product innovation does.)

Industry groups are not happy about the imminent demise of Energy Star by Marianne Lavelle The nonprofit Alliance to Save Energy has estimated that the Energy Star program costs the government about $32 million per year, while saving families more than $40 billion in annual energy costs.

The Mozilla Firefox New Terms of Use Disaster: What Actually Happened? by Youssuff Quips. It is clear is that Mozilla wants to be able to unambiguously claim to regulators that people agreed to have their data sold - they want that permission to be persistent, and they want it to be modifiable in perpetuity. That changes what Firefox has been, and the Firefox I loved is gone. (For what it's worth I don't think it's as bad as all that. In a seemingly never-ending quest to get extra income that's not tied to the Google search deal, Mozilla management has done a variety of stupid shit but they always learn from it and move on. They'll drop their risky adfraud in the browser thing too at some point. More: why privacy-enhancing advertising technologies failed)

18 May 2025 12:00am GMT

At Mozilla, we consider security to be a paramount aspect of the web. This is why not only does Firefox have a long running bug bounty program but also mature release management and security engineering practices. These practices combined with well-trained and talented Firefox teams are also the reason why we respond to security bugs as quickly as we do. This week at the security hacking competition pwn2own, security researchers demonstrated two new content-process exploits against Firefox. Neither of the attacks managed to break out of our sandbox, which is required to gain control over the user's system.

Out of abundance of caution, we just released new Firefox versions in response to these attacks - all within the same day of the second exploit announcement. The updated versions are Firefox 138.0.4, Firefox ESR 128.10.1, Firefox ESR 115.23.1 and Firefox for Android. Despite the limited impact of these attacks, all users and administrators are advised to update Firefox as soon as possible.

Just last year at the same security event, we responded to an exploitable security bug within 21 hours, for which we earned an award as the fastest to patch. But this year was special. This year, two security researchers signed up to attack Firefox at pwn2own. We continued the same rapid security response this year too.

Background

Pwn2Own is an annual computer hacking contest where participants aim to find security vulnerabilities in major software such as browsers. This year, the event was held in Berlin, Germany, and a lot of popular software was listed as potential targets for security research. As part of the event preparation, we were informed that Firefox was also listed as a target. But it took until the day before the event when we learned that not just one but two groups signed up to demonstrate their work.

Typically, people attacking a browser require a multi-step exploit. At first, they need to compromise the web browser tab to gain limited control of the user's system. But due to Firefox's robust security architecture, another bug (a sandbox escape) is required to break out of the current tab and gain wider system access. Unlike prior years, neither participating group was able to escape our sandbox this year. We have verbal confirmation that this is attributed to the recent architectural improvements to our Firefox sandbox which have neutered a wide range of such attacks. This continues to build confidence in Firefox's strong security posture.

To review and fix the reported exploits a diverse team of people from all across the world and in various roles (engineering, QA, release management, security and many more) rushed to work. We tested and released a new version of Firefox for all of our supported platforms, operating systems, and configurations with rapid speed.

Our work does not end here. We continue to use opportunities like this to improve our incident response. We will also continue to study the reports to identify new hardening features and security improvements to keep all of our Firefox users across the globe protected.

Related Resources

If you're interested in learning more about Mozilla's security initiatives or Firefox security, here are some resources to help you get started:

Mozilla Security
Mozilla Security Blog
Bug Bounty Program

Furthermore, if you want to kickstart your own security research in Firefox, we invite you to follow our deeply technical blog at Attack & Defense - Firefox Security Internals for Engineers, Researchers, and Bounty Hunters .

The post Firefox Security Response to pwn2own 2025 appeared first on Mozilla Security Blog.

17 May 2025 9:17pm GMT

Previously: PET projects or real privacy?

From recent news: Google is reportedly wrapping up work on in-browser privacy-enhancing advertising features. Instead, they're keeping third-party cookies and even encouraging going back to older user tracking methods like fingerprinting.

Google's Privacy Sandbox projects were their own special case, and it certainly looks possible that their continued struggles were mostly because of trying to replicate a bunch of anticompetitive tricks from Google's old ad stack inside the browser. Privacy-enhancing technologies are hard enough without adding in all the anticompetitive stuff too. But by now it looks more and more clearn that it wasn't just a problem with Privacy Sandbox trying to do too much. Most of the hard problems of PETs for advertising are more general. Although in-browser advertising features persist, for practical purposes they're already dead code. Right now we're in a period of adjustment, and some of the interesting protocols and code will probably end up being adaptable to other areas, just not advertising.

While PETs for advertising were a bad idea for a lot of reasons, all I'm going to list here are the big problems they couldn't get over.

PETs without consent didn't work. The original plan in the early days of Privacy Sandbox was to deploy to users with a simple Got it! dialog. That didn't work. Regulators in the UK wrote (PDF),

We believe that further user research and testing of the dialogue box, using robust methodologies and a representative sample of users, is critical to resolve these concerns. Also, it is not clear if users will be prompted to revisit their choices, and the frequency of this.

In the real world, PETs will be required to get the same kind of consent that other adtech is. Buried in a clickwrap agreement isn't going to pass inspection. PETs are catching the same kinds of complaints over lack of consent as any other adtech. And getting consent will be hard, because…

Users are about as creeped out by PETs as by other kinds of tracking. Jereth et al. find that perceived privacy violations for a browser-based system that does not target people individually are similar to the perceived violations for conventional third-party cookies. Co-author Klaus M. Miller presented the research at FTC PrivacyCon (PDF):

So keeping your data safer on your device seems to help in terms of consumer perceptions, but it doesn't make any difference whether the firm is targeting the consumer at the individual or group level in the perceived privacy perceptions.

Martin et al. find substantial differences between the privacy that users expect and the privacy (ish) features of PETs. In fact, users might actually feel better about old-fashioned web tracking than about the PET kind.

In sum, the use of inferences rather than raw data collected by a primary site is not a privacy solution for users. In most instances, respondents judged the use of raw data such as browsing history, location, search terms, and engagement data to be statistically the same as using inferences based on that same data. Further, for improving services across contexts, consumers judged the use of raw data as more appropriate compared to using inferences based on that same raw data.

PET developers tried to come up with solutions that would work as a default for all web users, but that's just not realistic considering that the research consistently shows that people are different. About 30% of people prefer cross-context personalized advertising, 30% really don't want it, and for 40% it depends how you ask. PETs are too lossy for people who want cross-context personalized ads and too creepy for people who don't. (In addition to this published research, there is also in-house research at a variety of companies, including at some of the companies that had been most enthusiastically promoting PETs.)

PETs never had a credible anti-fraud story. One of the immutable laws of adtech is that you can take any adtech term and put fraud after it, and it's a thing. PETs are no exception.

• Anti-fraud lesson of the 1990s: never trust the client

• Anti-fraud lesson of the 2000s: use machine learning on lots of data to spot patterns of fraud

• PETs: trust the client to obfuscate the data that your ML would have needed to spot fraud. (how was this even supposed to work?)

If PET developers could count on an overwhelming percentage of users to participate in PETs honestly, then there might not be a problem. A few people would try fraud but they would get lost in the noise created by PET math. But active spoofing of PETs, if they ever caught on, would have the same triad of user motivations that open-source software does: it feels like the right thing to do (since the PETs come from the same big evil companies that people are already protesting), you would have been able to make money doing it, and it's fun. Any actual data collected by PETs would have been drowned out by fake data generated either on principle, for money, or for lulz.

PETs didn't change the market. The original, optimistic pitch for PETs was that they would displace other surveillance advertising technologies in marketing budgets and VC portfolios. That didn't happen. The five-year publicity frenzy around Google's Privacy Sandbox might actually have had the opposite effect. The project's limitations, well understood by adtech developers and later summarized in an IAB Tech Lab report, encouraged more investment in the kinds of non-cookie, non-PET tracking methods that Mozilla calls unintended identification techniques.

Just as we didn't see articles written for end users recommending PETs as a privacy tip-because the privacy they provide isn't the privacy that users want-we also didn't see anyone in the advertising business saying they were cutting back on other tracking to do PETs instead. Even Google, which was the biggest proponent of PETs for a while, lifted its 2019 ban on fingerprinting as Privacy Sandbox failed to take off.

PETs would create hard-to-predict antitrust issues. If users are still creeped out by PETs, and advertisers find PET features too limiting, then the designers of PETs must be splitting the difference and doing something right, right? Well, no. PETs aren't just about users vs. advertisers, they're about large-scale platforms vs. smaller companies. PETs introduce noise and obfuscation, to make data interpretation only practical above a certain data set size-for a few large companies, or one. Designers of PETs can tune the level of obfuscation introduced to make their systems practical for any desired minimum size of company.

The math is complicated enough, and competition regulators have enough on their to-do lists, to make it hard to tell when PET competition issues will come up. But they will eventually.

PETs would have made privacy enforcement harder. This year's most promising development in privacy news in the USA is the Honda case. Companies that had been getting by with non-compliant opt outs and Right to Know forms are finally fixing their stuff. CCPA+CPRA are progressing to their (intended?) true form, as a kind of RCRA for PII. Back in the 1980s, companies that had a bunch of random hazardous materials around decided that it was easier to safely get rid of them than to deal with RCRA paperwork, and something similar is happening for surveillance marketing today.

PETs would have interfered with this trend by making it harder for researchers to spot problematic data usage practices, and helping algorithmic discrimination to persist.

Conclusion: learning from the rise and fall of PETs. In most cases, there should be little or no shame in chasing a software fad. At their best, hyped-up technologies can open up a stale industry to new people by way of hiring frenzies, and create change that would have been harder to do otherwise.all right, the cryptocurrency and AI bubbles might be an exception because of the environmental impact, but the PET fad wasn't that big. Having been into last year's trendy thing can feel a little embarrassing, but really, a trend-driven industry has two advantages.

• A trend can give you a face-saving way to dig up and re-try a previous good project idea that didn't get funded at the time. (this could still happen with prediction markets)

• Investing in a trend can be an excuse to fix your dependencies (I once got to work on fixing software builds, making RPMs, and automating a GPL corresponding source release, because Docker containers were a big thing at the time) and produce software that's useful later (PDF-to-structured-text tools, so hot right now)

In the case of PETs there probably should have been more user research earlier, to understand that the default PETs without consent idea wouldn't have worked and save development time, but that's a deeper problem with the relative influence of people who write code and people who do user research within companies, and not just a PET thing.

The development work that went into PETs wasn't wasted, because PETs are still really promising in other areas, just not advertising. For example, energy markets could benefit from being able to predict demand without revealing when individual utility customers are at home or away. PETs are already valuable for software telemetry-for example, revealing that a certain web page crashed the browser without telling the browser maintainer which users visited which pages-and could end up being more widely used for other products, where the manufacturer and user have a shared interest in facilitating maintenance and improving quality. But advertising is different, mostly because it's unavoidably adversarial. Every market has honest and dishonest advertisers, and advertising's main job is to build reputation by doing something that's practical for a legit advertiser to do and as difficult as possible for a dishonest advertiser. As the shift to a low-trust economy continues, and more software companies see their reputations continue to slide, real ad reform solutions will need to come from somewhere else. More: Sunday Internet optimism

Bonus links

Time To Get Serious by Brian Jacobs. (A must-follow RSS feed for anyone interested in #adReform. We have spent decades building up thoughtful measurement systems through collaboration and compromise. And yet we are prepared to believe what suits the largest vendors without question and without any hint of criticism. Indeed, we build what suits them into our thinking, with scant regard as to whether it fits with what we know. We are in a crisis in large part of our own making.

What Do We Do With All This Consumer Rage? by Anne Helen Petersen. As consumers, the globalized marketplace (with a noted assist from venture capital) has taught us to expect and demand levels of seamless service at low prices. But the companies that provide seamless service at low prices often provide lower-quality products and service. Or, now that VC-backed enterprises like Uber and DoorDash have ceased to subsidize the on-demand lifestyle, they provide lower quality products or experiences at higher prices.

The anatomy of Anatomy of Humbug, ten years on by Paul Feldwick. The text of Anatomy emerged (over many years) as my attempt to articulate the unspoken assumptions that underlay the way we made advertising, in the thirty years I worked at a successful agency. It seemed to me that the theories we all uncritically believed fitted rather badly with the kind of advertising we produced, and, more worryingly, with the kind of advertising that we increasingly knew worked best. We agonised over single-minded propositions and consumer benefits; then we created singing polar bears, comic Yorkshiremen, and laughing aliens, and the public loved them. Something didn't quite make sense.

Rage of the Oligarchs Naomi Klein: 'What They Want Is Absolutely Everything (I'm more worried about evil oligarchs who know how to hire and use a good PR team than I am about the guys who are willing to be the main character on Twitter or whatever, but maybe that's just me)

Costco's Kirkland brand is bigger than Nike-and it's about to get even bigger by Rob Walker. Like all private labels, it competes with brand-name consumer products largely on price-an obvious advantage in belt-tightening times. But Kirkland is also the rare private label that's developed its own powerful, and surprisingly elastic, brand identity. (Kirkland might be a success story for brand building by investing in measurable improvements. There is a content niche for posts like What to Buy from Costco & What to Avoid, which means an opportunity for Costco in offering low-overhead bargains and leaving it to independent content creators to get the word out.)

17 May 2025 12:00am GMT

The remedies phase of the U.S. v. Google LLC search case wrapped up last week. As the Court weighs how to restore competition in the search market, Mozilla is asking it to seriously consider the unintended consequences of some of the proposed remedies, which, if adopted, could harm browser competition, weaken user choice and undermine the open web.

Mozilla has long supported competition interventions in tech markets. Recent highlights include campaigns to pass the American Innovation and Choice Online Act, reports detailing the operating system power wielded by Apple, Google and Microsoft (among others), and detailed research into remedy design on Android and Windows to support the enforcement of EU Digital Markets Act.

In relation to the Google Search case, our message is simple: search competition must improve, but this can be done without harming browser competition.

As the maker of Firefox and Gecko, the only major browser engine left competing with Big Tech, we know what it means to fight for privacy, innovation and real choice online. That is why we have filed an amicus brief, urging the Court not to prohibit Google from making search revenue payments to independent browsers (i.e., browser developers that do not provide desktop or mobile devices or operating systems). Such a ban would destroy valuable competition in browsers and browser engines by crippling their ability to innovate and serve users in these fundamentally important areas. As explained in our amicus brief:

• Mozilla has spent over two decades fighting for an open and healthy internet ecosystem. Through developing open source products, advancing better web standards, and advocating for competition and user choice, Mozilla has tangibly improved privacy, security, and choice online. Much of this work is funded by Firefox's search revenue and implemented in Gecko-the last remaining cross-platform browser engine challenger to Google's Chromium.
  
• Firefox offers unparalleled search choice. Mozilla has tried alternatives (like Yahoo! In 2014-2017) and knows that Google Search is the preferred option of Firefox users. While Google provides the default search engine, Firefox offers multiple, dynamic ways for people to change their search engine.
  
• Banning search payments to independent browsers would threaten the survival of Firefox and Gecko. The Court previously recognized that Mozilla depends on revenue share payments from Google. This was underlined by testimony the Court heard from Eric Muhlheim, Mozilla's CFO. Eric explained how complex and expensive it is to maintain Firefox and Gecko and why switching to another search provider would result in a "precipitous" decline in revenue. Undermining Mozilla's ability to fund this work risks handing control of the web to Apple and Google and further entrenching the power of the largest tech companies.
  
• Banning search payments to independent browsers would not improve search competition. Independent browsers play an important role in the ecosystem, far beyond their market share. The Court previously found that they account for 2.3% of US search traffic covered by Google's contracts. As a result, the DOJ's expert calculated that banning payments to independent browsers would shift only 0.6% of Google's current market share to another search engine. This is not a prize worth destroying browser competition for.

At Mozilla, we believe that a more tailored approach to the remedies is absolutely critical. The Court should permit independent browsers like Firefox to continue to receive revenue share payments from Google to avoid further harm to competition. This would be a consistent approach with other jurisdictions that have sought to improve search competition and would not undermine the effectiveness of any remedies the court orders.

To learn more about Mozilla's position and why we're urging the Court to carefully consider the unintended consequences of these proposed remedies, read our full amicus brief.

The post The future of the web depends on getting this right appeared first on The Mozilla Blog.

16 May 2025 6:02pm GMT

Today is the 10th anniversary of Rust's 1.0 release. Pretty wild. As part of RustWeek there was a fantastic celebration and I had the honor of giving some remarks, both as a long-time project member but also as representing Amazon as a sponsor. I decided to post those remarks here on the blog.

"It's really quite amazing to see how far Rust has come. If I can take a moment to put on my sponsor hat, I've been at Amazon since 2021 now and I have to say, it's been really cool to see the impact that Rust is having there up close and personal.

"At this point, if you use an AWS service, you are almost certainly using something built in Rust. And how many of you watch videos on PrimeVideo? You're watching videos on a Rust client, compiled to WebAssembly, and shipped to your device.

"And of course it's not just Amazon, it seems like all the time I'm finding out about this or that surprising place that Rust is being used. Just yesterday I really enjoyed hearing about how Rust was being used to build out the software for tabulating votes in the Netherlands elections. Love it.

"On Tuesday, Matthias Endler and I did this live podcast recording. He asked me a question that has been rattling in my brain ever since, which was, 'What was it like to work with Graydon?'

"For those who don't know, Graydon Hoare is of course Rust's legendary founder. He was also the creator of Monotone, which, along with systems like Git and Mercurial, was one of the crop of distributed source control systems that flowered in the early 2000s. So defintely someone who has had an impact over the years.

"Anyway, I was thinking that, of all the things Graydon did, by far the most impactful one is that he articulated the right visions. And really, that's the most important thing you can ask of a leader, that they set the right north star. For Rust, of course, I mean first and foremost the goal of creating 'a systems programming language that won't eat your laundry'.

"The specifics of Rust have changed a LOT over the years, but the GOAL has stayed exactly the same. We wanted to replicate that productive, awesome feeling you get when using a language like Ocaml - but be able to build things like web browsers and kernels. 'Yes, we can have nice things', is how I often think of it. I like that saying also because I think it captures something else about Rust, which is trying to defy the 'common wisdom' about what the tradeoffs have to be.

"But there's another North Star that I'm grateful to Graydon for. From the beginning, he recognized the importance of building the right culture around the language, one committed to 'providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, disability, nationality, or other similar characteristic', one where being 'kind and courteous' was prioritized, and one that recognized 'there is seldom a right answer' - that 'people have differences of opinion' and that 'every design or implementation choice carries a trade-off'.

"Some of you will probably have recognized that all of these phrases are taken straight from Rust's Code of Conduct which, to my knowledge, was written by Graydon. I've always liked it because it covers not only treating people in a respectful way - something which really ought to be table stakes for any group, in my opinion - but also things more specific to a software project, like the recognition of design trade-offs.

"Anyway, so thanks Graydon, for giving Rust a solid set of north stars to live up to. Not to mention for the fn keyword. Raise your glass!

"For myself, a big part of what drew me to Rust was the chance to work in a truly open-source fashion. I had done a bit of open source contribution - I wrote an extension to the ASM bytecode library, I worked some on PyPy, a really cool Python compiler - and I loved that feeling of collaboration.

"I think at this point I've come to see both the pros and cons of open source - and I can say for certain that Rust would never be the language it is if it had been built in a closed source fashion. Our North Star may not have changed but oh my gosh the path we took to get there has changed a LOT. So many of the great ideas in Rust came not from the core team but from users hitting limits, or from one-off suggestions on IRC or Discord or Zulip or whatever chat forum we were using at that particular time.

"I wanted to sit down and try to cite a bunch of examples of influential people but I quickly found the list was getting ridiculously long - do we go all the way back, like the way Brian Anderson built out the #[test] infrastructure as a kind of quick hack, but one that lasts to this day? Do we cite folks like Sophia Turner and Esteban Kuber's work on error messages? Or do we look at the many people stretching the definition of what Rust is today… the reality is, once you start, you just can't stop.

"So instead I want to share what I consider to be an amusing story, one that is very Rust somehow. Some of you may have heard that in 2024 the ACM, the major academic organization for computer science, awarded their SIGPLAN Software Award to Rust. A big honor, to be sure. But it caused us a bit of a problem - what names should be on there? One of the organizers emailed me, Graydon, and a few other long-time contributors to ask us our opinion. And what do you think happened? Of course, we couldn't decide. We kept coming up with different sets of people, some of them absurdly large - like thousands of names - others absurdly short, like none at all. Eventually we kicked it over to the Rust Leadership Council to decide. Thankfully they came up with a decent list somehow.

"In any case, I just felt that was the most Rust of all problems: having great success but not being able to decide who should take credit. The reality is there is no perfect list - every single person who got named on that award richly deserves it, but so do a bunch of people who aren't on the list. That's why the list ends with All Rust Contributors, Past and Present - and so a big shout out to everyone involved, covering the compiler, the tooling, cargo, rustfmt, clippy, core libraries, and of course organizational work. On that note, hats off to Mara, Erik Jonkers, and the RustNL team that put on this great event. You all are what makes Rust what it is.

"Speaking for myself, I think Rust's penchant to re-imagine itself, while staying true to that original north star, is the thing I love the most. 'Stability without stagnation' is our most important value. The way I see it, as soon as a language stops evolving, it starts to die. Myself, I look forward to Rust getting to a ripe old age, interoperating with its newer siblings and its older aunts and uncles, part of the 'cool kids club' of widely used programming languages for years to come. And hey, maybe we'll be the cool older relative some day, the one who works in a bank but, when you talk to them, you find out they were a rock-and-roll star back in the day.

"But I get ahead of myself. Before Rust can get there, I still think we've some work to do. And on that note I want to say one other thing - for those of us who work on Rust itself, we spend a lot of time looking at the things that are wrong - the bugs that haven't been fixed, the parts of Rust that feel unergonomic and awkward, the RFC threads that seem to just keep going and going, whatever it is. Sometimes it feels like that's ALL Rust is - a stream of problems and things not working right.

"I've found there's really only one antidote, which is getting out and talking to Rust users - and conferences are one of the best ways to do that. That's when you realize that Rust really is something special. So I do want to take a moment to thank all of you Rust users who are here today. It's really awesome to see the things you all are building with Rust and to remember that, in the end, this is what it's all about: empowering people to build, and rebuild, the foundational software we use every day. Or just to 'hack without fear', as Felix Klock legendarily put it.

"So yeah, to hacking!"

15 May 2025 9:46pm GMT

Here is an update of what Thunderbird's mobile community has been up to in April 2025. With a new team member, we're getting Thunderbird for iOS out in the open and continuing to work on release feedback from Thunderbird for Android.

The Team is Growing

Last month we introduced Todd and Ashley to the MZLA mobile team, and now we have another new face in the team! Rafael Tonholo joins us as a Senior Android Engineer to focus on Thunderbird for Android. He also has much experience with Kotlin Multiplatform, which will be beneficial for Thunderbird for iOS as well.

Thunderbird for iOS

We've published the initial repository of Thunderbird for iOS! The application doesn't really do a lot right this moment, since we intend to work very incrementally and start in the open. You'll see a familiar welcome screen, slightly nicer than Thunderbird for Android and have the opportunity to make a financial contribution.

Testflight Distribution

We're planning to distribute Thunderbird for iOS through TestFlight. To support that, we've set up an Apple Developer account and completed the required verification steps.

Unlike Android, where we maintain separate release and beta versions, the iOS App Store will have a single "Thunderbird" app. Apple prefers not to list beta versions as separate apps, and their review process tends to be stricter. Once the main app is published, we'll be able to use TestFlight to offer a beta channel.

Before the App Store listing goes live, we'll use TestFlight to distribute our builds. Apple provides an internal TestFlight option that doesn't require a review, but it only works if testers have access to the developer account. That makes it unsuitable for community testing.

Initial Features for the Public Testflight Alpha

To share a public TestFlight link, we need to pass an initial App Store review. Apple expects apps to meet a minimum bar for functionality, so we can't publish something like a simple welcome screen. Our goal for the first public TestFlight build is to support manual account setup and display emails in the inbox. Here are the specifics:

• Initial account setup will be manual with hostname/username/password.
• There will be a simple message list that will only show the INBOX folder messages, with a sender, subject, and maybe 2-3 preview lines.
• You'll have the opportunity to pull to refresh your inbox.

That is certainly not what you'd call a fully functional email client, but it could qualify for bare minimum functionality required for the Apple review. We have more details and a feature comparison in this document.

In other exciting news, we're going to build Thunderbird for iOS with JMAP support first and foremost. While support on the email provider side is limited, we start with a modern email stack. This will allow us to build towards some of the features that email from the late 80's was missing. We'll be designing the code architecture in a way that adding IMAP support is very simple, so it will ideally follow soon after.

iOS Release Engineering and Localization

We've also gone through a few initial conversations on what the release workflow might look like. We're currently deciding between:

• GitHub Actions with Upload Actions (Pro: very open, re-use of some work on the Thunderbird for Android side. Con: Custom work, not many well-supported upload actions)
• GitHub Actions with Fastlane (Pro: very open, well-supported, uses the same listing metadata structure we already have on Android. Con: Ruby as yet another language, no prior releng work)
• Xcode Cloud (Pro: built in to Xcode, easy to configure, we'll probably get by with the free tier for quite some time. Con: Not very open, increasing build cost)
• Bitrise (Pro: Easy to configure, used by Firefox for iOS, we'll get some support from Mozilla on this. Con: Can be pricy, not very open)

For now, our release process is pressing a button every once in a while. Xcode makes this very easy, which gives the release operations more time to plan a solution.

For localization, we're aiming to use Weblate, just as Thunderbird for Android. The strings will mostly be the same, so we don't need to ask our localizers to do double work.

Thunderbird for Android

We're still focusing on release feedback by working on the drawer and looking to improve stability. April has very much been focused on onboarding the new team. I'll keep the updates in this section a bit more brief, as we have less to explore and more to fix

• We've accepted a new ADR to change the shared modules package from app.k9mail and com.fsck to net.thunderbird. We'll be doing this gradually when migrating over legacy code.
• Ashley has fixed a few keyboard accessibility issues to get started. She has also resolved a crash related to duplicate folder ids in the drawer. Her next projects are improving our sync debug tooling and other projects to resolve stability issues in retrieving emails.
• Clément Rivière added initial support for showing hierarchical folders. The work is behind a feature flag for now, as we need to do some additional refactoring and crash fixes before we can release it. You can however try it out on the beta channel.
• Fishkin removed a deprecated progress indicator, which provides slightly better support for Android watches.
• Rafael fixed an issue related to Outlook/Microsoft accounts. If you have received the "Authentication Unsuccessful" message in the past, please try again on our beta channel.
• Shamim continues on his path to refactor and move over some of our legacy code into the new modular structure. He also added support to attach files from the camera, and has resolved an issue in the drawer where the wrong folder was selected.
• Timur Erofeev added support for algorithmic darkening where supported. This makes dark mode work better for a wider range of emails, following the same method that is used on web pages.
• Wolf has been working diligently to improve our settings and drawer infrastructure. He took a number of much needed detours to refactor legacy code, which will make future work easier. Most notably, we have a new settings system based on Jetpack Compose, where we will eventually migrate all the settings screens to.

That's a wrap for April! Let us know if you have comments, or see opportunities to help out. See you soon!

The post Thunderbird for Mobile April 2025 Progress Report appeared first on The Thunderbird Blog.

15 May 2025 2:26pm GMT

Live from the 10 Years of Rust celebration in Utrecht, Netherlands, the Rust team is happy to announce a new version of Rust, 1.87.0!

Today's release day happens to fall exactly on the 10 year anniversary of Rust 1.0!

Thank you to the myriad contributors who have worked on Rust, past and present. Here's to many more decades of Rust! 🎉

---

As usual, the new version includes all the changes that have been part of the beta version in the past six weeks, following the consistent regular release cycle that we have followed since Rust 1.0.

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

$ rustup update stable

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

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

What's in 1.87.0 stable

Anonymous pipes

1.87 adds access to anonymous pipes to the standard library. This includes integration with std::process::Command's input/output methods. For example, joining the stdout and stderr streams into one is now relatively straightforward, as shown below, while it used to require either extra threads or platform-specific functions.

use std::process::Command;
use std::io::Read;

let (mut recv, send) = std::io::pipe()?;

let mut command = Command::new("path/to/bin")
    // Both stdout and stderr will write to the same pipe, combining the two.
    .stdout(send.try_clone()?)
    .stderr(send)
    .spawn()?;

let mut output = Vec::new();
recv.read_to_end(&mut output)?;

// It's important that we read from the pipe before the process exits, to avoid
// filling the OS buffers if the program emits too much output.
assert!(command.wait()?.success());

Safe architecture intrinsics

Most std::arch intrinsics that are unsafe only due to requiring target features to be enabled are now callable in safe code that has those features enabled. For example, the following toy program which implements summing an array using manual intrinsics can now use safe code for the core loop.

#![forbid(unsafe_op_in_unsafe_fn)]

use std::arch::x86_64::*;

fn sum(slice: &[u32]) -> u32 {
    #[cfg(target_arch = "x86_64")]
    {
        if is_x86_feature_detected!("avx2") {
            // SAFETY: We have detected the feature is enabled at runtime,
            // so it's safe to call this function.
            return unsafe { sum_avx2(slice) };
        }
    }

    slice.iter().sum()
}

#[target_feature(enable = "avx2")]
#[cfg(target_arch = "x86_64")]
fn sum_avx2(slice: &[u32]) -> u32 {
    // SAFETY: __m256i and u32 have the same validity.
    let (prefix, middle, tail) = unsafe { slice.align_to::<__m256i>() };
    
    let mut sum = prefix.iter().sum::<u32>();
    sum += tail.iter().sum::<u32>();
    
    // Core loop is now fully safe code in 1.87, because the intrinsics require
    // matching target features (avx2) to the function definition.
    let mut base = _mm256_setzero_si256();
    for e in middle.iter() {
        base = _mm256_add_epi32(base, *e);
    }
    
    // SAFETY: __m256i and u32 have the same validity.
    let base: [u32; 8] = unsafe { std::mem::transmute(base) };
    sum += base.iter().sum::<u32>();
    
    sum
}

asm! jumps to Rust code

Inline assembly (asm!) can now jump to labeled blocks within Rust code. This enables more flexible low-level programming, such as implementing optimized control flow in OS kernels or interacting with hardware more efficiently.

• The asm! macro now supports a label operand, which acts as a jump target.
• The label must be a block expression with a return type of () or !.
• The block executes when jumped to, and execution continues after the asm! block.
• Using output and label operands in the same asm! invocation remains unstable.

unsafe {
    asm!(
        "jmp {}",
        label {
            println!("Jumped from asm!");
        }
    );
}

For more details, please consult the reference.

Precise capturing (+ use<...>) in impl Trait in trait definitions

This release stabilizes specifying the specific captured generic types and lifetimes in trait definitions using impl Trait return types. This allows using this feature in trait definitions, expanding on the stabilization for non-trait functions in 1.82.

Some example desugarings:

trait Foo {
    fn method<'a>(&'a self) -> impl Sized;
    
    // ... desugars to something like:
    type Implicit1<'a>: Sized;
    fn method_desugared<'a>(&'a self) -> Self::Implicit1<'a>;
    
    // ... whereas with precise capturing ...
    fn precise<'a>(&'a self) -> impl Sized + use<Self>;
    
    // ... desugars to something like:
    type Implicit2: Sized;
    fn precise_desugared<'a>(&'a self) -> Self::Implicit2;
}

Stabilized APIs

• Vec::extract_if
• vec::ExtractIf
• LinkedList::extract_if
• linked_list::ExtractIf
• <[T]>::split_off
• <[T]>::split_off_mut
• <[T]>::split_off_first
• <[T]>::split_off_first_mut
• <[T]>::split_off_last
• <[T]>::split_off_last_mut
• String::extend_from_within
• os_str::Display
• OsString::display
• OsStr::display
• io::pipe
• io::PipeReader
• io::PipeWriter
• impl From<PipeReader> for OwnedHandle
• impl From<PipeWriter> for OwnedHandle
• impl From<PipeReader> for Stdio
• impl From<PipeWriter> for Stdio
• impl From<PipeReader> for OwnedFd
• impl From<PipeWriter> for OwnedFd
• Box<MaybeUninit<T>>::write
• impl TryFrom<Vec<u8>> for String
• <*const T>::offset_from_unsigned
• <*const T>::byte_offset_from_unsigned
• <*mut T>::offset_from_unsigned
• <*mut T>::byte_offset_from_unsigned
• NonNull::offset_from_unsigned
• NonNull::byte_offset_from_unsigned
• <uN>::cast_signed
• NonZero::<uN>::cast_signed.
• <iN>::cast_unsigned.
• NonZero::<iN>::cast_unsigned.
• <uN>::is_multiple_of
• <uN>::unbounded_shl
• <uN>::unbounded_shr
• <iN>::unbounded_shl
• <iN>::unbounded_shr
• <iN>::midpoint
• <str>::from_utf8
• <str>::from_utf8_mut
• <str>::from_utf8_unchecked
• <str>::from_utf8_unchecked_mut

These previously stable APIs are now stable in const contexts:

• core::str::from_utf8_mut
• <[T]>::copy_from_slice
• SocketAddr::set_ip
• SocketAddr::set_port,
• SocketAddrV4::set_ip
• SocketAddrV4::set_port,
• SocketAddrV6::set_ip
• SocketAddrV6::set_port
• SocketAddrV6::set_flowinfo
• SocketAddrV6::set_scope_id
• char::is_digit
• char::is_whitespace
• <[[T; N]]>::as_flattened
• <[[T; N]]>::as_flattened_mut
• String::into_bytes
• String::as_str
• String::capacity
• String::as_bytes
• String::len
• String::is_empty
• String::as_mut_str
• String::as_mut_vec
• Vec::as_ptr
• Vec::as_slice
• Vec::capacity
• Vec::len
• Vec::is_empty
• Vec::as_mut_slice
• Vec::as_mut_ptr

i586-pc-windows-msvc target removal

The Tier 2 target i586-pc-windows-msvc has been removed. i586-pc-windows-msvc's difference to the much more popular Tier 1 target i686-pc-windows-msvc is that i586-pc-windows-msvc does not require SSE2 instruction support. But Windows 10, the minimum required OS version of all windows targets (except the win7 targets), requires SSE2 instructions itself.

All users currently targeting i586-pc-windows-msvc should migrate to i686-pc-windows-msvc.

You can check the Major Change Proposal for more information.

Other changes

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

Contributors to 1.87.0

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

15 May 2025 12:00am GMT

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

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing Google Summer of Code 2025 selected projects

Foundation

• 10 Years of Stable Rust: An Infrastructure Story

Newsletters

• This Month in Rust OSDev: April 2025 | Rust OSDev
• The Embedded Rustacean Issue #45

Project/Tooling Updates

• Avian Physics 0.3
• Two months in Servo: CSS nesting, Shadow DOM, Clipboard API, and more
• Cot v0.3: Even Lazier
• Streaming data analytics, Fluvio 0.17.3 release
• CGP v0.4 is Here: Unlocking Easier Debugging, Extensible Presets, and More
• Rama v0.2

Observations/Thoughts

• Bad Type Patterns - The Duplicate duck
• Rust nightly features you should watch out for
• Lock-Free Rust: How to Build a Rollercoaster While It's on Fire
• Simple & type-safe localization in Rust
• From Rust to AVR assembly: Dissecting a minimal blinky program
• Tarpaulins Week Of Speed
• Rustls Server-Side Performance
• Is Rust the Future of Programming?

Rust Walkthroughs

• Functional asynchronous Rust
• The Power of Compile-Time ECS Architecture in Rust
• [video] Build with Naz : Spinner animation, lock contention, Ctrl+C handling for TUI and CLI

Miscellaneous

• April 2025 Rust Jobs Report

Crate of the Week

This week's crate is brush, a bash compatible shell implemented completely in Rust.

Thanks to Josh Triplett for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

RFCs

Rust

Rustup

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.

Call for Participation; projects and speakers

CFP - Projects

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

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

• rama - add ffi/rama-rhai: support ability to use services and layers written in rhai
• rama - support akamai h2 passive fingerprint and expose in echo + fp services

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!

CFP - Events

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

• No Calls for papers or presentations were submitted this week.

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!

Updates from the Rust Project

397 pull requests were merged in the last week

Compiler

• async drop fix for async_drop_in_place<T> layout for unspecified T
• better error message for late/early lifetime param mismatch
• perf: make the assertion in Ident::new debug-only
• perf: merge typeck loop with static/const item eval loop

Library

• implement (part of) ACP 429: add DerefMut to Lazy[Cell/Lock]
• implement VecDeque::truncate_front()

Cargo

• network: use Retry-After header for HTTP 429 responses
• rustc: Don't panic on unknown bins
• add glob pattern support for known_hosts
• add support for -Zembed-metadata
• fix tracking issue template link
• make cargo script ignore workspaces

Rustdoc

• rustdoc-json: remove newlines from attributes
• ensure that temporary doctest folder is correctly removed even if doctests failed

Clippy

• clippy: item_name_repetitions: exclude enum variants with identical path components
• clippy: return_and_then: only lint returning expressions
• clippy: unwrap_used, expect_used: accept macro result as receiver
• clippy: add allow_unused config to missing_docs_in_private_items
• clippy: add new confusing_method_to_numeric_cast lint
• clippy: add new lint: cloned_ref_to_slice_refs
• clippy: fix ICE in missing_const_for_fn
• clippy: fix integer_division false negative for NonZero denominators
• clippy: fix manual_let_else false negative when diverges on simple enum variant
• clippy: fix unnecessary_unwrap emitted twice in closure
• clippy: fix diagnostic paths printed by dogfood test
• clippy: fix false negative for unnecessary_unwrap
• clippy: make let_with_type_underscore help message into a suggestion
• clippy: resolve through local re-exports in lookup_path

Rust-Analyzer

• fix postfix snippets duplicating derefs
• resolve doc path from parent module if outer comments exist on module
• still complete parentheses & method call arguments if there are existing parentheses, but they are after a newline

Rust Compiler Performance Triage

Lot of changes this week. Overall result is positive, with one large win in type check.

Triage done by @panstromek. Revision range: 62c5f58f..718ddf66

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.5%	[0.2%, 1.4%]	113
Regressions ❌ (secondary)	0.5%	[0.1%, 1.5%]	54
Improvements ✅ (primary)	-2.5%	[-22.5%, -0.3%]	45
Improvements ✅ (secondary)	-0.9%	[-2.3%, -0.2%]	10
All ❌✅ (primary)	-0.3%	[-22.5%, 1.4%]	158

Full report here

Approved RFCs

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

• No RFCs were approved this week.

Final Comment Period

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

Tracking Issues & PRs

Rust

• Tracking Issue for non_null_from_ref
• Add std::io::Seek instance for std::io::Take
• aarch64-softfloat: forbid enabling the neon target feature
• Stabilize the avx512 target features
• make std::intrinsics functions actually be intrinsics
• Error on recursive opaque ty in HIR typeck
• Remove i128 and u128 from improper_ctypes_definitions
• Guarantee behavior of transmuting Option::<T>::None subject to NPO
• Temporary lifetime extension through tuple struct and tuple variant constructors
• Stabilize tcp_quickack
• Change the desugaring of assert! for better error output
• Make well-formedness predicates no longer coinductive

No Items entered Final Comment Period this week for Cargo, Rust RFCs, Language Reference, Language Team or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• RFC: Extended Standard Library (ESL)

Upcoming Events

Rusty Events between 2025-05-14 - 2025-06-11 🦀

Virtual

• 2025-05-15 | Hybrid (Redmond, WA, US) | Seattle Rust User Group
  • May, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-05-15 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2025-05-15 | Virtual (Joint Meetup, Europe + Israel) | Rust Berlin + Rust Paris + London Rust Project Group + Rust Zürisee + Rust TLV + Rust Nürnberg + Rust Munich + Rust Aarhus + lunch.rs
  • 🦀 Celebrating 10 years of Rust 1.0 🦀
• 2025-05-15 | Virtual (Zürich, CH) | Rust Zürisee
  • 🦀 Celebrating 10 years of Rust 1.0 (co-event with berline.rs) 🦀
• 2025-05-18 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-05-19 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • Tauri: Cross-Platform desktop applications with Rust and web technologies
• 2025-05-20 | Hybrid (EU/UK) | Rust and C++ Dragons (former Cardiff)
  • Talk and Connect - Fullstack - with Goetz Markgraf and Ben Wishovich
• 2025-05-20 | Virtual (London, UK) | Women in Rust
  • Threading through lifetimes of borrowing - the Rust way
• 2025-05-20 | Virtual (Tel Aviv, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Rust at Work a conversation with Ran Reichman Co-Founder & CEO of Flarion
• 2025-05-20 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2025-05-21 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Linking
• 2025-05-22 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-05-22 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2025-05-25 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-05-27 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2025-05-27 | Virtual (Tel Aviv, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Rust at Work - conversation with Eli Shalom & Igal Tabachnik of Eureka Labs
• 2025-05-29 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2025-05-29 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • שיחה חופשית ווירטואלית על ראסט
• 2025-06-01 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-06-03 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • Why Rust? למה ראסט? -
• 2025-06-04 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2025-06-05 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-06-07 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2025-06-08 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-06-10 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2025-06-10 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up

Asia

• 2025-05-17 | Delhi, IN | Rust Delhi
  • Rust Delhi Meetup #10
• 2025-05-24 | Bangalore/Bengaluru, IN | Rust Bangalore
  • May 2025 Rustacean meetup
• 2025-06-08 | Tel Aviv-yafo, IL | Rust 🦀 TLV
  • In person Rust June 2025 at AWS in Tel Aviv

Europe

• 2025-05-13 - 2025-05-17 | Utrecht, NL | Rust NL
  • RustWeek 2025
• 2025-05-14 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2025-05-15 | Berlin, DE | Rust Berlin
  • 10 years anniversary of Rust 1.0
• 2025-05-15 | Oslo, NO | Rust Oslo
  • Rust 10-year anniversary @ Appear
• 2025-05-16 | Amsterdam, NL | RustNL
  • Rust Week Hackathon
• 2025-05-16 | Utrecht, NL | Rust NL Meetup Group
  • RustWeek Hackathon
• 2025-05-17 | Amsterdam, NL | RustNL
  • Walking Tour around Utrecht - Saturday
• 2025-05-20 | Dortmund, DE | Rust Dortmund
  • Talk and Connect - Fullstack - with Goetz Markgraf and Ben Wishovich
• 2025-05-20 | Aarhus, DK | Rust Aarhus
  • Hack Night - Robot Edition
• 2025-05-20 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD
• 2025-05-22 | Augsburg, DE | Rust Augsburg
  • Rust meetup #13:A Practical Guide to Telemetry in Rust
• 2025-05-22 | Bern, CH | Rust Bern
  • 2025 Rust Talks Bern #3 @zentroom
• 2025-05-22 | Paris, FR | Rust Paris
  • Rust meetup #77
• 2025-05-22 | Stockholm, SE | Stockholm Rust
  • Rust Meetup @UXStream
• 2025-05-27 | Basel, CH | Rust Basel
  • Rust Meetup #11 @ Letsboot Basel
• 2025-05-27 | Vienna, AT | Rust Vienna
  • Rust Vienna - May at Bitcredit 🦀
• 2025-05-29 | Oslo, NO | Rust Oslo
  • Rust Hack'n'Learn at Kampen Bistro
• 2025-05-31 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #12
• 2025-06-04 | Ghent, BE | Systems Programming Ghent
  • Grow smarter with embedded Rust
• 2025-06-04 | München, DE | Rust Munich
  • Rust Munich 2025 / 2 - Hacking Evening
• 2025-06-04 | Oxford, UK | Oxford Rust Meetup Group
  • Oxford Rust and C++ social
• 2025-06-05 | München, DE | Rust Munich
  • Rust Munich 2025 / 2 - Hacking Evening
• 2025-06-11 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup

North America

• 2025-05-15 | Hybrid (Redmond, WA, US) | Seattle Rust User Group
  • May, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-05-15 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2025-05-15 | Nashville, TN, US | Music City Rust Developers
  • Using Rust For Web Series 2 : Why you, Yes You. Should use Hyperscript!
• 2025-05-15 | Hybrid (Redmond, WA, US) | Seattle Rust User Group
  • May, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-05-18 | Albuquerque, NM, US | Ideas and Coffee
  • Intro Level Rust Get-together
• 2025-05-20 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2025-05-21 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Linking
• 2025-05-28 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2025-05-29 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2025-06-05 | Saint Louis, MO, US | STL Rust
  • Leptos web framework

South America

• 2025-05-28 | Montevideo, DE, UY | Rust Meetup Uruguay
  • Primera meetup de Rust de 2025!
• 2025-05-31 | São Paulo, BR | Rust São Paulo Meetup
  • Encontro do Rust-SP na WillBank

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

Jobs

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

Quote of the Week

If a Pin drops in a room, and nobody around understands it, does it make an unsound? #rustlang

- Josh Triplett on fedi

Thanks to Josh Triplett for the self-suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, U007D, joelmarcey, mariannegoldin, bennyvasquez, bdillo

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

14 May 2025 4:00am GMT

As a product manager for Firefox, one of the areas I'm most passionate about is accessibility. This is not only because I'm a disabled person myself, but also because I've seen firsthand that building in accessibility from the beginning results in better outcomes for everyone. Our new profile management feature is a great example of this approach.

Shifting left means building accessibility in from the start

If you picture the product development process as a horizontal line, with "user research" on the extreme left and "launch to market" on the extreme right, accessibility tends to fall on the right side of the line. On the right side of the line, we are reactive: the product is already built for the needs of non-disabled users, so we're just checking it for accessibility bugs. On the right side of the line, it's often too late or very expensive to fix accessibility bugs, so they don't get fixed. On the right side of the line, the best we can hope for is accessibility compliance with an industry standard like WCAG. On the right side of the line, we are more likely to build something unusable - even if we checked all the accessibility compliance boxes.

So how do we ensure that accessibility moves to the other end of the line, the left side? One of the most powerful ways to "shift left" is to include disabled people in the process as early as possible. On the left side of the line, we become proactive: we build products with disabled folks, not for them. On the left side of the line, we prevent accessibility bugs from ever happening because we spot them in the designs. On the left side of the line, we have a chance to go beyond compliance and achieve accessibility delight. On the left side of the line, working together, we have a better chance to discover curb cut effects: solutions designed with people with disabilities that end up benefitting everyone.

How Firefox profiles shifted left

Firefox is not always on the left side of the line, but we've been working hard over the last couple years to "shift left."

I'm a proudly disabled university student who works full time and is passionate about rowing and musical theater. I made four profiles: medical, school, work and personal. Each profile has its own unique avatar, color theme and name so I can easily recognize and switch between them in one click. I especially love that browsing history, bookmarks and tabs no longer intermix. I'm now much less likely to accidentally share my health information with my professors or my strategic work plans with fellow Sondheim nerds.

Throughout this project, we partnered with disabled folks to aim for accessibility compliance and, more importantly, delight. They gave us valuable feedback from our very first user research studies and continue to do so.

One group dreamed up brand new ideas and suggested enhancements during an in-depth review of an early prototype (including an awesome curb-cut effect we hope to share with you later this year). Testers who are experts in assistive tech (AT) pinpointed areas where we still needed to improve.

This truly was a community effort. We learned a lot, and we have more work to do.

Try profiles now and help shape what's next

While we'd love to make it available to everyone immediately, profile management is more complex than it probably appears: It's built on core Firefox code, and it interacts with and affects several other features and essential systems. To ensure Firefox and the profile management feature remain stable and compatible, we need to continue our incremental rollout for now.

In the meantime, we'd love for you to use profile management on Nightly and Beta, where it's on by default for everyone, then share your thoughts in this thread on Mozilla Connect, our forum for community feedback and ideas. You'll help us validate fixes and catch new bugs, as well as get early access to new features and enhancements.

At least 29% of the population is disabled, which means many of you have the insight and lived experience to help Firefox "shift left" on accessibility. That collaboration is already shaping a better browser - and a better web.

The post 'Shifting left' for better accessibility in Firefox appeared first on The Mozilla Blog.

13 May 2025 9:52pm GMT

Ever thought, "I wish I could try that new Firefox feature early?" Good news - we've been trying out new features and now, you can try them out, too.

Firefox Labs is our space for sharing experimental features with our community before they're fully baked. It's a chance to play around with new ideas, tell us what's working (and what's not) and help shape the future of Firefox together.

Early access to what we're building

Firefox Labs is built on a simple idea: If we're building for Firefox users, we should be building with them, too.

"We created Firefox Labs to get features into users' hands earlier," said Karen Kim, senior product manager at Mozilla. "It's a safe space where people can turn things on, play around, and help us learn faster."

In the past, testing out new ideas usually meant downloading special builds like Nightly or digging into advanced settings. That's not for everyone. Firefox Labs makes it way easier - just head to your Firefox settings, flip a switch, and try something new.

It's inspired by our old Test Pilot program (shoutout to longtime Firefox fans!), which helped launch popular features like picture-in-picture. Firefox Labs carries that same spirit - but with a closer connection to the people using Firefox today.

Try these Firefox Labs features now

We've got a couple of features live in Firefox Labs that you can try today:

Custom wallpapers for new tab

Inspired by your feedback, you can now upload your own image or choose from a set of new wallpapers and colors to customize your Firefox home screen.

<figcaption class="wp-element-caption">r</figcaption>

"You can choose your own color - go bold, go subtle, it's completely up to you," said Amber Meryman, product manager for the New Tab team. "We've added a new celestial category, plus even more images across all your favorite themes, these new wallpapers are all about making Firefox feel more like you."

Pet photos, space scenes, whatever you're into - the choice is up to you.

Link previews

Not sure if that link is worth clicking? Link previews give you a quick snapshot of what's behind a link - so you can decide if it's relevant before opening a new tab.

"Link previews are about saving time and reducing clutter," said Joy Chen, who works on Firefox's AI Experiences team. "When you're scanning a lot of content, it's easy to feel overwhelmed. Link Previews helps you quickly assess what's most relevant to you, so you can browse and learn more efficiently."

The team is already seeing valuable feedback in Firefox Labs, from shortcut suggestions to content quality questions.

"All of it helps - even critical feedback gives us a clearer picture of how people might use or feel about these tools," Joy said.

Link previews are especially handy for staying focused while doing research, browsing news, or avoiding tab overload.

How to share feedback (yes, we're listening)

Each experiment includes a link to Mozilla Connect - our community hub for feedback, suggestions, and discussion. If you sign in or create an account, it's where you can:

• Share what you love (or what's confusing)
• Suggest improvements
• See what others are saying
• Help guide what we build next
• Hear directly from product teams and engineers who regularly jump into the conversation

How to get started with Firefox Labs

First, check to make sure you're using the latest version of Firefox. Then:

• Go to Settings > Firefox Labs (it only shows up if a feature is available).
• Turn on a feature and give it a try.
• Head to Connect to share your thoughts!

Your ideas help shape Firefox. Many features like custom wallpapers got their start from community posts. Your idea could be next -- head to Mozilla Connect.

So whether you want to test new features, share your thoughts, or just peek at what's coming, Firefox Labs is your front-row seat to the future of Firefox.

Update: The post was revised on May 14 to clarify a quote about link previews.

The post Jump into Firefox Labs: A place to try new features and help shape Firefox appeared first on The Mozilla Blog.

13 May 2025 4:27pm GMT

Hello from the Thunderbird development team! With some of our time spent onboarding new team members and interviewing for open positions, April was a fun and productive month. Our team grew and we were amazed at how smooth the onboarding process has been, with many contributions already boosting the team's output.

Gearing up for our annual Extended Support Release

We have now officially entered the release cycle which will become our annual "ESR" at the end of June. The code we're writing, the features we're adding, the bugs we're fixing at the moment should all make their way into the next major update, to be enjoyed by millions of users. This most stable release is used by enterprises, governments and institutions who have specific requirements around consistency, long-term support, and minimized change over time.

If waiting a whole year doesn't sound appealing to you, our Monthly release may be better suited. It offers access to the latest features, improvements, and fixes as soon as they're ready. Watch out for an in-app invitation to upgrade or install over ESR to retain your profile settings.

Calendar UI Rebuild

The implementation of the new event dialog hit some challenges in April with the dialog positioning and associated tests causing more than a few headaches when our CI started reporting test failures that were not easy to debug. Not surprising given the 60,000 tests which run for this one patch alone!!

The focus on loading data into the various containers continues, so that we can enable this feature and begin the QA process.

Keep track of feature delivery via the [meta] bug

Exchange Web Services support in Rust

Our 0.2 release will make it into the hands of Daily and QA testers this month, with only a handful of smaller items left in our current milestone, before the "polish" milestone begins. The following items were completed in April:

• Connectivity check for EWS accounts
• Threading support
• Folder updates & deletions in sync
• Folder cache cleanup
• Folder copy/move
• Bug fixes!

Our hope is to include this feature set to users on beta and monthly release in 140 or 141.

Keep track of feature delivery here.

Account Hub

The new email account feature was "preffed on" as the default experience for the Daily build but recent changes to our Oauth process have required some rework to this user experience. We're currently working on designing a UX and associated functionality that can detect whether account autodiscovery requires a password, and react accordingly.

The redesigned UI for Address Book account additions is also underway and planned for release to users on 25th May.

Global Message Database

We welcomed a new team member in April so technical onboarding has been a priority. In addition, a long list of patches landed, with the team focused on refactoring core code responsible for the management of common folders such as Drafts or Sent Mail, and significant changes to nsIMsgPluggableStore.

Time was spent to research and plan a path to tackle dangling folders in May.

To follow their progress, the team maintains documentation in Sourcedocs which are visible here.

New Features Landing Soon

A number of requested features and important fixes have reached our Daily users this month. We want to give special thanks to the contributors who made the following possible…

• Improvements to notifications
• Manual folder sorting improvements
• Several port bugs to correct bustage introduced by upstream changes
• and many more in the release notes for beta.

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

-

Toby Pilling

Senior Manager, Desktop Engineering

Thunderbird

The post Thunderbird Monthly Developer Digest - April 2025 appeared first on The Thunderbird Blog.

13 May 2025 1:25pm GMT

In a previous blog post I explained that we're working to streamline the data consent experience for extensions and allow users to consent to sharing data with extensions directly in the Firefox add-on installation flow itself - rather than during a separate post-install experience and asking developers to build their own custom consent experiences, which is the case today.

We are not changing our policies on data collection, nor are we changing how extensions can collect data. Our goal is to simplify how a developer can be compliant with our existing policies so that we can dramatically reduce the:

1. development effort required to be compliant with Firefox data policies
2. confusion users faces when installing extensions by providing a more consistent experience, giving them more confidence and control around the data collected or transmitted
3. time it takes for an extension to be reviewed to ensure it's compliant with our data collection policies

I'm pleased to announce that the initial version of this feature is now available in Firefox Nightly version 139 (and later) for extension developers to test out and provide feedback.

We need your help!

We want to make sure that the new data consent experience is easy for extension developers to adopt, and works as a drop-in replacement for any existing custom consent experiences you may have created. We also need to know if the data categories available to choose from are appropriate for your extension.

We encourage extension developers to test out this new experience with their own extensions in Firefox Nightly, and let us know what they think by posting on this Mozilla Connect thread, or reach out to me directly on BlueSky!

To install an extension that has this experience configured you will need to install it from a file. You'll need to first set the xpinstall.signatures.required preference to false in about:config. This will only work on Nightly, and not on release versions of Firefox.

How it works

Developers can specify what data they wish to collect or transmit in their extensions manifest.json file. This information will be parsed by the browser and shown to the user when they first install the extension. A user can then choose to accept or reject the data collection, just like they do with extension permissions. The developer can also specify that the extension collects no data.

To standardize this information for both developers and end users, we have created categories based on data types that extensions might be using today. In line with our current policies, there are two types of data: Personal data, and Technical and Interaction data.

To provide feedback on these categories, please let us know via our research survey. Therefore, please note that these options are subject to change based on the feedback we receive during this initial phase.

Personal data

Personally identifiable information can be actively provided by the user or obtained through extension APIs. It includes, but is not limited to names, email addresses, search terms and browsing activity data, as well as access to and placement of cookies.

Data type Visible during install	Data collection permission Used in the manifest	Definition / Examples
Personally identifying information	personallyIdentifyingInfo	Examples: contact information like name and address, email, and phone number, as well as other identifying data such as ID numbers, voice or video recordings, age, demographic information, or biometric data.
Health information	healthInfo	Examples: medical history, symptoms, diagnoses, treatments, procedures, or heart rate data.
Financial and payment information	financialAndPaymentInfo	Examples: credit card numbers, transactions, credit ratings, financial statements, or payment history.
Authentication information	authenticationInfo	Examples: passwords, usernames, personal identification numbers (PINs), security questions, and registration information for extensions that offer account-based services.
Personal communications	personalCommunications	Examples: emails, text or chat messages, social media posts, and data from phone calls and conference calls.
Location	locationInfo	Examples: region, GPS coordinates, or information about things near a user's device.
Browsing activity	browsingActivity	Information about the websites you visit, like specific URLs, domains, or categories of pages you view over time.
Website content	websiteContent	Covers anything visible on a website - such as text, images, videos, and links - as well as anything embedded like cookies, audio, page headers, request, and response information.
Website activity	websiteActivity	Examples: interactions and mouse and keyboard activity like scrolling, clicking, typing, and covers actions such as saving and downloading.
Search terms	searchTerms	Search terms entered into search engines
Bookmarks	bookmarksInfo	Information about Firefox bookmarks, including specific websites, bookmark names, and folder names.

Technical and interaction data

Technical data describes information about the environment the user is running, such as browser settings, platform information, and hardware properties. User interaction data includes how the user interacts with Firefox and the installed add-on, metrics for product improvement, and error information.

Data type Visible during install	Data collection permission Used in the manifest	Definition
Technical and interaction data	technicalAndInteraction	Examples: Device and browser info, extension usage and settings data, crash and error reports.

Specifying data types

You specify data types your extension transmits in the browser_specific_settings.gecko key in the manifest.json file. As a reminder, our policies state that data transmission refers to any data that is collected, used, transferred, shared, or handled outside of the add-on or the local browser.

Personal data

Personal data permissions can either be required or optional (only technicalAndInteraction cannot be required, and this is documented later):

"browser_specific_settings": {
  "gecko": {
    "data_collection_permissions": {
      "required": [...],
      "optional": [...]
    }
  }
}

The rest of this section describes each key in the data_collection_permissions object.

Required data

When types of data are specified in the required list, users must opt in to this data collection to use the extension. Users cannot opt-out, and Figure 1 gives an example of how it could look. If a user does not agree to the data collection the extension is not installed. Unlike today, this gives the user a chance to review the data collection requirements of an extension before it is installed in their browser.

In the manifest.json file below, the developer specifies a single type of required data: locationInfo.

{
  "manifest_version": 2,
  "name": "Example - Data collection with fallback",
  "version": "1.0.0",
  "permissions": [
    "storage",
    "management"
  ],
  "browser_specific_settings": {
    "gecko": {
        "id": "example-data-collection-with-fallback@test.mozilla.org",
        "data_collection_permissions": {
          "required": [
             "locationInfo"
          ],
          "optional": [
             "technicalAndInteraction"
          ]
         }
      }
  },
  "background": {
    "scripts": [
      "background.js"
    ]
  },
  "browser_action": {},
  "options_ui": {
     "page": "options/page.html"
  }
}

This results in a new paragraph in the installation prompt (see Figure 1). The data permissions are also listed in about:addons as shown in Figure 2.

Optional data

Optional data collection permissions can be specified using the optional list. These are not surfaced during installation (except technicalAndInteraction; see next section), and they are not granted by default. The extension can request the user opts in to this data collection after installation via a prompt, and the user can enable or disable this option data collection at any time in about:addons in the Permissions and data section of the extension settings.

Technical and interaction data

The technicalAndInteraction data type behaves differently compared to all others. This data permission can only be optional, but unlike other optional data collection options the user has the opportunity to enable or disable this during the installation flow.. In Figure 1, we can see this choice available in the optional settings section of the installation prompt.

No data collection

We also want to be clear to users when an extension collects no data. To enable this, developers can explicitly indicate that their extension does not collect or transmit any data by specifying the "none" required permission in the manifest, as follows:

{
  "manifest_version": 2,
  "name": "extension without data collection",
  "version": "1.0.0",
  "browser_specific_settings": {
    "gecko": {
      "id": "@extension-without-data-collection",
      "data_collection_permissions": {
        "required": ["none"]
      }
    }
  },
  "permissions": [
    "bookmarks",
    "<all_urls>"
  ]
}

When a user attempts to install this extension, Firefox will show the usual installation prompt with the description of the required (API) permissions as well as a new description to indicate that the extension does not collect any data (see Figure 3).

The "no data collected" type is also listed in the "Permissions and data" tab of the extension in about:addons as shown in Figure 4.

Note: The none data type can only be required, and it cannot be used with other data types, including optional types. When that happens, Firefox will ignore the none type, and only consider the other data types (see next section for more information). In addition, Firefox will show a warning message intended to developers in about:debugging as shown in Figure 5.

Accessing the data permissions programmatically

Extension developers can use the browser.permissions API (MDN docs) to interact with the optional data permissions. Specifically, the getAll() method would now return the list of granted optional data permissions as follows:

await browser.permissions.getAll()
{
  origins: ["<all_urls>"],
  permissions: ["bookmarks"],
  // In this case, the permission is granted.
​  data_collection: ["technicalAndInteraction"]
}

Extension developers can also use the browser.permissions.request() API method (MDN docs) to get consent from users for ancillary data collection (defined in the optional list):

await browser.permissions.request({ data_collection: ["healthInfo"] });

This will show the following message to the Firefox user, giving them the choice to opt in to this data collection or not.

Updates

When an extension is updated, Firefox will only show the newly added required data permissions, unless it's the special none data type because we don't need to bother the user when the extension does not collect any data. This should behave like today for traditional permissions.

Please try it out and let us know what you think!

As I mentioned, we really want to make sure that the new data consent experience is easy for extension developers to adopt, and works as a drop-in replacement for any existing custom consent experiences you may have created.

Please test out this new experience with your own extensions in Firefox Nightly, and let us know what you think by posting on this Mozilla Connect thread

The post New Extension Data Consent Experience now available in Firefox Nightly appeared first on Mozilla Add-ons Community Blog.

09 May 2025 9:28am GMT

Before we start, let's address the elephant in the room. Last month, we proposed that we would change our AI contributions policy to allow the use of AI tools in some situations, including GitHub Copilot for code. The feedback we received from the community was overwhelmingly clear, and we've listened. We will keep the AI contributions ban in place, and any future proposals regarding this policy will be discussed together, as a community.

At the same time, we have other big news! Complex sites such as Gmail and Google Chat are now usable in Servo, with some caveats. This milestone is only possible through the continued hard work of many Servo contributors across the engine, and we're thankful for all of the efforts to reach this point.

Servo now supports single-valued <select> elements (@simonwuelker, #35684, #36677), disabling stylesheets with <link disabled> (@Loirooriol, #36446), and the Refresh header in HTTP responses and <meta> (@sebsebmc, #36393), plus several new CSS features:

• the & selector for CSS nesting (@Loirooriol, #36246, #36254, #36248, #36249)
• 'scale', 'rotate', and 'translate' (@chocolate-pie, @Loirooriol, #35926)
• 'will-change' (@yezhizhen, #35787)
• the 'fit-content()' sizing function (@Loirooriol, #36056)
• the 'image-set()' notation (@chocolate-pie, #36210)

We've also landed a bunch of new web API features:

• the Response.json() static method (@sebsebmc, #36589, #36523)
• the CSSStyleSheet() constructor (@Loirooriol, #36521)
• the seekable property on HTMLMediaElement (@rayguo17, #36541)
• the label property on HTMLOptGroupElement (@simonwuelker, #35970)
• the align property on HTMLParagraphElement (@stephenmuss, #36054)
• ClipboardItem and navigator.clipboard.writeText() (@Gae24, #36336, #36498)
• addRule(), removeRules(), replaceSync(), and the rules property on CSSStyleSheet (@Loirooriol, @webbeef, #36313, #36586)
• getLineDash(), setLineDash(), and lineDashOffset on CanvasRenderingContext2D (@stevennovaryo, #36257)
• ReadableByteStreamController and pipeTo() on ReadableStream (@Taym95, @gterzian, #35410, #35650)

The biggest engine improvements we've made recently were in Shadow DOM (+70.0pp to 77.9%), the Trusted Types API (+57.8pp to 57.8%), Content Security Policy (+54.0pp to 54.8%), the Streams API (+31.9pp to 68.1%), and CSS Text (+20.4pp to 57.6%).

We've enabled Shadow DOM by default after significantly improving support, allowing Servo to render sites like wpt.fyi correctly (@simonwuelker, @longvatron111, @elomscansio, @jdm, @sakupi01, #35923, #35899, #35930, #36104, #34964, #36024, #36106, #36173, #36010, #35769, #36230, #36620).

ReadableStream, WritableStream, DOMPoint, DOMPointReadOnly, and DOMException can now be sent over postMessage() and structuredClone() (@gterzian, @kkoyung, @jdm, @mrobinson, #36181, #36588, #36535, #35989).

We've started working on support for stream transforms (@Taym95, #36470) and the trusted types API (@TimvdLippe, @jdm, #36354, #36355, #36422, #36454, #36409, #36363, #36511, #36596). We've also laid the groundwork for supporting the ::marker pseudo element (@mrobinson, #36202), animated images in web content (@rayguo17, #36058, #36141), and getClientRects() and getBoundingClientRect() on Range (@simonwuelker, #35993).

Servo can now render the caret and text selection in input fields (@dklassic, @webbeef, #35830, #36478), and we've landed a few fixes to radio buttons (@elomscansio, #36252, #36431), file inputs (@sebsebmc, #36458), and input validation (@MDCODE247, #36236).

Having disabled by default Servo's original, experimental layout implementation back in November 2024, we've now taken the step of deleting all of the disabled code (@Loirooriol, @TimvdLippe, @mrobinson, #35943, #36281, #36698) and moving all of the remaining layout code to layout (@mrobinson, #36613). Our new layout engine is improving significantly month over month!

We've added a new --enable-experimental-web-platform-features option that enables all engine features, even those that may not be stable or complete. This works much like Chromium's option with the same name, and it can be useful when a page is not functioning correctly, since it may allow the page to make further progress. Servo now uses this option when running the Web Platform Tests (@Loirooriol, #36335, #36519, #36348, #36475), and the features enabled by this option are expected to change over time.

Servo-the-browser (servoshell)

Our devtools integration now supports iframes (@simonwuelker, #35874) and color scheme simulation (@uthmaniv, #36253, #36168, #36297), shows computed display values when inspecting elements (@stephenmuss, #35870), and supports multiple tabs open in the servoshell browser (@atbrakhi, #35884). We've also landed the beginnings of a Sources panel (@delan, @atbrakhi, #36164, #35971, #36631, #36632, #36667). To use devtools, we now require Firefox 133 or newer (@atbrakhi, #35792).

Dialogs support keyboard interaction to close and cancel them (@chickenleaf, #35673), and the URL bar accepts any domain-like input (@kafji, #35756). We've also enabled sRGB colorspaces on macOS for better colour fidelity (@IsaacMarovitz, #35683). Using the --userscripts option without providing a path defaults to resources/user-agent-js. Finally, we've renamed the OpenHarmony app bundle (@jschwe, #35790).

Servo-the-engine (embedding)

We've landed some big changes to our webview API:

• pinch zoom, page zoom, and HiDPI scaling are now handled independently for each webview (@mrobinson, @shubhamg13, #36419, #36312)
• mouse click events no longer need to be generated by the embedder, only mouse button down and up events (@yezhizhen, #36413)
• webviews are now created with WebViewBuilder (@mrobinson, #36483)
• EmbedderMethods is now ServoBuilder (@mrobinson, #36276, #36549)
• WindowMethods have moved to WebViewDelegate and ServoDelegate (@mrobinson, #36223, #36400)

Embedders can now inject userscript sources into all webviews (@Legend-Master, #35388). Links can be opened in a new tab by pressing the Ctrl or ⌘ modifier (@webbeef, @mrobinson, #35017). Delegates will receive send error notifications for requests (@delan, #35668), and we made progress towards a per-webview renderer model (@mrobinson, @delan, #35701, #35716).

We fixed a bug causing flickering cursors (@DevGev, #35934), and now create the config directory if it does not exist (@yezhizhen, #35761). We also fixed a number of bugs in the WebDriver server related to clicking on elements, opening and closing windows, and returning references to exotic objects (@jdm, #35737).

Under the hood

We've finally finished splitting up our massive script crate (@jdm, #35988, #35987, #36107, #36216, #36220, #36095, #36323), which should cut incremental build times for that crate by 60%. This is something we've wanted to do for over eleven years (@kmcallister, #1799)!

webgpu rebuilds are now faster as well, with changes to that crate no longer requiring a script rebuild (@mrobinson, #36332, #36320).

Stylo has been upgraded to 2025-03-15 (@nicoburns, @Loirooriol, #35782, #35925, #35990), and we upgraded to the 2024 Rust edition (@simonwuelker, #35755).

We added a memory usage view for Servo embedders: visit about:memory for a breakdown of identified allocations (@webbeef, @jdm, #35728, #36557, #36558, #36556, #36581, #36553, #36664).

Perf and stability

We've started building an incremental layout system in Servo (@mrobinson, @Loirooriol, #36404, #36448, #36447, #36513), with a huge speedup to offsetWidth, offsetHeight, offsetLeft, offsetTop, and offsetParent layout queries (@mrobinson, @Loirooriol, #36583, #36629, #36681, #36663). Incremental layout will allow Servo to respond to page updates and layout queries without repeating layout work, which is critical on today's highly dynamic web.

OffscreenRenderingContext is no longer double buffered, which can improve rendering performance in embeddings that rely on it. We also removed a source of canvas rendering latency (@sagudev, #35719), and fixed performance cliffs related to the Shadow DOM (@simonwuelker, #35802, #35725). We improved layout performance by reducing allocations (@jschwe, #35781) and caching layout results (@Loirooriol, @mrobinson, #36082), and reduced the latency of touch events when they are non-cancelable (@kongbai1996, #35785).

We also fixed crashes involving touch events (@kongbai1996, @jschwe, #35763, #36531, #36229), service workers (@jdm, #36256), WritableStream (@Taym95, #36566), Location (@jdm, #36494), <canvas> (@tharkum, @simonwuelker, #36569, #36705), <input> (@dklassic, #36461), <iframe> (@leftmostcat, #35742), 'min-content' and 'max-content' (@Loirooriol, #36518, #36571), flexbox (@mrobinson, #36123), global objects (@jdm, #36491), resizing the viewport (@sebsebmc, #35967), and --pref shell_background_color_rgba (@boluochoufeng, #35865). Additionally, we removed undefined behaviour from the Rust bindings to the SpiderMonkey engine (@gmorenz, #35892, #36160, #36161, #36158).

The project to decrease the risk of intermittent GC-related crashes continues to make progress (@jdm, @Arya-A-Nair, @Dericko681, @yerke, #35753, #36014, #36043, #36156, #36116, #36180, #36111, #36375, #36371, #36395, #36392, #36464, #36504, #36495, #36492).

More changes

Our flexbox implementation supports min/max keyword sizes for both cross and main axes (@Loirooriol, #35860, #35961), as well as keyword sizes for non-replaced content (@Loirooriol, #35826) and min and max sizing properties (@Loirooriol, #36015). As a result, we now have full support for size keywords in flexbox!

We made lots of progress on web API features:

• added partial support for IntersectionObserver (@stevennovaryo, #35551)
• initial work on implementing the URLPattern API (@simonwuelker, #36144)
• history.replaceState() can be called from file:// documents (@kkoyung, #35864)
• members of radio input groups apply validity constraints more consistently (@jerensl, @elomscansio, @Barry-dE, #36197, #36090, #36103)
• file inputs show the selected file (@dklassic, #35789)

On security and networking:

• the nonce attribute is used in Content Security Policy checks (@simonwuelker, #35876)
• Request objects with FormData bodies use the correct Content-Type (@andreubotella, #36194)
• text response bodies containing a BOM consume it (@andreubotella, #36192)
• notifications fetch associated image resources (@pewsheen, #35878)

On the DOM:

• passive event listeners can be created (@shanehandley, #35877)
• removing an event listener that has not run prevents it from running (@tharkum, #36163)
• we removed some cases where custom element callbacks fired incorrectly (@xiaochengh, #35960, #35883)
• touchmove events are more reliable (@kongbai1996, #36218 #36200) and support the cancelable property (@kongbai1996, #35713)
• ResizeObserver callbacks are only invoked when elements change size (@simonwuelker, #36226)
• cancelled enqueued animation frame callbacks no longer run (@xiaochengh, #35849)
• scripts are no longer executed in documents that should disable scripting (@simonwuelker, #35871)
• script elements adopted between documents use the original document to determine when to execute (@xiaochengh, #35718)

And on many other bugs:

• Backspace no longer removes entire lines in <textarea> (@elomscansio, @jdm, #36112)
• improved overflow handling in some special cases (@yezhizhen, #35670)
• fixed incorrect fallback font caching (@mrobinson, #35705)
• fixed the intrinsic block size of replaced elements with auto width (@Loirooriol, #35275)
• 'table-layout: fixed' is no longer ignored when 'inline-size' is 'auto' (@Loirooriol, #35882)
• margins of block-level box stretches are always zero, regardless of collapsing status (@Loirooriol, #35904)
• indefinite stretch contributes to intrinsic sizes (@Loirooriol, #36030)
• static positions include ancestor padding (@Loirooriol, #36051)
• table rows with a span of >1 are sized appropriately (@PotatoCP, #36064)
• input element contents ignore any outer display value (@PotatoCP, #35908)
• indexing properties with values near 2^32 resolves correctly (@reesmichael1, #36136)

Donations

Thanks again for your generous support! We are now receiving 4664 USD/month (+6.8% over February) in recurring donations. This helps cover the cost of our self-hosted CI runners and our latest Outreachy interns, Usman Baba Yahaya (@uthmaniv) and Jerens Lensun (@jerensl)!

Servo is also on thanks.dev, and already 24 GitHub users (+3 over February) 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.

4664 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.

Conference talks

Josh Matthews (@jdm) will be speaking about Servo at RustWeek 2025, on Tuesday 13 May at 17:05 local time (15:05 UTC). See you there!

09 May 2025 12:00am GMT

The Rust Project is participating in Google Summer of Code (GSoC) again this year. GSoC is a global program organized by Google that is designed to bring new contributors to the world of open-source.

In March, we published a list of GSoC project ideas, and started discussing these projects with potential GSoC applicants on our Zulip. We had many interesting discussions with the potential contributors, and even saw some of them making non-trivial contributions to various Rust Project repositories, even before GSoC officially started!

After the initial discussions, GSoC applicants prepared and submitted their project proposals. We received 64 proposals this year, almost exactly the same number as last year. We are happy to see that there was again so much interest in our projects.

A team of mentors primarily composed of Rust Project contributors then thoroughly examined the submitted proposals. GSoC required us to produce a ranked list of the best proposals, which was a challenging task in itself since Rust is a big project with many priorities! Same as last year, we went through several rounds of discussions and considered many factors, such as prior conversations with the given applicant, the quality of their proposal, the importance of the proposed project for the Rust Project and its wider community, but also the availability of mentors, who are often volunteers and thus have limited time available for mentoring.

As is usual in GSoC, even though some project topics received multiple proposals¹, we had to pick only one proposal per project topic. We also had to choose between great proposals targeting different work to avoid overloading a single mentor with multiple projects.

In the end, we narrowed the list down to a smaller number of the best proposals that we could still realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of them would be accepted into GSoC.

Selected projects

On the 8th of May, Google has announced the accepted projects. We are happy to share that 19 Rust Project proposals were accepted by Google for Google Summer of Code 2025. That's a lot of projects, which makes us super excited about GSoC 2025!

Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s):

• ABI/Layout handling for the automatic differentiation feature by Marcelo Domínguez, mentored by Manuel Drehwald and Oli Scherer
• Add safety contracts by Dawid Lachowicz, mentored by Michael Tautschnig
• Bootstrap of rustc with rustc_codegen_gcc by Michał Kostrubiec, mentored by antoyo
• Cargo: Build script delegation by Naman Garg, mentored by Ed Page
• Distributed and resource-efficient verification by Zhou Jiping, mentored by Michael Tautschnig
• Enable Witness Generation in cargo-semver-checks by Talyn Veugelers, mentored by Predrag Gruevski
• Extend behavioural testing of std::arch intrinsics by Madhav Madhusoodanan, mentored by Amanieu d'Antras
• Implement merge functionality in bors by Sakibul Islam, mentored by Jakub Beránek
• Improve bootstrap by Shourya Sharma, mentored by Jakub Beránek, Jieyou Xu and Onur Özkan
• Improve Wild linker test suites by Kei Akiyama, mentored by David Lattimore
• Improving the Rustc Parallel Frontend: Parallel Macro Expansion by Lorrens, mentored by Sparrow Li
• Make cargo-semver-checks faster by JosephC, mentored by Predrag Gruevski
• Make Rustup Concurrent by Francisco Gouveia, mentored by rami3l
• Mapping the Maze of Rust's UI Test Suite with Established Continuous Integration Practices by Julien Robert, mentored by Jieyou Xu
• Modernising the libc Crate by Abdul Muiz, mentored by Trevor Gross
• New proc-macro Server API for Rust-Analyzer by Neil Wang, mentored by Lukas Wirth
• Prepare stable_mir crate for publishing by Makai, mentored by Celina Val
• Prototype an alternative architecture for cargo fix using cargo check by Glen Thalakottur, mentored by Ed Page
• Prototype Cargo Plumbing Commands by Vito Secona, mentored by Cassaundra

Congratulations to all applicants whose project was selected! The mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects.

We would also like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited mentorship capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our project idea list is still actual and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project maintainers and the Rust ecosystem. Some of the Rust Project Goals are also looking for help.

There is also a good chance we'll participate in GSoC next year as well (though we can't promise anything at this moment), so we hope to receive your proposals again in the future!

The accepted GSoC projects will run for several months. After GSoC 2025 finishes (in autumn of 2025), we will publish a blog post in which we will summarize the outcome of the accepted projects.

08 May 2025 12:00am GMT