Hacker News new | past | comments | ask | show | jobs | submit login

I've read a couple articles and haven't seen any details about how they're going to apply DP (differential privacy).

It's important to clearly distinguish what DP can and cannot do. DP is just a technique for taking a database and outputting some statistic or fact about it. The output has some noise added to it.

The guarantee of DP is (roughly) that anyone looking at the output alone won't learn much about anyone in the database. This also holds for anything you do with that statistic.

Think about this carefully when thinking about what DP does and doesn't promise. Also think about the difference between "privacy" and "security".

Example of what DP does protect against: If Apple is recommending products to people based on others' download habits, and this recommendation is based on differentially private statistics, then no other user or group of users can infer anything about my downloads. In fact, even engineers at Apple, if they can only see the statistics and not the original database, cannot infer anything about my downloads.

Example of what DP does not protect against: government accessing the data. The database still has to exist on Apple's servers. The government can get to it just as easily as before via warrants or so on. DP is not cryptography.

My assessment: On one hand it is awesome that Apple is taking a lead in using differential privacy and thinking about mathematical approaches to privacy. On the other, there are many facets of privacy and right now I think people are more concerned about security of their data and privacy from the government, or else privacy from companies like Apple itself. DP doesn't address these; it only addresses the case where Apple has a bunch of data and wants the algorithms it runs not to leak much info about that data to the world at large.

> The database still has to exist on Apple's servers.

It doesn't, which is part of the reason Apple wants to do this. You can still do differential privacy without collecting all the data, you just get less accurate results. See page 232 in [1], re "The Local Model".

[1]: http://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf

Edit: the article even says this down when it talks about RAPPOR.

Hi Frank and thanks for responding; you're right of course.

If Apple really did implement some sort of randomized response (or more sophisticated variant), I think that would a real breakthrough for user privacy since they'd be giving up control of the data.

According to the State of the Union (where they explain how they're doing differential privacy) there is an overall database, but only in aggregate. It's specifically designed so you don't know the individual answer from each person.

Even though the technique doesn't require collecting all of the data, Apple still does collect a huge well of data.

They store all iCloud sync material (backups, photos, contacts, calendars, mail, documents, etc.) without end to end encryption, and have all of the iMessage metadata.

This is so wrong. The only thing that isn't user-encrypted so far is the iPhone backup on their server (Of course it is encrypted but Apple have the key to decrypt it as needed).

The official explanation so far is that if the user forgot the password a user-encrypted backup would just become some useless junk.

This is (officially) the sole remaining non user-encrypted personal data on apple server that authority can reclaim using a warrant.

However after San Bernardino FBI mess, Apple start considering to also encrypt iCloud backup.

So if you think you are right, proofs please...

What's wrong? AFAIK the only thing fully end-to-end encrypted is the keychain.


Take note of what the wording leaves out. Apple holds the decryption keys for just about everything.

> iCloud Keychain encryption keys are created on your devices, and Apple can't access those keys. Only encrypted keychain data passes through Apple's servers, and Apple can't access any of the key material that could be used to decrypt that data

This wording is used for nothing else than the keychain.

Fully consistent with the behavior where disconnecting all your devices from your account, to then do a password reset and logging in on a new one device will make all your data available to you again in plaintext format. Including iCloud backups of iMessage chats.

Are you saying Notes, Safari Bookmarks, Photos, etc are encrypted on iCloud?

How come they are accessible from iCloud.com? Decrypted by the browser on the fly?

It seems so: https://support.apple.com/en-us/HT202303

However I reckon that technically Apple could access data or give data stored on iCloud to NSA/FBI because they actually still hold the keys for that part too (not only backup as I thought). Only the password/creditcard Keychain is now claimed to be fully user-encrypted and can't be recovered by any mean by apple.

For anything else than a warrant, they'll "just" have to breach every engagement they made in their contract which would, as far as I know constitute a pretty solid legal case that could only lead a public walk of shame that could compromise the whole company's future.

If you don't trust them, don't use their cloud, I totally respect that. In the end it always appeal to some degree of trust, even GitHub could be spying on paid private repositories under the hood if they really wanted to. But for what gain?

> For anything else than a warrant, they'll "just" have to breach every engagement they made in their contract which would, as far as I know constitute a pretty solid legal case that could only lead a public walk of shame that could compromise the whole company's future.

This is something I doubt. It would be rather easy to change the software and make it sync passwords, even on an individual basis. If this would come out, it would mean a big marketing problem, and could result in sales losses like 10-20%.

I said "could", but to be honest I think 2-3% is more realistic. Most people don't care. They want their data to be safe in case of theft, and have a backup in case of loss. Here on HN it's a big thing, but most users don't know, don't care.

CISPA grants civil immunity for sharing information with the government.

AFAICT only storage is encrypted. They decrypt server side.

Do you suggest that Apple is blatantly lying in the article I just cited?


> All your iCloud content like your photos, contacts, and reminders is encrypted when sent and, in most cases, when stored on our servers. All traffic between any email app you use and our iCloud mail servers is encrypted. And our iCloud servers support encryption in transit with other email providers that support it.

> If we use third-party vendors to store your information, we encrypt it and never give them the keys. Apple retains the encryption keys in our own data centers, so you can back up, sync, and share your iCloud data. iCloud Keychain stores your passwords and credit card information in such a way that Apple cannot read or access them.

The End.

I always find it amusing when people downvote me for telling them Apple is doing what they admit to be doing.


The burden of proof should be on Apple's site. Given their secrecy all you can do is pray or switch to open source.

Alternatively you can also RTFM before complaining about secrecy... https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Of course that will never be as audit friendly as an Open-Source code. But don't call it a secret, while you actually just didn't search for the information...

It's not only encryption, what's important, but proper key management. Just saying.

> Apple still does collect a huge well of data.

I don't think Apple has ever claimed it does not collect data.

> The output has some noise added to it.

You can also add noise to the input samples, so your database doesn't contain statistically significant information about any single individual. But aggregate queries will work as the noise evens out. See http://research.google.com/pubs/pub42852.html

Edit: Just saw that the linked article actually explains this in the last section as well.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact