fidzu : Mozilla

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

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

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

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

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

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

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

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

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

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

23 Jun 2026 5:59pm GMT

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

Naming updates

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

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

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

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

What we learned so far

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

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

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

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

Webmail

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

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

A look at what is coming next

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

Send and Appointment

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

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

We're looking for more ideas

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

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

Thank you for helping us build Thundermail.

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

23 Jun 2026 5:24pm GMT

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

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

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

Privacy and access in tension

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

But every step forward has come with a cost.

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

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

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

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

Finding a better way forward

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

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

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

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

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

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

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

A fix is both essential and possible

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

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

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

The post Keeping the Web Open and Private in the Bot Era appeared first on The Mozilla Blog.

23 Jun 2026 3:56pm GMT

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

Bots (and privacy-preserving browsers) not welcome

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

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

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

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

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

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

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

The Costs of Convenient Solutions

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

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

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

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

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

A Better Path Forward

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

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

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

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

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

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

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

The Foundations

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

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

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

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

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

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

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

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

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

Putting it together

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next Steps

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

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

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

Acknowledgements

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

---

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

23 Jun 2026 3:29pm GMT

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

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

The proof of concept holds

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

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

Reform is going global and fast

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

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

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

What the momentum demands

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

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

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

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

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

23 Jun 2026 12:43pm GMT

Highlights

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

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

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

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

New contributors (🌟 = first patch)

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

Project Updates

Accessibility

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

Add-ons / Web Extensions

Addon Manager & about:addons

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

WebExtensions Framework

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

WebExtension APIs

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

DevTools

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

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

WebDriver

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

Search and Urlbar

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

22 Jun 2026 7:57pm GMT

The latest version of PerfCompare is now live!

Check out the change-log below to see the updates:

[andra - esanuandra ]

