środa, 29 lipca 2009

Domek Symbiana w przebudowie

Od wypuszczenia na rynek inteligentnej komórki opartej na Symbianie 9.4 czyli S60 5 edycji nie minął jeszcze rok a obecna sytuacja przypomina bardziej remont domu. W otoczeniu powstały nowe domki (iPhone czy Android). Więc nasz domek tez wymaga już remontu. Zmienił się właściciel domku. Kupił ten domek najczęstszy gość tego domku. Do tej pory sporo zainwestował w otoczenie domku. W odróżnieniu od nowych właścicieli domków w okolicy domek i działka były dość stare. Poprzedni właściciel dotychczasowego domku został wybrany głównym zarządcą. W tej sytuacji nowy właściciel bez zbytnego rozgłosu rozpoczął remont domku, żeby stary domek był bardzo nowoczesny wewnątrz. Zarządca domku ma zaplanować jak będzie wyglądać rozbudowa domku. Natomiast właściciel wziął się za sprzątanie wewnątrz domu.

Pozostawiono że remont przedpokoju odbędzie się na samym końcu. W przedpokoju znalazła się stara drewniana podłoga (Symbian C++) która zostanie zastąpiona terakotą (Open C) i gresem (Open C++) podobnie jak w całym domku. Dotychczasowy salon (AVKON) zostanie przebudowany tak, żeby znalazł się nowy barek (Java eSWT) i kominek (Qt for S60). W kuchni (Java Mobile) będą wymienione meble na nowsze (Java Mobile Runtime). Łazienka (przeglądarka internetowa oparta na WebKit 413) zostaną wymienione nowe płytki (S60 Browser 7.1 z silnikiem przeglądarki WebKit 525). W toalecie (Nokia Web Runtime) wymieniono tez płytki (silnik przeglądarki WebKit 525). Pokój dla dzieci (Python for S60) przekształci się w pokój dla nastolatki (Python Mobile 2.0) z barwnym gresem (OpenC) .
Z garderobiani (Adobe Flash Lite) wymieni się wszystkie stare ubrania (FlashLite 2.0 z AVM) na nowoczesne (FlashLite z AVM 2.0). W całym domku wymieni się na nowe oświetlenie (API Platform Services 2.0). Na tyłach domku powstanie duży taras (NetS60) sąsiadujący z domkiem oplecionym winogronami (Windows Mobile) . Pomimo remontu domku zarządca (fundacja Symbian) chętnie zaprasza gości prezentując, udostępniając im plany nowego domku (Symbian^4). Większość ludzi przechodzi wokół domku komentując wygląd domku w kontekście nowych sąsiadów. No cóż ze z zewnątrz wygląda na zabytek to jednak mało kto to zwraca uwagi na remont wewnątrz domku. Przynajmniej właściciel i zarządca oraz ich goście mogą spokojnie przeprowadzić remont.

piątek, 24 lipca 2009

S60 Browser 7.1

Tempo rozwoju technologii mobilnych według mnie ostatnio osiągnęła tempo wręcz zawrotne, a większość użytkowników inteligentnych komórek jakoś nie zauważa tego. Co dopiero mówić o programistach tworzących zaawansowane aplikacje internetowe na urządzenia przenośne. Ich jest mało, a technologi jest sporo.

Nokia ostatnio ogłosiła, że niektóre komórki z Symbianem 9.3 (S60 3rd FP 3.2) i Symbianem 9.4 (S60 5th) będą miały aktualizowany firmware z nowszą wersją S60 Browser 7.1 Główne cechy tej przeglądarki to:
- oparcie na nowym silniku Webkit 525 (co sprawia że staje do równej rywalizacji z przeglądarkami internetowymi z iPhone czy Androida)
- współpraca z FlashLite 3.0 sprawia że jak tworzący zawartość dla stron internetowych będą musieli robić wersje plików SWF na urządzenia mobilne - chyba że poczekają jeszcze pół roku na pojawienie się FlashLite z AVM2, co nie zmienia faktu, że wersje stron internetowych zawierających zawartość Flash Platform powinny mieć wersje dla FlashLite.
- unikalną integrację z możliwościami komórki np: ustalenie położenie właściciela komórki, dostęp do danych takich jak IMEI, czy natywny edytor wiadomości z poziomu PlatformServices 2.0 API na poziomie WebRuntime (co daje przewagę nad widgetami Opery Mobile). Gdyby dodali jeszcze API do OpenGL ES z poziomu JavaScript to byłaby chyba rewolucja (wyprzedziliby to co Google ma do zaoferowania z O3D czy Mozilla z Canvas3D)

