> Want to know what data of yours, if any, is being collected? Look at the code.
I find this to be an extremely un-compelling position. A relatively small proportion of the general population has the skills to meaningfully look at the code, never mind the time. Moreover, even for someone who is capable, such an exercise quickly becomes non-trivial on an unfamiliar codebase for an app of any complexity.
In many cases there's also no guarantee that the code you're reading is the code that's running.
> I find this to be an extremely un-compelling position
It's more damaging than that. The bundling of privacy and FOSS advocacy weakens the former. Few without deep technical knowledge is sympathetic to FOSS. The potential audience for a privacy pitch is broader. By bundling the two, however, the technical advocacy community limits the appeal of the former to those supporting the latter. This is an issue because the opponents of privacy rights are not similarly limited. Hence, we find ourselves reliant on Google, Apple, Facebook and Amazon being benevolent dictators, in their services and Washington.
Yes, all they know is “this is impossible to install” and “what is a GitHub” and “where do I log in to the cloud?” and “this is the ugliest software I have ever seen in my life”.
Unless we’re talking about hosted FOSS, in which case you get the worst of both worlds.
I run my own mail server so this comes from a place of love: FOSS for server side products for consumers is a joke.
While I generally agree with you about the soundness of the FOSS==privacy argument, I think you're misstating it subtly. The claim isn't necessarily that the privacy sensitive user specifically will be able to audit the source but rather that someone somewhere will have done, and will have written about problems they uncovered. See also many eyes making all bugs shallow.
Not always. Heartbleed was present in OpenSSL for two years before anyone noticed.
Many eyes make all bugs shallow, but if there aren’t enough eyes with the skills or the time then problems will remain deep, even for important software like this.
Perhaps everyone thought everyone else had done the work?
Heartbleed was a very subtle security bug, the discussion here is about privacy violations. You think that detecting if, I dunno, mutt is secretly uploading your contact list is going to escape detection for years?
It will. IIRC HomeBrew’s integration of Goigle Analytics went unnoticed for almost a year, and only then they included an opt-out option (it’s still opt-in by default)
Thinking out loud here, what's the best counterfactual on HB?
I can imagine a ClosedSSL that gets hammered in a blackhat presentation. I can imagine ClosedSSL getting fixed, eventually.
It's just hard for me to imagine that happening faster because people like Neel couldn't read the code.
Maybe the counterfactual is that ClosedSSL is also well funded and cares deeply about security, so it finds HB internally.
But openness doesn't preclude funding. And closed source doesn't grant you an automatic security focus.
So rich ClosedSSL vs poor OpenSSL isn't an apples to apples comparison.
All things held equal, openness provides one extra possible avenue to find and catch bugs, and so such projects will tend to have more caught on average.
What does HB teach us then? Just that some bugs are hard.
Now, to be fair, if "openness" is just used as a substitute for internal security audits, a way to shrug and farm out that work and blame to passers-by, then that would be obviously terrible.
That probably happens more than we'd like to admit, but I still don't think it's the typical reason people open their code.
OpenSSL can just as easily act as a point towards FOSS for privacy given that it was a vuln that was discovered externally (multiple times by distinct parties).
Even then, it might work well for you, and if I had the patience or the time it could work well for me, but it'll never be of any use to my mum or my brother, neither of whom are technical.
I suppose it depends on how it ends up being implemented. I was envisioning something fairly automated, which could presumably spit out PACKAGE VERIFIED information that could be used in systems not requiring users to be technical.
I find this to be an extremely un-compelling position. A relatively small proportion of the general population has the skills to meaningfully look at the code, never mind the time. Moreover, even for someone who is capable, such an exercise quickly becomes non-trivial on an unfamiliar codebase for an app of any complexity.
In many cases there's also no guarantee that the code you're reading is the code that's running.