Retencja danych – przepisy wykonawcze.

Ustawa nakazująca operatorom przechowywanie danych o połączeniach istnieje od dawna, ale do tej pory dostawcy internetu robili, co mogli/chcieli, bo przepisów wykonawczych nie było. Wszystko wskazuje na to, że niebawem się to zmieni, bo Minister Infrastruktury przygotowuje rozporządzenie w tej sprawie. I nie wygląda ono różowo, szczególnie dla mniejszych ISP, opierających się o sieci ethernetowe, a ich także – obok dostawców telefonii i poczty elektronicznej – dotyczy.

Projekt rozporządzenia Ministra Infrastruktury w sprawie szczegółowego wykazu danych oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dostępnych usług telekomunikacyjnych obowiązanych do ich zatrzymania i przechowywania, o którym piszę, można przeczytać w całości na stronach Ministerstwa Infrastruktury, podobnie jak dołączone do niego uzasadnienie. Gorąco polecam lekturę obu tych pism przed czytaniem reszty wpisu, a na pewno przed komentowaniem.

Pisać będę z punktu widzenia najbliższego mi, czyli dostawcy internetu i tylko na temat dostarczania usługi internetowej. Pocztę elektroniczną i telefony całkowicie pomijam, choć zdanie administratorów – szczególnie serwerów pocztowych – także mnie interesuje i zapraszam do komentowania.

Przede wszystkim wygląda, że ustawodawca albo zapomniał o istnieniu i zasadach działania sieci opartych o ethernet, albo w ogóle nie zdaje sobie sprawy, w jaki sposób one działają. Ruch w obrębie sieci rozgłoszeniowej w takiej sieci zamykać się może w obrębie jednego przełącznika. Switche są różne, ale nawet te zarządzalne rzadko kiedy oferują wsparcie dla logowania czegokolwiek wymaganego w ustawie. O logowaniu połączeń między użytkownikami dostawcy korzystający ze switchy niezarządzalnych mogą całkiem zapomnieć. Oczywiście, można podzielić sieć na mniejsze (dla każdego użytkownika osobna sieć), ale w ten sposób po pierwsze bardziej obciąża się router, po drugie traci się największą zaletę takiej sieci, jaką jest decentralizacja ruchu lokalnego.

W rozporządzeniu brakuje definicji połączenia. O ile w przypadku telefonii sprawa jest dość oczywista i można ją traktować „na chłopski rozum’, o tyle w przypadku Internetu nie jest tak prosto, szczególnie, że istnieją protokoły bezpołączeniowe. Czy każdy pojedynczy wysłany pakiet traktować wówczas jako połączenie? Co traktować jako rozpoczęcie połączenia? Co jako zakończenie połączenia? W której warstwie modelu OSI należy badać połączenie?

Zauważyć należy, że rozporządzenie wprowadzać ma obowiązek logowania portów. W uzasadnieniu można przeczytać, że dotychczasowa praktyka wskazuje, że obecnie w większości przypadków operatorzy posiadają te dane i nie są one specjalnie generowane w celu retencji ale nie wierzę, że mowa w tym przypadku o portach. O ile większość mi znanych małych ISP jest w stanie określić IP użytkownika i ew. aktywność o zadanej porze, o tyle z portami sprawa ma się zupełnie inaczej (faktem jest, że służby praktycznie nigdy o to nie pytają).

Błędem jest też zapis, że port sieciowy określa rodzaj usługi komunikacyjnej w sieci teleinformatycznej. Istnieją oczywiście pewne zalecenia i standardy, ale port ani nie definiuje usługi, ani usługa nie definiuje portu. Nie ma żadnego problemu w wykorzystaniu nietypowego portu dla danej usługi, co więcej, stosunkowo często jest to stosowane (choćby jako redukcja zagrożenia ze strony skanerów szukających podatności w danych usługach).

Ciekawe jest też wymaganie określenia momentu nawiązania połączenia i rozłączenia z Internetem, także w przypadku adresacji statycznej. Oczywiście definicji Internetu brakuje… Co w przypadku popularnego wśród mniejszych operatorów DHCP, gdzie rozpoczęcie owszem, łatwo określić, ale koniec już nie bardzo…