Według mnie rywalizacja technologii internetowych na urządzenia mobilne przechodzi na nowy wymiar ze względu na możliwości technologiczne (sensory, geolokalizacja, identyfikacja poprzez IMEI). Jak wiadomo coraz większa rolę będzie odgrywała możliwość osadzania w aplikacji na urządzenia mobilne wbudowanej przeglądarki internetowej. W przypadku Symbiana trzeba zaprogramować sobie Browser Control API czy z Qt for S60 za pomocą QWebView object. W przypadku Androida mamy do dyspozycji WebView z takim przykładem a w przypadku iPhone UIWebView na przykładzie takiego przykładu
Według mnie przewaga Symbiana w tej dziedzinie osadzania zawartości HTML/CSS/JS w aplikacji jest bezapelacyjna w przypadku Qt for S60 ze względu na łatwą możliwość integrowania kodu JS w kodzie strony który miałby odwoływać się do API w Qt C++ danej aplikacji. No i mam obsługę plugina FlashLite w przypadku wybrania Browser Control API.

Drugi nurt rozwoju technologii internetowych na urządzenia mobilne to widgetyzacja. Widgety mobilne to technologia która pozwala na tworzenie małych programów pobieranych z internetu i ich działanie opiera się że mogą działać w komórce zarówno jak w trybie offline i jak przy połączeniu z internetem. Przeważnie pozwalają one na pobieranie danych w celu ich prezentacji. Głownie wykorzystywane są technologie internetowe czyli HTML/CSS/JS do zrobienia tych aplikacji na komórki.
Widgety zostały spopularyzowane przez Operę jako programiki uruchamiane z poziomu przeglądarki. Wkrótce potem Nokia zaproponowała tworzenie takich małych programików w oparciu o WRT (WebRuntime). Ostatnio Opera dzięki współpracy z T-Mobile wprowadziła Mobile Widgets SDK, aby móc zainstalować sobie Mobile Widgets trzeba pobrać Opera Widgets SDK i wypakować z pliku opera-widgets-sdk-0.3.zip Managera Widgetów Mobilnych
opera-widgets-sdk-0.3.zip\opera-widgets-sdk-20090603\util\manage\Opera_Widgets_Manager_9.50-716.sis
Warto też poczytać o tworzeniu widgetów i ich dystrybucji.
Miejscem gdzie można publikować swoje widgety są: T-Mobile Widget Development Site, Betavine z Vodafone oraz oczywiście na Ovi Store (tylko te z WRT) oraz z drJukka (WRT)

Pobieżna obserwacja wskazuje, że tworzenie widgetów mobilnych nie jest przeniesieniem strony internetowej do odpowiedniego formatu. To już raczej tworzenie aplikacji pod możliwości danego silnika który obsługuje dana technologię widgetów. Ponieważ specyfika pomiędzy rożnymi wersjami przeglądarek i silników na urządzenia mobilne są znaczne wiec warto zapoznać się z testami z Quirksmode a szczególnie w rozróżnieniu pomiędzy wersjami widgetów mobilnych a tych z przeglądarki Opery.

poniedziałek, 20 lipca 2009

Wirusy na Symbiana

Ponieważ coraz częściej pojawiają się informacje o tym że są wirusy na Symbiana (na blogu Symbiana, na blogu F-Secure, na blogu specjalisty Dancho Danchew) postanowiłem wyjaśnić czytelnikom jak sobie radzić z tym.
Faktem jest, że pomimo restrykcyjnych zabezpieczeń zdarza się komuś zainstalować podejrzane oprogramowanie. Nic nie poradzi się na to, że twórcy złośliwych programów mogą podszywać się pod jakieś znane oprogramowanie. Pierwsza zasada bezpieczeństwa to nie instalować podejrzanego oprogramowania. Wystarczy, że mafia otworzy jakieś serwis z linkami do paczek z programami do Symbiana oraz doda tam swoją paczkę SIS z wirusem. Mafia zleci napisanie pliku pkg z którego wygeneruje się własny sis z dwoma paczkami w środku. Na tym portalu mogą być wersje selfsigned albo nie podpisane zachęcające użytkowników do podpisania swoim certyfikatem, czy złamania zabezpieczeń w komórce. Nie jest to dobra sytuacja.

