Hacker News new | past | comments | ask | show | jobs | submit login
Homebrew now sends usage information to Google Analytics (github.com/homebrew)
359 points by aorth on April 25, 2016 | hide | past | favorite | 312 comments

I'm the maintainer who added this. I apologise for the poor communication. I would have responded sooner but I've been on a plane for the last 10 hours. I'd hoped the documentation would have made clear our reasons for doing this but I feel the discomfort so since getting off my flight I've opened and merged three PRs (https://github.com/Homebrew/install/pull/42 https://github.com/Homebrew/brew/pull/143 https://github.com/Homebrew/brew/pull/146) to better communicate this to our users on installation and `brew update` before any information is sent and ease the opt-out process.

I'd encourage you to keep the opt-out setting as-is. It clearly brings value to the development team, you're communicating it to users, and Homebrew users who aren't comfortable with opt-out can a) disable analytics or b) not use Homebrew. Switching to opt-in is going to greatly diminish the dataset you'd have for making improvements (selection bias).

The Homebrew developers' time is valuable, versus a subset of users making demands of a free tool. You've been conservative in how clients are identified, as well as the data collected, and people are still suggesting unreasonable alternatives. Can't make everyone happy. Thanks for an awesome tool.

Nobody is "making demands"

That's a strong suggestions of what is expected by users.

But why not make it "opt out" by default and then ease the ability to "opt in?"

Why are you even collecting this information? Homebrew isn't some for-profit product trying to optimize its funnel.

Keep doing what you were doing. You were doing a great job. There is no benefit to you or us to silently spy on us.

From the GitHub doc[0]:

> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.

I read this as: "Google Business Development contacted us and offered us a sum of money for high-privilege-level analytic data on developers."

I would have rather homebrew extended the donation coffer cup on line 0 every time "brew update" or "brew install foo" was called. Much like how Wikipedia ends up getting me to donate each year. Part of me wonders if this was my fault for not donating.

[0] https://github.com/Homebrew/brew/blob/master/share/doc/homeb...

How the hell did you get that? They don't have money for market research so an easy/free alternative is GA. You assumed because they use GA that Google paid them off? That is absurd.

Homebrew is an OSX packages manager. Take a look at the vested interests of Google prying into high permission level access of Apple devices. This is not the same implementation as simply hitting a page in your browser with the GA script.[0]

[0]: http://www.businessinsider.com/apple-walked-away-from-iad-to...

My question remains the same. You really think Google paid off Homebrew? /really?/

It should be opt-in, not opt-out.

Man, the privacy critics really come out of the woodwork every single time "opt-out" is mentioned, regardless of the actual facts for a specific situation. The developers explicitly state they set the anonymous IP address flag. There is nothing that links back to you as a person. Are you really concerned that the developers know which packages a random, unknown person has installed?

Crying "opt-in" to every single little thing that has ever tracked you for non-nefarious reasons completely detracts from the cases where tracking is nefarious. Homebrew is not tracking for ads. They are not tracking for anything worth selling to a 3rd party. They're not - and are incapable of - linking this to any other database that does contain personally identifiable information. There's no "profile" worth anything to anybody except the developers, who are trying to get some very basic information completely detached from any identity.

>> You will be notified the first time you run brew update or install Homebrew.

>> to opt-out of Homebrew's analytics you may set HOMEBREW_NO_ANALYTICS=1 in your environment

They went to the lengths to document this. And to notify you when you run the software. You have the opportunity to opt-out of something that is completely harmless. There is no valid reason to be crying foul over this. Of all the tracking that goes on with our internet connections, this should by far be the least of anyone's concerns.

I have uBlock Origin installed in Chrome. With all the ad networks and analytics scripts blocked. Google Analytics does not run in my browser. And yet, I am not even slightly opposed to homebrew's use of it. It's actually anonymous, unlike how many developers use GA in the browser (tracking IP addresses, custom fields like user ids that link back to the site's database, etc). God speed, homebrew devs.

If all this is true then why even go to the trouble of supporting opt out?

The support for opt out acknowledges (implicitly) that the choice to upload data is rightfully the user's own prerogative. Then paradoxically enables the feature by default anyway and places the switch behind some esoteric opt out commands.

Because they're not stupid and knew that the first thing out of naysayers' mouths would be "why is there no opt-out?!", which then gets followed up with "it shouldn't even be opt-out, it should be opt-in!". They tried to get out in front of the matter by even bothering to document the use of analytics, and implementing an opt-out mechanism at all. Unfortunately the nefarious ways in which intrusive analytics are used on the web has completely ruined the concept of gathering the most basic analytics in any situation.

They could have just added the analytics without saying anything. Which then leads to a) someone discovering the outgoing analytics request and reporting it on sites like HN, b) them having to defend the use of analytics and PR-fake-apologizing for not disclosing its use up front, c) implementing an opt-out, and then d) dealing with HN reports about it being opt-out instead of opt-in.

The privacy implications of analytics gets blown way out of proportion every time the subject is brought up. There is a huge difference between gathering basic information a la homebrew, and the way the large ad networks track and share your information across every damn website you browse. Yet there is this vocal group of people who treat them equally.

You might not support or use Google in any way. There are such people. They use DDG and go to extraordinary lengths to prevent any assistance to Google. I'm not one of those people, but the ability to turn off the feature is reasonable.

Some folks don't trust Google. There might be a case down the road where the U.S. government required access to the data due to National Security. Given how they handled the San Bernadino iPhone incident, it's not like this won't ever happen.

Others believe that Google will use the data for their own ends. In the same way other don't want Googke to become more powerful, others will be concerned that Google uses analytical data like this for their own commercial purposes, and it's not known what this might be.

It also would be a PR nightmare if this wasn't added, even though the data is anonymised to the Homebrew guys. Perception is important also. Not to mention the fact that it doesn't hurt to add this option to Homebrew.

Personally, I'll just leave it on as I don't subscribe to any of the above views, but I'm imaginative enough to see potentially legitimate concerns. :-)

I support opt-in as well. Make it the default option so people can press enter or use -y if you'd like.

I'm thinking along the lines of popcon in Debian http://popcon.debian.org/

If you can't verify that Google are actually anonymizing the data then you can't claim this is "completely harmless". I don't trust Google and this requires me to. Is that unreasonable to you?

I second that. It must be an opt-in feature.

I don't see why; you're tracked like this on nearly every website you visit unless you opt out. This isn't malicious.

That doesn't follow. The fact that many websites do this doesn't prove that it isn't malicious. It may not be (it probably isn't), but that has little to do with the complaints made about the change.

Since more people downvoted you than upvoted you, that proves that when most websites do something, it can't be malicious when an application on your computer does it. I think?

Not even your IP address is recorded. It's physically impossible for this to be malicious. There are no real privacy advocates complaining here, only people who post "it must be opt-in!" as an instant reaction to just reading the term "opt-out". Most of the complaints are probably from people who have never even used homebrew. The submission headline contains the phrase "Google Analytics", which attracts the people who always come to criticize the tool rather than actually analyzing how the tool is being used in each case.

> It's physically impossible for this to be malicious.

It's "physically impossible for Google to read the IP header addresses if the pack data contains "&aip=1"? The IP is still logged with Google, according to their own documentation[1]:

    When present, the IP address of the sender will be anonymized.