Ostatnia niefortunna rzecz to – moim zdaniem – termin, od kiedy rozporządzenie miałoby zacząć obowiązywać. Planowaną datą jest bowiem 1 stycznia 2010 r., co praktycznie nie daje mniejszym operatorom możliwości dostosowania się do niego, także po doprecyzowaniu ww. nieścisłości.

Szczerze mówiąc, ciekaw jestem opinii, szczególnie administratorów mniejszych, opartych o ethernet sieci, na temat tego projetku. Chętnie też poznam uwagi na temat ew. błędów w mojej interpretacji ww. rozporządzenia.

 

 

Usunięcie blokady portu 25 w Neostradzie.

Świat się nie zawalił. Narzekań specjalnych nie było, trochę psioczenia niektórych adminów (oj, nie wszyscy się przygotowali, nie wszyscy). Operacja się udała, więc pora na informację, jak zacną skądinąd blokadę wyłączyć.

Rano ten wpis wyglądał inaczej (i ta wersja niedługo wróci), ale z tego co wiem, polityka informowania na infolinii TP jest taka, że się nie da, więc na razie trzymajmy się tej wersji, bo z pewnych względów jest ona słuszna. Myślę, że oryginalna wersja powróci w okolicy Mikołajków.

Na wstępie uwaga: tak naprawdę wcale nie musisz tej blokady (i nie powinieneś – zobacz poprzednie wpisy, w których opisane są przyczyny jej wprowadzenia) wyłączać. O wiele lepszym rozwiązaniem jest zmiana konfiguracji czytnika poczty. No ale załóżmy, że skonfigurowałeś to komuś, komu za ChRL nie wytłumaczysz, jak zmienić konfigurację, a sam nie masz dostępu do tego systemu (pozdrawiam rodaków za granicą). Albo masz beznadziejny soft pisany na zamówienie, który wysyła maile na porcie 25 (bez uwierzytelniania, ciekawe, który admin serwera pocztowego przyjmuje taki syf z puli Neostrady). Co wtedy?

Póki co, postaraj się przekonfigurować czytnik poczty. Jeśli nie, zajrzyj za kilka dni…

Na wstępie uwaga: tak naprawdę wcale nie musisz tej blokady (i nie powinieneś – zobacz poprzednie wpisy, w których opisane są przyczyny jej wprowadzenia) wyłączać. O wiele lepszym rozwiązaniem jest zmiana konfiguracji czytnika poczty. No ale załóżmy, że skonfigurowałeś to komuś, komu za ChRL nie wytłumaczysz, jak zmienić konfigurację, a sam nie masz dostępu do tego systemu (pozdrawiam rodaków za granicą). Co wtedy?

Wtedy wystarczy zmiana loginu do usługi Neostrada. Na stronie TPSA zawarty jest dokładny opis możliwych ustawień poziomów ochrony przy pomocy loginu. Jak widać, możliwe w tej chwili są trzy warianty:

  1. „goły” login, czyli zablokowane porty „wirusowe” oraz 25,
  2. dodanie prefiksu „PODSTAWOWY-” do loginu – blokowane porty „wirusowe”, odblokowany port 25,
  3. dodanie prefiksu „BEZ_OCHRONY-” do loginu – odblokowane porty „wirusowe”, oraz port 25.

Aby odblokować wysyłkę poczty, wystarczy dodać prefix „PODSTAWOWY-„. Wpuszczanie wirusów nie ma sensu, szczególnie, jeśli użytkownikiem komputera jest ktoś, kto – mając do dyspozycji obrazkowe insturkcje – nie umie zmienić portu, na którym wysyłana jest poczta.

Jak widać, trzeba mieć zdalny dostęp do routera (albo założyć, że osoba, która nie umie zmienić portu poradzi sobie routerem, w co wątpię), albo zdalny dostęp do konfiguracji modemu (pod Windows to chyba tylko jakiś zdalny pulpit wchodzi w grę, ale wtedy lepiej zmienić port).

