Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

• (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
• (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

• Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
• Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.

—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Reklama

„Ciche” zdarzenie w procesie

Miałem pomysł na wpis zainspirowany tym, co się dzieje obecnie w Polsce i na świecie. Zrezygnowałem jednak z niego, choć tematyka tego wpisu będzie jakoś związana z tematyką zdrowia i medycyny. Jakiś czas temu, wysłałem w usługach medycznych zlecenie.. Po wybraniu właściwej opcji, potwierdzeniu oświadczeń zlecenie zostało wysłane. Mijają kolejne dni, a powiadomienia o realizacji/podjęciu zlecenia nie przychodzi. Po sprawdzeniu w systemie okazało się, że zlecenie wisi. Postanowiłem ustalić co się dzieje poprzez wykorzystanie infolinii zamiast udawać się do punktu, czekać w kolejce i odejść „z niczym” – co się ostatecznie okazało. Okazało się, że lekarz właściwy do podjęcia zlecenia jest nieobecny przez określony czas. Trudno, trzeba poczekać.

Wracając jednak do infolinii, z której nie korzystałem od dawna, spotkałem się z nową dla mnie sytuacją. Generalnie bardzo rzadko mam okazję korzystać z infolinii. Ostatnie moje doświadczenia były inne, bardziej standardowe, opierające się na wybieraniu określonych numerów z klawiatury, a potem kończyło się rozmową z konsultantem. Tym razem było inaczej…

Po przywitaniu, przedstawieniu formuły o ochronie danych osobowych, identyfikacji poprzez podanie numeru klienta, padło sformułowanie: „Proszę powiedzieć czego potrzebujesz…”. I w tym momencie nastała cisza – ja nic nie mówiłem i w słuchawce była cisza. Czekałem na standardową formułkę: „Wybierz 1, aby…., wybierz 2, aby…”. Po kilkunastu sekundach usłyszałem: „Powiedz, co potrzebujesz, na przykład [i pojawia się fraza] chcę się umówić na wizytę”. I w tym momencie stało się jasne, że zmienił się model obsługi na infolinii. Podałem potrzebę i „obsługa” poszła dalej już w mniej zaskakujący sposób. Było to ciekawe doświadczenie, które próbowałem zobrazować na poniższym diagramie w BPMN, z pewnym zastrzeżeniem. Zastosowałem na nim uproszczenie dla zadania „Kontynuuj proces” (zaznaczonego linią przerywaną). Nie wskazałem konkretnych kroków, które dalej mogłyby wystąpić – można to potraktować jako podproces lub pominięcie kroków procesu podczas jego wizualizacji.

Po rozłączeniu zacząłem się zastanawiać:

• (1) na ile sekund ciszy był ustawiony system (oznaczenie zdarzenia czasowego (ang. intermediate timer event) na diagramie),
• (2) co w sytuacji, gdybym użył jakiegoś sformułowania, np. komentując do osoby obok: „chyba nie działa”,
• (3) co w sytuacji, gdybym użył słowa, na które system nie jest przygotowany,
• (4) co w sytuacji, gdybym powiedział coś za cicho/niewyraźnie lub w sposób niekompletny (np. ze względu na posiadane objawy)

System w różnych sytuacjach może mieć przygotowaną odpowiednią reakcję – prosić o powtórzenie, powiedzenie głośniej, użycie innych słów, „dopyta” lub skieruje bezpośrednio do konsultanta z odpowiednim oznaczeniem sprawy. Sytuacje (2)–(4) są wynikiem działań oznaczonych na diagramie poprzez grupę, w której znajduje się „Przeanalizuj przekaz”. Jest to pewne uproszczenie, na które sobie pozwoliłem i wykorzystałem do tego element bramki opartej o dane (ang. data based gateway). Danymi tutaj jest „treść” przekazu przełożona na odpowiednie części składowe oraz odpowiednio przeanalizowana (zainteresowanych odsyłam do publikacji na ten temat).

Przypuszczam, że takie rozwiązania nie są rzadkością. Wynikać to może z różnorodności potrzeb użytkowników. Zdarzyło mi się kilka razy, że zastanawiałem się, którą opcję wybrać spośród wskazanych i przeważnie wtedy wolałem nawiązać połączenie z konsultantem. Myślę, że pewne kwestie mogą zostać obsłużone bez udziału konsultanta – na przykład mógłbym sobie wyobrazić, że przesunięcie wizyty na pierwszy możliwy termin. W powyższym przypadku to system za użytkownika wybiera odpowiednią ścieżkę obsługi a może nawet skierować do odpowiedniego konsultanta, bazując na ustalonych regułach czy słowach kluczowych.

Gdy brak zdarzenia…

Ostatnio idąc do pracy, zauważyłem jak zmienia się cykl na skrzyżowaniu, które muszę pokonać. Samochody zaczęły zwalniać i w momencie jak dotarłem na skrzyżowanie zapaliło się im czerwone a ja nacisnąłem przycisk dla pieszych, aby wywołać zielone. Niestety zgodnie z cyklem zapaliło się światło zielone najpierw na jednej podporządkowanej, potem na drugiej. W tym momencie powinno zapalić się światło zielone dla pieszych, ale to nie nastąpiło. Przypuszczam, że za późno nacisnąłem przycisk, aby algorytm zmiany świateł to wyłapał. Może przycisk nie działał, choć to raczej nie możliwe, bo często z tego przejścia korzystam. Mogę przypuszczać, że cykl jest ustawiony jak na poniższym diagramie.

Na powyższym diagramie w BPMN wykorzystane zostały elementy:

• Zdarzenie oparte o czas (nadejście określonego momentu czy minięcie określonego czasu), co jest oznaczone przez obiekt timer event. Na diagramie są 2 takie zdarzenia: początkowe dla procesu (start timer event), oznaczone jako (A) na diagramie oraz pośrednie, występujące wewnątrz procesu (intermediate timer event), oznaczone kolejnymi literami (B, C, D, E).
• Zdarzenie informujące o otrzymaniu sygnału/komunikatu od zewnętrznego aktora (message event), tym razem zastosowane wewnątrz procesu (intermediate message event). Takim komunikatem/sygnałem jest żądanie od pieszego, który oczekuje zmiany światła z czerwonego na zielone dla przejścia dla pieszych. Ostatnio wskazywałem, że to zdarzenie może rozpocząć proces. W tym wypadku to zdarzenie wpływa na przebieg procesu, który wykonałby się i tak bez tego zdarzenia – nastąpiłaby zmiana świateł, tak, aby samochody z dróg podporządkowanych mogły przejechać przez skrzyżowanie. Różnica między obiektami jest widoczna na diagramach – jedno z nich ma pojedynczą linię (początkowe), a drugie podwójną (wewnątrz procesu).
• Bramka oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze napotkane zdarzenie inicjuje uruchomienie ścieżki/przebiegu procesu, występującego po tym zdarzeniu. Na końcu rozdzielenia też jest bramka i w zależności od jej rodzaju – wszystkie ścieżki muszą dojść do tego miejsca lub wystarczy jedna, aby proces przeszedł dalej. W powyższym przykładzie zastosowano również bramkę, która oznacza, że wystarczy tylko jedno z „wejść”, aby przejść dalej w procesie (tzw. exclusive gateway). Taka bramka znajduje się także poniżej, w celu wyboru jednej ze ścieżek, w zależności od tego, czy światło dla pieszych jest zielone czy nie. Decyzja oparta jest o zebrane dane/statusy (exclusive data-based event) a nie zdarzenia. Wcześniejsze zdarzenie (żądanie pieszego) spowodowało zmianę światła lub nie – jest to w sumie zero-jedynkowe. Takie oznaczenie można zaliczyć do danych sterujących procesem. Gdy brak takiego zdarzenia, zadania dotyczące światła dla pieszych w przebiegu procesu zostaną pominięte.
• Zadania (ang. tasks) wykonywane w procesie – zmiany świateł na czerwone, a potem na zielone dla odpowiednich sygnalizatorów oznaczonych numerami (1)-(4).
• tzw. artefakty, czyli dodatkowe elementy rozszerzające interpretację diagramu. Dodałem komentarze dotyczące przebiegu procesu, aby lepiej oznaczyć miejsca, które opisuje w punkcie dotyczącym bramek. Są to informacje dodatkowe, które nie sterują przebiegiem procesu, a pozwalają lepiej zrozumieć przedstawiony diagram.

Za pomocą wskazanych obiektów można sterować przebiegiem procesu oraz sekwencją wykonywanych zadań. W zależności od obsłużonych zdarzeń lub ich kolejności wystąpienia, proces pójdzie ścieżką „domyślną”, obsłuży wyjątek lub zastosuje zadania wynikają z alternatywnego przebiegu procesu. Powyższy proces mógłby przebiegać tak, że zawsze następuje przełączenie światła dla pieszego – z czerwonego na zielone, niezależnie od jego żądania.

Może być też tak, że w zależności od liczby żądań, czy jedno czy z dwóch stron jezdni, zmiana świateł dla samochodów następuje szybciej lub czas oznaczający, że konieczne jest przestawienie świateł się wydłuża. Pewnie istnieje też system, który dostosowuje długość cykli do ruchu lub natężenia ruchu pieszych. W niektórych miastach były testowane (a nawet chyba są wdrożone) takie mechanizmy, które badają natężenie ruchu lub mają zmienny system sygnalizacji w zależności od pory dnia.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Dzięki niej będę mógł tworzyć treści bardziej dostosowane do Waszych oczekiwań. Jeżeli pojawią się jakieś uwagi do samej ankiety lub problemy z jej wypełnieniem prośba o sygnał w komentarzu lub na adres e-mail podany po prawej stronie.