Wybory – sytuacja, pomysły

Początkowo z wyborami było trochę śmiesznie (no dobrze, śmiech przez łzy), zrobiło się trochę strasznie (okupacja PKW, nie ma zgody na kwestionowanie wyników przez miłościwie nam panującego, wygrana PSL). Pojawiły się też głosy o konieczności stworzenia otwartego, wolnoźródłowego systemu i inicjatywy w tym temacie. Cieszy, bo oznacza, że to nie moje paranoje i pomysł ma sens.

Trochę na FB pisałem, ale to znika, więc dla pamięci (i szerszego grona). Do głowy przyszedł mi wariant minimum. Zaznaczam, że bazuje na starych procedurach ręcznych (ale cóż więcej trzeba?) i starych, sprawdzonych technologiach, choć korzystając z nowych warunków.

Wystarczyłoby, żeby komisje wysyłały proste tekstowe dokumenty o ustalonym formacie (formatkę, czyli odpowiednik protokołu powinny dostać wcześniej) przy pomocy emaila (stara sprawdzona technologia, dobrze się skalująca). W ramach ustalenia autentyczności i tajności[1] podpisanego/zaszyfrowanego GPG. Oczywiście członkowie komisji (a przynajmniej 2-3 z każdej komisji) musieli by mieć potwierdzone klucze, ale z tym nie ma problemu – i tak są na szkoleniu dla członków komisji. Maila każdy w dzisiejszych czasach ma (wystarczą 2-3 osoby z komisji, powtórzę) i wysłać umie. Czyli tak, wysyłali by wyniki podpisane GPG z dowolnych, nawet prywatnych, darmowych kont. Potwierdzenie dostarczenia jest opcjonalne (delivery notification), ale dostępne w programach pocztowych, czyli komisja wie, czy/kiedy protokół dotarł do serwera poczty PKW. Z nowoczesnych dodatków i zwiększania wiarygodności – można załączyć „skany” papierowego protokołu. Wystarczy smartfon z aparatem (znaczy: smartfon)…

Po stronie serwera email PKW nic specjalnego się nie dzieje. Jeśli chodzi o dalszą część serwerową, to program do liczenia łączy się do serwera poczty, odbiera maila, na podstawie tematu przypisuje do komisji (albo z treści formularza…). Następnie weryfikuje autentyczność podpisu GPG i w przypadku zgodności parsuje plik tekstowy.

Gdyby pliki były wysyłane w dokładnie określonym formacie, to całość jest do naklepania w Perlu w parę godzin. No ale pewnie nie będą, bo maile umożliwiają dość dużą dowolność formatu wysyłki pliku i co program, to wynalazki… (szczególne ukłony w stronę Microsoft). Można się bawić oczywiście w napisanie prostego klienta poczty dla komisji. Zaleta rozwiązania jest taka, że po wyborach PKW może udostępnić publicznie wyniki. Albo wręcz przeforwardować wyniki z danej komisji wszystkim zainteresowanym, którzy np. wcześniej zgłoszą takie zapotrzebowanie.

W kontekście wysokiego wyniku PSL i ponownie sporej ilości głosów nieważnych dla przypomnienia kawałek historii:

wybory 2010 głosy nieważne

Źródło: http://uczciwe-wybory.pl/analiza-glosow-niewaznych-wyborach-parlamentarnych-2005-2007-2011-samorzadowych-2010/

W odpowiedzi na to kolejny pomysł – kamery w komisjach i albo streaming online, albo przynajmniej rejestracja i udostępnienie obywatelom bezpośrednio po wyborach[2]. Jeśli jest podejrzenie fałszowania głosów przez członków komisji (a właśnie o dostawianiu krzyżyków mowa), to powinno to rozwiązać problem. Plus obowiązek przebywania głosów „na oczach kamer” od momentu wyjęcia ich z urny do czasu sporządzenia protokołu przez komisję.

W ten sposób obywatele mieliby możliwość prostego zweryfikowania wyborów ze swojej komisji i nadzorowania pracy (przypomnę, po zamknięciu lokali poza członkami komisji i mężami zaufania obywatele nie mają dostępu do lokali).

[1] Tajność wygląda na zbędną. Wysyłki są dokonywane już po zamknięciu lokali, więc nie ma potrzeby utajniać wyniku.

