I believe you are trying to think about this rationally, but this is not the only thing going on.

When a mac boots up or changes network location, a long list of processes on your machine (like AppleIdAuthAgent, identityservicesd, , and maybe 10 or 20 more) connect to various apple servers associating your actual identity with the ip address. It will continue to do these kinds of things while you are online. And all this is interleaved with oscp requests.

Do you have sources for this? I don’t doubt you, I’d just be interested to read some details about what exactly those services are doing/sending.

this is from observations of my own machines.

I would suggest you install little snitch, turn off everything, and then boot your machine. Maybe switch from ethernet to wifi and observe the kinds of popups you get.

Another method, though hard to associate with specific processes, would be to run tcpdump -i <interface>.

Sometimes it's more useful to run tcpdump and do a capture, then play it back later because DNS lookups by tcpdump itself make it more chatty than it should be. You could also run it with -n but you get less information.

It is not possible to accurately connect an identity with an IP address. Many computers share IP addresses, and many others jump IP addresses frequently.

Let's say you're one out of 10,000 users in a large network sharing a single public IP address.

Anyone trying to identify you just needs to narrow that down from 10,000 to one. This can be done many different ways by combining data sources. You could automate it with algorithms and maybe some machine learning, but it'd also be pretty trivial for a dedicated human to do it.

Browser fingerprint, mac address, software versions, browsing behavior (https doesn't hide URLs), access times, and application hashes will all help narrow down that search.

Maybe your university requires you to install some special software (like one of those locked down browsers for exams), and the attacker knows an approximate range of time when you installed it based on your exam schedule. They could narrow their search by intercepting OCSP requests and filtering for application hashes that match the specific version of the software you most likely downloaded, based on the time you most likely downloaded it.

But why? Why go to these ridiculous lengths to try to extract information from an unreliable source?

Apple already has the device identifier and Apple ID. These are reliable. They do not need combining different data sources and algorithm and machine learning. They are the accurate data already. If they wanted it, they could just send it.

They don't. Why not? If they wanted this information, why on god's green earth would they not just send it?

It's quite obvious. That way you can't get nailed for breaching privacy.

It's exactly the same concept as the NSA saying that they are only collecting metadata and not doing any spying.

It would do absolutely nothing whatsoever for the legality of any collection they might want to do.

Of course, it would. IPs are required data to be gathered. They can be almost all the time correlated with real identities using other requests, but under many data regulation laws they wouldn't be allowed to send personal identifying information that isn't necessary.

GDPR would not agree with you there, I gather.

How does the GDPR agree with the collection of personally identifying data that is not necessary to operation?

I didn't mention Apple. Anyone intercepting the OCSP traffic (which isn't encrypted) could use it to track you.

Shoot, apparently those Tor devs have been completely wasting their time.

Somebody in the security industry should let them know that their work on the network level is useless and unnecessary because leaking IP addresses isn't a real privacy threat.

Accurately. The key word in there was "accurately".

The real key word is "legally". IP addresses + other metadata (browser fingerprinting and the like) can be enough to sufficiently identify an individual, or at least a household, for some purposes, such as making a more effective advertising profile.

Collecting the data based on IP would basically have the exact same legal status as doing it based on other identifiers. No browser is involved here, so no fingerprinting. And finally, Apple is not in the advertising business and has no need for advertising profiles.

Coulda woulda shoulda isn’t evidence.

I'm having trouble figuring out your meaning in this context. Care to explain?

There is no evidence Apple is storing any information collected via OCSP for advertising, or collecting metadata along with it. Effectively all they know is an IP address and a hash identifying a developer certificate that can correspond to any of dozens of apps.

How does "coulda woulda shoulda" mean that?

If IP addresses couldn't in some cases accurately track users, then it wouldn't be a priority to build a network that obscured them.

If they can only do it "in some cases", then they can't do it accurately, is the entire point. It can do it SOMETIMES.

Apple has more accurate information. They are not sending it. Why?

I think you might be confusing accuracy and reliability. But I'm not here to argue about semantics, you can use whatever definition of accuracy you want. IP addresses are large attack vector for deanonymization/tracking, and people should be thinking more about how IP addresses get leaked and in what contexts. Whatever definition of "accuracy" you want to use, I don't think that changes the overall point that IP addresses matter.

To your earlier comment:

> Why would you not interpret this charitably as them not actually trying to spy on you?

I fully agree with this. I think Apple's intention is not to spy on users, it's to A) stop malware, and B) exert more control over their ecosystem in general.

I have a problem with point B, but that's a separate conversation.

To your later point:

> It is not possible to accurately connect an identity with an IP address.

This is just plain wrong; it is possible to accurately connect identities to IP addresses, people do it all the time. Reliability is a separate conversation. If you're working off of a different definition of "accurate", then, whatever, I don't care. But I stand by the point that IP addresses are a privacy risk and that they can be used to track/identify users in the real world, I don't think that's a disputable fact.