So-called "anonymized" data can be re-correlated with the original values. DJB's gave a great description[2] of this problem, right after he started working for Verizon[3]:

    Hashing is magic crypto pixie-dust, which takes personally identifiable
    information and makes it incomprehensible to the marketing department.
    When a marketing person looks at random letters and numbers they have no
    idea what it means. They can't imagine that anybody could possibly
    understand the information, reverse the hash, correlate the hashes, track
    them, save them, record them. 
[1] https://developers.google.com/analytics/devguides/collection...

[2] https://projectbullrun.org/surveillance/2015/video-2015.html...

[3] If you don't believe that DJB works for Verizon, ask the man in the middle... who may have been making an elaborate joke.

>> The IP is still logged with Google, according to their own documentation

Not quite[1]. The full IP never makes it to disk. It's true that "anonymous IP" isn't as anonymous as I'd have expected. Only the last octet of an IPv4 address is removed. Considering homebrew's use specifically, not just looking at GA in general, I think this is acceptable.

[1] https://support.google.com/analytics/answer/2763052?hl=en

> The full IP never makes it to disk.

The full IP makes it to Google. We don't know what Google actually does with the packets they receive; we only know what they say.

> Only the last octet of an IPv4 address is removed.

Really? Wow. They aren't even pretending to anonymize addresses with a hash. Given that there is certainly more than 8-bits of identifying data in the other data sent to GA, a unique identifier can easily be recovered. Also, the bits they mask are the least interesting part of the address. They are preserving the network part of the address, which probably gives them the AS number.

> Considering homebrew's use specifically, not just looking at GA in general

That's the point - homebrew is choosing to add data to GA, which cannot be considered in isolation. The problem with GA isn't that they collect data from any particular site. Knowing that you occasionally visit ${website} might be interesting, but it's of limited value and relevancy. A list of people that visit ${political_opponent}'s website might be very interesting, but most of the time nobody is going to care. Knowing that you installed some software isn't interesting in most cases.

All of those situations change when someone can aggregate the data. Consider all those data points combined with the other websites that send data to GA, gmail, when you loaded the Javascript, fonts, etc hosted by Google. Add in all the data that is sent to Google from Android devices, Chrome, Nest, and every other product that Google (err, "Alphabet") is involved in. In aggregate, just the timestamps and partial address information will produce surprisingly accurate profile of your life. This gets scary when you start to do an actual pattern-of-life analysis and correlate "anonymized" data back to real names.

>They are preserving the network part of the address, which probably gives them the AS number.

Yep, it is guaranteed to reveal your ASN because the smallest IP prefix on the internet is /24.

The last 8 bits are not dependent on the network address.

I think the phrase you're looking for is "no true privacy advocates."

Yes, but those are websites. Some degree of tracking is vital to the functioning of many websites. e.g. No cookies, no sessions (generally speaking). Furthermore, it is expected that a lot of websites are tracking you.

I feel pretty safe in saying that most developers do not expect a command-line tool to phone home without saying, especially if this behavior was introduced in an update for a tool which didn't do that historically (and without any notification of the change).

Considering the popularity of this tool, it's a bit shocking that the core dev team of Homebrew didn't seem to anticipate that people would be upset by this. It really knocks my trust in and willingness to depend on this project.

Opt-in, like optional security, rarely gets used.

That's not a user problem.

It most certainly is if support is focused on the wrong packages and features because they don't have the data to make informed decisions.

By that logic, CPython should track usage stats too.

It does to a very limited extent, in that pypi collects downloads statistics.

Change it to opt-in, please.

> I apologise for the poor communication.

Try apologizing for your poor behavior. You didn't "communicate poorly;" you offended people who used your software, and betrayed their trust. You can either make this thing opt-in, or "ease the opt-out process" and continue being a jerk.

Feeling this betrayed and entitled over anonymous analytics in an open source project?

I personally don't care about the tracking, since I don't use homebrew, but corporate f-you non-apologies annoy me. No one is complaining about "poor communication;" they're complaining about a feature they dislike. An actual apology would be something like "I apologize for adding this feature, and I am removing it."

When it's not opt-in, yes. As developers, we should know better.

Since there is a lot of negative comments here, let me add the counterpoint here that I am totally fine with this. For me, any time saved by enabling you guys to build better software is well worth it. Thanks!

Thanks for the changes!

Please leave it like countries with good organ donation opt-out policies.

Speaking of which, become an organ donor if you live in an opt-in country.

Like in Brazil, where there are real cases of people convicted of murdering donors to sell their organs to rich people?

Third-world country edge-cases. Murder is still murder. The preponderance of donations in first-world countries saves lives, but is so rarely done despite the pressing demand. When you or family member needs a life-saving transplant, which system would you want?

The one where the organ was freely and explicitly offered, not harvested from a person who might have mistakenly believed their body would still be theirs in death.

The fact that they are transparent about this, that we can opt-out if we want and that they're open source makes me feel more than comfortable sharing anonymous usage information with them. Homebrew has been amazing for me!

Is an alert displayed to the user the first time it tries to send info to Google? If not, that is far from "transparent". It's good that they tell you how to opt out on the website, but I can't remember the last time I went to the website. Probably when I first installed Homebrew on this Mac.

This. Either everyone should be notified before the first google analytics transmission so that they can choose to opt in our out. Or the default should be off and maybe on new installs they can choose to opt in. At the opt in/out dialog (when you give the users a choice) you can make the default to opt-in, but having the default as opt-in without any input from the user is bad form. It is similar to spammers calling your e-mail address "double opt-in" because they got you to open an e-mail and you didn't click the unsubscribe link.

How should this be handled if the software in question is a server daemon? I want the users to make an explicit choice but it's not obvious what's the best way to do that.

On install.

Or if you want to cover existing users, just ask during the first interactive invocation, when there is no prior user chosen setting (works for new installs too)...


  choice = no
  if $brew_prefix/etc/homebrew.yaml:
    choice = read analytics $brew_prefix/etc/homebrew.yaml
    if interactive-tty and cmd != "--prefix":
      choice = ask-user "enable anonymous analytics (it helps us!)? Y/N: "
      write analytics=<choice> $brew_prefix/etc/homebrew.yaml
  if choice == yes:

I feel like on update would be better. Answering a yes/no/never isn't that much of an ask, I don't think. And that way you get a chance to use the software before you have to make a decision.

Get littlesnitch on Mac and you won't need to rely on third parties alerting about outgoing connections, although I recon the when we're talking about something like homebrew it's not easy to vet every single outgoing connection.

Still littlesnitch is really awesome for the privacy conscious users.

