Przejdź do treści

Pieśni o Bezpieczeństwie Sieci
blog Michała "ryśka" Woźniaka

Programiści WiOO i aktywiści otwartej sieci też są ludźmi

Trudno mi uwierzyć, że muszę o tym pisać, ale:
Programiści rozwijający wolne i otwarte oprogramowanie oraz aktywiści otwartej sieci, bezinteresownie utrzymujący niezależnie usługi sieciowe, też są ludźmi.

Wygląda na to, że ten fakt jest wyjątkowo trudny do przetrawienia dla naukowców (w tym, najwyraźniej, również osób odpowiedzialnych za etyczną ocenę proponowanych badań). Ostatnie zamieszanie związane z Princeton-Radboud Study on Privacy Law Implementation (“Badanie wdrożenia regulacji związanych z prywatności, prowadzone przez Princeton-Radboud”) dobrze to ilustruje.

“To nie jest badanie skupiające się na ludziach”

Pomysł badania wydaje się prosty: weźmy listę “popularnych” stron internetowych (według listy Tranco, stworzonej z myślą o badaniach naukowych), wyślijmy wiadomości e-mail na związane z domenami tych stron adresy, które (jak można się spodziewać) są obserwowane przez ich administratorów w kontekście zapytań związanych z prywatnością (np. privacy@example.com), i użyjmy odpowiedzi do oszacowania stanu wdrożenia CCPA i RODO. Brzmi dobrze!

Było jednak z tym badaniem kilka problemów:

Wyobraźmy sobie teraz, że prowadzimy mały, niezależny serwis mediów społecznościowych, i dostajemy maila (brzmiącego, jakby został wysłany przez prawnika), który powołuje się na regulacje prawne dotyczące prywatności, o których nawet nie słyszeliśmy. Wiadomość kończy się tym zdaniem:

Oczekuję odpowiedzi bez zbędnej zwłoki, najwyżej w ciągu 45 dni od otrzymania niniejszej wiadomości, zgodnie z Sekcją 1798.130 Kodeksu Postępowania Cywilnego Stanu Kalifornia.

Czas dzwonić do prawnika? To może szybko wygenerować spore koszty. Czy można tę wiadomość po prostu zignorować? To się może skończyć jeszcze bardziej kosztownym procesem sądowym. Więc zaczynamy się martwić, nie spać po nocach, w związku z czymś, co brzmi całkiem poważnie, ale ostatecznie okazuje się po prostu czymś, co jakiś badacz uznał za “badanie nie skupiające się na ludziach”.

Odczłowieczanie

FAQ tego badania konsekwentnie mówi o “witrynach internetowych”, i “kontaktowaniu się z witrynami internetowymi”, i tak dalej, tak jakby to oznaczało, że nie dotknie to żadnych osób zajmujących się ich administrowaniem i odpowiadaniem na te e-maile. Na przykład (tłumaczenie i pogrubienie moje):

Co jeśli strona zignoruje e-mail, który jest częścią tego badania?

Nie wiadomo nam o żadnych negatywnych konsekwencjach braku odpowiedzi ze strony witryny internetowej na e-mail wysłany w ramach niniejszego badania. Nie będziemy wysyłać ponagleń dotyczących wiadomości, na które witryny internetowe nie odpowiedziały, i nie będziemy publikować nazw witryn w kontekście konkretnych odpowiedzi w naszym badaniu.

Niestety, nikt tego nie powiedział administratorce małej instancji niezależnych mediów społecznościowych, która być może nadal martwi się (lub nawet wydaje pieniądze na prawnika) tymi wiadomościami. Ale bez obaw, Princeton University Institutional Review Board uznało, że “to nie jest badanie prowadzone na ludziach”. Wszystko gra!

To nie jest pierwszy raz, gdy takie odczłowieczanie ma miejsce. Jakiś czas temy badacze z University of Minnesota przeprowadzili badanie, które polegało na proponowaniu zmian kodu jądra Linuksa celowo zawierających błędy.

Nalegali, że “studiowali tylko proces rozwoju”, jakoś umknął im fakt, że ten proces oparty jest na pracy konkretnych osób, z których wiele wkłada własny, prywatny czas wolny i energię w pracę nad jądrem Linuksa. Deweloperzy nie byli zadowoleni.

Ostatecznie badacze musieli przeprosić za brak empatii wobec programistów pracujących nad jądrem Linuksa i szacunku dla ich czasu.

Dygresja: branie “otwartości” na poważnie

Osobiście wydaje mi się, że jest to powiązane z szerszym problemem tego, jak wiele osób nie traktuje społeczności skupionych na (szeroko pojętej) otwartości poważnie.

W przypadku badania uniwersytetu Princeton, szereg osób administrujących instancjami Fediverse dostało te wiadomości. Badanie University of Minnesota dotknęło deweloperów jądra Linuksa. W obu przypadkach ich trud (zarządzanie serwerami niezależnych mediów społecznościowych; rozwój wolnego oprogramowania) nie były najwyraźniej uznane jako poważne czy istotne – nawet jeśli ich efekt (np. jądro Linuksa) uznany za poważny był.

Dostrzegam to w innych sytuacjach: ludzie dużo narzekają na Big Tech i “Platformy”, ale na sugestię, że Fediverse może być sensowną alternatywą (w sensie usługi, ale też w sensie modelu finansowania), reagują protekcjonalnym machnięciem ręki. Obserwuję to od lat również w kontekście wolnego oprogramowania.

A tymczasem publicznie wyautowany sprawca nadużyć, Facebook, zmienia sobie nazwę na Meta, i natychmiast wszyscy grzecznie debatują o tym, jak mądra i błyskotliwa jest to zmiana.

Badacz człowiekowi wilkiem?

Nieumiejętność rozpoznania przez badaczy człowieczeństwa w twórcach wolnego oprogramowania czy osobach administrujących małymi, niezależnymi witrynami czy usługami jest martwiąca. Jeszcze bardziej martwiący jest fakt, że nawet ciała zajmujące się oceną potencjalnych problemów etycznych badań naukowych popełniają ten sam błąd.

Natomiast marnowanie, w celu przeprowadzenia tego typu nieprzemyślanych badań, cennych zasobów (czasu, energii) aktywistycznych administratorek i administratorów czy twórców wolnego oprogramowania jest po prostu hańbą. Zraża do badaczy grupę osób głęboko zaangażowanych w kwestie prywatności, i to w momencie, w którym badania dotyczące prywatności i praw cyfrowych są absolutnie kluczowe.

Czemu podoba mi się pomysł Zarządzania Zależnościami w Oparciu o Kontrakt (CBDM)

Jakiś tydzień temu @tomasino opublikował opis swojego pomysłu dotyczącego zarządzania zależnościami w oparciu o kontrakt (w oryginale: Contract-Based Dependency Management, CBDM), i skłamałbym, gdybym powiedział, że mi się on nie podoba.

Jest to po prostu lepszy model zarządzania zależnościami niż SemVer czy jakikolwiek inny system wersjonowania oprogramowania. Ale nie tylko! CBDM:

  • dostarcza twórcom oprogramowania dodatkowej dobrej motywacji do utrzymywania rozbudowanych zestawów testów;
  • daje twórcom oprogramowania dobry powód, by pomagać w utrzymaniu rozbudowanych zestawów testów projektom, na których się ich własny projekt opiera;
  • pozwala uzyskać jasną i jednoznaczną odpowiedź na pytanie, czy dana funkcjonalność albo dany aspekt zachowania danej zależności jest oficjalnie wpierany przez twórców tej zależności;
  • dostarcza jasną i jednoznaczną informację, jeśli jakaś funkcjonalność czy aspekt zachowania danej zależności uległ zmianie;
  • jeśli aktualizacja zależności w jakiś sposób negatywnie wpłynie na projekt od niej zależny, CBDM pozwala jednoznacznie ustalić, kto nawalił.

Czym jest Zarządzania Zależnościami w Oparciu o Kontrakt (CBDM)?

Zasadniczo pomysł sprowadza się do polegania na wynikach testów jednostkowych, zamiast na numerach wersji, podczas decydowania czy nowa wersja zależności jest kompatybilna z zależnym od niej oprogramowaniem. Testy te powinny oczywiście testować te funkcjonalności i aspekty zachowania danej zależności, na których polega zależny od niej projekt.

Innymi słowy, zamiast patrzeć na numery wersji, patrzmy na testy jednostkowe dla danej zależności (oraz wyniki ich uruchomienia).

Tomasino nurkuje w ten temat głębiej w swoim wpisie, naprawdę warto go przeczytać.

Co jest nie tak z numerami wersji?

Numery wersji bardzo często nie są godną zaufania metodą ustalania, czy coś się aby nie zepsuje po aktualizacji. Sam SemVer to przecież nic innego niż próba spowodowania, by były bardziej godne zaufania w tym kontekście.

Problem jednak polega na tym, że niemożliwe jest wyrażenie wszystkich wymiarów możliwych zmian w danym projekcie oprogramowania za pomocą zestawu zaledwie kliku liczb. Mało tego, pewnie zmiany mogą być uznane za mało istotne lub w ogóle nieistotne, kosmetyczne, przez twórców danego pakietu oprogramowania, a jednocześnie mogą być wystarczająco duże, by spowodować poważne komplikacje dla zależnych od niego projektów, wykorzystujących jakąś specyficzną jego cechę.

