Why would you not interpret this charitably as them not actually trying to spy on you? If they wanted to spy on you, why on Earth would they not send the actual valuable information?
Why would you not interpret this charitably as them not actually trying to spy on you? If they wanted to spy on you, why on Earth would they not send the actual valuable information?
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.
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.
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?
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.
Apple has more accurate information. They are not sending it. Why?
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.
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.
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 exactly the same concept as the NSA saying that they are only collecting metadata and not doing any spying.
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.
Source: me, downloading and running various apps
Has a third party verified they don’t keep track of IP addresses?
If they wanted the information, they would need to send it.
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.
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.
also ipv6
Different part of MacOS can send it and you would have no idea until it malfunction like in this case.