Wolne repozytoria dla Androida czyli alternatywa dla Google Play.

Model sprzedaży aplikacji przez Google mi się niezbyt podoba: sporo mało użytecznych aplikacji, wszechobecne aplikacje płatne i z reklamami. Oczywiście, niby jest system ocen, ale nadal ciężko wybrać (z dwóch wysoko ocenianych czytników ebooków jeden był totalnie OKDR). Niby jest filtrowanie płatne/bezpłatne, ale już filtra na wersję bez reklam nie ma. Ogólnie, żeby coś znaleźć fajnego, trzeba trochę prób i błędów. Niewiele jest dobrych i jednocześnie darmowych aplikacji. TBH wolałbym trial pełnej wersji, albo po prostu aplikacje, które w prosty sposób umożliwiają przekazanie pieniędzy np. przy pomocy Flattr. Na ostatnim P.I.W.O pytałem o alternatywne repozytoria pakietów i nikt nie znał takowego.

Dołóżmy do tego fakt, że twórca aplikacji sprzedawanej w Google Play dostaje w przypadku zakupu nasze dokładne dane i robi się niezbyt ciekawie. Gdyby ktoś chciał repozytorium zorientowane bardziej na wolność, prywatność i z wolnym oprogramowaniem, to informuję, że takowe istnieje. Dowiedziałem się o nim, gdy ponarzekałem na Androida – zostałem odesłany do projektu Replicant, czyli całkowicie wolnej alternatywy dla Androida.

Mój tablet (Go Clever A73) nie jest wspierany (ogólnie mało urządzeń jest), ale za to dowiedziałem się o tytułowym wolnym repozytorium dla Androida, czyli f-droid.org, czyli wspomnianej alternatywie dla Google market AKA Play. Zawiera tylko wolne oprogramowanie (preferowany sposób dystrybucji to dostarczenie kodu źródłowego do utrzymujących f-droid.org, a następnie skompilowanie przez nich). Można pobierać aplikacje bezpośrednio, można skorzystać z managera. Pierwsze wrażenie przy instalacji pakietów z jego pomocą – znacznie lżejszy od aplikacji obsługującej Play. Aplikacje szybciej się pobierają i instalują. I mniej kolorowo – niestety, dostępne są tylko opisy aplikacji, nie ma screenshotów. Wada, bo jednak kupujemy oczami.

Część aplikacji jest dostępnych w Play (co ciekawe, musiały być wysoko ocenione, skoro je zainstalowałem). Może się zdarzyć, że przed instalacją wersji z f-droid.org trzeba będzie odinstalować wersję z Google Play. Większość aplikacji jest użyteczna i po prostu działa. Trzeba jednak zwrócić uwagę na opisy i funkcjonalności, bo czasem zdarza się, że aplikacja dostępna w repozytorium f-droid jest mniej funkcjonalna, niż jej odpowiednik z Google Play – wynik pozbycia się niewolnych bibliotek czy źródeł danych.

Inną ciekawą funkcją są tzw. antyfunkcje. W managerze pakietów można określić, czy chcemy dopuścić instalację aplikacji zawierających reklamy, namierzających położenie lub raportujących działania (kiedyś to się spyware nazywało…), wspierających płatne dodatki, wspierających płatne usługi sieciowe czy w końcu zależne od innych, płatnych aplikacji. Domyślnie wyszukuje tylko wśród wolnych aplikacji, ale można wyłączyć. Jeśli komuś zależy, to może podążać ścieżką GNU i RMS, ale nie ma przymusu.

W przeciwieństwie do Play, f-droid.org pozwala na wybór wersji instalowanej aplikacji. Czyli jeśli najnowsza np. nie działa na naszym sprzęcie, albo zwyczajnie się nam nie podobają zmiany wprowadzone przez autora, to nie ma przymusu i nadal można zainstalować wersję starszą.

Nie wiem jak ocenią f-droid.org typowi użytkownicy, ale z linuksiarskiej perspektywy – warto się zainteresować tym alternatywnym repozytorium pakietów dla systemu Android. Oczywiście z obu źródeł pakietów można korzystać jednocześnie.

PS. Opisuję, bo mało popularne, choć było opisywane po polsku dwa razy.

Retencja danych – jak logować ruch.

Jakiś czas temu pisałem o retencji danych, natomiast nigdy nie napisałem jak albo czym logować dane o ruchu sieciowym na Linuksie. Niedawno otrzymałem spam o treści „XXX posiada w swojej ofercie gotowe rozwiązanie do zbierania, przechowywania i analizowania ruchu sieciowego zgodnych z ustawą o retencji danych”. Cena dla małych ISP niewąska, bo za coś, co obsłuży ruch do 1 Gbps, składającego się z jednej sondy, jednego kolektora, softu i wdrożenia wołają dziewięć tysięcy euro.

