Wolne social media

Za sprawą zbanowania Donalda Trumpa na Twitterze głośno zrobiło się w temacie wolności wypowiedzi w social media. Także odnośnie braku regulacji prawnych dotyczących social media i centralizacji usług. Zaczęły powstawać „wolne” alternatywy. Ponieważ zdarzyło mi się już tłumaczyć w paru miejscach moje stanowisko, pora na wpis.

Źródło: wygenerowane za pomocą https://thumbnail.ai/

Problem

W czym w ogóle problem? Przecież nigdy nie było tak, że każdy może skorzystać ze środków masowego przekazu. O treściach zamieszczanych w prasie decydował redaktor, podobnie w przypadku telewizji czy radio. Każdy mógł zadzwonić, ale na antenę nie dostawał się każdy. Dodatkowo obszar był uregulowany przez prawo prasowe. Choćby prawo do zamieszczenia sprostowania. I polemiki ze sprostowaniem. Nawet jeśli była np. w zakładzie pracy gablota na ogłoszenia, to miała ona właściciela. I mógł on nieodpowiadające mu treści po prostu usunąć. Albo zamknąć ją na kluczyk.

Sytuacja się zmieniła. Nie mamy już typowego broadcastingu, gdzie pojedyncza osoba rozgłasza treści, czyli jest nadawcą, a pozostali są odbiorcami. Obecny model zdemokratyzował bycie nadawcą. Każdy może publikować treści, które są dostępne dla wszystkich. Ale nie to jest najważniejszą zmianą. Już wcześniej każdy mógł uruchomić swoje radio, czasopismo czy postawić własną gablotę z ogłoszeniami. Oczywiście o ile miał odpowiednie środki i kompetencje. Pieniądze i znajomość prawa, powiedzmy.

Najważniejsze zmianą jest coś innego. W sumie nie zmianą, a zmianami. Po pierwsze, social media sprawiły, że publikacja treści dla wszystkich nie wymaga istotnych nakładów ze strony nadawcy. Nie są potrzebne ani specjalne środki, ani kompetencje, by zacząć przekaz do wszystkich w kraju i na świecie. O ile będą chętni, by nas słuchać.

Prawa człowieka

Po drugie i najważniejsze, ten sposób komunikacji stał się powszechny i dominujący. Odebranie komuś możliwości publikowania poglądów w ten sposób jest pewnego rodzaju wykluczeniem społecznym. Trochę tak, jakby kiedyś zabronić komuś rozmawiać w szkole czy zakładzie pracy. Dotyczy to zarówno w życia prywatnego, jak i – w niektórych przypadkach – zawodowego. W przypadku niektórych istotna część życia zawodowego toczy się na Linkedin czy GitHub[1] . Wyobrażacie sobie rekrutera pracującego w branży IT z wykluczonym korzystaniem z Linkedin? Ja nie.

Dlatego coraz częściej pojawiają się głosy, że prawo do internetu to podstawowe prawo człowieka. W badaniu w roku 2010 77% ankietowanych spośród 27 tys. osób z 26 krajów Europy określiło, dostęp do internetu jako podstawowe prawo człowieka[2]. Wydaje mi się, że można w tym momencie utożsamić internet z social media.

Centralizacja i struktura serwisów social media

Oba przytoczone wyżej serwisy są centralne. Podobnie jak Twitter czy Facebook. W tym momencie pojawia się pytanie o wolność i regulacje prawne. W kontekście wolności słowa i prawa człowieka. Aby dokładniej zobaczyć w czym problem, trzeba przeanalizować strukturę władzy w serwisach social media. Typowo wygląda ona następująco:

  1. Właściciel serwisu – ten, który ma środki. Pieniądze, prawa do domeny, przetwarzania danych użytkowników itp.
  2. Dostawcy infrastruktury – podmioty zapewniające łączność i hosting. Firmy zewnętrzne, ale w większości przypadków niezbędne dla funkcjonowania.
  3. Administrator serwisu – osoba z wiedzą techniczną, umiejąca utrzymać serwis w działaniu. Zarządzanie infrastrukturą, konfiguracja oprogramowania. Może być po prostu pracownikiem na usługach właściciela.
  4. Moderatorzy serwisu – osoby mogące usuwać treści lub użytkowników. Niekoniecznie w kontekście całego serwisu, mogą zarządzać wydzieloną częścią (np. grupą na FB). Mogą być pracownikami na usługach właściciela lub rekrutować się z użytkowników.
  5. Użytkownicy – osoby korzystające z serwisu. Uczestnicy komunikacji. Nadawcy i odbiorcy treści.

