policy-templates VS Servo

There is no such thing as a "known trusted extension" ever since they killed sideloading extensions and forced auto-updates. 10 years ago not force updating extensions was also a thing they moved behind a flag, and then just dropped.

Also - if you want to blacklist certain extensions from certain sites, you abso-freaking-lutely can already... see: https://github.com/mozilla/policy-templates/blob/master/READ...

you want the `restricted_domains` field.

It gets worse - Mozilla is the fucking worst at checking submitted extensions. They tried to the play into the whole "app store" thing that Google/Apple were doing, but those are justifiable cost centers at those two companies in a way that just doesn't work for a player like Mozilla.

Mozilla's store checks for extensions are fairly pathetic. You can submit a near empty shell with excessive permissions, get approved the first time, then auto-update to a new release (which will deploy to users immediately thanks to auto-updates). That new version has to pass a battery of useless automatic SAST checks, which will happily highlight all sorts of things it doesn't like (it flags words like "hello" because it contains a curse word) but which won't do shit to check if you're hoovering up credentials, browsing data, tracking users, etc.

If you're unlucky, at some point in the next 24 months you'll trigger a real review from Mozilla and get caught.

To be blunt - I have 15 years experience writing extensions. I don't like Google. If you think Mozilla is better you're wrong.

You can do that with policy templates. Use the Discussion tab at the top of the GitHub page if you need help setting them up.

Policy Templates for Firefox

They very well could do this for a a company that requires really strict privacy and security, but unfortunately in its current state Firefox doesn't have nearly the corporate sysadmin-friendly tooling that Chrome and especially Edge do.

When I was tasked with implementing CIS browser hardening policies at a previous job a few years ago, this was just a matter of enabling some Group Policy template settings for Chrome and Edge, but for Firefox this involved distributing a prefs.js file to all the workstations. In any corporate environment it's very likely going to be point and click Windows admins that are implementing browser standards, who tend to be allergic to anything resembling code and are already used to using GPOs for just about everything.

Yes, Firefox does have GPO templates but it's not nearly as rich as Chrome and Edge. Edge has even more GPO templates than does Chrome iirc, Chrome already had a lot to begin with and then Microsoft added even more of their own on top of that.

https://github.com/mozilla/policy-templates/blob/v4.11/READM...

https://learn.microsoft.com/en-us/deployedge/configure-micro...

That alone already puts Firefox at a huge disadvantage for corporate deployment, the other thing that makes it even less attractive, even to companies where privacy/security is a huge requirement (like my previous job) is that Edge is already bundled with the OS, and is one less thing that needs to be manually patched. In high security corporate environments, just keeping things patched is always a huge task so it's very hard to convince someone that they need to put in more work to keep an extra piece of software patched (which is already very difficult considering how frequently browsers are updated). To make things even worse, just about all vendors will only support Chromium-based browsers for whatever SaaS they sell you, so Firefox is a nonstarter for getting support, even if it will work just fine 99.9% of the time.

For all these reasons, I lost the battle to keep Firefox around, which is a huge shame because of how much I love it and wanted to fight the Chromium monoculture. So I guess for a corporation to support Firefox despite how corporate-friendliness the alternatives are, they'd have to reaaaally want to.

You can see the relevant JSON code in the changelog. As I said, you can post a comment on this page to remind Mike to update the documentation for policy templates.

This GitHub repository has a Discussions tab where you can ask questions about deploying Firefox: Policy Templates for Firefox.

Check out the official documentation here: Policy Templates for Firefox. You can use the Discussions tab if you have any questions.

Servo, the embeddable, independent, memory-safe, modular, parallel web rendering engine

> Is there any easy to use/hack HTML layouting engine where I could experiment with custom CSS attributes and bridge that gap? Would anything from Servo be suitable?

Servo could be used for this. You'd want to add support for parsing the CSS properties themselves to the style crate in https://github.com/servo/stylo and then the layout implementation to the layout2020 crate in https://github.com/servo/servo. You do effectively get a whole browser though.

I'm currently working on building a lighter weight / hackable layout engine based on a combination of https://github.com/servo/stylo (for css parsing and selector resolution), https://github.com/DioxusLabs/taffy (for box-level layout) and https://github.com/pop-os/cosmic-text (for flow/inline layout). I expect to have something decent in around 6 months

Neither of these setups currently have any support for pagination though.

Great to see some competition still alive in browser engine development. See also Servo (previously part of Mozilla) https://servo.org/ - that and Ladybird are still very underdeveloped compared to every day browsers.

It's a huge shame that there are no nightly builds of ladybird to try out but I assume that's because they just don't want the bug reports (if everything doesn't work it's pointless getting random bugs filed).

I haven't messed with it yet but from looking into it, this should absolutely work.

https://github.com/servo/servo/wiki/Building-on-ARM-desktop-...

don't know, there was a downtime in 2021 and 22 but since 2023, contributions look back to where it was before .. https://github.com/servo/servo/graphs/contributors

The world has moved on though to opinionated tools, and Rust isn't even the furthest in that direction (That would be Go). The equivalent of those two lines in Cargo.toml would be this example of a basic configuration from the jacoco-maven-plugin: https://www.jacoco.org/jacoco/trunk/doc/examples/build/pom.x... - That's 40 lines in the section to do the "defaults".

Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:

Servo: https://github.com/servo/servo/blob/main/Cargo.toml

rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...

ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml

socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...

1. Servo

It won't don't worry. There already are forks, for the worst case scenario. And Servo is on its way. Not yet ready, but it will be. Originally, from Mozilla kitchen.

To pain broad strokes, the layout phase (~= take the HTML, take the CSS, determine the position and size of boxes) is largely sequential in production browser engine today. Selector matching (~= what CSS applies to what element) is parallel in Firefox today, via the Stylo Rust crate originally developed in the research browser engine Servo. Servo can do parallel layout in some capacity (but doesn't implement everything), https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep... is an interesting and recent document on the matter.

Parallel layout is generally considered to be a complex engineering problem by domain experts.

https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... is a really cool article that is related, that is a few years old but what it says is largely correct today.