Hi, I'm an engineer at Mozilla working on the address bar of Firefox. We recently released a rewrite of the address bar with the explicit goal of making it easier to extend and experiment with the address bar: https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar
You're welcome.
Fair enough, but to be fair to cliqz, we didn't turn down their API proposal due to privacy or security concerns. The old address bar stack was kind of a mess and hard to extend in a sane way.
> Do you think the address bar rewrite will be able to satisfy cliqz's needs and therefore allow them to unfork/go back to being an add-on?
The rewrite makes it technically possible to provide any APIs they'd need. I think we'd consider patches, as we did before, with a better chance of them getting accepted.
I hope to soon see a cliqz blog post about their project unforking, only spun as an ingenious way of saving memory, improving security and extending reach.
Good to hear that Mozilla changed their mind, when we proposed an open API for extensions to access the search area it was turned down
Unfortunately, as we mentioned in a previous post [1], Mozilla is not totally independent when it comes to the presentation of search in Firefox due to their existing search deals, so they couldn't continue with the integration. This is why we needed our fork.
Disclaimer: I work for Cliqz
[1]: https://0x65.dev/blog/2019-12-11/the-pivot-that-excited-mozi...
I don't understand why this sort of product exists though. As a user, whether or not I'm aware of the difference, I don't want the additional memory overhead of running a separate browser, the separate cookie jar, the delayed updates, the additional bugs... the better approach would obviously be to work with FF developers to add the extra extension APIs they need; I can only assume they took that path but got rejected. If you're a Firefox user, ie someone who inherently places their trust in the security and privacy decisions of Mozilla, that's probably a red flag.