"Firefox has open APIs for everything the browser does—a majority of Firefox “application” code is written in JavaScript. Chromium on the other hand does not expose certain areas that are sensitive to Google’s business. The most notable example is the address bar (where Cliqz search lives). Google has no interest in making it easy for others to take control of the address bar; the flow to the default search engine (Google) is protected. Of course one could create new APIs, but that would imply creating them on top of the source-code. This is not a big issue, we have already created a prototype, but then there is the problem of maintaining it."
For the question of "why not call it a browser extension or something" because "browser extension" already means something completely different. It's also a bit wonky to think choice of language should decide if you call something a fork or not in the first place, doubly so considering significant portions of the browser are already written in that language.
Initial version often involve heavy surgery. Then the maintainers have to manually merge from upstream essentially forever. Manual merges are not fun, they are tedious, and they are prone to errors (in part because they are tedious).
Over time these companies get a better grip on the bare minimum they need from Postgres' internals and file PRs. The goal is for their changes to be an add-on instead of a code fork.
From what I understand, Postgres team rarely has any vested interest in being antagonistic to these companies. Google's business model pushes them toward being antagonistic to any such efforts. Which means cliqz is stuck managing a fork forever, and may even run into cat-and-mouse games.
The only way to win is not to play.
So in this case, the core framework being exposed to javascript is evidence of the expectation of external users, thus it will likely not be a moving target. If you're modifying some software, you will greatly prefer programming to an API than not.
In this case, going with Chrome would mean very invade changes to enable exposing things the upstream specifically wants to keep private in their codebase. Firefox instead requires only well-delineated, minimally invasive changes because there is a nice clean boundary between UI code and engine code (which incidentally matches c++/js boundary, the languages themselves don’t matter much), which means their changes can be isolated to the UI layer, which in turn means a much cleaner path to merging upstream changes
Whether or not it's been bound to a scripting language does not make it any more or less "open" or stable (which is what they seem to actually be looking for - stability). They forked the code, everything is an "open API" at that point. There is no concept of open API vs. not when you're just talking about the source of a project.
Whether or not an internal API is stable is relevant. But that stability is independent of which language it's in, and the only way to determine that is to either look for author intent or history of the API. Just because it's currently exposed to JavaScript doesn't mean it's stable at all.
And just because it's internal doesn't mean it's not an API.
Suppose you wanted a deeper change like it to automatically add .com .org etc to the address entered as long as that’s not a phishing website. Now you needed to maintain that patch going forward and reapply it to every new version of the base browser. That’s much safer if the address bar’s code is isolated from the rest of the browser.
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.
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...
In the context of a browser fork, these statements make no sense: "Firefox has open APIs for everything the browser does [...] Chromium on the other hand does not expose certain areas that are sensitive to Google’s business." In the context of changing the source code, how are some APIs "open" and others not? How can the Chrome code possibly "protect" (their words) the address bar from modification relative to any other code?
I think what they're instead talking about is the available extension APIs from JavaScript maybe? But in that case, why call the project a fork, instead of a browser extension or something?