Yesterday on 1 Feb 2021, Apple released macOS 11.2 (Big Sur .2), which removes the ContentFilterExclusionList that prevented user content filtering applications from blocking Apple first-party apps from accessing the network. This misfeature, originally introduced on 12 November 2020 in macOS 11.0 (the only OS available on the new M1/ARM “Apple Silicon” macs) and initially publicized on Twitter by Patrick Wardle, creator of LuLu, was a major privacy violation, permitting Apple apps to phone home even when you used a firewall like LuLu or Little Snitch to block them.

Fortunately, it’s now removed, and users like me who don’t use iCloud, the App Store, Siri, iMessage, or FaceTime (and have Apple’s analytics disabled) can now upgrade to Big Sur, knowing that it is possible to prevent the device from constantly sending usage data across the network to the manufacturer.

There are several privacy/usage leaks remaining in the OS, but now they can be effectively blocked without affecting the overall operation of the device.

Test Prep

The following testing occurred today, using an M1 Macbook Air with Wi-Fi MAC 18:3e:ef:b9:2a:01.

The system was booted from 11.2 USB installer media, and diskutil zeroDisk force /dev/disk0 was run from terminal. nvram -c was used to wipe all stored NVRAM settings, including network configuration and credentials. The system upon reboot was missing its OS as well as its macOS and system recovery partitions (as expected), and booted to the “exclamation point in a circle” awaiting OS and firmware restore.

The machine was placed in DFU mode, connected with a cable to another machine running Apple Configurator 2, and UniversalMac_11.2_20D64_Restore.ipsw (SHASUM 7315f657df2a14b838b9d51eb49cdfff5be090e7) was dragged directly onto the “DFU” icon for the USB2-attached MBAir, restoring the firmware and OS.

On first boot, the system did not connect to the previously-automatically-connected available Wi-Fi network, suggesting successful clearing of NVRAM (which normally persists your Wi-Fi password across reinstalls/OSes).

The system completed the out-of-box-setup (initial country selection, user account creation, et c) without being connected to the network. Location services, analytics, “Screen Time”, Siri, and Touch ID were all declined.

(Has anyone else noticed that Apple’s setup wizards are getting more and more aggressive about prompting you to enable their services, even after you click no?)

What’s It Doing?

Pcapping began.

The desktop appeared, and the system was connected to a dedicated wi-fi network for the purpose, DeviceUnderTest. 60 seconds or so of “no activity” simply staring at the desktop elapsed, and the system was rebooted, automatically reconnecting to the test network.

Wi-Fi was then disabled. The pcap on the gateway was filtered thus:

tcpdump -lne -r 2021-02-02.firstboot-unfiltered-11.2.pcap \ -w 2021-02-02.firstboot.filtered-b92a01-11.2.pcap ether host 18:3e:ef:b9:2a:01

The following is all packets to or from 18:3e:ef:b9:2a:01: 2021-02-02.firstboot.filtered-b92a01-11.2.pcap.gz

In this few minutes, the system generated 38 megabytes of network traffic.

The following is a list of all hostnames queried in DNS by Big Sur in this pcap:

nostromo:~$ tshark -r 2021-02-02.firstboot.filtered-b92a01-11.2.pcap \
    -T fields -e dns.qry.name | sort | uniq |
    grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa"