Nieświadomy użytkownik przeważnie nie zwróci uwagę na to czyj jest certyfikat. Nawet mało kto wie jak można sprawdzić plik SIS przed instalacją. Większość użytkowników ma w komórkach nawet wyłączone w swoich komórkach sprawdzanie czy dany certyfikat nie jest na liście unieważnionych certyfikatów Symbiana np: stąd
Jak włączyć sprawdzanie certyfikatów?
Menu -> Narzędzia -> Ustawienia -> Aplikacje -> Menadżer Aplikacji -> Opcje -> Ustawienia -> Sprawdzanie certyfikatów online -> Musi być sprawdzony/Musi Przejść

Co ważniejsze będzie przed instalacją sprawdzanie do kogo należy certyfikat. Wystarczy użyć polecenia:

signsis -o jakis.sisx

Jeżeli komuś zależy na sprawdzeniu poprawności certyfikatu w paczce może użyć takiego polecenia:

createsis dump jakis.sisx

Przeważnie będzie tak, że jak się zauważy certyfikat chiński to trzeba będzie zachować dużą ostrożność (z wyjątkiem kiedy jest to własny chiński certyfikat developerski).

Do sprawdzenia paczek instalacyjnych sis warto użyć witryny http://www.whatisinmysis.com/ wystarczy wysłać podejrzany plik paczki i wtedy będzie można zauważyć uprawnienia API dla danego pliku i jak ścieżkę certyfikacji.

Przydałby się jakiś skaner online, który by skanował pod katem identyfikatorów aplikacji - SID pewne pliki z paczek miałyby SID już mógłby być już na poziomie skanera zidentyfikowane jako szkodliwe. Warto wysłać podejrzany plik paczki sis do sprawdzenia przez File Scannera czy Sample Analysis System.
Można też wypakować pliki z paczki sis poleceniem:

dumpsis -x jakis.sisx

albo użyć programu SiSXplorer.
Wirusów na Symbiana będzie przybywało w sytuacji kolejnej "liberalizacji" dostępu programu SymbianSigned i powrotu do wydawania certyfikatów developerskich. Nawet pisanie wirusów i łamanie zabezpieczeń oraz szukanie luk bezpieczeństwa w tym systemie operacyjnym sprawi że mafia coraz bardziej zainteresuje się wykorzystaniem tej platformy do własnych celów.

Na dzień dzisiejszy widzę następujące rozwiązanie chroniące częściowo użytkowników przed wirusami i nadużywaniem uprawnień API. Użytkownik posiadający certyfikat developerski będzie mógł tylko podpisać aplikacje które mają tylko UID3 tylko w zakresie testów. Próba podpisania aplikacji która ma UID3 inny niż testowy spowoduje odmowę podpisania. Inne rozwiązanie to dać ludziom narzędzie które będzie równocześnie skanerem antywirusowym, skanerem integralności paczki SIS i weryfikatorem chronionych UID3 i oczywiście umożliwiać podpisywanie certyfikatem developerskim. A jak z ochroną przed piractwem? Są 2 podejścia: dostarczać oprogramowanie na bazie IMEI, w przypadku złamania wprowadzić weryfikację UID3 co uniemożliwi ponowne podpisanie. Następnie oprogramowanie powinno też weryfikować podpisane aplikacje pod kątem unieważnionych certyfikatów.

niedziela, 5 lipca 2009

Certyfikaty na Symbiana

Jednym z najbardziej kontrowersyjnych tematów wśród posiadaczy komórek jest podpisywanie aplikacji na Symbiana. Inżynierowie tworzący Symbiana spodziewając się problemów z masowym tworzeniem niebezpiecznego oprogramowania na komórki, postanowili zabezpieczyć się przed tym. Pierwsze zabezpieczenie to wprowadzenie mechanizmu wymogu podpisywania paczek instalacyjnych certyfikatami. A drugie zabezpieczenie to mechanizm uprawnień dostępu do plików w komórce i do pewnych bibliotek poprzez programistyczne API.