Kolejna niefajna sprawa, to fakt, że jeśli pomylimy się przy zmianie loginu (uwaga na wielkość liter, ma znaczenie!), to trwale odetniemy się od routera. Dlatego zmiana portu wysyłania poczty wydaje się znacznie lepszą, prostszą, bezpieczniejszą i korzystniejszą dla wszytkich opcją.

Tragiczny kod widgetu AdTaily.

Kiedyś, gdy AdTaily startowało (zamknięta beta), a ja miałem piękny i validujący się się XHTML 1.0 Strict na blogu, pierwszą rzeczą, na którą zwróciłem uwagę po zainstalowaniu widgetu, była była niezgodność z XHTML. Małe, a drażni, więc zgłosiłem błąd. Samemu nie udało mi się poprawić – primo, bardzo słabo znam JS, secundo, ok. 20 kB to jednak sporo do przeglądania.

O całej sprawie zapomniałem, aż do wczoraj, gdy niezależnie dwóm osobom (KosciaK i Tomasz Fiedoruk), o których wiedziałem, że powinny mieć umieszczony widget, napisałem, że wszystko fajnie, ale widgetu nie widzę. Winnym okazało się AdTaily, a raczej tragiczny kod ichniego widgetu, ale po kolei…

Pierwszy był KosciaK, u którego zwróciłem na fakt braku widgetu przy okazji wpisu o – ładnym skądinąd – nowym szablonie na blox. Ponieważ u mnie i na kilku innych blogach (bloxowych i nie), na tej samej przeglądarce, widget jest widoczny, myślałem, że chodzi o szablon właśnie, tym bardziej, że jakieś magie z jquery się tam dzieją.

Jakoś po stwierdzeniu, że na Operze widzę, na debianowej wersji Firefoksa, czyli Iceweasel w wersji 3.0.6 nie widzę, na Icecat (czyli w pełni wolnej wersji Firefoksa) 3.5.3 też nie widzę, a z kolei on u siebie widzi, po pobieżnym przyjrzeniu się problemowi, z braku czasu i pomysłów przeszliśmy nad tym do porządku.

Niewiele później zaczęło się na blipie narzekanie na sytuację z reklamami, co skłoniło mnie do stwierdzenia, że ciężko mieć reklamy, jak się nie ma widgetu. Tym razem chodziło o dwie strony, jedną bez fajerwerków w kodzie – jak twierdził autor – oraz, drugą, w której od biedy można by czegoś po stronie kodu szukać. Po stronie kodu strony niczego nie udało się znaleźć, więc podejrzenie padło na system operacyjny, jako jedyną część wspólną.

Po chwili do niedziałających przeglądarek dołączył Konqueror na moim systemie, oraz Iceweasel na systemie kumpla. Z kolei oficjalne buildy Mozilli wyświetlały wszystko jak należy. Także u mnie. Sytuacja bardzo ciekawa, więc postanowiłem zagadkę rozwiązać, tym bardziej, że to może jakiś błąd w Debianie (któraś z bibliotek czy coś takiego).

Po chwili zabawy z diffowaniem plików i kopiowaniem po kawałku oficjalnego builda do katalogu z Icecat okazało się, że „winnym” jest extra user agent. Cudzysłów jak najbardziej uzasadniony, bo tak naprawdę winny jest widget AdTaily. Fragment kodu:

parseFloat(b.substring(a+this.versionSearchString.length+1))},dataBrowser:
[{string:navigator.userAgent,subString:"Chrome",identity:"Chrome"},
{string:navigator.userAgent,subString:"OmniWeb",versionSearch:"OmniWeb/",identity:"OmniWeb"},
{string:navigator.vendor,subString:"Apple",identity:"Safari",versionSearch:"Version"},
{prop:window.opera,identity:"Opera"},
{string:navigator.vendor,subString:"iCab",identity:"iCab"},
{string:navigator.vendor,subString:"KDE",identity:"Konqueror"},
{string:navigator.userAgent,subString:"Firefox",identity:"Firefox"},
{string:navigator.vendor,subString:"Camino",identity:"Camino"},
{string:navigator.userAgent,subString:"Netscape",identity:"Netscape"},
{string:navigator.userAgent,subString:"MSIE",identity:"Explorer",versionSearch:"MSIE"},
{string:navigator.userAgent,subString:"Gecko",identity:"Mozilla",versionSearch:"rv"},
{string:navigator.userAgent,subString:"Mozilla",identity:"Netscape",versionSearch:"Mozilla"}],
dataOS:[{string:navigator.platform,subString:"Win",identity:"Windows"},
{string:navigator.platform,subString:"Mac",identity:"Mac"},
{string:navigator.platform,subString:"Linux",identity:"Linux"}]};