Stąd się biorą specyfikacje, a wraz z nimi niekończące się debaty o tym, czy konkretna zmiana łamie specyfikację, czy też nie.

CBDM w praktyce

Załóżmy, że rozwijam jakiś projekt, nazwijmy go AProject. Używa on (i zależy od) biblioteki, powiedzmy: LibBee. Twórcy LibBee są bohaterami, na których nie zasługujemy, i utrzymują dla LibBee bardzo rozbudowany system testów.

Jako twórca AProjekt definiuję zależność od LibBee nie jako:

LibBee ver x.y.z

…ale jako:

LibBee, (lista konkretnych testów z całego zestawu testów LibBee, które muszą być niezmienione, i mieć wynik pozytywny)

(Zostawmy na razie temat tego, jak dokładnie taka lista testów zależności miałaby wyglądać.)

Ta lista testów nie zawiera wszystkich testów LibBee – w istocie, nie powinna zawiera ich wszystkich, jako że to by oznaczało, że w zasadzie przypinamy na sztywno becną wersję LibBee (zakładając pełne pokrycie kodu tej biblioteki testami; wrócimy do tego). Co jednak ważne, powinna ona zawierać testy sprawdzające wszystkie funkcjonalności i aspekty zachowania LibBee, na których mój AProject polega.

Ta lista testów tworzy kontrakt. Jeżeli kontrakt ten jest spełniony przez dowolną nowszą (czy starszą) wersję LibBee, to oznacza, że mogę bezproblemowo zaktualizować moją zależność w AProject. Po aktualizacji wszystko powinno nadal działać, jak należy.

A jeśli aktualizacja LibBee mimo wszystko spowoduje problemy w AProject?

Napisałem “powinno”, bo oczywiście ludzie popełniają blędy. Jeśli aktualizacja LibBee spowoduje problemy w AProject mimo tego, że kontrakt jest spełniony (to znaczny, mimo tego, że testy wymienione w kontrakcie nie uległy zmianie, oraz że dają wynik pozytywny), to istnieje tylko jedna opcja: AProject polegał na jakiejś funkcjonalności lub jakims aspekcie zachowania LibBee, który nie był ujęty w kontrakcie.

To oznacza, że jasnym jest, kto odpowiada za ten nieprzewidzialny problem: ja. Ja, jako twórca AProject, nie upewniłem się, że kontrakt faktycznie testuje wszystko, na czym polega mój projekt. W ten sposób unikamy długiej, męczącej dyskusji pomiędzy mną a twórcami LibBee, dotyczącej tego, kto nawalił. Uzupełniam więc kontrakt o dane brakująch testów i skupiam się na naprawieniu problemu.

Tym samym AProject uzyskał lepszy, pełniejszy kontrakt zależności, a mój czas (i cenny czas developerów LibBee) nie został zmarnowany na wzajemnych oskarżeniach.

Tyle wygrać!

A jeśli dany test nie istnieje w zależności?

Jeśli korzystam w AProject z jakiejś funkcjonalności LibBee, na którą po prostu nie ma napisanego testu, mam doskonały powód, by go dopisać, i wysłać twórcom LibBee jako mój wkład w rozwój biblioteki, z której korzystam.

Jeśli mój dopisany test zostanie zaakceptowany przez twórców LibBee i włączony do zestawu testów tej biblioteki, daje mi to jasny sygnał, że funkcjonalność, z której korzystam, jest oficjalnie wspierana. Mogę zatem dodać informację o tym teście do mojego kontraktu zależności w AProject. LibBee uzyskała nowy test i ma lepsze pokrycie kodu testami, kompletnie za darmo. Mój projekt ma pełniejszy kontrakt zależności, co oznacza, że mogę się nie martwić o aktualizacje LibBee.

Tyle wygrać!

A jeśli mój test zostanie odrzucony?

Jeśli twórcy LibBee odrzucą mój test, jest to bardzo jasny sygnał, że AProject polega na jakiejś funkcjonalności albo jakimś aspekcie zachowania, które nie są oficjalnie wspierane.

Z jednej strony, mogę wtedy zdecydować, że trudno, ryzykuję korzystanie z nieoficjalnie wspieranej funkcjonalności. Dodam wtedy mój test do kontraktu, ale sam test umieszczę bezpośrednio w AProject. Pozwoli mi to weryfikować nowe wersje LibBee zanim zaktualizuję tę zależność. Z drugiej strony, mogę zdecydować, że to zbyt ryzykowne, i przepisać AProject tak, by nie polegał na niewspieranej funkcjonalności.

W każdym razie wiem, w co się pakuję, a twórcy LibBee wiedzą, że nie będę ich winił jeśli zmienią ten konkretny aspekt działania ich biblioteki – zostałem przecież ostrzeżony, i mam swój test jako dowód.

Więc znów: tyle wygrać!

Czas obalić numery wersji?

Nie, w żadnym razie. Numery wersji są nadal przydatne, choćby po to, by wiedzieć, że dana zależność została zaktualizowana. W zasadzie warto nadal z nich korzystać również w celu zarządania zależnościami, podając wspierane numery wersji zależności nawet jeśli mamy już kontrakt, w celu płynnego przejścia z zarządzania zależnościami w oparciu o numery wersji do CBDM.

Numery wersji sprawdzają się nieźle na poziomie ludzkim, te zgodne z SemVer niosą ze sobą dość dobrze zdefiniowany zestaw informacji. Po prostu nie są w stanie wyrazić wszystkiego, na czym by nam zależało w dobrym systemie zarządzania zależnościami. Zgodzi się z tym każdy, kto zarządzał większym projektem z dużą liczbą zależności.

Gdzie jest haczyk?

Zawsze jest jakiś haczyk!

Trzy kluczowe rzeczy są dość trudne do dobrego zdefiniowania:

  1. W jaki sposób “identyfikuje się test”?
  2. Jak sprawdzić, że “test nie uległ zmianie”?
  3. Jak “dodaje się test do kontraktu”?

Odpowiedzi na pytania 1. i 2. prawie na pewno zależą od jeżyka programowania, a pewnie i od systemu, w którym piszemy testy. I prawie na pewno odpowiedzi na te pytania zdefiniują w dużej mierze odpowiedź na pytanie ostatnie.

Z gruba ciosany pomysł:

  1. Test identyfikowany jest jego nazwą (praktycznie każdy system testów jednostkowych pozwala “nazywać” testy, często nawet tego wymagając).
  2. Jeśli kod źródłowy testu zmienił się w jakikolwiek sposób, test uznaje się za zmieniony. Prawdopodobnie miałoby sens odpalanie jakiegoś lintera, tak, by zmiany w znakach niedrukowalnych nie powodowały uznania testów za zmienione.
  3. Jeśli identyfikujemy testy na podstawie ich nazwy, używanie nazwy testu w kontrakcie wydaje się najsensowniejsze.

Pomysł CBDM, moim zdaniem, ma mnóstwo sensu. Rozwój oprogramowania staje się coraz bardziej oparty na testach (i bardzo dobrze!), czemu przy okazji nie użyć ich do rozwiązania problemu piekła zależności?

Ściągawka z kultury hakerskiej dla mediów (i nie tylko)

Wersja niniejszego wpisu została pierwotnie opublikowana przez Oko Press.

Obfite okraszanie przekazów medialnych dotyczących kwestii bezpieczeństwa informacji, włamań, wycieków, i cyberataków słowami “haker”, “zhakować”, i podobnymi, jest problematyczne:

  1. Utrudnia rzetelne zdanie sprawy z przyczyn danego wydarzenia, a w efekcie niemal uniemożliwia rzeczową debatę publiczną.
  2. Demonizuje kreatywną społeczność majsterkowiczów i majsterkowiczek, artystek i artystów, badaczek i badaczy systemów informatycznych, czy osób zajmujących się bezpieczeństwem informacji.

Utrudniona debata publiczna

Włamanie na konto pocztowe Michała Dworczyka świetnie ilustruje problem pierwszy.

Tytuły w stylu “Atak hakerski na Dworczyka” czy “Rząd zhakowany” stawiają Dworczyka i rząd w roli ofiar, które zostały “zaatakowane” przez jakichś domniemanych ale nieznanych (i przez to strasznych) “hakerów”, na których tym samym przenoszona jest odpowiedzialność.

Jak wyglądałaby debata publiczna, gdyby tytuły brzmiały “Wyciek tajnych danych z niezabezpieczonego konta Dworczyka” albo “Rządowe maile na prywatnej skrzynce pocztowej”? Być może skupiłaby się na fakcie, że Michał Dworczyk zachował się w sposób skrajnie nieodpowiedzialny. Być może też zastanawialibyśmy się, dlaczego osoby publiczne używają prywatnych kont pocztowych do oficjalnej komunikacji – czy próbują coś ukryć?

To nie są hipotetyczne dywagacje, przecież po publikacji informacji o wycieku maili częścią rządowego przekazu dnia byli “hakerzy z Rosji”

