When it's Monday morning and you're on the subway, in a coffee shop, or squeezing in a few email replies after your morning workout, your phone becomes your digital office. But every time you open your browser, you risk getting struck with any combination of distracting ads, auto-playing videos, and open tabs from the previous week competing for your attention.
For many remote and on-the-go workers, your mobile browser can become a minefield of interruptions and distractions, slowing you down when you need to focus most.
Luckily, there are multiple Firefox features that can help ensure your mobile browser is a focused, productive workspace.
Reduce distractions and clutter with Ad Blocker for Firefox on iOS
Opening a link shared via text or email can save time and keep things moving when a client or coworker needs a fast response. However, once it's actually opened, there is a lot of opportunity for various pop-ups, overlays, and ads to get in between you and what you came in to do.
Because Firefox's strong line-up of ad-blocking and privacy extensions on desktop and Android are not available in the same way on iOS, we built Ad Blocker for Firefox directly into the browser. To decide what gets blocked, Ad Blocker uses the EasyList filter and Apple's WebKit Content Blocker technology. It won't impact every ad or sponsored content on a new tab, as those presented directly by host sites and displayed in search results will still be visible.
To try Ad Blocker on iOS, go to Settings > Browsing > Ad Blocker and turn it on to enjoy a cleaner browsing experience.
Get the gist faster with Shake to Summarize
When you're on a deadline, scanning through heavy text, ads, and filler content can turn a quick scan into an infinite scroll session.
Firefox's Shake to Summarize feature helps people get the gist in seconds on both iOS and Android. To use it, simply shake your phone on any web page under 5,000 words, and a clean summary of the page's content will instantly appear. It can also be activated by tapping the "Summarize Page" option under "More" in the three-dot menu.
Like all Firefox features, we built Shake to Summarize with your privacy and protection in mind. This means using device-specific technology to keep your data secure. You can learn more about the AI powering this feature here.
The feature launched on iOS last September, received a strong response from users, and earned a special mention in TIME's Best Inventions of 2025. It is now available on iOS and Android in English, German, French, Spanish, Portuguese, Italian, and Japanese.
Keep your tabs tidy with Tab Groups on Android
Just like us, our smartphones tend to live multiple lives: work, personal, and everything in between. While it can be incredibly convenient to have everything you need for all parts of your life on one device, things can get cluttered fast.
One minute you are knee-deep in a client proposal and the next you're flicking through the countless Google searches from over the weekend. "How old is Harry Styles?" and "Movie times near me" - while pertinent when you were off the clock 24 hours ago - have absolutely nothing to do with the work you are trying to get done now.
To help make sure your prep for Thursday's client meeting doesn't get lost in your pop music deep dive from the weekend, you can group related tabs in Firefox for Android. Each group can be labeled and assigned a color, appearing as a single, searchable card in the tab tray rather than separate tabs, so it's easy to locate when needed. You can open, rename, recolor, and delete these cards whenever you want. To use Tab Groups on Android, simply drag one tab onto another, or select a few and tap "Add to group." Label the group, choose a color, and you're all set. To try it out, download the latest version of Firefox for Android. iOS support for this feature is on the way.
Pick up where you left off across devices with Firefox Sync
Sometimes we start a task on one device and finish it on another. Maybe you found an article on your computer that you want to read on the subway on your phone. Or, perhaps you want to pull out your laptop and finish filling out that lease application you started on your tablet.
Enable Firefox Sync and you can resume tasks you paused in your browser when switching across your mobile phone, tablet, and laptop. The feature lets you access your open tabs, bookmarks, and passwords across all the devices you access Firefox on.
The best part? We put your data privacy first. Firefox Sync uses end-to-end encryption so your synced data is encrypted before it reaches Mozilla's servers.
To take your browsing experience with you wherever you go, connect your iOS or Android phone to your Mozilla account and start syncing with your other devices.
Take back control of your focus with Firefox
For remote and on-the-go workers, focus is everything.
With Firefox features like built-in ad blocking on iOS, Shake to Summarize for instant insights, and Tab Groups on Android to keep your work and personal digital spaces organized, you can transform your phone from a distraction hub into a productive workspace.
Download the latest version of Firefox for Android or Firefox for iOS today to test out any of the above features available on your device - and take back control of your attention.
The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches.
While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.
Overview
GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by cargo install and sometimes the contents of target/.
PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.
GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.
When cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs1. The current code to do so achieves this by storing all environment variables to target/. This, of course, persists when target/ is cached.
If your environment contained secrets, these can now be accessed by PRs via the cache.
Our fix
Our short term fix for this is to make Miri only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.
We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.
Am I affected?
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
The cache is accessible to PRs (common and often the intended use case)
Possible quick fixes include:
Disabling cache for that job.
Scoping secrets to steps in that job that do not call Miri.
Temporarily disabling Miri.
Once done, please clear the cache. Consider rotating any secrets that might have leaked.
The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.
Even if you do not run Miri, ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.
Threat model
We consider it bad practice to have a cache that can easily be tainted by secrets.
If caching target/, it is worth making sure that the inputs to processes that create target/ (anything invoking cargo) do not have secrets available. It is generally rare for standard cargo build/test subcommands to need any secrets or tokens2, so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.
Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.
Acknowledgements
Thanks to Predrag Gruevski of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.
Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.
Miri is invoked multiple times by cargo miri for complicated reasons ↩
In theory it could come up with build scripts reading from the network ↩
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.3 is out on npm.
New features:
New tool: close_firefox_session - ends the browser session: it releases the connection when the server is attached to an existing Firefox, and closes the browser when the server started it.
New parameter: fullPage for screenshot_page - captures the whole scrollable document instead of the viewport.
New parameter: downloadFolder for set_download_behavior - only used when setting the "allowed" behavior, it sets the folder where downloads should be stored and defaults to ~/.firefox-devtools-mcp/output/downloads.
Bug fixes:
No longer fails to find the Firefox binary on Linux with Flatpak.
restart_firefox now rejects when used against a server started with --connectExisting, whereas it used to restart the WebDriver session without restarting the browser and silently ignored all its configuration parameters.
Other changes:
Servers started with --connectExisting now disconnect after 30 minutes without any tool call.
restart_firefox is now part of the mozilla-internal package, and should only be used in controlled environments, as it allows the agent to restart the browser with a custom configuration. Instead, the new tool close_firefox_session can be used whenever clients do not need to update the browser configuration, and will have a more consistent behavior.
Path checks for the saveTo parameters have been improved to avoid overlapping with existing profile folders
Install:
claude mcp add firefox-devtools npx @mozillamozilla/firefox-devtools-mcp@latest
For internal Firefox development, swap firefox-devtools-mcp with firefox-devtools-mcp-moz in order to benefit from additional tools, such as chrome-privileged script execution.
Special thanks to all the contributors who filed issues and submitted patches for this release: f3tch (github), shoemoney and mightykatun.
Today at ALL IN, Canada's largest AI and technology event, Mozilla and Mila announced a new initiative and fresh investment to build an open source AI foundation layer that enables organizations and institutions to own and operate advanced AI systems locally, ensuring full control over their technology and data.
Doubling down on its commitment to open source AI, the Government of Canada announced its support for the initiative. Mila will lead the technical delivery and coordination of the project, while Mozilla contributes technical expertise. It also provided the initial $5 million investment to kick off the project. Hypertec is committing an additional $1 million in first-year funding to accelerate initial Canadian deployments of the open source AI foundation layer on Hypertec hardware.
"Canada has a choice: depend on technologies developed elsewhere, or build more of what we need here at home," said The Honourable Evan Solomon, Minister of Artificial Intelligence and Digital Innovation and Minister responsible for the Federal Economic Development Agency for Southern Ontario. "Open source AI gives Canadian businesses and institutions greater control over their technology and data, while making powerful tools more affordable, accessible, and easier to adapt. By supporting this work, we are strengthening Canada's capacity to build and adopt AI on our own terms."
Mila and Mozilla will lead the work together: Mila drawing on a world-class community of close to 2,000 researchers and professionals, Mozilla as technical partner from industry, bringing 25 years of experience stewarding open infrastructure others build on. Mila and Mozilla are actively engaging new partners, inviting companies, research institutions, funders, governments, and developers to join and support this work.
What's being built
The goal is simple: make owning your AI as easy as renting it. Using open source models was never the hard part. Turning a raw open source model into something a small business, a hospital, a local charity, or a government can run in production - secure, reliable, plugged into everything else - takes an engineering team most organizations and institutions do not have and months they can't spare.
The goal is to offer businesses and organizations a ready-to-use AI package that they can run privately and keep under their own control, rather than having to build a complex system themselves or rely entirely on expensive, pay-per-use proprietary AI services.
For example, a small manufacturer could use the system as a private AI assistant for its employees. It could search the company's manuals, procedures, and past project files; help staff draft reports or answer technical questions; and help its software team write and improve code. Because the system is designed to be able to run locally, the company could do this while keeping its proprietary information and data within its own environment.
That also means lower costs. For the vast majority of everyday business tasks, companies will be able to use open source AI running on open source tools instead of paying a commercial provider every time an employee makes a request. But this requires reducing the technical work and expense involved in putting open source AI into practice.
This initiative was founded to solve that problem, building the free layer that makes owning open source AI easy - the same kind of layer the web was built on. It has two halves: An open standard, published as interface contracts, so any part of the stack can be swapped for a better one. And a working "reference implementation" any organization can install on its own machines or the ones it chooses, running the models and controls it chooses against its own data, with governance and access control built in from the start. The ambition is that with the standards and foundation in place, open source AI can be built anywhere, by anyone.
"Six months ago, we announced our partnership with Mozilla to advance open source and sovereign AI. Today, we are bringing that work to a whole new level," said Valérie Pisano, President and CEO of Mila. "By delivering an open, secure AI foundation layer, we empower organizations, from small businesses to non-profits to governments, to own their technological future so they can run, control, and maintain AI models themselves. At Mila, our research community has always believed that for AI to be trustworthy and accessible, it must be built on open standards that keep control in local hands."
The work already underway
Over the last six months, Mila and Mozilla have been designing the architecture, deciding which open source components belong at each layer, and testing that the whole system works end to end. This investment builds on that progress.
Working alongside Mila and Mozilla, Hypertec will help move the initiative from research and reference implementation to real-world adoption by Canadian businesses and institutions, providing a practical, private, and cost-effective path to deploy AI while maintaining greater control over their data and technology.
"AI is advancing at an extraordinary pace and has the potential to transform our economy and society for the better. Canada has an important role to play in ensuring that AI is developed and adopted responsibly, said Simon Ahdoot, CEO of Hypertec Group. "Hypertec is proud to help turn open source innovation into AI that Canadian organizations can deploy securely and under their own control. This is exactly the kind of partnership between government, research, and Canadian industry needed to realize the full potential of AI."
Why now
Mozilla's State of Open Source AI report found that while 79% of developers adding AI functionality use open models, only 53% of teams ever reach production, stopped by cost, security, integration, and maintenance. This work aims to change that.
"AI today is at a crossroads, where it could be closed and owned by a few, or open and available to every coder, developer, enterprise, and nation," said Mark Surman, President of Mozilla. That's what we're building - an open source AI ecosystem that fits together as seamlessly as the web, and that anyone, anywhere can build on. We're so grateful to Canada for scaling this work, and call on partners across sectors - from enterprises and governments to coders and startups - to join us in building this future."
Within six months, Mozilla and Mila expect to publish working reference implementations for enterprise, government and public-interest use cases. The two-year ambition is bigger: to have solved this problem outright, so that open source AI can be adopted fully and easily, anywhere, by anyone.
The DevTools team has made it possible to inspect and edit stylesheets from within the JavaScript Debugger pane.
The feature can also be enabled from the experimental section in the devtools settings panel, or by setting devtools.debugger.features.stylesheets-in-debugger to true in about:config.
Restyled the Extensions panel empty states to match the Figma specs, including a new illustration for the disabled add-ons and private browsing states - Bug 2058450
Fixed a jiggle effect when scrolling through theme previews in about:addons - Bug 2059917
Added spacing between message bars and their sibling elements in the about:addons page (empty state promo, theme appearance mode control) - Bug 2066436
Set focus on the extension permissions prompt dialog so keyboard users can reach it - Bug 2059855
Removed activeAddons/activeTheme/activeGMPlugins from the legacy telemetry environment, now collected only through Glean - Bug 2055613
DevTools
Nicolas Chevobbe [:nchevobbe] fixed an issue in the inspector to stop showing the HTML editor for nodes (e.g text or whitespace nodes) which should not be editable when F2 is pressed. (#2064213)
Sebastian Zartner [:sebo] updated the documentation for the Rules view to include details around the @media emulation panel added some weeks back. (#2063851)
Chris Van Linden fixed an styling issue in debugger editor file search bar where the button hover background overlapped the focus outline (#2063466)
Nicolas Chevobbe [:nchevobbe] fixed an a11y issue where the keyboard focused sliders in the fonts panel did not have the correct contrast against the background. This allows keyboard users to easily see which control currently has focus. (#2062576)
There is no automation for the core type updates yet.
However, several areas have been working on support, hence the promotion to tier 2.
Until we get the automation in place, we will not be ready for wider roll-out, as it will be more likely that core patches will break the TypeScript reporting.
New Tab Page
Developer experience improvement: it's no longer necessary to create the WebPack bundles when updating New Tab JSX / SCSS files. This occurs automatically during the ./mach build [faster] step. Thanks to Nathan Barrett for his work there!
Mike Kaply made it so that New Tab Settings honor Locked Preferences in policy by making the New Tab settings UI read and respect policy-locked preferences and disabling corresponding controls so managed/enterprise users cannot override locked prefs from the settings surface.
Nina Pypchenko [:nina-py] added a small size to the Stocks New Tab widget, introducing a compact 1×1 Stocks tile in the Firefox New Tab Page layout so users on narrow windows or dense NTP configurations can keep Stocks visible without consuming medium/large slots.
Nina Pypchenko [:nina-py] added ticker search to find and add individual stocks, adding a search/lookup UI and add flow that calls the ticker lookup API and updates widget state/local storage so users can search, add, and immediately see new symbols on their New Tab Page.
Bryan Olsson added a plural selector to the Fluent string newtab-stocks-watchlist-full in the New Tab Page localization so the Stocks widget shows correct singular/plural wording for watchlist sizes across locales, fixing grammar that could confuse users when their watchlist count changes and touching the NTP stocks string bundle used by all localized builds.
We've also started rolling out an experimental Privacy widget
Reem Hamoui changed the Privacy widget copy color to grey in the New Tab Page so the "Nightly blocks trackers as you browse. You will see them here." text displays with correct muted contrast (2063205).
Reem Hamoui restored the ETP OFF state rendering in the New Tab Page privacy widget so the widget shows the actual ETP OFF status instead of misleading 'blocks trackers' copy for users who disable ETP (2063525).
Reem Hamoui applied UX fixes to the New Tab Page privacy widget to correct alignment, labels, and click-targets so users see and interact with the widget reliably and accessibility attributes behave as expected.
We've also started tinkering with some new layout variants
Here's one such layout (widget column on left):
Irene Ni updated SectionsLayoutFeed's 7-double-row-2-ad fallback to match Remote Settings so feed layout and ad fallback counts align with remote config, reducing layout mismatches and incorrect ad placements in feeds using the fallback (2063684).
Irene Ni implemented a carousel card type for the New Tab feed, adding slide-based card rendering and navigation hooks so users get swipeable/rotating cards in the carousel component.
Dre cleaned up orphaned wallpapers in the wallpaper service to remove broken entries and reduce wasted storage so users no longer see missing background tiles.
Nina Pypchenko [:nina-py] fixed wallpaper attribution rendering in the Nova New Tab flow by adjusting the Nova-specific NTP component's conditional rendering (CSS/JS) so the attribution node is not skipped when the nova feature is enabled, restoring photographer/credit metadata on New Tab pages for users on Nova-enabled desktop builds and preventing missing attribution UX.
We're in early days in building out the infrastructure for a Recent Searches widget
Nina Pypchenko [:nina-py] added a blank widget scaffold to the New Tab Page widget registry for the Search team (bug 2065011), creating a no-op/placeholder widget registration hook so the Search team can iterate on experiments without changing current NTP visuals - no immediate visible impact for end-users until the widget is populated.
Drew fixed alignment of the explanation text on various result types. Bug 2063460
Drew enabled more providers (like Wikipedia) for DE, FR, IT regions. Bug 2064557
Drew updated important dates suggestions for 2027 in DE, FR, GB, IT and US regions. Bug 2064437
Dao fixed a regression with the result menu being empty on certain results. Bug 2066758
Adaptive autofill
James is analyzing results of experiments and working with Product to let the feature ride to Release in the near future.
Quick actions
Dale improved the Open Firefox Labs action. Bug 2063849
Dale improved styling of disabled actions. Bug 2056488
Multi Context Address Bar
Dao and Moritz made great progress with having the urlbar code work in different contexts, including across processes.
Dao migrated some text input context menus (address bar, search bar, Thunderbird compose subject) onto a single shared menu with a new custom-item API, allowing removal of the legacy moz-input-box component.See EditContextMenu for documentation and usage. Bug 2064369.
Dharma started refactoring the urlbar code to use extended classes. Bug 2064728
New tab search bar has been enabled in Nightly! Bug 2062212
This is the second part of a two-part series in which we explore approaches to protecting children online while safeguarding privacy, security and the open web.Part onecovers our concerns regarding age gates, and suggests alternative policy proposals that address the root causes of online harms. Part two explores better ways to build age assurance architectures that respect users' rights and autonomy.
Across the world, legislation to introduce age gates and social media bans is proliferating. Many governments are still considering age restrictions a straight-forward and cost-effective tool to achieve their child safety goals. However, evidence is mounting that age assurance mandates pose risks to users' privacy, security, free expression and access to information, threaten the open web and competition, and undermine policymakers' goals: enabling young people to have safe and trustworthy experiences online, while enabling the digital economy to grow.
As we have said before, we believe that blunt tools like social media bans are overly broad, undermine users' rights and do not address the root causes of online harm. Reducing risks to young people online requires a holistic, privacy-first approach to online harms emphasizing enforcement of existing rules, addressing harmful design, and equipping all users with better defaults, more choice and granular controls over their experiences online.
Age gates alone are insufficient to address online harms, but age signals can contribute to more holistic approaches by helping achieve age-appropriate experiences online. Where age assurance obligations are considered as one tool out of many to foster age-appropriate experiences, their potential benefits must be balanced against their negative implications for users' privacy and security, access to services, and the openness of the web.
From the service to the device - taking stock of regulatory models
Implementing age assurance is not a single intervention, but a series of steps. A user's age is first assessed, which can happen through a variety of sources of age information and with varying degrees of accuracy. That signal is secondly shared with the actor responsible for age-appropriate experiences, and thirdly acted upon or enforced by that actor.
Dominant approaches to age assurance obligations focus on online platforms - given that this is where many risks encountered by young people unfold. In practice, this has led to online services - websites or apps - turning to third-party age assurance providers to perform age assurance, whether through biometric age estimation, age inference based on users' behavioral data, ID-based checks, or other methods.
In this model, third-party age assurance companies both assess users' ages and share that signal with the platforms responsible for implementing it. To retain access to social media platforms, messaging services and many other online offerings, users are thus forced to surrender their sensitive personal data to these age brokers, often a different one for each service.
Once in the hands of these providers, peoples' data is at risk of being sold, repurposed or accessed by law enforcement. The recent data breach of a ID and age verification provider that exposed more than 153 million IDs underscores that this is not a theoretical concern, but a significant risk for anyone asked to prove their age online. Rather than being asked to trust companies, some of which have already been exposed for their harmful data practices, people deserve verifiable guarantees that their data is safe and secure.
Emerging regulatory models are considering the role that device intermediaries, like operating systems, device manufacturers, and app stores, can play in age assurance. In such models, these actors are either required to communicate an age signal to the actor responsible for acting on it, or to restrict access to services themselves, based on an age signal created at the device level.
Device intermediary focused approaches, too, come with significant challenges: Given the significant concentration of power among (mobile) operating systems and app stores, such a legislative design can easily further entrench the dominance of Apple and Google, disadvantage open source competitors, and undermine users' privacy and control, including over their devices. These implications must be carefully mitigated.
Principles for better age assurance architectures
Every approach to age assurance comes with important trade-offs, and we maintain that there is no age assurance system that mitigates all risks to users' fundamental rights, access to services, competition and the open web, while being effective in avoiding every instance of under-age access. However, we do believe that better age assurance architectures are possible. In many situations, unverified age signals may be sufficient to provide age -appropriate experiences without undermining fundamental rights. Where stronger assurances are considered necessary, zero knowledge architectures can help protect users' privacy.
Better age assurance architectures must be private, secure, accessible to all users, and, crucially, must provide them with autonomy, choice and control. Designing age assurance obligations that live up to these values is a question of governance, not technology. Hence, policymakers have a crucial role to play in defining requirements for rights-respecting age assurance systems.
1. Assignresponsibilities deliberately.
From people's devices, to operating systems, app stores and websites or apps, many actors can be involved in age assurance processes. Some of these actors will be better suited to be responsible for certain steps of age assurance processes than others to avoid negative outcomes for fundamental rights and the open web.
Given that websites and apps know most about their services, their features and content hosted, we argue that they are in the best place to act on age signals to provide age-appropriate experiences. Implementing age signals at this level allows for more granular choices for creating age appropriate experiences. Other actors, like network operators or device vendors, simply do not have the necessary information.
While websites or apps are best placed to create age appropriate experiences, device intermediaries like operating systems are well-placed to facilitate the privacy-preserving sharing of age signals created locally. Moving age assessments to the device-level allows users to interact with an age provider once, rather than having their age assessed by a different age provider for every service they use. If such approaches are pursued, strong protections need to be in place for open source operating system providers, as well as mandates for the development of open and free standards to avoid fragmentation and competition harms, and to strengthen transparency and user consent
2. Ensure choice, equity and accessibility.
Age can be attested to, approximated or verified in many ways. Every age assessment method comes with important trade-offs, but people should not be forced to take risks on their personal data and safety to retain access to services and information. Users should thus always have a choice between multiple age providers that are privacy-preserving, non-discriminatory and accessible. This is especially important for young people who often don't have access to more privacy-preserving age assurance methods, and are expected to hand over their biometric data to stay online.
The question of which providers are deemed trustworthy enough to participate in such a system is a crucial one. Policymakers must ensure that the options available to people protect their privacy and security, and that a diverse list of providers prevents people from being locked out. Only if everyone has the ability to access age assurance systems through privacy-preserving and rights-respecting providers, will the web remain accessible and open. People should be able to rely on a plurality of institutions, government or private, that can either attest to their age, including face-to-face, or have existing knowledge of their ages that they can share through the use of anonymous credential technology. Examples might be banks, public health and educational institutions, libraries, or services like phone providers, ISPs, subscription services or other services that are able to attest to a user's age.
3. Put people in control.
We should always be in control over what information is shared about us, and to whom. Once an age signal is created, age assurance architectures should empower users to hold that signal - in the form of a credential - on their device. Whether an age signal is shared with an app or website by the operating system or the browser, users must be in control of the decision whether and to whom that information is shared with.
Users must also retain control over - and trust in - their devices. Digital devices are the interface through which we all navigate increasingly large parts of our lives; they are our trust anchors. Enforcing restrictions at the device level on what people can or cannot do online would undermine the already fragile trust relationship between the two - pushing people toward less secure workarounds, rather than addressing the underlying policy concern.
This means that it is best when responsibility for sharing the results of age assessments is performed by users and their devices.
4. Assess risks end-to-end.
Many jurisdictions require age assurance systems to be "highly effective". We believe that the effectiveness of an age assurance system should be considered end-to-end, and not be limited to the assessment step: After all, where an older relative or friend is willing to help a child circumvent a block, no technical mechanism can be effective.
Given these considerations, we think there is value in considering age assurance approaches that empower parents to attest to their child's age when setting up their device. Coupled with barriers to resetting the age once set, such an age signal would provide a high degree of confidence without requiring invasive proofs of age through biometric analysis or ID document checks. As noted above, such approaches need to ensure that age attestation is not another factor cementing the dominance for a few actors, and that open source projects are meaningfully protected from being locked out of participating in a market.
Despite those challenges, we believe that it is crucial to not only consider the potential risks young people could encounter online, but also the risks flowing from age assurance systems themselves. Given those risks, parental age attestation can be a lower-risk approach suitable in many contexts.
5. Leverage zero-knowledge architectures.
Where high-assurance age credentials are used, zero-knowledge architectures are the right step towards sharing age signals in a privacy preserving way. Such approaches allow users to verify the truth of a statement about them, like their age or age range, without having to reveal the information on which the statement is based.
While zero-knowledge architectures are promising, they do not solve every issue. Beyond limiting disclosure of information about people (such as attributes other than their age), hiding the issuer of age credentials (like a bank, public service or educational institution) is key to preserving users' privacy and choice of assessment methods. This prevents discrimination against users of smaller or less common age providers.
Likewise, the issuer of an age credential should not know which service or feature someone is accessing with an age proof. The example of Spain's Catera Digital, or "porn passport", shows why: The Spanish age verification system created tokens that the verifying authority could use to infer a user's browsing history, undermining users' privacy, trust, and ultimately the adoption of the system.
Zero-knowledge proofs themselves also do not prevent abuse of age information, such as by using age data in ad targeting. Beyond strict prohibitions on repurposing age data, we believe that any age assurance system should be open source to facilitate trust, accountability and transparency.
To prevent the sharing of age tokens, we believe rate limits, which restrict how often an age token can be used, are the best and most effective solution. We strongly caution against linking tokens to attested hardware, such as trusted platform modules (TPMs). Hardware-bound tokens force users to use specific, approved hardware. Hardware attestations can leak details about the device's configuration and location, thus enabling tracking or unjustified discrimination at the moment of certification issuance. Attestations undermine users' freedom over their own devices, including what software they can install and run. People who run older or unsupported devices might be excluded as old, weak hardware is routinely found to be compromised, such that it needs to be revoked. Rate limits offer a far simpler and more robust answer to these challenges.
6. Don't break the internet.
The open internet - and the web built on top of it - is a global public resource that millions depend on every day, and that has become a cornerstone of our societies. This openness thrives on open standards, shared protocols, and interoperability. Age checks risk fragmenting the web in more ways than one: Incompatible requirements will create a patchwork of age-gated communities, and age gates in the hands of a few will push people further into closed ecosystems, undermining the wider digital competition and the decentralization that gives the internet its strength.
To avoid the hollowing out of fundamental rights online, and the undermining of the open internet, international collaboration and free and open standards are urgently needed to govern age assurance across borders.
***
We believe the principles set out above can help mitigate the large-scale erosion of privacy, security, and agency that the first wave of age assurance laws and social media bans has introduced.
But improved legislative mandates and technical fixes alone are not enough to improve young people's online experiences in a rights-respecting way. Enabling young people to develop positive relationships with digital technologies is foremost a societal issue, not a technical one. Changing norms around how we engage with technology, what we ask of companies seeking our attention, and how we have conversations about what safety means beyond abstinence and control will require a whole-of-society approach to digital well-being.
We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware.
What we've seen
A video call is set up for something positive - maybe for a job, maybe for a project, maybe for a contract opportunity - and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard).
These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection.
Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust - ideally, try to be the one who sets up the call on a platform you already use.
Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on.
If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help.
Bug 2069143 - When retrieving comments for a bug(s) via REST API, remove comments that would be collapsed in the web UI unless explicitly asking for them
Bug 2070247 - Support limiting who can needinfo the Hackbot account
Bug 2061445 - Migrate Bugzilla (system info) REST resource to native Mojo API
Bug 1877201 - Post to bug/{bugid}/comment returns wrong comment_id
Bug 2072224 - Update REST API authentication documentation to reflect per-resource migration to native Mojo auth
Bug 2060932 - Support GitHub-style <details>/<summary> collapsible sections in comments
Bug 2072689 - Buglist link on My Dashboard is broken
The AI race is shifting. Again. Practically overnight, competition has expanded from "which AI model is best?" to a new high-stakes battle over which models people can access, through which products, and whether people have meaningful choice about AI at all.
In response, Mozilla and Mistral today announced a partnership built on a shared idea: a new, open-source AI model alternative to Big Tech-default browser ecosystems. The intent: a model deliberately designed to keep the web open to technological diversity, competition, and choice.
And we're putting this idea into practice in Firefox.
Mistral Small 4 is coming to Firefox Smart Window beta (learn more about Firefox Smart Window here), becoming a new AI model for Smart Window users in the US and Canada, while expanding Smart Window beta access and French-language support to Firefox users in France. Across all markets where Smart Window beta is available, Firefox users can still choose from a multitude of other AI models.
"AI is becoming part of how people experience the web every day. We want to make sure that doesn't mean people are chained to one company's self-serving pipeline. With the browser sitting at the heart of the web and online experience, it should be a place where different AI providers can compete and open source has a seat at the table.
This isn't just a product partnership. A browser shouldn't be a one-way funnel. It should preserve what made the internet powerful to begin with: the freedom to explore, discover different ideas and tech, and decide for ourselves where to go next," said Anthony Enzor-DeMeo, CEO of Mozilla Corporation.
Choice and competition are worth protecting
As AI integration becomes increasingly concentrated, we are in jeopardy of a handful of closed-model companies controlling the browser, the search engine, the AI model, and the surrounding services that connect them. Mozilla and Mistral are betting that independent and interoperable models can offer an alternative to global tech monopolies controlling the next digital era.
"This partnership represents two open source advocates working together to bring Mistral's scientific innovations to Mozilla's consumers around the world. Together, we are bringing privacy, control, and choice to AI-powered web browsing," said Arthur Mensch, Co-founder and CEO of Mistral.
Meaningful choice isn't confined to personal preference for one AI model over another. Web products need to be able to work with different AI providers, and people deserve the option of switching without being locked into a single company's ecosystem. When a tech layer as far-reaching and influential as AI is controlled by a small handful of players, it risks creating closed systems and closed doors, making it harder for new ideas and better technologies to grow, reach users, and compete on merits.
Mozilla and Mistral aim to keep that door open. The combination of an independent browser with a frontier European AI company gives people and institutions greater access to useful, responsible AI, the opposite of locking them into one company's singular technology ecosystem.
Selecting Mistral, and expanding to France
Mozilla selected Mistral Small 4 after evaluating its performance for Smart Window Beta, including multilingual performance, an important part of the fit. The companies approached multilingual and multicultural tuning as a core model feature, rather than simply adapting an English-first experience for a new market.
For Firefox users, Mistral access starts with Smart Window Beta, a browsing experience designed to turn AI into a useful assistant for the things we do online: making sense of complex search trails, finding something valuable you clicked away from, presenting data sources, and generally picking up where day-to-day internet use got left off.
France is the first new market for Smart Window with official French-language support. Mozilla is planning additional European expansion later this year.
A different kind of AI competition
Our Mistral partnership puts an ambitious new AI model approach into practice: a multilingual, globally competitive European AI company reaching people through an independent browser, leveraging openness to create more room for new technologies to compete and succeed. Mistral can reach Firefox users without owning the browser, and Mozilla can integrate and recommend Mistral without removing user choice.
It is a natural extension of the principles that have shaped Firefox and the open web, and the kind of AI ecosystem we intend to continue building.
EDIT: Updated to reference gh correctly. Thanks flod!
Sometimes on Github, I need to fetch a patch from a fork I don't typically see everyday so I can try it out locally. I use the line at the top of the patch which has a copy button next to it because it's convenient.
The common steps for this are:
Click the contributor's branch and go to their github fork repository.
Copy the repository link.
Add a new git remote with an alias (typically their username).
git fetch <alias>
git checkout <alias>/<branch>
Here is a one-liner for it that you can add to your gitconfig:
You might ask, why do all of this when the github gh CLI does this for you? While it does simplify some tasks, I wanted a solution that was independant to a specific git host. The git@github.com remote that is used in the alias can be changed or made configurable if desired. This is something that I wouldn't be able to do with platform-dependant gh.
The fetch also works well with jj too because the fetch and checkout remain headless.
Formatted and commented, it looks less intimidating:
f() { # Get the repository name from your checkout (assuming it is the # original directory name as the remote). PNAME=$(basename `git rev-parse --show-toplevel`); # Parse out the fork's owner. # Example: `<owner>:<branch>` OWNER=$(echo $1 | cut -d':' -f1); # Parse out the branch name. # Example: `<owner>:<branch>` BRANCH=$(echo $1 | cut -d':' -f2); # Do a fetch of that particular branch using the extracted # information from above. # This assumes the remote is hosted on github. git fetch git@github.com:$OWNER/$PNAME.git $BRANCH; # Checkout using the alias `FETCH_HEAD` which git provides. git checkout FETCH_HEAD;};# Execute the function!# It's easier to build a function that holds variables and execute# rather than in-line it.f
Comments
With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below.
Learn how this was implemented from the original source here.
<noscript><p>Loading comments relies on JavaScript. Try enabling JavaScript and reloading, or visit <a href="https://mindly.social/@jonalmeida/117279142568496801">the original post</a> on Mastodon.</p></noscript>
<noscript>You need JavaScript to view the comments.</noscript>
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.
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.
Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!
Some of these tasks may also have mentors available, visit the task page for more information.
No Calls for participation were submitted this week.
If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!
Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.
No Calls for papers or presentations were submitted this week.
If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!
There were almost no regressions this week, and several performance improvements! Though some of them were reverts of regressions from a previous week. #162422 improved the performance of Polonius, whose performance is getting closer to the previous NLL borrow checker.
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.
Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub. In his own words, here is a look back over the past year!
First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about. Some highlights from that funded work that I'm proud of:
On top of that, I spent time diagnosing unexpected failures in others' PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.
A few pieces of work from this period that stand out to me:
supporting a large scale rewrite of Servo's JS engine integration to address intermittent panics related to garbage collection-I reviewed lots of pull requests, but also filed many issues that enabled the work addressing the panics to be spread across many other contributors
supporting another contributor's grant proposal to work on Servo that was approved!
This role I've carved out means a lot to me-I've found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others. A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference! I'm excited to see what's possible in the coming year.