• PCF-391 The keyboard handling for the revision dropdown should be done differently (#926)

[david - davidmiculit ]

• Bug 2040649 - Remove Raptor framework from PerfCompare (#1042)

[kala - kala-moz ]

• Results Page: Return the scatter series for base and new back to original order (#1046)

• Bug: 2044194 Port client-side KDE mode detection from kde-widget into CommonGraph (#1045)

• Bug 2034263: Give subtest column in subtest page a max-width (#1047)

[paul - padenot]

• Two small followups on modal-work (#1049)

• Assorted fixes to improve the app when numbers are very large and not measuring time. (#1050)

Thank you for the contributions!

Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat!

1 post - 1 participant

Read full topic

17 Jun 2026 4:46pm 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

Project/Tooling Updates

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

Observations/Thoughts

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

Rust Walkthroughs

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

Miscellaneous

• [video] RustWeek 2026 talk recordings

Crate of the Week

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

Thanks to Arne Code for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

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

CFP - Events

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

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

Updates from the Rust Project

527 pull requests were merged in the last week

Compiler

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

Library

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

Cargo

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

Rustdoc

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

Rustfmt

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

Clippy

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

Rust-Analyzer

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

Rust Compiler Performance Triage

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

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

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.6%]	22
Regressions ❌ (secondary)	0.5%	[0.1%, 2.0%]	40
Improvements ✅ (primary)	-1.8%	[-5.9%, -0.1%]	125
Improvements ✅ (secondary)	-3.8%	[-69.4%, -0.1%]	90
All ❌✅ (primary)	-1.5%	[-5.9%, 0.6%]	147

1 Regression, 4 Improvements, 8 Mixed; 5 of them in rollups 28 artifact comparisons made in total

Full report here

Approved RFCs

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

• No RFCs were approved this week.

Final Comment Period

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

Tracking Issues & PRs

Rust

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

Compiler Team (MCPs only)

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

Leadership Council

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

Rust RFCs

• Named Fn trait parameters

Language Reference

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

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

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

New and Updated RFCs

• No New or Updated RFCs were created this week.

Upcoming Events

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

Virtual

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

Europe

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

North America

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

Oceania

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

South America

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

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

Jobs

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

Quote of the Week

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

- Sergey "Shnatsel" Davidoff on /r/rust

Thanks to Dos Moonen for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

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

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

17 Jun 2026 4:00am GMT

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

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

Contributions

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

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

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

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

General

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

WebDriver BiDi

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

Marionette

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

16 Jun 2026 2:00pm GMT

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed:

Highlights:

• [Nazım Can Altınova] Add source map symbolication and source view support (#6018)
  • It requires Firefox changes that will land in Firefox 154, but after these changes, you will be able to see the source mapped function names as well as the source contents!
• [fatadel] Upgrade to React 19 (#6067)
• [fatadel] Drive counter tooltips from a tooltipRows schema (#6023)
• [Markus Stange] Support reading profiles from JsonSlabs files (#6037)
• [fatadel] Replace the footer-links overlay with a settings menu (#6042)

Other Changes:

• [Nazım Can Altınova] Fix call node context menu being hidden behind source view bottom box (#6045)
• [Nazım Can Altınova] Pass --use-env-proxy only when the node version is >= 24 (#6064)
• [fatadel] Upgrade @firefox-devtools/react-contextmenu to 5.2.4 (#6066)
• [Markus Stange] Switch profiler-edit from minimist to commander (#6065)
• [Florian Quèze] Don't fail profile processing when a marker's stack field is not a backtrace (#6069)
• [fatadel] Remove unused undici-types package (#6074)
• [cathaysia] Update isLocalURL to include LAN addresses, .local domains, and hostn… (#5973)
• [Markus Stange] Fix from-url with binary profiles (#6072)
• [Markus Stange] Add an insertStackLabels helper. (#6076)
• [fatadel] Add TrackPower-tooltip-average-power-microwatt (#6080)
• [Markus Stange] Downgrade to React 19.1 to fix unusable dev build performance. (#6082)
• [spokodev] fix(FilterNavigatorBar): clip overflow so many breadcrumbs do not expand the parent (#6085)
• [Markus Stange] Move paddings inside the tree header cells. (#6002)
• [Markus Stange] Add an --insert-label-frames argument to the profiler-edit tool (#5966)
• [Markus Stange] Stop printing "error: too many arguments" during tests. (#6088)
• [Markus Stange] More additions to profiler-edit, for sp3 profiles (#6009)
• [Nazım Can Altınova] Do not rely on localized texts in the settings menu tests (#6101)

Big thanks to our amazing localizers for making this release possible:

• be: Andrei Mukamolau
• de: Ger
• de: Michael Köhler
• de: Ralf Duehnfahr
• el: Jim Spentzos
• en-CA: chutten
• en-GB: Ian Neal
• es-CL: ravmn
• fr: Théo Chevalier
• fr: wy
• fur: Fabio Tomat
• fy-NL: Fjoerfoks
• ia: Melo46
• it: Francesco Lodolo [:flod]
• nl: Mark Heijl
• ru: Valery Ledovskoy
• sr: Марко Костић (Marko Kostić)
• sv-SE: Andreas Pettersson
• tr: Grk
• tr: Selim Şumlu
• zh-CN: Olvcpr423
• zh-TW: Pin-guang Chen

Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!

1 post - 1 participant

Read full topic

16 Jun 2026 1:38pm GMT

Firefox gives you many ways to make the browser your own, from privacy settings and AI controls to tab management, custom colors, and more. As we continue to improve Firefox, you get more control over how it works for you.

Today, we're introducing a redesigned settings experience that makes your options easier to find, understand, and manage.

Over time, some settings pages became crowded, related preferences were spread across different sections, and it wasn't always obvious where to look for a particular option. The redesign makes settings easier to navigate while preserving existing preferences and the flexibility and control that Firefox is known for.

The new settings feature a cleaner layout, modern visual design, improved labels and descriptions, and updated navigation, bringing related categories together. One of the most noticeable updates is the retirement of the long-standing "General" page. Many of the options that were previously there have now moved into more specific areas, including "Appearance," "Accessibility," "Languages," and "Tabs and browsing."

Some options may have moved, but your existing preferences haven't changed. The customization options you rely on are still available. If you're not sure where to find something, the search bar can help you locate it quickly. You can also visit Mozilla Support for more detailed guidance.

This redesign reflects extensive user research, including interviews, usability testing, card-sorting exercises, and analysis of usage data. It was also shaped by feedback from the Firefox community through Mozilla Connect, Reddit, and other channels, along with collaboration across Mozilla teams.

Thank you to everyone who shared their feedback along the way. Your insights helped shape the redesigned settings experience, and they'll continue to guide future improvements as Firefox evolves.

The post Firefox is easier than ever to customize appeared first on The Mozilla Blog.

16 Jun 2026 12:58pm GMT

Firefox has been busy introducing updates across productivity, privacy and AI. From Project Nova and browser-wide AI controls to expanded privacy protections and new ways to stay organized, the goal is simple: help you spend less time managing your browser and more time getting things done online.

But building the best browser isn't just about shipping new features. It's also about building them alongside the people who use Firefox every day.

Introducing the Firefox roadmap

Today, we're introducing the Firefox roadmap to give people a closer look at what we're building and a preview of where Firefox is heading next.

We've always built Firefox in the open and our new roadmap is an extension of that.

"Some of the best ideas in Firefox come directly from the people who use it," said Ajit Varma, head of Firefox. "The roadmap gives our community a new way to see what's taking shape, share feedback earlier and help guide where we're heading next."

The roadmap highlights what we're working on across Firefox, including productivity, privacy, performance, AI and the technologies that help make the web better for everyone.

Some items on the roadmap will be things we've already shared; others we'll be sharing publicly for the first time. Together, it'll provide a clearer picture of where Firefox is headed and the areas we're investing in to build a better browser.

Here's a look at what's rolling out now in Firefox 152, and what we're building next.

New in Firefox 152

• Tab Groups are now on Android: When "just a few" turns into dozens of tabs, it's hard to tell what's important or which tab had the thing you were actually looking for. Tab Groups have been helping Firefox desktop users bring order to the chaos. Now, they're starting to roll out on Firefox for Android, turning related mobile tabs into clear threads you can name, color and come back to when you're ready. iOS support will follow later this year.
• Simpler way to manage Firefox settings: We've redesigned Firefox settings to make it easier to find what you're looking for, discover controls you might not have known existed, and truly make Firefox your own. Don't worry: Your existing preferences aren't changing; just better organized. Get the details here and visit Mozilla Support for answers to all your settings questions.
• Privacy protections you can actually see: You shouldn't have to worry about trackers every time you browse. Firefox blocks many of them automatically so you can focus on what you came to do. The new Blocked Tracker Widget brings that protection into view, showing how many trackers Firefox has blocked over time, what kinds of tracking activity it stopped and how Firefox is working behind the scenes.

What's next on the Firefox roadmap

• Power users know that even small efficiency improvements add up over time. One of Firefox's most requested customization features, customizable keyboard shortcuts give you more control over how Firefox fits into your workflow, whether you're streamlining a routine task, adapting Firefox to your accessibility needs or simply prefer your own shortcuts.
• Designed to help people handle everyday PDF tasks without leaving the browser, upcoming PDF editing improvements will include the ability to split, merge and reorganize documents directly in Firefox.
• Multi-Account Containers, one of Firefox's most-loved browser extensions, helps people carve out a separate space for each part of their online life and keep work, personal and other online activities from bleeding into one another. We're now bringing Containers into the native Firefox experience, so more people can take advantage of one of Firefox's most distinctive tools without needing to install an add-on first.
• Firefox's free built-in VPN is coming to mobile devices, helping people stay protected across more of the devices they use every day. Whether you're traveling, connecting from public Wi-Fi or simply browsing away from home, bringing VPN to mobile is part of a broader effort to make Firefox privacy protections available wherever you go.
• Sometimes the fastest way to get information is simply to ask. With Quick Answers, people will be able to ask Firefox a question using their voice and receive a concise AI-generated answer right in the browser, with sources available when they want to learn more.
• We're continuing to build Smart Window, our optional and private AI browsing experience designed to help people get answers, compare information and make sense of what they're already reading online. You can now try it without joining a waitlist.
• We're adding Power Saving Mode to help identify tabs that consume the most resources on your phone and automatically reduce their impact, extending battery life without constantly managing what's running in the background.

Join the conversation

Try out the latest features, explore what's coming next and tell us what you think on Mozilla Connect.

We're also hosting a Reddit AMA on June 24 with Firefox product leaders, so bring your questions.

Talk soon.

The post What's new in Firefox this June, and what's next on the Firefox roadmap appeared first on The Mozilla Blog.

16 Jun 2026 12:57pm GMT

The past month was busy; the theme was evolution. We went into this quarter with our own ideas for what we wanted to accomplish. However, our users had better ideas. With the release of Thunderbird's own mail service, Thundermail, the need for a better account settings import process across our services and apps became vital.

We have also heard from our users about issues they had with syncing, notifications, bugs, and more. As such, we refined our roadmap, because the goal is always a better, safer, more private email client, and delivering that experience is more important than any foregone projects. Our roadmap can change, but our goal to deliver the best cannot.

Android

On Android, our focus turned to our import function through a QR code. This helps transfer settings from Thunderbird desktop to mobile. We also ensured that it would work for our new Thundermail project. This allows our early Thundermail users to quickly move their accounts to the Thunderbird mobile app. Additionally, we merged fixes for importing accounts, getting the avatar monogram to match the account immediately after setup, and new translations.

We also began some exploratory work on one of our biggest upcoming projects. Our users have been clear about a recurring issue that they want resolved. Notifications. Notifications on an email client are tricky, especially one like ours, where we support so many different services. Users report not receiving notifications for newly delivered emails, even when polling or push are enabled, notifications appearing improperly in the notification shade, and many others.

We broke this up into two projects. The first priority will be to work on the quick fixes. These are bugs discovered through reports or our own testing. These fixes won't require an entire refactor of our sync, notification, or database features, allowing us to address user concerns without launching a big project. But we are intending to launch a big project. We'll do whatever we have to in order to make notifications work as expected. That's the second planned project, to consider larger performance improvements, even a full refactor of sync, notifications, and the app database if we have to. Prompt email delivery is essential. We're going to ensure Thunderbird becomes a trusted client for rapid email syncing and notification.

We've also begun investigating potential feature flag options. While we currently have internal feature flags for our debug builds, we're looking into options that we could host ourselves to ensure privacy, while also allowing us to enable features more quickly, without a full update. This would also allow us to roll back any changes that introduce issues without an app update. We hope it can allow us to launch products more quickly, and potentially even give end users more control over the features they have enabled.

iOS

The iOS app is coming along nicely, with the core libraries (IMAP, SMTP, and MIME) set up. We're working on how to store account data in the local database, as well as starting the email compose functionality. iOS will have a WYSIWYG editor for new messages, just as you've come to expect from other email clients. Also, this week has been busy with WWDC and understanding how the new tools and operating system will affect and improve our roadmap, mostly in the user interface.

Our Open Source Community

We wouldn't be who we are without the open source community at our core. Open source isn't just how we build software, it's how we plan, make, and grow. Our community has a say in what we do, which includes making changes, bug fixes, suggesting new features, and voicing complaints - this insight from you is our greatest strength. Over the past month, we've heard requests for new features, bug fixes, and changes, and we've adapted our plans for the rest of the year to focus on this. And hopefully deliver them in more bite-sized pieces.

First, the community has helped drive our upcoming projects. From notifications to investigations into spam filters, our community is helping drive our objectives. Our priorities and our roadmap have shifted thanks to that feedback. With our community having our back, we're making the best email client available on iOS and Android, and can't wait to deliver these improvements. We're listening and working on these highly requested changes.

A notable contribution from our community came in the form of a fix for our notification widget. The text wasn't scaling for users with different font size settings. This is a serious accessibility issue. Fortunately, a contributor pushed a fix which ensures the font size scales with the system. We're grateful for this help, and it's a perfect example of how we build better together.

Becoming a Contributor

Interested in contributing yourself? It can be tough to figure out where to start or how to go about it. Soon starting development on the Thunderbird for Android app will be easier than ever. We're moving our documentation around and adding templates and examples to make everything from requesting new features to working on bug fixes, and even documenting your changes easier. We've also added a new pull request template to help you write a detailed message explaining your pull request. This includes letting us know if you've used AI in the development and to what level it was used.

One note to say with contributions, given our limited team size and resources, we are focusing our efforts on the top items on the roadmap first and foremost. Second, we will spend a couple of weeks solving the largest impact bugs. Then we will spend a week or two supporting what contributions help resolve bug reports or align with our roadmap. We are intrigued about how AI can help us in these efforts, but we are also vigilant about the quality of the code. Potential contributors need a strong understanding of what they are contributing. This means being able to change, improve, and support the code they contribute in the future.

We have just three engineers on each of our iOS and Android teams. We're supported by wonderful designers and product folks, but we also couldn't do it without your support. So, thank you. We're doing our best to make a great product, and with your help, contributions, donations, bug reports, feature requests, and enthusiasm, we're able to do it better than ever. Thanks for checking in with us!

- Danielle G. (she/her), Senior Android Engineer

The post Mobile Progress Report: June 2026 appeared first on The Thunderbird Blog.

16 Jun 2026 11:00am GMT

Highlights

• Maxx Crawford added a pref to hide the New Tab logo so users can opt out of branding without altering page layout or resorting to CSS overrides.
• Harshit enabled video overlay detection in Nightly 153, allowing you to use the context menu to control videos on more pages! We plan on letting this ride out in Firefox 153.
  • You can try it out on this Instagram reel in Nightly

• A note to WebExtension authors - as part of a planned deprecation announced last month, executeScript and insertCSS are now restricted from moz-extension pages starting in Firefox 152 - Bug 2015559
• Nicolas Chevobbe [:nchevobbe] added support and debugging for modern attr()(which is enabled on Nightly) (#2014751)

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• Sam Johnson
• Sebastian Zartner [:sebo]

New contributors (🌟 = first patch)

• Immaculate Atim: Switch to using an array instead of an object string for browser.backup.enabled_on.profiles
• liz: Screenshots overlay visible on both splitview browsers
• 🌟 Rahman Mahmutović [:r_m]: Can't change content in box model in inspector for box-sizing:border-box elements
• Takeru Mitsumori: Fix typo in ID name about-translations-swap-langauges-icon in about-translations.html
• 🌟 Freya Arbjerg [:freyacodes]: Blackboxed columns are ignored
• tom.passarelli: tab-preview-panel emits unpaired popupshown/popuphidden events, breaking sidebar autohide

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

• As part of the work for the Project Nova about:addons page restyling, the about:addons sidebar has been migrated to the moz-page-nav and moz-page-nav-button reusable components, improving accessibility and visual consistency with the Firefox Desktop about:settings page - Bug 1881767

WebExtensions Framework

• Implemented WebExtensions negative permissions infrastructure, providing the foundations for enterprise policy "blocked host permissions" features - Bug 1745823
• Restricted host permission changes for MV3 extensions force-installed via enterprise policy (matching similar behaviors provided by Chrome enterprise policy behaviors) - Bug 1904054
  • Thanks to Mike Kaply for the implementation of this enterprise policy enforcement feature.

WebExtension APIs

• Fixed handling of <all_urls> as an API permission in Manifest V3, ensuring the permission is correctly initialized on extension install - Bug 1758306

DevTools

• Rahman Mahmutović [:r_m] made it possible to edit width/height in the box model section of the Layout panel (#1717176)
• Sebastian Zartner [:sebo] improved toggling tools driving in-page highlighters (e.g. the Measuring) (#1262773)
• Sebastian Zartner [:sebo] added a setting to control visibility of HTML comments in the markup view (#1455294)
• Freya Arbjerg [:freyacodes] fixed an issue in script blackboxing (#2036767)
• Alexandre Poirot [:ochameau] replaced custom preference to log RDP messages with MOZ_LOG (#1622857)
• Alexandre Poirot [:ochameau] fixed retrieval of garbage collected script text content (#1758454)

WebDriver

• Sameem updated the "Take Element Screenshot" command from WebDriver Classic to crop screenshots of elements which exceed the viewport. This aligns with the specification and avoids errors when attempting to capture huge elements.
• Alexandra Borovova updated the events for new top-level browsing contexts: we will not send anymore "browsingContext.domContentLoaded" and "browsingContext.load" events for them, instead the "browsingContext.contextCreated" event will be sent when a tab is ready to be used. This is required to align with the expected per-spec behavior.
• Henrik Skupin landed a patch allowing geckodriver to gracefully shut down Firefox when geckodriver itself is terminated.
• Hiroyuki Ikezoe disabled Firefox's "scroll axis lock" feature so WebDriver actions for wheel input devices can scroll in arbitrary directions when using pan gestures.

Lint, Docs and Workflow

• Added a rule to prevent new uses of Preferences.sys.mjs.
• The browser environment globals within ESLint have now been updated. These include Sanitizer, VideoFrame and a few other new ones.
• Temporal, and some other definitions have been added to TypeScript.

New Tab Page

• Much has happened in the last 2 weeks! Here's a full bug list, and here are some highlights.
• Dre fixed the List widget that was creating a new list too eagerly on the New Tab Page (2033592) - prevents accidental list creation and improves the Lists UI reliability.
• Maxx Crawford fixed Weather widget small card layout issues with opt-in location options and an error message displayed, resolving card overflow and removing the spurious opt-in error so users see a compact Weather card and correct location prompts on New Tab.
• Reem Hamoui added key dates state to the Sports widget, enabling the Sports card to surface event deadlines/key-date highlights on New Tab so sports users see timely date info.
• Scott Downe added a manage widgets option to the New Tab nova widgets context menu, giving users a direct context-menu entry to open the widget management flow from any widget with Nova enabled.
• Scott Downe added a reusable Newtab widget base component to centralize lifecycle, focus/keyboard handling, DOM templates, and telemetry hooks, reducing duplication and making widget behavior more consistent; see Newtab widget base component.
• Dre converted per-widget expansion handling to a shared widget expansion handler to unify expand/collapse state management and prevent widgets from incorrectly retaining or losing expanded state; see Convert widget expansion handling to shared widget expansion.
• Nina Pypchenko [:nina-py] updated the Sports widget to populate the "follow teams" state from the /teams endpoint, so follow/unfollow toggles now reflect server-side subscriptions and reduce incorrect follow states.
• Scott Downe moved widget menu items within New Tab widgets to standardize menu ordering and action grouping, so users find Add/Remove/Configure entries in expected positions across platforms.
• Dre fixed a World Clock city search bug for the word clocks widget, restoring expected search filtering/matching so city lookups return correct results.
• Scott Downe fixed an issue where the New Tab small weather widget size change didn't always apply by correcting the widget size update path (JS/CSS layout interactions), improving consistent rendering for small-tile weather across responsive breakpoints and platforms; see Newtab small weather widget size change doesn't always work.
• Nina Pypchenko [:nina-py] added a group stage section to match highlights in the sports widget on New Tab so users now see stage-aware grouping and stage labels on match highlight cards, making tournament context (group vs knockout) visible while browsing highlights.
• Dre fixed the small world clock widget not expanding to large while editing clocks so users can enter edit mode and expand the widget as expected; the change wires the edit-mode resize handler to update widget size/class during edits.
• Maxx Crawford added WCW OMC message strings so World Cup widget messaging flows on New Tab now display the correct copy (localized where available) instead of falling back to missing-text behavior.
• Reem Hamoui added a "View all" button and a list view for the results tab at medium widget size so Sports widget users on medium New Tab tiles can expand results and scroll full lists without resizing the widget.
• Maxx Crawford added WCW "Watch Live" stream strings to the Sports widget strings bundle so the widget can surface a localized "Watch Live" CTA for applicable events.
• Dre restored VoiceOver reachability for Edit/Remove in World Clock on macOS so macOS VoiceOver users can now focus and activate clock Edit/Remove controls thanks to accessibility role/label and focus-order fixes.
• Maxx Crawford removed the persistent browser logo when all new-tab features (Top Sites, widgets, content feed) are disabled by adding a conditional render guard in the New Tab component, preventing an orphaned logo (2041033).
• Mike Conley added New Tab jest tests to the node tests Tier 1 CI job Run newtab jest tests as part of node tests Tier 1 job to catch regressions earlier in CI
• Irene Ni shipped multiple visual fixes for the Sports widget Sports widget - various visual fixes (spacing, truncation, icon alignment, clipping) to improve readability and layout on constrained viewports.

Picture-in-Picture

• kpatenio adjusted our YouTube site specific wrapper so that the URL bar toggle appears more reliably, especially when selecting videos from the YouTube search page.
• Thanks to Sylvestre for patching some bugs to prevent some spurious console errors!
• Niklas fixed captions on autopip videos failing to sync with the origin videos.

Performance Tools (aka Firefox Profiler)

• Firefox Profiler now has a CLI! We also added a profiler-analysis skill to the Firefox codebase. Once you capture a performance profile, you can ask Claude or an AI to analyze it by providing a link or local path. You can use it to analyze a performance regression or debug an issue if you have a profile at hand.
  • https://www.npmjs.com/package/@firefox-devtools/profiler-cli
  • You can install it with npm install -g @firefox-devtools/profiler-cli@latest

Search and Urlbar

Nova UI refresh

• Drew and Daisuke continued working on reorganizing styles and updating the urlbar for Nova.
• 2019154, 2019152, 2041501, 2040532

Suggest

• Drew landed several Suggest improvements: realtime suggestions colors, sports suggestions received World Cup tweaks, and online Suggest via OHTTP was enabled for eligible users in Firefox 153.
• 2040561, 2039753, 2035614, 2038843

Adaptive autofill

• James fixed soft-block counting to track autofill dismisses, rather than consecutive backspaces on the same autofill, and added telemetry to measure URLs reintegration after blocking.
• 2040819, 2037177

Quick actions

• Dharma created a new Firefox Labs quick action, fixed the Update action button, and re-enabled ScotchBonnet in some tests that were not updated yet.
• Caleb added Calculator support for certain unicode operators.
• 2023169, 1928635, 1923383, 2033861

Multi Context Address Bar

• Moritz continued refactoring the urlbar code: converted some of the js modules to not be system modules, fixed dynamic results templates, incorrect reuse of result rows, and keyboard shortcuts on the unified search button panel.
• 2039297, 2036095, 2039844, 2037933, 2030050

Other

• Marco, Drew and Daisuke fixed several intermittent test failures.
• 2038510, 2023908, 2011584, 1938142, 1971091

Search

• Mark removed old WebExtension-based search engines from the source tree, removed loading of search add-ons from resource://search-extensions/.
• Caleb fixed multiple documentation issues and added a test covering searches from a private window.
• 1904613, 2035878, 2037942, 2033545, 2005724

Places

• Marco removed some unnecessary database transactions, fixed the bookmarks panel folder dropdown on Windows, and resolved several intermittent test failures.
• Thanks to Sam Johnson who fixed the bookmark edit panel showing "mobile" instead of "Mobile Bookmarks".
• 2039534, 1505800, 2008829, 2029541, 2035084

15 Jun 2026 5:26pm GMT

Hi Mozillians,

For years, the Mozilla Community Newsletter has served as a monthly touchpoint for contributors and community members across the Mozilla ecosystem. Coordinated by the Customer Experience (CX) team, it helps keep our global contributor and product communities informed, connected, and engaged through updates, contributor stories, announcements, and opportunities to get involved.

While the newsletter has traditionally been distributed directly to community members, we recognize that many of these updates are valuable to a broader audience as well. That's why we're bringing our content into a blog post format, making it easier for anyone interested in Mozilla's mission, products, and community work to stay informed.

Whether you're a longtime contributor, a Firefox enthusiast, or simply curious about what's happening across Mozilla, we hope these updates provide useful insights into the people, projects, and initiatives shaping our community.

In this edition, we're sharing our latest updates from May 2026. It's packed with the latest community news, contributor highlights, project updates, and opportunities to get involved in Mozilla's work around the world.

So, without further ado, let's dive in!

‍ From localizing to Firefox Enterprise

Long-time Mozillian Valery recently shared an open-source project he built to help Firefox Enterprise administrators manage Firefox deployments more easily called Browser Policy Manager or BPM. Beyond the tool itself, this story is a proof of the long-term value of investing in the community. Stories like Valery's show how community contributions evolve over time and why fostering a strong, engaged contributor community continues to pay dividends across the Mozilla ecosystem.

Learn more about PBM

Firefox Referrals: We want to hear from you

Could Firefox users help grow the community by recommending Firefox to friends and family? That's the question being explored in a recent Mozilla Connect discussion about potential referral programs. Join the conversation to share your thoughts on what would motivate you to recommend Firefox, and what a referral experience should (or shouldn't) look like.

Share your feedback

Web Serial finally arrives in Firefox 151

After years of community interest and requests dating back more than a decade, Firefox 151 now includes support for the Web Serial API. Developers can use Firefox to communicate with and manage serial-connected devices such as ESP boards, Raspberry Pi Picos, 3D printers, CNC machines, and other microcontrollers directly from the web. It's a long-awaited milestone for the maker and hardware community, and we're excited to finally see it land in Firefox.

Learn more

Community spotlight

In this community spotlight, we feature Baurzhan Muftakhidinov, whose work has helped bring Firefox and many other open source projects to Kazakh users. His story is a testament to the power of persistence, community, and the importance of keeping smaller languages visible online.

Read Baurzhan's story

---

P.S.

Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.

12 Jun 2026 11:28am GMT

Mozilla Champions the Reintroduction of the American Innovation and Choice Online Act (AICOA)

Today, only a handful of tech companies shape the online experience for the more than 300 million internet users in America. This concentration of power is exactly why we need legislation that advances competition and user choice. It's all the more urgent as AI transforms not just the tools that people use, but also magnifies the competitive inequities underlying the web itself.

The American Innovation and Choice Online Act (AICOA) is bipartisan legislation designed to curb harmful gatekeeper behaviors of the biggest tech platforms. The bill does so by prohibiting dominant platforms from unfairly preferencing their own products, discriminating against tech competitors, and preventing interoperability - all practices that stop the best product winning and stifle consumer control. The goal is straightforward: companies should compete based on the quality of their products, not by leveraging anticompetitive tactics.

As the builder and operator of the Firefox browser and the browser engine Gecko, Mozilla has firsthand experience with the impact of the exclusionary practices AICOA seeks to prevent. For example, deceptive design tactics deployed by operating systems make it difficult for people to install and keep Firefox as their preferred browser. Browsers are the portal through which people access the open web, and users should define that interaction. AICOA would help limit the ability of operating systems to steer users toward affiliated products through deceptive design choices. Ensuring meaningful user choice online is not just about variety; it reflects values and individual preferences. Openness and innovation thrives when the web is built around platforms that serve people, not the other way round.

Browser engines, while lesser-known, are among the most complex and consequential pieces of infrastructure on the modern internet, impacting user-focused innovations in privacy, security, speed, and more. Gecko is one of only three widely used engines and the only independent browser engine. The importance of that competitive counterweight cannot be underestimated. When platform owners favor their own vertically integrated products, independent challengers face barriers that have nothing to do with product quality and everything to do with a monopolized market.

It's important to recognize that antitrust reform can make the internet more private and secure than it is today, as we've consistently emphasized. For example, in 2021, Firefox was at the forefront of developing technology against cross-site tracking, but could not release the technology to Firefox users on iOS because of app store rules preferring Apple's own browser engine, blocking alternatives like Gecko.

We're champions of AICOA and look forward to working with members of Congress to push this legislation forward and tackle longstanding anticompetitive practices. Mozilla thanks Senators Grassley and Klobuchar for their leadership in advancing competition. A thriving tech ecosystem requires an open, fair, and competitive market where innovative services can compete on merit and people can control their own experiences online.

The post A Handful of Companies Control the Web. AICOA Can Change That. appeared first on Open Policy & Advocacy.

11 Jun 2026 2:05pm GMT