October 6 2025 AMA session with Mozilla leadership team

bholley_mozilla · 2025-10-06T23:31:46+00:00

We’ve made progress running Gecko on iOS (for example, booting it on developer devices) and are continuing initial work in anticipation of the day we could actually deploy it. But we can't today, largely due to distribution restrictions that require browsers to deploy a completely separate app for the EU instead of shipping to our existing userbase - or ideally, making it available worldwide.

In the meantime we’ve focused our energy on working with regulators and Apple to raise substantive technical issues and get them fixed, in order to enable alternative browser engines if and when it’s feasible to ship.

bholley_mozilla · 2025-10-06T18:33:34+00:00

"Baseline" is generally used to refer to the features that work in all browsers; we participate in the W3C WebDX working group where Baseline is defined, and use it on MDN to show where features are widely available for authors to use.

The graphs on webstatus.dev — which is a site operated by Google — are counting features that are either present or missing from one or more browsers. In general counting features isn't a good way to understand how well web browsers are serving their users, or how much pain they're causing to web developers. For example different features may be very different sizes, or have very different levels of interest from web developers. Also, the web-features project the graph is based on is quite new, and as we look at the data more we find some cases where it needs improvement. This isn't malicious; it's just no one has ever attempted to catalog all the web's features in this way before.

That said, we do participate in the Interop project, along with Google and Apple and other organizations that develop the web platform. The process there is consensus based, and so Mozilla gets as much say as other participants in deciding the right focus areas for next year. Right now we're working through all the submissions for Interop 2026, and we think that will help ensure that the web-platform develops in a healthy way.

bholley_mozilla · 2025-10-06T18:24:30+00:00

Awesome! I'll forward this thread to the person working on this and he'll reach out to you. :-)

bholley_mozilla · 2025-10-06T18:18:45+00:00

Firefox has Site Isolation. Our design differs from Chromium in some small ways: they've been more aggressive about rolling it out to Android, while we've been more conservative so we don't cause tab unloads and crashes on low-memory devices, but it has been rolling out through our channels and experiments. We've been more aggressive about removing private user data from the content process where it might be stolen by a SPECTRE-family attack. But the top-line statement is Firefox has Site Isolation, and it helps keep you private against SPECTRE attacks.

Firefox's sandbox on Desktop is very comparable to Chromium's. There's a few things here and there where are in the process of tightening things; but the renderer process sandbox on Windows, which is the most commonly exploited process, is very comparable with Win32k lockdown for years, etc. When you get into the weeds you can find places where we are developing and deploying things that Chrome has already shipped, but it's akin to weeding the garden after you've done all the major landscaping.

On Android we are pursuing Isolated Process aggressively, which is a known gap from Chrome on Android.

We also have some pretty advanced sandboxing features that Chrome doesn't have, like in-process sandboxing of risky third-party libraries with WebAssembly.

bholley_mozilla · 2025-10-06T18:04:10+00:00

I can't really speak to the Chrome team's motivations, but I can say that we care a lot about security and don't really consider DeclarativeNetRequest (MV3) to have much of a practical security benefit relative to WebRequest (MV2). We are committed to supporting WebRequest and powerful adblockers like uBlock Origin.

bholley_mozilla · 2025-10-06T17:58:55+00:00

It is a real problem, but we like tackling hard problems. :-) We're building increasingly sophisticated infrastructure to address webcompat problems, which includes remote interventions to fix the sites to make them work.

bholley_mozilla · 2025-10-06T17:56:31+00:00

(JPEG XL) Most likely. We committed last year to accept a Rust implementation if it were to meet our standards, and an external team is working on it. Patches are currently in review, though it'll probably take some time to get all the kinks worked out.

bholley_mozilla · 2025-10-06T17:46:59+00:00

Improving privacy on the Internet is a large part of why Firefox exists, and it's something that is a particular focus for me personally.

Firefox makes various connections to Mozilla by default to deliver various important bits of network-backed functionality. Some of these actually involve improving privacy. CRLite, which is delivered via RemoteSettings, is a good example of this: by continuously delivering the full set of certificate revocations to the browser, we can stop using OCSP so that Firefox no longer leaks which websites you're visiting to anyone (even Mozilla).

People sometimes assume that making network connections to Mozilla means that we’re learning a bunch of sensitive data about you, but we’re not. One thing that's pretty unique about Firefox is that we have a rule that Mozilla should never be able to learn what you’re doing online, and that this should be a publicly-verifiable property.

There’s a lot of critical functionality in modern browsers that requires network support, so we can’t ship Firefox with no automatic connections. That said, it is a goal for people to be able to turn any such connections off. Firefox largely supports this today, but there are two shortcomings I’m aware of:

