Poznański Budżet Obywatelski i CAPTCHA

Jak co roku można było głosować na Poznański Budżet Obywatelski. Wszedłem na stronę, zobaczyłem CAPTCHA i… zaniemówiłem. Implementacja, którą zobaczyłem była prostsza do połamania (czyt.: rozwiązania automatem) niż opisywana kiedyś CAPTCHA Agory. Polegała na podaniu wyniku dodawania dwóch liczb, podanych słownie, z zakresu 1-10. Dla ułatwienia tekst był podawany jawnie, jako tekst w HTML.

Jak już podniosłem szczękę z podłogi i przetarłem oczy, to dziesięć minut później miałem skrypt, który bezbłędnie podawał wynik. Zgłosiłem podatność, wraz z sugestią, żeby skorzystać z gotowców, a nie własnej, wadliwej implementacji CAPTCHA. Szybko otrzymałem odpowiedź, którą można streścić… it’s not a bug, it’s a feature:

Obecnie funkcjonujący mechanizm CAPTCHY został wprowadzony nie tylko w oparciu o bezpieczeństwo, ale również przystępność użytkowania, co w przypadku tak różnorodnej grupy osób jak grupa głosujących w Poznańskim Budżecie Obywatelskim, jest szczególnie ważne.

[…]

Zaproponowane przez Pana rozwiązanie – skorzystanie z usług zewnętrznych takich jak Google – jest niemożliwe do wprowadzenia, ponieważ musimy opierać się na własnych, niezależnych od firm zewnętrznych rozwiązaniach, co zapewnia nam pełną możliwość ingerowania w przypadku wystąpienia ewentualnych błędów czy problemów z usługą.

Wyciąłem opis dodatkowych mechanizmów weryfikacji osób głosujących, które na szczęście są obecne. Jednak stawka, o którą toczy się gra jest wysoka – nawet 2 mln za projekt ogólnomiejski. Liczę więc, że w przyszłym roku zabezpieczenia będą lepsze. Rozważyłbym wręcz wykorzystanie Profilu Zaufanego, tak po prostu. W tym roku wygenerowanie dodatkowych głosów było dość proste, choć sam automat do łamania CAPTCHA nie wystarczyłby.

Tak w ogóle nie zagłosowałem w tym roku – pamiętałem, żeby czekać do końca października i… przypomniałem sobie o głosowaniu 31.10. Skończyło się dzień wcześniej. Mówi się trudno.

UPDATE Niewielka aktualizacja w celu doprecyzowania w czym rzecz wynikająca z rozmowy. CAPTCHA, której rozwiązanie jest możliwe automatycznie to… nie CAPTCHA. Spokojnie można ją pominąć. Gdyby ktoś miał złe intencje i dostęp do bazy danych z danymi paru tysięcy mieszkańców Poznania, to stosunkowo łatwo, automatycznie mógłby w tym roku zmienić wyniki głosowania. Przy czym problem jest głębszy i CAPTCHA w Poznańskim Budżecie Obywatelskim, nawet działająca, nie ratuje tu sytuacji. Skala kilku tysięcy głosów jest do obsłużenia ręcznie, nawet przez pojedynczą osobę.

Profil Zaufany jest podobno mało popularny, nie mam zatem pomysłu jak sensownie zabezpieczyć tego typu głosowanie przez internet.

Ilość rowerów Nextbike na stacjach – reaktywacja

Dawno temu pisałem o monitoringu rowerów Nextbike na stacjach. Moja strona podająca aktualną ilość rowerów miejskich na stacjach Nextbike działała do kwietnia tego roku, po czym przestała odświeżać dane. Jest to o tyle niefajne dla mnie, że appka androidowa Nextbike i jej wyszukiwanie rowerów to jakaś kpina i zdecydowanie łatwiej i szybciej znajdowałem potrzebne dane u siebie. Albo po prostu I don’t like the bugs but the bugs like me, czyli znowu mam pecha i u mnie nie działa. W ogóle o appkach na Androida, zwłaszcza polskich wypadałoby już popełnić osobny wpis…

Poczyniłem szybki debug i okazało się, że Nextbike zapytany o konkretne miasto zwraca od niedawna błędny XML, zawierający zawsze także dane dla Indii. Zgłosiłem błąd mailem, co wiązało się z zabawną sytuacją, bo po pierwsze zostałem przez centralę wzięty za pracownika (chyba raczej stażystę) firmy Nextbike i odesłany do innego pracownika, który może założyć ticket w systemie. Padło też pytanie, a skądże to ja mam namiar na ten URL (przypominam, mający official w nazwie). No cóż, URL lata w wielu miejscach w sieci…

W każdym razie błąd został zgłoszony, a dane się nie pokazywały. Próbowałem na szybko zreanimować skrypt w Perlu, ale albo zmian było więcej, albo nie do końca umiem korzystać z tej biblioteki. W każdym razie poległem, a na dłuższe grzebanie w Perlu nie miałem ochoty. Przy okazji niegdyś poukładany kod wydał mi się już nie taki fajny i w sumie można by go przepisać…

