Opera mini 5 beta – wrażenie.

Niby moja Nokia 3110c nie obsługuje (tak twierdzi przy próbie instalacji), ale install anyway i po chwili było to „cudo” na moim telefonie. Już na wstępie widać, że faktycznie projektowane jest toto na większe wyświetlacze – przedstawiło się mniej więcej pera min, bo zabrakło miejsca na ekranie.

Opcji w porównaniu z wersją 4 bardzo mało, ale niby jest wszystko. Podejście do działania inne – wersja 5 pokazuje całą stronę i pozwala powiększyć (zoom) wybrany obszar. Dzięki temu niby jest bardziej naturalnie (czyli jak na dużym ekranie), ale mi się bardziej podobało podejście z wersji 4, czyli dostosowanie do komórki (zoom zawsze mnie drażnił). Nie ma (nie znalazłem) mojego ukochanego przewijania blokowego – jest tylko ta śmieszna strzałeczka i po linii trzeba – niewygodne.

Wersja 5 ma trochę nowych ficzerów. Szybki ich przegląd: miniaturki na małym ekranie to IMHO pic na wodę, fotomontaż – zero użyteczności. Speeddial z wersji 4 (gwiazdka, cyfra) był IMO wystarczający. Manager haseł – nie zamierzam korzystać. Przeglądanie w zakładkach – no to może ma sens, tylko niestety u mnie przy próbie otworzenia drugiej zakładki przeglądarka się wysypała (ale to beta i niesupportowany sprzęt, więc się nie gniewam). Drugi raz nie próbowałem.

Działa szybko (na oko szybciej niż 4), ale zajmuje 350 kB miejsca w pamięci flash telefonu (poprzednia wersja ok. 160 kB). Podsumowując – zobaczę wersję stabilną i mam nadzieję, że dostosują ją do 3110c, ale w tej chwili bardziej podoba mi się czwórka. Na tę chwilę pora odzyskać utracone 350 kB.

Błędy w moBILET – przepis na DoS i proste oszustwo.

Z moBILETu korzystam od dawna, ogólnie jestem zadowolony. Kiedyś, na starym blogu, pisałem o słabych punktach tej usługi i ogólnych wrażeniach. Dziś zaszło pewne zdarzenie, które przypomniało mi o tym, że miałem napisać parę słów więcej o bezpieczeństwie i możliwościach nadużyć.

Po pierwsze, najsłabszym punktem moBILETu są… kontrolerzy. Nigdy nie zdarzyło mi się, bym został poproszony o przełączenie na inny ekran, nie był sprawdzony kod i w ogóle całe sprawdzenie skończyło się na sprawdzeniu, czy godzina na wyświetlonym bilecie jest OK. Zatem najprostszy sposób oszustwa to prosta aplikacja w javie, która wyświetli co trzeba i doda taką godzinę, by bilet był ważny. Pewnie z 30 min roboty, jeśli ktoś zna Javę ME.

Po drugie, stosunkowo łatwo uniemożliwić komuś skasowanie biletu. Wystarczy zacząć dzwonić w momencie, kiedy próbuje skasować bilet. Zaowocuje to wyświetleniem przez aplikację komunikatu, żeby najpierw zakończyć rozmowę, a samo kupno biletu nie będzie możliwe do czasu, kiedy dzwoniący nie przestanie dzwonić (czy się nie rozłączy, nie testowałem dokładnie). De facto pozwala to na DoS na kasującego bilet, możliwe, że skuteczny, bo kanary mają przykry zwyczaj rozpoczynania kontroli tuż po ruszeniu tramwaju.

Tak dziś wyszło, jak kumpel zadzwonił tuż po moim wejściu do tramwaju. Chwilę później zadzwonił z pytaniem, czy moBILET się wywalił. Nie, ale i tak gratki za pomysł. Ląduje w kategorii security, choć nietypowe.

Niebawem koniec wysyłki maili na port 25.

Jeden z bardziej burzliwych tematów trzeciego spotkania PLNOG to planowane zablokowanie ruchu na porcie 25 przez TPSA. Dotyczyć będzie jedynie użytkowników Neostrady (oraz pakietów zawierających tę usługę – w skrócie – usługa dla klienta indywidualnego o zmiennym IP) i wysyłających pocztę z klientów pocztowych w stylu Thunderbirda czy Outlook Express (dla korzystających z webmaila nic się nie zmieni). Podobnie jak przy portach netbiosowych będzie istniała możliwość wyłączenia blokady poprzez zmianę loginu. Wprowadzone ma być całkiem niedługo, bo z dniem 1 grudnia.

Oczywiście było trochę ataków na TPSA podczas dyskusji, że czemu np. nie robią recenta (niby na czym?), czemu nie skanują poczty pod kątem spamu (ingerencja w treść) itp., ale akurat moim zdaniem jest to świetna decyzja (i jedyna wykonalna technicznie przy tej skali usług), tym bardziej, że i RFC pozwala na takie działanie, i – dla bardzo chcących wysyłać przez port 25 użytkowników – będzie prosta możliwość zdjęcia blokady (nie polecam). Poza tym, już teraz serwery mail na świecie mogą nie przyjmować poczty wysyłanej z portu 25 z klas IP oznaczonych jako przeznaczone do wysyłki po autoryzacji, przez serwer ISP lub webmail (zobacz PBL advisory), a takie powinny być klasy przeznaczone dla neostrady.

Nowość żadna, bo duże portale opiniowały to już parę miesięcy temu i są przygotowane, a większość dostawców została powiadomiona, ale pewnie sporo użytkowników i zupełnie małych dostawców kont pocztowych jeszcze o tym nie wie, dlatego informuję i polecam zapoznanie się z RFC 4409.

Jak już pisałem, decyzję uważam za dobrą, co więcej, mam nadzieję, że mniejsi i całkiem mali ISP pójdą tą samą drogą, i to wkrótce (pewnie poczekają nieco na efekty w TPSA). W tym przypadku inicjatywa TPSA jest naprawdę przemyślana, słuszna i dobrze wykonana (no dobrze, chwalę dzień przed zachodem słońca, ale wiem, co już zrobili i jak niewiele zostało – tylko poinformowanie użytkowników, które jest zaplanowane). W końcu jest szansa, że Polska nie będzie jednym z czołowych spamerów na świecie, a dostawcy poczty powinni odczuć spadek ilości nadchodzącego spamu, co przełoży się na spadek obciążenia serwerów poczty i maszyn skanujących.

Dla tych leniwych użytkowników, którzy nie chcą czytać – szybkie info jak włączyć nową wysyłkę poczty. Do nieszyfrowanego wysyłania poczty wystarczy zmienić port serwera pocztowego z 25 na 587.

Oficjalny komunikat TPSA dotyczący blokady portu 25, zawiera namiary na dokładne konfiguracje u większych darmowych dostawców poczty.