Warto przypomnieć z artykułów Symbian Foundation Security Blog kilka faktów: tworzenie infrastruktury opartej na certyfikatach nie było prostym zadaniem dla firmy tworzącej system operacyjny Symbian. W tej sytuacji postanowiono przekazać te zadania do zewnętrznych podmiotów. W 2004 roku postanowiono, że certyfikatami będzie zarządzać Verisign, testowaniem Capgemini, a Symbian będzie tylko zarządzał portalem do rejestracji oprogramowania i certyfikatów. Potem doszedł w 2007 roku TC TrustCenter, który faktycznie przejął główną rolę dostarczyciela certyfikatów dla twórców oprogramowania na Symbiana. Skutkiem takiego podejscia oznaczało że developerzy musieli sami się obsłużyć i generowało dodatkowe koszty tworzenia oprogramowania. A producentom komórek taki model był bardziej na rękę bo przenosił odpowiedzialność za oprogramowanie do komórek na programistów i organizacje testujące. Wkrótce okazało się, że zaczęły się pojawiać zagrożenia, ze strony niebezpiecznego oprogramowania. W tej sytuacji postanowiono jakoś zabezpieczyć się na poziomie systemu operacyjnego. Więc inżynierowie z Symbiana postanowili tak zaprojektować system, żeby wymuszał instalację tylko podpisanego i zaufanego oprogramowania z certyfikatem. Tak więc od 2006 roku mamy pierwsze komórki oparte na Symbianie 9.x, które posiadały mechanizm zarządzania uprawnieniami dostępu do programistycznego API.

Uprawnienia dostępu do API oznacza tylko tyle co wolno robić danemu programowi użytkownika. Zanim program zostanie uruchomiony zawiera informacje o tym jakie uprawnienia dostępu do API potrzebuje. Podczas instalacji najpierw jest sprawdzany czy paczka ma poprawny certyfikat, następnie sprawdzany jest rodzaj certyfikatu. Certyfikat może być wygenerowany na konkretna komórkę według posiadanego numeru IMEI, albo wg informacji o właścicielu certyfikatu (tzw z Publisher ID). Można też wyróżnić certyfikaty po kątem sposobu w jaki mogą zostały wygenerowane: własny (self-signed), developerski (devcert), z uprawnieniami (cert with manufactured capabilities).

Do nauki programowania Symbiana wystarczy w większości przypadków certyfikat własny (selfsigned). Instrukcja zrobienia takiego podpisu z linii poleceń wymaga zainstalowania SDK i przerobienia tej instrukcji. Natomiast, żeby wygenerować podpis developerski trzeba wcześniej mieć wykupiony certyfikat typu Publisher ID z firmy TC TrustCenter. Ten certyfikat kosztuje 200$ na rok czasu. Następnie trzeba zarejestrować się na stronie Symbian Signed. Pobrać program Developer Certificate Request i na bazie certyfikatu z Publisher ID wygenerować plik certyfikatu developerskiego w programie Open Signed Offline na konkretny numer IMEI.

Dla kogoś komu zależy na nauce programowania na Symbiana może też sobie używać do woli programu Open Signed Online, dzięki któremu będzie mógł wysłać swoją paczkę sis do podpisania przez nich certyfikatem dla IMEI danej komórki. Trzeba tylko pamiętać żeby UID3 był w zakresie 0xE0000000...0xEFFFFFFF. Podpisując w innym zakresie UID3 trzeba pamiętać o tym że inni nie będą mogli podpisywać poza Tobą danej aplikacji, bo dany UID3 będzie przypisany do danego adresu email osoby, która zażyczyła sobie dany UID3.

W takiej sytuacji dużą popularnością cieszą się chińskie usługi on-line do tworzenia developerskich certyfikatów. Są to: iMobile czy Opda.

