Apple has access to all apps you open, your position, the content of your iCloud, etc. etc.
And it wasn't all apps—unsigned apps are allowed to run, so by definition, there's no way for Apple to "know" about them. Many people didn't know it was happening because they weren't affected.
Details: https://eclecticlight.co/2020/11/16/checks-on-executable-cod...
> Usage Data. Data about your activity on and use of our offerings, such as app launches within our services, including browsing history; search history; product interaction; crash data, performance and other diagnostic data; and other usage data
https://www.apple.com/legal/privacy/en-ww/
Or maybe Apple Lawyers don't understand either?
> BTW, OCSP checks are unencrypted, but Apple says it will change to an encrypted protocol.
“When caught, simply apologize and promise to do better next time, it will be fine”. It wasn't the first time, and it won't be the last.
As a sidenote: https://www.bbc.com/news/business-13416598
This is not how any browser implements it today. Browsers either do not check (Chrome, Safari) or check but fail open (Firefox, Edge). I'm not aware of any browser that fails closed in its default configuration. More: https://www.ssl.com/article/how-do-browsers-handle-revoked-s...
Browsers primarily handle revoked certs by pushing certificate revocation lists (CRLs).
Mozilla and Chrome have schemes to send a subset of revocations from the browser vendor to the user, Mozilla's is named OneCRL, the Chrome one is CRLSets.
For most websites if your end entity leaf certificate is revoked for some mundane reason Chrome likely simply won't know or care and it'll still work, because you aren't covered by CRLSets as the data would be too huge.
The long term fix, which site owners can implement, is OCSP Must Staple. What happens there is, when you request a certificate you insist on this "extension" and the extension tells client software "This certificate is only valid if accompanied by an up-to-date OCSP response". Then you set your server software to fetch OCSP responses for its own certificate and serve those to visitors.
This means excellent privacy (PornHub's certificate issuer still knows that PornHub is PornHub, not an invasion of privacy, and PornHub still knows that PornHub visitors visited PornHub, but the issuer doesn't learn who the visitors are) while being revocable (if the issuer provides REVOKED OCSP answers then you can't show that revoked certificate to a client once the last not-REVOKED OCSP answer expires)
Unfortunately, and this is a huge shame most especially for Apache, there are a lot of HTTPS servers that got OCSP Stapling badly wrong, meaning you need newer versions of software or have to install complicated workarounds because the early implementations were so stupid.
Incidentally did you know that web browsers tell certificate authorities about every website you visit that uses TLS with support for OCSP stapling.
OCSP stapling is exactly what enables the browser to verify the revocation status without contacting the cert authority. Also, not all browsers check OCSP.
Facebook collected data for ages using their SDK and lists of e-mail addresses/phone numbers submitted to them by advertisers but only started exposing them in their "download my data" tool (their GDPR SAR process basically) relatively recently.
GDPR access requests don't always tell the truth, often due to malice but in some cases incompetence too (there were a couple of times where my GDPR complaints have actually revealed to the company that their third-party SDKs leaked more data than they originally thought).
This is easily disproven by making a GDPR access request to see what various companies have retained on you, or if you’re extra paranoid inspecting what the device is sending back over the network.