Oczywiście funkcje mogą się łączyć. Istotny jest tu fakt, że każda instancja wyższa ma środki techniczne, by ograniczać w dowolny sposób wszystkie instancje niższe. Także eliminując zupełnie ich dostęp do serwisu.

Nawiasem, zagadnienie jest szersze. Temat nie dotyczy tylko typowych social media i tylko o ograniczanie dostępu. Gdy Google, Agora czy Wirtualna Polska mówi, że zamyka serwis to użytkownicy nie mają nic do powiedzenia. Nie muszą nawet dostać możliwości pobrania pełnych treści w formacie zdatnym do łatwego przetworzenia maszynowo. Podobnie z blokowaniem dostępu do serwisów, w szczególności do publikacji treści.

Centralizacja

Nie jest to temat nowy, dominująca rola gigantów social media została dostrzeżona już dawno. Pojawiły się rozwiązania alternatywne, oparte o fediwersum. Czyli osobne, niezależne serwisy, ale dające możliwość interakcji między użytkownikami różnych instancji.

Na pierwszy rzut oka fediwersum wydaje się to rozwiązaniem problemu centralizacji. Ale czy jest nim faktycznie? Uważam, że nie. Gwarancja wolności w tym przypadku opiera się na tym, że użytkownik może pójść na inną instancję. Albo, w skrajnym przypadku, uruchomić własną.

Niestety, uruchomienie własnej instancji leży poza kompetencjami większości użytkowników. Uruchomienie to kompetencje administratora, a istniejące rozwiązania wymagają specjalistycznej wiedzy. Nie są może trudne dla ludzi z IT, ale świat nie składa się ani wyłącznie, ani nawet w większości z ludzi z IT.

Co gorsza, nawet uruchomienie własnej instancji nie gwarantuje, że ludzie z innych będą mieli dostęp do naszych treści. Wymiana danych między instancjami jest bowiem opcjonalna, dobrowolna i może zostać zablokowana. Na wielu poziomach, od konfiguracji instancji, przez filtrowanie pakietów sieciowych. Oczywiście takie rozwiązanie zmniejsza centralizację, ale nie eliminuje źródła problemu.

Rozwiązanie

O rozwiązaniu problemu centralizacji możemy mówić, gdy dowolnych dwóch użytkowników, którzy wyrażą taką wolę, będzie się mogło komunikować ze sobą. Niezależnie od decyzji innych osób i przynależności do serwerów. Fediwersum takiej gwarancji niestety nie daje[3]. I nie znam rozwiązania, które coś takiego oferuje.

Technicznie widziałbym to jako oddanie pełnej decyzyjności o odbieranych informacjach w ręce użytkowników końcowych. Czyli protokół pozwalający na wymianę informacji ze wszystkimi, nie dopuszczający cenzurowania. I prosta aplikacja, zastępująca serwis, używalna dla zwykłych użytkowników, pozwalająca na korzystanie (subskrybcję tematów, tagów, użytkowników, nadawanie, odbieranie wiadomości) przy pomocy tego protokołu. Z możliwością filtrowania użytkowników, tagów, tematów zarządzaną na poziomie użytkownika.

Wydaje mi się, że blisko tego modelu – pomijając aspekt centralnych serwerów – byliśmy w czasach NNTP. Użytkownik miał swój czytnik, swoje subskrybcje i filtry. Pobierał co chciał, odsiewał co chciał. Korzystanie z czytnika nie było wiele trudniejsze, niż obsługa email. Oczywiście wtedy obsługa email nie była powszechna, a i UX aplikacji był inny.

