Jak działają blokady aplikacji?

Blokada aplikacji działa, siadając między tobą a aplikacją, którą próbujesz otworzyć, i wykorzystuje dowolny dostęp, jaki przyznaje jej system operacyjny, by albo uniemożliwić jej uruchomienie, albo sprawić, że coś to uruchomienie kosztuje. Na iOS ten dostęp pochodzi niemal wyłącznie z własnego frameworku Apple, Screen Time — aplikacje zewnętrzne nie mogą po cichu zabijać innych procesów, więc cokolwiek nazywa siebie blokadą na iPhonie, jest w rzeczywistości tylko nakładką na te same App Limits i Communication Limits, które Apple już dostarcza. Na Androidzie system jest bardziej liberalny: aplikacja może poprosić o uprawnienia Accessibility Service lub Usage Access i wykorzystać je, by wykryć, kiedy zablokowana aplikacja trafia na pierwszy plan, i natychmiast przykryć ją własnym ekranem. Mechanizm różni się między platformami, ale cel jest identyczny — przechwycić otwarcie i zdecydować, co dzieje się dalej.

Dwa mechanizmy i dlaczego zachowują się inaczej

Na iOS blokada zewnętrzna zwykle działa, prosząc o autoryzację Family Controls / Screen Time, co pozwala jej zarejestrować listę aplikacji jako „ograniczone” za pomocą frameworku Apple ManagedSettings. Gdy stukasz w ograniczoną aplikację, to sam iOS — nie aplikacja zewnętrzna — przechwytuje uruchomienie i pokazuje ekran blokady Screen Time, ponieważ deweloper zewnętrzny w rzeczywistości nigdy nie ma dostępu do danych ani procesów twoich innych aplikacji; może jedynie poprosić system, by je oznaczył. To także powód, dla którego blokady na iOS zachowują się względem siebie stosunkowo spójnie: wszystkie są nakładkami na ten sam, leżący u podstaw system. Na Androidzie blokada zwykle korzysta z API Accessibility Service (zaprojektowanego dla czytników ekranu) lub API Usage Stats, by obserwować, która aplikacja jest na pierwszym planie, a gdy wykryje zablokowaną nazwę pakietu, rysuje nad nią nakładkę, zanim zdążysz wejść w interakcję z aplikacją pod spodem. Daje to blokadom na Androidzie więcej elastyczności — bogatsze nakładki, niestandardowe procesy odblokowania w rodzaju quizu — ale też większą kruchość, ponieważ uprawnienia dostępności można cofnąć w Ustawieniach, i to ta sama osoba, którą blokada ma powstrzymywać, może to zrobić. Ten podział tłumaczy też częstą skargę dotyczącą konkretnie blokad na iOS — że wiele z nich wygląda i działa podobnie do siebie mimo tworzenia przez różne firmy — ponieważ wszystkie są ograniczone tym samym, wąskim zestawem haczyków, jakie udostępnia Apple, zamiast budować każda od zera naprawdę niezależny mechanizm blokowania.

Co naprawdę decyduje o tym, czy blokada się utrzyma

Siła każdej blokady aplikacji sprowadza się do jednego pytania: kto kontroluje wyłącznik? Blokada, która istnieje wyłącznie na tym samym koncie co osoba, którą blokuje — bez osobnego kodu, bez drugiego urządzenia, bez żadnej innej osoby trzymającej klucz — jest mechanicznie zawsze odwracalna przez tę samą osobę, ponieważ system musi pozwolić, by ustawienia własnej aplikacji zmieniał ktokolwiek aktualnie korzysta z telefonu. Screen Time od Apple jest tego najczystszą ilustracją: ustawiony bez osobnego kodu Screen Time, App Limits można wyłączyć w Ustawieniach w mniej niż trzydzieści sekund — zrobi to ta sama osoba, którą miały ograniczać. Dodaj kod, który trzyma inna osoba — konfiguracja rodzic/dziecko w Family Sharing, wokół której Screen Time jest zbudowany — a mechanika się nie zmienia, ale zmienia się strona, która może cofnąć blokadę, i to jest cała różnica między ograniczeniem a sugestią. To też powód, dla którego pytanie „jak silna jest ta blokada” jest nieco mylące; framework leżący u podstaw większości blokad na danej platformie jest w dużej mierze taki sam. Różni się to, co stoi między blokadą a stuknięciem, które by ją zdjęło — nic, odliczanie, wpisany kod albo coś, co wymaga realnego wysiłku. Warto jasno powiedzieć, że to nie jest wada charakterystyczna dla jednej konkretnej aplikacji; to strukturalna właściwość każdego narzędzia zbudowanego, by działać na urządzeniu, które ta sama osoba zarówno posiada, jak i próbuje sobie ograniczyć — a to dotyczy praktycznie każdej konsumenckiej blokady aplikacji na rynku, nie tylko tych słabszych.

