Hacker News new | ask | show | jobs
by sheenobu 1879 days ago
I thought of Nix while reading this thread and I'm wondering what makes it unique here? As a daily NixOS user I get that it is better but I don't know the specifics. the nixpkgs rpeo is superficially similar to homebrew (lots of people submitting packages, running on github, automation around commits).

What are the differences wrt to security?

1. It's language, Nix, is limited in scope?

2. No automated PR merge workflows (yet)?

3. Better community/engineering/security?

1 comments

Well, a very simple answer is that homebrew embeds nonconsensual spyware into the brew tool itself, and nix does not. For me, "doesn't exfiltrate my private data to Google in the default config" is an important security benefit of nix over homebrew.

The longer answer is about the inherent benefits of the nix way of doing things; it is a horse of a different color compared to all other package managers I've seen or heard about. It is a different installation paradigm, and the nix documentation (and many blog posts) do a better job of describing its main differences than I can here.

Deterministic builds as a first class feature is probably the shortest summary. Being able to reference an entire and exact hash tree of deps is hugely valuable.

It does warn about it before sending anything though https://github.com/Homebrew/brew/blob/3e0f14083aa983c136a375...
Analytics are an invaluable resource for a volunteer-run project. To their credit, they issue a noticeable warning with the command to turn it off. It seems to me your issue is more about using Google Analytics - if there's a better alternative that is sustainable (read: free and doesn't require much effort to maintain) that should be suggested.
My issue is that the data is exfiltrated without consent. It literally does not matter where it goes if private data is transmitted without consent.

With consent, it's fine to send it anywhere they like.

Their analytics are also unauthenticated. I sort of want to make the first letter of each package in the top packages ranking spell out something funny.

Fine on the unauthenticated part. But about private data - it's literally anonymous and just counting the number of installs of a package and the number of build failures. All the data they collect (and the code that handles it) is public. They can't even isolate individual users because no individual data is collected.
It's not anonymous by any stretch, that's a false claim.

It includes a persistent unique identifier, generated on install, a sort of Homebrew supercookie for tracking you across months or years until you wipe your OS install.

It also includes the client IP address (because you can't make an HTTP connection without transmitting that). The fact that Homebrew doesn't see this information doesn't mean it's not transmitted (to Google). This leaks your city-level location.

These two things permit Google to assemble a rough location tracklog based on client IP geolocation (correlated via the unique install ID), along with which packages you installed. Google, as we know, spies for the US federal government.

You're missing the point here, though: even if it were totally anonymous (which, as I've pointed out, it's not): it's still unethical malware even in that case because it's private data transmitted without consent. The fact that you don't consider your usage data private is fine; others do and transmitting that from their systems without consent is abuse.

I mentioned that it's unauthenticated to point out that there's literally nothing stopping anyone on the whole internet from polluting the dataset with whatever bogus information they want. I wouldn't undertake this myself, but it's entirely in-bounds for an organization that feels entitled to co-opt your private computer to conduct surveillance on you without your consent. It's a public API, after all.

We’re looking into other analytics platforms. If you happen to know a good replacement with better privacy and similar features, we’d be happy to review PRs.

Please mind that knowing unique installs will remain important for us though. We have zero interest in tracking people but we do need meaningful install counts. Those numbers have been super helpful for making decisions, for example which packages are worth maintainers’ time and which aren’t.