Mastodon a blokowanie

Mastodon chwali się, że daje możliwość kontroli widoczności. Na poziomie użytkownika posiada do tego celu dwie zbliżone opcje. Pierwsza z nich to mute, czyli wyciszenie, które, cytując komunikaty pojawiające się przy blokowaniu:

They won’t know they’ve been muted.
They can still see your posts, but you won’t see theirs.
You won’t see posts that mention them.
They can mention and follow you, but you won’t see them.

Druga z nich to block, która jest opisana jako:

They can see that they’re blocked.
They can’t see your posts and you won’t see theirs.
You won’t see posts that mention them.
They can’t mention or follow you.

Czyli w obu przypadkach nie widzimy postów w których jest wymieniane (mention) dane konto. Ma to nieco sensu, ale wykorzystując którąkolwiek z możliwości, zepsujemy sobie dostęp do treści. I to nie tylko pisanych przez zablokowane konto, ale także znikną nam wszystkie wiadomości w wątkach, w których jest wymienione to konto, niezależnie od tego, kto je napisał. Dość inwazyjne, zwłaszcza, że ludzie często zostawiają w wątkach wszystkie dotychczas wywołane osoby.

Jeśli chodzi o block, to osoba zablokowana widzi, że jest zablokowana. Przynajmniej teoretycznie, bo co prawda taka informacja jest dostępna (w API), ale nie ma żadnego miejsca, gdzie możemy sprawdzić jakie konta nas zablokowały. Nie dostajemy też informacji o blokowaniu. Co w praktyce możemy zauważyć? Zepsute wątki, zwłaszcza brakujące wiadomości. Choć wtedy może to wynikać także z wyciszenia przez nas innej wywołanej osoby, poprzez mute. Najlepszą metodą bez sięgania po API jest sprawdzenie, czy mamy możliwość obserwacji danego konta. Brak możliwości włączenia obserwacji danego konta – opcja niekatywna – oznacza, że zostaliśmy zablokowani.

Jeśli chodzi o they can’t mention to… nie działa. Jak najbardziej można zamieścić toot zawierający oznaczenie konta, które nas blokuje. Serwer podpowiada nicka i obsługuje go normalniew toocie. Zapewne wywołana osoba nie dowie się, że została oznaczona, ale to nie znaczy, że oznaczenie nie została. Co więcej, wszyscy inni użytkownicy będą widzieli to oznaczenie. Nie wiem jaki był zamysł autorów, ale wygląda na obietnicę bez pokrycia. Podobnie jak they can see that they’re blocked. Niby można się dokopać, ale czy widać? Polemizowałbym.

Jeśli chodzi o they can’t see your posts, to nie do końca jest to dowiezione. Zadziała tylko, jeśli mamy ograniczoną widoczność własnych tootów do zalogowanych kont. Co raczej nie jest popularnym ustawieniem. W przeciwnym razie wystarczy, że oni skorzystają z okna przeglądarki w trybie prywatnym.

Podsumowując, mam wrażenie, że z poziomu użytkownika blokowanie/wyciszanie na Mastodonie zrobione jest słabo. Skomplikowane (dwie różne metody), nie do końca działające zgodnie z opisem, za to bardzo inwazyjne. Wygląda, jakby ktoś projektując rozwiązanie mocno skupił się na aspektach technicznych, zapominając o „dużym obrazie” i skutkach. W efekcie użytkownicy nie dostają więcej niż na innych platformach, za to cierpi używalność platformy.

Wpis przeleżał nieco w szkicach, więc nadeszła pora na publikację…

Głodny wilk

We wpisie o optymalizacji strony pisałem tym, że wilk może być syty, i owca cała. Czyli, w kontekście reklam AdSense, można mieć reklamy i nie mieć reklam. Zarabiać i nie psuć strony wolnymi reklamami.

Dawno temu pisałem co prawda, że wyłączyłem reklamy AdSense. Przynajmniej na podstawowym blogu. Jednak było zgromadzone sporo środków, ale poniżej progu wypłaty. Co skłoniło mnie do salomonowego rozwiązania – włączenia reklam na wybranych stronach. Dokładnie na tych, które mają najwięcej wejść z wyszukiwarki.

Uznałem rozwiązanie za mało inwazyjne z jednej strony, a z drugiej okazało się zaskakująco dochodowe. To nawet nie było słynne 80/20, to bardziej 95/5. Znaczy się kilka(naście) najpopularniejszych stron robiło praktycznie cały dochód. A skoro nie widać różnicy, to po co spowalniać resztę? Brak inwazyjności objawił się także względnie dopasowanymi reklamami. Może nie były tematyczne, ale gdy zerknąłem parę razy, widziałem reklamy po polsku, bez paramedycznych itp. Raczej duże sklepy itp. Czyli jakby znośnie.

Gdybym był zwolennikiem teorii spiskowych stwierdziłbym, że Google specjalnie zwiększa dochód po włączeniu reklam, a potem steruje tak, żeby się wyświetlały, ale żeby jak najdłużej nie można było wypłacić środków. Bo wykres przychodów z reklam AdSense w czasie wygląda tak:

wykres zarobków AdSense w latach 2023-2025. widoczny wyraźny trend spadkowy
Zarobki AdSense, 2023-2025

