[rphlx]

The Wired article is not detailed enough to definitively poo-poo this scheme, but I am pretty skeptical about some of the claims, given a) how easy it is to map an IP to a coarse location, b) how easy it is to map many IPs to a small number of already-known humans/users.

That is to say: the asym crypto may strongly protect the precise (GPS or LTE triangulation) location from Apple and from others, but I do not see how a cloud-based system can ever hide coarse location from Apple and/or from governments as, given the short range of BT, they can reliably infer that a device (and hence its owner) is/was near whatever IP sends the encrypted precise location to their cloud. Then it's just a matter of mapping the device's "randomized" ID back to an actual user/phone. That seems easy enough as soon as a second device accesses it from an IP that's mappable to a specific residential address, Apple account, etc.

e.g.

A and B both log into iTunes or some other Apple service using [e-mail] and [e-mail] from HOMEIP at some point in the past. HOMEIP is never used by any other Apple accounts.

A(lice) and B(ob) exchange a secret and otherwise begin participating in this "private" tracking scheme.

A goes out shopping and while there it pushes its encrypted precise location to the Apple cloud, using random ID 424242, from MALLIP. Perhaps A's device sends it directly, or perhaps it's relayed from BT to Mall wifi to Cloud by C's device if A has both LTE and wifi disabled.

A few minutes later S(omeone) requests encrypted location for random ID 424242, from HOMEIP.

Apple (and any government compelling it to share information) can reliably infer that "Someone" was A or B attempting to track either B or A, and that the tracked phone was at/near the business address of MALLIP - their coarse location - even if they can't decrypt the precise location without the secret key. If you know from public records that A and B are married, and assume that women are more likely to be at a mall on their own than men, you may further assume that A is at the Mall while B is at home.

Result: the "private"/"encrypted" precise location beaconing has an unfixable metadata side channel that will leak coarse location data to Apple and to any governments that compell it.

[moreira]

What you're saying is basically that this scheme will leak the IP address you're on, because that's just how the internet works.

There's... not much that can be done about that, and there's no need for the scare quotes on the words private or encrypted. Any encrypted communication still uses an IP address that can be mapped to a coarse location; this isn't an Apple related thing.

If you want to be able to find your device (it's opt-in), it needs to relay its location via the Internet. Doing so requires an IP address, which can indeed be mapped to a coarse location in some cases (my own home IP address is totally useless, it says I'm in London when I'm on the other side of the country). I'm not sure what the big deal is.

[rphlx]

> that's just how the internet works

Well, the Internet does not strictly require all traffic between two parties to go through a MegaCo Cloud. Location privacy in this system would appear to be greatly enhanced (vs Apple-as-an-adversary) if A and B communicated directly, or through a server that they controlled, instead of through iCloud. In concise security terms, Apple man-in-the-middles the encrypted traffic in this system and thus may perform traffic analysis, deanonymization-via-inference, etc as I said above.

It's certainly true that NAT, firewalls, and a lot of other things make direct communication between two iDevices inconvienent and frequently impossible - that's fine and fair enough. But then the Company should not be making at least partially untrue privacy and anonymity claims that are essentially impossible to satisfy when by design all of the traffic flows through their cloud.

AFAICT Apple (and likely its host governments) will still need to be trusted parties in any scheme that flows through their infra, unless you care only about protecting your precise location, and are willing to expose your coarse location to them.

To be clear, they may already have that info from other services, and you'll have to trust Apple a lot anyway since they're making the phone and some custom silicon within it. And them having coarse location is certainly preferable to them having precise location data - so this system (as we are inferring it to work) is not worthless, and is still an improvement over a naive implementation.

But real internet anonymity and location privacy is hard to achieve; just ask any tor developer. So please don't let the marketing dept openly claim that, or even imply that, when the claim can't realistically survive a two minute security audit by HN infosec nerds. To be specific the WWDC claims that "this whole interaction is ... anonymous" and "there’s no need to worry about your ... privacy" are what I am taking some issue with here.

[dkoston]

If the gateway used to receive these requests cannot decrypt them and they pass through other connections before decryption, why wouldn’t this be possible? At the point of decryption you’d have the connecting IP of the last hop but if the origin IP isn’t forwarded, and there’s no request correlation ID or other identifying information, the machine processing the request wouldn’t know where the original request came from.

Of course any of the intermediate machines could be tracking this data for correlation purposes but it should be possible to strip it along the way.

If the request data containing the 424242 is encrypted and only the machine without origin info has access to that identifier, how would you know the request is for 424242?

[bluesign]

You are making a lot of assumptions, basically your story summarise as:

- A and B connect from same home network with their apple IDs - B checks location of someone (you assume it is A) - so we have A’s coarse location

Depending on implementation details, this randomIDs you mentioned not needed to be same when submitting and querying (and probably not)