Całość rozwiązania opiera się o netflow, który od dawna był polecany jako narzędzie do analizy ruchu i wykrywania anomalii. Skoro już padło (nie z moich ust ;-)) odważne stwierdzenie, że jest to sposób zgodny z ustawą o retencji danych, to można przedstawić zarys, jak to zrobić samemu. Tym bardziej, że część ISP nadal korzysta z jakichś mało wydajnych i logujących znacznie mniej informacji rzeźb w stylu logowanie przy pomocy iptables. Oraz – co ważne – rozwiązanie oparte o netflow zapewnia zbieranie o logowaniu ruchu z hostów za NAT (jeśli uruchomione jest na routerze robiącym NAT).

Jeśli chodzi o protokół NetFlow oraz wysyłkę i zbieranie danych, w Debianie (i zapewne większości innych dystrybucji) od dawna dostępne są narzędzia zawarte w pakiecie flow-tools. Do wysyłki służy fprobe, do odbioru flow-capture Jak widać z Wikipedii (próbki sobie tym razem daruję), dla każdego połączenia (flow), zapisywane są czas rozpoczęcia i zakończenia połączenia, typ połączenia, docelowy i źródłowy adres IP, a także porty źródłowy i docelowy. To z ciekawszych rzeczy zgodnych z ustawą. Obciążenie generowane na maszynie zbierającej nie jest duże, choć przy dużych kilkudziesięciu Mbps robi się zauważalne.

Natomiast jeśli chodzi o sFlow, to w Debianie dopiero począwszy od wersji Wheezy, jest narzędzie do zbierania sfdump zawarte w pakiecie nfdump-sflow. Ta wersja korzysta z próbkowania, czyli badany jest co któryś pakiet na interfejsie. Dzięki temu obciążenie na urządzeniu zbierającym, czyli sondzie, jest praktycznie pomijalne.

Zebrane flowy, niezależnie od protokołu zbierania, zajmują stosunkowo niewiele miejsca (automatyczna kompresja), a wykorzystać je można nie tylko na potrzeby związane z retencją danych, ale także (przede wszystkim) do wykrywania anomalii w ruchu sieciowym czy – w przypadku zbierania danych z urządzeń mających informacje związane z BGP – do planowania sieci. Widać wówczas nie tylko z których IP jest ruch, ale także AS docelowy i źródłowy.

Zdaję sobie sprawę, że powyższe to żaden rocket science i pewnie większość sieciowców kojarzy temat (choć mali ISP – niekoniecznie). Natomiast w środowisku związanym z Linuksem może być to pewna ciekawostka. Celowo nie zamieszczam przykładów konfiguracji – dokumentacja jest dobra. Gdyby były pytania lub niejasności, proszę pytać w komentarzach, postaram się odpowiedzieć.

Na koniec uwaga: IANAL, więc nie podejmuję się określenia, czy taki sposób jest zgodny z przepisami nt. retencji danych. Na pewno zebrane dane są dokładniejsze i wygodniejsze, niż logi DHCP, logi z iptables itp. Jeśli chodzi o prywatność, to zawierają dokładnie tyle, na ile pozwala i ile wymaga ustawa. Nie jest logowany sam ruch, tylko dane o nim.

0-day w Linksysie ma szerszy zasięg czyli problem z UPnP dla Broadcom..

Zgodnie z wcześniejszą zapowiedzią firma DefenseCode opublikowała szczegóły nt. niedawnego 0-day na routery Linksys. Okazuje się, że chodzi o implementację UPnP w firmware Broadcom i – jak można się spodziewać – w takiej sytuacji podatnych jest znacznie więcej routerów, różnych producentów. Na pewno podatność dotyczy Linksysa WRT54GL, WRT54G3G, prawdopodobnie WRT310N, poza tym, dotknięty potencjalnym błędem chip może występuje w urządzeniach urządzeniach wielu producentuów, m.in. Netgear, Asus, D-Link, Zyxel, TP-Link.

Padało pytanie, czy exploit działa z WAN czy z LAN. Z dokumentu wynika, że w wielu przypadkach działa spoza sieci lokalnej. Pojawia się stwierdzenie, że jedyna popularna implementacja UPnP, która nie posiada błędu, to MiniUPnP (tak, open source, tak, OpenWrt jest odporne). Pora na zmianę firmware’u, chociaż UPnP mam wyłączone. Ciekawe swoją drogą, czy wyłączenie UPnP eliminuje podatność.