Gdyby dołożyć do tego „niecenzurowalny”, rozproszony protokół wymiany danych, mielibyśmy coś, co wydaje mi się rozwiązaniem. Nie znam szczegółów rozwiązania, ale wydaje mi się, że IPFS miałby szanse spełnić te wymagania. Tym bardziej, że zdobywa popularność – wchodzi do przeglądarek, na przykład jest już oficjalnie w Brave.

[1] Tak, uważam GH za pewnego rodzaju social media. Nie typowe socjalne, bardziej techniczne, dla wąskiej grupy, ze specyficznym elementem socjalnym, ale nadal twór tego typu. Na zasadzie: zwykli ludzie pokazują fotki i komentują je, programiści pokazują kod, wysyłają pull requesty. Nie jest to oczywiście dokładna analogia.
[2] 50% odpowiedzi tak, kolejne 27% raczej tak.
[3] Widzę, że PeerTube jest częścią fediwersum. I wydaje mi się odporne na cenzurowanie. Może więc być tak, że problemem są implementacje. W każdym razie pisząc o fediwersum mam tu na myśli implementacje w stylu Diaspora, Mastodon, StatusNet.

Sprawdzanie DNS sinkhole

W poprzednim wpisie o phishingu w Polsce pisałem, że chcę zbadać jak wygląda adopcja listy hole.cert.pl wśród ISP do DNS sinkhole zapytań o domeny używane do phishingu. Odzew był mniejszy, niż się spodziewałem, ale coś udało się zrobić. Trochę się nauczyłem i może się to przydać także do względnie łatwego, samodzielnego sprawdzania np. cenzury w sieci, nie tylko w Polsce.

Wyniki

Jeśli kogoś interesują wyniki DNS sinkhole na podstawie hole.cert.pl wśród ISP, to znajdzie je w repo. Jak widać próbka jest mała, ale pewien trend daje się zauważyć. Nawet duzi ISP kablowi nie wykorzystują listy od CERT Polska. Na pewno – co oczywiste – wykorzystują ją sygnotariusze porozumienia. CERT trafnie zauważa, że lista może być wykorzystywana nie tylko na DNS operatorów, ale także na innych poziomach (Pi-hole, filtry AdBlock). Przypomnę jednak, że chodziło mi o sprawdzenie jaka jest adopcja listy na poziomie infrastruktury ISP. Czyli bez wymagania dodatkowych urządzeń czy działań po stronie użytkowników.

Pierwotny pomysł, czyli skrypty uruchamiane przez osoby trzecie w zasadzie ląduje w koszu. Wykorzystanie sond z projektu RIPE Atlas probe pozwala sprawdzić wszystko samodzielnie, bez angażowania innych ludzi. Wyniki się pokrywają, więc w repo zostawiłem zebrane ręcznie. Przy okazji widzę, że przy wynikach przydała by się data pomiaru. Do wyciągnięcia z commitów, ale lepsza byłaby podana jawnie.

RIPE Atlas probe

Dawno temu pisałem już o RIPE Atlas probe. Ogólnie są to małe pudełka dystrybuowane przez RIPE i uruchamiane przez ochotników (zarówno firmy jak i osoby fizyczne) w swoich sieciach na całym świecie. Pozwalają na wykonywanie pomiarów zlecanych przez panel RIPE. Istnieje też wersja programowa.

Użycie RIPE Atlas probe daje całkiem spore, zwłaszcza jeśli chodzi o zasięg pomiarów, możliwości ale… nie jest proste. Po pierwsze, trzeba mieć konto i kredyty. O ile założenie konta to moment, o tyle zebranie kredytów chwilę trwa – trzeba mieć uruchomioną sondę. No chyba, że dostaniemy je od kogoś, kto już je zgromadził (dziękuję!).

Po drugie, parametrów jest dużo i podobnie jak zwracane wyniki nie są do końca oczywiste. Np. w JSON szczegółowa odpowiedź jest zakodowana w base64, przez co początkowo uznałem (nie tylko ja…), że jej tam nie ma. Dekodowanie odpowiedzi DNS jest proste i opisane w dokumentacji, z przykładami w różnych językach. Niemniej, bariera wejście jest większa, niż się spodziewałem.

