Homebrew now sends usage information to Google Analytics
github.com
github.com
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.
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 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.
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 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.
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.
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.
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'm thinking along the lines of popcon in Debian http://popcon.debian.org/
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.
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.
Speaking of which, become an organ donor if you live in an opt-in country.
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.
> 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...
[0]: http://www.businessinsider.com/apple-walked-away-from-iad-to...
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.
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-analyticsStill littlesnitch is really awesome for the privacy conscious users.
Also, Microsoft really needs to clean up their domain usage, because it takes 999 permission rules to run Office.
To achieve the best security, you should disable most bultin rules or customize them yourself.
Could you point to a source which would help me educate myself?
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).
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.
% brew update
==> Homebrew has enabled anonymous aggregate user behaviour analyticsThe 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.)
They could have a prompt with a countdown, you opt in it you don't say 'no' after a minute.
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.
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'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.
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?
This could have been handled much better with some sort of opt-in prompt like the debian installer does for its popcon usage tracker.
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.
Its, of course, always your choice if you're willing to trade it for something.
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.
So yes. Running their own server would be much preferable.
> The Google Analytics anonymous IP setting is enabled i.e. 1 (https://developers.google.com/analytics/devguides/collection...)
I'm not sure if they use it to improve their ad products, but I wouldn't be surprised if the answer is no.
Secondly, do you have a source for that? I find that a very dubious claim, from a business perspective.
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.
"""
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.
"""
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".
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.
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.
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!
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.
But nobody actually cares that much, only enough to complain. At length.
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.
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.
How does that sound?
"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.
Tracking people's online activity through a large percentage of the internet, without their consent or even knowledge qualifies as malicious to me.
If it's not malware, it's certainly really similar to it.
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 removalIf 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.
...anyway, complaining about getting downvoted is a surefire way to keep getting downvoted :P
Requiring the user to set an environment variable to opt out is smarmy.
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.
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.
Is there some way to see the caller of a process? htop displays no parent in the tree view.
Keep in mind that no personal info is ever sent. Just a random UUID.
> Just your universally unique id
...
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.
How is a Homebrew UUID personal info?
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.
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).
Any rubyists want to provide a patch to do this?
use their opt-out if you want
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.
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.
I'm reminded of when Adblock Plus went sour, and we got uBlock Origin. There are lots of examples of this.
It was nice back then. Packages didn't install themselves in /usr/local.
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.
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/
/nix/store? Really? You can't just make up new root level directories. That's so wrong.
- 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?
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
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
Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers).
And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like.
But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions.
In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).
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.
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.
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.
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.
Not ethically written, free software. You would never see this behavior from a GNU program.
- 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]
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?
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.
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.
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.
> 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.
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_64https://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/localBut 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!
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
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!
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).
Lately though, I've came across many packages that are available for Homebrew but not for macports.
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
guess its back to the linux vm when working on a mac...
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.
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.
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.
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.
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.
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.
No they can't, unless that choice means that the data never arrives at Google's servers.
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?
But I do not expect applications outside of my browser to behave like web sites do.
http://unix.stackexchange.com/questions/117467/how-to-perman...
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.."
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 ..
What I want:
"brew disable analytics"
Of course, the better alternative IS for it to be opt-in, which it should be.
>>>`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.
He works at Apple.