Gdzie w tym mechanizmie mieści się tarcie

Ponieważ leżący u podstaw mechanizm blokowania (albo jego braku) jest w dużej mierze narzucony przez system, znaczący wybór projektowy, jakiego dokonuje większość blokad, dotyczy tego, co dzieje się w momencie odblokowania. Odblokowanie oparte na timerze (poczekaj pięć minut) dodaje opóźnienie, ale żadnego wysiłku. Odblokowanie wpisywanym kodem (pobierz kod z innego urządzenia) dodaje niewielką przeszkodę logistyczną. Odblokowanie wymagające wysiłku poznawczego — odpowiedź na prawdziwe pytanie, wykonanie serii pompek zweryfikowanej przez czujnik ruchu telefonu — dodaje coś bliższego dyskomfortowi samego zadania, którego pierwotnie unikasz, a to jakościowo inny rodzaj tarcia niż zwykłe czekanie. Żadne z tych rozwiązań nie zmienia tego, czy leżące u podstaw uprawnienie systemowe da się technicznie cofnąć; zmieniają one to, jak bardzo osoba to cofająca musi tego chcieć w danym konkretnym momencie — co badacze zachowań badający kompulsywne korzystanie z telefonu (w literaturze naukowej czasem nazywane „problematycznym korzystaniem ze smartfona”, ponieważ nie istnieje formalna diagnoza uzależnienia od telefonu w DSM-5) generalnie traktują jako bardziej istotną dźwignię niż surowa siła ograniczenia, ponieważ siła woli się waha, a spójny koszt — nie. Warto też zauważyć, że tarcie i twarde ograniczenie techniczne nie są konkurencyjnymi podejściami tak bardzo, jak raczej punktami na jednym spektrum — zaplanowany Downtime bez kodu jest słaby na obu osiach, limit chroniony kodem jest silny na osi technicznej, ale nie daje żadnego tarcia, jeśli kod jest znany, a odblokowanie oparte na quizie jest porównywalnie słabe na osi technicznej (nic nie powstrzymuje przed całkowitym odinstalowaniem aplikacji), ale silne w wymaganiu aktywnego, wysiłkowego zaangażowania dokładnie w tym momencie, który ma znaczenie.

Gdzie w tym wszystkim jest Mr. Grummel

Mr. Grummel wykorzystuje wysiłkową wersję tego mechanizmu: zamiast timera czy wpisywanego kodu, przejście przez blokadę oznacza poprawną odpowiedź na prawdziwe pytanie quizowe. Nie próbuje być twardszą blokadą techniczną, niż pozwala na to system — żadna aplikacja w pełni taką nie jest, bez drugiej osoby trzymającej kod — jest zaprojektowany tak, by podnieść koszt poznawczy momentu, w którym inaczej po prostu stuknąłbyś przez to na wprost. Ten wybór projektowy odzwierciedla konkretny zakład: że dla większości ludzi, przez większość czasu, problemem nie jest potrzeba technicznie niemożliwej do złamania blokady, tylko to, że bezkosztowe obejście jest zbyt łatwo dostępne.