Sytuacji nie poprawiał fakt, że panel RIPE jest właśnie aktualizowany czy też przerabiany i nie wszystko wydaje się działać poprawnie. Np. wyszukiwania sond zwracają różne wyniki po API i przez stronę WWW.

RIPE Atlas Tools

Ostatecznie stanęło na tym, że korzystałem z API za pośrednictwem RIPE Atlas Tools. Do prototypowania i sprawdzeń ręcznych całkiem użyteczne. Nie jest to narzędzie idealne, na przykład status jest podawany numerycznie i… nie znalazłem opisu, który co oznacza. TBH szybciej było mi sprawdzić metodą porównania z wynikami z panelu. W każdym razie status connected to 1. Opis użycia w CLI:

Usage: ripe-atlas probe-search [-h] [--asn asn] [--asnv4 asnv4] [--asnv6 asnv6] [--prefix prefix] [--prefixv4 prefixv4] [--prefixv6 prefixv6]
[--location location | --center center | --country country] [--radius radius] [--tag tag] [--limit limit]
[--field {id,asn_v4,asn_v6,country,status,prefix_v4,prefix_v6,coordinates,is_public,description,address_v4,address_v6,is_anchor}]
[--aggregate-by {country,asn_v4,asn_v6,prefix_v4,prefix_v6}] [--all] [--max-per-aggregation max_per_aggregation] [--ids-only] [--status {0,1,2,3}]

Pora na parę przykładów użycia. W zasadzie wystarczają one do sprawdzenia jak z sieci danego ISP na określonym serwerze DNS jest resolvowana domena, czyli tego, co było przedmiotem projektu. Znalezienie aktywnych sond w sieci Orange (AS5617):

ripe-atlas probe-search --asn 5617 --country pl --ids-only --status 1

Sprawdzenie rozwiązywania domeny (tu: example.com) na wskazanym serwerze DNS (tu: 8.8.8.8) i sondzie (ID 1234):

ripe-atlas measure dns --query-argument example.com --from-probes 1234 --target 8.8.8.8

Powyższe zwróci w konsoli wynik w postaci już zdekodowanej. Dodatkowo będzie tam link do wyniku w panelu RIPE, który można pobrać w postaci JSON. Wtedy trzeba zdekodować odpowiedź DNS samodzielnie w sposób linkowany wyżej.

Na koniec wystarczy porównać, czy oczekiwany wynik jest taki sam, jak z serwera co do którego mamy pewność, że nie zmienia odpowiedzi i już wiemy, czy mamy do czynienia z DNS sinkhole. No prawie, bo domena może mieć np. zróżnicowane rozwiązywania nazwy na podstawie geolokalizacji. Można oczywiście sprawdzać większe ilości sond itp., ale do sprawdzania ew. cenzurowania stron lepsze mogą być zapytania HTTP – blokada bowiem może być na innym poziomie niż rozwiązywanie nazw domen.

Co dalej?

Ustalić adresy IP serwerów DNS przydzielanych klientom przez największych polskich ISP. Sądziłem, że będzie trywialne. Niestety myliłem się. Kiedyś można było bez problemu znaleźć je w sieci na stronach poszczególnych ISP. Teraz często nie chwalą się oni tą informacją. Np. nie udało mi się znaleźć tej informacji np. dla operatorów Vectra i Toya[1]. Tu liczę na pomoc czytelników w postaci podania nazwy ISP i przydzielonych przez niego adresów serwerów DNS.

Pełny automat. Powyższe przykłady są dobre do ręcznego wykorzystania. Mam wrażenie, że odpytywanie przy pomocy RIPE Atlas Tools słabo nadaje się do oskryptowania. Obsługa timeoutów, parsowanie odpowiedzi, zapisywanie wyników – wydaje mi się, że lepiej będzie napisać wszystko w Pythonie.

Badanie czasu od pojawienia się domeny na liście do czasu zablokowania u danego ISP. Bez pełnego automatu nie ma co podchodzić do tematu. I pewnie do przemyślenia jak to potem sensownie interpretować, pewnie trzeba będzie wspomóc się statystyką.

