5 ms·

I have liked the other posts in this series, but I find the reasoning in this one confusing. (Disclaimer: Perhaps it is because I am familiar with the Chrome c

by evmar 7y ago

I have liked the other posts in this series, but I find the reasoning in this one confusing. (Disclaimer: Perhaps it is because I am familiar with the Chrome code.) 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?

zamadatix 7y ago
The statements make a lot more sense if you put back the parts you excluded: "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.
- tedunangst 7y ago
  I still don't know what that means. I run chromium. It has an address bar. I can change the search engine.
  - Retric 7y ago
    It means you can change how the address bar behaves in a complex fashion without changing the rest of the browser’s code. 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.
- rasvj 7y ago
  Both Firefox's and Chromium's source code is completely open (it could be argued that Chromium's code is even more open since it's mostly BSD). Google can't stop you from modifying anything in the browser, and that includes the address bar. The language in which that component is implemented is irrelevant, and Google has certainly not chosen C++ to implement to address bar with the express purpose of making that component harder to modify.
  - zuzun 7y ago
    If there's no real API, you have to patch things and diverge from master and then you face the problem that Chromium is under constant change that you most certainly can't keep up with, so either you chose to ignore all the work happening in Chromium and end up with a stale branch or you spend most of your time making your patch work with the latest changes.
- evmar 7y ago
  So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript code, but not the C++ code alongside it? (I am genuinely confused by the reasoning, questions are not rhetorical.)
  - jamoes 7y ago
    My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.
    - bagacrap 7y ago
      Ever since Chrome Beta users have been able to change the search engine that powers the omnibox (to include autocomplete suggestions, not just search results).
      - xemdetia 7y ago
        Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.
        bagacrap 7y ago
        The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".
        7y ago
- hinkley 7y ago
  Look, for instance, to the history of forks of Postgres to add new functionality. 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.
- kllrnohj 7y ago
  That doesn't make any more sense. They seem to be conflating "it's been bound to the internal scripting system" with "open API" 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.
  - varelaz 7y ago
    It does. For example Firefox made some features as API and declared interfaces, while Chrome didn't and left it as internal functions, which you cannot rely on, you cannot be sure that interface won't change.
    - kllrnohj 7y ago
      Unless it's exported to 3rd parties it's an internal function. Just because it's JavaScript doesn't make it stable API. And just because it's internal doesn't mean it's not an API.
- LifeLiverTransp 7y ago
  Google certainly likes to let forkers ride the rewrite rodeo, when it comes to key-components- in its open source.
deleted 7y ago
[deleted]
bagacrap 7y ago
Their product appears to be mostly an extension, with a small amount of bespoke browser code which necessitated a fork. I believe they are saying the delta is smaller with a Firefox base because there are more pre-existing extension APIs they can reuse (and rely on someone else to maintain). 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.
- dao- 7y ago
  > 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 https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar You're welcome.
  - kkm 7y ago
    Disclaimer: I work for Cliqz. 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 Ref: -https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28
    - dao- 7y ago
      We haven't changed our mind there. We're not going to implement a webextension API that allows replacing the results popup or parts of it with an iframe as we don't believe that to be a good API.

by evmar 7y ago

zamadatix 7y ago

The statements make a lot more sense if you put back the parts you excluded: "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.

tedunangst 7y ago
I still don't know what that means. I run chromium. It has an address bar. I can change the search engine.
- Retric 7y ago
  It means you can change how the address bar behaves in a complex fashion without changing the rest of the browser’s code. 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.
rasvj 7y ago
Both Firefox's and Chromium's source code is completely open (it could be argued that Chromium's code is even more open since it's mostly BSD). Google can't stop you from modifying anything in the browser, and that includes the address bar. The language in which that component is implemented is irrelevant, and Google has certainly not chosen C++ to implement to address bar with the express purpose of making that component harder to modify.
- zuzun 7y ago
  If there's no real API, you have to patch things and diverge from master and then you face the problem that Chromium is under constant change that you most certainly can't keep up with, so either you chose to ignore all the work happening in Chromium and end up with a stale branch or you spend most of your time making your patch work with the latest changes.
evmar 7y ago
So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript code, but not the C++ code alongside it? (I am genuinely confused by the reasoning, questions are not rhetorical.)
- jamoes 7y ago
  My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.
  - bagacrap 7y ago
    Ever since Chrome Beta users have been able to change the search engine that powers the omnibox (to include autocomplete suggestions, not just search results).
    - xemdetia 7y ago
      Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.
      - bagacrap 7y ago
        The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".
        7y ago
hinkley 7y ago
Look, for instance, to the history of forks of Postgres to add new functionality. 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.
kllrnohj 7y ago
That doesn't make any more sense. They seem to be conflating "it's been bound to the internal scripting system" with "open API" 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.
- varelaz 7y ago
  It does. For example Firefox made some features as API and declared interfaces, while Chrome didn't and left it as internal functions, which you cannot rely on, you cannot be sure that interface won't change.
  - kllrnohj 7y ago
    Unless it's exported to 3rd parties it's an internal function. Just because it's JavaScript doesn't make it stable API. And just because it's internal doesn't mean it's not an API.
LifeLiverTransp 7y ago
Google certainly likes to let forkers ride the rewrite rodeo, when it comes to key-components- in its open source.

deleted 7y ago

[deleted]

bagacrap 7y ago

Their product appears to be mostly an extension, with a small amount of bespoke browser code which necessitated a fork. I believe they are saying the delta is smaller with a Firefox base because there are more pre-existing extension APIs they can reuse (and rely on someone else to maintain). 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.

dao- 7y ago
> 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 https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar You're welcome.
- kkm 7y ago
  Disclaimer: I work for Cliqz. 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 Ref: -https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28
  - dao- 7y ago
    We haven't changed our mind there. We're not going to implement a webextension API that allows replacing the results popup or parts of it with an iframe as we don't believe that to be a good API.