The privacy worry here is twofold. First that these requests are (currently) sent in plaintext. To their credit, I think Apple is fixing that issue. Which is good, because plaintext payloads allow adversaries on the same network to potentially sniff which applications you're using.

The second privacy worry is that regardless of whether or not Apple is trying to spy on users, they still might be storing that data, and we only have their word to go on that it'll be stored in a protected way or deleted regularly. If a court order comes down asking Apple to reveal that information, or if it gets hacked, that data increases the threat model for Apple users.

An adversary with access to Apple's data (whether that adversary is a hacker or a government) could theoretically tie app usage to real-world identities if the IP addresses are logged, especially if they can match IP addresses with logging of other data being sent to Apple's servers. That's the point m463 is making in his original comment -- the data here doesn't just exist in isolation, it's IP addresses that an attacker could correlate with other real-world identifying information.

Many computers don't share IP addresses too. And there are times when there is only one macOS under an IP. This is not something to just wave away.

The point is, this information is UNRELIABLE.

Apple has access to information that is ACTUALLY RELIABLE.

However, they choose to not use the reliable information.

Why would you see this, and assume that they, on purpose, decided to NOT use the reliable information, but instead use unreliable information to spy on you?

Why would they do something so bone-headedly stupid?

Do you reject the possibility that they combine the reliable information with the unreliable information to strengthen the latter? I mean, if you have logs stating that a specific Apple ID connected from a specific IP address at a specific time, and they know the identity tied to that Apple ID, it seems reasonable that it would strengthen the claim of "the user at this IP address is most likely this person" quite a bit, especially if the same IP shows up regularly with that Apple ID? I'm not saying they do this currently, but I'm just drawing attention to the fine line between privacy and security. Vigilance isn't necessarily a bad thing, as long as it's grounded in the full reality. It's always possible that one day, Apple's focus in this area may change. When it does, it helps if part of that discussion is already being had.

I reject that, yes, because they could just collect the reliable information. The unreliable information is no value.

>The requests contain only app hashes.

No, application hashes are never sent. People are confusing OCSP and notarization. The requests sent via OCSP check the developer certificate. Notarization checks are done over HTTPS.

The request also contains your ip address. Charitable would be distributing a bloom filter and checking matches locally.

Your IP address is a very weak and unreliable way to identify you. If they actually wanted to identify you, they have much better ways to do it, and those ways are not used.

Is it even app hashes, or developer certificate hashes?

The larger the program, the longer it takes to verify the first time you run it. I can only interpret that as meaning they are basing the whole program.

Source: me, downloading and running various apps

Apparently the initial launch delay is Gatekeeper, which is something different.

Your IP address can be pretty accurately matched to an identity due to PRISM.

Has a third party verified they don’t keep track of IP addresses?

An Apple ID is tied to an identity right now. They don't use it. Why?

What does that even mean? Of course they can identify you, you are knocking their door with the same IP with your iCloud account. Maybe the file you are giving them does not have your uid, but as long as you have connected your Mac to your Apple account you are uniquely identified.

Plenty of computers share a single public IP address. Plenty of computers jump IP addresses constantly. It is not at all reliable trying to tie IP addresses together that way.

If they wanted the information, they would need to send it.

Maybe you have a funny network situation, but my network situation is solid, and my IP address rarely changes. IP addresses are absolutely identifiable information.

They are SOMETIMES identifiable information. They are not RELIABLE for identification.

If you are going to be collecting information, you are not going to choose unreliable information when you have the option to collect reliable information. That would not make sense.

I can right now open my vpn, change my ip address, go to my apple account and it will report that my Mac is "Online", meaning that apple knows that my particular machine is on with a given IP address. It would be completely useless (redundant at the very least) to also include the uid in the signature file.

There might ten other, a hundred other people with the same public IP visible to Apple, if you ISP is running you through a NAT.

That fact that you have connected from an IP recently in no way guarantees that the next connection from that IP will be coming from you. That is exactly why you need to send an identifier for any data being collected.

Every time you change network locations, all of these daemons contact apple again. There are plenty of push services on your machine and apple keeps track of where you are.

also ipv6

And Apple updates your ip continuously in their server as evidenced in the “find my” service.

>They do not contain the unique hardware identifier that Apple computers have

Different part of MacOS can send it and you would have no idea until it malfunction like in this case.

They would not be accurately tied together, though, since these requests are not sent with any kind of identifier.

Who knows, may be they can start to send id too by a special request from the server or send those hashes by other channels in addition to this one, but much later. And server can make such request based on some heuristics or based on some 'black list' of hashes. How can you know for sure? We can only guess to the certain degree without looking into sources.

Why would they NOT want the data now but would want it in some unspecified future?

To avoid being caught could be one reason. Why would they hide the feature without option in GUI to turn it off? We do not know. Possibly they are hiding something else, something bigger, who knows.