Internet w komórce – jak zmniejszyć transfer.

Na urlopie byłem – z premedytacją – odcięty od sieci. Kontemplacja szumu wiatru i fal to Dobra Rzecz, ale co za dużo, to i świnia nie zje, więc w pewnym momencie zapragnąłem sprawdzić, co się na świecie dzieje. Tradycyjne gazety, które były pod ręką, to niezupełnie było to, o co mi chodziło, więc postanowiłem nadrobić trochę zaległości, oraz dopracować sposób korzystania z internetu w komórce.

Wszystko będę opisywał na podstawie nienajnowszego, ale IMO nadal funkcjonalnego (kategoria „po pierwsze ma dzwonić”, nie „all in one” ) telefonu komórkowego Nokia 3110c (o, równe 2 lata temu już opisywałem, jak ten czas leci…) – rozmiar ekranu to tylko 128×160 pikseli, 1,8 cala oraz Opery mini w wersji 5 z włączonym mobile view (nic lepszego do przeglądania stron na komórce póki co nie znalazłem i nie zanosi się, żeby w najbliższym czasie coś miało dorównać Operze mini). Co prawda, jak pisałem, niby mój telefon nie wspiera oficjalnie wersji 5, ale jak pisałem, działa (także wersja stabilna), i to działa dobrze. Na bardziej współczesnych telefonach z większym wyświetlaczem może się to nieco różnić i choć raczej nie drastycznie, to wypada zaznaczyć te warunki.

Do przeglądania stron WWW przez komórkę przy niewielkim zużyciu transferu Opera mini 5.0 świetnie się nadaje dzięki kompresującemu proxy – strona najpierw trafia na serwery opery, tam jest dostosowywana, kompresowana i dopiero wysyłana na telefon, dzięki czemu zużywa znacznie mniej transferu.

Domyślne ustawienia Opery mini są dobre, ale przy większej ilości przeglądanych stron kilobajty nieubłaganie lecą. Czy można jeszcze jakoś zmniejszyć zużycie transferu? Wydaje mi się, że tak. Grafika zużywa stosunkowo dużo transferu, a czy jest tak naprawdę potrzebna? Szczególnie taka w niskiej jakości i na małym ekranie, gdzie TBH niespecjalnie cokolwiek widać? W sytuacji, gdy koncentrujemy się na informacji zawartej w tekście? Jasne, co innego, gdy ktoś robi zakupy w internecie, czy przegląda np. takie blogi, na jakich zdjęcia są istotne (ale get real, wariant z obrazkami w niskiej jakości, na małym ekranie też wtedy nie bardzo wchodzi w takim wypadku w grę). No to można wyłączyć ładowanie obrazków w ogóle…

Pewnie mi było łatwiej, bo lubię typowo tekstowe narzędzia, ale IMO nawet użytkownik, który na co dzień używa grafiki w aplikacjach na komputerze niespecjalnie odczuje w komforcie użytkowania brak grafik na telefonie (zakładam, że przywykł do wyglądu stron w komórce w ogóle – „lekko” się to jednak różni, przynajmniej z włączonym mobile view i na tak małym ekranie), bo Opera ładnie zaznacza, gdzie była grafika na stronie (z uwzględnieniem jej rozmiaru) i pokaże podpis (o ile webmajster ustawił). Przyznam, że całkiem zacnie to wygląda, więc chociaż nie robiłem dokładnych pomiarów zmniejszenia pasma („na oko” – warto), to uważam, że i tak warto spróbować wyłączyć także ładowanie grafiki w Operze mini, nawet, jeśli komuś niespecjalnie zależy na zmniejszeniu transferu danych.

Jedyny tak naprawdę zauważony minus to brak wyświetlania captchy na blogach, ale kto pisze komentarze z klawiatury innej niż pełnowymiarowe qwerty?

Security – ostatnie różności (zabezpieczenia moBILETu ponownie).

Wczorajszy dzień jakoś tak obfitował w wydarzenia związane z bezpieczeństwem, że postanowiłem to podsumować.