Nie trzeba doktoratu ze statystyki, żeby zobaczyć, że zarobki spadają. Systematycznie. I to pewnie mimo dodania reklam na jednej czy dwóch popularnych wpisach w tzw. międzyczasie. Próg wypłaty środków znowu jest blisko ale… jakoś ciągle jest to „za parę miesięcy”. Od paru miesięcy. Czyli ewidentne gotowanie żaby. Czy też bardziej: głodzenie wilka.

Dla jasności, mimo pewnych chwilowych aberracji w pozycji, ilości wejść i odsłon, jest stabilnie. Nic się istotnie nie zmienia – ani ilość wejść, ani pozycja. W panelu AdSense też niby wszystko na zielono. A może to globalny trend?

Cóż, skoro tak to ma wyglądać, to jednak nie będzie połowicznego rozwiązania, tylko reklamy AdSense wylecą. Tym razem zupełnie i na dobre. Ale najpierw chcę uzbierać do progu wypłaty…

Zamiast tego[1] uruchomiłem możliwość postawienia kawy. Zupełnie nieinwazyjne, całkowicie dobrowolne. Czy działa? Za wcześnie, by wnioskować. No ale bez złudzeń, przy blogach tego typu raczej sprawdziłyby się mikropłatności, coś w stylu tego, co próbował kiedyś wdrożyć Brave.

To, co mi jeszcze chodzi po głowie to jakaś sieć, która wyświetla „reklamy” non-profit. Społeczne, jakiś open source itp. I czasami, rzadko, tak 1:20 reklamy stron, które należą do sieci. Znacie coś takiego? A może to pomysł na biznes/startup?

[1] W sumie to nie do końca zamiast, bo trochę szerzej i trochę inna motywacja. Więc to „zamiast” to tylko w kontekście „jest blog i są pieniądze”.

Potwierdź mój wiek, anonimowo

Pojawiło się zagadnienie weryfikacji wieku przyjaznego dla prywatności czyli anonimowej weryfikacji wieku. Czyli mamy serwis X, który chce potwierdzić, że użytkownik ma 18 lat, ale jednocześnie ma otrzymać możliwie mało danych na temat tego użytkownika. Idealnie: tylko wiek.

Rysiek zaproponował rozwiązanie, które zaintrygowało mnie na tyle, że postanowiłem przeanalizować, czy to ma szansę działać. Wyszło mi, że nie. W tym wpisie skupiam się wyłącznie na proponowanym opisie algorytmu, czyli punktach i akapicie w którym jest zawarty.

Podsumowując założenia, ma tam być tak, że jest serwis X, użytkownik U, oraz serwis potwierdzania identyfikacji EID. X ma nie wiedzieć, kim jest U (dane osobowe). EID jak najbardziej zna dane osobowe użytkownika U, ma potwierdzić wiek, ale ma nie wiedzieć, że potwierdzenie jest na potrzeby serwisu X.

Problemy, które tu widzę, są dwa. Pierwszy jest taki, że użytkownik U w pełni kontroluje komunikację pomiędzy X a EID. Najpierw wysyła dane (które może dowolnie ustalić przed wysłaniem), potem otrzymuje odpowiedź, którą przekazuje. Czyli mamy do czynienia z man in the middle. Nie byłoby tu wielkiego problemu, gdyby EID wiedziało, że rozmawia z X – wystarczyłoby wtedy użyć odpowiednich kluczy prywatnych i publicznych. Ale jest to sprzeczne z założeniami.

Drugi problem jest poważniejszy. Serwis X nie wie, jakiego użytkownika weryfikuje. W tej sytuacji dowolny „dowód osobisty” może posłużyć do weryfikacji użytkownika.

Przekładając to na bardziej tradycyjne okoliczności: osoba w kominiarce przychodzi kupić alkohol i w ramach weryfikacji wieku pokazuje na ekranie telefonu zdjęcie dowodu osobistego. Czy sprzedawca jest w stanie zweryfikować wiek osoby na tej podstawie? Wg mnie – nie bardzo. Zdjęcie na ekranie to tutaj odpowiednik MITM (nie wiemy nawet, czy dowód jest autentyczny). Natomiast kominiarka (ukrycie tożsamości, anonimowość) uniemożliwia sprawdzenie, czy dowód należy do danej osoby.

Czyli dokładanie kolejnych warstw, algorytmów, systemów, stron w komunikacji nie zwiększa nam tu pewności anonimowej weryfikacji wieku. Nie w stosunku do wybrania przez użytkownika na stronie opcji „potwierdzam, że mam 18 lat”.

Być może po prostu mamy problem z akceptacją faktu, że weryfikacja wieku nigdy nie była anonimowa? Bo sprzedawca w sklepie z alkoholem nie tylko sprawdza[1], czy osoba posiada dowód osobisty. Sprawdza też, czy jest on autentyczny. I czy należy do tej osoby. OK, do tego ostatniego nie potrzebuje tu kompletu danych z dowodu, wystarczy zdjęcie. Ale do pozostałych danych ma dostęp w trakcie sprawdzania autentyczności.

Na Mastodonie trwa dyskusja, pewnie warto zapoznać się z całością, a komentować czy sugerować działające rozwiązania można równie dobrze tam.

[1] A przynajmniej powinien to robić.