Hoe werken app-blockers?

Een app-blocker werkt door zich tussen jou en de app die je probeert te openen te plaatsen, en gebruikt daarbij welke toegang het besturingssysteem hem ook toestaat om ofwel die app te verhinderen te starten, ofwel het iets te laten kosten voordat dat gebeurt. Op iOS komt die toegang vrijwel volledig via Apples eigen Screen Time-framework — apps van derden mogen niet stilletjes andere processen afsluiten, dus alles wat zichzelf een blocker noemt op een iPhone is in feite gewoon een schil om dezelfde App-limieten en Communicatielimieten die Apple al standaard levert. Op Android is het besturingssysteem toegeeflijker: een app kan Accessibility Service- of Usage Access-machtigingen aanvragen en die gebruiken om te detecteren wanneer een geblokkeerde app naar de voorgrond komt, en die direct met een eigen scherm te bedekken. Het mechanisme verschilt per platform, maar het doel is identiek — het openen onderscheppen en bepalen wat er vervolgens gebeurt.

De twee mechanismen, en waarom ze zich anders gedragen

Op iOS werkt een blocker van een derde partij doorgaans door Family Controls-/Screen Time-autorisatie aan te vragen, waarmee hij via Apples ManagedSettings-framework een lijst apps als "beperkt" kan registreren. Wanneer je op een beperkte app tikt, onderschept iOS zelf — niet de app van de derde partij — het opstarten en toont een Screen Time-blokkeerscherm, omdat de externe ontwikkelaar nooit daadwerkelijk toegang heeft tot de gegevens of processen van je andere apps; hij kan het besturingssysteem alleen vragen ze te markeren. Dit verklaart ook waarom iOS-blockers relatief op elkaar lijken in hoe ze zich gedragen: het zijn allemaal schillen om hetzelfde onderliggende systeem. Op Android gebruikt een blocker doorgaans de Accessibility Service API (bedoeld voor schermlezers) of de Usage Stats API om te volgen welke app op de voorgrond staat, en zodra hij een geblokkeerde pakketnaam detecteert, tekent hij daar een overlay overheen voordat je met de app eronder kunt interacteren. Dat geeft Android-blockers meer flexibiliteit — rijkere overlays, aangepaste ontgrendelstromen zoals een quiz — maar ook meer kwetsbaarheid, omdat toegankelijkheidsmachtigingen in Instellingen ingetrokken kunnen worden door dezelfde persoon die de blocker juist moet tegenhouden. Deze scheiding verklaart ook een veelgehoorde klacht specifiek over iOS-blockers — dat veel ervan op elkaar lijken en hetzelfde aanvoelen ondanks dat ze door verschillende bedrijven gemaakt zijn — omdat ze allemaal beperkt worden door dezelfde smalle set aanknopingspunten die Apple blootgeeft, in plaats van dat elk een werkelijk onafhankelijk blokkeermechanisme vanaf nul bouwt.

Wat écht bepaalt of een blokkade standhoudt

De kracht van elke app-blocker komt neer op één vraag: wie bedient de uitschakelaar? Een blocker die volledig binnen hetzelfde account draait als de persoon die hij blokkeert — geen aparte toegangscode, geen tweede toestel, niemand anders die de sleutel in handen heeft — is mechanisch altijd omkeerbaar door diezelfde persoon, omdat het besturingssysteem wel moet toestaan dat de instellingen van een app worden gewijzigd door wie de telefoon op dat moment gebruikt. Apples Screen Time is daar het duidelijkste voorbeeld van: zonder aparte Screen Time-toegangscode ingesteld, kunnen App-limieten in Instellingen binnen dertig seconden worden uitgezet door dezelfde persoon die ze zouden moeten beperken. Voeg een toegangscode toe die iemand anders beheert — de ouder/kind Family Sharing-opzet waar Screen Time om gebouwd is — en de mechanica verandert niet, maar wel wie de blokkade ongedaan kan maken, en dat is het volledige verschil tussen een beperking en een suggestie. Dit is ook waarom "hoe sterk is deze blocker" een enigszins misleidende vraag is; het framework onder de meeste blockers op een bepaald platform is grotendeels hetzelfde. Wat verschilt, is wat er staat tussen de blokkade en de tik die hem zou opheffen — niets, een aftelling, een getypte code, of iets dat echte inspanning vereist. Het is de moeite waard om duidelijk te zijn dat dit geen gebrek is dat specifiek is voor één app; het is een structurele eigenschap van elk hulpmiddel dat gebouwd is om te draaien op een toestel dat dezelfde persoon zowel bezit als probeert te beperken, wat geldt voor vrijwel elke consumenten-app-blocker op de markt, niet alleen de zwakkere.

Waar wrijving in het mechanisme past

Omdat het onderliggende blokkeer-of-niet-mechanisme grotendeels vastligt door het besturingssysteem, is de betekenisvolle ontwerpkeuze die de meeste blockers maken wat er gebeurt op het moment van ontgrendelen. Een op een timer gebaseerde ontgrendeling (vijf minuten wachten) voegt vertraging toe maar geen inspanning. Een ontgrendeling met een getypte code (een code ophalen van een ander toestel) voegt een kleine logistieke horde toe. Een ontgrendeling die cognitieve inspanning vereist — een echte vraag beantwoorden, een setje push-ups doen dat door de bewegingssensor van de telefoon wordt geverifieerd — voegt iets toe dat dichter bij het ongemak van de taak zelf ligt die je probeert te vermijden, wat een wezenlijk ander soort wrijving is dan simpelweg wachten. Niets hiervan verandert of de onderliggende OS-machtiging technisch ingetrokken kan worden; het verandert hoeveel de persoon die intrekt het op dat specifieke moment moet willen, wat gedragsonderzoekers die compulsief telefoongebruik bestuderen (in de academische literatuur soms "problematisch smartphonegebruik" genoemd, aangezien er geen formele DSM-5-diagnose voor telefoonverslaving bestaat) doorgaans als de relevantere hendel beschouwen dan pure beperkingskracht, omdat wilskracht schommelt maar een consequente kostprijs dat niet doet. Het is ook de moeite waard om te vermelden dat wrijving en harde technische beperking geen concurrerende benaderingen zijn, maar eerder ergens op een spectrum liggen — een geplande Downtime zonder toegangscode is zwak op beide assen, een met een toegangscode beveiligde limiet is sterk op de technische as maar biedt geen wrijving als de code bekend is, en een quizgebaseerde ontgrendeling is relatief zwak op de technische as (niets weerhoudt je ervan de app volledig te verwijderen) maar sterk in het vereisen van actieve, moeizame betrokkenheid op precies het moment dat ertoe doet.

Waar Mr. Grummel in past

Mr. Grummel gebruikt de op inspanning gebaseerde versie van dit mechanisme: in plaats van een timer of een getypte code, betekent langs een blokkade komen een echte quizvraag correct beantwoorden. Het probeert geen hardere technische vergrendeling te zijn dan het besturingssysteem toestaat — geen enkele app is dat volledig, zonder dat een tweede persoon een toegangscode beheert — het is ontworpen om de cognitieve kosten te verhogen van het moment waarop je er anders zo doorheen zou tikken. Die ontwerpkeuze weerspiegelt een specifieke gok: dat het probleem voor de meeste mensen, de meeste tijd, niet is dat er een technisch onbreekbaar slot nodig is, maar dat een kosteloze overschrijving te makkelijk binnen handbereik ligt.