Problem jest szerszy: za każdym razem, gdy okazuje się, że jakieś usieciowione urządzenie nie zostało wystarczająco zabezpieczone przez producenta (od żarówek, przez samochody, po sex-zabawki), media piszą o “hakowaniu” i “hakerach”, zamiast skupić się na dostawcach wadliwego, niebezpiecznego produktu. W efekcie, mnóstwo energii idzie w debatowanie, jak “zabezpieczyć się przed hakerami”.

Z jednej strony nie rozwiązuje faktycznych problemów (rząd unikający korzystania z bezpiecznej infrastruktury państwowej, oficjele nie stosujący podstawowych zabezpieczeń, producenci sprzedający niebezpieczne produkty).

Z drugiej: tworzone są regulacje prawne (jak amerykańska CFAA), które osoby utalentowane technicznie i ciekawe traktują jak groźnych przestępców i terrorystów. To prowadzi do sytuacji, w których ktoś znajduje problem bezpieczeństwa w dużej firmie, informuje tę firmę, po czym zostaje oskarżony o “włamanie”.

Społeczność hakerska

Spora część tych utalentowanych technicznie osób nazwałaby siebie “hakerami”. Z drugiej strony, nie wszyscy hakerzy i hakerki są osobami technicznymi. Haker to ktoś ciekawy świata, myślący niesztampowo, lubiący przekraczać granice i dzielić się wiedzą: informacja chce być wolna.

Haker nie musi być informatykiem. Świetnymi przykładami hakerów z polskiego podwórka są Pomysłowy Dobromir, Antonisz, Adam Słodowy. Doskonale ilustrują kreatywne podejście do rozwiązywania problemów, pragnienie pomagania innym.

Polska społeczność hakerska koncentruje się wokół hakerspejsów. Większość z nich ma formę prawną (zwykle jest to stowarzyszenie lub fundacja), członkinie i członków, siedzibę, zarząd. Polscy hakerzy i hakerki brali udział w debatach publicznych, na masową skalę produkowali pro bono przyłbice antycovidowe dla osób pracujących na pierwszej linii pandemii, organizowali setki godzin warsztatów z cyberbezpieczeństwa. Stali się też przedmiotem pracy naukowej z dziedziny socjologii.

Globalnie hakerki i hakerzy są podobnie aktywni: biorą udział w konsultacjach społecznych, używają drukarek 3d do produkcji brakujących części zamiennych respiratorów dla szpitali, czy pomagają protestującym w czasie Arabskiej Wiosny obchodzić blokady internetu.

Trudno podać datę początkową ruchu hakerskiego – już Ada Lovelace jak najbardziej się w nim mieści – ale często wymienia się Tech Model Railroad Clubna MIT jako ważne miejsce i czas (przełom lat 40. i 50. XX w.) dla narodzin współczesnej kultury hakerskiej. Pierwsi współcześni hakerzy byli modelarzami kolejowymi. W tym czasie w PRL-u nazywaliśmy ich “majsterkowiczami”.

Wraz z popularyzacją komputerów osobistych i Internetu kultura hakerska się rozpowszechniła i nieco rozmyła. Powstały hakerspejsy, czyli “kluby hakera”: przestrzenie, w których hakerzy i hakerki mogą realizować swoje pasje i wymieniać się wiedzą. Jest miejsce na spokojną pracę z laptopem, wifi, prąd, i kawa. Czasem jest serwerownia. Często jest warsztat do pracy z drewnem czy metalem, drukarki 3d, warsztat elektroniczny, plotter laserowy. Większe hakerspejsy (jak ten Warszawski) mają cięższy sprzęt, na przykład tokarki.

Hakerspejsy tworzą nieformalną, globalną sieć miejsc, w których osoby ze społeczności, zgubione w nieznanym mieście, mogą uzyskać dostęp do prądu i Internetu, i znaleźć przyjazne towarzystwo. Z czasem niektóre hakerspejsy zrzeszyły się w większe organizacje hakerskie, jak niemiecki Chaos Computer Club. Powstały również ruchy powiązane: ruch wolnego oprogramowania, ruch wolnej kultury.

Pojawiły się też fablaby i makerspace’y, które skupiają się bardziej na praktycznej, twórczej stronie ruchu hakerskiego.

Granice są rozmyte, wiele fablabów i makerspace’ów nie czuje się częścią ruchu hakerskiego. Z grubsza: makerspace’y kładą mniejszy nacisk na etos hakerski, bardziej skupiając się na robieniu rzeczy. Mniej się też na ogół interesują elektroniką i informatyką. Fablaby z kolei to makerspace’y mniej nastawione na budowanie społeczności, a bardziej na udostępnienie (zwykle odpłatnie) pracowni wszystkim zainteresowanym.

Etos hakerski

Nie ma jednej, globalnie uznanej definicji etosu hakerskiego. Są jednak pewne stałe elementy, które pojawiają się w zasadzie na każdej liście:

  • wiedza ubogaca, dostęp do niej nie powinien być ograniczany (“informacja chce być wolna”);
  • autorytety są podejrzane, centralizacja (wiedzy, władzy, kontroli, itp.) również;
  • wartość hakera czy hakerki nie ocenia się na bazie z koloru skóry, płci, wieku, itp., a na podstawie wiedzy i umiejętności;
  • praktyka jest ważniejsza niż teoria.

Hakerzy i hakerki są często bardzo wyczuleni na różnicę pomiędzy faktem, że coś jest niezgodne z prawem, a faktem, że coś jest nieetyczne. Działania nielegalne i jednocześnie nieetyczne są dla nich zdecydowanie mniej interesujące, niż działania nielegalne a zarazem etyczne.

Stąd wsparcie społeczności hakerskiej dla organizacji dziennikarskich czy organizacji pozarządowych.

Stąd narzędzia takie, jak Tor Project, SecureDrop, Signal, czy Aleph, szeroko używane przez organizacje dziennikarskie na całym świecie, a zapoczątkowane i tworzone przez osoby ze społeczności hakerskiej.

Stąd też działania grup takich, jak Telecomix, od pomagania w obchodzeniu blokady internetu w Tunezji czy Egipcie, po wykradnięcie logów udowadniających, że amerykańskie firmy pomagały rządowi Syrii cenzurować Internet i szpiegować Syryjczyków.

Czemu Telecomix zdecydował się wykraść te logi? Ponieważ działania rządu Syrii i współpracujących z nim amerykańskich firm były skrajnie nieetyczne, a technologia była przez nie wykorzystywana w celach, które dla hakerów są nie do zaakceptowania: blokowania dostępu do wiedzy i dławienia opozycji. Etos hakerski w działaniu.

Hakerzy i włamywacze

Jak zwykle w kwestiach etycznych, ocena takich działań nie jest czarno-biała i jednoznaczna. Granica między hakerem a cyberprzestępcą jest nieostra, wyznaczona z grubsza właśnie przez ten niedookreślony etos. Nie daje to jednak licencji na równianie wszystkich hakerów i hakerek do cyberprzestępców.

Dobrym tłumaczeniem czasownika “hack” (w konteście kultury hakerskiej) jest “majstrowanie”. Zwykle oznacza coś kompletnie niewinnego, jak naprawianie swojego roweru czy montowanie półek w garażu. Co prawda “majstrowanie” przy cudzym zamku do drzwi brzmi podejrzanie, nie powiemy jednak: “ktoś mi się wmajstrował do mieszkania i ukradł telewizor”.

Istnieją hakerzy-włamywacze, tak samo jak istnieją majsterkowicze-włamywacze. Gdy majsterkowicz się gdzieś włamie, nazwiemy go włamywaczem. Gdy majsterkowicz coś komuś ukradnie, nazwiemy go złodziejem.

Absurdem byłoby mówić o “gangu majsterkowiczów” tylko na podstawie faktu, że przy większym rabunku użyto narzędzi.

Nie mówilibyśmy o “majsterkowiczach”, gdyby grupa młodzieży włamała się do pokoju nauczycielskiego, wyłamując zamek śrubokrętem.

Wreszcie, nie mówilibyśmy o “majsterkowiczach” również wtedy, gdy dana grupa przestępcza byłaby finansowana, wyposażona, i wyszkolona przez konkretne państwo, które ustalałoby cele jej włamań.

Jakoś jednak nie dziwią nas tytuły w stylu: “Rosyjskojęzyczni hakerzy zhakowali policję w Waszyngtonie” albo cytaty typu: “Policja namierzyła młodego hakera, teraz zajmie się nim sąd rodzinny.”.

Czym innym jest zorganizowana grupa przestępcza (nieważne, czy działa w Sieci, czy poza nią), czym innym młodociany wandal, a czym innym komórka szpiegowska. Trzynastolatek z Gdańska nie ma nic wspólnego z Rosyjskimi cyber-szpiegami, ci z kolei raczej niewiele z gangiem kryminalistów wyłudzających haracz on-line. Nazywanie ich wszystkich “hakerami” niewiele wnosi i nic nie wyjaśnia.

Zderzenie z rzeczywistością

Angielski czasownik “hack” znaczy “ciosać”, “rąbać”. Z czasem, na MIT właśnie, stało się też rzeczownikiem i nabrało znaczenia “psikus”, “psota”, zwłaszcza gdy chodziło o żarty wymagające inwencji i poświęcenia. W kulturze hakerskiej przyjęło też dodatkowy sens: “niekoniecznie eleganckie, ale skuteczne i błyskotliwe rozwiązanie jakiegoś problemu”.