Motywacja mi nieco siadła, więc pewnie zejdzie dłuższa chwila nim coś nowego się pojawi.

[1] Dla Netii z kolei znalazłem serwery DNS, ale nie było ochotnika do zrobienia testu wersją ze skryptem. Przy pomocy sond RIPE Atlas ustaliłem, że nie korzystają z listy CERT Polska, ale z publikacją tego poczekam na zmianę flow zamieszczania danych.

Delegalizacja noży

Czy noże są legalne? Odpowiedź jest nieoczywista, w przypadku noży fizycznych i różni się mocno między państwami. Wygląda na to, że delegalizacja noży to etap do którego dotarła nasza cywilizacja. Przynajmniej w przypadku oprogramowania. Noże są metaforą, chodzi o narzędzia w postaci oprogramowania.

Tym razem wirtualnym nożem został program youtube-dl. W całej sprawie chodzi o zamknięcie jego repozytorium na GitHubie po otrzymaniu niedawnego żądania usunięcia na podstawie DMCA. Polecam lekturę, mi uzasadnienie wydaje się ciekawe – oprogramowanie służy do omijania zabezpieczeń i robienia nieautoryzowanych kopii. I rzekomo posłużyło do zrobienia nieautoryzowanych kopii artystów zrzeszonych w RIAA. W to ostatnie akurat jestem skłonny uwierzyć.

Zastanawiam się jednak nad pierwszą częścią. Pobranie z YouTube jest możliwe przy pomocy wielu narzędzi. Potrafi to każda przeglądarka internetowa. Kopię można zrobić smartfonem. O masie oprogramowania dedykowanego do odtwarzania multimediów, w tym z YouTube nie wspominam. Poza tym, w grę wchodzi dowolne oprogramowanie do rejestracji obrazu, nagrywania dźwięku czy nagrywania pulpitu. Tak wiele noży do zdelegalizowania…

Zresztą, celem umieszczania materiałów na YouTube jest udostępnianie ich publicznie. Szczególnie jeśli nie są ustawione ograniczenia widoczności, czyli materiał jest publiczny. A może znowu chodzi o reklamy i ich omijanie? Bo przecież narzędzie, czyli nóż może służyć do różnych celów. Na przykład do krojenia chleba. W przypadku youtube-dl mogę zrobić kopię własnych materiałów, które umieściłem na YouTube. Albo pobrać na dysk – legalnie w świetle polskiego prawa – materiały do ich odtwarzania bez zużywania transferu przez komórkę.

Sprawa jest głośna i zastanawiam się, jak się skończy ta próba delegalizacji noży. Czy usunięcie miało charakter automatyczny i zostanie wkrótce przywrócone? Całość jest ciekawa tym bardziej, że w grę chodzi GitHub jako miejsce do rozwijania oprogramowania. Jeśli usunięcie repozytorium zostanie utrzymane, to mogą być tu spore ruchy – ludzie mogą zacząć migrować na inne platformy. Smaczku sprawie dodaje fakt, że właścicielem GitHuba jest Microsoft, a YouTube Google.

UPDATE Program nadal można pobrać ze strony projektu, jest też dostępny w repozytoriach dystrybucji Linuksa.

UPDATE 2: O sprawie zdjęcia youtube-dl z GitHuba w kontekście legalnych zastosowań pisało EFF. Jest też artykuł w serwisie Torrentfreaks o odpowiedzi w postaci zamieszczania mp3. Oraz poruszona kwestia przeglądarek. Polecam.

UPDATE 3: Pojawił się ciekawy wpis na blogu pierwotnego autora youtube-dl w którym pisze o genezie projektu i realiach. Zachęcam do lektury.

UPDATE 4: Trwało to dłuższą chwilę, ale wygląda, że repo youtube-dl powróciło. Decyzja do przeczytania tutaj. Dłuższe uzasadnienie stanowiska GitHub. I zamierzają zmienić proces obsługi DMCA na bardziej przyjazny developerom.