Wyciek danych studentów, pracowników i współpracowników Uniwersytetu Warszawskiego
Polskie uczelnie od dawna nie mają szczęścia do ochrony danych swoich studentów i pracowników. Uniwersytet Warszawski właśnie informuje o dużym incydencie bezpieczeństwa, dotyczącym studentów MIMUW, WPiA oraz pracowników uczelni.
Wycieki, wycieki, wycieki. Zgubiony laptop pracownika, SGGW, atak włamywacza na Politechnikę Warszawską, atak przestępców na SWPS i Collegium Da Vinci – do kolekcji dużych incydentów na polskich uczelniach w ostatnich miesiącach dołączył właśnie Uniwersytet Warszawski i to w dość trywialny sposób.
Bo to ukryte repozytorium było
UW rozsyła dzisiaj wiadomości do swoich studentów i pracowników, informując o incydencie bezpieczeństwa i prawdopodobnym wycieku ich danych. Pełną treść komunikatu możecie sobie rozwinąć poniżej, my skupimy się na najciekawszych elementach – czyli „co, jak i kiedy”.
Zacznijmy od pierwszego pytania, czyli co wyciekło. Tu nie mamy dobrych wiadomości. Według komunikatu w ręce niepowołanych osób mógł trafić pełny zestaw danych osobowych przetwarzanych przez uczelnię. Wszyscy studenci MIMUW (nie wiemy niestety, których roczników to dotyczy – komunikat tego nie precyzuje) i „część studentów WPiA” (nie wiemy, która część), a także pracownicy i współpracownicy zostali narażeni na wyciek takich danych jak:
- imiona i nazwisko,
- informacja o zmianie nazwiska,
- nazwisko panieńskie,
- płeć,
- zdjęcie,
- PESEL,
- data urodzenia,
- obywatelstwo,
- numer indeksu,
- numery telefonów (prywatne/służbowe),
- adresy e-mail (prywatny, służbowy, studencki),
- adresy korespondencyjne,
- stopień naukowy,
- status osoby: student/pracownik,
- dane dot. profilu w bazie USOS,
- program studiów,
- funkcje pełnione na uczelni.
Wygląda na komplet danych przechowywanych w USOS-ie. Jak zatem doszło do wycieku i jak dowiedział się o nim UW? To chyba najciekawszy dla naszych czytelników fragment:
[…] w serwisie dostępny był katalog z repozytorium kodu źródłowego, które zawierało dane […] Umieszczenie repozytorium z danymi było
następstwem błędnych działań osób odpowiedzialnych za przygotowanie i konfigurację nowego serwisu www.mimuw.edu.pl. […] Repozytorium z danymi było ukryte. […] Aby uzyskać dostęp do katalogu, należało posiadać wiedzę związaną z hostingiem aplikacji WWW i używaniem
repozytoriów kodu; dane osobowe nie były odsłonięte i w łatwy sposób dostępne publicznie. Do repozytorium można było uzyskać dostęp tylko w wyniku wykonania działań inwazyjnych określonego typu, nie przez standardowe korzystanie z portalu. Ponadto administrator stwierdził wystąpienie podatności polegającej na umieszczeniu w repozytorium kodu źródłowego klucza dostępu, który umożliwiał wysłanie do bazy USOSapi (serwis zawierający kompletne rekordy danych) indywidualnego zapytania, dotyczącego konkretnej osoby fizycznej.
Analiza wsteczna komunikatu wskazuje, że najprawdopodobniej w serwisie www.mimu.edu.pl w trakcie prac wdrożeniowych pozostawiono dostęp do folderu /.git, zawierającego pełne informacje o wszystkich plikach znajdujących się na serwerze, a w plikach tych znaleziono bazę danych oraz klucz do API umożliwiającego odpytanie USOS-a o wszystko. To swego czasu dość popularny błąd – ale mówiąc „swego czasu” mamy na myśli lata 2000 -2010, a nie 2020.
W komunikacie znajdują się także inne kwiatki.
W dniu 5 listopada 2020 r., na podstawie powiadomienia przesłanego do Uniwersytetu Warszawskiego przez CERT Polska o krytycznych błędach w serwisie www.mimuw.edu.pl ustalono, że od dnia 12 czerwca 2017
roku w ww. serwisie dostępny był katalog […] Po dokonaniu pełnej analizy zdarzenia i logów systemowych administrator ustalił, że dostęp do repozytorium mogła uzyskać osoba nieuprawniona.
Wszystko zatem wskazuje na to, że dane leżały sobie od czerwca 2017(!), a Uniwersytet dowiedział się o tym tylko dlatego, że informację przekazał zespół CERT Polska. Sam CERT opis błędu otrzymał podobno od kogoś, kto błąd odkrył i chciał w odpowiedzialny sposób przekazać dalej. Brawo odkrywca, brawo CERT Polska za sprawną obsługę incydentu, ale zdecydowanie nie brawo Uniwersytet. Na dokładkę logi wskazują, że z danymi zapoznała się osoba nieuprawniona – ciekawe, czy tylko jedna. To nie wygląda dobrze.
Niezwykle ciekawa jest też terminologia użyta w opisie incydentu. W tym samym komunikacie znaleźć możemy takie oto stwierdzenia:
[…] na żadnym etapie nie przełamano zabezpieczeń informatycznych systemów MIMUWu […]Repozytorium z danymi było ukryte […] dane osobowe nie były odsłonięte i w łatwy sposób dostępne publicznie
Do repozytorium można było uzyskać dostęp tylko w wyniku wykonania działań inwazyjnych określonego typu […]
Administrator stwierdził, że w wyniku ataku nieznany sprawca uzyskał dostęp […]
Gdy to czytamy, to nasuwa się jeden wniosek: skoro dane były ukryte, nie były dostępne w łatwy sposób, potrzebne były działania inwazyjne oraz atak, lecz mimo tego nie doszło do przełamania zabezpieczeń, to znaczy, że tych zabezpieczeń po prostu nie było. Niestety.
Komentarz eksperta
O komentarz do incydentu poprosiliśmy Katarzynę Muszyńską, Head of Data Protection Team w LexDigital Sp. z o.o.
W przypadku przygotowywania powiadomień do osób, których dane uległy naruszeniu, ważne jest, aby dostosować ich treść do zakresu danych posiadanych o tej osobie. Możemy przypuszczać, że zakres danych różnił się w przypadku studentów uczelni i pracowników oraz współpracowników. Co za tym idzie – osoby te mogą spotkać się z innym rodzajem konsekwencji związanych z naruszeniem ich prywatności. Urząd Ochrony Danych Osobowych kładzie ogromny nacisk na przygotowywanie informacji możliwie jak najbardziej spersonalizowanej dla danej grupy osób. Wielokrotnie po zgłoszeniu naruszenia do organu nadzorczego konieczna jest weryfikacja treści i ponowna wysyłka komunikatu.
Trudnością, jaką napotykają organizacje podczas wysyłki komunikatów o incydencie, jest fakt posiadania aktualnych danych kontaktowych do osoby. Być może adresy e-mail nie są już aktywne i jedynym rozwiązaniem na skuteczne powiadomienie staje się wysyłka listu pocztą tradycyjną.
Warto wspomnieć, że podczas analizy tego typu incydentów przydatnym narzędziem staje się ocena wagi naruszenia wg modelu Enisa (wytyczne Agencji Unii Europejskiej ds. Bezpieczeństwa Sieci i Informacji). Ocena pozwala na klasyfikację naruszenia i uzyskanie informacji, jak daleko idące konsekwencje incydent niesie dla danej osoby. Na bazie wyniku analizy podejmuje się decyzję o zgłoszeniu naruszenia do organu nadzorczego i podjęcia środków zaradczych.
Na koniec coś pozytywnego
Wygląda na to, że w przeciwieństwie do Politechniki Warszawskiej, UW obsługuje incydent w sposób rzetelny i otwarty. Zamiast zamiatać sprawę pod dywan i udawać, że nic się nie stało, jasno i otwarcie komunikuje przyczyny i skalę problemu. Co więcej, gdy zerkniemy na rekomendacje przekazane ofiarom, zobaczymy wiele wartościowych uwag. Dowiemy się, że:
- powołano zespół kryzysowy,
- incydent został zgłoszony odpowiednim organom,
- zmieniono hasła i klucze dostępu,
- trwa audyt wewnętrzny i szykowany jest audyt zewnętrzny,
- UW monitoruje, czy dane nie zostały upublicznione.
UW rekomenduje także korzystanie np. z HaveIBeenPwned, dwuskładnikowego uwierzytelnienia i menedżerów haseł. To dobre rekomendacje. W sumie to chyba najlepszy zestaw rekomendacji, jaki widzieliśmy do tej pory pod komunikatem o wycieku danych. Na minus zaliczymy tylko brak jakiegokolwiek komunikatu na stronie MIMUW (albo my nie potrafimy znaleźć).
Podsumowując, incydent bardzo wstydliwy, a reakcja całkiem niezła. Przedmiot oblany, ale można powtarzać.
O bezpieczeństwie kont i hasłach
Kontom i hasłom poświęcone są dwa odcinki naszego unikatowego kursu wideo Bezpieczeństwo Dla Każdego. W prostych słowach tłumaczymy, jak podnieść bezpieczeństwo swoich kont i unikać sytuacji stresowych towarzyszących dzisiaj studentom i pracownikom uczelni. Do tego 29 innych tematów, ważnych dla każdego użytkownika sieci – każdy znajdzie tam coś ciekawego.
Tekst zaktualizowany o informacje o odkrywcy, który powiadomił CERT Polska oraz o komentarz eksperta, zamieniona została też grafika z USOSweb na stronę główną MIMUW, by uniknąć wątpliwości.
Podobne wpisy
- Jak włamano się do Ubera i dlaczego najwyraźniej nie było to trudne
- Jak złamano hasła ofiar wycieku danych z KSSiP?
- Jak wszystkie polskie media podały dalej fake newsa o włamaniu hakerów do banku
- Jakie dane rosyjski Killnet wykradł z serwera polskiej agencji
- Co ujawnili Anonymous (i inne grupy), czyli historia prawdziwych wycieków ostatnich tygodni
Nie „brawo Cert Polska” tylko brawo osobo ktora podeslala info o podatnosci do Cert Polska.
Nie bardzo rozumiem. Czy mógłbyś wyjaśnić o co chodzi?
Znany manipulant. Zignoruj go.
Niestety, są poszlaki że wyciek mógł być szerszy, jestem studentem innego wydziału UW niż wymienione i też dostałem maila z tym powiadomieniem. Aktualnie staram się wyjaśnić, czy nie został wysłany przez pomyłkę i jak moje dane znalazły się na serwerach MIMUW.
Jestem absolwentem MIMUW i z dawnych rozmów z wydziałowym adminem pamiętam, że MIMUW hostował USOSa dla całego UW, hostował też serwis do rekrutacji (IRK to się nazywało). Więc zdziwiłbym się, gdyby problem dotyczył tylko studentów MIMUW.
Jedyna szansa jest wówczas, jeśli są oddzielne instancje dla różnych wydziałów i (to ważne): mają różne klucze API, które *nie są* w tym samym repo.
Na szczęście od 10 lat już jestem magistrem ;)
Magister, nie bój, nie bój… myślisz, że oni skasowali dane, bo skończyłeś studia?
No właśnie… dane których studentów wyciekły? Obecnych? Byłych? Dane absolwentów też?
Ktoś wie?
I teraz powstaje ciekawe pytanie, czy to byl nieuprawniony dostep skoro nie bylo zadnego zabezpieczenia…
głębokie ukrycie jest zabezpieczeniem tak czy siak, to jak zakopanie sztaby złota w lesie i nikt mi nie wmówi, że tak nie jest, nie sprowadzajmy się wyłącznie do haseł, wielo-składmnikowych cudów, a to że ktoś może sobie z wykrywaczem metali przechodzić to już inna sprawa :)
Porownania maja to do siebie, ze sa niedokladne i niekoniecznie odzwierciedlaja przypadek ktory jest omawiany. Jednak idac tym tokiem, znalezienie sztaby zlota w lesie przestepstwem nie jest. Tak samo jak znalezienie 5zl w trawie.
Kiedys przyjmowalo sie, ze to co nie jest zabezpieczone jest publiczne. To jest sensowne zalozenie, poniewaz w Internecie dzieje sie wiele rzeczy, na przyklad jakies pajaczki sobie laza i skad taki automatyczny pajaczek ma wiedziec ze czegos ma nie dotykac. To wlasciciel swojej aplikacji w Internecie musi jasno okreslic „nie dotykac”. Tutaj to nie nastapilo.
Ciekawostka – znalezienie złota w lesie i nie oddanie go jest przestępstwem: https://pl.wikipedia.org/wiki/Przyw%C5%82aszczenie
Niekoniecznie. Nie wiadomo, czy sztabka znaleziona w lesie posiada prawowitego wlasciciela, czy to jakas pozostalosc na przyklad po II Wojnie Swiatowej. Dlatego wlasnie takie analogie sa bez sensu, bo sprowadzaja dyskusje na dziwne tory, niezwiazane z meriutm sprawy.
Dlaczego na ilustracji do artykułu jest USOSweb a nie strona wspomniana w artykule?
Czy taki obrazek przestraszy większą publiczność i podbije oglądalność?
Z tego co wiem bezpośrednio, to kto inny zauważył to niż CERT. Ta osoba zgłosiła to do MIMu, a dopiero jak MIM nie chciał reagować, skontaktowała się z CERTem żeby ich pogonili.
Wydział Archeologii- To samo co p.Marcina. :(
Z treści oświadczenia wynika, że prawdopodobnie wyciekł kod serwisu mimuw.edu.pl, w którym był klucz dostępowy do USOS API. Patrząc na daty podane w komunikacie, klucz mógł być dostępny od samego początku istnienia serwisu (który zdaje się był wdrożony w 2017 roku).
Serwis USOSweb – usosweb.mimuw.edu.pl przedstawiony na grafice pod treścią oświadczenia jest zupełnie innym serwisem, nie powiązanym z mimuw.edu.pl (poza wykorzystywaniem tej samej domeny), i z mojej „insajderskiej” wiedzy wynika, że jego konfiguracja raczej nie wyciekła. USOS API jest aplikacją hostowaną centralnie, dla całego UW, z dostępem do danych wszystkich osób, bez podziału na wydziały.
Klucz do USOS API mógł być wykorzystywany przez serwis mimuw.edu.pl w wyszukiwarce pracowników wydziału, która swoją wiedzę mogła czerpać z USOS. Jest wielce prawdopodobne, że ten klucz pozwalał odpytywać USOS API o dowolnego studenta oraz pracownika uczelni i udostępniał takie dane: https://usosapps.uw.edu.pl/developers/api/services/users/#user, co jest zbieżne z informacjami podanymi w komunikacie. Jeżeli klucz był skonfigurowany poprawnie to atakujący nie powinien mieć dostępu do innych funkcjonalności USOS API, takich jak pobieranie czy modyfikacja ocen studenta.
CERT dostal dwa zgloszenia bo na serwerach UW byly dwa repozytoria git dostepne dla kazdego kto chcial poszukac.
Skąd te informacje?
Gdzie było to drugie repo? Może napiszą o tym artykuł albo dodadzą do tego?
Jako osoba związana z UW/MIM-em/USOS-em chciałbym wyprostować kilka rzeczy. Bo już Rzeczpospolita na podstawie ZTS informuje o wielkim „wycieku z USOS-a”.
Prawdopodobny (prawdopodobny, bo nie ma informacji o tym, że ktoś nieupoważniony faktycznie miał dostęp do danych wrażliwych) wyciek dotyczy zasobów uczelnianych, ale nie całego UW, tylko jego wydziału (UW ma kilkadziesiąt wydziałów). Lista danych, które mogły zostać udostępnione częściowo pokrywa się z tym co jest w USOS każdej uczelni. Ale tylko pokrywa. Nic więcej z tego nie wynika. W bazach USOS tak naprawdę danych może być dużo więcej albo dużo mniej, to zależy od wielu różnych czynników. Tylko, że to nie jest wyciek danych z bazy USOS, którą ma u siebie UW, tylko wyciek z portalu MIM UW.
Z tego, że w repozytorium znajdował się klucz do USOS API również nie musi nic wynikać (oczywiście może, ale nie musi). Klucz mógł zostać dezaktywowany po zakończeniu pracy. Dodatkowo klucze mają różny poziom dostępu i obejmują konkretne metody. To mógł być klucz, który miał dostęp np. tylko do wysyłania maili na dane ID. Żadnych informacji na ten temat nie mamy, więc na razie mamy same domysły. (Swoją drogą z kluczami USOS API jako takimi USOS – jako dostawca oprogramowanie – nie może wiele zrobić. Każda uczelnia ma swoje bazy, swoje instancje API, swoje zestawy kluczy, itp. USOS nie ma do tych danych *żadnego* dostępu. Udostępnia tylko narzędzia. I nie jest w stanie nic poradzić na to, że ktoś zapisał swoje hasło admina do bazy danych na żółtej kartce i przykleił do monitora :-) – albo jak w tym wypadku postanowił się podzielić ze światem kluczem do API).
W artykule jest obrazek przedstawiający portal USOSweb (wycinek USOS), ale znowu: to nie był wyciek danych przez portal USOSweb na UW. Bardziej adekwatnie byłoby wstawić tutaj screen z portalu MIM UW. Łączenie tego wszystkiego z USOS-em jest naprawdę mało fortunne.
Z maila od władz uczelni i artykułu jasno wynika, że incydent jest poważny, za pomocą klucza można było pobierać kompletne dane osobowe, a analiza logów wskazuje, że ktoś nieuprawniony już raz to zrobił. Pisanie, że nic się nie stało, jest takim samym hiperbolizowaniem jak przytoczonej Rzeczypospolitej, tylko że w drugą stronę.
> za pomocą klucza można było pobierać kompletne
> dane osobowe, a analiza logów wskazuje, że
> ktoś nieuprawniony już raz to zrobił
I to jest kluczowe.
Uważam, że odpowiedzialni za wspomniane serwery MIMUW powinni dokładnie zbadać te logi by ustalić, kiedy i jakich konkretnie osób dane zostały pobrane.
Następnie oczekuję opublicznienia liczby rekordów, które zostały pozyskane przez nieuprawnione osoby oraz poinformowania tych, których dane zostały pobrane, o tym fakcie.
@Amadeusz, nie czaisz o co chodzi. Chodzi oto, że ktoś może stwierdzić, że USOS jest dziurawym rozwiązaniem, gdy tymczasem dziurę zrobił admin aplikacji, która jedynie łączyła się z USOS-em.
To admin instancji USOS nie wie do jakich endpointów i jakie uprawnienia ma dany klucz i czy nadal jest aktywny? Czy po prostu Pan jest developerem USOS, a nie adminem instancji na UW?
Już dawno należałoby zmienić ustawę „Prawo o szkolnictwie wyższym” w taki sposób, żeby uczelnie *NIE* przechowywały następujących danych:
– zdjęcie: powinno być usunięte z baz uczelni po wydrukowaniu legitymacji (tak jako to robi warszawskie ZTM przy wyrabianiu karty miejskiej)
– adres zamieszkania (to jest zupełnie niepotrzebne, wystarczy adres do korespondencji) – można przy przyjęciu zapytać o miejscowość pochodzenia i dodać do statystyk, bez powiązania ze studentem)
Może ktoś z UW albo ministerstwa to czyta i pójdą po rozum do głowy?
Na szczęście od niedawna już nie żądają kserokopii dowodu/paszportu. Czas najwyższy by zacząć minimalizować dane na poważnie.
Adres zamieszkania stanowi podstawę przy przydzielaniu niektórych stypendiów i miejsc w domach studenckich więc tak czy inaczej w pewnych momentach musi on być obecny w systemie
No to jak trzeba to się go zażąda. Student niekorzystający ze wspomnianych świadczeń powinien móc nieujawniać tego adresu. To bardzo poufna informacja IMHO.
@Szymon
Należy zbierać tylko dane *niezbędne*. To, że dane „mogą być przydatne” albo nawet „są przydatne” nie wystarczy.
Adres zamieszkania do studiowania potrzebny nie jest. Kto będzie chciał ubiegać się o miejsce w akademiku, ten wtedy może podać adres.
Uważam, że ani uczelnie czy szkoły, ani państwo w ogóle nie powinno gromadzić baz danych z adresami zamieszkania, w zupełności wystarczy adres do korespondencji.
Na stronie MIMUW komunikatu co prawda nie ma, ale cała wydziałowa społeczność otrzymała od dziekana następującego maila:
Szanowni Państwo,
Drogie Koleżanki i drodzy Koledzy,
Drogie Doktorantki i Studentki, drodzy Doktoranci i Studenci:
Piszę ten list przede wszystkim z przeprosinami, które należą się
członkom naszej społeczności.
Większość z Państwa dostała oficjalny komunikat o naruszeniu danych
osobowych wskutek zdarzenia, jakie miało miejsce w portalu Wydziału
MIM. Całe zdarzenie i jego możliwe negatywne następstwa, a także kroki
już podjęte i środki, które może podjąć każdy, są w tym komunikacie
opisane zgodnie z wymogami przepisów RODO. Incydent został zgłoszony
do Urzędu Ochrony Danych Osobowych i do prokuratury.
Oto krótki opis naruszenia: na serwerze www dostępny był (przez
dłuższy czas) katalog z repozytorium kodu źródłowego, które zawierało
dane studentów i pracowników MIM, a w niektórych przypadkach
studentów Wydziału Prawa i Administracji i współpracowników
Uniwersytetu Warszawskiego. Umieszczenie repozytorium z danymi było
następstwem błędnych działań osób odpowiedzialnych za przygotowanie i
konfigurację nowego serwisu mimuw.edu.pl. Repozytorium z danymi było
ukryte; osoba nieuprawniona mogła uzyskać dostęp do niego tylko w
wyniku wykonania określonych przeszukań i działań inwazyjnych, nie
przez standardowe korzystanie z portalu. Chciałem wyraźnie podkreślić,
że na żadnym etapie nie przełamano zabezpieczeń informatycznych
systemów Wydziału MIM.
Niestety, możliwymi konsekwencjami ewentualnego naruszenia danych
osobowych mogą być nieuczciwe działania osób trzecich, wymienione w
oficjalnym komunikacie.
Incydent naruszenia jest wynikiem ludzkiego błędu; jest mi przykro i
wstyd, że doszło do tego akurat w naszej społeczności, w czasie, gdy
Wydział podlega formalnie i faktycznie mojemu nadzorowi. Pragnę
zapewnić, że podjęliśmy kroki, aby natychmiast usunąć możliwość
nieuprawnionego dostępu do danych, a także przeprowadzić wszechstronną
analizę i audyt systemów informatycznych WMIM, tak, aby podobna
sytuacja – żenująca wpadka – nie mogła powtórzyć się w przyszłości.
Czuję się za ten incydent odpowiedzialny. Raz jeszcze wszystkich
Państwa przepraszam.
Paweł Strzelecki
Dziekan MIM
Kolejny wyciek danych i zapewne nie ostatni. Nie ma idealnych zabezpieczeń. Tylko dlaczego karany jest jak zwykle przede wzystkim właściciel danych (ryzyko kradzieży tożsamości, konieczność wymiany dokumentów) oraz ich posiadacz (kara od UODO) a nie ten kto je bezprawnie wykorzysta (wyłudzający kredyt oraz bank który to akceptuje bo widzi tylko swój zysk) ???
Czas na surowe karanie przestępców i banksterów za posługiwanie się cudzymi danymi a nie posiadaczy tycj danych.
Patrząc na jakoś systemów produkowanych przez UW (patrz USOS lub IRK) jakoś nie dziwi fakt, że szambo wybiło; dziwić może że wybiło dopiero teraz :-D
USOS to dość dobry system z wieloma funkcjami ogromnie ułatwiającymi studentom życie. Ma pewne wady, ale i tak jest sto razy lepszy niż różne „wirtualne dziekanaty” czy inne, zwykle pełne dziur i działające na nieaktualnym sofcie, pisane na kolanie przez słabych adminów, autorskie systemy informatyczne uczelni nieużywających USOS-a.
Problem w tym, że większość uczelni czy wydziałów które z USOS-a korzystają, zrobiły to „bo dziekan kazał” albo „bo rektor kazał” i panie z dziekanatu traktują USOS jak zło konieczne. Ani myślą o wykorzystaniu go dla dobra studentów. Wyłączają moduły, które są w nim najlepsze – na przykład zaawansowaną rejestrację, każąc wszystkim studentom rejestrować się w trybie „kto pierwszy, ten lepszy”, co jest zaprzeczeniem idei USOS-a i w efekcie zmusza do wstrzelania się w rejestracje uruchamiane często o chorych godzinach.
Poza tym wiele wydziałów dane na swojej stronie www aktualizuje, a dane w bazie USOS – nie. M.in. z powodu lenistwa pań w dziekanatach, rozkłady zajęć nadal są robione tabelkami w EXcelu, a w USOS-ie pustka (mimo że ma świetny interfejs do planów zajęć). Trochę winy jest też po stronie uczelnianych adminów, którzy stawiają raz instancję USOS-a, a potem niezbyt o nią dbają.
Twórcy USOS-a nie mogą być obwiniani za to, że ktoś z ich oprogramowania korzysta niezgodnie z założeniami, że go nie aktualizuje, że nie napełnia go wartościowymi danymi etc.
Wiem, że wielu studentów UW ma takie przeświadczenie, ale USOS nie jest robiony przez UW, tylko na UW. USOS-em zajmuje się zrzeszenie bodaj 70 uczelni w Polsce, a BTW. główna siedziba tego stowarzyszenia jest w Poznaniu. Info znalazło się nawet na wikipedii.