Natomiast jak zależy na wprowadzeniu oprogramowania do masowej dystrybucji to czeka jeszcze sporo wydatków i pracy. Pierwszym to jest zakup certyfikatu PublisherID. Następnie zarejestrowanie się w programie Express Signed gdzie można kupować identyfikatory dla zawartości. Jeżeli zależy na tym, żeby twoja paczka sis z zawartością miała chroniony identyfikator UID3 to trzeba kupić PayPalem tak zwany ContentID. Następnie trzeba podpisać aplikację z certyfikatem i kluczem z TC TrustCenter. kolejną rzeczą jest wysłanie tego pliku sis do podpisania certyfikatem Symbiana (Root B). W programie Express Signed można podpisywać zawartość pasywną (multimedia, motywy) i jak aplikacje. Z tym, że trzeba wcześniej samemu sprawdzić czy aplikacja spełnia warunki testów. Po wysłaniu trzeba odczekać jakiś czas, a po wstępnej weryfikacji na koncie będzie podpisana przez Symbiana aplikacja. Czasami losowo występuje audyt twoich aplikacji. Jeżeli aplikacja nie będzie spełniać testów to konto zostanie zablokowane aż do momentu wysłania aplikacji spełniającej wymogi testów.

Natomiast w programie Certified Signed warto uzyskać podpisanie aplikacji pod kątem bezpieczeństwa i dostępu do zastrzeżonych uprawień API. Jest to dość kosztowny audyt, ale dzięki temu że zewnętrzni audytorzy sprawdzą działanie programu sprawi też że można uzyskać pewność że aplikacja jest bezpieczna dla użytkowników.

Nokia w programie dla firm Forum Nokia Launchpad wymaga, żeby firma biorąca udział w tym programie już posiadała Publisher ID. Natomiast dla własnych potrzeb mają dział który zajmuje się przygotowywaniem aplikacji do przetestowania wg dodatkowych kryteriów testów przez zewnętrzne firmy posiadające uprawnienia do testowania aplikacji. Dodatkowe kryteria są opisane w dokumencie Nokia Test Criteria for Symbian C++ Applications v2.1. Firmy, które zajmują się testowaniem aplikacji na Symbiana przed przyznaniem im zaufanych certyfikatów ną nazywane "Test Houses" Są to: Digia, Flander, Mphasis, NSTL, Sogeti.

Dla programistów midletów w technologii MIDP2.0 sytuacja też nie jest klarowna. Twórcy Java Mobile w sytuacji gdy inżynierowie Symbiana tworzą zręby pod zabezpieczenia ich systemu operacyjnego postanowili przejąc model wymagania podpisu w sytuacji dostępu do określonego API. Gdy liczba pakietów dostarczanych dla Java Mobile zacząła lawinowo rosnąć do ciała standaryzujacego, wymusiło to na producentach komórek wdrożenie mechanizmów bezpieczeństwa. W praktyce to polega na tym że każdy niepodpisany midlet w komórce nie może wykonywać potencjalnie niebezpiecznego API. W praktyce każdy producent urządzeń definiował to jakie API będzie wymagał podpisania.W praktyce wyszło że firma Verisign wdrożyła program Java Verified, któy miał podpisywac midlety Javy aby były one zaufane. Aby aplikacja Javy Mobile stała się zaufana to trzeba dokonać zakupu certyfikatu do podpisywania midletów typu PublisherID. Ten certyfikat jest inny niż ten który jest używany do podpisywania aplikacji Symbiana. Następnie trzeba zarejstrować się w programie Java Verified i wysłać podpisanym zakupionym certyfikatem w celu uzyskania podpisanej wersji zaufanej w celach testowych. W praktyce to oznacza że możesz w ciągu tygodnia czasu przetestowac aplikację w komórce majac dostęp do trusted API. Aby aplikacja Java Mobile mogła być uruchomiona w każdej komórce to jest potrzebne wysłanie midletu do organizacji testującej. Po opłaceniu testów otrzymujesz wynik testów i pliki midletu podpisane podpisem organizacji testujacej. I potem znowu z witryny w programie Java Verified otrzymujesz midlet podpisany który możesz już dystrybować aplikację.

Wkrótce sytuacja stała się taka, że wysokie koszta zaczęły generować ośrodki testujące aplikacje przed dopuszczeniem aplikacje Javy Mobile do oficjalnego podpisywania. Wystawiały one testy w zależności od ilości modeli komórek do przetestowania. Testy odpowiadały na pytanie czy aplikacja Java Mobile spełnia testy opisane w dokumencie Unified Testing Criteria (PDF). W tym przypadku głównym problemem okazał się dla większosci hobbystów i zaawansowanych użytkowników komórek fakt posiadania Publisher ID. Pośrednio to przyczyniło się do spadku zainteresowania technologiami Java Mobile przez programistów i zaawansowanych uzytkowników, w szczególności w Stanach Zjednoczonych co pokazują takie wpisy na blogach: Ivana Kuznietsova, czy J2MESecrets ( trochę nie bez powodu w Stanach Zjednoczonych komórki Nokii są mało popularne).

