gcp

Thank you!

Note we provide updated Debian packages: https://support.mozilla.org/en-US/kb/install-firefox-linux#w...

You also get the ability to deploy all browser infrastructure on-premise, to effectively decouple yourselves from us and get sync data, telemetry, and so on all stored on-prem, serve updates from your own servers, etc. This is something that wasn't really practical before.

I'm not sure why we would be okay with breaking a browser's trust in that way

I'm not sure what you mean here. If we accept that this is something a lot of Enterprise deployments require, wouldn't you prefer to have things like DLP, VPN and security logging be built-in in the browser, rather than being provided by third-party products that intercept or hook the browser traffic somehow?

If the site is public and the issue happens in a fresh profile, just a link here would likely do the trick.

Not sure if you're aware, but this button does actually exist in the help menu, at least for getting a public report filed. I looked through our tracker and didn't find any report similar to yours though (..and Office365 has a ton of webcompat bugs on file...), so I'd recommend you and "others" to actually file those bugs.

Finding and fixing those bugs in websites (unless they're behind a login that you can't easily sign up for) typically isn't the issue, but getting ahold of the site owner sometimes is.

If we can't get ahold of the website operator, or they're slow or unwilling to fix it, we can ship compatibility shims in the browser.

Take a look at about:compat to get some idea.

Browser engines are incredibly complicated, yet at the same time are very performance and security sensitive while needing insane backwards compatibility and full multi-platform support. That unfortunately requires large teams, which is why there's only Gecko and WebKit/Blink left.

"Making a browser" you can do with a team of 1 person. Just search & replace the branding in the Chromium source.

I think we hit all the features you mention but not sure about the above.

(Regardless of one's feelings about generative AI, I think some features like local translation or alt text are too nice to be labeled "LLM shit", but I admit I am biased)

Warning (instead of blocking) is possible. Due to the security logging (plus, if wanted, SIEM integration) you get the flagging.

Can you run data through a local or corporately-situated LLM instructed to "Assess whether this looks potentially sensitive" via a given set of rules, and flag it to the user or a supervisor to proceed/abort?

Not in the first version, but this is an area we are working in.

what kind of hooks and feedback/UI interaction is available for third party integrations?

We support the standard SDK for this which is also used by Chromium based products:

https://hacks.mozilla.org/2025/03/improving-firefox-stabilit...

That's how Trellix and Broadcom integrate with it as well.

Firefox Enterprise tries to remove as much friction there as possible, and adds a pile of features like deployment monitoring, policy changes while running, device posture checks, various security features like SIEM logging, etc.

The other part is that you get the option to run all supporting services entirely on premise, so the browser never has to "phone home" to us, but you still have working updates, sync support, and so on.

It's client-server (Firefox <=> management console). There's no other app needed client side, it's all built into the browser.

what about WAN users? intermittent connections?

Supported (one of our core developers often works on a spotty 5G, so we got rather loud feedback when this broke...)

multiple profiles? per-user or per-device? multiple users per device and multiple devices per user? group management? integration with other directory services - or do they reinvent the wheel and I need to input every update in multiple applications? multiple platforms?

Yes to pretty much all of these - minus reinventing the wheel - I think only "multiple profiles for the same user-id" are currently not supported. You'd essentially need to give an alternate login to the users that need this (because that's what triggers the profile selection). I don't think there's technically anything stopping this, just didn't seem like a common enough use case to get in the very first release.

mobile apps?

Not in this first release. (^_~)

Does it reliably autodeploy or do I need to manually do something for each of my 10,000 users?

We expect most will autodeploy over an existing MDM solution (Intune, Fleet, ...).

Again, how much will Mozilla invest in this small group of users, the IT admins?

I'd say Firefox Enterprise's customers are the IT admins, no? The users aren't generally the asking party to get a managed browser.

If they did, we wouldn't be having this discussion to begin with!

This is a bit vague to really reply to very specifically, but yes, this is hard. Which is why quite some people work in this area. It's rather valuable to do so at Firefox-scale.

Even if the majority of time it generates the “same” failure mode, it can still sporadically generate a rare execution trace.

This doesn't matter that much because the "same" failure mode already allows you to see the bug and fix it.

Hint: No-one is claiming memory is to blame for 100% of the Firefox crashes. No-one is claiming it's 99% either.

Without knowing more about your configuration, it's hard to give advice, but definitely worth trying with a clean profile first.

If you don't report this problem upstream it will never get fixed, as obviously no-one else is seeing this. Firefox has a built-in profiler that you can use to report performance problems like this.