22 comments

[ 2.8 ms ] story [ 44.5 ms ] thread
I would have expected this for iOS, but for macOS this is quite jarring. I don't think just designing good products is too innovative and that extends to the M1 chips. The negative side of such manufacturers is quite predictable and this is just plainly bad software behavior through and through. Apple isn't user oriented, it just assumes its users won't notice.
IOS still tracks you. Just setup your router though a linux computer with 2 ethernet ports set up to forward traffic, connect to your wifi on your phone, and capture the traffic on the computer. You will see all the DNS requests to Apple endpoints.
installing lulu (application-level firewall) let's you see most (all?) of it. i just wish there was a definitive list of what the endpoint services are. for instance, i have no interest in icloud photo storage, so i'd love to block all those connections at the IP level (not just dns), but i really like using imessage on my mbp, so want to let those through. i'm currently having to figure this out via trial and error (and lots of error, at that).

https://objective-see.com/products/lulu.html

> let's you see most (all?) of it.

Who really knows any more. A couple years ago Apple prohibited kernel level firewalls (for security) and rolled out their ContentFilterExclusionList which whitelisted many Apple services, but also created a huge opportunity for attacks. It was quite an appalling gesture on Apple's part.

Since then, attacks surfaced, and they backtracked on their terrible idea.

https://www.itpro.co.uk/security/firewalls/358338/apple-drop...

>> Apple has removed a controversial feature in its macOS operating system that allowed more than 50 of its own apps to completely bypass third-party security tools like firewalls and virtual private networks (VPNs).

>> The ContentFilterExclusionList, introduced in macOS 11 Big Sur, was flagged by the security community and developers late last year as being a potential security risk. This list’s existence in macOS meant traffic generated from Apple software such as Maps and iCloud couldn’t be blocked by a socket filter firewall.

>> Researchers have speculated that Apple excluded its own apps from the oversight of third-party firewalls in the name of overall security. For example, if excluded, these services may continue to receive updates when all web traffic is blocked.

don't be daft the users of this platform implicitly, unequivicably trust that apple is not doing anything bad with this... </sarcasm>

Frankly I'm (unfortunately) not shocked and nor should any other user of any other platform be, this is the norm in the industry right now. I'd like to be able to turn around in 5 years and say I'm glad they turned off all those servers and disabled all that tracking but I'm not counting on it...

> You can be insecure to everyone, or you can be insecure to Apple. There’s no third choice.

Third choice: Use a VPN if you're concerned about this, until Apple transmits this unique hardware ID in a secure way

I wonder if it's HTTP because of certificate validity problems, wasn't there a case where a Mac couldn't boot to "Online Recovery" mode when the date on the machine is wrong (and therefore it treated the server's certificate as invalid)?

I guess a fix for the above issue would be to first query a server for the current time/date.

How ironic considering today that...

>Apple CEO Tim Cook today delivered the keynote speech at the Global Privacy Summit in Washington D.C. The conference, hosted by the International Association of Privacy Professionals, is focused on international privacy and data protection.

Tim Cook is a spook or a blackmail target ..
Apple is Spyware. I use it out of sheer need.....not desire. it's a crappy ecosystem. it's a dictators wet dream....

Apple is the cause of millions of deaths of year....and they have no intent on fixing themselves. this is what made them big.....support from the global industrial complex..

Can we reserve trite clichés like "Apple is Spyware" for reddit and maybe reserve this place for more focused discussion?

"MacOS sending HTTP requests with hardware unique identifiers in plaintext is bad because..." would be an example.

If your threat model is this extreme you likely should be airgapped and not downloading OTA updates.
There are no non-OTA updates available for macOS any longer, AFAIK.

You can download full installers, and do a full reinstall on each point release, but that is prohibitively time-consuming (and still requires internet access to reactivate the device following a drive wipe, which transmits your ECID and other information to Apple at albert.apple.com).

I understand that it may also optionally drop executables on your system at reinstallation time (based on device serial) for devices enrolled in Apple's DEP, which allows for no-click MDM enrollment for serials registered with Apple to an organization, so who knows if Apple can also be compelled at that point to target specific devices with police malware.

There is no good way to set up a new Apple system in a really trustworthy way, as it absolutely requires phone-home during wipe/reinstall (to check to make sure your serial isn't marked as stolen in someone else's iCloud account, among other reasons). I have written about this before.

https://sneak.berlin/20201204/on-trusting-macintosh-hardware...

This is a lot of hyperbole apart from the fact that the data here is transmitted in plain text, which is dumb and more likely to be an oversight. I fail to see how Apple would have something to gain by letting others see this data.
Got a new blocked domain in my Pi-hole: gs.apple.com
This will make your OS updates fail.
Thanks. Just checked now and it works, if the update will fail to download I’ll tempororary disable this domain.
If it works, then your blocking is ineffective.

If these calls are blocked, the update will fail, as they are required.

At the moment there aren’t updates, but the check for new updates work. I’ll try when there’s an update.
Why not download from main OS and verify from uefi like everyone else does?
> 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

The request does not come from the firmware. It's a full on normal macOS application process, in normal macOS, on the main CPU that's doing the HTTP requests. They could easily use TLS.

This is why it strikes me as so odd that Apple is still using plaintext here.

(I don't even think there is internet access available to the ASPs in the traditional sense.)

> 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.

There is a set of organizations in the United States which have access to unencrypted backbone traffic, all credit card processing transactions in the country[1] (since 2010 at least!), and every flight record in the country (via the ironically named "Secure Flight") program.

It's not a lot of database querying to take this "pretty low-resolution" data and begin to narrow down which ECIDs map to which PNRs map to which payment cards (which, thanks to BSA/PATRIOT, always map to government ID without exception) with $1000+ payments to Apple for shiny new M1 macs. It's even fewer if you can query Apple's sales database directly without a warrant or probable cause via FAA702.

If you don't think that sort of information is ripe for abuse, you're not thinking very creatively.

[1]: https://www.wired.com/2010/12/realtime/