4 ms·
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 r
by ghayes 6y ago
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.
- olliej 6y agoCRLs are how we dealt with OCSP in the browser, and I feel like those must surely have more insanity than the Developer ID certs
- catlifeonmars 6y agoOr something akin to OCSP stapling, which has been mentioned in a few places?
- tialaramex 6y agoStapling 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?
- e_proxus 6y agoWouldn’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.”
- catlifeonmars 6y agoThat’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