Mastodon backup

Kolejna w stosunkowo krótkim czasie, ale dość długa awaria jednego z liczniejszych serwerów Mastodon w Polsce, pol.social, dała okazję do bliższego przyjrzenia się możliwościom backupu. Okazało się, że ludzie się przenoszą na inne serwery i… nie jest to takie proste, szczególnie, gdy dotychczasowy serwer nie działa.

W normalnych warunkach migracja na Mastodonie polega na wskazaniu nowego miejsca, gdzie ma znaleźć się konto. Przenoszeni są m.in. obserwowani, obserwujący, ale treści (tooty, czyli dopowiednik postów) zostają na starym serwerze. Nie ma możliwości przeniesienia treści na nowy serwer, przynajmniej oficjalnej. Zresztą byłoby to trudne, bo wszystkie istniejące odnośniki do niej, wątki, i tak przestaną działać. Kwestia niezbyt szczęśliwego projektu protokołu.

Istnieje nieoficjalne rozwiązanie slurp, które zostało zaprojektowane do działania z GoToSocial. Jeden serwerów ActivityPub, raczej pomyślany o małych, samodzielnie utrzymywanych instancjach. Polega na umieszczeniu starych tootów na serwerze z oryginalnymi datami. Wątki i odnośniki nadal przestają działać, jeśli serwer na którym były umieszczane zostanie wyłączony. Jednak można mieć przynajmniej swoje wpisy w formie „ciągłej”, razem z nowymi, które będą już pełnoprawne. Nie jest to rozwiązanie idealne, ale lepsze, niż nic.

Mastodon pozwala na wykonanie pełnej kopii, eksportu danych, raz na siedem dni:

You can request an archive of your posts and uploaded media. The exported data will be in the ActivityPub format, readable by any compliant software. You can request an archive every 7 days.

Niezależnie od tego, można – czy może bardziej: trzeba – pobierać formacie CSV dodatkowe ustawienia swojego profilu, np. obserwowanych, banowanych, bookmarki czy blokowane domeny. Trzeba, bo tych danych nie ma w tworzonym archiwum. A szkoda.

Zrobiłem prosty skrypt, który – nie wymagając logowania w przypadku publicznej widoczności – wyświetla obserwowanych. Wg mnie to najważniejsza, najtrudniej odtwarzalna informacja, poza samą treścią. Można go użyć np. w trakcie robienia backupu danych, jako jednego z elementów wykonywanych przez skrypty do backupu.

Włączyłem tworzenie archiwum i… po 20 minutach nadal wyświetlał informację, że tworzy archiwum. Przynajmniej tak pokazywała strona, bo po odświeżeniu strony jednak pojawił się gotowy do pobrania plik. Zapewne był już wcześniej, tylko błąd w Mastodon powoduje, że nie ma informacji o zakończeniu tworzenia.

Sam plik zawiera kilka plików JSON oraz drzewo katalogów z grafikami. W samych grafikach trudno się zorientować – tytuły plików i struktura katalogów nie są w formacie czytelnym dla człowieka.

Fun fact: archiwum pobrałem głównie po to, żeby łatwo móc przeszukiwać treść swoich postów. Wyszukiwarka na Mastodonie jest i niby działa, ale jednak wygodniej mi korzystać z grep w wierszu poleceń.

Postaw kawę

Przy pewnej okazji dostałem pytanie, czy korzystam z jakiegoś rozwiązania, gdzie można postawić mi wirtualną kawę. Pytający w przykładzie użył serwisu buycoffee.to. Nie miałem nic takiego. Kiedyś myślałem o Patronite, ale jakoś nie czułem, bym zasługiwał. Zerknąłem na buycoffee.to i stwierdziłem, że założę konto. Po pierwsze, kojarzyłem logo, po drugie, jest to ładnie umocowane legalnie i ma proste zasady, do tego jakoś tak przejrzyście opisane. Last but not least – firma jest z okolic Poznania.

Nadal uważam, że blog pewnie nie zaowocuje wpłatami, ale… robię jeszcze parę rzeczy (kapela, jakieś prezentacje, jakiś open source), więc niech sobie będzie, może komuś się działalność spodoba, uzna za ją za wartościową i zechce postawić kawę. Tym bardziej, że konto w serwisie nie kosztuje, a darowizny korzystnie się rozlicza. Może nie prosto, od strony obdarowywanego, bo trzeba pilnować ostatnich sześciu lat per darczyńca, ale w praktyce nie płaci się podatku. Zresztą, eksport do arkusza, tabela przestawna i gotowe. Gdyby kogoś temat interesował, to dają dobry artykuł nt. rozliczania darowizn.

Nie jest tak, że serwis od darowizn jest za darmo. Pobierają dwie opłaty – 2,5% kosztu transakcyjnego oraz 7,5% opłaty serwisowej. Patronite byłby nieco tańszy, ale różnica jest pomijalna. Ta opłata serwisowa wydaje mi się dość spora, jeśli ktoś ma większe obroty. Mogła by być górna kwota opłat, powyżej której opłata serwisowa nie jest pobierana. W sumie ciekawe czy nie właśnie dlatego Radio 357 zaczęło przyjmować wpłaty na własną rękę?

Zatem, po krótkiej walce z WordPressem[1], w paru miejscach (strona główna, sidebar na blogu) pojawiło się logo serwisu buycoffee.to, prowadzące do miejsca, gdzie można postawić wirtualną kawę. I zapewne zostanie tam na dłużej w ramach eksperymentu. Tym bardziej, że zamierzam wkrótce definitywnie i całkowicie rozstać się z reklamami Google AdSense. Ale o tym będzie już w innym wpisie…

[1] Dodanie jest w skrajnie nieintuicyjnym miejscu. I w skrajnie nieintuicyjny sposób. W ogóle dziwna organizacja tego wszystkiego, a jeszcze mam WordPressa po polsku… W każdym razie skończyło się dodaniem kodu HTML w sidebar. Znaczy wygląd -> widżety.

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