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?
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.
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.
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.)
An open API implies a certain intent of the author. If there is an open API to utilize some feature, that implies an expectation that others will use it and thus an expectation of a consistent interface version to version. If you're forced to go around monkey-patching the core framework, you can expect a moving target as there is no expectation of external users thus no motivation to maintain a consistent interface between versions.
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.
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.
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).
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.
When you decide to fork a project, a key concern is: how invasive are your changes going to be? This is a very large component of how easy or hard it will be to merge upstream changes in the future.
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
I think, Open as in scriptable and documented. Chrome has many undocumented apis and most of it is in c++. Not everything is exposed to the webview area.
This reasoning makes sense to me. If you have a JS api, to me that implies a consistent and maintained interface. Modifying the internals seems like it could easily become deprecated or have to be completely different with a single wrong PR
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.
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.
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.
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.
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.
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.
> 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
Sorry if I was unclear, I meant a red flag wrt cliqz's intentions. 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?
> Sorry if I was unclear, I meant a red flag wrt cliqz's intentions.
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.
In that case it sounds like the real explanation for forking was "the relevant part of the Firefox codebase had too much tech debt to make contributions so we had to fork our bodges." (No offense wrt tech debt; I know what it's like to be saddled with it and congrats on addressing yours.)
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.
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.
Note that Mozilla trusted us enough to invest in Cliqz, and we passed their security and privacy audit before they started their experiment with our search in the dropdown. At this time we did also built prototypes together for webextension APIs that would be able to tweak the url bar's behaviour.
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.
It is very different on mobile. I just took some screenshots of Google search on Firefox on Android before and after enabling an addon that sets my user agent to Chrome on Google sites: https://imgur.com/a/P9zDn7B
It looks deliberate but it's also not clear to me which is the "better" version. It doesn't look like one has more features or is obviously newer or better. (i personally like the second screenshot better, but i think the rounded boxes in the first screenshot is actually google's latest design fad)
You can sometimes trigger similar changes in appearance to the search results view by switching to incognito or clearing your cookies - Google often A/B tests or performs slow rollouts of changes like this, a difference in appearance could just be because a new user agent string got you placed into a different release group.
It’s more apparent on other things - I probably should have searched for flights or movies or something else more interactive. Firefox-as-itself doesn’t get any nice features like upcoming movie times without going into other websites, while Firefox-pretending-to-be-Chrome does.
Honestly at this point I’d like to give up on the user agent header and have everybody say they’re Chrome all the time.
In the first screenshot you see third party news stories above the fold and in the second story there's nothing but knowledge cards above the fold. Both are presenting relevant information (and no ads) but which format is preferable? My guess is that certain knowledge cards (like stock price history) are subtly less functional on FF so they are omitted.
I'm seriously skeptical of that. It's plausible they didn't bother trying to get it to work in FF, and just thought "screw that". But judging by de screenshot of the stock price history alone, clearly FF has no trouble rendering that history - both screenshots are FF, right? It's only the UA header that was changed.
Incidentally, this is far from the first time google has been caught heavily optimizing exclusively for their own browsers, which, to be clear, is quite probably not explicit policy - but is monopolistic abuse nonetheless. Remember the youtube polymer redesign? The Edge HW acceleration-breaking invisible layers? I get the feeling they just don't test in other browsers nearly as well.
Occam's Razor suggests you're looking for ghosts, and just to be sure I tried this on my phone: as far as I can tell behaviour using FF + chrome UA addon (which I specifically installed to test this) is indistinguishable from chrome as far as google search's stock ticker display goes. focusing points, time spans, toggle modes, clicking the extra-info chevron... all no difference.
Given google's history here you really shouldn't be giving them the benefit of the doubt in this matter; at best they're consistently, repeatedly negligent; but it's at least conceivable there's culture of giving additional other google teams; which is a form of monopolistic power abuse.
Oh yeah, that didn't even register to me. But still, when you get recommended stories vs when you get info cards is such black magic that i wouldn't assume that's necessarily firefox vs chrome either.
You're likely seeing the "newer" version on Chrome and they just haven't tested it enough in Firefox so they're not delivering it to Firefox users yet.
Ah, that's good news then. I am somewhat worried about the Chrome monoculture with Edge going that direction and Chrome marketshare continuing to grow.
Firefox will eventually die in 5 to 10 years if the marketshare trend continue.
Firefox for Android already has a negligible number of users and as a consequence webmasters stopped to worry about making their mobile websites compatible with the limitations of Firefox.
Every time I retry chrome/chromium I switch back to FF.
Its just not worth it, turning off all the background pinging home/etc is really annoying too. I ended up DNS blackholing a bunch of stuff.
I use user agent switcher sometimes to poke around on sites, YT is totally broken and I ditched using google search about a decade ago due to their policies.
I'm the same I used brave for a while and fully support what they are doing just wish they had forked from firefox so it would actually have a functional sync rather than the pipeline rubbish they have current
I use Chrome and Firefox and I've never noticed a problem with youtube. That said, I love how firefox actually prevents youtube from autoplaying (not even the youtube autoplay switch can seem to do that 100% of the time).
Hmm, I just got a Vimeo video to play in FF Dev, but I had to solve two recaptchas to get there (probably because I am coming from my VPN endpoint, not just because they want to torture FF users).
If I remember correctly, the big Youtube issue were with the "recent" redesign that involed a lot of web components code using the Polymer Material Design framework. And Firefox just wasn't as performant with that (polyfills required?)
I've always found the old design better (just like reddit), so I disabled polymer for YT and got both more performance and better UX out of that deal.
To try it out, just append &disable_polymer=1 after any YT video url.
Considering YouTube(comments, notifications etc.) has had bugs constantly in recent years I don't think using one browser or the other would make a big difference on that site.
Even after more than one year you can still not make a one-line space between paragraphs in YT comments without editing the comment afterwards because YT will always insert additional empty lines for whatever reason.
I switched to the basic HTML version of gmail a year or so ago for that reason. If you don't need the advanced features, I highly recommend it, especially for occasional use. I do most of my email through Thunderbird.
It's not that it doesn't work, it's that there is an anecdotal bias towards making you do more work to prove you're not a robot.
I don't use Chrome, so I can't tell how bad it is on a comparative basis, but (especially in private browsing mode) Recaptcha can make you cycle through a half-dozen different images looking for the traffic lights or what not before letting you continue.
Depends on the Google property and depends on device type (there's many more differences between Chrome on Android v. Firefox on Android compared with Chrome on Windows v. Firefox on Windows). Mobile really is still diabolical.
Why doesn't Microsoft open source their engine if they're not using it any more? It can't possibly still have any of the NSCA code in it.
Microsoft is still a scumbag, claiming to support open source, releasing some of their middle-wear and buying GitHub, yet refusing to release something that could actually make our web community more diverse.
Open sourcing huge code bases is not straightforward. Some of the code could be licensed from other parties who Microsoft needs to bring together and convince on the effort. The code needs audit for any potential legal risks. It's not like "hey I'm just gonna put it on GitHub". It's a tremendous investment.
They are abandoning it outright. I'm not sure what good open sourcing a failed browser renderer would accomplish. Between Gecko, Webkit, Blink, KHTML, and others, there are already plenty of FOSS options out there.
Are there? I've only seen the major ones you mentioned and Mozilla's Servo which look remotely fit for the modern web. And of those, only WebKit is _really_ easily embeddable.
One argument I could think of is that it can take a long time for typical users to upgrade their browsers. If they've stopped development on the old version, then open sourcing it could help people find vulnerabilities that will never be addressed.
I never heard of Clikz, so I checked out their website, and their mayor sales pitch seems to be that it is european? I mean, as an european I suppose I would rather use european products, but I'm not going to use a different search engine just because of that.
(Just talking about the sales pitch here, I haven't used it so I don't know if it offers anything more)
My intuition is that most of the code for which performance really matters is written in Rust and C++ (the web engine, Gecko, and the Javascript engine, SpiderMonkey).
When it comes to responsiveness, raw compute throughput (the thing you get most out of say, vectorized C++) is not especially important. You care about latency and JavaScript can provide good latency if it's been JITted. If part of your flow is already in JavaScript, porting more to JS can actually improve latency because it cuts native<->JS transitions out of the call stack, so you're running less code in total even if the code you run is a bit slower (due to being JS instead of C++).
In general Chrome and Firefox have both moved a lot of stuff from C++ to JS (this is referred to as 'self-hosting') because it allows inlining across more calls and eliminates native<->JS transition overhead.
I urge the mods to take a look at how often the "0x65.dev" domain, which is just Cliqz, ends up on the front page.
Of special note (and I bow to them) is how they've used such a domain name to spam their services. If they had used "cliqz.com" or whatever their actual domain is, fewer people would click, but when I see this I'm inclined to think this is some personal blog of a fellow software developer, and not blogspam of a shady ads company.
If you have concerns with Hacker News moderation, please send them a message at hn@ycombinator.com. They'll see it faster, and it's better than polluting the site with accusations.
Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data.
One must know what "astroturfing, shiling, brigading" are to follow that rule. As such, astroturfing is the labor in putting fake grass down. Shiling, I'm guessing is giving the money item, a shilling, to someone. Brigading, I guess is starting a brigade. My point is that making up, or using new words(not in the dictionary) and using them in a guideline without defining them, nullifies the rule to most of the populous. Also, dang is super responsive to HN comments that he finds incongruent with the rules. He'll be here shortly to chastise OP and me.
Merriam-Webster is a popular a publisher of American-English dictionaries: emphasis on American. It also had a significant role in shaping American-English as distinct from British-English. E.g. removal of the letter u in British-English words like colour. Or, the unsuccessful campaign to spell the word acre as aker.
That's false. Webster is the dictionary that had a role in shaping American English in a distinct fashion. The quality of the work deteriorated when the Merriam brothers purchased it, and they changed the title from Webster's by the time they had begun compromising the value of English reform.
I work at Cliqz in the engineering team and have been involved with this advent project. I'd like to provide some background.
For a while, we have been thinking internally about having a tech blog for Cliqz engineering teams. It is fairly common for tech companies to have a separate blog for technical content, separated from the main website. We picked a name: 0x65.dev (0x65 being the hexadecimal representation of 101, the idea was that we would write about the tech at Cliqz in an accessible way).
To make sure we'd commit to writing on this new blog, we thought of organizing an "advent" for Christmas, where we would publish one article per day digging on one of the aspects of what we do: search, privacy, browsers. When creating the list of topics, we did not optimize for Hacker News (or any other community for that matter, we also post and twitter and Reddit equally), as this was suggested by some other comment. We really wanted to create a coherent schedule to explain why and how we do things, to have a logical progression in the topics (looking at the posts from first to last, it should hopefully make some kind of sense!). We started on day one with "Why the world needs more search engines", to motivate our efforts in this area, and started detailing on following days the way we built our engine from scratch.
One thing we wanted especially, was for engineers to write about the projects they work on, to get their perspective, without any filter. So far, many different people have contributed. If some of the technologies or keywords we use seem "trendy", it's because we are ourselves hyped about those, and we use them internally to build our products.
Before the event we never anticipated this would resonate so much with the HN community, and while very pleasant, it was not the goal. We were of course extremely enthusiastic when we saw the great feedback from the community. If anything, this proves that the topics which we are passionate about are also of interest for a part of the HN community (many of us at Cliqz read HN every day; in fact we all used our personal accounts to submit, comment or discuss about the posts). It also shows that what we do is not disconnected from reality, and that there is real interest around the topics of search, independence, privacy; a good validation for us!
Personally, I have never heard of cliqz, so 0x65.dev and cliqz mean exactly the same thing to me, which is nothing. I don't think I would be less inclined to click if it were cliqz.com.
While I understand the need for base training data to launch a competitor to a search engine like Google, I won't deny this gave the name an immediate bad taste in my mouth.
They use a different domain probably because people with uBlock Origin and pi-hole won’t be able to visit their main site at cliqz.com (which is enough for me to ignore everything coming from them).
I think the upvoting has to do with this series of posts on the domain. If it was uninteresting content the posts would not be upvoted in the way they are.
It's not unusual for a company blog to have a different name. A simple example is Signal v. Noise [1] which is the Basecamp folks. I would not want to seem them penalized for doing what others have done for a long time which has been seen as fine.
Knowing who Cliqz is a bit about being an insider for certain technology circles. Many people do not know and many people do not care. Some folks having issues with the company should not stop interesting content from being upvoted. Some members here have issues with Google, Microsoft, and other companies. That never stops their content from being listed.
I am not a Cliqz user. I am curious of the motivations of people who use Chrome (put out by an advertising company) while having issues with Cliqz (being put out by a media company).
My bet is spinning off their own browser has nothing to do with anything but fear the browser vendors, Firefox and Chrome alike, will start blocking their real money maker.
This is not even a new strategy. Other companies have tried similar tricks over the years too, though most of them went with Chromium forks instead for their spy/adware laden wares.
Frankly, it's disappointing to see this even on here, but I don't blame anyone for it; they are really working hard to sugar up the pitch here.
There is a point in there I think you're missing. That is Google is an advertising company. Isn't it hypocritical to have an issue with Cliqz for being an advertising company while being OK with Chrome which is from an advertising company (Google)?
If posts from Google and Chrome are OK for hacker news then why not from others with similar business models?
I'm not attempting to say that Cliqz has an OK model. I'm suggesting self examination and consistency.
Indeed, Cliqz appears to have a weirdly close, Pocket-like relationship with Mozilla. According to Wikipedia (https://en.wikipedia.org/wiki/Cliqz#History), in 2017 Cliqz was bundled in with Firefox for 1% of users downloading the latter (from Mozilla's own website, presumably) in Germany. This was despite that "Users who receive a version of Firefox with Cliqz will have their browsing activity sent to Cliqz servers, including the URLs of pages they visit", and "text typed in the address bar, queries to other search engines, information about visited webpages and interactions with them including mouse movement, scrolling, and amount of time spent". HN thread: https://news.ycombinator.com/item?id=15421708
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?