1-courier.push.apple.com
1-courier.sandbox.push.apple.com
46-courier.push.apple.com
49-courier.push.apple.com
a1051.b.akamai.net
a1864.gi3.akamai.net
a2047.dscb.akamai.net
a239.gi3.akamai.net
albert.apple.com
albert.gcsis-apple.com.akadns.net
api.apple-cloudkit.com
api.smoot.apple.com
apple-finance.query.yahoo.com
appleid.apple.com
bag-smoot.v.aaplimg.com
bag.itunes.apple.com
c.apple.news
captive.apple.com
captive.g.aaplimg.com
cdn.apple.com.c.footprint.net
cf.iadsdk.apple.com
configuration.apple.com
configuration.ls.apple.com
cs9.wac.phicdn.net
e10499.dsce9.akamaiedge.net
e11408.d.akamaiedge.net
e12919.dscd.akamaiedge.net
e1329.g.akamaiedge.net
e16126.dscg.akamaiedge.net
e17437.dscb.akamaiedge.net
e5977.dsce9.akamaiedge.net
e673.dsce9.akamaiedge.net
e6858.dsce9.akamaiedge.net
e6987.a.akamaiedge.net
e6987.e9.akamaiedge.net
gateway.fe.apple-dns.net
gateway.icloud.com
gdmf.apple.com
gdmf.apple.com.akadns.net
geo-applefinance-cache.internal.query.g03.yahoodns.net
get-bx.g.aaplimg.com
gsa.apple.com
gsa.apple.com.akadns.net
gsp-ssl.ls.apple.com
gspe1-ssl.ls.apple.com
gspe21-ssl.ls.apple.com
gspe35-ssl.ls.apple.com
help.apple.com
iadsdk.apple.com
init-p01md.apple.com
init.ess.apple.com
init.itunes.apple.com
init.push-apple.com.akadns.net
init.push.apple.com
internalcheck.apple.com
lcdn-locator-usnkq.apple.com.akadns.net
lcdn-locator.apple.com
mesu.apple.com
ocsp.apple.com
ocsp.digicert.com
pancake.apple.com
pancake.g.aaplimg.com
pds-init.ess.apple.com
stocks-sparkline.apple.com
swcdn.apple.com
swdist.apple.com
swscan.apple.com
time.apple.com
weather-data.apple.com
weather-edge.apple.com
weather-edge.news.apple-dns.net
www.apple.com
xp.apple.com
nostromo:~$ tshark -r 2021-02-02.firstboot.filtered-b92a01-11.2.pcap \
    -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" |
    grep -v "_dns-sd" | grep -v "in-addr.arpa" | wc -l
      74
nostromo:~$

All of these 73 hostname lookups happened without launching any apps: no App Store, analytics off, no iTunes, nothing. No Apple ID has been used on the device. The device was set up, analytics and network services declined, connected to network, sat at desktop, rebooted, sat at desktop, and then shut down.

Let’s see what happens when we launch some apps:

nostromo:~$ ssh root@gateway.local "tcpdump -s 9999 -i ens3 -w - ether host 18:3e:ef:b9:2a:01" |
    pv > 2021-02-02.applaunch.11.2.pcap

The system is reconnected to Wi-Fi, and rebooted.

One by one, the following apps are launched (via the command-space launcher, which also sends each and every keystroke typed into it over the network):

• App Store
• News
• TV
• Books
• Maps

The “we’re going to upload your hardware serial number” non-consent “consent” screen on these was clicked through, and then the splash pages were permitted to load, and then the apps were closed. The system was shut down.

An additional 47 megabytes of traffic was generated in this additional 2-3 minutes: 2021-02-02.applaunch.11.2.pcap.gz.

nostromo:~$ tshark -r 2021-02-02.applaunch.11.2.pcap -T fields -e dns.qry.name | sort |
    uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa"
tshark: The file "2021-02-02.applaunch.11.2.pcap" appears to have been cut short in the middle of a packet.

