[candiodari]

Facebook is pretty bad, but this is a general thing.

https://www.icloud.com/#contacts

http://contacts.google.com

Even many games collect this information. Even really, really popular ones.

https://techcrunch.com/2016/07/11/pokemon-go-wants-to-catch-...

And with graph theory this means that if they got, say 10% (more likely 1% or so) of people to do this, they can reconstruct 99% or more of the total graph easily.

Hence the constant astonishment by privacy advocates that actually watch their own usage. "I don't use a smartphone and yet they figure out the email addresses of people I only ever call" type of comments.

Meanwhile government organizations have become famous in recent years for subpoenaing this information at the drop of a hat ... especially for divorces, but even for commercial conflicts (e.g. non-payment).

Everybody's in on it and this fight has been fought ... and comprehensively lost. The justice system is not going to let this source of information go, and that means companies aren't going to let it go.

You just can't have applications in the cloud and privacy, because the cloud means that aggregating the information from many sources is easy. Not that it isn't theoretically possible, but it just doesn't work in practice.

[grzm]

iCloud and Google contacts are explicitly for syncing contact information. This is what one expects when using these services. Syncing with iCloud is optional. I not familiar with Google Contacts to know the details.

TOS for games and social networks like Facebook may mention they access this information but it's not their sole purpose and users are may be surprised this is happening.

Also, at least in the case of iCloud, contacts data is encrypted in flight and at rest. Apple doesn't have access to the data, and can't be shared with authorities even under subpoena.[0] Again, I don't know the situation with Google Contacts. I agree that the situation with games and social networks is much more problematic and something to be concerned about.

Yeah, there are definitely concerns when storing information on others' servers, but it's also important to weigh them appropriately. That said, depending on your level of paranoia, you might not accept anything anyone says, and that's your choice.

[0]: https://support.apple.com/en-us/HT202303

[candiodari]

The problem with the argument from Apple is that they control code that can decrypt the information. That code can do whatever it wants, with or without your approval (they can change the code on the frontend without your approval). This "end-to-end encryption" are a commitment, a promise on their part, nothing more (and I might add, this is a bit of text on a PR page, it is not even a contractual obligation to you, a very important difference that I assure you is not an accidental oversight on the part of Apple's management. Not that a contractual obligation would protect your data from subpoenas).

So this still requires you trust Apple, and any organization that can compel Apple to take action, to not break your security. This, of course, includes any organization that can subpoena Apple, which due to international cooperation includes quite a few organizations.

The ONLY person that can be entrusted with information and be legally protected from subpoenas is you yourself, and your lawyer (and even then technically only when actually representing you, although I don't think that line has ever been crossed), and even that only applies within the US. I agree that Apple does seem to have had some success with this information, has not released such info -so far- in a public request (there are, however, a number of non-public channels for subpoenas).

If I were to ask you to enter your bank information on a website with javascript that encrypts the information, then sends it to the server under my control, end-to-end encrypted (the server does not know - independently of the frontend - the encryption keys. Of course the whole system still does know the information), would you trust that ? Of course not, as I control the frontend and the backend, and therefore I can still decrypt it. I can change the frontend code to send me the unencrypted information (or worse - the encryption key the backend does not know - as that would give me access now and access to any future updates), same trick as with LVM encryption.

Maybe I even need you to visit the site before I'd be able to decrypt it, but I hope you can see that I can still access the information if I control both, and when you decide to entrust information to that you should still decide if you trust me, and anyone who can subpoena information from me. The only difference is a few extra steps for me when I want to access the information.

So far Apple's argument is that it would be unreasonable ("onerous" I believe is the legal term) to demand they actually execute those steps. We don't know if that argument held up in the non-public channels (there does seem to be a compromise made [1])

People think that if you have LVM encryption on a disk it can't be copied without having access to the encryption key. That's wrong, of course I can copy it, I just can't read it unencrypted at that point. If I then install a boatloader that uses a side channel to send the encryption key to me (the 128 bytes of the key, not the actual data on the drive) and from that point on I have access to the information I copied earlier. Note that "protected boot" doesn't actually protect you either. I simply install a bootloader that looks exactly like the official bootloader on screen, you enter your password, it simulates an update or whatever, replaces itself with the official bootloader again, and reboots. Presto, I now have access to all your drives and you're none the wiser, and the only thing I needed was physical access to the information (in other words, only the exact same thing I would need if it wasn't encrypted at all).

[1] https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...

[grzm]

There's a number of straw men here: I understand the difference between being able to copy and decrypt data. You're the one who brought that up. The FBI case is about unlocking a device (which make the keys available), not decrypting data at rest when you don't have access to the keys. You brought up specifically accessing contact data available to specific apps, and those were the points I addressed.

So, only software you compile yourself, and never storing data on servers you don't own? How about hardware, including chips, from third-parties? Trusting encryption algorithms others have certified? How far does your trust extend? Is it reasonable for others to have different levels of trust than you?

[candiodari]

Nope. You do not require that you only use software you compile yourself. Software that only uses local storage, for obvious reasons, does not need that.

That's why I'm saying that you only need to be watch out for cloud software. Local contact storage is of course fine.

It's just that neither android nor Apple/ios has that.

[grzm]

I don't know what the options are on Android, but you aren't required to use iCloud on iOS for Contacts (or at all, for that matter, though there are likely feature limitations such as some syncing between devices if you don't have it enabled).

[candiodari]

I'm not sure why it is so terribly important for you to defend Apple here, but let's just say that I'm pretty sure I would just avoid using a smartphone all together for anything important.

Contacts has code in it that is explicitly designed to expose this info (to provide features found useful by many Apple customers of course). And we know that the safety guarantees are somewhat noncommittal (and I would argue at least a bit misleading).

And that's enough, if you want to avoid giving out this info, I'd use other tools to communicate.