- Apple devices request signatures in order to perform software updates
- Those requests include the device's ECID, which is fixed per-device and used to generate the signature
- Those requests are sent in plaintext to the signing server
- As a result, it would be possible for someone snooping on internet traffic on something like a backbone to correlate an ECID with the IP address the request was sent from, and over time track the movements of a unique device between different IP addresses.
It is worth noting that the ECID is not considered secret information, though it is unique and unchangeable. This is also not a surprising revelation; the functioning of TSS and SHSH blobs has been well-known since the early days of iOS reverse-engineering.
The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device. Encryption would obviously have no effect on Apple's ability to access the data, so that's a bit of a red herring.
My understanding from the Apple security documentation is that they explicitly opted for using HTTP "rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmware’s attack surface." I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway, though I'm sure some kind of challenge-response process would allow the ECID to be encrypted either way.
But I can't see a reason that requests wouldn't be made over HTTPS outside of this environment by default; it might not eliminate the attack surface but would curtail it quite a lot. It would be interesting to know if there's a specific reason behind that decision. I don't really find it that convincing that it might be done deliberately such that essentially "someone watching a network backbone might be able to figure out what city your ECID is in".