Homebrew now sends usage information to Google Analytics(github.com)
github.com
Homebrew now sends usage information to Google Analytics
https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Analytics.md
328 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.
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"
> it must be
https://news.ycombinator.com/item?id=11568404
https://news.ycombinator.com/item?id=11568404
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.
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...
> 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...
[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.
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.
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.
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. :-)
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/
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]:
[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.
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.
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.
[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
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.
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.
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.
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 out is the problem: https://news.ycombinator.com/item?id=11572181
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.
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.
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.
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)...
pseudocode:
pseudocode:
choice = no
if $brew_prefix/etc/homebrew.yaml:
choice = read analytics $brew_prefix/etc/homebrew.yaml
else:
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:
enable-analyticsI 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.
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.
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?
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).
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.
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.
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.
seems like not, yet https://github.com/Homebrew/brew/issues/142
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
[1]: https://files.grid.in.th/plBnTi.png
I get the following:
% brew update
==> Homebrew has enabled anonymous aggregate user behaviour analyticsThe fact that it's opt-out rather than opt-in... yeah, well. I don't think I need to finish that sentence.
Set HOMEBREW_NO_ANALYTICS=1 to opt out.
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.)
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 0.0.0.0 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.
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.
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 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 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.
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...)
> 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?
How does that sound?
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.
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.
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.
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.
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.
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.
But nobody actually cares that much, only enough to complain. At length.
[deleted]
"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."
https://www.google.com/intl/en/policies/privacy/
"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..."
https://www.google.com/policies/privacy/partners/
It should be noted this does not directly contradict what GP claims.
https://www.google.com/intl/en/policies/privacy/
"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..."
https://www.google.com/policies/privacy/partners/
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.
"""
https://support.google.com/analytics/answer/6004245?hl=en
"""
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.
"""
https://support.google.com/analytics/answer/6004245?hl=en
> 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".
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 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.
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!
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.
https://support.google.com/analytics/answer/1011397?hl=en
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.
https://support.google.com/analytics/answer/1011397?hl=en
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."
or
"FreeBSD has issues.." "It's Free. Nobody's forcing you to use it."
or
"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.
For example: "Linux has issues" "It's free. Nobody's forcing you to use it."
or
"FreeBSD has issues.." "It's Free. Nobody's forcing you to use it."
or
"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.
"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.
Malware
-------
- 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 removalI 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.
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.
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
...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.
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.
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.
[deleted]
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.
Of course, you have to trust homebrew, but hell, you're already running their software, so it's a little late.
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.
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.
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.
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?
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.
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:
http://popcon.debian.org/
http://popcon.debian.org/
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.
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?
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
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.
[deleted]
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.
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.
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.
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.
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.
Agreed.
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).
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
...
[deleted]
> > Just your universally unique id
How is a Homebrew UUID personal info?
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.
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.
[deleted]
"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.
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.
[deleted]
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.
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:
http://nixos.org/nix
https://github.com/NixOS/nixpkgs
https://blog.errright.com/switching-from-homebrew-to-nix/
http://nixos.org/nix
https://github.com/NixOS/nixpkgs
https://blog.errright.com/switching-from-homebrew-to-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.
http://pkgsrc.org
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).
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.
http://pkgsrc.org
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.
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.
http://inthebox.webmin.com/homebrew-package-installation-for...
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.
http://inthebox.webmin.com/homebrew-package-installation-for...
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.
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/
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.
/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?
- 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):
/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
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):
/nix/store/2mmvks92lx37xghj0795ldzrg50lh2pg-bash-4.3-p42
├── bin
│ ├── bash
│ ├── bashbug
│ └── sh -> bash
└── share
├── info
│ ├── bash.info
… …
└── man
└── man1
├── bash.1.gz
└── bashbug.1.gz
/nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4
├── 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
/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
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 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.
[deleted]
engiqueer(1)
> 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.
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.
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.
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]
- 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?
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.
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.
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.
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.
> 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.
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/
http://wiki.netbsd.org/pkgsrc/pkgsrc_64bit_osx/
# 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_64You can find homebrew uninstall info from here
https://github.com/Homebrew/brew/blob/master/share/doc/homeb...
https://github.com/Homebrew/brew/blob/master/share/doc/homeb...
# 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
/usr/local/bin/
/usr/local/etc/
/usr/local/lib/
/usr/local/share/
# I removed
$ rm -rf /usr/local/share/ /usr/local/etc/
# Restore permissions
$ sudo chmod 0755 /usr/local
$ sudo chgrp wheel /usr/localHonest 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!
Kudos!
[1]: https://stallman.org/stallman-computing.html
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!
Kudos!
[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
https://en.wikipedia.org/wiki/Argumentum_ad_populum
I wonder if all of the opt-in advocates don't use gmail for their email. I am pretty sure they do
https://en.wikipedia.org/wiki/Ad_hominem
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
https://en.wikipedia.org/wiki/Argumentum_ad_populum
I wonder if all of the opt-in advocates don't use gmail for their email. I am pretty sure they do
https://en.wikipedia.org/wiki/Ad_hominem
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?
And..
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.
https://en.wikipedia.org/wiki/Organ_donation#Opt-in_versus_o...
And I am 100% an opt-out advocate!
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?
And..
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.
https://en.wikipedia.org/wiki/Organ_donation#Opt-in_versus_o...
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?
And..
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).
And..
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).
Not on my computer: https://github.com/StevenBlack/hosts
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.
I think it's very reasonable to prompt a message on install saying "Homebrew collects and sends anonymous analytics. Use Homebrew --disable-analytics to opt out" and have that null the analytics identifier. Environment variables aren't that convenient.
You know what homebrew team : you guys are providing a great tool here and you should really charge for it. Take out the analytics stuff, cause no one cares if it helps you or makes it easier for you to improve software that you write for free on your own time. No one cares that it'll take you more time to improve this great tool without the analytics. No one cares that it'll cost you money to use another service besides Google Analytics. We don't want you to spend time or money that you don't have either, just don't bother doing updates or improving it, it's pretty good the way that it is. But honestly, the fact that I can do a clean install of OSX and install my entire dev environment + favorite apps in about 3 minutes VS going to each individual site, having each of them (most likely) collect data about me, have to download them individually, and then install them individually -- is DEFINITELY worth some extra money in your pocket! Charge me a couple bucks, I'll gladly pay you for it. Heck, I'm going to go donate now + wait to get charged. ALSO: Don't let me know TOO much, all the details make me think I can't trust you! And you made the opt-out directions too hard.. you mean I have to do extra work that will take 15 SECONDS OR LESS out of my day to opt-out?.. NO! You do more work, don't make things easy on yourself OR me, that's not cool, you can just start charging me for it. =P. Keep up the good work!
Totally fine with it.
I use MacPorts[1] which is a good alternative to homebrew. It's an older project.
Lately though, I've came across many packages that are available for Homebrew but not for macports.
[1] http://macports.org/
Lately though, I've came across many packages that are available for Homebrew but not for macports.
[1] http://macports.org/
Here's a quick and dirty way to opt out for BASH and ZSH users for easy copy/pasting.
BASH:
BASH:
cat <<EOF >> .bashrc
# Opt out of Homebrew analytics
export HOMEBREW_NO_ANALYTICS=1
if [[ -e "$HOME/.homebrew_analytics_user_uuid" ]]; then
rm -f "$HOME/.homebrew_analytics_user_uuid"
fi
EOF
cat <<EOF >> .zshrc
# Opt out of Homebrew analytics
export HOMEBREW_NO_ANALYTICS=1
if [[ -e "$HOME/.homebrew_analytics_user_uuid" ]]; then
rm -f "$HOME/.homebrew_analytics_user_uuid"
fi
EOF
You don’t need to remove that file; the whole point of this env variable is that it stops Homebrew from sending any data. It won’t even be created if that variable is set.
That's only true if the variable is set before the first instance when data would have been sent, otherwise the file will exist (as it did on my system).
Kudos for at least announcing this. (And I've totally opted out.)
So essentially US government is now one data request from Google away from having a full list of software (and vulnerabilities) for any given developer Mac?
Many large corporations have internal homebrew packages. You can learn company secrets by getting a list of packages that are being installed.
As I see more applications try and hit remote ad servers, I feel even better that I'm blocking all of these ad servers with my /etc/hosts file using https://github.com/StevenBlack/hosts. The update will be a no-op from my machine.
+1 for pkgsrc
AFAIK, Max Howell was rejected from a position at Google, and now his trademark making use of Google? Let him take a look at GNU.ORG; if he can see any GA code.
People have all of their traffic tracked by their ISPs, they use chrome, they have full activated accounts on their phones, they add tag themselves everywhere around facebook and they are mad because someone wants statistics over google analytics... you IT people need to relax... I'm sure someone will find a way to bring up inequality, sexism, racism and being vegan at some point on the thread.
one more what used to be decent software selling out to marketing....
guess its back to the linux vm when working on a mac...
guess its back to the linux vm when working on a mac...
opt-in by default is fine with me. Thanks for the great tool!
The tinfoil hats are strong in this thread.
set HOMEBREW_NO_ANALYTICS=1
I love the knee-jerk hostile reactions to any sort of phoning home by an application. They've provided extensive explanations on what is collected, why they're collecting it, who has access, what it's for, and even the code that does the actual collecting and it still isn't enough for people.
While I'm against this type of thing typically, this information is exactly what someone who is concerned about it needs to see, and if they don't want to be involved they include the opt-out on the very same page. I don't see how this could get any better, this could be held up as a gold standard for Microsoft and Google moving forward.
This type of data is invaluable to developers, I can't tell you how frustrating it is that so many people now refuse to share it because of overblown privacy concerns. The data is anonymized and no one cares enough about what you're doing to de-anonymize it.
There are real threats to your privacy out there and spending time on stuff like this just adds to the noise.
While I'm against this type of thing typically, this information is exactly what someone who is concerned about it needs to see, and if they don't want to be involved they include the opt-out on the very same page. I don't see how this could get any better, this could be held up as a gold standard for Microsoft and Google moving forward.
This type of data is invaluable to developers, I can't tell you how frustrating it is that so many people now refuse to share it because of overblown privacy concerns. The data is anonymized and no one cares enough about what you're doing to de-anonymize it.
There are real threats to your privacy out there and spending time on stuff like this just adds to the noise.
Your arguments are ridiculous. Humans judge; we're good at it. Burn us enough times with false promises of privacy or outright lies and yes, we will learn to become very skeptical and untrusting. You're asking people to continue trusting a system that has proven to be working against users' best interests for a long time.
The data is not sufficiently anonymized. Your public IP address is sent to Google and--the burden of proof is on Google to prove this doesn't happen--there is nothing stopping Google from comparing that data to other requests they get from the same IP address (say, from your browser). Maybe Google can't personally identify me from this data, but they can sure target me with ads, which--shock--make them money.
The data is not sufficiently anonymized. Your public IP address is sent to Google and--the burden of proof is on Google to prove this doesn't happen--there is nothing stopping Google from comparing that data to other requests they get from the same IP address (say, from your browser). Maybe Google can't personally identify me from this data, but they can sure target me with ads, which--shock--make them money.
Yeah. So every site and every product on the internet has this dark pattern. Do you use google? Youtube? StackOverflow? Are you outraged by them too?
We detached this subthread from https://news.ycombinator.com/item?id=11567580 and marked it off-topic.
> So every site and every product on the internet has this dark pattern.
Not every site/product on the internet uses an abusive analytics platform, hell not all of them use analytics at all.
With sites visited in a browser, an extension can be used to block access to abusive services such as GA. There is no Ghostery for the terminal.
I have no issue with them wanting to collect usage information. I opt-in to Debian's package usage tracking.
If I still used Homebrew, I would have a huge issue with them sending information about what packages I install to Google.
Not every site/product on the internet uses an abusive analytics platform, hell not all of them use analytics at all.
With sites visited in a browser, an extension can be used to block access to abusive services such as GA. There is no Ghostery for the terminal.
I have no issue with them wanting to collect usage information. I opt-in to Debian's package usage tracking.
If I still used Homebrew, I would have a huge issue with them sending information about what packages I install to Google.
How is GA abusive? The webmaster has to explicitly permit data sharing with google. That is, the webmaster is asked if s/he wants to share data with google and the options are unchecked by default.
GA prohibits the use of personally identifiable information.
Additionally the webmaster can tell google to not store IP info, which the webmaster has chosen to this in this case.
GA prohibits the use of personally identifiable information.
Additionally the webmaster can tell google to not store IP info, which the webmaster has chosen to this in this case.
> The webmaster has to explicitly permit data sharing with google.
Abusive to users. Google's whole reason for offering free analytics is to build better advertising profiles.
> Additionally the webmaster can chose to not send IP info to google,
I must have missed the memo where Google invented a way to make HTTP connections with no client IP.
Abusive to users. Google's whole reason for offering free analytics is to build better advertising profiles.
> Additionally the webmaster can chose to not send IP info to google,
I must have missed the memo where Google invented a way to make HTTP connections with no client IP.
This has gone full circle and honestly is quite irritating at this point.
People say that Google uses GA data for advertising, I say that this is not the case and then you just chose to ignore that. So I'm just gonna ask directly - can you show some evidence suggesting Google uses GA data for building advertising profiles or did you pull this opinion out of your ass?
Because as someone who analyses marketing and advertising data, I can tell you that I strongly believe they do not use GA data in this way. 1) They have no need to, they have better data; 2) This data is unreliable; 3) GA prohibits the use of personally identifiable information; and most important of all:
THE WEBMASTER CAN CHOSE TO NOT SHARE IT WITH THEM. If this webmaster went out of his way to tell google not to store IP information, I think it is pretty safe to assume that they did not opt-in to share the data with google AT ALL.
Apart from these technical reasons, using GA data in the way you think they do opens a regulatory risk of EPIC proportions.
But if you have some evidence to suggest that they do use it for "advertising profiles", please do share it. But if you can't and you formed this opinion because you are prejudiced, I would like to see you admitting it.
People say that Google uses GA data for advertising, I say that this is not the case and then you just chose to ignore that. So I'm just gonna ask directly - can you show some evidence suggesting Google uses GA data for building advertising profiles or did you pull this opinion out of your ass?
Because as someone who analyses marketing and advertising data, I can tell you that I strongly believe they do not use GA data in this way. 1) They have no need to, they have better data; 2) This data is unreliable; 3) GA prohibits the use of personally identifiable information; and most important of all:
THE WEBMASTER CAN CHOSE TO NOT SHARE IT WITH THEM. If this webmaster went out of his way to tell google not to store IP information, I think it is pretty safe to assume that they did not opt-in to share the data with google AT ALL.
Apart from these technical reasons, using GA data in the way you think they do opens a regulatory risk of EPIC proportions.
But if you have some evidence to suggest that they do use it for "advertising profiles", please do share it. But if you can't and you formed this opinion because you are prejudiced, I would like to see you admitting it.
THE WEBMASTER CAN CHOSE TO NOT SHARE IT WITH THEM
No they can't, unless that choice means that the data never arrives at Google's servers.
No they can't, unless that choice means that the data never arrives at Google's servers.
Of course they can. When you sign up for GA, you get asked
Do you want to share data with google to improve our products?
Do you want to pool aggregated data for benchmarking?
Both are unchecked by default.
Or do you think that google will access the data without permission? In which case, what do you base your opinion on?
Do you want to share data with google to improve our products?
Do you want to pool aggregated data for benchmarking?
Both are unchecked by default.
Or do you think that google will access the data without permission? In which case, what do you base your opinion on?
stephenr(2)
I have come to expect some tracking of stuff that happens in my browser. I try to block as much of it as I can with noscript, ublock, etc.
But I do not expect applications outside of my browser to behave like web sites do.
But I do not expect applications outside of my browser to behave like web sites do.
Wish there was a way of opt'ing-out without having to set an env var for every session .. is there some brew place to put ENV vars?
That's what ~/.bashrc or ~/.bash_profile or (whatever it is for your shell) is for.
Yeah, I don't want to do that every single time I put home-brew on a machine somewhere, for every single user.
Doesn't it have its own global config? I confess that I'm too miffed by this intrusion in my privacy to be bothered to find out ..
Doesn't it have its own global config? I confess that I'm too miffed by this intrusion in my privacy to be bothered to find out ..
Seeing as it's just an environment variable for your shell, look for a way to set global environment variables.
Are you perhaps looking for /etc/profile.
Put it in ~/.profile ?
add this to shell profile file:
export HOMEBREW_NO_ANALYTICS=1
pls go ahead and read the first response:
http://unix.stackexchange.com/questions/117467/how-to-perman...
http://unix.stackexchange.com/questions/117467/how-to-perman...
This is a very single-user-centric view. Some of us have Macs with many hundreds of users.
And so .. It is too invasive of my .bashrc/.profile that I have to use it to disable spy activity. I'd rather brew just have its own flag somewhere that says "Don't ever send analytics, ever, for any user on this system.."
And so .. It is too invasive of my .bashrc/.profile that I have to use it to disable spy activity. I'd rather brew just have its own flag somewhere that says "Don't ever send analytics, ever, for any user on this system.."
Shove it in your .bashrc, or equivalent for your shell of choice.
Couldn't you just put it in your .bashrc?
For every user on this machine? On every Mac in the house? Meh.
What I want:
What I want:
"brew disable analytics"
You would still need to do it for every user, anytime you create a new one. I fail to see how that's any different from, say `echo "export HOMEBREW_NO_ANALYTICS=1" >> .bashrc`
Of course, the better alternative IS for it to be opt-in, which it should be.
Of course, the better alternative IS for it to be opt-in, which it should be.
This:
>>>`echo "export HOMEBREW_NO_ANALYTICS=1" >> .bashrc`
.. makes me responsible for it. This:
>>> brew analytics no-never
.. makes brew responsible for it. There is a big difference. Some of us don't want to have to maintain yet another .bashrc file tweak just to have a safe and sane environment.
I hope the homebrew guys will pay attention to this issue.
>>>`echo "export HOMEBREW_NO_ANALYTICS=1" >> .bashrc`
.. makes me responsible for it. This:
>>> brew analytics no-never
.. makes brew responsible for it. There is a big difference. Some of us don't want to have to maintain yet another .bashrc file tweak just to have a safe and sane environment.
I hope the homebrew guys will pay attention to this issue.
Google must have eventually hired him.
https://news.ycombinator.com/item?id=9695102
https://news.ycombinator.com/item?id=9695102