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ć.

Raspberry Pi niemal read only

W końcu padła kolejna karta microSD. Tym razem jakaś chińszczyzna, kupiona wieki temu na Aliexpress. Działała długo. Nie pamiętam od kiedy, ale chyba parę lat. Znaczy się, problemy miała wcześniej, ale nie miałem czasu się tym zająć i jakoś działało. Chodzi oczywiście o Raspberry Pi robiące za router GSM.

O tym, że nie jest z nią dobrze wiedziałem. Przy instalacji nowych pakietów miała narowy i leciały jakieś błędy. Za pierwszym razem ograniczyłem zapisy na kartę – wyłączyłem bieda statystyki w postaci logowania ilości przesłanych danych. Mogłem wyłączyć więcej logów oraz swap, ale nie wpadłem na to. Zresztą, działało.

A teraz pewnego dnia zniknął internet, akurat gdy pracowałem. Oczywiście udostępniłem sobie net z komórki, ale zrobiłem szybką diagnostykę. W logach czysto, w dmesg czysto, uptime 240 dni. Reboot i… nadal nie działało. Za to chwilę po reboocie przy zwykłym działaniu pojawiły się błędy odczytu. Uznałem, że wina karty.

Chyba niesłusznie i była to po prostu awaria a2mobile, bo po przełożeniu modemu do innego komputera netu także nie było.

Tu mała dygresja odnośnie operatorów. Zmigrowałem z Aero2 na a2mobile i tak to sobie działa. Przy okazji – można odzyskać kaucję za kartę, którą pobierało Aero2. Nie trzeba odsyłać karty, nie trzeba podawać numeru ani wypełniać druku – wystarczy napisać email, tak jak to opisano na Pepper. W mniej niż tydzień pieniądze z depozytu miałem na koncie.

Tak w ogóle to widzę, że w Aero2 mają nowe pakiety i może niepotrzebnie rezygnowałem. Bo teraz w Aero2 dają 10 GB za 10 zł bez limitu prędkości. Z kolei obecne a2mobile nadal daje za 12,9 zł 5 GB bez limitu prędkości, kolejne 5 GB z limitem 3 Mbps (modem 3G, więc nie robi to dramatycznej różnicy i spokojnie da się działać), kolejne 5 z limitem 1 Mbps (no tu jest wolno już), a potem 512 kbps. W praktyce pewnie zwykle mieściłbym się w 10 GB, a lepiej dopłacić 10 zł za kolejny pakiet przy tych rzadkich okazjach, kiedy potrzeba będzie więcej transferu. Hmm…

No ale skoro karta ewidentnie pada, to pora na wymianę. Czasu mało, więc zamawiać nie będę, szybka wizyta w sklepie, kupiłem jakiś dziwny wynalazek 32GB za 20 zł. Karta microSD z napisem full HD na opakowaniu. Przy okazji zauważyłem, że bardzo stary Raspbian się tam ostał – jeszcze oparty na bullseye. Zastanawiałem się przez chwilę, czy nie instalować nowego Raspbiana (oparty na bookworm), ale o ile backup obrazu karty miałem, o tyle plików nie. Oczywiście mogłem podmontować i zgrać pliki, ale stwierdziłem, że więcej będzie roboty z szukaniem ich wszystkich, niż z aktualizacją Raspbiana.

No i w sumie miałem rację – aktualizacja była bezproblemowa. Przy okazji wyłączyłem logi, wyłączyłem swap, zrobiłem lekki tuning pamięci, ustawiając minimalną możliwą dla karty graficznej (16 MB zamiast domyślnych 64 MB). No i zobaczymy, ile podziała teraz. Oczywiście mam świeży backup, znowu w postaci obrazu karty.

Przy okazji, trafiłem na ciekawy opis, jak zrobić w Raspberry Pi kartę w trybie read only przy pomocy overlayFS. Spróbowałem i… niestety nie działa, choć raspi-config twierdzi, że przełączył. Nie tylko u mnie, widziałem podobne opisy na forach – na 64bit niby działa, na 32bit – nie. A moje RPi to 1B, więc nie mogę 64bit użyć. Na dokładniejszy debug nie starczyło już czasu, może następnym razem się uda…