This is why, when it comes to privacy, Apple isn't worth consideration. All we have is their word, and that simply isn't enough.
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.
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.
Few without deep technical knowledge do even know what FOSS is.
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.
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?
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.
By comparaison, while there have been a few issues with Google, for a company that processes so much personal data, their track record is excellent. I can't think of any major personal data leak that could be attributed to Google.
Maybe Apple got better within these 4 years, TBH, they most likely did. However, I don't consider 4 years to be a "long time" for a tech giant. Their privacy focus is relatively recent.
The thing is: we often associate ad tracking and (lack of) privacy. It is certainly one aspect, but it is far from the whole picture. The most damaging form of privacy violations are usually not caused by advertisers but first by people who are close to you (ex: revenge porn), and second by hackers (ex: blackmail). I used the fappening as an example because nude pictures are the archetype of private data.
As for targeting phishing, I think companies who take privacy seriously have to do something about it. Phishing is the number one threat users face when it comes to cybersecurity and therefore privacy.
Now comes the debatable part: hackers targeted the iCloud platform, why? Why not Picasa, or Facebook, or whatever place images are stored? My hypothesis is that iCloud was the best target for such an attack, partly because compared to the others, it didn't offer as much anti-phishing security.
EDIT: I just noticed I didn't mention governments. First, for most people in western countries, government is unlikely to be their biggest problem. So I would rather focus on the immediate surroundings (ex: boss, partner, neighbors, etc...). And if the government really is after you, then an Apple solution might be good, but I don't think they are completely turstworthy. They are still bound by the US law after all, and they are not completely zero-knowledge. To make things clear, Google and Facebook are also out in that case.
Possibly because the celebrities targeted used iPhones, and didn’t publish their private pictures to Facebook or a Google service.
The only exception is iCloud keychain, but I believe only if you decline the default setting to create an iCloud security code (I'm not entirely sure about that)
This is more than a little hyperbolic. In the US you need a warrant.
I don't trust it, though, if we're talking domestic surveillance. The ECI-level leaks said FBI "compels" domestic companies to enable their stuff for eavesdropping. Whatever that means is secret. In the Lavabit case, the FBI argued to the judge Lavabit wouldn't be harmed if they lied to their customers about the compromised. The judge agreed. So, court orders, fines, retaliation, forced lies, and secrecy orders of all that are a possibility in the United States. Just don't put secrets on anything made in America or by Americans. You can use American tech for obfuscation or untrusted functions, though.
Apple isn't worth consideration if you are willing to put in the effort, or delegate trust, to other systems. If you'd prefer to delegate trust to them, how is that effectively different that FOSS that you haven't examined?
When devs announce how their software handles privacy concerns, they have an incentive to be honest because all it takes is one discovery of conflicting code and their trust is lost. But if the code is closed source, that incentive for honesty is removed. Of course the media can still seek circumstantial evidence and make accusations, but that’s a far cry from version control.
Separately, closed source code invites new incentives to disrespect user privacy for profit.
So, there are these two major categories involved, both of which are mitigated by opening the source code.
Apple remains liable for both of them.
All that Apple has is an observation that they sell hardware too. I guess we are just assuming they already make enough money from advertising as it is and don’t really want more.
I think there is a significant difference.
I just don't see open source as better protecting privacy. See for example the telemetry in .NET Core or VS Code [1]. Users discover this stuff by watching network traffic, not through code audits.
Let’s assume Apple violated their privacy policy and was fined $999 million, the highest “multi-million dollar” fine they could be assessed. That’s just barely more than 1% of their market cap.
Fines are definitely incentive to do right but the fine must be felt. I’m not aware of any cases where the tech giants have been levied a fine that really hits them hard.
Watching network traffic is limited to circumstantial evidence, and not even that without a circumstantially isolated environment. Those are a couple of scenarios where these accusations can be made.
On the other hand, open source projects come in all shapes and sizes. Generally, they have a strong community of both developers and users around them. If you don't feel like looking at the code, you don't even have to trust the project itself. You can look to the community and its abundance of users, at least a few of which have audited the code and share your use case. And these users aren't just neutral third parties. Nay, they're better than that. They, too, value their own privacy, and are therefore motivated to protect it.
As for the theory of "open source community," see the MyBTGWallet scam. This open source project, recommended by the Bitcoin Gold team, stole $5 million via a single line of code. Being open source isn't much protection really.
Just because something is closed source doesn’t make it bad. And just because something is open doesn’t automatically make it good.
But seeing sibling explanation being downvoted into oblivion makes me think no one is interested in discussing this anyway so why waste breath.
The future looks good if we just continue to implement it the way it should be.
>This is why, when it comes to privacy, Apple isn't worth consideration. All we have is their word, and that simply isn't enough.
Quite a few of the things listed in the article are not open source (some of the map stuff, as an example). Last I checked (several years ago), we only have DuckDuckGo's word for it.
I think the idea is not that these are all trustworthy services, but that no single company has all the data on you.
In fact, the first systems that resisted strong pentesting by NSA were proprietary, shared- or closed-source systems. They shredded everything else. Two are below with another designed like that. The first, safe, kind-of-secure machine that I know of was Burroughs B5000 whose CPU did things like stop overflows, protect pointers, and check function arguments. It was immune to common, root causes of many failures or attacks. OS in a type-safe, high-level language (ALGOL variant). It was a proprietary system whose source was shared with customers. Linux systems still don't have as much code-level security in average case as that proprietary software from 1961. The virtualization solutions in FLOSS still aren't produced as securely as VAX VMM or the separation kernels that followed in 2000's with VMM's layered on top.
http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... (See Layering and Assurance sections especially. Compare to QA practices of favorite FLOSS VM.)
http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04... (Nizza uses FLOSS components. This document is just great at describing the architecture they and the proprietary vendors were using with separation kernels. The proprietary offerings contained a lot of problems FLOSS didn't with their 4-12kloc kernels having less code to screw up. User-mode drivers can boost reliability a bit, too.)
You can also use all sorts of runtime tools to see what a binary is doing at runtime, so I imagine it would be pretty easy to see if an application is phoning home, and where home is located, although the data is probably encrypted.
In fact, it might actually be easier for an end user to audit a binary using such automated tools instead of looking at the source code itself. At least with the automated tools, the tools can flag suspicious constructs in the binary that may indicate that it's up to no good, and do so in a way that is more understandable to the end user.
Nowadays, very little of our data solely relies on our own devices, and most of the value of consumer software occurs when data is being transmitted between systems. When your data lives in the cloud, there is almost always a side-channel way to get at your private data that won't be visible in any Git repository: Just go look at it directly.
Meaning that, nowadays, if we're to live any sort of non-Luddite, Internet connected lifestyle, all we have to go on with anybody is their word. If I limited myself to services where inspecting the source code would give me what I need to know about how well my privacy will be protected, without trusting the word of any third parties, then I'd have to let go of email, telephone, and credit and debit cards (and banking in general). Plenty of other things, too, but I think those three paint the picture well enough.