Wat apsd eigenlijk is
apsd is de Apple Push Notification service daemon. Het is een standaardonderdeel van macOS, geleverd en ondertekend door Apple, en het is verantwoordelijk voor het onderhouden van de verbinding van je Mac met het pushnotificatienetwerk van Apple (APNs). Het is geen malware, geen optionele toevoeging en niets dat je zelf hebt geïnstalleerd.
Zijn taak is smal maar essentieel: het houdt een verbinding open met de pushservers van Apple, zodat berichten die naar je Mac worden gestuurd op het moment van verzending kunnen aankomen, in plaats van te wachten tot een app erom vraagt. Wanneer de infrastructuur van Apple iets voor jouw machine heeft, pusht die het via die verbinding door, en apsd geeft het door aan het onderdeel van het systeem waar het thuishoort.
Een verrassend groot deel van macOS draait op die ene verbinding. iMessage en FaceTime gebruiken hem voor signalering, zodat een bericht of inkomend gesprek direct aankomt. Mail gebruikt hem voor accounts die pushlevering ondersteunen. Find My is ervan afhankelijk. Agenda, Contacten en Herinneringen gebruiken hem om te merken dat er iets is veranderd op een ander apparaat. Melding van de App Store en apps van derden lopen erdoorheen. Op Macs die zijn ingeschreven voor mobile device management, worden MDM-opdrachten op dezelfde manier geleverd, en daarom is apsd een harde vereiste in beheerde omgevingen.
Dus als je apsd actief ziet op het netwerk, kijk je meestal naar het loodgieterswerk achter een melding die je op het punt stond te ontvangen, of achter het stille systeem dat bevestigt dat er niets nieuws voor je is.
Waarom apsd altijd verbonden is
De reden dat apsd in elke netwerkmonitor verschijnt, is architecturaal en niet toevallig. Pushmeldingen werken alleen als het ontvangende apparaat bereikbaar is, en de manier waarop Apple een apparaat bereikbaar maakt, is door één langdurige uitgaande verbinding naar de servers van Apple te openen en die open te houden. De verbinding blijft bestaan, meestal inactief, en wisselt kleine keep-alive-verkeer uit zodat beide kanten weten dat alles nog in orde is.
Dat ontwerp is bewust efficiënt. Het alternatief, elke app die je wil melden zijn eigen verbinding laten openen en op updates laten pollen, zou betekenen dat er tientallen sockets, tientallen wake-ups en een merkbare aanslag op batterij en bandbreedte zouden zijn. In plaats daarvan is er één gedeeld kanaal voor het hele systeem, en individuele apps praten nooit rechtstreeks vanaf je Mac met hun notificatiebackends. Ze geven het bericht aan de service van Apple door, en Apple duwt het via de ene verbinding die apsd vasthoudt.
De verbinding moet ook opnieuw worden opgezet zodra het netwerk eronder verandert. Wakker worden uit sluimerstand, overschakelen van Wi-Fi naar Ethernet, verbinding maken met een ander netwerk, een VPN verbinden of verbreken: elk van die acties verbreekt de bestaande socket, en apsd bouwt meteen een nieuwe op. Als je een verbindingslog bekijkt terwijl je tussen netwerken beweegt, is apsd een van de eerste processen die telkens opnieuw verbindt.
De eindpunten waarmee het praat zijn door Apple beheerde push- en courierhosts, en APNs-verkeer loopt meestal via TCP-poort 5223, met terugvalopties wanneer die poort niet beschikbaar is op een beperkend netwerk. Het volume is normaal klein: veel verbindingen, korte uitwisselingen, weinig totale data. Dat profiel van hoge zichtbaarheid en weinig bytes maakt apsd opvallend in monitoringtools zonder dat het ooit echt zwaar is.
Is apsd veilig, en hoe kun je dat zelf controleren
apsd is veilig. Het is een first-party Apple-daemon, maakt al jaren deel uit van macOS en zijn netwerkgedrag wordt volledig verklaard door de taak die het uitvoert. De terechte zorg is niet of de echte apsd gevaarlijk is, maar of het proces dat op je Mac onder die naam draait wel de echte is. Een eerlijke vraag, want malware een saaie systeemachtige naam geven is een oude truc.
Je kunt dat zonder speciale tools vaststellen. Zoek in Activity Monitor apsd in het Network- of CPU-tabblad en open de inspector door erop te dubbelklikken. De echte daemon draait als root, staat op het alleen-lezen systeemvolume in plaats van in je thuismap, Applications of een Downloads-map, en wordt gestart door launchd in plaats van door iets dat je hebt geopend. Een kopie van apsd ergens in je gebruikersmap zou de afwijking zijn die je moet uitzoeken.
De sterkere controle is de codehandtekening. De systeembinaries van Apple zijn ondertekend door Apple, en op moderne macOS is het systeemvolume cryptografisch verzegeld, dus een gemanipuleerde of vervangen systeemaemon is niet iets dat gewone software stilletjes kan regelen. Wil je dat expliciet bevestigen, dan wordt macOS geleverd met command-line tools die de ondertekeningsautoriteit van elke binary rapporteren, en voor apsd zou die autoriteit Apple moeten zijn.
Het is ook goed om te weten wat apsd niet is. Het verstuurt je berichten of documenten niet als inhoud naar Apple. Het pushkanaal draagt notificatiepayloads en signalering voor de hierboven beschreven diensten, en voor end-to-end versleutelde diensten zoals iMessage is het een bezorgroute, geen plek waar leesbare inhoud staat. Als je apsd constant ziet verbinden, zegt dat alleen dat het notificatiesysteem werkt, niets meer.
Moet je apsd blokkeren?
Het eerlijke antwoord is nee, en het is de moeite waard om specifiek uit te leggen waarom, omdat de gevolgen voor één proces ongewoon breed zijn.
apsd blokkeren dempt niet selectief één luidruchtige app. Het verbreekt het ene kanaal waarlangs elke pushmelding op de Mac binnenkomt. iMessages verschijnen niet meer totdat iets anders een synchronisatie afdwingt. FaceTime-gesprekken stoppen met overgaan. Find My verliest zijn vermogen om snel te reageren. Mail-accounts die op push vertrouwen, vallen terug op periodiek controleren of stoppen helemaal met bijwerken. Agenda, Contacten en Herinneringen horen niet meer over wijzigingen die op je andere apparaten zijn aangebracht. Meldingen van apps van derden komen simpelweg niet aan. Op een beheerde Mac worden MDM-opdrachten van IT niet meer afgeleverd, wat meestal uitloopt op een supportticket in plaats van een oplossing.
Erger nog, de foutmodus is verwarrend in plaats van duidelijk. Niets toont een foutmelding dat push is geblokkeerd. Dingen stoppen gewoon stilletjes met op tijd te zijn, en weken later ben je aan het uitzoeken waarom berichten op je iPhone aankomen maar niet op je Mac.
Als het onderliggende doel minder meldingen is, zijn de juiste hulpmiddelen degene die daarvoor zijn gemaakt. In Systeeminstellingen kun je meldingen per app uitschakelen, en met de focusmodi kun je ze onderdrukken op basis van context of planning, beide stoppen de onderbreking terwijl de aflevering intact blijft. Als het doel minder achtergrondverkeer is, is apsd sowieso het verkeerde doelwit: in verplaatste bytes is het een van de lichtste sprekers op een typische Mac. De processen die echt gegevens verplaatsen zijn meestal synchronisatieclients, back-upagents, updaters en apps met analytics- of advertentie-SDK's, en dat zijn de processen die het waard zijn om te bekijken.
Wanneer apsd hoog CPU- of netwerkgebruik vertoont, en het grotere geheel
Af en toe gedraagt apsd zich echt verkeerd, en het symptoom is bijna altijd hetzelfde: aanhoudend CPU-gebruik en een stroom verbindingspogingen die ver boven het rustige keep-alive-patroon uitstijgt. Wat je meestal ziet, is een reconnection-loop: de daemon probeert verbinding te maken, de poging mislukt of wordt afgebroken, en hij probeert het opnieuw, eindeloos.
De veelvoorkomende oorzaken zijn het waard om in volgorde door te nemen. Een haperend of beperkend netwerk is het meest voorkomend: captive portals, bedrijfsnetwerken die de poorten filteren die APNs gebruikt, of een onstabiele VPN kunnen er allemaal voor zorgen dat apsd geen verbinding kan voltooien terwijl het blijft proberen. Daarna komt een verouderde credential: een Mail- of iCloud-account waarvan de authenticatie is verlopen, verschijnt vaak als push-activiteit in plaats van als een duidelijke fout, en uitloggen bij dat account en opnieuw inloggen lost het op. Problemen met Keychain die de certificaten beïnvloeden die betrokken zijn bij de pushverbinding, veroorzaken hetzelfde patroon. Als niets daarvan van toepassing is, lost een herstart verrassend veel van deze lussen op. Controleer ook of de lus een specifiek netwerk volgt. Als apsd thuis perfect werkt en op kantoor in een lus blijft hangen, wijst dat op het netwerk, niet op je Mac.
Het bredere punt is het punt dat je hier bracht. apsd is een daemon onder velen die macOS zonder het te vragen draait, en de meeste praten met het netwerk, allemaal normaal, allemaal standaard ondoorzichtig. macOS geeft je bijna geen zicht op welke verbindingen waarheen gaan, en daarom leest een gewoon proces met een onbekende naam al snel als verontrustend.
Dat zichtbaarheidsgat dicht NetMute. Het toont realtime verkeer per app en per proces, zodat je kunt zien wat apsd doet naast alles op je Mac. Logging op domeinniveau legt vast met welke domeinen elk proces contact had, wanneer en hoeveel data er werd verplaatst, waardoor een vage verdenking een specifiek antwoord wordt. Als iets echt niet hoort te praten, blokkeert de firewall per app het met één klik, met tijdelijke regels die vanzelf verlopen voor wanneer je alleen wilt testen of blokkeren iets breekt. Netwerkprofielen laten regels meebewegen met het netwerk waarop je zit, en Tracker Shield dekt meer dan 1.100 bekende tracker-domeinen. Het doel is niet om meer te blokkeren, want zoals apsd laat zien is het meeste achtergrondverkeer legitiem, maar om het verschil te zien.