1-courier.push.apple.com
1-courier.sandbox.push.apple.com
26-courier.push.apple.com
34-courier.push.apple.com
a1806.dscb.akamai.net
a1838.dscb.akamai.net
a1864.gi3.akamai.net
a1956.dscb.akamai.net
a2047.dscb.akamai.net
amp-api.apps.apple.com
api-edge.apps.apple.com
api-glb-den.smoot.apple.com
api-glb-usw2c.smoot.apple.com
api.apple-cloudkit.com
apple-finance.query.yahoo.com
apple.com
apple.comscoreresearch.com
appleid.apple.com
apps.mzstatic.com
ax.itunes.apple.com
bag.itunes.apple.com
books.apple.com
buy.itunes.apple.com
c.apple.news
captive.apple.com
captive.g.aaplimg.com
cdn.smoot.apple.com
cdn.smoot.g.aaplimg.com
cdn2.smoot.apple.com
cf.iadsdk.apple.com
client-api.itunes.apple.com
configuration.apple.com
configuration.ls.apple.com
cs9.wac.phicdn.net
e10499.dsce9.akamaiedge.net
e11408.d.akamaiedge.net
e12919.dscd.akamaiedge.net
e1329.g.akamaiedge.net
e14313.g.akamaiedge.net
e16126.dscg.akamaiedge.net
e17437.dscb.akamaiedge.net
e3925.dscx.akamaiedge.net
e5949.dscg.akamaiedge.net
e5977.dsce9.akamaiedge.net
e673.dsce9.akamaiedge.net
e673.dscx.akamaiedge.net
e6858.dsce9.akamaiedge.net
e6987.a.akamaiedge.net
e6987.e9.akamaiedge.net
e8143.dscb.akamaiedge.net
gateway.fe.apple-dns.net
gateway.icloud.com
gdmf.apple.com
gdmf.apple.com.akadns.net
geo-applefinance-cache.internal.query.g03.yahoodns.net
get-bx.g.aaplimg.com
gsp-ssl.ls.apple.com
gspe1-ssl.ls.apple.com
gspe19-ssl.ls.apple.com
gspe21-ssl.ls.apple.com
gspe35-ssl.ls.apple.com
help.apple.com
humb.apple.com
iadsdk.apple.com
init.itunes.apple.com
init.push-apple.com.akadns.net
init.push.apple.com
is1-ssl.mzstatic.com
is2-ssl.mzstatic.com
is3-ssl.mzstatic.com
is4-ssl.mzstatic.com
is5-ssl.mzstatic.com
itunes.apple.com
js-cdn.music.apple.com
mesu-cdn.origin-apple.com.akadns.net
mesu.apple.com
news-assets.apple.com
news-client.apple.com
news-client.news.apple-dns.net
news-edge.apple.com
news-edge.origin-apple.com.akadns.net
news-events.apple.com
news-events.news.apple-dns.net
ocsp.apple.com
ocsp.digicert.com
pancake.apple.com
pancake.g.aaplimg.com
pds-init.ess.apple.com
play.itunes.apple.com
s.mzstatic.com
sb.tv.apple.com
se-edge.itunes.apple.com
sf-api-token-service.itunes.apple.com
smoot-api-glb-den.v.aaplimg.com
smoot-searchv2-usw2c.v.aaplimg.com
stocks-sparkline.apple.com
support-sp.apple.com
swscan.apple.com
time.apple.com
uts-api.itunes.apple.com
weather-data.apple.com
weather-edge.apple.com
weather-edge.news.apple-dns.net
www.apple.com
xp.apple.com
nostromo:~$ tshark -r 2021-02-02.applaunch.11.2.pcap -T fields -e dns.qry.name |
    sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" | wc -l
tshark: The file "2021-02-02.applaunch.11.2.pcap" appears to have been cut short in the middle of a packet.
     106
nostromo:~$

105 unique hosts looked up this time. Again, this is on a system that does not opt in to any Apple services: no iCloud, no FaceTime, no iMessage, no App Store apps, no Siri, no analytics.

The system was reconnected to the network, and 11.2-block-apple-hosts.sh was downloaded and executed, placing the combined list of hosts into /etc/hosts in an attempt to perform some simple hostname-based blocking. The system was then shut down.

Pcapping resumed.

The system was booted to the desktop, the cursor moved around, and rebooted to the desktop once more.

The same apps were again one by one launched in order and terminated:

• App Store
• News
• TV
• Books
• Maps

The system was shut down and the resulting file: 104KB (~one tenth of a megabyte) comprising 2021-02-02.hostblocking.11.2.pcap.

It’s still sending DNS traffic trying to look up the following hostnames:

nostromo:~$ tshark -r 2021-02-02.hostblocking.11.2.pcap -T fields -e dns.qry.name |
    sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa"
tshark: The file "2021-02-02.hostblocking.11.2.pcap" appears to have been cut short in the middle of a packet.

24-courier.push.apple.com
36-courier.push.apple.com
a1806.dscb.akamai.net
a1864.gi3.akamai.net
api-edge.apps.apple.com
api-glb-usw2c.smoot.apple.com
apple-finance.query.yahoo.com
apple.comscoreresearch.com
apps.mzstatic.com
c.apple.news
captive.apple.com
captive.g.aaplimg.com
cf.iadsdk.apple.com
configuration.apple.com
configuration.ls.apple.com
e10499.dsce9.akamaiedge.net
e11408.d.akamaiedge.net
e12919.dscd.akamaiedge.net
e1329.g.akamaiedge.net
e17437.dscb.akamaiedge.net
e5977.dsce9.akamaiedge.net
e673.dsce9.akamaiedge.net
e673.dscx.akamaiedge.net
e6987.a.akamaiedge.net
e6987.e9.akamaiedge.net
gateway.fe.apple-dns.net
gateway.icloud.com
gdmf.apple.com
gdmf.apple.com.akadns.net
geo-applefinance-cache.internal.query.g03.yahoodns.net
get-bx.g.aaplimg.com
gsp-ssl.ls.apple.com
gspe1-ssl.ls.apple.com
gspe19-ssl.ls.apple.com
gspe35-ssl.ls.apple.com
help.apple.com
iadsdk.apple.com
init.itunes.apple.com
init.push-apple.com.akadns.net
init.push.apple.com
mesu-cdn.origin-apple.com.akadns.net
mesu.apple.com
news-edge.apple.com
news-edge.origin-apple.com.akadns.net
ocsp.apple.com
pds-init.ess.apple.com
play.itunes.apple.com
push.apple.com
smoot-searchv2-usw2c.v.aaplimg.com
swdist.apple.com.edgekey.net
swscan.apple.com
xp.apple.com
nostromo:~$