Z perspektywy czasu patrząc na rynek oprogramowania na Symbiana sytuacja jest dość dziwna. Restrykcyjne zasady tworzenia oprogramowania na Symbiana sprawiają że wiele osób chciałoby coś zaprogramować i udostępnić światu, muszą liczyć się z tym że mało ludzi umie podpisać aplikacje na Symbiana, czy wyrobić certyfikaty na własną komórkę. Obecnie w dobie popularności zaawansowanych komórek rośnie rola tych którzy łamią i obchodzą zabezpieczenia (dla Apple iPhone są to jailbreaki), natomiast w przypadku Symbiana oprogramowanie które dodaje dostęp do ukrytych folderów i jak wyłącza sprawdzanie uprawnień API podczas instalacji (np: HeliOX).

W komórce jest repozytorium certyfikatów są tam certyfikaty rożnych firm które otrzymały możliwość dodawania swojego certyfikatu jako zaufanego. Ale i tak hakerom czasami udaje się wgrać odpowiednie własne certyfikaty. Dodanie własnego certyfikatu sprawia że można podpisywać aplikacje własnym developerskim certyfikatem. Inną możliwością jest patchowanie pliku swpolicy,ini w plikach ROM (tak zwanej pamięci gdzie są przechowywane pliki potrzebne do uruchomienia podczas restartu). Głównie łamaniem komórek interesują Ci ludzie, którzy chcą mieć pełną kontrolą nad tym jak działa Symbian w ich komórkach.

Czasami korzystam z narzędzi które mają sprawdzić poprawność i integralność certyfikatów:
devcertlist - który sprawdza numery IMEI w certyfikacie i uprawnienia do API w danym certyfikacie

Ponieważ Fundacja Symbiana widzi coraz większe zapotrzebowanie na rozwój ich aplikacji, pozostaje przed dylematem jak rozwiązać mechanizmy dystrybucji aplikacji. Obecny model miałby sens gdyby nie było certyfikatów deweloperskich. Sytuacja przypomniałaby sytuację twórców aplikacji na iPhone. Zakup certyfikatu PublisherId, a potem zakup hurtowej ilości ContentID jest nie do przyjęcia dla większości programistów którzy robią i piszą aplikacje dla własnych potrzeb.. W tej sytuacji korzystniejszym modelem byłoby "fundowanie" opensourcowych aplikacji poprzez PublisherId w zamian za to, że autor aplikacji może rozwijać się w tworzeniu aplikacji na Symbiana. Wystarczy jakiś system podobny do tego jak Git, gdzie system podczas rejestracji proponował podanie IMEI komórki użytkownika. W zamian za to że ktoś tam opublikuje kod źródłowy to otrzyma UID3. Jak użytkownik zamieści tam swoją niepodpisaną paczkę sis, to system wygeneruje certyfikat na IMEI komórki użytkownika. Inni użytkownicy, będą mogli sobie pobrać kod źródłowy i skompilować go u siebie a następnie odesłać razem z kodem na serwer w celu uzyskania podpisu. Opcjonalnie byłaby kompilacja kodu na serwerach (za opłatą oczywiście). W ten sposób może to się rozwijać w stronę IDE on line dla programistów. Wiadomo że ten model raczej będzie cieszył się uznaniem tych którzy będą mieli dostęp do podpisanych sisów rożnych wersji tego samego programiku. Z jednej strony taki otwarty model trzymania kodu źródłowego może zachęcić programistów do robienia swojej wersji programiku "Witaj Świecie" na komórki jak zobaczą jak wielu innych też dzieli się swoim kodem. Nokia dala już dostęp ludziom do kodów biblioteki Qt i fajnie jest jak potencjalni uzytkownicy mogą obserwować zmiany w kodzie źródłowym bibliotek Qt. Im więcej darmowego oprogramowania na Symbiana i tym więcej kodów źródłowych będzie korzystnie wpływać na wizerunek Symbiana i producentów komórek z Symbianem. Im więcej stron dla początkujących jak nauczyć się programowania na Symbiana C++ pisanych przez uczących się to tym lepiej dla wszystkich.