[2] Zdaję sobie sprawę, że danych jest sporo i nakłady na infrastrukturę (kamery plus streaming) nie są małe. Być może wystarczyłaby możliwość montowania kamer (z publicznym streamingiem) przez obywateli.

Porażka systemu wyborczego PKW

Jak powszechnie wiadomo, przy wyborach samorządowych zaliczyliśmy malowniczego w tym roku malowniczego faila. Nie, żeby było to trudne do przewidzenia, biorąc pod uwagę błędy w zabezpieczeniach widoczne już wcześniej. No, ale powiedzmy, że niezabezpieczenie maszyn developerskich może się zdarzyć najlepszym i nie musi rzutować na zachowanie produkcji.

Tak się składa, że w pewnym okresie mojego życia miałem regularne doświadczenia z komisjami. Pierwszy raz pracowałem w komisji dawno temu, gdy jeszcze każdy mógł się zgłaszać samodzielnie (a nie przez partię) i było losowanie wśród zgłoszonych. Miało to pewne wady, więc zmieniono sposób zgłaszania kandydatów do komisji – musiały robić to komitety wyborcze. I z tym sobie poradziłem, bo zawsze znalazł się ten czy inny komitet wyborczy, który nie wymagał bycia partyjnym aktywistą i po prostu zgłaszał studenta, który chciał sobie dorobić. Tu też mam pewne ciekawe doświadczenia i przemyślenia, ale to może przy innej okazji. Koniec końców, w młodym wieku miałem całą procedurę dobrze opanowaną, parokrotne doświadczenie, spory dystans do którejkolwiek partii politycznej… Jednym słowem, bezstronny wyborczy gun for hire.

Zwieńczeniem mojej kariery okołowyborczej było wystawienie mnie przez jeden z komitetów jako… męża zaufania. Tu akurat znajomi organizowali partii kampanię i szukali zaufanych ludzi znających się na rzeczy. Pamiętam, że już wtedy średnio się kwapiłem do pracy w komisjach ze względu na stawki. No ale jako mąż zaufania jakoś lepsze pieniądze dostałem (a pracy mniej), więc jakoś poszedłem.

Pamiętam, że były to chyba pierwsze „zinformatyzowane” wybory. Pamiętam, że samo liczenie poszło komisji, nawet sprawnie, natomiast pojawiły się „problemy z systemem”. IIRC rzecz działa się w szkole. Szkolny informatyk robił za obsługę informatyczną lokalu i rozłożył ręce przy wprowadzaniu. System „nie przyjmował” danych z karty (poprawnie wypełnionej). IIRC poszło m.in. o nieprzyjmowanie ilości kart nieważnych innej niż zero. Komisja wpadła na pomysł, że w sumie w takim razie najprościej będzie… poprawić na protokołach na zero, bo w sumie i tak nieważne. I byliby to chyba zrobili, gdybym nie uświadomił, że od razu mogą wpisać mój protest na protokole i najpewniej do rana nie wyjdą, bo centrala ich cofnie do poprawki.

Atmosfera na moment zgęstniała, ale niedługo później okazało się, że nie tylko my mamy problem (wcześniej jakoś nikt takiej informacji nie udzielił), nie działa więcej rzeczy i przyszło z centrali zarządzenie, że olać system informatyczny, przechodzimy na ręczne. Czyli, że robimy wszystko po staremu i wszystko mamy gotowe do zawiezienia. Tak czy inaczej, wtedy system zaliczył malowniczą porażkę. Swoją drogą przez tego typu akcje (robisz dobrze, siedzisz parę godzin dłużej) i brak przewidywalności czasu trwania pracy (bo w komisji jednak różni ludzie się trafiają) zniechęciłem się ostatecznie do siedzenia w komisjach.

Teraz mamy powtórkę. Znajomi z IT są bardzo rozbawieni słysząc o problemach z 3 tys. jednoczesnych połączeń. Nie dziwię się. Zaprojektowanie systemu, który przyjmie dane nie jest trudne. Dziwi mnie – i nie tylko mnie – co innego. Mianowicie, czemu co roku projektuje się i wykonuje system od zera, bez żadnego doświadczenia z lat ubiegłych? Jaki byłby problem z tym, żeby specyfikacja protokołu była prosta i jawna, część zarówno serwerowa, jak i kliencka rozwijana jako open source i używana ponownie przy każdych wyborach? Przecież format protokołu praktycznie się nie zmienia. I jest bardzo prosty. Spokojnie można studentom jako zadanie na zaliczenie semestru zadać opracowanie formatu przesyłu danych[1]. Dokumentacja systemu też na wolnej licencji, żeby łatwo można było odtworzyć – i w razie potrzeby poprawić – środowisko.

