Reasons (not) to trust Apple's privacy promises

[anon36005609]

Well, oops.

[VenTatsu]

By #3 you mean BlackBerry right? Because Apple tracks your location, browsing history, and app usage to deliver iAds. Admittedly the tracking only applies when an iAd is being displayed, but to engage in the behavior your are critical of others for, then claim purity because you do it less is a bit dishonest.

I say this as a happy iPhone user. I love their devices and software, but I could do without the spin and outright BS that pervades the entire industry.

[howaboutthis]

@coherent_light

Code review is no doubt easier to review if it’s open source,but is that really knowably better than closed source code if that code gets reviewed as a matter of company procedure?

What is the company procedure regarding crypto? Not the official PR version, but the real version practiced by the programmers.

I’ll take Open Source over closed any day, even if I don’t necessarily understand the code. You may or may not trust any one person who contributes to the source code, but you’ve got (hopefully) many, many people, with diverse interests, allegiances, social and political leanings, etc, poring over that code, unlike closed source which is a few programmers developing according to company policy. Policy which itself be secret.

[telecinese]

@howaboutthis

(hopefully)

There’s the rub, no? To me the whole point of the OpenSSL flaw becoming important is the gap between theoretical security and efficiency because “anyone can audit and fix problems” and the reality of “not many actually do it”.

Edit: Related. All greek to me, but maybe you programmer types can get the joke.

[howaboutthis]

These days, you can’t even trust tin foil hats.

Tinfoil hats actually amplify mind-control beams

[VenTatsu]

There has been some good analyses of this whitepaper, Steve Gibson did a multi-part review on his podcast Security Now. (note: he’s a bit of a controversial figure in the security community, so take his analyses with a grain of salt.)

The take away is that the on-device security or the latest devices looks like it should be near bullet proof, but it has a fatal flaw, any data that passes thought Apple’s servers is available to Apple to decrypt. The proof of this is that when you restore a backup to a new phone (different hardware keys) you only need to provide your Apple ID password. There are some caveats, local (non-iCloud) backups can be encrypted separately, But iMessages are always transmitted (and restored) by Apple servers, without access to the old hardware keys.

Apple has the power to bypass their own SSL encrypting to grab the data needed to access any data that would have been secured by their at-rest encryption. This is the Lavabit security hole, NSA requires they turn over SSL keys and just snoops the password used to access and decrypt your could backups and they have full access.

[coherent_light]

@tropo

This can not be used as an argument that closed source is just as easy to review and test as open source. It’s a ‘back box’ problem with closed source and while there are numerous techniques for testing for bugs, they certainly can’t be considered lower effort than being able to read through the actual code.

The argument is that open code that is seldom reviewed by the right people is more problematic than code that is reviewed by experts—even if done as part of a closed process.

I’m not clear on how this could be fallacious, but understanding everything might not be feasible given my own limitations.

@howaboutthis

I’ll take Open Source over closed any day, even if I don’t necessarily understand the code. You may or may not trust any one person who contributes to the source code, but you’ve got (hopefully) many, many people, with diverse interests, allegiances, social and political leanings, etc, poring over that code, unlike closed source which is a few programmers developing according to company policy. Policy which itself be secret.

In such cases, perhaps we can fall back on examining the track record of the company itself. Has there really been a legitimate, genuine cause from Apple which indicates the tone taken by the author in the original link is justified? Maybe. I can see that many of the issues and concerns raised aren’t technical, but political in nature.

Saying so doesn’t diminish the value of open source, of course. But maybe hoping problems are found in someone else’s code is ultimately a lesser strategy to what it could be.

[VenTatsu]

@coherent_light

The argument is that open code that is seldom reviewed by the right people is more problematic than code that is reviewed by experts—even if done as part of a closed process.

It’s wrong to assume that closed code will get any more review than open code. It’s wrong to assume that critical code will get any review, let alone expert review, that goes for open as well as closed code.

I write code that is PCI-DSS compliant, I’ve taken part in our yearly PCI-DSS audit, done by accredited auditors. I have never seen a PCI-DSS auditor that knew how to write code. The experts are either doing forensic audits (after a breach) or independent security research. They are not typically doing annual audits of large closed source code bases.

The security assurances for most closed software comes from the development groups own internal non-expert (peer) review process. And in any group you have a diversity of skills, resulting in differing review quality. Which is pretty much what you also see in open code bases.