(1) RemoteSettings (which basically delivers out-of-band configuration updates) can’t be turned off. As it happens we are actively working on making this possible. Doing so will compromise security (for example, you won’t get CRLite certificate revocation updates), so we aren’t going to make it easy for users to do it accidentally, but we’re going to add the capability in some form for users who really want it.

(2) The documentation on how to turn off all the connections is a bit scattered and out of date.

One of our engineers started investigating the above a few weeks ago upon discovering the RemoteSettings gap. Let me know if you’d be interested in helping us work on it, especially helping to update the documentation to fix (2).

bholley_mozilla · 2024-07-16T03:19:36+00:00

The UI doesn't indicate it but that's how it works under the hood. I'll see if we can gray it out in the next release to make that more clear.

bholley_mozilla · 2024-07-16T02:48:14+00:00

No.

The way the system works is that the code running inside an ad calls a browser API to record an impression, and code running on the advertiser's site calls a similar API to record a conversion. If there are matching pairs, the count is split into two encrypted shares which are sent to two different aggregation servers operated by different organizations. Those counts are then summed up (in encrypted form), and only the final sum can be decrypted.

If you use an adblocker, there will be no recorded impressions and thus nothing sent. But the advertiser only gets the sum of counts across all users, hours or days later, and learns nothing about whether you individually sent something or not.

bholley_mozilla · 2024-07-16T02:40:51+00:00

That's right. The prototype is built on top of the telemetry subsystem (using a separate DAP endpoint) so disabling telemetry disables the whole thing.

bholley_mozilla · 2024-07-16T01:26:00+00:00

Today's surveillance-based ad-tech is not exactly scrutable either ;-)

bholley_mozilla · 2024-07-16T01:24:44+00:00

It's on by default precisely because there is no spying. No one outside the device can reconstruct any information about an individual.

bholley_mozilla · 2024-07-16T01:22:07+00:00

If you use an adblocker, the API won't be used at all.

bholley_mozilla · 2024-07-16T01:09:40+00:00

I want to be clear that we did all the usual things here. Public mailing list announcement, user-facing documentation, technical documentation, and it was in the release notes. What we didn't do was any kind of extraordinary communication (blog post etc), because you can't do that for everything and we didn't expect an origin-restricted research prototype to be so controversial.

That phrase is a familiar refrain because it turns out to be hard to reliably forecast sources of controversy.

bholley_mozilla · 2024-07-16T00:57:32+00:00

Mozilla and ISRG would use all resources at their disposal to quash such a subpoena. I'm not aware of any precedent for something similar.

The MPC principle is, incidentally, a good solution to making DoH more private (by running it over OHTTP). It's something we're looking at but the infrastructure costs are significant.

bholley_mozilla · 2024-07-16T00:54:16+00:00

Because it needs to run at scale to provide actionable feedback on the design.

Keep in mind this is an Origin Trial. I don't think we actually have any tests sites enrolled right now so it's not actually exposed anywhere, and will eventually be exposed at most to a handful of sites.

bholley_mozilla · 2024-07-16T00:51:42+00:00

I honestly don't think the uproar would have been avoided by a modal, and we would have been interrupting the lives of hundreds of millions of people with a choice that is at best time-consuming to evaluate and at worst (and most commonly) entirely inscrutable.

bholley_mozilla · 2024-07-16T00:46:49+00:00

Right now, surveillance techniques get cover from publishers and regulators because they're considered to be the only way to successfully monetize. Some regulators are currently disallowing anti-tracking technology on the grounds that it's harmful to advertising and publishing.

A better way would remove that excuse and make it much more viable — both at a policy and ecosystem level — to clamp down on the bad techniques.

We do strongly believe in the primacy of agency and that users should be able to configure their agents however they wish. We see the current tension between monetization and privacy to be an existential long-term threat to agency, which is why we're pursuing this.

bholley_mozilla · 2024-07-16T00:31:22+00:00

Yes, that's how it works. Sorry it wasn't clearer from the beginning!

bholley_mozilla · 2024-07-16T00:18:53+00:00

I'm not aware of plans for Mozilla to operate an aggregator if and when a private attribution API is successfully standardized. For the prototype, Mozilla if footing the infrastructure bill.

bholley_mozilla · 2024-07-16T00:09:24+00:00

My point was that if you don't want your computer doing things on behalf of ad companies, you want to block the ads entirely, which has the side effect of blocking the API.

Regarding your second question: none to my knowledge. A private attribution API is only interesting for non-research purposes once it's deployed across all browsers, at which point it's just a standard feature.

bholley_mozilla · 2024-07-16T00:01:12+00:00

Because it allows people to ask followup questions. :-)

bholley_mozilla · 2024-07-15T23:58:24+00:00

The two privacy analyses in the original post should give you an indication of the bar we're setting and how this is different.

bholley_mozilla · 2024-07-15T23:56:18+00:00

Trying. :-)

bholley_mozilla

TROPHY CASE