“Problemem” może tu być złe napięcie w szynach modelu kolejki, blokada Internetu w Tunezji, albo… brak otwartego dostępu do biblioteki tekstów naukowych. A skoro “informacja chce być wolna”, to trzeba jej pomóc.

Tyle tylko, że to już może zostać łatwo zinterpretowane jako “cyberatak” – na bazie wspomnianych regulacji prawnych pisanych w celu “obrony przed hakerami”. To doprowadziło do zaszczucia hakera, aktywisty, współzałożyciela Reddita, pomysłodawcy SecureDropa i współtwórcy formatu RSS, Aarona Swartza. Po jego śmierci, JSTOR zdecydował się jednak nieco otworzyć swoje zbiory dla publiki.

Gdyby ruch hakerski nie był tak łatwo demonizowany, być może organa ścigania podeszły by do sprawy inaczej, i Aaron wciąż by żył.


Pytania i odpowiedzi

Jak nazwać ludzi, którzy włamują się do indywidualnych i zbiorowych systemów w złych celach?

Włamywaczami” albo “cyberprzestępcami”, jeśli mówimy o włamaniu natury kryminalnej. “Wandalami” (z przymiotnikiem, np. “cyfrowymi”, “sieciowymi”, itp.), jeśli mówimy np. o włamaniu i podmienieniu treści jakiejś strony – zwłaszcza jeśli nie było specjalnie skomplikowane technicznie (jak niechlubne hasło admin1 na stronie premier.gov.pl). “(Cyber)szpiegami”, jeśli mowa o atakach prowadzonych, finansowanych, lub powiązanych z rządami konkretnych państw.

Jeśli brakuje konkretnych informacji, zawsze można nazwać ich “atakującymi”, “agresorami”, itp.

Uwaga techniczna: często nie doszło nawet do włamania! Na przykład w przypadku “młodych hakerów”, którzy rzekomo się “włamali” na serwery e-dziennika, okazuje się, że atakujący “doprowadzili do ich [serwerów] przeciążenia, utrudniając na pewien czas prowadzenie zdalnych lekcji”. To tak, jakby grupa ludzi stworzyła sztuczny tłum przed wejściem do szkoły – trudno to nazwać włamaniem!

Kiedy nazwać kogoś hakerem?

W takich samych sytuacjach, w których (gdyby dane wydarzenie nie było związane z komputerami), nazwalibyśmy ich “majsterkowiczami”. To naprawdę dosyć dobry model.

[Majsterkowicze] włamali się do gabloty szkolnej i umieścili w niej niestosowne komunikaty” – raczej nie brzmi dobrze. Nawet, jeśli ci wandale sami siebie nazywają “majsterkowiczami”. A więc również nie “[Hakerzy] włamali się na stronę i podmienili treść”.

[Majsterkowicze] wyprodukowali 50.000 przyłbic antycovidowych i wysłali do szpitali i instytucji medycznych” – to działa. A więc i “hakerzy wyprodukowali…”.

[Majsterkowicze] włamali się do mieszkania ministra” nie ma sensu. A zatem również nie “hakerzy włamali się na konto ministra”: raczej “nieznani sprawcy”, “osoby podejrzane o współpracę ze służbami obcego kraju”, itp.

Czym są hakatony?

Hakatony to wydarzenia, na których osoby technicznie utalentowane starają się w krótkim czasie rozwiązać jakiś problem lub osiągnąć jakiś cel. Hakatony mogą na przykład być społeczne (jak Random Hacks of Kindness, czy dawniej polski SocHack), albo skoncentrowane na tworzeniu startupów (jak Startup Weekend).

Na czym tak naprawdę polega hakowanie?

Hakowanie to nic innego, jak majsterkowanie, tylko może nieco bardziej sugeruje użycie komputerów (a i to nie zawsze). Serio serio. Przekonać się o tym można w dowolnym lokalnym hakerspejsie.

Czy walka o ten termin nie jest już przegrana? Nie lepiej znaleźć inne słowo na tę społeczność?

Próbowaliśmy – “haktywista” i “aktywista cyfrowy” nie wzięły się z nikąd. I natychmiast zaczęły być używane w znaczeniu “cyberprzestępca”, na przykład tu:

“Activists or hacktivists are threat actors motivated by some political, economic, or social cause, from highlighting human rights abuse to internet copyright infringement and from alerting an organization for its vulnerabilities to declaring online war with people or groups whose ideologies they do not agree with”

Inne słowa zostały “odzyskane” przez ich społeczności. Społeczność LGBTQ+ odzyskala skutecznie słowa, które były pejoratywnymi określeniami osób homoseksualnych (nikt w mediach nie napisze dziś o nich używając np. nazwy części rowerowej, a przecież jeszcze w “Seksmisji” bohater mówi “nie róbcie z nas pederastów”!). Podobnie społeczność osób czarnoskórych w Stanach Zjednoczonych skutecznie odzyskała słowo-na-n.

I wreszcie, być może najważniejsze: czemu w ogóle mielibyśmy oddawać to słowo bez walki? Tak się nazwaliśmy, tak nasza społeczność się określa, czy nie należy się nam jakiś zupełnie podstawowy szacunek? Dlaczego mielibyśmy się po cichu zgadzać na publiczne równanie z kryminalistami i szpiegami tylko dlatego, że łatwiej komuś pisać “haker” niż zastanowić się, co się faktycznie wydarzyło w danej sytuacji?

Centralizacja jest zagrożeniem dla demokracji

Angielska wersja niniejszego wpisu została pierwotnie opublikowana na stronach Redecentralized oraz VSquare.

Po brutalnym ataku na Kapitol w Waszyngtonie, monopoliści mediów społecznościowych zaczynają sobie wreszcie uświadamiać, że centralizacja jest niebezpiecznia. Pełna kontrola nad codzienną komunikacją setek milionów użytkowników i użytkowniczek wiąże się z odpowiedzialnością, być może zbyt wielką nawet dla informatycznych behemotów.

Całe lata Facebook i Twitter nie były skłonne egzekwować własnych zasad dotyczących nakłaniania do przemocy, ze strachu przed negatywną reakcją znacznej części osób korzystających z ich usług. Teraz nagle blokują konta Donalda Trumpa i osób promujących teorię spiskową QAnon, mając nadzieję, że uda im się szybko zamknąć temat i wrócić do udawania, że wszystko jest w porządku.

Wszystko jednak nie jest w porządku. Te działania są zwyczajnie niewystarczające. Można je jednak odczytywać jako przyjęcie części odpowiedzialności za przemoc, która wybuchła na Kapitolu.

Nic się przecież nie zmieniło w retoryce prezydenta Trumpa, ani w przedziwnych teoriach spiskowych związanych z QAnon. Monopoliści mediów społecznościowych całe lata byli ostrzegani, że promowanie tego typu treści doprowadzi do rozlewu krwi; zresztą, już doprowadziło do tego w przeszłości.

A może po prostu wynik wyborów w Stanach oznacza, że coś, co kiedyś było korzystne dla tych firm, nagle stało się problemem?

“Trudne położenie”

Uczestniczyłem w wielu publicznych debatach na temat zarządzania Internetem. Za każdym razem gdy ktoś przypominał platformom społecznościowym (np. Facebookowi), że powinny włożyć więcej wysiłku w moderowanie problematycznych treści, platformy odpowiadały narzekając, że to niezmiernie trudne w tak dużej sieci, wszak regulacje prawne i kwestie kulturowe są tak bardzo różne w różnych zakątkach świata.

Trudno się nie zgodzić! Tyle, że w intencji tych korporacji był to argument za ograniczaniem regulacji prawnych, a w istocie jest to świetny argument za decentralizacją.

Jakby nie patrzeć, społecznościówki znalazły się w tym “trudnym położeniu” wyłącznie na własne życzenie: wynika to wprost z ich modelu biznesowego, polegającego na byciu centralnie zarządzanymi, globalnymi platformami, które próbują wpasować nieprzebrane bogactwo kultur w sztywne ramy jednej, spójnej, globalnej polityki moderacji treści.

Innymi słowy giganci mediów społecznościowych domagają się od lat, żeby demokratycznie wybrane rządy nie obejmowały ich regulacjami prawnymi zgodnymi z wolą obywateli, ponieważ nie pasuje im to do modeli biznesowych!

Te same firmy ignorują ostrzeżenia dotyczące nieskrępowanego rozprzestrzeniania się ruchów rasistowskich na ich platformach, i zarabiają krocie wręcz promując treści ekstremistyczne (potwierdzają to zresztą ich własne badania).

Polaryzacja debaty publicznej i dewastacja tkanki społecznej są, jak można się było spodziewać, tylko kosztem zewnętrznym.

I tak źle, i tak niedobrze

Jakiekolwiek blokowanie kont przez główne platformy społecznościowe oczywiście naychmiast budzi obawy o cenzurę (warto zauważyć, jak skutecznie tym argumentem posługują się właśnie osoby tworzące treści toksyczne, wzmacniające podziały społeczne). Czy naprawdę chcemy żyć w świecie, w którym garstka dyrektorów korporacji de facto decyduje o tym, co jest, a co nie jest dopuszczalne w społecznej czy politycznej debacie publicznej?

