Przem Kalicki – zapiski

Rozwijając program GPSTrack+ zainteresowałem się możliwościami współczesnych telefonów. Jak szybko zachłysnąłem się możliwościami skrytymi za kolejnymi specyfikacjami JSR, tak szybko zostałem sprowadzony na ziemię. W kręgu moich szczególnych zainteresowań były dwie specyfikacje:
JSR-82(odpowiada za komunikację poprzez Bluetooth) i JSR-75(odpowiada za odczyt i zapis danych użytkownika). O ile z tą pierwszą nie było żadnych większych problemów, to sposób implementacji tej drugiej pokazał mi słabe strony oprogramowania Java dla telefonów – według mnie są to podpisy cyfrowe. Odkryłem, że aby moja aplikacja miała prawo czytać i zapisywać dane w systemie plikowym musi być podpisana cyfrowo. Na początku wydawało się, że to ma sens – wyglądało to na troskę o użytkowników telefonów, aby nie instalowali oprogramowania niewiadomego pochodzenia. Nawet gdy takie były założenia, to przegięto – ochrona użytkownika nie kończy się na ostrzeganiu przed zagrożeniami. Poszli dalej! W niektórych rejonach działania aplikacji twórcy telefonów uniemożliwiają współpracę programu z telefonem. Aplikacja może zapytać czy użytkownik na pewno chce pozwolić niepodpisanej aplikacji na dostęp do plików na stałe (SonyEricsson k550i), może pytać za każdym razem gdy użytkownik będzie czytać plikać (Nokia 3110c), albo w ogóle o nic nie pytać tylko zabronić dostęp do wszystkiego(Motorola v360).
I jakie masz wtedy wyjście użytkowniku? Albo poszukać jakiegoś obejścia sprawdzania cyfrowego podpisu dla midletu (pisałem o tym między innymi tutaj dla Motoroli, a tutaj można poczytać o sposobie na Nokię 3110 [s40]), albo zmusić developera do podpisania aplikacji. To pociąga za sobą same problemy: aplikację taką trzeba podpisać certyfikatem, który już znajduje się w telefonie. Z tego co sprawdziłem na kilku modelach różnych marek ogranicza wybór do w zasadzie kilku centrów certfyfikacyjnych, między innymi VeriSign. Certyfikat VeriSign do podpisywania aplikacji to wydatek prawie 500$ na rok. Jaki jest sens stosowania go przy pisaniu aplikacji OpenSource? Żaden. Gorzki wniosek jest taki, że kupiłeś telefon, ale tak naprawdę to nie możesz go używać do czego chcesz! Aby wykorzystać wszystkie jego możliwości będziesz płacić! Dopłacisz, bo żaden deweloper zmuszony do wykupienia certfyfikatu nie będzie rozdawał programów za darmo.
Można jeszcze inaczej – producenci telefonów różnią się w podejściu do utrudniania użytkownikom midletów. Poniżej tabelka z stopniami sprawdzania (źródło):

Jak widać postęp jest z generacji na generację. Mój obecny telefon SE W910i należy do ósmej generacji, nie ma żadnego problemu z dostępem do danych użytkownika.
Mogę domyślać się tylko, komu zależało na wyciągnięciu tych paru dolarów więcej. Rzesza programistów Java która mogłaby pisać niezliczone ilości przeróżnych aplikacji czy rozwijać platformę MicroEdition nie będzie wiązać się z czymś, do czego ciągle trzeba dopłacać na niejasnych zasadach. I chyba szukając alternatywy już ją znaleźli…

Szukając materiałów na temat znalazłem wpis na pewnym blogu o bardzo wymownym tytule: „How MIDlet Signing is Killing J2ME”