All in all I think that’s a pretty good improvement. I’m going to be blocking all/most of these hostnames/third-level domains at NextDNS, my DNS provider, and I imagine you could accomplish much the same in Pi-Hole or some similar project. This, coupled along with a (now working) user firewall (I intend to use LuLu) should be sufficient for my purposes.

It will be interesting (read: time-consuming and toilsome) work trying to figure out which hostnames beyond the obvious ones (such as swscan.apple.com) will need to be unblocked to receive OS security updates. Apple, if you’re listening (like you apparently were last time), putting critical OS patches/checks on a small number of consistently named hostnames, and publishing/documenting that list, would be hugely beneficial for those of us who want to avoid vulnerabilities while hard opting-out from Apple’s other nonconsensual network services.

Blocking this list of hostnames, coupled along with the fact that macOS will now no longer prevent LuLu and Little Snitch from working against Apple’s own embedded OS spyware in 11.2 means that I’m saved from having to switch to KDE and the shitshow that is PC laptop hardware for at least a few more months. (Did you know there are precisely zero good GUI email clients for Linux?!)

(I recently received an XPS 13” for testing, and while the 300+ ppi screen is amazing (also, it’s an option), you’re fooling yourself if you think this thing can compete with Apple laptops.)

The quest for a computer that allows me to boot, open a local text editor, write some words, save them on a disk, quit the program, and shut down without snitching to the network continues. (This is mild hyperbole: Pop! OS on the XPS 13 is already there; I just can’t stand the plasticky keyboard, the shitty GPU, and the terrible desktop environments available for Ubuntu-alikes.) Winston Smith would be proud, I think.

I’m starting a video series soon that’s going to highlight these sorts of widespread, invisible processes that happen with our tools and technology, generally without our knowledge. It’s a scary thought, but Apple devices and software, while chock-full of network surveillance, are actually some of the least intrusive in the industry. Make sure you sign up at sneak.berlin/list to be notified when my video series launches if you’re interested in this kind of stuff.

Final Notes

If you’re really concerned about privacy for these things, do what I do, and keep it behind a separate VPN router at all times (a VPN client on the device itself is insufficient). At my home and office I have a dedicated vlan/ssid for such things, with a PC Engines apu2 as WireGuard client and gateway, and on the road I have a GL.iNet GL-E750 which takes a SIM card, speaks LTE/4G to the tower, runs OpenWRT and a WireGuard client (on which I have root and access to iptables/tcpdump!), has a battery, and provides Wi-Fi. I don’t put SIM cards in any of my Apple devices any longer, nor do I ever connect them to the unfiltered, un-VPN’d internet. My iPhone 12 Pro (sadly, my last) has never had a SIM card in it, and never will.

This may seem a bit extreme, but all iPhones/iPads (and now Macs!) maintain a persistent connection to Apple at all times (to APNS, for the receipt of push notifications), with a unique identifier, which permits Apple to construct a detailed track log of your device via the geolocation of the client IP that connects to the service. This, coupled along with the unique identifier, lets them (and any other service your devices frequently connect to with a unique ID) see when you switch from your home ISP to your mobile carrier, from your mobile carrier to your work ISP, or when you go to a different city or town. I’ve nothing to hide, but I’d prefer that the people who constructed my laptop not forever receive a realtime log of when I’m at or away from home; that strikes me as unreasonable. Apple’s marketing around privacy seems to assume that people desire privacy from everyone but Apple themselves.

Stay safe out there, and keep in touch.