Wczoraj zrobiłem przymiarkę do napisania tego w Pythonie. Okazało się, że bez problemu jestem w stanie parsować XML. Przy okazji zrezygnowałem z pobierania danych dla każdego miasta oddzielnie – miast jest na tyle dużo, że szybciej jest pobrać plik XML raz. Skoro zapowiadało się tak fajnie, to od razu postanowiłem przerzucić konfigurację z hasha w programie do pliku YAML. A skoro szło tak fajnie, to zmieniłem „template”, zaszyty w printach w skrypcie, na Jinja2, przy okazji mając pierwszy praktyczny kontakt z tym rozwiązaniem, bo wcześniej „korzystałem” z niego tylko w template’ach dla bloga opartego o Pelican. Bardzo fajne, rozbudowane bardziej, niż przypuszczałem i jednak rządzące się swoimi prawami. W każdym razie mniej oczywiste niż mi się wydawało do tej pory.

Skoro szło tak dobrze, to dorzuciłem pięć kolejnych miast (Pszczyna, Zgierz, Kędzierzyn-Koźle, Kołobrzeg i Tychy), bo tyle pojawiło się od kwietnia. Oczywiście już nie do skryptu, tylko do prostego w utrzymaniu pliku z konfiguracją. 🙂 Całość zapakowana w virtualenv oczywiście, dla przenośności.

Ze skryptu nie jestem w 100% zadowolony – pewnie można go jeszcze uprościć, ale… może kiedy indziej, tym bardziej, że mógłbym jeszcze uzupełnić dane o geolokalizacji i pewnie gdzieniegdzie zostało błędne kodowanie znaków. Póki co, strona z ilością rowerów znowu działa. Ciekawostka – wszystkie pliki (skrypt, konfig, dane o wymaganych modułach) mają tyle samo linii co oryginalny Perl (TBH żadne nie było specjalnie sprzątane czy optymalizowane pod kątem wielkości), a jest o niebo czytelniej i prościej.

Wybór najlepszego interfejsu

Dodana kolejna funkcja, zwracająca trasy i odpowiednie dla nich najlepsze interfejsy. Napisane na szybko rano, przetestowane i poprawione przed chwilą, bo nie wiem jakim cudem napisałem rano taki bezsens. Plan był znacznie bardziej ambitny, dzień zapowiadał się pięknie i nawet zaryzykowaliśmy bonusowy wypad do centrum handlowego Posnania celem nabycia oświetlania, ale…

Zanim przejdziemy do ale dygresja nt. owego centrum. Nie wiem co jest zrobione źle. Albo nie jest skończone i nie działają wentylatory, albo jakaś awaria czujników, albo… broken by design. W każdym razie efekt jest taki, że na dość luźnym parkingu, przy braku jeżdżących aut jest duszno i mocno śmierdzi spalinami. Pierwszą rzeczą po wyjeździe było gruntowne przewietrzenie auta, nie chcę myśleć co będzie przy większym ruchu…

Inne wtopa – oprogramowanie do znajdowania trasy na tabletach (oj, można się zgubić, można…) działa w oszczędnej (Poznań, prawda? ;-)) wersji demo, zachęcającej klientów do zakupu licencji. Albo poczekania. Profesjonalnie. Niestety, fotki nie zrobiłem, bo napis zdążył zniknąć, a trochę mi się spieszyło, więc nie uruchamiałem drugi raz.

Wracając do ale: brak czasu, sponsoruje bieg Wings for Life World Run (ciekawa formuła, swoją drogą, może kiedyś się skuszę?). Nie wiedziałem, że się odbywa, więc nie sprawdziłem trasy i na powrocie utknąłem w korkach. Pewnie nie wkurzałoby, gdyby nie fakt, że bieg najpierw blokował główną ulicę z jednej strony centrum, a potem… inną ulicę z drugiej strony centrum. Jak doczytałem później, w międzyczasie jeszcze trzecią ulicę. Generalnie wjazd do centrum w praktyce wyłączony na ponad godzinę (stawka mocno rozciągnięta…), miasto totalnie zablokowane, bo korki się skumulowały, podobno 800 aut stało na rondzie Śródka.

Nie wiem co za umysł wytyczył tak trasę, ale jeśli chce w ten sposób zniechęcić ludzi do biegów czy też tej konkretnej imprezy, to jest na doskonałej drodze. Bo rozumiem start w centrum, przebiegnięcie przez centrum i jakieś utrudnienia w ruchu, żeby biegacze „byli widoczni”, ale totalna blokada centrum i pałętanie się biegaczy przez godzinę? Noż wyraz.

W każdym razie po godzinie stania w korku cała energia i chęć pisania czegokolwiek poszły się paść, więc tylko poprawki, ten wpis i tyle. Sondy dziś nie będzie.

PS Oświetlenie kupiłem.