Oczywiścienie chcemy. To jest zbyt dużo skoncentrowanej władzy, władza zaś psuje. Pytanie nie brzmi “w jaki sposób te globalne platformy powinny używać swej władzy”, a raczej: “czy te firmy powinny w ogóle mieć taką władzę”.

Odpowiedź jest prosta: “nie”.

Alternatyw nie brakuje

Można jednak inaczej. Fediverse jest zdecentralizowaną siecią społecznościową.

To tak, jakby Twitter i Facebook działały podobnie do serwerów e-mail: możesz mieć konto na dowolnej instancji (tak nazywane są serwery na Fediversie), różne instacje komunikują się zaś ze sobą – jeśli masz konto na (powiedzmy) mastodon.social, możesz swobodnie wchodzić w interakcje z kontami z (na przykład) pleroma.soykaf.com, czy na dowolnej innej instancji używającej tego samego protokołu.

Poszczególne instancje utrzymywane są przez różne osoby bądź społeczności, korzystając z różnych rodzajów oprogramowania; każda ma swoje własne zasady.

Te zasady egzekwowane są za pomocą narzędzi moderacji, wśród których są takie, których nie da się zaimplementować w sieci zcentralizowanej. Osoby moderujące mogą blokować lub wyciszać poszczególne konta, mogą też blokować (tudzież: “defederować”) całe problematyczne instancje całkowicie – co jest zwyczajnie niemożliwe, jeśli cała sieć społecznościowa jest jedną “instancją”.

Mało tego, każda osoba na Fediversie może też samodzielnie blokować i wyciszać wątki, problematyczne konta, czy całe instancje tylko dla siebie. To oznacza, że problem napastliwych kont można rozwiązać na wiele sposobów, dostosowując reakcję do skali konkretnego problemu. Ponieważ społeczności zarządzają swoimi własnymi fediwersowymi instancjami, zależy im na tym, by szybko rozprawiać się z wszelkimi aktami agresji czy zastraszania; mają też po temu narzędzia i odpowiednią moc sprawczą.

Lokalne zasady zamiast globalnej cenzury

Fediverse też doświadczyło rasizmu i skrajnie prawicowego trollowania. Instancje takie, jak Gab próbowały stać się częścią tej sieci, pojawiały się też indywidualne rasistowskie i skrajnie prawicowe konta na innych instancjach.

Zostały one jednak bezceremonialnie wyrugowane dzięki lepszym narzędziom moderacji, jasnym i jednoznacznym zasadom dotyczacym tego, co jest niedopuszczalne na instancjach różnych społeczności, oraz dzięki osobom zarządzającym i moderującym, które bezpardonowo blokowały agresywne konta i problematyczne instancje.

Prezentacja Dereka Caelina, badacza i dziennikarza skupiającego się na technologiach komunikacyjnych, oferuje doskonałe podsumowanie tej sytuacji (okraszone całkiem solidnym zestawem danych). Mogę ją tylko gorąco polecić.

Dziś rasiści i skrajnie prawicowe trolle mroczny kąt Fediversu, do którego rzadko kto zagląda. Oczywiście nie powstrzyma to grupy zatwardzialców przed rasistowskimi dywagacjami we własnym gronie na własnej instancji (takiej, jak Gab), ale izoluje ich to, przez co trudniej jest im radykalizować kolejne osoby, i chroni innych użytkowników i użytkowniczki Fediversu przed potencjalnymi atakami. Oczywiście takie osoby nadal mogą tworzyć konta na innych instancjach, pod warunkiem, że dostosują swoje zachowanie do przyjętych na nich norm.

A wszystko to pomimo braku centralnego ośrodka narzucającego zasady. Okazuje się, że niewiele osób lubi rozmawiać z faszystami.

Co dalej?

Nie uda się znaleźć jednego uniwersalnego, centralnie egzekwowanego zestawu zasad moderacji, który dałoby się wdrożyć globalnie. Społeczności mają różną wrażliwość i różne zasady, a osoby zanurzone w tych społecznościach sami najlepiej rozumieją kontekst danej komunikacji, i wiedzą, jak ją moderować.

Na poziomie indywidualnym możesz po prostu dołączyć do Fediversu. Na poziomie społecznym, powinniśmy wyrwać murom popularnych sieci społecznościowych zęby krat, objąć je regulacjami prawnymi, i doprowadzić to tego, by monetyzacja toksycznych, zatruwających debatę publiczną, interakcji on-line była tak samo niedopuszczalna, jak wylewanie trujących ścieków do rzeki.

Zresztą, sami społecznościowi monopoliści dochodzą w końcu do wniosku, że skuteczna moderacja scentralizowanej globalnej sieci jest zwyczajnie niemożliwa, i że potrzebne są nowe regulacje prawne. Skoro nawet oni to widzą, my też powinniśmy.

Dzień, w którym cenzura Sieci w Polsce stała się faktem

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

Stało się. Dziś weszła w życie ustawa tak zwana “antyterrorystyczna”. W niej zaś znajdziemy artykuł 32c, którego punkt pierwszy brzmi (polecam jednak lekturę całego artykułu):

W celu zapobiegania, przeciwdziałania i wykrywania przestępstw o charakterze terrorystycznym oraz ścigania ich sprawców sąd, na pisemny wniosek Szefa ABW, złożony po uzyskaniu pisemnej zgody Prokuratora Generalnego, w drodze postanowienia, może zarządzić zablokowanie przez usługodawcę świadczącego usługi drogą elektroniczną dostępności w systemie teleinformatycznym określonych danych informatycznych mających związek ze zdarzeniem o charakterze terrorystycznym lub określonych usług teleinformatycznych służących lub wykorzystywanych do spowodowania zdarzenia o charakterze terrorystycznym, zwane dalej „blokadą dostępności”.

Jednym słowem, szef ABW w porozumieniu z Prokuratorem Generalnym mają prawo zablokować dowolną stronę, treść czy usługę w Internecie. I to, zgodnie z pkt. 4, “w sprawach niecierpiących zwłoki” na 5 dni bez decyzji sądu. A kto decyduje, że sprawa nie cierpi zwłoki? ABW i Prokurator Generalny, rzecz jasna!

Zastanawiające, że ani w komunikacie MSWiA na temat (jeszcze projektu) tej ustawy, ani w komunikacie na stronie Sejmu, ani słowem się nie zająknięto na temat tych nowych uprawnień ABW.

Czy powodem może być roztargnienie? Bardzo nie chcę wierzyć, że nasi szanowni włodarze, dniem i nocą czuwający nad naszym bezpieczeństwem, są aż tak roztargnieni, by zapomnieć wspomnieć o dość ważnym elemencie ustawy tak ważnej, że nie przeprowadzono nawet konsultacji społecznych (musiał to za rząd zrobić RPO), by nie opóźniać jej wejścia w życie…

Być może pominięcie to wynika z faktu, że nikt tak naprawdę nie jest w stanie wskazać, w jaki sposób zablokowanie jakiejkolwiek treści miałoby pomóc w walce z terroryzmem? Zwłaszcza blokowanie treści w tak błyskawicznym trybie? Myślałbym, że raczej należałoby treści nie blokować, ale bacznie przyglądać się, kto uzyskuje do niej dostęp. Ale ja tam się nie znam.

Moim ulubionym pytaniem na które nie ma nigdzie odpowiedzi, bo jakże miałaby być, jest jednak pytanie zadane mi w mediach społecznościowych Fundacji Panoptykon. Brzmiało ono:

Czy ‘ekspert’ Michał “rysiek” Woźniak może wyjaśnić, jak pisowski rząd będzie rozpakowywał transmisję SSL?

No więc właśnie tu jest pies pochowany, jest to doskonałe i ważne pytanie, tyle że… to nie ja powinienem to wyjaśnić. Warto by to pytanie (i parę innych) zadać ABW. Drogie ABW – jak zamierzacie rozpakowywać transmisję SSL?

Zostałem jednak do tablicy wywołany, więc spróbujmy. By nie było zbyt łatwo, zmierzę się z pytaniem szerszym: w jaki sposób pobożne życzenia ABW, Prokuratora Generalnego i twórców tej ustawy mają się do rzeczywistości, a konkretnie faktu, że połączenia SSL/TLS stają się standardem?

Odpowiedź krótka: nijak. Ale od początku.

Czym jest połączenie SSL?

Połączenie SSL (czy dziś raczej TLS) to połączenia szyfrowane stosowane szeroko w komunikacji przez Internet. Zielona kłódeczka przy adresie strony banku oznacza właśnie, że komunikacja jest szyfrowana i nikt poza operatorem strony a naszą przeglądarką nie ma możliwości odczytania treści komunikacji.

Problem w tym, że SSL/TLS opiera się na systemie certyfikatów wydawanych przez urzędy certyfikacji. Każdy urząd certyfikacji może wydać certyfikat dla dowolnej domeny, a my musimy ufać, że nie będą ich rozdawać komu popadnie. Np. rządom z cenzorskimi zapędami.

Czy można rozpakować transmisję SSL?