Żeby nie było, że tylko firma winna, IMHO sporą winę za sytuację ponosi PKW, która powinna być w stanie w dowolnym momencie przejść skutecznie na system ręczny. Informatyzacja wyborów to jedynie bonus, nie ich sedno. Ale u nas pokutuje wciąż – nie tylko przy wyborach – bożek systemu informatycznego, najwyższej wyroczni i zarazem wykładni. System nie pozwala i koniec, bo system to rzecz święta.

Na Niebezpieczniku jest dobry artykuł nt. wyborów, w którym jest więcej informacji nt. systemu oraz przyczyn porażki. Osobiście najbardziej przerażony jestem tym, co tam wyczytałem:

Nikt nie weryfikuje protokołów papierowych opracowanych przez GKW i wprowadzonych do kalkulatora a następnie zatwierdzonych przez TKW o ile nie pojawią się protesty wyborcze, bodajże po 30 dniach od upłynięcia czasu na zgłaszanie protestów protokoły oryginalne są utylizowane, na kolejnych szczeblach sprawdzana jest tylko suma kontrolna. (chodzi o skan kodu z protokołu papierowego i jego porównanie z sumą kontrolną danych dostarczonych elektronicznie — dop. red.)

Mam nadzieję, że suma kontrolna jest wyliczana w taki sposób, że weryfikuje jednocześnie dane nt. oddanych głosów. Tak czy inaczej spodziewałbym się, że w tak ważnym wydarzeniu nie będzie polegać się tylko na widzimisię wprowadzającego, tylko ktoś dane z papierowego protokołu wklepie dla pewności jeszcze raz. Bo prosta suma kontrolna, czy też suma kontrolna o znanym algorytmie wyliczania jak najbardziej zabezpieczy przed literówką, ale nie przed celową manipulacją (partii A dodać 50, partii B odjąć 10, partii C odjąć 40). A do komputera nie wprowadza komisja, tylko pojedynczy operator.

[1] Przynajmniej za czasów moich studiów można było, nie wiem jaki teraz jest poziom na uczelniach. Z systemem już bym nie polegał na studentach, tu się jednak trochę praktyki przydaje.

Przyspieszanie łącza internetowego

Wpis, który przeleżał jako szkic ponad rok. I bardziej go już nie skończę, więc publikuję, jak jest. Miały być testy i dokładne konfiguracje, ale z braku czasu będzie czysta teoria. Tak czy inaczej myślę, że przyda się ludziom z wolnymi łączami lub korzystającym z WWW (i nie tylko…), a chcącym zminimalizować ilość przesłanych danych do urządzenia końcowego. Do rzeczy.

Na podstawie doświadczeń z Aero2, czyli łącza zarówno wolnego (niska przepływność) jak i zlagowanego (duże opóźnienia pakietów), postanowiłem popełnić krótki poradnik, jak przyspieszyć działanie sieci na wolnym łączu internetowym. Zwykle zakładam w tym poradniku, że użytkownik korzysta z Linuksa, ale nie zawsze i część sposobów przyda się niezależnie od systemu.

Krok pierwszy – przyspieszanie zapytań DNS

Ważna sprawa, bo serwery DNS odpytywane są coraz częściej. Otwarcie pojedynczej strony internetowej to w dzisiejszych czasach często kilkanaście, a nawet kilkadziesiąt zapytań do serwerów DNS. W przypadku zlagowanego połączenia do każdego zapytania dochodzi opóźnienie łącza. Można sobie pomóc poprzez wykorzystanie lokalnego cache DNS. Z prostych w konfiguracji polecam opisany kiedyś dnsmasq lub lekki i wydajny unbound. Cache DNS działa dla całego systemu, nie tylko dla stron WWW, ale w ich przypadku różnica powinna być najbardziej widoczna. Dodatkowa zaleta to uniezależnienie się od potencjalnych problemów z serwerami DNS naszego dostawcy łącza.