Po pierwsze, po dyskusji z netu na ten temat, postanowiłem się przyjrzeć moBILTowi. W sumie po raz kolejny bo i na zabezpieczenia patrzyłem (i to dwa razy). Przy dyskusji zeszło oczywiście na temat jak oni to sprawdzają (jak pisałem, sprawdzają źle) oraz jak mogą sprawdzać. Oczywiście najdoskonalsza wersja, to sprawdzenie online (odpytanie bazy o fakt skasowania danego biletu). Ponieważ twierdziłem, że jakby napisanie fake’owej aplikacji było proste (grafiki są – jak pisałem – dostępne, cudów tam nie ma, zwykła Java ME i trzy semi statyczne ekrany), to na pewno studenci (taki gatunek człowieka, co to nigdy kasy nie ma, dostęp do wiedzy i czas ma (chyba, że akurat pije, co mimo braku kasy zdarza się często, albo sesja), więc do skutecznego kombinowania pierwszy) by to zrobili. I że pewnie jest algorytm, który na podstawie cyfr/kodu z biletu pozwala zweryfikować prawdziwość biletu offline.

Nie ukrywam, że pozazdrościłem Niebezpiecznikowi opisu hackowania karty IKEI w celu dostania kawy, więc był czas, kawa, motywacja…

Bliższe przyjrzenie się ujawniło, że to, co brałem za QR code, to raczej Aztec code. Na dodatek odwrócone kolory ma (nie doczytałem, czy oryginalny Aztec na to pozwala, na wiki wszystkie są odwrotne). Ale Neoreader czyta to. Po przeczytaniu okazuje się, że twórcy nie ułatwili kontrolerom pracy – nie ma żadnego unikatowego ID zaszytego w tym kodzie. Jest tylko dokładny timestamp kasowania biletu. Opieram się wyłącznie na screenach dołączonych do instrukcji na stronie (dead link) – wyglądają na prawdziwe.

Niestety, inaczej niż w przypadku Niebezpiecznika, ludzie zawiedli. Apel na blipie pozostał może nie tyle bez odpowiedzi (odezwały się 2 osoby, z czego tylko jedna mogłaby pomóc), co bez danych. Pozostali znajomi nie odezwali się jak na razie z danymi, więc zostałem tylko ze swoimi danymi. Szybka analiza wykazuje, że są tak naprawdę 3 dane brane pod uwagę. Dokładny czas kasowania, numer ze strony pierwszej, bieżący numer ze strony drugiej i… tyle. Przy czym numer ze strony pierwszej jest stały (być może dla danego użytkownika, typu usługi, regionu) w trakcie jednego dnia. Natomiast bieżacy numer to po prostu inkrementowane ID w bazie (też nie wiem, czy dla danego typu usługi i regionu, czy transakcji globalnie, ale wiem, ile przyrasta dobowo).

Szybkie odświeżenie wiadomości z pracy magisterskiej i naklepanie prostego AG (algorytmu genetycznego) w Perlu nie przyniosło rezultatu w postaci znalezienia korelacji między datą danego dnia, a numerem ze strony pierwszej, choć na oko wygląda, że taka może istnieć (Perl i algorytm wolne i nie do końca przemyślane). Tak naprawdę czekam na więcej danych, w szczególności chcę porównać, czy dany numer jest stały dla wszystkich użytkowników (i usługi) w danym dniu. Jeśli jest, to ewidentny błąd twórców moBILETu – nawet jeśli nie ma algorytmu, to wystarczy, że jeden student skasuje bilet w danym dniu i przekaże numer innym. I nie da się zweryfikować offline, na podstawie sumy kontrolnej czy czegoś takiego, czy to autentyczny bilet…

Po drugie, za sprawą wpisu u Marcina Kasperskiego dowiedziałem się, że wbrew temu, co mówili sceptycy, słynną Nokię 1100 da się wykorzystać do przechwytywania SMSów z kodami jednorazowymi do transakcji. Czarny scenariusz się sprawdza – kody SMS nie są bezpieczne, istnieje metoda na oszukanie czytnika kart chipowych… Nadchodzą niedobre dni dla banków internetowych?

Po trzecie, atak phishingowy na Lucas Bank (dead link). Tu lekka lipa ze strony banku, bo korzystajac z formularza kontaktowego na stronie nie możemy wprost zgłosić takiego zdarzenia. Co więcej, wymagane jest podanie adresu email. A korzystając z tego formularza wyrażamy zgodę na przysyłanie spamu przez bank. Słowo kretyn w stosunku do osoby, która to wymyśliła nie oddaje w pełni tego, co chcę wyrazić…

UPDATE: Szybkie sprawdzenie z mobiletem kumpla pokazuje, że numer ze strony pierwszej jest stały w obrębie danego dnia dla wszystkich użytkowników (danej usługi, w danym regionie, kupujących dany typ biletu).