Teoretycznie można. Gdyby ktoś uzyskał (wykradł? zażądał?) dostęp do kluczy prywatnych dowolnego z tych urzędów, miałby możliwość swobodnego wydawania certyfikatów dla dowolnej domeny. Czyli mógłby wykonywać atak Person in the Middle: przeglądarce użytkowniczki przedstawiać się ważnym certyfikatem, który samemu sobie wygenerował. Ponieważ sam sobie wygenerował certyfikat, ma powiązany z nim klucz prywatny pozwalający rozszyfrować transmisję. Po jej przejrzeniu (lub ocenzurowaniu jej części), szyfruje wszystko prawdziwym certyfikatem serwera, z którym użytkowniczka chciała się łączyć.

Dla serwera i dla użytkowniczki wszystko wygląda normalnie, tyle że nasz złośliwy atakujący (lub przyjazny agent ABW) ma dostęp do naszej komunikacji – może ją czytać, może też ją modyfikować.

I dotyczy to tak samo losowego bloga, jak i strony naszego banku.

Skąd wziąć klucze?

Można je wykraść. Urzędy certyfikacji powinny bardzo dbać o bezpieczeństwo, ale czasem… no cóż. Oczywiście nikt by nie podejrzewał miłościwie nam panujących o tak niecne metody (ani o odpowiednie kompetencje)!

Więc zamiast tego mogą odpowiednie certyfikaty zwyczajnie kupić. BlueCoat to firma, która oferuje rozwiązania “filtrujące” (czyt. cenzurujące) Sieć, sprawdzone u tak zacnych klientów, jak prezydent Assad. Problem w tym, że BlueCoat ma dziś możliwość wydawania dowolnych certyfikatów dla dowolnych domen. Mówią, że do testów. Ale gdzie jest popyt, znajdzie się podaż.

Dlaczego to kretyński pomysł?

To jednak nadal wymaga kosmicznych nakładów finansowych na sprzęt, który byłby w stanie w czasie rzeczywistym rozpinać SSL/TLS, cenzurować treści, po czym spajać te połączenia na tyle szybko, by nikt nie zauważył. Podejrzewam, że w tym miejscu zgodzi się ze mną autor pytania: to jest zwyczajnie niewykonalne na skalę całego ruchu w kraju.

I tu pojawia się kolejny problem. Skoro ABW rękami operatorów telekomunikacyjnych nie będzie miało jak blokować konkretnych treści przesyłanych bezpiecznymi połączeniami SSL/TLS, to co dokładnie chcą blokować?

Oczywiście ABW może domagać się blokowania adresu IP, pod którym strona jest dostępna. Tu żadne szyfrowanie na poziomie, na którym działa SSL/TLS nie pomoże. Operator ustawia trasę na czarną dziurę, i cześć. Cóż jednak jeśli mówimy np. o grupie na popularnym portalu społecznościowym, który używa SSL/TLS, a na wezwanie ABW do zablokowania tej konkretnej grupy odpowie, że jakby niekoniecznie? Zablokują wszystkie IP tego portalu?

Co jeśli strona, którą ABW chce zablokować, stoi za rozwiązaniem takim, jak CloudFlare? Jeśli CloudFlare nie zgodzi się na zablokowanie danej strony, ABW musiałoby zablokować wszystkie adresy IP CloudFlare, co oznacza, że żadna z milionów stron korzystających z CloudFlare nie będzie dostępna w Polsce. Poprawka: SNI idzie czystym tekstem, nie trzeba więc blokować całego CloudFlare’a by zablokować jedną z domen z niego korzystających.

Jakby nie patrzeć, ABW jest w idiotycznej sytuacji. Rozpinanie ruchu SSL/TLS nie wchodzi w rachubę. Blokowanie całych domen ze względu na jeden wpis też jakby niekoniecznie. Problem w tym, że to nie jest powód, by na artykuł 32c w ustawie antyterrorystycznej machnąć ręką – bo “wszystkich nas nie rozszyfrują”.

To jest powód, dla którego w ogóle takich zapisów nie powinno być. Tymczasem zaś – czas odpalić SSL/TLS na wszystkim.

e-Dockleracje

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

tl;dr e-Deklaracje w dockerze; jeśli chcesz od razu przeskoczyć do informacji, jak z tego skorzystać, by bez walki odpalić je na swoim GNU/Linuksie, kliknij w klikadło

Gdy w 2010r. Ministerstwo Finansów wypuściło program e-Deklaracje (za który dostało nawet od FWiOO zasłużonego “Izydora”), życie użytkowników Linuksa zmieniło się na dwa sposoby.

Po pierwsze, wreszcie mogliśmy oddawać się niewątpliwej przyjemności składania deklaracji podatkowych na naszych wspaniałych, wolnych jak pingwin systemach operacyjnych.

Po drugie, by na tę przyjemność zasłużyć, co roku odprawiać musieliśmy zgoła magiczne rytuały, by rzeczone e-Deklaracje odpalić na nowszej o rok dystrybucji. Zajmowało to zwykle…

A dobę, a pięć…

Problem wynika rzecz jasna ze światłej decyzji oparcia e-Deklaracji o Adobe AIR: zamknięte, własnościowe środowisko uruchomieniowe rozwijane i kontrolowane przez jedną firmę. Firmę znaną z przyjaznego podejścia do systemów operacyjnych spod znaku przyjaznego nielota.

Rzecz jasna niebawem okazało się, że Adobe nie zamierza rozwijać dalej wersji AIR na Linuksa.

Plus jest taki, że zwolennicy wolnego oprogramowania dostali kolejny argument za tym, by instytucje publiczne nie opierały swych działań na zamkniętym oprogramowaniu. Minusem jest konieczność kombinowania, jak by tu coraz bardziej starożytne środowisko odpalić na nowoczesnych dystrybucjach…

A gdyby tak odpalać cały ten majdan na równie antycznej dystrybucji? Wszak i tak odpalany jest tylko raz na rok, na te kilkadziesiąt minut potrzebnych na wypełnienie i wysłanie deklaracji, po czym znów idzie w odstawkę.

Może maszyna wirtualna? To jednak zbyt dużo zabawy, miejsca na dysku, zasobów… Da się inaczej?

Enter the Docker

Docker ułatwia korzystanie z kontenerów – lżejszych braci maszyn wirtualnych. Nie wchodząc w szczegóły, docker ułatwia i automatyzuje tworzenie bardzo dokładnie kontrolowanych środowisk. Coś jak maszyna wirtualna, tyle że wymagająca znacznie mniej zasobów.

“Jak pomyślał, tak zrobił” – et voilà! Zdokeryzowane e-Deklaracje, for your tax reporting pleasure!

Chcę! Jak?

Są dwa wymagania systemowe: docker oraz jądro Linuksa w wersji 3.8 lub późniejszej. Użyszkodników wersji Ubuntu starszych niż 14.04 zapraszam tu; Debiana Wheezy – tu. Gentowcy i pochodni, jestem pewien, poradzą sobie sami.

Jeśli natomiast używamy dowolnego smaku Ubuntu w wersji 14.04 lub nowszej, dockera mamy w repozytoriach:

sudo apt-get install docker.io

Przyda się też dodanie naszego juzera do odpowiedniej grupy:

sudo adduser $USER docker sg docker

Teraz kod. Dla gitowców:

git clone https://git.hackerspace.pl/rysiek/e-dockleracje cd e-dockleracje

Dla reszty świata:

wget https://git.hackerspace.pl/rysiek/e-dockleracje/snapshot/e-dockleracje-master.tar.bz2 tar -xjf e-dockleracje-master.tar.bz2 cd e-dockleracje-master

W tym momencie mamy wszystko, co potrzeba. Uruchamiamy:

./edeklaracje.sh

…i czekamy. Docker pobiera podstawowy obraz Ubuntu 13.10, instaluje w nim konieczne pakiety, pobiera Adobe AIR, Acrobat Readera i same e-Deklaracje, instaluje wszystko, i wreszcie – uruchamia nam e-Deklaracje. Prosto z wydzielonego kontenera, ale z dostępem do naszego dotychczasowego katalogu konfiguracyjnego e-Deklaracji, o ile istnieje.

Budowanie musi zrobić tylko raz, więc następne uruchomienia będą znacznie szybsze.

Pochwała Copyleftu

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

Tekst powstał na potrzeby publikacji pokonferencyjnej po CopyCamp 2014, w ramach której publikowana jest wersja angielska. Zachęcam do zapoznania się z całą publikacją, oraz do odwiedzenia konferencji CopyCamp jesienią tego roku.

Free as in Freedom, not free as in beer

Ten cytat z Richarda M. Stallmana, doskonale znany zwolennikom wolnego oprogramowania, wynika z prostej potrzeby wyjaśnienia dwuznaczności w języku angielskim – “free” może znaczyć “wolny”, może też znaczyć “darmowy”; oba znaczenia przy tym mają sens w kontekście oprogramowania. Stał się też niejako deklaracją programową ruchu wolnego oprogramowana.

Wiele inicjatyw czerpie garściami z filozofii wolnego oprogramowania – ruch wolnej kultury, Wikipedia, wolne zasoby edukacyjne i wiele innych opierają się na ideach wypracowanych i przetestowanych w wolnych i otwartych projektach informatycznych. Myśl “free as in freedom, not free as in beer” jest więc bliska również im.