Krok drugi – kompresja danych

Mechanizm kompresji danych na wolnym odcinku nie jest niczym nowym. Od dawna z powodzeniem stosuje go Opera w swojej funkcji turbo. Pierwsza obróbka strony odbywa się na ich serwerach, które dysponują szybkimi łączami. Dodatkowo może się odbywać redukcja zbędnych elementów. Zaletą rozwiązania jest łatwość uruchomienia – wystarczy kliknąć przycisk w Operze. Wadą rozwiązania jest to, że wymaga korzystania z Opery i działa tylko dla stron WWW.

Kompresja danych – DIY

ziproxy

Jeśli mamy dostęp do serwera (może być VPS) z Linuksem, możemy w prosty sposób stworzyć podobne rozwiązanie samodzielnie, korzystają z programu ziproxy. Instalujemy je na serwerze, konfigurujemy, jak bardzo mają być redukowane grafiki (60-70% wygląda znośnie), ustawiamy adres IP i port serwera jako proxy w przeglądarce i.. tyle. Od tej pory przez wolne łącze przesyłane są zredukowane (stratnie, zatem gorzej wyglądające) obrazy. Reszta danych jest przesyłana w postaci skompresowanej.

Zaleta jest taka, że działa z każdą przeglądarką i – dla paranoików – że nasze dane nie błądzą po serwerach Opery.

Wady: działa tylko dla WWW, stopień redukcji obrazów ustala się raz, nie ma możliwości dynamicznej zmiany jakości (np. obejrzenie wybranych obrazów w lepszej jakości).

sshuttle

Jeśli mamy dostęp do serwera z Linuksem i dodatkowo ma on zainstalowanego Pythona, to możemy skorzystać z VPN over SSH, czyli shuttle. Rozwiązanie powstało jako namiastka VPN i miało pierwotnie bardziej zapewniać bezpieczeństwo transmisji (szyfrowanie) w przypadku otwartych hotspotów. Można je jednak skonfigurować tak, aby ruch był kompresowany (wykorzystanie kompresji SSH).

Zaletą jest to, że działa dla całego ruchu (TCP), nie tylko dla WWW. Można określić, do których sieci ruch ma być obsługiwany przez to rozwiązanie.

Wada: działa tylko dla TCP (oraz zapytań DNS), wymaga zainstalowanego Pythona na maszynie pełniącej rolę serwera.

ssh + socks proxy

Jeśli nie chcemy instalować dodatkowego oprogramowania, a mamy dostęp do serwera z Linuksem, możemy w prosty sposób wykorzystać tunelowanie SSH oraz – podobnie jak w poprzednim przypadku – wykorzystać kompresję oferowaną przez SSH. W tym celu ustawiamy socks proxy w przeglądarce na localhost oraz port 9000, oraz uruchamiamy ssh -CND 9000 user@serwer. Od tej pory ruch WWW tunelowany jest przez SSH do serwera. Jeśli zależy nam nie tylko na wydajności, ale i na prywatności, warto sprawdzić ustawienia przeglądarki dotyczące przesyłania zapytań DNS przez proxy.

Zaleta: łatwość uruchomienia (na systemach *nix).

Wady: działa tylko dla ruchu WWW (lub jawnie przetunelowanego z innych aplikacji), wymaga przeglądarki WWW ze wsparciem dla socks proxy (praktycznie każda sensowna ma tę opcję dostępną w ten lub inny sposób).

OpenVPN

Ostatni sposób to wykorzystanie OpenVPN oraz wbudowanej kompresji. Wymaga skonfigurowanego OpenVPN zarówno po stronie klienta jak i serwera.

Zalety: działa dla wszystkich rodzajów ruchu.

Wady: wymaga zainstalowania i skonfigurowania OpenVPN. Dochodzi narzut CPU na szyfrowanie (domyślnie będzie włączone, zwł. u zewnętrznych providerów).

Oczywiście cudów nie ma i ww. sposoby pomogą jedynie dla treści, które przesyłane są jako nieskompresowane i dobrze się kompresują. Nie ma co liczyć, że filmy na YouTube zaczną działać szybciej. Osobiście idę na łatwiznę i korzystam zwykle z ssh i socks proxy.