I have little snitch and can verify that everything talks to the Internet all of the time :(

Only if you let them. I have installed little snitch and the only applications that have unlimited access to the Internet (all servers on port 80/443) are my web browsers. The other applications barely have access to their on servers (only if I find it necessary for them to auto-check for updates) let alone google analytics.

To achieve the best security, you should disable most bultin rules or customize them yourself.

Many of the requests come from various services that I don't feel knowledgeable enough to disable. Like gamed, iTunes etc. no easy way to figure out if something is phoning home or a (close to) critical OS X service.

Could you point to a source which would help me educate myself?

Well, blocking OS X from phoning home is probably impossible or at best very dangerous (because you block all of OS X's anti-virus blacklists).

But most other processes are easy to block. The first thing you should do is check the name of the process. If it is something like iTunes, you need to ask yourself if you want iTunes to have Internet (do you want Apple Music/radio, wifi sync, and the iTunes Store? If not, just block all ports/servers for iTunes. If you only want Wifi sync, enable connections to the local network only (best do it manually in the rule settings). If you want iTunes to have Internet, I'd allow port 80 and 443 to apple servers and apples CDN (you will end up having ~15 rules, just allow the servers as you see fit and when prompted). Since iTunes is from Apple, it uses some system services to communicate with iCloud additionally, by default they are all enabled and you don't have to do anything. All essential system processes are allowed by default. I personally disabled most of them since I don't need most of them. Let's have a look at gamed. gamed is a system process to communicate with the Game Center services. If you want Game Center to work, you will also need to enable this process. You can learn that by yourself if you click at the question mark on the bottom left corner when an alert pops up. It shows additional information for all system applications, and most popular apps. If it says that this process is needed for Game Center but you don't play any games on your Mac, it is safe to disable.

You can do that for all processes and eventually work out a list with trusted services and applications. I personally often only allow some applications Internet to port 80 and 443 and only if I know the apps really need it. If you don't trust the app at all, you should update it manually (by downloading the newest version on their website).

~15 rules per service is what I'm having trouble with. Lots of expertise to acquire and apply.

LittleSnitch also makes you totally paranoid about how almost every piece of software is spying on you without explicit consent.

Also, Microsoft really needs to clean up their domain usage, because it takes 999 permission rules to run Office.

In a similar vein, installing uMatrix makes you (rightfully) paranoid about what web pages are collecting from you. "Wait I can disable 28 Javascript scripts and iframes and the page loads OK?"

Skype is even more fun to watch in Little Snitch with all of its p2p connections. I regularly have 2k+ connections being opened to sync online state.

For posterity, Homebrew is using curl to talk to Google Analytics. You will have to selectively block curl by destination in Little Snitch (or only allow the various other hosts Homebrew uses).

I block the google analytics at DNS level at home. However, don't use a Google product such as Chrome as it will totally ignore your DNS settings. There is also an issue of some webpages not loading because its waiting for google analytics to finish loading. So I normally re-direct the data to an internal server in my net that captures all the traffic, which will allow the server to finish loading (also allows me to replace image Ads with Jolly Rogers images).

The issue with this is that the DNS settings only apply at home. And most mobile devices totally ignores the DNS settings as well, using the one provided my my carrier instead.

I am confirming that Homebrew silently starts talking to Google with no warning after a "brew upgrade".

I was prompted with a warning during my most recent brew update...

I brew updated a few times today and finally got that message. By the time that message showed up, the file ~/.homebrew_analytics_user_uuid was already 4 hours old, which makes me wonder when they actually started doing the analytics

I updated Homebrew almost daily and my .homebrew_analytics_user_uuid shown that it was created on Apr 24[1], which means I have been sending the analytics data without knowing for two days already (UTC+7) :-\

[1]: https://files.grid.in.th/plBnTi.png

I get the following:

  % brew update
  ==> Homebrew has enabled anonymous aggregate user behaviour analytics

The fact that it's opt-out rather than opt-in... yeah, well. I don't think I need to finish that sentence.


The right thing to do would be to make it opt in, not opt out. (Which would not be without precedent. Debian's popcon is opt-in.)

Disagree. Google Analytics is a network of companies that has agreed to privately collection information about users without their permission or even knowledge. It is malware that should not be included in Homebrew. The only ethical decision we can make as developers is not to use it.

Yeah, I'll confess that this is a real deal breaker for me personally .. I'll be having a closer look at ports and maybe fink soon. Maybe after all its time to get off OSX and back to Linux, where these sorts of things happen less frequently ..

If it means that much to you, why not add host file entries to point GA's DNS records at or something else invalid? If you don't trust that either, supplement it with packet filter rules to drop traffic heading to the IP addresses to which those names (currently) resolve. Switching platforms seems like a major overreaction here.

Privacy should be the default.

Only if you're willing to pay for it. Otherwise, you trade privacy for convenience, or some other benefit.

Its, of course, always your choice if you're willing to trade it for something.

There is a lot of free, open and convenient software that respects my privacy.

Do you think money or privacy violations must be part of the equation to make good software?

That is like the old argument against free/open software that I heard from a lot of people, back in the 90's. I thought we were past that.

Its a huge hassle, and I don't want to have to keep fighting the battle against this policy. So I'll just rather switch.

Maybe try out Nix while you're at it, too! I'm using NixOS, and I'm pretty happy with it so far. The standalone package manager fills the same niche as Homebrew, I think.

I only use Linux, so what do I know, but... is the highly interesting Nix package manager a full alternative to Homebrew ?

Or you could just say HOMEBREW_NO_ANALYTICS=1 and be done with it.

Until next month when we might need to set HOMEBREW_NO_PIWIK=1337...

I'd assume "NO_ANALYTICS" would mean "no analytics" not "no google analytics?

Who knows!? This marks quite a change in attitude where the end user is suddenly responsible for staying on top of newly silently introduced opt-out settings. I'm pretty disappointed and feel the amount of trust I've had in the maintainers have dropped considerably. Sneakily sending random HTTP requests to third party analytics services and stuffing my dotfiles with unique identifiers for tracking purposes is not what I expected from a friendly open source project.

This could have been handled much better with some sort of opt-in prompt like the debian installer does for its popcon usage tracker.

>This marks quite a change in attitude where the end user is suddenly responsible for staying on top of newly silently introduced opt-out settings. I'm pretty disappointed and feel the amount of trust I've had in the maintainers have dropped considerably.

I agree with you. I'd much rather have this be out in the open - like, ever 5th time I run 'brew' or something, it asks me for permission to send analytics, and the options are "YES-once, YES-Always, NO-NEVER", and if I say NO, NEVER, it never asks me again.

If spying on me can be automated, so can not spying on me.

I'd assume that software that wasn't sending analytics wouldn't start doing so without at least informing me first, but I'd be wrong. I think the parents point is that we can't trust Homebrew to do the right thing, because they've now chosen not to.

Yep, and as you can see if you read the code there are as few references to GA as possible so that it’d be easy to change the service we use without editing code everywhere.

Would be somehow more ethical if they set up their own piwik instance to collect the same data?

Collecting telemetry is reasonably, but it seems inappropriate for Google to get a copy and to be able to identify which of their users installed a particular piece of software from the IP address.

So yes. Running their own server would be much preferable.

For Homebrew:

> The Google Analytics anonymous IP setting is enabled i.e. 1 (https://developers.google.com/analytics/devguides/collection...)

It's worth noting that AIP's functionality requires you to trust Google -- the data is received by them, but their design specifies that they mask it before it's processed or stored.

Or so they claim.

While I feel we should all treat Google with skepticism here, I didn't realize they (and so failed to acknowledge) that Homebrew was attempting to remedy that, so I apologize for speaking out of turn.

We don’t have the resources for this. If you have any suggestion for a service that doesn’t require us time to manage we’d be very grateful. Homebrew have a dozen maintainers for >30 PRs & issues per day plus maintaining our own CI infrastructure plus normal development; and all of this is on our spare time.

As a Homebrew user, thanks for your efforts. I'm totally fine with the change myself, and I apologize for everyone else in here who cares about their privacy, but doesn't really care about the time volunteers are committing, nor the time savings from this feature.

I concur, thank you for wanting to do a better job with readily available tools that are widely used and easy to implement. I support your use of GA.

Add a feature where users can opt-in for periodic reports to be uploaded as a private gist, and a link is transmitted to you. GitHub is already a trusted party where Homebrew is concerned, so the loss of privacy is minimal. Users control their own GitHub accounts, so they control of the permanence of the data you collect on them. You can use Google Forms to transmit the links, so your infrastructure is cheap-to-free. For bonus points, encrypt the links with your public key.

How does that sound?

We don’t want personal data; we only care about aggregation. Being able to link each gist to its owner would be a privacy issue here.

Excellent point, I should've thought of that.

So the project is short-handed, but wants to take on scouring analytics to start packaging common things people are doing with the software.

If you're too busy to do this "right" why bother? Are you hoping making more shortcuts will increase adoption?

Current employer doesn't much care about these things, but last employer did. Having shared this thread with their IT folks, they've decided to cut people off from homebrew while they figure it out.

I guess costing yourself users is one way to free up some time.

As I wrote we’d be very grateful if you had any suggestion.

Have you tried getting donations for the project? Have you tried joining a foundation that supports open source projects (like Apache)?

Yes we recently joined the Software Freedom Conservancy so we can now accept donations.

I think it would be, yes. At least, it would not get into the hands of an external 3rd party (that as we know, lives from selling / using data they gather from people).

Google does not use GA data unless the webmaster chooses to share it with them.

I'm not sure if they use it to improve their ad products, but I wouldn't be surprised if the answer is no.

Firstly, this is a decision that should be up to the user, not the webmaster.

Secondly, do you have a source for that? I find that a very dubious claim, from a business perspective.

> this is a decision that should be up to the user, not the webmaster.

This may be a dumb example, but if I get someone (I don't know very well) a glass of water from the kitchen, I won't take a little sip from it on the way. Yes, they might not care, and it's super unlikely that I would infect them with anything. But it's still not my call, and you only need to see someone not get something so basic once to lose a lot of trust in them, certainly if they actually start arguing about it. It's more than optional courtesy, it's a respect for boundaries and personal choices.

And it doesn't matter at all how much they are doing otherwise for you, that is orthogonal. By that I mean: nobody asked anyone to make something for free, we're just asking people to not unwittingly have them feed GA if they don't want to. If there are too many things to fix and too few developers, fix fewer things. It's just homebrew, not cancercure. If enough users disagree with that, let them all opt-in and/or volunteer their own time, problem solved either way.

If enough users disagree with that, let them take over maintenance of homebrew.

But nobody actually cares that much, only enough to complain. At length.

"We use the information we collect from all of our services to provide, maintain, protect and improve them, to develop new ones, and to protect Google and our users. We also use this information to offer you tailored content – like giving you more relevant search results and ads."


"When you visit a website that uses our advertising products (like AdSense), social products (like the +1 button) or analytics tools (Google Analytics), your web browser automatically sends certain information to Google... When you visit websites or use apps that use Google technologies, we may use the information we receive from those websites and apps..."


It should be noted this does not directly contradict what GP claims.

Also related:


Google Analytics protects the confidentiality of Google Analytics data in several ways:

Google Analytics data may not be shared without customer consent, except under certain limited circumstances, such as when required by law.

Security-dedicated engineering teams at Google guard against external threats to data. Internal access to data (e.g., by employees) is regulated and subject to the Employee Access Controls and Procedures.



> protects the confidentiality

For their definition of "confidential", which they can change at any time.

> certain limited circumstances

If they only intended the "required by law" example, they wouldn't use such a broad - and completely undefined - set of circumstances.

> guard against external threats

Google may have good security practices now, but an continually growing collection of highly-revealing tracking data is a very tempting target for many businesses, governments, etc. If Google (or anybody else) wants to claim that they are protecting your data, they should indemnify the subjects of their spying against any damages those caused by those "external threats".

>they should indemnify the subjects of their spying against any damages those caused by those "external threats"

I despise GA as much as the next guy, but you'd have to be pretty crazy to expect any business to provide such a guarantee. Google isn't your insurance company.

I don't really expect that anyone would make that kind of guarantee; I'm arguing in the style of a proof by contradiction. These businesses shouldn't be making this kind of claim, and they shouldn't be holding onto data beyond what is necessary. Data should be expunged as soon as possible, because then there isn't anything to protect.

Businesses are acting like there is no risk in holding personal information. When people complain, they respond with claims that the data is safe. When businesses act like they are secured and that we should trust them, we should be asking them to stand behind those claims. I agree, this is crazy, but businesses really want to make strong claims but not be bound by those claims. An honest business that actually believed in their own promises shouldn't have problem putting those promises into a formal guarantee.

>I don't really expect that anyone would make that kind of guarantee

Yet you do seem to expect that guarantee:

> An honest business that actually believed in their own promises shouldn't have problem putting those promises into a formal guarantee.

You can't use such guarantees to vet businesses because no sane company would meet your requirements!

That seems to say Google won't share your Analytics data without making any guarantee that they won't _use_ your analytics data.

Everyone who has signed up for GA knows it. When you sign up you are asked 2 questions:

Do you want to share data with google to imrpove our products?

Do you want to pool your data for benchmarking purposes?

Both are unchecked by default. But here you go, I will search for "google analytics data sharing" for you.


Indeed! Feel free to demand a refund or refer to the contract you signed... Nobody's forcing anyone to use it.

This is the sort of defeatist and way-too-easy attitude that turns things to garbage all around. In many ways, bringing up issues that affect many opinionated people's core values is how things get fixed. If this was said for everything that was free, then we wouldn't have anything.

For example: "Linux has issues" "It's free. Nobody's forcing you to use it."


"FreeBSD has issues.." "It's Free. Nobody's forcing you to use it."


"I had a hard time installing Gentoo because of bad documentation. Somebody should fix that. No, seriously, metaland." "It's Free. Nobody's forcing you to use it."

I'm all for "beggars can't be choosers", but when there's nothing else to choose, of course people are going to complain.

The usage license we agreed to means we can fork it and remove this nonsense spyware.

I'm always amused by the way some people try to extend the definition of malware beyond its scope. This isn't malware. It's just anonymous usage tracking. If you don't like it you can turn it off. I hope you don't use a smartphone because the amount of intrinsic "malware" you must be subjected to must be unbearable.

"Malware" is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruses, worms, trojan horses, ransomware, spyware, adware, scareware, and other malicious programs. It can take the form of executable code, scripts, active content, and other software.

Definitions vary, but I once wrote these notes for the definition in a security policy. It is probably more broad than what some people would write.

    - Any software that actively attempts to do any of the following:
	- Do harm to the system, applications or data
	- Deliberately weakens system security
	    - By changing system or user security settings
	    - Contains or installs backdoors
	    - Downloads updates as executables
	    - Use executables to wrap otherwise readable data
	    - Expects higher or more privileges than is needed by it's function.
	- Circumvent the wishes or intention of the user
	    - Makes it self the default application for file-types that already have an application assigned to them
	    - Inserts itself into other applications against the users expectation (eg. as a plugin)
	    - Uses the privileges of other applications to circumvent system policy
	- Hide its activity from inspection
	    - Anti-debugging, and other rootkit like behaviour
	- Use "dark patterns" to trick the user into performing or agreeing to some action
	    - Installs toolbars, etc.
	- Compromise the privacy of the user
	    - Phones home, access data irrelevant to it's function
	- Resists removal

I don't see how GA can be classified as malware according to this.

Automatically opting a user into data collection, without explicitly asking the user, is a dark pattern.

Requiring the user to set an environment variable to opt out is smarmy.

Phones home...

It does not compromise the user's privacy in any way. GA prohibits PII. Also, the webmaster has to opt-in to share the data with Google in the first place.

Some people disagree. If they didn't, why is this on HN with a lot of comments from people who a unhappy with this change?

If software compromises my privacy, I feel that I have been betrayed and lost something that I can not take back.

If you don't get to automatically participate in a "anonymous" usage survey, have you lost something you can not undo?

That in my opinion, is why software should always err on the side of privacy.

People just LOOVE to be outraged. For example in this thread people rage about google getting hands on their data. When I point out that the webmaster has to explicitly chose to share the data with google, I get downvoted. When I say that GA prohibits the use of PII, I get downvoted. It doesn't matter that I'm right. People WANT to be outraged. Reason, no reason, doesn't matter.

Chill, dude. Most of us dislike GA and its monopoly on web/mobile tracking. Why trust GA to respect webmaster options when you don't have to?

...anyway, complaining about getting downvoted is a surefire way to keep getting downvoted :P

I didn't say that this usage of GA is malware, I said that GA, the network, is a malware. So while Homebrew may (or may not) be protecting their users identities while using a malware service, they are still choosing to use a malware service.

Tracking people's online activity through a large percentage of the internet, without their consent or even knowledge qualifies as malicious to me.

But surely you can see the similarity here. The tracking software wasn't in Homebrew before, is added without asking you when you update, and is completely useless to you as a user but builds information about you and sends it to a third party.

If it's not malware, it's certainly really similar to it.

It is used to improve the product, why is this useless to the user?

Software that ships Ask Toolbar in their installer say it's to improve the product as well.

never underestimate people's principled paranoia rofl

Does Homebrew's UUID linked with the user's Google Analytics ID in their browser cookies?

It certainly appears not. They're using curl and reporting a UID they generate.

   A Homebrew analytics user ID e.g. 1BAB65CC-FE7F-4D8C-AB45-B7DB5A6BA9CB. This 
   is generated by uuidgen and stored in ~/.homebrew_analytics_user_uuid. This 
   does not allow us to track individual users but does enable us to accurately 
   measure user counts vs. event counts 

Of course, you have to trust homebrew, but hell, you're already running their software, so it's a little late.

You can always even check the code that’s running on your own computer. If you installed Homebrew in /usr/local the relevant files are /usr/local/Library/Homebrew/utils/analytics.sh and /usr/local/Library/Homebrew/utils/analytics.rb.

That's probably true, but then no one would opt-in.

Or, even worse, there'd be a selection effect where the distribution of people who opt in is skewed from the total distribution of Homebrew users, ruining the dataset for any analysis one might want to do to it. There's a reason that Nielson Ratings collection isn't opt-in.

Funny, it's been quite a few years, but I remember being a Nielson family for a few months, and it was absolutely opt-in. We had to fill out a little booklet with what we were watching and data about ourselves.

You can't opt in to Nielson because they choose who to give the boxes to. Of course it's optional to do it if they do ask you if you want a box.

Although if Homebrew wasn't using Google Analytics, maybe people would. It could just be a "Do you mind sending us anonymous usage data? [y/N]" prompt. Many other apps do something equivalent, and I don't mind giving it to them. The fact that those apps ask in the first place makes me much more amenable to the idea.

"Do you mind" would be counterintuitive. I see analytics and want to respond "n", for no analytics

...which is very telling.

As in, people want privacy at the expense of volunteer time.

Simple solution: Charge people for using Homebrew who don't want to send analytics in, fund Homebrew development with those funds. Otherwise, its an external cost being foisted on the volunteers by developers who want privacy at the cost of additional volunteer time.

EDIT: The tone of this thread is the exact problem with open source projects and participation. "I want a say, but I'm not willing to contribute in any way except use your tool you're providing for free." Sad, but expected.

I think most people aren't concerned so much about sharing usage data. The problem is specifically the way it's being shared via a third party. Other apps ask if I mind sharing some data (e.g., Firefox), and I don't have a problem with that.

Okay. Is everyone going to pony up for a self-hosted analytics box and the time to manage it? No? Of course not. Everyone wants to complain, no one would contribute resources to do it though. Privacy has a high moral value (its free to want it and complain about it), but small economic value (you use Chrome? It sends everything you do back to Google. You'll still use it, because its better than not).

a HN thread is not the appropriate place to ask for resources for a project.

There are many OS projects out there with larger needs than an analytics server that have managed to get the support they need. If resources are an ongoing problem you even have the option of applying to join a free software foundation like Apache that has resources.

> join a free software foundation like Apache that has resources

There's a reciprocal arrangement here. One of the requirements of joining the Apache Software Foundation is using "Apache" when refering to the name of the software product for the first time in a new context, e.g. first mention on a webpage. Apache Groovy was promoted from Apache's incubator last November (2015), so I've been doing just that ever since. Unfortunately, many of the developers who work on Groovy don't bother, availing themselves of those resources but not giving back to the foundation the small amount asked.

Just like open-source doesn't come with warranties from the creator, it also doesn't come with obligations to the end user other than to abide by the license.

You use Homebrew. In return, you send anonymous stats to save the developers time. If you'd prefer not to, set the env var or stop using Homebrew.

Alternatively, fork it, take out the modifications, and run your own version of Homebrew. But that takes time, and effort; that same time and effort homebrew devs are trying to save with a feature. Why is your time as a user valuable but the Homebrew dev's time not?

Not necessarily. Opting in takes effort, and people aren't really seeing any reward, so they would be less likely to take the effort.

You can make it so that opting in and out takes equal effort.

I'd consider it less strong opinions and more power of defaults.

At 193,622 submissions, I wouldn't say "nobody" opts in to popcon:


This is software, they can just ask instead!

Which might break some scripts that expect home brew not to require user input. The right way to do it would be to ask if a terminal was available but in reality, scripts are not careful enough to tell applications that they are in fact headless. I've seen some scripts break under that assumption.

Did it print a warning when upgrading on terminal?

They could have a prompt with a countdown, you opt in it you don't say 'no' after a minute.

That's kinda the point.

... which, if true, tells you something about the value of this 'feature' to the user.

Or, you could edit /usr/local/Library/Homebrew/utils/analytics.rb to send Google Analytics garbage (from random UUIDs) until Homebrew makes this feature opt-in.

This is a great idea.

Any rubyists want to provide a patch to do this?

trashing the telemetry data they're using to figure out what OS/ver people are using and bugs they are hitting makes you a real jerk

use their opt-out if you want

Collecting telemetry data without letting users even know about it (much less opt in) isn't cool, either.

I'm really having trouble understanding this (and I appear to be in a very very tiny minority). Why would it bother you if homebrew devs and Google knew which packages you had installed?

Fair point, the public shaming that is happening now is probably punishment enough.

Frankly I don't trust the opt-out code to be (and remain) bug-free. There are, as far as I can tell from searching, no tests. So I feel more comfortable maintaining a patched version with the calls nooped instead.

You can also submit a pull-request to add tests or fix any bug you can find.

Totally agree. I don't feel too comfortable bout google knowing everything about me... Should be opt in.

Did you read the link? Your actions cannot be tied specifically to you.

Says the company that offers the service? There's traces , ips, etc. everywhere, not impossible to correlate...

1) Homebrew is not a company. 2) It's open source.

1) Google the company. 2) GA is not open source nor does it matter when it's your data on someone else's server.

What makes you trust Homebrew over Google? What makes you trust anyone with your data online?

Well, up until now, Homebrew wasn't specifically collecting any information.

Then stop using Homebrew.

You may also want to "rm ~/.homebrew_analytics_user_uuid"

You could really screw with their statistics by regularly changing the contents of that file.

Homebrew maintainer here. Remember that we didn’t put these analytics in place to get rich or get free beer at the local pub. Screwing up the stats won’t help anyone.

We currently don’t have any overview of our userbase; we don’t even know how many people use Homebrew. More importantly, Homebrew currently only bottles the default options but we know some people use some options that cause the formulae to build from source. If tomorrow we see that e.g. `brew install foo --with-bar` is run by hundreds of people everyday we could start bottling it and saving time to everyone. But right now that’s completely dark; the only insights we have about the usage is people opening issues/PRs.

Out of curiosity, would the homebrew maintainers be open to replacing google analytics with an open source setup if the infrastructure was sponsored?

I can’t speak for all the team here but yes that’s something we’d consider. Someone suggested Keen IO on the issues tracker which is not open-source but it’s the only viable alternative that has been proposed so far, and it’s not from Google so some people would be more happy with that.

Amazing. I've been using --with-python3 a lot, having a bottled option would be great.

I'll leave analytics turned on, but the blog post says it'll strip arguments. Your example above seems to conflict with what the post says, no?

Yeah it’s not implemented yet. We’re doing it incrementally and actually started shipping the first bits one month ago (but it was opt-in for tests). Bottling the most used options is something we’re really excited both as maintainers and users and is IMO the number 1 reason these analytics will benefit everyone. We’re currently looking how it behaves and will add them soon.

The biggest benefit of this change is getting people to reconsider their usage of homebrew. For example, now I'm looking into Nix. These sorts of changes fuel competition and innovation.

I'm reminded of when Adblock Plus went sour, and we got uBlock Origin. There are lots of examples of this.

its better to create am empty ~/.homebrew_analytics_user_uuid and remove write permissions

Where's your reasoning? Homebrew gave theirs.

Keep in mind that no personal info is ever sent. Just a random UUID.

My reasoning? Because it's good to respect the privacy and choices of your users. Homebrew never called home to Google in the past, most people would not reasonably expect it to suddenly start doing so without letting them know.


I expect that if it was opt-in most people wouldn't take the active step to do so. And if given a choice on first-run, a large proportion of users would choose to disable the analytics reporting.

Making it opt-out seems deceitful - an attempt to trick users into leaving it enabled.

And the Homebrew developer responses thus far on the GitHub issue (users should be watching the documentation and Twitter feed - they'd have seen the announcement) seem unrealistic and unfair.

This should have been opt-in from day one, not opt-out. Especially if it's changing existing behaviour (having never automatically reported telemetry in the past).

One decent reason would be that existing installs arguably shouldn't change their privacy considerations without a hoop to jump through.

I block Google Analytics in my web browser, too...

> no personal info

> Just your universally unique id


> > Just your universally unique id

How is a Homebrew UUID personal info?

They send more than that, have you checked out the code? Every time you do an install Google gets to know about it: https://github.com/Homebrew/brew/blob/acc9a7ca8554bc2413dee2...

Maybe this is sufficiently private, maybe not. I'm not a security expert.

Maybe GA's fingerprinting heuristics are advanced enough to know that because user 1034324234 installed spacemacs at 4:01 and I visited the spacemacs documentation at 4:01 that there's a decent chance I'm user 1034324234.

Decent enough to see if the pattern happens again. After a few rounds of this, it's close enough to serve me ads based on user 1034324234's install patterns.

:shrug: doesn't sound crazy to me.

Ads which you'll no doubt block anyway. Not seeing the issue here.

It's on my PC.

"oconnore" is a perfectly valid unique identifier on HackerNews that doesn't tie to anything about you if you don't have your email address in your profile. This is no different.

The difference is, it's a choice to post on a public website. homebrew is a package management tool, there is no expectation that it will send information about you to Google.

>is a package management tool

This. The reasons they articulate for suddenly deciding on performing this data collection, and for doing it via GA are laughable. I am sufficiently annoyed at this because of the generation of yet another outbound data stream from my system, but the fact that in all likelihood the project will do nothing with this data really annoys me. There is zero need for this in a package system.

he does have the email, though

What is the mechanism in which Homebrew inserts itself into every shell session anyway? I had expected it to be loaded somewhere in some shell initialization script, such as .bashrc or .bash_profile, but I couldn't find anything.

It doesn't — by default, Homebrew lives in /usr/local/bin/, which is already in the default $PATH on OS X.

But then, by which mechanism does Homebrew notify GA that I have opened a terminal tab? There is a curl command executed every time, and I see a connection to GA with Little Snitch.

Is there some way to see the caller of a process? htop displays no parent in the tree view.

You probably have something in your .bashrc, or shell equivalent, that is launching brew.

Yet another reason to ditch the antiquated Homebrew, and switch to the cross platform Nix:




Aren't the majority of Homebrew users on Mac OS X? Does Nix work on Mac OS X?

Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers).

And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like.

But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions.


In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).

Could you provide constructive criticism for why Homebrew is so bad instead of lambast it?

Here's why I don't like Homebrew, and why I believe Nix is (almost) strictly an improvement over it:

1. Updating packages is not safe. If I update openssl and the ABI changes, all of my currently installed packages that depend on it are now broken -- time to rebuild everything. I've burned way too many hours on ABI breakage and rebuilding everything. That problem can't happen with Nix because Nix will ensure that each library is linked precisely to the versions of the libs they need.

2. Nix has a continuous integration server (called Hydra[1]) that builds every package, and caches the binaries. Because Nix knows each packages entire dependency graph, Hydra only needs to build just the packages that have changed. When I want to update some packages, I can count on not having to rebuild everything myself. Each binary package is signed, so I know my stuff is coming from the build server, regardless of whether or not I get the files through a cache or third party. I can also run my own Hydra instance to build my OS X and Linux packages, and I can share the binaries with others should I wish.

3. The lack of determinism. With Nix on OS X, packages are built using OS X's native Sandbox APIs to ensure that the build process can only see the dependencies that were explicitly specified. This guarantees that if the build works on my machine, it will work on yours -- whereas I've seen brew formulas under-specify configure flags and such, resulting in the default of linking to non brew installed libraries, causing quite a bit of confusion when things don't work at run time, or just flat out fail to build.

4. Brew is OS X specific. Nix works on OS X, Linux, and a FreeBSD. As someone who deploys to Linux virtual servers, it's nice that I can use the same versions of packages both in development and production.

It's not all roses, though. We have a smaller community of OS X users at this point, so not everything works (thus my "almost" qualification). Regarding the underlying tech and the outlook for the future, Nix is a superior tool.

I wrote a blog post a while back about my experiments with Homebrew, which covers most of the major security concerns I have with it. I hope it's clear from the post (linked below) that I went into the process with an open mind, and even positive expectations, because so many people really like Homebrew. But, I was alarmed at the implications of some of the decisions they've made; I understand why they made the design choices they made, but I don't think the trade off is even close to worth it. It is, as noted, particularly scary for server use, but I would be hesitant to use it for any purpose.


After that post was written, I continued to tinker with Homebrew (because it is so popular, it was really hard to completely toss it aside), but found a number of other problems. While it has lots of packages and they are often very up to date, updating over time and upgrading/downgrading versions, both proved fragile.

In a world with so many really good package managers, I find it unfortunate that the one that captured so many people's imagination and enthusiasm is broken by design, and in ways that have been understood for decades (even before good package managers, it was understood that you don't run all your servers as the same user). Or, at the very least, cannot ever be a general purpose package manager for operating systems; if you understand the limitations and know you can never safely deploy to servers using Homebrew, and only ever use it on private development laptop/desktop systems, then I won't judge. I understand it is easy to use, has a lot of packages, and has a lot of good documentation. Those are good things.

Anyway, I'm a packaging nerd. It's a thing I'm weirdly passionate about (I've contributed patches to yum in the distant past, have been a maintainer of packages for all sorts of operating systems and OSS and commercial projects, and I maintain the package repositories for my company's products and projects). I have strong opinions, but they are based on much (much!) more than average experience; over the past two decades I've spent a lot of time building packages (for Linux, Windows, Mac OS X, Solaris, FreeBSD, etc.). It may even be the technical area I have spent the most time on, since it's been consistent across nearly every company and project I've ever worked for/on. Homebrew strikes me as a huge step backward.

Could you elaborate what you dislike most about home brew? I only don't like that they refuse to package old versions, although they are still supported by the author and quite popular (I'm looking at you Python). Furthermore, it often leaves deprecated APIs on my computer without offering to upgrade them (because other packages rely on them).