UPDATE: Znalazłem dwa ciekawe, polskie serwisy nt. bezpieczeństwa, do których odsyłam zainteresowanych tematem bezpieczeństwa. W szczególności pierwszy pisze więcej o tym konkretnie zagadnieniu (wygląda, że wyłączenie UPnP pomaga), a tutaj znajdziecie istny pogrom domowych urządzeń sieciowych.

Moje zastosowania dla tabletu z Androidem.

Pisałem, że tablet z Androidem znalazł u mnie parę zastosowań. Do czego można go jeszcze wykorzystać?

Po pierwsze: mikroblogi. Na Androidzie jest Blipper i Mustard, które umożliwiają wygodne korzystanie odpowiednio z blip.pl i idenit.ca. O ile Mustard jest taki sobie i często wolę usiąść do komputera, to Blipper jest znacznie bardziej ergonomiczny i ma genialną funkcję sekretarka. W zasadzie często tylko dla tej funkcji uruchamiam program – po prostu chcę się dowiedzieć, czy ktoś odpisał na moją wiadomość albo status. No i napisanie tych 160 znaków od czasu do czasu z klawiatury dotykowej jest do przełknięcia.

Po drugie: Gry i edukacja (czyli też gry). W przypadku edukacji chodzi o gry dla dzieci uczące literek, cyferek i rozwijające pamięć. Same gry – chyba nie wymaga komentarza. Raczej zabijacze czasu i nie znalazłem nic naprawdę fajnego i wciągającego. Już w przypadku gier flashowych na PC jest lepiej, o wszystkich nie wspominając. No cóż, mysz i klawiatura czy inny pad dają jednak spore możliwości.

Po trzecie: pomoc treningowa, czyli Android jako trener. Bardzo nietypowe, ale bardzo fajne zastosowanie. Otóż są programy, które zliczają ilość wykonanych ćwiczeń, dobierają serie i pilnują czasu między seriami. Na dodatek trochę też pilnują wykonania ćwiczeń i zliczają powtórzenia. Przykładem może być program do pompek: kładziemy tablet na podłodze i robimy pompkę tak, by nos lub broda dotknęły ekranu, co powoduje zaliczenie wykonania pompki. W przypadku przysiadów wykorzystywany jest zapewne akcelerometr. Nie ukrywam, że bardzo mi się podoba takie rozwiązanie – pełna, praktycznie bezobsługowa pomoc treningowa.

Po czwarte: czytanie i przeglądanie stron. Miało być podstawowym zastosowaniem, jest niszą. Proste PDFy faktycznie wygodniej niż na telefonie i często wystarczająco wygodnie w porównaniu z PC, ale strony to ja jednak wolę na komputerze.

Wpis jest odpowiedzią na komentarze przy poprzednim wpisie o Androidzie.

Zawieszanie w wykonaniu Androida.

Gdy poprzednio pisałem o Androidzie na tablecie nie byłem zachwycony. Jestem parę miesięcy używania później i coraz bardziej utwierdzam się w przekonaniu, że to nie to. Zdecydowaną większość rzeczy wolę robić jednak na komputerze przenośnym. Jakość konsumpcji treści, tj. czytania tekstów również niczego nie urywa. Komórka jednak dużo mniejsza, lżejsza i wygodniejsza w trzymaniu. Ale parę zastosowań się znalazł.

Ostatnio miałem przygodę. Zwykle jak nie korzystam z tabletu, to po prostu blokuję ekran i zostawiam go podłączonego do ładowarki. Ostatnio dłuższy czas nie używałem, zerkam, a tam ekran bootowania z animowanym napisem Android. Pomyślałem, że się rebootnął i – z lekkim uśmiechem – że chłopaki z Google skiepścili sprawę, bo Linux się nie wiesza[1], ale kolejne zerknięcia parę godzin później ujawniło, że to zwis.

Nie pomogło odpięcie od ładowarki, krótkie ani długie wciskanie przycisku power. Za to reagował na klawisze dotykowe na obudowie. Skończyło się tak, że zostawiłem go, żeby się rozładował z nadzieją, że się włączy. No i tym razem się udało.

Incydent przypomniał mi, że miałem poćwiczyć bootowanie Debiana na tym urządzeniu. Szybkie poszukiwania zaowocowały odkryciem, że obrazy systemu Wheezy dla tabletów (nieoficjalne oczywiście) zniknęły. A szkoda, bo genialnie uprościłyby sprawę. Tak czy inaczej jak tylko coś zdziałam w tym temacie, to nie omieszkam opisać.

[1] Linux też się wiesza. Tylko pomijalnie rzadko i zwykle deterministycznie, tj. za sprawą np. skopanego modułu.