While this doesn't allow them to perfectly log every app you run, anyone with access to the data could create a pretty solid picture of which apps you're running. That includes anyone in the...
While this doesn't allow them to perfectly log every app you run, anyone with access to the data could create a pretty solid picture of which apps you're running. That includes anyone in the middle.
There's no good reason not to encrypt this transaction, it's basic security best practices when you're dealing with PII.
The post makes valid points but none of them make a case for not being alarmed by this. This is a company that makes privacy a part of their brand identity. Makes sense to point out where they're failing at that.
The nuance here really comes down to how we define PII. Does an Apple developer certificate serial number, sent in the clear, sent from a source IP to ocsp.apple.com, within some variable interval...
The nuance here really comes down to how we define PII.
Does an Apple developer certificate serial number, sent in the clear, sent from a source IP to ocsp.apple.com, within some variable interval of time (determined by Apple) constitute PII?
If we are trying to take advantage of this information, what can we actually ascertain? That some Mac behind that public IP launched an app signed by Mozilla for the first time in the last x minutes (where x isn’t even necessarily constant)? And, we would know it’s Mozilla only if we also had a database of developer certificate serial numbers. For high profile developers this is probably trivial to obtain or create, but for low profile developers we won’t even necessarily be able to identify the developer by their certificate serial number. Apple definitely can, since developers are registered with Apple’s developer program, but I’m assuming we’re a MITM here. If users don’t trust Apple, they shouldn’t be running macOS connected to the internet to begin with.
Is this concerning to me? Mildly. Is leaking these developer certificate serial numbers really personally identifying? This is the kind of thing that presents a surface where one could be fingerprinted, over enough observations over a long enough time. For specific combinations of developer certificate serial numbers, that could be uniquely identifying (if you launch them all within a window when the caching is expired and a MITM is listening). It’s bits of information that are leaking that Apple should encrypt. But, this is no more scary to me than looking at something like the fingerprinting surface that web browsers present. If I was really paranoid about what kind of information my Mac might be leaking, these OCSP checks are the least of my worries.
I don't disagree that, among all the concerns, it's far from the biggest. But certainly it's more than enough info to contitute PII. Fortunately the attention this has gotten will no doubt inspire...
I don't disagree that, among all the concerns, it's far from the biggest. But certainly it's more than enough info to contitute PII.
Fortunately the attention this has gotten will no doubt inspire them to make the trivial changes necessary to better protect the data.
I think this is true only in very specific circumstances. Within a household of multiple Macs running similar collections of apps (or a group of Macs on a public WiFi access point), I don’t see...
But certainly it's more than enough info to contitute PII.
I think this is true only in very specific circumstances. Within a household of multiple Macs running similar collections of apps (or a group of Macs on a public WiFi access point), I don’t see how a MITM would really be able to get much useful signal out of this. If you happen to run software signed with a developer cert that is unique to you, well, then now that’s definitely PII. But, how likely is that? I’m not a security expert, but it seems like there are likely a thousand other more reliable ways to try to identify someone than listening for these leaked serial numbers.
I thought I'd submit this in response to the—frankly alarmist—article by Jeffrey Paul, which makes the claim: This isn't true, and is explained in this response from Jacopo Jannone—who's article...
I thought I'd submit this in response to the—frankly alarmist—article by Jeffrey Paul, which makes the claim:
It turns out that in the current version of the macOS, the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it.
This isn't true, and is explained in this response from Jacopo Jannone—who's article ends on the following TL;DR:
No, macOS does not send Apple a hash of your apps each time you run them.
You should be aware that macOS might transmit some opaque information about the developer certificate of the apps you run. This information is sent out in clear text on your network.
You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file.
This seems like a fair summary of the situation. It's a bad look for Apple in terms of surfacing why and how the functionality works to technical users, but a good-faith interpretation of their actions here, rather than an alarmist take, will better indicate why Apple have decided to do this. While the lack of use of SSL when communicating to Apple's OCSP's servers is unfortunate, it's also not unintentionally lazy and is meaningfully explained in the article as to why it's over plaintext.
And yes, I have purposefully answered the article's question-in-title with the answer the article arrives at for clarity.
Another recent article worth reading: Apple Developer ID OCSP It's by Jeff Johnson, who's written some of the main articles about this system before, and whose tweet was the main source the other...
It's by Jeff Johnson, who's written some of the main articles about this system before, and whose tweet was the main source the other day explaining why Catalina users couldn't launch apps.
This article explains that he noticed that Apple has massively increased the length of time that Apple is caching the response, and also explains the difference between Developer ID and app notarization (which I wasn't clear on before).
Another good article on the topic: An OCSP disaster waiting to happen And another good one that's more on Apple's side (which has felt like the more rare position): Application Trust is Hard, but...
While this doesn't allow them to perfectly log every app you run, anyone with access to the data could create a pretty solid picture of which apps you're running. That includes anyone in the middle.
There's no good reason not to encrypt this transaction, it's basic security best practices when you're dealing with PII.
The post makes valid points but none of them make a case for not being alarmed by this. This is a company that makes privacy a part of their brand identity. Makes sense to point out where they're failing at that.
The nuance here really comes down to how we define PII.
Does an Apple developer certificate serial number, sent in the clear, sent from a source IP to ocsp.apple.com, within some variable interval of time (determined by Apple) constitute PII?
If we are trying to take advantage of this information, what can we actually ascertain? That some Mac behind that public IP launched an app signed by Mozilla for the first time in the last x minutes (where x isn’t even necessarily constant)? And, we would know it’s Mozilla only if we also had a database of developer certificate serial numbers. For high profile developers this is probably trivial to obtain or create, but for low profile developers we won’t even necessarily be able to identify the developer by their certificate serial number. Apple definitely can, since developers are registered with Apple’s developer program, but I’m assuming we’re a MITM here. If users don’t trust Apple, they shouldn’t be running macOS connected to the internet to begin with.
Is this concerning to me? Mildly. Is leaking these developer certificate serial numbers really personally identifying? This is the kind of thing that presents a surface where one could be fingerprinted, over enough observations over a long enough time. For specific combinations of developer certificate serial numbers, that could be uniquely identifying (if you launch them all within a window when the caching is expired and a MITM is listening). It’s bits of information that are leaking that Apple should encrypt. But, this is no more scary to me than looking at something like the fingerprinting surface that web browsers present. If I was really paranoid about what kind of information my Mac might be leaking, these OCSP checks are the least of my worries.
I don't disagree that, among all the concerns, it's far from the biggest. But certainly it's more than enough info to contitute PII.
Fortunately the attention this has gotten will no doubt inspire them to make the trivial changes necessary to better protect the data.
I think this is true only in very specific circumstances. Within a household of multiple Macs running similar collections of apps (or a group of Macs on a public WiFi access point), I don’t see how a MITM would really be able to get much useful signal out of this. If you happen to run software signed with a developer cert that is unique to you, well, then now that’s definitely PII. But, how likely is that? I’m not a security expert, but it seems like there are likely a thousand other more reliable ways to try to identify someone than listening for these leaked serial numbers.
I thought I'd submit this in response to the—frankly alarmist—article by Jeffrey Paul, which makes the claim:
This isn't true, and is explained in this response from Jacopo Jannone—who's article ends on the following TL;DR:
This seems like a fair summary of the situation. It's a bad look for Apple in terms of surfacing why and how the functionality works to technical users, but a good-faith interpretation of their actions here, rather than an alarmist take, will better indicate why Apple have decided to do this. While the lack of use of SSL when communicating to Apple's OCSP's servers is unfortunate, it's also not unintentionally lazy and is meaningfully explained in the article as to why it's over plaintext.
And yes, I have purposefully answered the article's question-in-title with the answer the article arrives at for clarity.
Another recent article worth reading: Apple Developer ID OCSP
It's by Jeff Johnson, who's written some of the main articles about this system before, and whose tweet was the main source the other day explaining why Catalina users couldn't launch apps.
This article explains that he noticed that Apple has massively increased the length of time that Apple is caching the response, and also explains the difference between Developer ID and app notarization (which I wasn't clear on before).
Another good article on the topic: An OCSP disaster waiting to happen
And another good one that's more on Apple's side (which has felt like the more rare position): Application Trust is Hard, but Apple does it Well