Apple has done a fantastic PR job regarding privacy. I am more skeptical about the status of actual privacy given their iMessage situation and now this.

And their participation in PRISM https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...

What does "participation" in PRISM mean?

> Apple: "We have never heard of PRISM"[115] "We do not provide any government agency with direct access to our servers, and any government agency requesting customer data must get a court order."[115]

* https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...

Certainly American companies are subjects to warrants and NSLs, but Google (to give one example) had its dark fibre connections between data centres tapped by the NSA. Is that the "participation" that was referred to by the Snowden documents?

* https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns...

* https://www.theguardian.com/technology/2013/oct/30/google-re...

* https://venturebeat.com/2013/11/25/level-3-google-yahoo/

* https://www.washingtonpost.com/world/national-security/nsa-i...

> had its dark fibre connections between data centres tapped by the NSA. Is that the "participation" that was referred to by the Snowden documents?

No, that's a separate thing. They do both. See the "you should use both" slide.

https://github.com/iamcryptoki/snowden-archive/blob/master/d...

As to the apple claims that they didn't participate in PRISM, I think they were just lying. Clapper lied to congress as well, so this isn't unheard of. They would likely have breached their government contract by telling the truth. That being said, them having never heard about the program name might be true because it might not have been known to them under that name, but that's just a detail.

Apple was not lying because “PRISM” was an internal source identifier at the NSA for the process of acquiring data through the FISA warrant process. Apple never heard the word PRISM; they got FISA warrants and replied to them as required by law.

This is clearly indicated on the PRISM Wikipedia page that was linked above.

> PRISM is a code name for a program under which the United States National Security Agency (NSA) collects internet communications from various U.S. internet companies.[1][2][3] The program is also known by the SIGAD US-984XN.[4][5] PRISM collects stored internet communications based on demands made to internet companies such as Google LLC under Section 702 of the FISA Amendments Act of 2008 to turn over any data that match court-approved search terms.

> Apple was not lying because “PRISM” was an internal source identifier at the NSA for the process of acquiring data through the FISA warrant process. Apple never heard the word PRISM

As I've said, that's a detail and splitting hairs. If a sentence has multiple interpretations and one of them is true, but you phrase it in a way that most people interpret the sentence in the wrong way, you are intentionally deceiving people. They should have said "we have never heard the name PRISM" or something like this.

I thought you just ended up in PRISM you don't "join" it? Just like Google found out from the Snowden leaks and then encrypted all their DC to DC fiber.

I think there were aspects of PRISM that required cooperation from providers like Google. Like the NSA would send queries to them and they would return emails or what have you that match those queries. Though of course this “cooperation” is required by law.

If there's a court order, (FISA: https://en.wikipedia.org/wiki/Foreign_Intelligence_Surveilla..., or otherwise) companies have to comply. So I don't really see how one can blame a any company for that.

You can absolutely blame companies, specifically Apple, because many things are not E2EE when they could be.

See: the last sentence of my post

Their iMessage situation?

They backup the private key to iCloud unless you manually disable backups. So even though iMessage is advertised as E2E encrypted, for the vast majority of users, Apple can read each and every message.

(And even if you disable backups, Apple can still read most if not all of your messages, because the persons on the other side of the conversations have not disabled backups)

It's worth noting that Google, the big bad guys of privacy, uses a proper E2E encryption scheme.

iMessages is e2e encrypted, so I’m not sure what you’re saying here

Can Apple read your iCloud storage? I’m not saying that it is, but shouldn’t that be encrypted at rest with a customer-specific key?

Yeah, they can read everything:

https://sneak.berlin/20200604/if-zoom-is-wrong-so-is-apple/

They were going to actually encrypt it, but suddenly had a change of heart after the FBI had a chat with them:

https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

Ugh

I don't have any detailed knowledge of it, but I've seen various similar comments based on this article and similar ones:

https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

This stance undermines the point of E2E. The messaging system is still E2E even if people backup their plaintext messages or their key on non-E2E storage.

Having you messages deleted because you forgot your iCloud password is good security but a terrible default.

Calling Apple's privacy stance PR is extremely misleading.

It's been engrained in them since the 80s and with the growth of Google, it became fun to vilify Apple because of it.

A better privacy solution would be to sync revocation lists every so often (and, if you must, right before opening a new app). Is there any privacy-preserving reason to not go this direction? How often would you expect certificates to be rescinded? You could also use a bloom filter to significantly reduce the false-positive rate.

CRLs are how we dealt with OCSP in the browser, and I feel like those must surely have more insanity than the Developer ID certs

Or something akin to OCSP stapling, which has been mentioned in a few places?

Stapling makes sense for the Web but not here.

With OCSP Stapling the remote web server whose identity you want to assure yourself of periodically gets an up-to-date OCSP answer about its own certificate. When you connect to that server, it gives you the certificate, and the OCSP answer, which assures you that the certificate is still good, and is signed by the Issuer of the certificate.

So, you visit Porn Hub, Porn Hub knows you visited and can reasonably guess it's because you like porn (duh). Porn Hub talks to their CA. The CA knows Porn Hub are Porn Hub and could reasonably guess it's a porn site (duh) but this way the CA doesn't learn that you visited Porn Hub. That's Privacy preserving. Nobody learns anything you'd reasonably expect they shouldn't know.

But how can we apply that to an application on your Mac? If every app reaches out from your Mac to Apple to get OCSP responses, they learn what you have installed, albeit I guess you can avoid telling them when exactly you ran it. This is enormously more costly and not very privacy preserving.

CRL-based ideas are much better for your privacy, although they might cost you some network traffic when the CRL is updated.

Of course one reason for Apple not to want to do CRLs is that they're transparent and Apple is not a very transparent type of company. With OCSP you've got no way to know if and when Apple revoked the certificate for "Obvious Malware II the sequel" or equally for "Very Popular App that Apple says violated an obscure sub-clause of a developer agreement".

But with CRLs it'd be easier for any researcher to monitor periodically for revocations, giving insights that Apple might not like. Do revocations happen only 9-5 Mon-Fri Cupertino time? Are there dozens per hour? Per day? Per Year?

That’s assuming that the OCSP is hosted by Apple, which doesn’t have to be the case. It sounds shitty from an app developer perspective, but app developers would have an incentive to host endpoints that make their apps runnable on macOS. This improves privacy, by distributing ocsp traffic across organizations, but also puts the burden of verification on app developers. Not sure if this would harm or help the app ecosystem

Wouldn’t a properly diffed CRL list be much smaller than a hash payload on every app launch? Say, a request like “give me all the revoked certificates since I last asked.”