Yes, Nix works on Mac OS X. (I packaged X11/XQuartz, MacVim, and a few other things for OS X)

Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby?

It was nice back then. Packages didn't install themselves in /usr/local.

> Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby?

Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/) is shiny, rather than technical merits.

> It was nice back then. Packages didn't install themselves in /usr/local.

You might enjoy Nix, then -- for that reason, and the following:

1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share}

2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback.

3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default)

4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish).

[1]: http://www.pathname.com/fhs/ [2]: http://nixos.org/hydra/

That's the purpose of /usr/local.

/nix/store? Really? You can't just make up new root level directories. That's so wrong.

The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it.

- your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it

- build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to

Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly.

Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?

> That's the purpose of /usr/local.

I think you must have ignored a substantial portion of my comment. Let's take a look at what (part of) my Nix store looks like (you'll see it fundamentally looks nothing like /usr/local):

  ├── bin
  │   ├── bash
  │   ├── bashbug
  │   └── sh -> bash
  └── share
      ├── info
      │   ├── bash.info
      …   …
      └── man
          └── man1
              ├── bash.1.gz
              └── bashbug.1.gz
  ├── bin
  │   ├── git
  │   ├── git-cvsserver
  │   ├── git-http-backend -> /nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4/libexec/git-core/git-http-backend
  │   ├── git-receive-pack -> git
  │   ├── git-shell
  │   ├── git-upload-archive -> git
  …   └── git-upload-pack
Note that each package under /nix/store is its own prefix; that is, it contains its own bin, lib, share, etc.

/usr/local is a dumping ground "for use by the system administrator when installing software locally"[1]. If you need multiple versions of automake installed: tough luck, the paths collide. If you need multiple versions of Erlang: tough luck, the paths collide.

Would you like to be able to rollback your system by changing one symlink[2]? Too bad: when you last installed packages into /usr/local, your package manager clobbered the previous version.

Technically, we could make /usr/local a symlink forest pointing into /nix/store, but we don't: we want to make sure that only the packages we explicitly declared are picked up by build tools, rather than defaulting to searching through the currently "installed" packages.

> /nix/store? Really? You can't just make up new root level directories. That's so wrong.

Can you substantiate your claim? Note that "it doesn't feel right" doesn't count as a rational criticism.

[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...

[2]: This probably sounds like a bold claim. I tried to explain how this works above, but if you don't believe me, feel free to ask and I'll explain further. Alternatively, feel free to read the first paragraph here: http://nixos.org/nix/manual/#sec-profiles

Funny that you should mention the FHS. From that same document:

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

They really should be using /opt:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree

I left MacPorts because the political infighting between package maintainers often left ports hopelessly out of date.

That's basically the main reason why I left MacPorts. The other was the fact that they'd build their own version of already installed programs. The worst offender for a long time was tetex until they finally added support for looking at an existing tetex installation.

I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.

I remember switching from Fink and Macports because most of the time both of them would break or break something important.


See me where? I don't follow.

> generated by uuidgen

So sending a unique tracking number...

> enable us to accurately measure user counts vs. event counts

for the specific purpose of associating events from the same user...

> This does not allow us to track individual users

somehow doesn't accomplish it's stated purpose? The entire point of that UUID is to track individual users.

> The Google Analytics anonymous IP setting is enabled

Sending Google an additional boolean flag doesn't prevent Google from reading the Source Address from the IP header.

Would really prefer it to be opt-in instead of opt-out as others have said. Sharing the info with Homebrew is one thing, the GA borg-malware is another entirely. Something like that should require an explicit request. At least in the browser, I can blacklist all requests with uBlock.

Atom does the same thing and I'm not a fan. You have to explicitly remove the analytics 'package'. Soon every piece of software will be reporting, silently.

>Soon every piece of software will be reporting, silently.

Not ethically written, free software. You would never see this behavior from a GNU program.

Absolutely. If there were it'd be opt in and not to Google.

Seems like Homebrew is doing many things right:

- Anonimizing IP address.

- Explaining what data is collected, and why

- A way to optout

Something that could be better:

- Make this optout for new users and opt-in for existing users?

- Notify the user in some manner when the data is sent to GA for the first time?

- Change the uuid every X period of time to make things more privacy friendly.

[Edit: wording]

"[...] we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us [...]"

Isn't this a false dichotomy? Why can't other measures be used that don't require "resources" to do "detailed user studies" yet don't require on-by-default information capturing? Surely there are many open source projects that persist to make their users happy without this information, correct?

These kinds of "features" are a problem for open source, and I don't know that they are a good idea in general.

It's nice to know how and where your software is being used, but in many environments call-home functionality and auto-update functionality are non-starters.

Any non-user initiated network activity should be explicitly agreed to and available to be easily stripped.

We can and should do a better job with open source software than closed source would-be competition. Even if you aren't a privacy advocate, privacy is a priority of a significant amount of the technical community. It's significant enough that it should be addressed as a forethought to features like this, not an afterthought.

Things like this pop up as negative news entries that people gloss over. The guy who makes the snap decision "don't use brew, it phones home" today could be a CTO who never had that opinion changed three years from now.

Made me open an HN account just to say this

This is a very bad move and will further erode the already declining trust people put in package managers and software distribution channels. This is not transparency - transparency would be asking for user's explicit consent on the first brew invocation that includes this "feature". If this decision is not publicly reverted I will be removing homebrew altogether as it indicates a severe lapse in judgement, good faith or both on the part of the homebrew team.

Reminder - The NSA/GCHQ systems described their use of Google Analytics piggybacking to fingerprint and target users for exploitation.

They also used similar Windows error reporting to monitor what software/hardware users have.

Not that anyone should be snooping on what users do without opt-in permission, but even if we believed that Google "anonymize" it, there are still concerns.

More simply, there's just no reason for you to know what I do on my own computer. It's none of your business and I don't need a reason.

I don't mind homebrew collecting anonymous information about me but I do not want Google to get even more information about me (and since the ip address I use with homebrew is the same I use to surf the web, the information is not anonymous for Google).

It looks like everybody today wants to spy on you. Google, Facebook, and Twitter want to look at your browsing history, NSA wants to see your calls, emails, and messages history. Microsoft wants to know about everything you do at your PC and now even package managers want to have their share of data, too. What about asking my opinion first? Well, as homebrew developer have said

> The problem with opt-in is that you don’t get representative data.

Users do not seem to be enthusiastic about participating when they have a choice so let's go without asking them.

Isn't this the same info they'd get if they ran their own registry like every other package manager (instead of using GitHub)? In the grand scheme of things, this seems pretty minor to me.

See, that's why I am a diehard macports user. /opt/local and not /usr/local. No cross pollution with my own configure && make && make install packages, nicely separated and maintained.

macports requires all of xcode, homebrew just the CLI tools.

This statement is false. With only Command Line Tools installed, macports complains, but everything works.

Here's a github issue related to this for those who are interested: https://github.com/Homebrew/brew/issues/142

Tonight I'm going to read about pkgsrc and tomorrow give a try. It has active community last time I used it few years ago. Seems to have also binaries available at http://pkgsrc.joyent.com/install-on-osx/

  My quick notes on how to get started with pkgsrc
  More info:	http://pkgsrc.org/
  # Download pkgsrc
  curl -O https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc.tar.bz2
  # validate shasum
  $ curl -O https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc.tar.bz2.SHA1
  $ cat pkgsrc.tar.bz2.SHA1
  $ shasum pkgsrc.tar.bz2
  # extract pkgsrc archive. Mine lives at ~/Work and I also install built packages under Work.
  $ tar jxvf pkgsrc.tar.bz2
  # bootstrap
  $ cd pkgsrc/bootstrap
  $ ./bootstrap --abi=64 --prefer-pkgsrc=yes --unprivileged --compiler=clang --prefix="$HOME/Work/pkg"
  # append prefix/bin to your PATH
  $ cat ~/.bash_profile
  export PATH="$PATH:$HOME/Work/pkg/bin"
  # re-login to make PATH effective
  # Example build of dos2unix (poor example because lots of dependencies like perl...)
  $ cd pkgsrc/converters/dos2unix/
  $ bmake install
  ===> Installing binary package of dos2unix-7.3.3
  $ file ~/Work/pkg/bin/dos2unix
  /Users/petri/Work/pkg/bin/dos2unix: Mach-O 64-bit executable x86_64

You can find homebrew uninstall info from here


  # I did:
  # remove all packages
  $ for f in $(brew list); do brew remove "$f"; done
  # download uninstall script
  $ curl -O https://raw.githubusercontent.com/Homebrew/install/master/uninstall
  # review script
  # run uninstall script
  $ chmod +x uninstall
  $ ./uninstall
  # review
  # I removed
  $ rm -rf /usr/local/share/ /usr/local/etc/
  # Restore permissions
  $ sudo chmod 0755 /usr/local
  $ sudo chgrp wheel /usr/local

Honest question for people who are opposed to this update and think it should be opt-in: what do you see as the downsides or pitfalls of sending anonymised usage info to Homebrew / Google Analytics?

I really wish people would explain their reasoning here. I guess I just don't understand why handing a list of installed packages to Google is not my interest. Everyone in this thread seems to be just assuming that everyone else is already onboard with this reasoning.

I normally enjoyed the insight and comments of the thread more than the content of the article and don't comment that much.

But my personal opinion on this, only to share it and be heard possibly by the developers of homebrew, is that I honestly do not care about this. It's nice they are open about it, it's a hell of a tool and hey, if they want to track what I do to improve it, have my data.

I really don't see the opt-in/opt-out debate being so harsh on this. Because it's open source it should be opt-in? I really don't think so. Analytics are a valuable source of information for the developer and google provides a hell of a service for that. And you probably use several closed source tools that track you, sometimes without even telling you. Yes, you can really of external tools to block this, great for all of us those tools exists, you can use it for homebrew as well.

I wonder if all of the opt-in advocates don't use gmail for their email. I am pretty sure they do, and they are not worried about all of the tracking going on there? Or on other apps? Unless you really follow most if not all of stallman's computing principles[1], being furious about this, is, IMHO, disproportionate and a bit ungrateful.

So I am more than OK with opt-out. Nice that you wrote about it, nice that you provide a way to do it, and nice that you use your time to create such a great tool!


[1]: https://stallman.org/stallman-computing.html

Because it's open source it should be opt-in?

Because the sending of data to a third party is not directly related to the functioning of the software.

Analytics are a valuable source of information for the developer

Yet it's not the developer's data, it's the users' data.

you probably use several closed source tools that track you, sometimes without even telling you


I wonder if all of the opt-in advocates don't use gmail for their email. I am pretty sure they do


Nice links, that's why I like comments.

Ok, let's don't state it as an argument, but rather as a question.

Do anyone that's so much against opt-in is aware of closed source tools that tracks you and use it anyway?


Do you use any third party web service like gmail or any other?

Although I hardly think I'll get an answer from most. At some point you have to make assumptions, wether those are fallacies, ok.

It's true it's not directly related to the functioning of the software, but it improves it in anyway, then there's a connection with it.

I take developer side and I personally look for see the grater good/less harm and compromise.

Opt-in will likely give them very little % of adherence and thus rendering all of this useless. Most of the opt-in advocates have technical capabilities to opt-out in any way (homebrew way, network filters, forking ,etc...). So why not simply letting this go?

I do think homebrew is a rather technical tool so most users are tech savvy guys, but still.

For me, this is pretty similar debate to donating organs.


And I am 100% an opt-out advocate!

Do anyone that's so much against opt-in is aware of closed source tools that tracks you and use it anyway?


Do you use any third party web service like gmail or any other?

I can only answer for myself, and it's no to both, with caveats. I do have a hotmail account, but I only use it for subscriptions to public mailing lists. I've had it for over 20 years, and stopped using it for private correspondence around 2005. I also have an Android phone, but it's not activated (as in, I never gave it any credentials to log in to any Google services, and I do not have a mobile data plan). Any application I need is sideloaded, or installed with F-Droid.

The rest of my networked machines are running Debian, OpenWRT or NetBSD. I do have a Windows (8.1) VM on my work laptop, but that VM is switched off unless I get paid to use it.

It's true it's not directly related to the functioning of the software, but it improves it in anyway, then there's a connection with it.

It's not a given to any specific user that sharing their data will improve the software in areas that the user cares about. Nor is it a certainty that not sharing leads to the software not improving in those areas.

There definitely is a case to be made that more accurate metrics will allow the developers to make more focused decisions, and I don't think anyone is arguing against that. That's not what the argument is about. The question is whether the developers' need for data is sufficient justification to hand over their users' data to the biggest aggregator of personal data on the planet, and whether it is justifiable to do so without the user's knowledge (the primary reason for opt-in is because it's the easiest way to unambiguously ascertain consent).

Thanks for the link! I have been using http://winhelp2002.mvps.org/hosts.htm for many years but it looks like StevenBlack's file is more comprehensive and updated more frequently.

Just used this list to set up DNS blocks on my network (DD-WRT/DNSmasq forcibly handles DNS traffic, with a bash script to add IPv6 hosts entries). Seems to work well so far.

It's high time for CVE-like identifiers for privacy violations.

This is a great idea. Has there been any prior attempt at this?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact