Why we Forked Firefox and Not Chromium | Hacker News Reader

Why we Forked Firefox and Not Chromium

0x65.dev

483 pointsnikbackm122 comments

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.

I still don't know what that means. I run chromium. It has an address bar. I can change the search engine.

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.

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.)

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.

The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".

It addresses changing the site that feeds it. It does not address changing the behavior.

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.

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.

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

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

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.

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.

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.

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

You're welcome.

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#c28

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.

what is not good about it. Privacy? Security? :~)

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.

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.

Disclaimer: I work for Cliqz

[1]: https://0x65.dev/blog/2019-12-11/the-pivot-that-excited-mozi...

Does Google still provide a "significantly worse" experience if the user agent is Firefox? I recall that was true on Gmail and Youtube for a while.

they did it on purpose, I don't see why they would stop doing this, it basically means less money for them, not that I agree it should be a thing.

I just downloaded their browser 10 min ago and I can't really tell any difference in search. Haven't really tried any other g products yet.

They claim to be open and most things are opt in but im not sure why their "human web" is not opt in.

Have you tried a re captcha yet? They're awful on firefox (read: non-chrome), especially if not signed into a google account.

Is there any good alternative to recaptcha?

That question has come up a few times, lots of good discussion in this post:

https://news.ycombinator.com/item?id=20058697

And the back and forth on whether you really need it:

https://news.ycombinator.com/item?id=20158386

Recaptcha works fine on FF...

Sure it works be Google will make ff do more steps and even load the images slower on the "click till non match" ones

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.

> Recaptcha can make you cycle through a half-dozen different images

That's when I just leave. If I'm feeling nice, I'll drop the site owner a note explaining why, but usually not.

Nobody's site is that great.

I had to stop ordering from Newegg because they wanted me to recaptcha just to log into my account. It seems to be fixed now, though.

This seemed to work well. I can't find a better test.

https://patrickhlauke.github.io/recaptcha/

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

Oh wow. That seems very deliberate.

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.

I was reacting to "just today's stock price" versus "today's price plus some history".

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.

A static screenshot does not fully capture the functionality of a web element, hence my use of the term "subtly".

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.

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.

They are doing the same to Palemoon too. a few regular sites are recently failing to load within Palemoon.

Not a fan of Firefox and I refuse to like or use chrome.

Which one is better and which photo is which?

I can’t speak to better, but the first is unmodified user agent and the second is spoofing mobile Chrome’s.

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.

Yawn.

Returning a chart on "xyz stock" is not new.

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.

There's still breakage in small areas: https://bugzilla.mozilla.org/show_bug.cgi?id=1601831 https://github.com/webcompat/web-bugs/issues/25270

IIRC though the main issue with YouTube was a slow polyfill library which has been fixed since they updated to the standardized version of Shadow DOM.

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.

Vivaldi reports itself as Chrome now, making Chrome numbers even higher

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.

I would reckon a lot of those statistics are based on analytics rather than polling.

In which case Firefox blocks a lot of trackers so naturally their marketshare appears less than reality.

Adblock plus + uBlock == 6.5 millions of users for Firefox.

While this is not nothing, this should be a few 0.x % of global browser marketshare

Firefox blocks trackers by default, no need for an add-on.

The android market share is a real shame, because Ff on Android is actually pretty darn solid.

YouTube is still unusably slow on Safari.

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 certainly clear they haven’t spent an oz of effort improving it outside of chrome, that’s for sure.

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.

"don't think using one browser or the other would make a big difference on that site[YouTube]"

It did though. See this comment: https://news.ycombinator.com/item?id=21826191

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).

Have you tried vimeo? Doesn't work on firefox.

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).

[right click] -> Open With -> mpv

https://addons.mozilla.org/en-US/firefox/addon/open-with/

(If your desktop environment supports drag and drop, you can also drag and drop vimeo or youtube URLs into mpv.)

I've been using firefox for years and never had a problem with vimeo; is the vimeo breakage recent?

[edit] picked the first video from "staff picks" on vimeo and it worked fine in FF:

https://vimeo.com/378423659

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.

play.google.com/books can't be used from Firefox at all last time I checked.

The unstated motivating factor here is that Mozilla made a minority investment in Cliqz back in 2016: https://en.wikipedia.org/wiki/Cliqz#History

Isn't this article about stuff that happened in 2015 though?

It seems like the investment followed from using FF, not the otherway around.

> EdgeHTML

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.

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.

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.

> Between Gecko, Webkit, Blink, KHTML

That's kinda just two browser engines. Blink is a fork of WebKit, and WebKit is a fork of KHTML.

Though I'm partial to the argument that provided the main options are at least FOSS, diversity of implementations is of minimal concern.

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.

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.

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)

"Firefox has open APIs for everything the browser does—a majority of Firefox “application” code is written in JavaScript."

While it makes hacking on Firefox easier, isn't this a liability for performance? Is this, perhaps, partly why WASM is such a focus for Mozilla?

Yeah, but when you look at it what is the alternative? To write the same thing as JS in Chromium, right?

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).

I personally consider UI responsiveness to also be something that really matters.

It's great that part of the UI handling code is fast, but that doesn't mean all of it shouldn't be fast.

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.

Why is this question downvoted? I thought that was an interesting question.

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.

https://news.ycombinator.com/newsguidelines.html

Speaking as a person who's done as much, and definitely is no fan of Cliqz:

https://news.ycombinator.com/item?id=21718650

https://news.ycombinator.com/item?id=21724844

They're really responsive, and they're very proactive about these things.

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.

Astroturfing in the most famous English dictionary:

https://www.merriam-webster.com/dictionary/astroturfing

Brigading in the most famous English dictionary (see definition 2):

https://www.merriam-webster.com/dictionary/brigading

Oxford English Dictionaries might like a word about your fame assertion... :)

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.

Oxford has astroturfing too: https://www.oed.com/view/Entry/325483?rskey=aidQ7O&result=2&...

Shilling does have a NorthAmerican connotation: https://www.oed.com/view/Entry/178128?rskey=UvAWn2&result=4#...

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.

You're right. I thought it was Webster that acquired Meriams' company.

I like the series and I didnt even upvote. Not sure why you're angry.

I've also been noticing that. But tbh they are not alone. The list of companies and startups exploiting HN is long.

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.

Honestly the first place I heard about Cliqz is a little unfortunate: Firefox sideloaded them into people's browsers in Germany back in 2017: https://blog.mozilla.org/press-uk/2017/10/06/testing-cliqz-i...

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.

Hi,

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!

In case anyone thinks the advent thing is super weird, FastMail is known for doing advent blog series: https://fastmail.blog/2017/12/01/fastmail-advent-2017/

I encourage more writing.

As a reader, I care about the quality of the article itself, not about whatever taint the site or author might have.

I’ve noticed cliqz.com is on tracker block lists.

Apparently not by default on uBlock Origin.

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).

[1] https://m.signalvnoise.com/

But you are mistaken.

Increasingly buried underneath all the big talk about privacy and the blog spam, is the fact that Cliqz also is an advertising company: https://cliqz.com/en/magazine/press-release-cliqz-introduces...

They've literally resurrected the ad-riddled browser toolbar: https://myoffrz.com/en/

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.

Thanks for that.

I was thinking about trying their browser.

That press release is insane. Sharing "approximate location"?

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

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 don't want to read anything about Cliqz and their shitty products

Then don't. It's really that easy.

but why???

Reply on news.ycombinator.com