Jak widać, ktoś w AdTaily postanowił wymyślić koło od nowa i napisał własne rozpoznawanie przeglądarki i systemu operacyjnego. Na dodatek niezupełnie działające, bo nie obsługuje – z szybko przychodzących mi do głowy – Iceweasel i Icecat, zapewne także Swiftfox, Arora (nie wiem, jak się przedstawiają). W statystykach pewnie wychodzi, że nikt Konquerora nie używa, bo jeszcze nie widziałem by Konqueror się „KDE” przedstawiał (a z racji tematyki mam trochę wejść od użytkowników Konquerora). Po zmianie ciągu Icecat na Firefox we wspomnianym user agent extra version oczywiście widget wyświetla się tam, gdzie wcześniej się nie wyświetlał.

Zagadką dla mnie pozostanie, czemu pisana jest własna obsługa rozpoznawania przeglądarki (widget o 1kB większy, a i tak nie rozpoznaje wielu przeglądarek), czemu dzieje się to po stronie widgetu (a nie wysyłany jest cały user agent na serwer, jeśli to do celów statystycznych, a nie wyświetlania). O paru skrótach typu „Apple = Safari” nie wypowiadam się, bo zwyczajnie nie znam.

Ewidentnym błędem – jeśli chodzi o wyświetlanie – jest brak fallbacku do jakiegoś sensownego defaultu w przypadku nierozpoznania (a przecież engine przedstawiał się normalnie), nie tylko jest to sprzeczne z działaniem w każdej przeglądarce szerzej o kampanii Anybrowser, ale przekłada się na brak widzialności widgetu na niektórych stronach (ale nie zawsze! u mnie na blogu był widoczny bez problemu) u wszystkich użytkowników Debiana, korzystających z dostępnych domyślnie w dystrybucji przeglądarek. Oraz u wszystkich korzystających z podrasowanych/nietypowych przeglądarek.

Czemu tak było? Czy były inne skutki braku rozpoznania (np. nie zliczanie kliknięć w statystykach kampanii od nie rozpoznanych przeglądarek, gdy widget był widoczny)? Nie mam pojęcia, nie znam na tyle JS, by to wyjaśnić. To JS, więc kod jest dostępny, znających się zachęcam do obejrzenia.

Jakie jest rozwiązanie? Szybkie i brzydkie – dodanie brakujących przeglądarek w widgecie (znowu spuchnie, nadal nie wszystko będzie obsługiwane). Ładne – przepisanie widgetu, który nie tylko ma ww. problem, ale także nie jest widoczny z sieci Orange (mało ludzi zgłaszało to jako bug, więc nie spodziewałbym się w najbliższym czasie poprawienia tego), jest napisany w taki sposób, że jego wywołanie rozwala XHTML 1.0 Strict. Oczywiście rozwiązanie ładne będzie wymagało nakładów finansowych, ale biorąc pod uwagę, że nie jest to pierwsza około JSowa wpadka w ostatnim czasie, może warto nawiązać współpracę z kimś, kto takie rzeczy umie? Przeprojektowanie serwisu teraz będzie łatwiejsze niż później, podobnie zmiany w kodzie widgetu…

Temat (braku) bonusów za wynagrodzenia już poruszyłem na flakerze. Trochę inna tematyka, ale polecam lekturę wpisu No more free bugs. Z mojej strony to ostatni zgłoszony (za free) błąd. Co prawda dla mnie to (i szukanie błędów, co robić pewnie będę nadal, i ogólnie reklamy) zabawa, ale czemu mam odbierać chleb zawodowcom (przynajmniej tym od błędów i kodowania; reklamodawcy niech nie liczą na względy)?