Zwykliśmy kłaść nacisk i akcentować przede wszystkim pierwszą część tego cytatu. To o wolność chodzi, można by rzec, nie o to, czy coś jest darmowe, czy nie. Takie akcentowanie potrzebne było (i jest), by wyraźnie oddzielić oprogramowanie, kulturę czy zasoby edukacyjne, które dają odbiorcom wolność, od tych, które są tylko darmowe – dających dostęp, ale odmawiających pozostałych czterech wolności.

Coraz bardziej jednak wyraźna staje się potrzeba zmiany akcentu. Twórcy oprogramowania, kultury i zasobów edukacyjnych, wolnych czy nie, też muszą jeść.

Cztery Wolności

Richard Stallman wprowadził proste i skuteczne kryterium tego, czy oprogramowanie (swobodnie możliwe do zastosowania również w innych dziedzinach) jest wolne – jego licencja powinna gwarantować:

  • wolność uruchomienia w dowolnym celu;
  • wolność modyfikacji;
  • wolność rozpowszechniania;
  • wolność rozpowszechniania własnych modyfikacji.

Aby jednak skutecznie powiększać zbiór wolnego oprogramowania, w pierwszej wolnej licencji na oprogramowanie, GNU GPL, zastosowano jeszcze jeden trick – copyleft, czyli wymóg, by oprogramowanie opierające się na udostępnianym na niej wolnym programie same były udostępniane na tej samej licencji.

Warunek copyleft stał się wewnątrz społeczności wolnego i otwartego oprogramowania zarzewiem zażartej, trwającej do dziś dyskusji.

Jego przeciwnicy preferują licencje niecopyleftowe, jak MIT czy BSD, zwolennicy – opowiadają się za GNU GPL i pochodnymi.

Pierwsi argumentują, że warunek copyleft ogranicza prawa twórcy dzieła zależnego (np. programu opartego o oprogramowanie na licencji GNU GPL), nie może on bowiem (jeśli swój program w ogóle udostępnia) zdecydować o nie udostępnianiu swojego programu na wolnej licencji.

Drudzy wskazują, że choć być może twórca ten faktycznie nie ma już możliwości wyboru licencji, jednak dzięki temu zabiegowi wszyscy inni – w tym użytkownicy jego programu – mają zagwarantowane cztery wolności, które mieli zagwarantowane w przypadku programu źródłowego.

Innymi słowy, debata toczy się pomiędzy wolnością twórcy adaptacji do zamknięcia swojej adaptacji dzieła na wolnych licencjach, a wolnością wszystkich odbiorców, zawsze.

“Adaptacji” i “odbiorców”, ponieważ dyskusja ta wylała się oczywiście poza świat wolnego oprogramowania, i równie zaciekle toczy się w kontekście wolnych zasobów i wolnej kultury.

Modele biznesowe

Zarówno w świecie oprogramowania, jak i poza nim, warunek copyleft ma renomę “niedobrego dla biznesu”. Twórcy adaptacji chcieliby mieć możliwość zamykania swoich adaptacji prac na wolnych licencjach, by móc na nich zarabiać – a jak zarabiać na czymś, co można kopiować do woli?

Odpowiedzią są modele biznesowe zgodne z kulturą daru, kulturą dzielenia się. Finansowanie społecznościowe, modele oparte na dobrowolnych wpłatach, zarabianie na produktach powiązanych (np. koszulki zespołów) czy koncertach, zaś w przypadku oprogramowania sprzedaż usług (jak wdrożenie, dostosowanie do potrzeb, wsparcie, itp) pozwalają artystom i twórcom utrzymać się mimo, a czasem wręcz dzięki swobodnemu dzieleniu się ich twórczością przez fanów.

Modele te są nieoczywiste, wydają się niepewne – a jednak coraz częściej finansują duże nawet produkcje. Z drugiej strony, “klasyczne” modele nie gwarantują przecież sukcesu. Tym bardziej, że oparty na nich rynek zagospodarowany jest od dawna, np. przez wielkie wytwórnie fonograficzne.

Można odnieść wrażenie, że stosowanie niecopyleftowych licencji to często wyraz braku zaufania do nowych modeli, wynik przemyślenia w stylu “a może kiedyś będę chciał oprzeć na tym jakiś zamknięty produkt, co wtedy?” Jeśli jednak ja mogę zamknąć, mogą zamknąć i inni. Wszyscy na tym tracimy.

Heartbleed

Doskonale ilustruje to sprawa Heartbleed, czyli poważnego błędu w popularnej bibliotece wykorzystywanej przez dużych i małych do szyfrowania transmisji w Internecie . Błąd był trywialny, miał jednak potężne konsekwencje dla całego ekosystemu wolnego oprogramowania, i szerzej: niemal całego Internetu. Pozostawał też niewykryty przez kilka lat.

Oprogramowanie, którego dotyczył – biblioteka OpenSSL – udostępniana jest na licencji niecopyleftowej. Zachęca to firmy, również te duże, do korzystania z niej w swych produktach i usługach, co też chętnie robią. Z OpenSSL korzysta m.in. Google, Facebook, Amazon.

Korzysta – ale niespecjalnie dokłada się do rozwoju tej kluczowej biblioteki. Twórcy OpenSSL nie mieli dość środków na regularny audyt kodu, co było jedną z przyczyn, dla których Heartbleed mógł pozostawać niezauważony.

Duzi gracze nie dzielą się też kodem, swoimi zmianami w oprogramowaniu, z którego korzystają. Licencja tego nie wymaga, czemu więc miałyby to robić? Okazuje się, że Facebook używał zmodyfikowanej wersji OpenSSL. Zmiany w niej wprowadzone (prawdopodobnie całkiem przypadkiem) spowodowały, że była ona niepodatna na błąd Heartbleed.

Gdyby OpenSSL był na licencji wymagającej udostępnienia kodu i zmian społeczności, być może błąd zostałby wykryty znacznie wcześniej, kiedy jeszcze nie był tak groźny.

Not free as in beer

Rozwój wolnego oprogramowania, wolnej kultury, wolnych zasobów edukacyjnych kosztuje. Tysiące ludzi poświęcają swój czas, wiedzę i umiejętności, i dzielą się efektami swej pracy. Często zapominamy o tym, np. argumentując za wolnym oprogramowaniem podkreślamy, że jest “darmowe”.

Nie jest. Czas nauczyć się doceniać pracę w nie wkładaną. Również finansowo.

Copyleft wbrew pozorom może tu pomóc: skoro nikt nie może zamknąć mojej pracy, sam mogę korzystać z cudzych jej ulepszeń. Wszyscy na tym zyskujemy.

Zmiana klucza GPG

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

Wszem i wobec – zmieniam klucz GPG, ze starego:

07FD 0DA1 72D3 FC66 B910 341C 5337 E3B7 60DE C17F

…na nowy:

D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E

Bezpieczeństwo starego klucza nie zostało naruszone. Głównym powodem zmiany jest ten słaby podklucz:

sub1024R/0x085C4F046A46EBC9

Wygenerowałem nowy, znacznie silniejszy klucz. Przy okazji dbając o to, by zabezpieczyć się (w jakimś zakresie) przed potencjalnie paskudnymi konsekwencjami utraty klucza prywatnego (np. wraz ze skradzionym laptopem). Skorzystałem z tych trzech tutoriali (niestety, po angielsku):

Z ich pomocą stworzyłem parę kluczy master, przechowywaną w bezpiecznym miejscu; oraz parę kluczy laptopowych, do codziennego użytku.

Para master nigdy nie znalazła się na moim laptopie, ani na żadnym innym urządzeniu, którego na co dzień używam – została wygenerowana na oddzielonym od sieci losowym “niczyim” laptopie, jednym z kilku zalegających w Warszawskim Hackerspace (każdy hackerspace na świecie pewnie ma takich kilka). Na laptopie uruchomiłem TAILSa.

Z pary master wygenerowałem z kolei (również na tym samym losowym laptopie) parę laptopową. Parę master przeniosłem w bezpieczne miejsce, laptopową – na laptopa. Obie zostały bezpiecznie wymazane z maszyny, na której były tworzone (na wszelki wypadek; i tak wszystko działo się na ramdysku).

Rozdzielenie kluczy na master i laptop oznacza, że nie mogę podpisywać cudzych kluczy na bieżąco – mogę to zrobić wyłącznie gdy mam dostęp do pary master, której oczywiście ze sobą nie wożę.

Komunikat o zmianie klucza

Poniżej znajduje się mój komunikat o zmianie klucza. Wersja podpisana oboma kluczami dostępna jest do ściągnięcia.

Komunikat o zmianie klucza GPG Data: 30 grudnia 2014

Z wielu powodów stworzyłem ostatnio nowy klucz OpenPGP, którego od teraz będę używał, porzucając klucz stary.

Stary klucz będzie nadal ważny przez jakiś czas, ale wolałbym, by wszelka przyszła korespondencja korzystała już z nowego klucza. Chciałbym też, by nowy klucz został zintegrowany do sieci zaufania. Niniejsza wiadomość podpisana jest oboma kluczami, by ją uwiarygodnić.

Stary klucz to:

