22.11.2004
Ludzki interfejs
Jestem pod wrażeniem przeczytanej ostatnio książki pt. “The Humane Interface: New Directions for Designing Interactive Systems” autorstwa Jefa Raskina.
Projektant komputera Apple Macintosh wstrząsa posadami współczesnych interfejsów. Bierze pod lupę jakiś element współczesnych interfejsów komputerów osobistych, a następnie:
- mówi, dlaczego uważa ten element za źle zaprojektowany
- udowadnia naukowo, że istotnie jest z nim coś nie tak
- proponuje własne rozwiązanie
- tłumaczy, czemu jest ono lepsze
- naukowo udowadnia wyższość swojego rozwiązania
To, co uderza w “The Humane Interface”, to nie tylko skala problemów leżących u podstaw dzisiejszych GUI, które wskazuje autor, ale właśnie naukowe podejście. Choć psychologiczne dywagacje, w które wdaje się Raskin, są nieco przegadane, dość czytelnie wskazuje on przyczyny problemów ze stosowanymi dzisiaj rozwiązaniami. Przedstawia kilka ogólnie uznawanych koncepcji procesów poznawczych człowieka i wynikające stąd wspólne cechy wszystkich użytkowników komputerów.
Najważniejsze z pojęć, których doniosłe znaczenie dla projektowania interfejsów omawia autor, to pojedyncze centrum uwagi (ang. locus of attention) oraz przyzwyczajenie (ang. habit). Na ich podstawie Raskin pokazuje wady obecnych interfejsów (głównie okienkowych) oraz wyjaśnia lepsze mechanizmy, które sprawniej będą realizowały nasze cele.
Przez całą książkę przewijają się opisy komputera Canon Cat, którego projektantem był Raskin, i w którym z powodzeniem zastosowano wiele z proponowanych przez niego rozwiązań.
Oto wybrane ciekawsze lub ważniejsze spostrzeżenia i opinie autora:
- nie ma żadnego powodu, aby współczesny komputer osobisty włączał się dłużej niż kilka sekund
- rola przyzwyczajeń w codziennej pracy jest olbrzymia. Dobry interfejs powoduje powstanie właściwych nawyków i korzysta z psychologicznej wiedzy o sposobie ich tworzenia. Niestety, we wszystkich dzisiejszych interfejsach nagminnie korzysta się z trybów pracy (ang. mode), co powoduje - od czasu do czasu - błędy związane właśnie z przyzwyczajeniami
- użytkownik nie jest projektantem interfejsu - nie będąc ekspertem w tej dziedzinie nie wie, jakie rezultaty na dłuższą metę będą miały jego decyzje, dlatego wszelkie możliwości dostosowania (ang. customize) interfejsu zazwyczaj szkodzą użytkownikom i są zrzucaniem odpowiedzialności za wygodną pracę z barków autorów systemu
- nie powinno się tworzyć osobnych wersji interfejsu dla początkujących i doświadczonych
- projektując interfejs należy mieć na uwadze m.in. prawo Fittsa (dotyczy zależności między odległością i rozmiarem obiektu na ekranie a czasem wskazania go kursorem) i prawo Hicksa (dotyczy zależności między liczbą opcji do wyboru a czasem dokonania wyboru)
- autor proponuje analizę efektywności interfejsu za pomocą techniki GOMS
- negacja pojęcia aplikacji i systemu operacyjnego - z punktu widzenia użytkownika są one szkodliwe
- negacja systemu plików (wraz z drzewiastą strukturą katalogów) - z niewiadomych przyczyn w momencie, gdy użytkownik zechce przerwać pracę nad dokumentem, komputer wymaga od niego wymyślenia unikatowej w skali katalogu, niezbyt długiej, niezawierającej pewnych znaków ([, ], *, %, …) nazwy pliku i - co śmieszniejsze - choć plik ten może być kilkumegabajtowym tekstem, odtąd człowiek ma odwoływać się do tego pliku jedynie za pomocą owej krótkiej nazwy i trudnej do zapamiętania ścieżki dostępu
- każda operacja powinna móc zostać cofnięta lub ponowiona (globalne undo i redo)
- wyszukiwanie przyrostowe (incremental search), polegające na natychmiastowym szukaniu już pierwszych wpisanych do pola tekstowego liter, jest o wiele lepsze niż tradycyjne wyszukiwanie “wszystko albo nic”
- ikony są szkodliwe, zazwyczaj nieczytelne i pod niemal każdym względem przegrywają w konkurencji ze zwykłymi, słownymi etykietami opcji czy przycisków
- tradycyjne logowanie na podstawie nazwy użytkownika i hasła można zastąpić logowaniem na podstawie samego tylko hasła. (Raskin popełnił jednak błąd w swoim opisie tego pomysłu i nie mogę się zgodzić z jego propozycją, ale to temat na osobny wpis.)
- twórca Macintosha proponuje ZoomWorld - wirtualną, nieograniczoną przestrzeń roboczą z bogatym zestawem silnych narzędzi wyszukujących i nawigacyjnych, w której praca pozbawiona byłaby przywar obecnych systemów, wizualnie opartą na przybliżaniu i oddalaniu się od powierzchni, na której rozmieszczone są dokumenty, strony internetowe, pojedyncze polecenia (grupy takich poleceń to zamienniki aplikacji) i inne zasoby komputerowe
- spośród dwóch ogólnych sposobów pracy: czasownik-rzeczownik (akcja-obiekt) lub rzeczownik-czasownik (obiekt-akcja) lepiej sprawdza się ten drugi (oznacza on, że najpierw wybieramy obiekt do manipulacji, a następnie decydujemy, co z nim zrobić). W miarę możliwości wszystkie funkcje systemu powinny być realizowane w modelu obiekt-akcja
“The Humane Interface” to znakomita książka, choć niektóre tezy w niej zawarte są kontrowersyjne. Autor prezentuje nowe podejście do tworzenia urządzeń oprogramowanych w taki sposób, aby wykorzystać wiedzę o wspólnych cechach wszystkich użytkowników i nie walczyć z naturą ludzką. Jef Raskin parafrazuje regułę z książki “I, Robot” Isaaka Asimova w następujący sposób:
A system shall not harm your content or, through inaction, allow your content to come to harm.
co znaczy: “System nie naruszy wyników Twojej pracy ani, poprzez bierność, nie zezwoli, aby została ona naruszona”.
Duża część książki poświęcona jest zagadnieniu realizacji tego hasła.
Jak dotąd nie ma polskiego tłumaczenia tej pozycji, ale książkę można dostać w bibliotece Instytutu Informatyki Uniwersytetu Wrocławskiego.
po przeczytaniu tego tekstu czuje pewien nie dosty. wydaje mi sie ze ta ksiazka jest jak biblia prawda objawina od Jungowskiej bogini wiedzy ktrej nie da sie podwazyc niczym. tekst nie pasuje mi do recenzji, ani do polemiki z ksiaza, poprostu ja wychwala. te kilka uwag negatywnych to dal mnie za malo jak na ta forme prasowa. nie lubie czytac ze ta czy tamta ksiazka jest prawda objawiona. moze jest naprawde zajebista i koles sie na na rzeczy, jednak nie podoba mi sie sam tekst. za bardzo wychwala ksiazke. moze to moje polskie malkontenctwo ale tak jest i juz.
Och, Asar - przesadzasz. :) Zgadzam sie, ze od tekstu az wieje entuzjazmem, ale raczej wobec samej formy ksiazki, a nie jej tresci (jak zaznaczam, pewne tezy Raskina sa co najmniej kontrowersyjne). Potraktuj to, prosze, nie jako typowa recenzje, bo na to tekst rzeczywiscie jest zbyt nacechowany emocjonalnie, a raczej jako wieczorna opowiesc Kuby podnieconego podejsciem Jefa Raskina…
aha, no to spoko, czekam z niecierpliwoscia na teskt o kontrowersyjnym podejsciu autora. a po za tym bardzo mi sie podoba mozliwosc dostosowania opery do usera, mowie Ci Els zainteresuj sie tym.
Bardzo fajna recenzja. Ksiazka od dluzszego czasu zalega na mojej polce i do tej pory nie mialem czasu/motywacji zeby ja przeczytac. Po Twojej recenzji czuje ze bede musial:)
PS. Fajna macie biblioteke ze takie ksiazki sa dostepne : u nas w Wawie troche posucha w tym temacie;/
no proszę jaki fajny blog :) znasz jeszcze jakieś podobne miejsca po polsku?
“Human Interface” jest dostępny na eMule, po Twojej recenzji chyba sobie zarezerwuję czas na lekturę :)
No khem… jako bądź co bądź człowiek, który od czasu do czasu współtworzy coś, z czym będzie potem pracować end-user nie mogę nie odnieść się do części postulatów:
- jest naprawdę wiele dobrych powodów, aby komputer włączał się pół minuty czy minutę: jeśli mówimy o typowym komputerze w typowej firmie, który jest właściwie terminalem realizującym warstwę klienta w systemie informatycznym firmy to OK, ale ze stacjami roboczymi jest już dużo gorzej; zresztą… komputer rzadko się wyłącza, w szczególności w firmach,
- rozumiem, że chodzi o problem przełączania się między trybami pracy: owszem, z tym jest duży problem,
- uwaga o tym, że user nie ma pojęcia o customizacji pachnie trochę ślepym ekstremizmem pana Nielsena, któremu powinien ktoś pokazać, jak współczesni młodzi ludzie korzystają i czego oczekują od GUI;) - imho customizacja w przypadku aplikacji, których złożoność interfejsu przewyższa znacznie stopień komplikacji kokpitu F-14, jest absolutnie niezbędna: choćby tak prosta sprawa jak możliwość rozmieszczania i ukrywania toolbarów pozwala userowi na uniknięcia śmietnika na ekranie i dopasowanie UI do postulatów Fittsa i Hicksa,
- model GOMS.. no cóż, HCI to młoda dziedzina, podstawy naukowe jeszcze się formułują, ale czy ktoś, kto nie słyszał o modelu GOMS, nie stosuje go w części lub całości intuicyjnie?
- zgadzam się, że z punktu widzenia end-usera różnice pomiędzy OS a aplikacją nie powinny mieć znaczenia, podobnie śmieszne jest to, że nadal moja pierwsza partycja to “C:”, a link zawierający “Document and Settings” jest strasznie, strasznie długi - myślę, że to w ciągu najbliższych pięciu lat się zmieni,
- ikony dają radę… jest problem ze standardami w przypadku mocno niezależnych produktów (czyt. trzymania się układu ikon z Office), ale bez ikon naprawdę byłoby krucho (toolbar z napisami?! zgroza!),
- imho istnienie login i passwd jest uzasadnione przychologicznie, bo posiadanie hasła do _własnego loginu sprawia, że mniej chętnie je udostępniamy,
- ZoomWorld… tia… no pomyśl Els, wolisz przeglądać struktury katalogowe czy szukać Wrocławia na mapie świata korzystając z Zooma, hmmm? płaska reprezentacja skomplikowanych struktur to był zawsze _zły pomysł - aż prosi się o kontrę: “so show me your proof-of-concept, Luke!”, bo pomysł bez analizy i prototypu jest niewiele wart,
- obiekt-akcja rzeczywiście wydaje się najlepszym pomysłem, bo od poziomu usera do developera jesteśmy object-oriented.
ciekawostka:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/uicycle.asp
A wiecie, co mnie ciekawi? Ciekawią mnie koncepcje usability UI rozbudowanych aplikacji bazujących na klientach webowych - sam fakt, że takie aplikacje bazują na html i zwykle daleko im do kokpitów pokroju interfejsu Office sprawia, że zapędy umieszczenia wszystkiego-wszędzie są w naturalny sposób hamowane. Cóż… widać można dostrzec plusy ograniczeń technologii;).
Robert: nie bardzo. Jest niby http://nf.hyperreal.info/ i http://annazasada.com/, ale oba są praktycznie nieaktualizowane, nic więcej tego rodzaju nie kojarzę. (Pewnie jakieś blogi polskich webdesignerów mogą zahaczać o temat HCI, choć wątpię.)
Misia: włączanie komputera - ostatnio stwierdziłem, że np. Windows mógłby zapamiętać dokładnie stan pamieci, procesora i urządzeń peryferyjnych zaraz po uruchomieniu kompa (i załadowaniu OS-a) na dysku twardym (do zrobienia? chyba tak), po czym w momencie ponownego uruchmomienia komputera załadować ten stan, zakładając, że w systemie nic się nie zmieniło. Zmiany w oprogramowaniu, np. w konfiguracji systemu, mogą być zapisywane na dysk przez sam system, zmiany w sprzęcie można sygnalizować jakimś przełącznikiem dającym znać OS-owi (zresztą je chyba łatwo wykryć i nie zajmuje to dużo czasu). W przypadku takiej zmiany robimy pełen naturalny start, a nie start ze zrzutu pamięci. Po odpaleniu ze zrzutu ewentualne zmiany (godzina, wczytanie jakichś tymcasowych rzeczy, nie wiem) można zrobić w tle, aby nie przeszkadzać użytkownikowi, w ciągu pierwszej minuty-dwóch od włączenia komputera. Pytanie - czy to się da zrobić? (zakładając, że możemy zmieniać OS i sprzęt, przy czym sprzęt tylko troszkę) Czy w związku z tym trzeba by przebudować całą architekturę komputerów? Chyba nie bardzo. ;)
- czasami trybem jest prawie każde ustawienie konfiguracji w programie, albo wciśnięcie CAPS LOCK - coś, na co użytkownik podczas pracy nie zwraca uwagi, a co zmienia zachowanie programu
- GOMS - oczywiście, że nie, przykładem jest to, że użytkownik bardzo długo musiał pamiętać i wpisywać całą ścieżkę dostępu, co do znaczka, choć wystarczyło wpaść na system drzewek w GUI lub podpowiedzi następnego członu (jak w WinXP na przykład w oknach zapisywania plików)
- no mnie też jako informatykowi się to nie podoba, ale są naukowe dowody na to, że dostosowanie aplikacji szkodzi użytkownikom, m.in. poprzez wprowadzanie trybów. Dokładniej - nie przekonam Cię, musisz sięgnąć po tę książkę i sam ocenić, jakie jest Twoje zdanie
- są naukowe dowody na to, że ikony nie dają rady ;P (żartuję, ale tylko trochę. Powiedzmy sobie szczerze - ilu ludzi domyśli się na przykład, co znaczy ikona Reload w przeglądarkach, jeśli nie zna podpisu?) Znów - trzeba by sięgnąć do wyników badań
- ZoomWorld - zgadzam się, że ZoomWorld Raskina ma poważne braki, autor w ogóle nie porusza np. tematu cudzej treści (nawigowanie po własnej treści jest prostsze niż po cudzej). trochę niezręcznie to opisałem, w ZoomWorld są “warstwy” i nie wszystko jest płaskie, im głębiej (bardziej się przybliżamy do kolejnych warstw), tym większy poziom szczegółowości. ZW ogólnie jest wesołą koncepcją, ale moim zdaniem stworzyłby mnóstwo nowych problemów. Może kiedyś doczekamy się czegoś takiego ;)
- nie wiem, jak z tą psychologią identyfikatora i hasła, ale wiem, że z praktycznego punktu widzenia pomysł Raskina jest nie do przyjęcia: po pierwsze, w takim systemie pojedyncza próba włamania to próba włamania na wszystkie konta naraz, po drugie nie można mieć dowolnych haseł, bo prędzej czy później nastąpi konflikt (i jakoś trzeba będzie go rozwiązać), wreszcie przy nie do końca dowolnych hasłach użytkownicy będą mieli większe problemy z zapamiętaniem ich, jeśli weźmiemy pod uwagę, że każdy użytkownik korzysta np. z 10 systemów na hasło
- co to są “koncepcje usability UI“? Tzn. co konkretnie Cię ciekawi? :)
Els:
Windows może to zapamiętać już _teraz- tryb “hibernacja”, szczególnie przydatny na laptopach:). A podniesienie stanu komputera bez wykorzystania dump’a wymaga czasu, podczas którego nie ma sensu pozwalać userowi na cokolwiek, skoro aplikacje jeszcze się nie uruchomiły. No i… naprawdę problem wolnego startu komputera w zasadzie nie istnieje, bo ile razy dziennie włączasz komputer? Znam prywatne osoby, których komputery wyłącza tylko brak prądu, a w firmach to popularna praktyka.
“Dopasowanie”, o którym napisałeś, zrozumiałem jako “customizację”, a Ty teraz coś o trybach mówisz… nie potrafię podać w tej chwili programu, który umożliwia userowi dostosowanie/dodawanie trybów - co miałeś na myśli? Dopasowywanie wyglądu pulpitu przez samodzielne rozmieszczenie toolbarów i ikon w samych toolbarach nadal uważam za bardzo, bardzo potrzebne. I akurat Office jest tego najlepszym przykładem, że nie trzeba być informatykiem, żeby to było potrzebne i wykorzystywane ;).
Ikony bez podpisów. No to chyba jasna sprawa, że mając sto różnych obrazków na ekranie mogę mieć problem z poprawnym rozpoznaniem ich znaczenia, dlatego wyświetlają mi się hinty. Znasz popularny program, w którym trzeba się _domyślać znaczenia ikon? Praca w dużych programach użytkowych bez ikon byłaby po prostu wolniejsza.
Usability interfejsów www. UI klientów webowych pozwala wykorzystać funkcjonalność biznesową typowej aplikacji, ale formą jest www. Koncepcje tworzenia UI dla aplikacji okienkowych oraz dla stron www są w tej chwili miejscami znącząco różne. Ciekawi to, ile interfejs www powinien czerpać z cech typowych dla aplikacji okienkowych (np. zakładki, menu, modalność okien), a ile z klasycznych, powiedzmy: informacyjnych stron www. Porównaj liczbę opcji dostępnej na głównej stronie onet.pl z pustym dokumentem Office (choćby Word) - w przypadku takich stron informacyjnych główną akcją jest po prostu “wyświetl”…
No i zajrzałem z ciekawości na http://nf.hyperreal.info/, bo nie znałem tej strony. Masakra! Jaka to “ergonomia, dostępność, użyteczność”, skoro są problemy z czytelnością, kontrastem, a właściwa część strony wykorzystuje u mnie raptem nieco ponad połowę ekranu? Czy 1280×1024 to taka ekstremalna rozdzielczość? Za to Anna Z chyba rozgląda się za pieniędzmi w innych branżach niż usability, skoro o swój blog nie dba ;).
pytanie: Robert, ty jesteś z warszawy?
moim zdaniem :-) :
ad 1. to nie ma większego znaczenia. czy będzie się włączać minutę, czy kilka sekund, efektywność i komfort pracy pozostają niezmienione. zresztą niebawem pojęcie komputera biurkowego zniknie.
ad 2. nie wiem, ale widocznie jest to czymś uzasadnione. błędy w pracy? czasem w takim np. vim’ie można się pomylić, czasem trochę to kosztuje.
ad 3. myślę, że każdy użytkownik w jakimś stopniu, może minimalnym, powinien mieć możliwość dostosowywania interfejsu. nie znam programu, w którym czegoś w interfejsie jest za dużo albo za mało i nie chciałoby się tego zmienić.
ad 4. nie mam zdania
ad 5,6. nie mam bladego pojęcia, o co chodzi
ad 7. i co, jeden system dla wszystkich? posługiwanie się komputerem, to pewna umiejętność. każdy powinien mieć choć minimalne pojęcie, o co chodzi, a na to składa się rozróżnienie między systemem operacyjnym i aplikacją (A: MacOs jest śliczny :-), B: tak, też kupię tego misia)
ad 8. denerwują mnie spacje w nazwach plików. poza tym uważam, że to jest przesada, by zapomnieć o systemie plików. jeśli ktoś jest niechętny zgłębianiu się w budowę jego struktury, mógłby korzystać z wygodnego interfejsu, tylko niech ktoś taki zaprojektuje. a jak autor chce zapamiętać nazwę dokumentu, nad którym pracuje użytkownik? problem jest po stronie użytkownika: jeśli nie ma nawyku, zawsze będzie nadawał enigmatyczne nazwy plikom. może się zastanowić nad sposobem wymuszenia dłuższej nazwy lub określeniu innych informacji, np. poprzez jakiś formularz przy pierwszej edycji pliku.
ad 9. raczej tak
ad 10. no pewnie :-)
ad 11. nie do końca. wprawdzie nie wiedziałem, do czego służy lornetka w pasku nawigacyjnym w firefox’ie, ale po lekturze Twojego wpisu zmusiłem się i już wiem: to nie jest lornetka, tylko domek (trzeba się uważnie przyjrzeć) i służy niczemu ;-) ikony są wygodne, w często używanych aplikacjach są niezastąpione (proponuję w Wordzie w pasku rysowanie zastąpić ikonki opisami słownymi ;-))
ad 12. i tak niedługo nie będzie haseł, tylko inne sposoby autoryzacji. Naczelny Architekt coś przebąkiwał, zresztą czytałeś
ad 13. 3D na monitorze? to musi być toporne. ciekawsze jest rozwiązanie wielkiego pulpitu z podglądem na tylko ćwiartkę. myślę, że przeciętnemu użytkownikowi byłoby dużo łatwiej, gdyby nie męczyć go zadaniami typu konfiguracja czy instalowanie produktu. to powinno dziać się automatycznie, w tle.
ad 14. pewnie, że drugi jest lepszy, każdy obiekt jest inny, trudno byłoby zatem, aby do każdego przypisać podobne akcje
ad Els ;-) nie dałoby się powiększyć tego okienka?
meister: tak, z warszawy, a co?
els: jakby na złość Tobie :) http://nf.hyperreal.info/ został dzisiaj zaktualizowany, ale to jednak bardziej blog webstandardowy niż związany z HCI…
dołączam się do sugestii o powiększenie i poszerzenie pola z treścią komentarza. :)
robert: absolutnie nic, coś mi się przywidziało :-)
Akurat Raskin rozprawia się z tymi trzema argumentami już w książce…
Włamanie? Statystycznie system jest bardziej bezpieczny, tylko pozornie wydaje sie inaczej (kryptografia pełna jest takich zagwozdek :) ).
Dowolne hasła? Nie są dowolne, wymyśla je komputer, dając tylko parę do wyboru; tym sposobem nigdy nie będzie konfliktu.
Zapamiętywanie? Użytkownicy nie będą mieli problemu z pamięcią, gdyż dużo dłuższe hasła (typu trzy przymiotniki + rzeczownik) są podbudowane zasadami gramatyki, które bardzo pomagają, a każdy z nas ma je od dawna wpojone. Czy ktoś oglądał kiedyś “Za chwilę dalszy ciąg programu?” Do dziś pamiętam “Bardzo stary wesoły miech,” chociaż nie ma to większego sensu. Czy tak samo pamiętałbym matematycznie równie bezpieczną sekwencję losowych cyfr i liter? Wątpię…
Marcinie: jeśli chodzi o argumenty Raskina i moje tezy o hasłach, to mogę (w niektórych miejscach matematycznie) udowodnić błędność lub przynajmniej niekompletność stwierdzeń autora książki.
1) Bezpieczeństwo. Raskin stwierdza, że taki system jest równie bezpieczny z dwóch powodów: po pierwsze dlatego, że system z hasłem n-literowym jest tak samo bezpieczny, jak z dowolnym loginem i hasłem n-literowym (argumentacja oczywista). Zgoda - ale tylko pod warunkiem, że w systemie istnieje jedno konto albo że próbujemy się włamać na jedno, wybrane konto. Jeśli w systemie istnieje milion kont, prawdopodobieństwo włamania się na dowolne z nich - a nikt nie chce, aby na jego konto ktokolwiek się włamywał - rośnie dokładnie milionkrotnie, czyli rozwiązanie nie jest skalowalne, jeśli chodzi o liczbę użytkowników systemu. Oczywiście, nie ma to praktycznego znaczenia np. w przypadku domowego komputera, ale jeśli mówimy o serwerze pocztowym z milionami użytkowników…
Raskin ubezpiecza się, dodając 1 (lub ew. więcej) znak do hasła w zamian za rezygnację z loginu. Wspaniale, ale 1 znak to zazwyczaj około 70 możliwości (znaki alfabnumeryczne i przestankowe), czyli aby zniwelować problem z wieloma hasłami naraz, potrzebujemy tych znaków kilka więcej. Czyli w praktyce jedno słowo więcej (w wielowyrazowych hasłach Raskina). To jedno słowo to przecież właśnie login, który łatwo zazwyczaj zapamiętać i który uniemożliwia jednoczesne włamywanie się na wiele kont naraz (jednym “zapytaniem” do systemu logowania).
2) Dowolność: tak, Raskin optuje za hasłami narzucanymi przez komputer. Dziękuję, nie trzeba. Jeśli dla każdego systemu mam zapamiętać trzy-cztery wyrazy (powiedzmy - krótkie zdanie), a systemów mam np. 30 - nie ma najmniejszej możliwości, aby to działało. Z powodu narzucania hasła nie będę mógł używać w różnych systemach jednego hasła. Rozwiązanie Raskina jest problemem. Niezłe jest popularne ostatnio w Sieci rozwiązanie “podstawa+dodatek”, gdzie podstawa jest stała między serwerami (systemami), a dodatek zależy jakoś od nazwy systemu (np. ustalony fragment domeny). Ścisła tajemnica samej podstawy jest gwarancją wysokiego bezpieczeństwa takich haseł. Jeśli dodatkowo użyjemy funkcji haszującej, mamy naprawdę niezły system. Ale w dalszej perspektywie trzeba będzie fizycznie identyfikować użytkownika - i to pewnie będzie najskuteczniejsze.
3) Zapamiętywanie - poruszone powyżej. Te dodatkowe literki w haśle, gwarant porównywalnego bezpieczeństwa systemu, są odpowiednikiem loginu, który może być dowolny ALBO również zaproponowany przez system (tylko tutaj już taki być nie musi). Nic nie stoi na przeszkodzie, żeby w związku z tym w tradycyjnych systemach nie proponować hasła odpowiedniej długości i odpowiedniego typu.
Fajnie byłoby zobaczyć badania, jak dobrze ludzie zapamiętują hasła wielowyrazowe, ale pozbawione sensu (choć gramatyczne)…
Swoją drogą - sekwencja 987karaiby654 jest niemal równie bezpieczna, jak losowy ciąg znaków, z punktu widzenia znanych mi ataków na hasła związanych w jakikolwiek sposób z ich konstrukcją (np. słownikowego), a nie jest trudna do zapamiętania, prawda? Nie potrzeba wcale żadnych kropek, przecinków, procentów ;) czy nawiasów, przynajmniej tyle wiem na ten temat. Ale może się mylę i jakieś znane metody łamania haseł poprzez niepełny przegląd istotnie łatwiej złamią 987karaiby654 niż 5%7^7dajkada? :P
1. Oczywiscie, ze chodzi o komputery domowe, cala ksiazka jest im poswiecona. :) Poza tym milion przy ilosci kombinacji nawet prostych hasel to naprawde nie jest duza liczba…
2-3. Tyle tylko, ze login — jako z reguly publicznie znany — zadnego bezpieczenstwa nie gwarantuje i z punktu widzenia kryptografii sa to “stracone” literki.
Ależ właśnie próbuję Ci udowodnić, że pomysł Raskina nie zwiększa bezpieczeństwa w żaden sposób.
Obecnie mamy hasła jakiejś długości i login jakiejś długości (login jest zazwyczaj jednym słowem). Wg Raskina mielibyśmy dłuższe hasła i brak loginu. Korzyść wg Raskina: mniejsze obciążenie pamięci i większe bezpieczeństwo (lub równe bezpieczeństwo).
Mój kontrargument: ze względu na jednoczesne łamanie wszystkich kont w systemie przy jednokrotnej próbie logowania hasło musi być dłuższe nie o jeden, a o kilka znaków i te kilka znaków równie dobrze można uczynić loginem. Raskin mówi o hasłach w domowych komputerach, jednak również hasło do poczty to hasło używane w domowy komputerze, prawda? Stąd kilka znaków (licząc 60 używanych znaków alfanumerycznych), aby “zniwelować” - powiedzmy - spadek bezpieczeństwa w systemie Raskina związany z milionem użytkowników (60^3 to 216 tysięcy, 60^4 to ok. 12 milionów - czyli 4 litery wystarczają, zakładam pesymistycznie, że wszystkie litery są równie często wykorzystywane przez ludzi) na serwerze.
Oczywiście loginy będą musiały być trochę dłuższe, nie musi być rzecz jasna żadnego ograniczenia górnego na ich długość, system sam może je podpowiadać, ale właśnie jestem zdania, że nie powinien tego robić.
Gwarancja bezpieczeństwa w tym przypadku polega tylko na tym, że system z loginem i hasłem uniemożliwia jednoczesne włamywanie się na wiele kont, który to problem związany z bezpieczeństwem występuje w systemie Raskina.
Chcę powiedzieć po prostu tyle, że wzrost długości hasła w systemie Raskina musi być wzrostem o kilka znaków i z praktycznego punktu widzenia lepiej, żeby te kilka znaków stanowiły login, ponieważ:
- unikamy trudności z losowaniem haseł przez system, tzn. ludzie mogą wówczas, ale nie muszą korzystać z dziwnego, choć gramatycznego hasła proponowanego przez system
- login również może, ale nie musi być proponowany przez system
- system robi się praktycznie dowolnie skalowalny ze względu na pojedynczy atak na parę (login, hasło) - niezależnie od liczby kont, bezpieczeństwo każdego z osobna i wszystkich razem się nie zmieniają
Nie można pominąć kwestii wielu systemów, do których potrzeba hasła, i sprawy wielu użytkowników w jednym systemie - a autor książki w dużym stopniu to zrobił i to był jedyny fragment książki, który mi się nie spodobał. Zresztą, trudno się dziwić, że nie ma tam więcej na ten temat, sprawie uproszczonego logowania poświęcił dokładnie jedną stronę książki ;)
Naprawde nie rozumiem, czym rozni sie Twoj pomysl od pomyslu Raskina, oprocz tego ze jedno wybrane slowo z hasla nazywasz loginem…
Loginy tez mozna “lamac” (jest to o tyle latwiejsze, ze z reguly kazdy ma dosc naturalny, i publiczny login). “Jednoczesne wlamywanie sie na wiele kont” a) moze nie byc wcale takie zle (nie ma domyslnego loginu typu “root” czy “admin,” od ktorego sie zaczyna i zdobycie ktorego konczy cala zabawe) i b) jest wlasciwie tylko ladna nazwa… Przeciez w dzisiejszych systemach moge rowniez “jednoczesnie sie wlamywac,” probujac najpierw poszczegolne loginy, a potem przy kazdym z nich wszystkie hasla… dla mnie to taka sama sytuacja.
Plus w rozwiazaniu Raskina? Uzytkownik nie zdenerwuje sie, ze ktos juz mu zajal “jkowalski.” :) (Co jest poniekad argumentem przeciwko “skalowalnosci.”)
Co do wielu systemow, racja, ale nie powinno sie stosowac takich samych loginow na roznych komputerach (choc pewnie wszyscy i tak to robia), no i da sie to rozwiazac “naokolo,” tak jak zreszta juz i teraz radzi sie z roznymi haslami na roznych serwerach.
Pojedyncza proba wlamania oznacza koniecznosc fizycznego polaczenia sie z systemem - dla uproszczenia przyjmijmy, ze polega na wyslaniu zapytania do systemu bazodanowego. Kazda taka proba zabiera jakis kwant czasu (pominmy na razie fakt, ze kolejne nieudane proby “z jednego miejsca” w dobrze zabezpieczonych systemach wywoluja coraz dluzsze przerwy miedzy kolejnymi probami logowania).
Chcac wlamac sie gdziekolwiek, dysponujemy ograniczona moca obliczeniowa i poswiecajac jakis czas mozemy wykonac maksymalnie tyle prob wlamania, ile wynosi ten czas podzielony przez dlugosc kwantu. Jasne, prawda? I teraz: nawet przy jawnych loginach (np. spis uzytkownikow systemu na stronie WWW) bezpieczenstwo systemu z loginami jest wieksze od tego bez nich, poniewaz wykonujac ustalona liczbe prob marnujemy je w systemie z loginami na pojedyncze konto, zas w systemie z samym tylko haslem kazda proba moze nam dac haslo dowolnego z uzytkownikow. W tym sensie bezpieczenstwo systemow bez loginow bedzie mniejsze.
Plus zwiazany z jkowalskim - znow, nie jest to u Raskina zaden plus… Wystarczy w obecnych systemach - jak to napisalem w komentarzu 16. - spowodowac, aby to systemu wlasnie proponowaly loginy, aby symulowac bezkonfliktowosc Raskina. Do tego celu nie potrzeba ZADNYCH zmian technicznych, nie trzeba systemu z samym tylko haslem, aby uniknac opisanej przez Ciebie frustracji. Ale ja, szczerze mowiac, strasznie wkurzylbym sie, gdyby system nadal mi login “fujara” zamiast mojego elsindela, ktory zawsze i wszedzie jest unikatowy, bo go sobie wymyslilem i wiem, ze wszedzie moge go uzyc. ;P
Zalozmy bardzo prosty przyklad. W pierwszym systemie mamy jednoznakowy login i jednoznakowe haslo (znak = cyfra od 0 do 9). W drugim systemie mamy dwuznakowe haslo. Zalozmy, ze mamy jedna probe.
Dla jednego uzytkownika:
- pierwszy system: szansa 1/100 (lub 1/10, jesli znamy login),
- drugi system: szansa 1/100.
Dla dwoch uzytkownikow:
- pierwszy system: szansa 1/50 (lub 1/10, jesli znamy login),
- drugi system: szansa 1/50.
Moze cos pokrecilem, ale wydaje mi sie, ze drugi system (= Raskina) jest co najmniej tak samo, a praktycznie bardziej bezpieczny?
Marcinie: tak, jesli haslo bedzie odpowiednio dluzsze w systemie Raskina niz haslo w systemie tradycyjnym, to bezpieczenstwo jego systemu bedzie odpowiednio wysoki. Chodzi o to, ze pomysl Raskina wprowadza po prostu nowy problem: nagle bezpieczentwo systemu jest (potencjalnie w znaczacym stopniu) zalezne od liczby uzytkownikow - to jest niewatpliwa wada jego rozwiazania (wada nr 1). Wada nr 2 (subiektywna) - w wielu systemach jeden uzytkownik bedzie mial wiele nonsensownych, choc gramatycznych hasel, i sadze, ze bedzie trudno to zapamietac. Trudniej niz jedno-kilka hasel, jak to jest dzisiaj (dopoki nikomu nie powie sie takiego hasla, nie zapisze etc. nie ma zadnego niebezpieczenstwa w uzywaniu jednego hasla do trzech kont pocztowych).
Uwaga do tego, co napisales: Raskin w ksiazce sie pomylil - napisal tam takie zalozenia:
tradycyjny login k-literowy i haslo n-literowe, szansa wlamania przy pojedynczej probie 1/|A|^n (A - alfabet).
Zgoda, napisal prawde.
jego haslo n-literowe, szansa wlamania przy 1 probie taka sama.
Zgoda.
Nastepnie napisal prpozycje: wydluzmy haslo o 1 znak i mamy wieksze bezpieczenstwo.
Nieprawda. Bezpieczenstwo jest wieksze wowczas tylko wtedy, gdy w systemie jest mniej uzytkownikow niz |A|, zas mniejsze, gdy jest ich wiecej. Jesli uzytkownikow jest |A| ^ 4, MUSIMY wydluzyc haslo o 4 znaki, aby osiagnac porownywalny stopien bezpieczenstwa.
I tak: jesli W SUMIE poswiecimy tyle samo znakow na haslo i login, to w systemie o niewielkiej liczbie uzytkownikow system Rasina jest teoretycznie bezpieczniejszy. Chcialem tylko zaznaczyc, ze w przypadku np. serwerow pocztowych tych dodatkowych znakow na haslo posiwecic musimy wlasnie kilka, aby liczba kombinacji wzrosla o milion czy 10 milionow, i te kilka juz mozna przeksztalcic w login i wracamy do obecnego systemu, nie trzeba zadnych rewolucji.
Swoja droga - jak to sie ma do poczucia kontroli? Czy uzytkownicy nie zbuntuja sie, ze system proponuje im kilka glupawych hasel, ktore na pierwszy rzut oka wydaja sie byc kpina z niego? :P
Marcinie - wreszcie (dopiero teraz sobie przypomniałem ;) mam argument za tym, że system bez nazwy użytkownika (system Raskin) może wymagać więcej wysiłku poznawczego od użytkownika.
Otóż - przypomnijmy sobie, jakie mamy ograniczenia na postać hasła u Raskina, a jakie w tradycyjnym systemie.
U Raskina:
- hasła są generowane przez system
- hasła mają postać gramatycznej frazy (domyślnie w języku użytkownika), złożonej z kilku (2-3) słów wybranych ze słownika
W tradycyjnym systemie:
- hasła są ustalane przez użytkownika
- hasła mają postać dowolną w ramach ustalonego alfabetu (zazwyczaj litery i cyfry, czasem trochę więcej znaków jest dostępnych)
Raskin twierdzi, że bezpieczeństwo jego systemu jest wystarczające, to znaczy liczba kombinacji - możliwych haseł - przy słowniku złożonym z tysięcy słów codziennego użytku idzie w miliardy lub jeszcze znacznie większe liczby (autor podaje tylko oczekiwany czas zgadywania hasła na współczesnej maszynie jednoprocesorowej, ale możemy założyć, że mamy do dyspozycji dość duży słownik danego języka z podziałem na rzeczowniki i przymiotniki, może też czasowniki czy inne części mowy).
Istotnie, przy trzywyrazowym haśle mamy całkiem sporo możliwości i próba ataku słownikowego (trochę oszukuję, ale chodzi mi o to, że atakujący również może mieć dostęp do słownika i po prostu generuje wszystkie gramatyczne kombinacje) na takie hasło jest równoznaczna z próbą losowego ataku na np. trzyznakowe hasło przy alfabecie o wielu tysiącach liter.
We wcześniejszych komentarzach podawaliśmy obaj jakieś niewielkie liczby określające długości haseł w systemie Raskina. Jednak w oczywisty sposób długość haseł u Raskina jest nieporównywalna z długością haseł w tradycyjnym systemie z dwóch powodów:
- podstawowym znakiem z punktu widzenia bezpieczeństwa nie są litery, a słowa ze słownika. Ponieważ hasła muszą być gramatyczne, mamy ustalony zbiór słów i reguł budowania hasła, który osoba atakująca system też zna (wystarczy, że sama jest użytkownikiem systemu). W praktyce zatem zamiast np. ośmioznakowego hasła przy 60-literowym alfabecie w tradycyjnych systemach mamy 3-znakowe hasło przy wielotysięcznym alfabecie u Raskina, gdzie każde słowo (pomijając nawet odmianę, która zresztą w języku angielskim nie występuje w przypadku rzeczowników i przymiotników) jest jednym znakiem do “zgadnięcia”
- z punktu widzenia człowieka jedno słowo, cząstkę hasła Raskina, łatwiej zapamiętać niż 5-7 liter (taka mniej-więcej jest przeciętna długość słów w języku polskim czy angielskim, a w każdym razie w tej okolicy), ale też na pewno jest to bardziej kosztowne niż jedna-dwie litery. Im mniej zakorzenione w umyśle użytkownika słowa występujące w haśle Raskina, tym trudniej mu je zapamiętać - a ponieważ są one generowane na zasadzie losowej, nawet wśród kilku proponowanych haseł użytkownik raczej nie znajdzie niczego, co przystaje w jakiejś mierze do jego doświadczeń i będzie łatwiejsze do zapamiętania niż losowa fraza w jego języku. W praktyce zatem zapamiętanie hasła kilkuwyrazowego będzie niełatwe, a zapewne trudniejsze niż zapamiętanie własnego hasła.
Nie jestem w stanie podać żadnej obiektywnej miary poziomu trudności zapamiętania kilku słów, może psychologowie zajmujący się pamięcią coś na ten temat by powiedzieli, ale z tego, co mi wiadomo, nie mamy jeszcze takiej wiedzy.
W każdym razie nie bardzo jest jak porównać trudność zapamiętania nazwy użytkownika i 8-znakowego hasła w tradycyjnym systemie z trudnością zapamiętania nonsensownego, gramatycznego hasła kilkuwyrazowego w systemie Raskina. Analiza znak-po-znaku, której próbowaliśmy wyżej, jest więc całkowicie błędnym podejściem i oczywiste jest, że długość hasła w systemie Raskina jeśli chodzi o liczbę znaków będzie większa niż długość dzisiejszej pary (użytkownik, hasło), co wcale nie będzie przekładało się na większe niż normalnie bezpieczeństwo, bo nie znaki, a słowa są budulcem bezpieczeństwa u Raskina.
Podsumowując: cały pomysł w przypadku dużych systemów uważam za wątpliwy. W przypadku małych systemów jest godny rozważenia.
Swoją drogą - tworzę właśnie niewielki system, do którego dostęp będzie ograniczony, a samych użytkowników będzie kilkoro. Inspirowany lekturą Raskina uznałem, że nie ma sensu wprowadzanie nazw kont użytkowników, a ponieważ bezpieczeństwo nie jest w tym przypadku kluczowe (i nie ma mowy o jakiejkolwiek skali), zamiast wpisywania nazwy użytkownika będzie po prostu wybór imienia i nazwiska z listy pracowników (system wewnątrzfirmowy) i prośba o hasło. W przypadku ewentualnych konfliktów nazwisk wystarczy prezentowane informacje rozszerzyć np. o nazwę stanowiska, drugie imię, dział firmy lub inną daną różnicującą.
Takie rozwiązanie wydaje mi się uczciwym kompromisem: nie trzeba pamiętać nazwy użytkownika, a hasło może być wymyślone przez użytkownika lub proponowane przez system (wszystko jedno).
Odnosnie poziomu trudnosci zapamietywania slow, to generalnie wazne sa 2 aspekty: konkretnosc vs abstrakcyjnosc oraz powiazanie (mniej lub bardziej sensowne) vs przypadkowosc.
Konkretnosc oznacza, ze latwiej je sobie wyobrazic i w ten sposob lepiej zapamietac, a sensowne powiazanie powoduje, ze pamietajac jedno z nich, latwiej sobie przypomniec reszte.
Nie mozna zapominac jednak o znaczeniu osobistym: cos dla 99 osob bedzie bezsensowne, a dla jednej bedzie mialo indywidualny sens.
Zeby system Raskina byl przyjazny dla uzytkownika, proponowane wyrazy powinny byc co najmniej konkretne: niech to np. bedzie “pomidor” ale nie “interakcja”. Choc jednoczesnie autorowi bloga byloby pewnie blizsze to drugie ;)
Powstaje zatem problem podzialu raskinowskiego slownika na wyrazy latwe i trudne do zapamietania (teoretycznie mozna by to zbadac eksperymentalnie, ale byloby to dosc kosztowne). A gdyby chciec jeszcze wziac pod uwage drugi czynnik, tym bardziej nie byloby latwo okreslic, ktore zestawienia sa “sensowne”, a ktore nie.
Jesliby zas z tego zrezygnowac, to haslo nie byloby tak latwe do zapamietania, jak sie Raskinowi wydaje. Choc niewatpliwie latwiejsze, niz absolutnie losowy ciag znakow w rodzaju: j$ot54@k*Ą.
Wygladaloby wiec na to, ze blizszy uzytkownikowi powinien byc system tradycyjny, w ktorym to on wybiera sobie login i haslo - takie, jakie jemu odpowiadaja.
Ale rowniez tu tkwi haczyk: otoz z calym szacunkiem dla uzytkownikow obawiam sie, ze niewielu potrafi tak sobie dobrac haslo, aby jednoczesnie bylo bezpieczne (a zatem nic osobistegow rodzaju daty urodzenia czy drugiego imienia) i latwe do zapamietania (tj. aby osoba nie miala potrzeby go nigdzie zapisywac).
Poza tym wiekszosc uzytkownikow nie zna pojecia “atak slownikowy” wiec dosc czesto (to moje obserwacje i intuicja) do roli hasla wybierane sa pojedyncze slowa, ktore, zdaje sie, stosunkowo latwo zlamac.
Nie bardzo wyobrazam sobie, zeby przy rejestracji wyskakiwala odpowiednia informacja w stylu “Jak wybrac odpowiednie haslo?”, a gdyby nawet, to malo kto by ja uwaznie czytal. Alternatywa, zwlaszcza w miejscach, gdzie to jest szczegolnie wazne (w bankach, korporacjach itp.), wydaja sie po prostu szkolenia pracownikow w zakresie bezpieczenstwa informacji. Ale co zrobic np. z klientami bankow, ktorzy oczekuja bezpieczenstwa, a nie maja ochoty uczyc sie podstaw kryptografii i psychologii zapamietywania? :P Zdaje sie, ze nie ma prostej odpowiedzi…
Witam
Mam pytanie może ten watek jest już zakończony (szczególnie odnośnie logowania na podstawie hasła ) , ale mam pytanie co sie stanie gdy uztkownik zapomni hasła istnieje taka możliwośc jaka bedzie możliwośc przypomnienia mu tego hasła?? zapomniales hasła?? podaj e-mail?? jezeli tak to mozna podac kazdy e-mail na który zostanie wysłane hasło lub instrukcji odzyskania hasła.
Dobre pytanie. Jeśli system ma jedną tylko informację o użytkowniku i jest nią hasło, to oczywiście nie ma żadnej możliwości odtworzenia hasła - żadnej podstawy do kontaktu z Klientem. Login w postaci emaila (stopniowo staje się to standardem) wraz z hasłem umożliwia przypomnienie/zmianę hasła. To, co napisałeś, jest więc chyba kolejną wadą pomysłu Raskina.