[MBCook]

Not really. You could do it the way the Have I Been Pwned database works.

You hash your query and then send only the first X number of bits.

The server returns all results that hash up to that same first X number of bits.

The server doesn’t know exactly what number you were looking for, and you don’t have to download the entire database.

But in this case the server WOULD be able to figure out the set of possible phone numbers you were asking about. Because of the complexity of passwords the search space would be a lot larger.

So privacy wise this does seem better.

[tempay]

Indeed, I wasn't clear enough in my original message that it was under the assumption that you want to keep the caller 100% private from Apple.

Though there is a valid argument that you're still leaking information (e.g. "Person X received a call at 21:05:43"), but I'm not sure how you could possibly make an API that avoided that given the time sensitive nature of identifying callers.

[fboemer]

https://developer.apple.com/documentation/sms_and_call_repor... has some more details on privacy in Live Caller ID Lookup.

[Disclosure: I work on the team responsible for the feature]

[tempay]

Thanks, that was an interesting read. Seems like a nice solution with the pragmatic trade off with trusting there isn’t collusion between Apple and the third party.

[Cyphase]

The client can constantly and at random intervals make lots of chaff queries to the API, so the service doesn't know which are real calls and which aren't. The client knows it's incoming calls history, so it can make sure it's chaff queries are statistically convincing.

For instance, if you often receive a call at the same time of day, that could be a detectable signal in the noise, unless the client then creates a lot of similar fake signals in the noise.