pub 4096R/0x5337E3B760DEC17F 2011-09-28 [2015-01-31](wygasa:) Odcisk palca = 07FD 0DA1 72D3 FC66 B910 341C 5337 E3B7 60DE C17F

Nowy klucz to:

pub 4096R/0xEAA4EC8179652B2E 2014-10-14 [2020-10-12](wygasa:) Odcisk palca = D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E

By pobrać cały klucz z publicznego serwera kluczy, możesz zwyczajnie:

gpg --keyserver keys.riseup.net --recv-key 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'

Jeśli zaś masz już mój stary klucz, możesz upewnić się, że nowy klucz jest podpisany kluczem starym:

gpg --check-sigs 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'

Jeśli nie masz mojego mojego starego klucza, lub chcesz się dodatkowo upewnić, że wszystko gra, możesz porównać odciski palca kluczy:

gpg --fingerprint 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'

Gdy jesteś usatysfakcjonowany i pewny, że masz właściwy klucz, i że UIDy kluczy zgadzają się z oczekiwanymi, byłbym zobowiązany za podpisanie mojego nowego klucza. Można to zrobić za pomocą komendy:

** UWAGA: jeśli mój klucz jest już przez Ciebie podpisany, ale wyłącznie lokalnie (lsign), użyj komendy –lsign-key zamiast tego, co poniżej, i nie wysyłaj podpisów na serwer kluczy **

gpg --sign-key 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'

Chciałbym w miarę możliwości otrzymać Twoje podpisy mojego klucza. Możesz mi je wysłać mailem, jeśli masz działające MTA na swoim systemie):

gpg --export 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E' \ | gpg --encrypt -r 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E' \ --armor | mail -s 'Podpisy OpenPGP' rysiek@hackerspace.pl

Przy okazji – mocno sugeruję wdrożenie mechanizmu automatycznego odświeżania kluczy w celu otrzymywania na bieżąco rewokacji i innych aktualizacji stanów kluczy. Można do tego użyć parcimonie – daemona, który powoli, w tle, odświeża klucze z serwerów kluczy przez Tora. Używa losowego czasu przerw pomiędzy kolejnymi akcjami, i oddzielnych tras w sieci Tor dla każdego z kluczy. Oznacza to, że ciężko byłoby komukolwiek skorelować aktualizacje kluczy z Twoim zestawem kluczy.

Gorąco też zachęcam do zapoznania się z najlepszymi praktykami dotyczącymi GPG, zebranymi przez RiseUp; stamtąd bezczelnie ukradłem większość angielskiego tekstu niniejszej wiadomości. ;-)

https://help.riseup.net/en/security/message-security/openpgp/best-practices

Jeśli pojawią się jakieś pytania bądź problemy, proszę o znak sygnał – i przepraszam za zamieszanie.

Michał “rysiek” Woźniak rysiek@hackerspace.pl http://rys.io/

Siła wyższa

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

Jakkolwiek nie jestem wielkim zwolennikiem przepływu celebrytów i celebrytek do polityki – mamy, jak sądzę, lepsze źródła kompetencji intelektualnych niezbędnych do rządzenia w naszym pięknym kraju – to jednak wolę wyborców wypada uszanować.

Z tejże woli wyborców do sejmiku wielkopolskiego weszła Katarzyna Bujakiewicz, którą posiadający telewizory czytelnicy mogą kojarzyć z tak wiekopomnych projektów artystycznych, jak seriale “Na dobre i na złe” czy “Magda M”.

Ja jednak radną Bujakiewicz kojarzyć będę jednak z tego, jak krótko sprawować będzie swój mandat, oraz (i przede wszystkim) ze względu na powód, dla którego mandatu sprawować nie będzie dłużej.

To nie jest jej zła wola czy lekceważenie wyborców. Po prostu w oświadczeniu majątkowym, jakie musi złożyć każdy radny, nie może ujawnić niektórych swoich dochodów z komercyjnych kontraktów aktorskich. Za kłamstwo grozi kara pozbawienia wolności, a za niezłożenie tylko wygaśnięcie mandatu. To drugie wyjście jest bardziej uczciwe – mówi jeden ze sztabowców komitetu Teraz Wielkopolska.

Sztabowca komitetu Teraz Wielkopolska zachęcam do rozważenia, czy aby nie pominął pewnych możliwości wyjścia z sytuacji. Skoro tak lekko podchodzimy do tematu zerwania swego rodzaju kontraktu pomiędzy radną Bujakiewicz, a jej wyborcami, może moglibyśmy przynajmniej wziąć pod uwagę, że przecież kontrakt z dotychczasowymi pracodawcami radnej również można zerwać?

Czy dowiemy się, jakie konsekwencje groziły by radnej w takim wypadku. Oczywiście, że nie. Są wszak rzeczy ważne i ważniejsze. Głos wyborców jest ważny; komercyjny kontrakt radnej Bujakiewicz z producentami bawiących tych wyborców seriali jest jednak, jak widać, ważniejszy.

No cóż. Kamyczek do ogródka sceptycyzmy względem celebrytów i celebrytek próbujących swych sił w polityce.

Internet jednak bez pornografii?

To jest bardzo stary wpis, opublikowany ponad 4 lata temu.
Możliwe, że nie odzwierciedla dziś poglądów Autora lub zewnetrznych faktów. Jest zachowany jako wpis historyczny.

Na 3 dni nie można wyjechać i zostawić posłów samym sobie, bo zaraz coś zmalują.

Sejmowa Komisja Administracji i Cyfryzacji przyjęła dziś projekt “Uchwały w sprawie działań na rzecz ograniczenia dostępu dzieci do pornografii w Internecie”, dawniej “wzywającą Ministra Administracji i Cyfryzacji do zagwarantowania rodzicom prawa do Internetu bez pornografii” – ostatecznego druku nie ma jeszcze na stronach Sejmu, ale zapewne pojawi się tu.

W porównaniu z oryginalnym projektem, nowy tekst jest… lepszy, choć nie znaczy to, że dobry. Oto on (pomijam nieistotną w zasadzie rozbiegówkę w stylu “zważywszy, że…”):

UCHWAŁA

Sejmu Rzeczypospolitej Polskiej z dnia ……………..

W sprawie działań na rzecz ograniczenia dostępu dzieci do pornografii w Internecie

(…)

  1. Sejm Rzeczypospolitej Polskiej wnosi o przygotowanie przez Ministra Administracji i Cyfryzacji rozwiązań, które zagwarantują rodzicom prawa dostępu do sieci internetowej wolnej od pornografii.
  2. Rozwiązania te powinny uwzględniać następujące wytyczne:
    1. Każda osoba powinna mieć możliwość blokowania przesyłania treści o charakterze pornograficznym;
    2. Dostawca usług internetowych powinien dostarczyć narzędzia, które umożliwią blokowanie przesyłania treści o charakterze pornograficznym;
    3. Dostawca usług internetowych jest zobowiązany do zapewnienia narzędzi, które umożliwią blokowanie przesyłania treści o charakterze pornograficznym, nieodpłatnie;
    4. Dostawca usług internetowych może wyłączyć dostęp do treści o charakterze pornograficznym. Powinno to znaleźć odzwierciedlenie w umowie z klientem.
  3. Minister Administracji i Cyfryzacji przedstawi projekt rozwiązań w ciągu 18 miesięcy od dnia podjęcia niniejszej uchwały.

Ale jak to?

Tak to. Komisja zwołała posiedzenie w tej sprawie tydzień po poprzednim, nie dając czasu na sensowne przygotowanie się i merytoryczną dyskusję. Szczęście w nieszczęściu, że tekst uchwały został zmieniony na coś, co nie jest już kompletnym absurdem (a jedynie trochę, w zależności od tego, kto czyta).

Co to znaczy?

Tekst uchwały można czytać tak, by odpowiedzią MAiC mogło być:

Istnieją filtry rodzicielskie na każdą platformę, dziękuję, pozdrawiam.

…można też czytać tak, by odpowiedzią musiało być:

ISPs muszą “dobrowolnie” wprowadzić cenzurę sieci na poziomie własnej infrastruktury, opt-in lub opt-out.

To znaczy, że trzeba zadbać o to, by (jeśli uchwała przejdzie przez Sejm) rozwiązanie przygotowane przez MAiC nie oznaczało konieczności wprowadzenia centralnego filtrowania Sieci.

Jedyne wyjście, jakie widzę, to filtrowanie na poziomie urządzeń końcowych (w tym np. routerów domowych). W trakcie konsultacji społecznych w zeszłym roku na dokładnie ten sam temat, dokładnie taką propozycję rozwiązania przedstawiliśmy Ministerstwu. Czas je odkurzyć.

Co teraz?

Teraz czas na decyzję Sejmu, która zapewne zapadnie w najbliższych tygodniach. Niestety, projekt tak zmodyfikowany ma najwyraźniej poparcie koalicji, więc zapraszam do pisania do posłów i posłanek, a tymczasem przygotowuję się na 18-miesięczną walkę o to, byśmy nie mieli filtrów ani przymusowych ani “dobrowolnych” (jak w Wielkiej Brytanii) gdziekolwiek indziej, niż na urządzeniach końcowych.

To oznacza mnóstwo pracy; jeśli uważacie, że jest cenna i ważna – ponawiam apel o wsparcie Panoptykonu.