Closed Dr-Kownacki closed 4 years ago
redpfire
commented
4 years ago No dokładnie. Zgadzam się. Najlepiej jest rozwiązać problem inwigilacji za pomocą lokalnej i najlepiej zaszyfrowanej przez klucz derivowany z hasła które podaje uzytkownik bazy i tylko on ma do tego wszystkie dostep a nie rząd.
matsobdev
commented
4 years ago Tutaj chodzi o nazwę, że tak powiem nazwę - tą dostępną w ustawieniach telfonu? Przerabiałem temat dość dawno temu, 2016 zanim advertising beaconów w BLE wszedł na dobre i dość cienko to wygląda. Skanowanie źre baterię dość mocno, czasem jak telefon nie ma opcji ustawienia widoczności BT (bez limitu czasu, choć to można by podbijać co jakiś czas włączenie rozgłaszania), to programistycznie czasem nie dało się tego zrobić - zależy jak producent skroił sobie Androida. Apple - nie mam pojęcia.
potiuk
commented
4 years ago Poniżej moje spojrzenie na problem, co sądzicie ?
Ogólny komentarz. Funkcjonalność którą proponujesz @Dr-Kownacki jest dokładnie taka jaką ProteGo w połączeniu z protokołem G+A ma realizować - dodam ma to realizować bezpieczniej, sprawniej lepiej, wygodniej dla użytkownika i bardziej anonimowo. Efekt osiągany jest dokładnie taki jak proponujesz, ale wykorzystują zdobycze nauki/matematyki/inżnynierii robi to o wiele lepej. Szczegóły poniżej.
Myślę że warto chwilę poświęcić, żeby zrozumieć jakie dane są przechowywane gdzie i jak to rozwiazanie ma działać. Postarałem się to jak najbardziej przystępnie wytłumaczyć poniżej, tak żeby każdy kto nawet nie rozumie jak działa protokół G+A mógł te ogólne założenia poznać. Myślę, że sporo problemów w naszych dyskusjach wynika z różnic w zrozumieniu jak to ma działać.
Ten post jest super @Dr-Kownacki bo w kontekście tego co chciałbyś zrobić - pokazuję jak ten sam problem (lepiej) rozwiązuje protokół G+A. Może to pozwoli nam wszystkim być na tym samym poziomie zrozumienia.
Podsumuję Twoją propozycję moimi słowami tak jak ją rozumiem, żeby być pewnym że mówimy o tym samym.
Rozumiem, że w całym pomyśle zamiast instalowania aplikacji (co 90% użytkowników potrafi i już robiło) proponujesz założenie anonimowego (czyżby) maila i przekonfigurowanie nazwy telefonu (i włączenie rozgłaszania tej nazwy) żeby zawierało ten mail. Dodatkowo - i tak trzeba by oprócz tego zainstalować aplikację która pasywnie by skanowała to, co inni użytkownicy rozgłaszają.
Niestety (według mnie) takie rozwiązanie ma olbrzyme problemy (szczegóły poniżej):
Wszystki problemy są w pełni (i bardzo dobrze) rozwiązane przez protokół G+A i (mam nadzieję) przyszłą aplikację ProteGO.
Użytkownik zakłada dedykowane anonimowe konto pocztowe na dowolnej darmowej skrzynce w ale w ustalonym formacie np. protego---drkownacki@gmail.com
Od razu odpadnie bardzo dużo osób które tego nie zrobią (bo nie potrafią, bo się boją, bo nie chcą, bo nie używają maila - moja teściowa nie potrafi obsługiwać maila). Z punktu widzenia "user experience" to jest oczywisty koszmar i na wstępie myślę że 60%-70% osób nie będzie w stanie tego zrobić.
Użytkownik ustala nazwę BT swojege smartfona tożsamą do w/w. adresu mailowego i włącza rozgłaszanie tej nazwy. Czy da się skutecznie to na IOS zrobić jak na Androidzie?
Nie ma takiej potrzeby. Wszystko można rozgłaszać w "advertising info" - unikalne identyfikatory BT. Dokładnie jest to to, co robi iBeacon.
Jeżeli siła sygnału dla rozglaszanej nazwy jest "wystarczająca" (tutaj do ustalenia jaka minimalna wartość -dBm ma sens), to taka nazwa (adres email) jest zapisywana wraz datą/czasem i lokalizacją "spotkania" w LOKALNEJ (zaszyfrowanej?) bazie.
Dokładnie tak działa protoół Apple + Google, przy czym rozgłaszane i zapisywane są losowe identyfikatory (BT-ID) wygnerowane z "Daily Tracking Seed (DTS)" który jest generowany z "Private Seed (PS)". Kryptografia/Matematyka - mając tylko BT-ID, nie jesteśmy w stanie zgadnąć DTS. Mając tylko DTS nie jesteśmy w stanie zgadnąć PS. To jest bardzo inteligentny sposób zrobienia tego dobrze, prywatnie i bez możliwości oszukania. Niebezpiecznik ocenił ten algorytm na 5+. To działa tylko w jedną stronę. I to jest dużo lepsze niż konieczność wprowadzania dodatkowych, ręcznie konfigurowanych identyfikatorów takich jak email.
Interakcja pomiędzy smartfonami ma charakter czysto "PASYWNY", zapisuje się LOKALNIE w smartfonie w lokalnej bazie rekordy spotkań "z nasłuchu". Nie ma żadnej interakcji pomiędzy smartfonami, nie ma żadnego serwera, wymieniania kluczy, handshake'ow etc. - wszystko dzieje się CAŁKOWICIE PASYWNIE ( i trywialnie ). Moim zdaniem to największy atut tego rozwiązania bo działa a'la beacon... Nie wymaga Internetu nawet przez 99% czasu !
Dokładnie tak działa protokół G+A.
Aplikacja pozwala również dodatkowo na "ręczne" precyzyjne wpisanie danych spotkania, zeskanowanie się wzajemne osób na spotkaniu z "pewnym" kontaktem ew. wpisaniem czy były maski na twarzach, jaka była wielkość pomieszczenia albo czy na dworzu etc. itp. Wtedy też i "warning" dla takiego eventu będzie bardziej rozbudowany, do dyskusji. To szczególnie ważne m.in. dla personelu medycznego, już pisałem o tym w #63
Myślę że to akurat jest możliwe do realizacji. Rozwiązanie G+A daje jedynie automatyczną część do Contact Tracing, ale aplikacja może mieć więcej funkcji. Ważne żeby a) część automatyczna działała niezależnie b) żeby zachować prywatność danych w BT - najprawdopodobniej aplikacja nie będzie miała dostępu do tych danych BT bezpośrednio (zobaczymy co G+A API nam umożliwi ale tak interpretuję ich whitepaper). Więc może się nie dać tych danych skorelować (pamiętajmy że nigdy na serwer nawet osoby chore nie wysyłają historii swoich spotkań. Jedyne co jest wysyłane na serwer (jeśli ktoś jest zdiagnozowany jako chory i się na to zgodzi) to lista DTS które ta osoba miała przez ostatnie 2 tygodnie. Wszyscy inni pobierają DTS-y wszystkichchorych i sprawdzają czy się z nimi nie spotkali. Nigdzie na serwerze nie ma informacji o indywidualnych spotkaniach i nie ma absolutnie żadnych (!) informacji o ludziach zdrowych.
Użytkownik przy instalacji LOKALNIE wpisuje w aplikację swój PESEL, albo numer telefonu (sam się może ew. zaczytac z SIM/sieci?). To musi być jedna z tych dwóch informacji, poniżej wyjaśniam dlaczego, być może lepszy będzie numer telefonu, bo nie każdy ma PESEL a każdy mający smartfona ma numer telefonu. Podkreślam że to tylko lokalnie jest przechowywane.
Tak właśnie proponowałem jako najlepsze rozwiązanie w pkt 4. w #83 -> proszę przejrzeć komentarze. Pojawił się wtedy pomysł (nie mój - w dyskusji). Żeby telefon przechowywać tylko lokalnie i ewentualnie (jeśli użytkownik by się na to zgodził) byłby wysyłany do GIS w momencie w którym aplikacja stwierdzi, że jest prawdopodobieństwo zarażenia. To by ułatwiło komunikację w przypadku osób starszych które nie mają zwyczaju zaglądania do notyfikacji od aplikacji - umożliwiło by GIS-owi skontaktowanie się z taką osobą.
SANEPID/GIS/MZ mają bazę wszystkich przypadków zakażeń, a przy pobieraniu próbki zawsze jest zapisywany PESEL/numer telefonu pacjenta. Nawet jak gdzieś prywatnie/odpłatnie to badanie wykonamy to ustawowo te dane w przypadku pozytywnego wyniku MUSZĄ być przekazane do j.w. stąd te dane zawsze są zebrane.
To już się dzieje. COVID-19 podlega ustawie z 2008 dotyczacej chorób zakaźnych: http://prawo.sejm.gov.pl/isap.nsf/download.xsp/WDU20082341570/U/D20081570Lj.pdf - Art 14. pkt 6/ wyraźnie mówi o konieczności zbierania i przekazywania tych danych
Przy rejestracji pozytywnego przypadku SANEPID/GiS na podstawie PESEL/numeru telefonu generuje automatycznie jakimś algorytmem (biorąc w nim pod uwagę chwilowy czas generowania etc.itp.) unikalny klucz definiujący fakt POZYTYWNEGO wyniku i powiązanie go z PESEL/lub numerem telefonu osoby zakażonej.
Algorym A+G to właśnie robi. W momencie stwierdzenia że osoba jest zarażona, GIS daje tej osobie kod do wpisania w aplikacji i DTS tej osoby są wysyłane na serwer. Tu nawet nie trzeba numeru telefonu, czy PESEL-u - wystarczy telefon tej osoby z aplikacją i wpisanie do niego kodu wygenerowanego przez GIS. Kod może być jednorazowy, ważny tylko dla konkretnej osoby i ważny przez kilka minut więc nie sposób go będzie (bez dostępu który ma GIS) oszukać. Bardzo podobnie jak jest na przykład z kodem BLIK (swoją drogą moja firma właśnie aplikację która była pierwszą wersję BLIK-a dla PKO-BP)
Dla uproszczenia niech to będzie numer telefonu stąd bramka SMS GIS/SANEPID pod ten numer telefonu wysyła w SMS ten obliczony unikalny klucz w ustalonym formacie jako jakiś rozpoznawalny ciąg znaków np. PROTEGO-klucz--dgdegh1$&wt$&4vfea253
Nie ma takiej potrzeby - patrz dalej.
Aplikacja w smartfonie przy odebraniu takiego SMS rozpoznaje po kliknięciu w aplikacji SMS (albo nawet sama) format/link etc. i proponuje aktywację wysyłki ostrzeżenia dla osób z LOKALNEJ bazy danych, ale klucz można też wprowadzić ręcznie na wszelki wypadek.
Nie ma takiej potrzeby. Dokładnie to samo w Algorytmie G+A jest robione przez wszystkich użytkowników - ale lokalnie, na ich telefonach. Ci wszyscy użytkownicy pobierają DTS wszystkich osób chorych (potwierdzonych diagnozą i kodem z GIS) i sprawdzają czy w ICH LOKALNEJ bazie nie ma spotkań z tymi chorymi. Te dane są symetryczne - ja spotkałem ciebie = ty spotkałeś mnie. To sprawdzenie jest robione w pełni anonimowo, w pełni bezpiecznie i bez możliwości manipulacji.
Aplikacja wyśle warningi mailem do osób z LOKALNEJ bazy telefonu tylko wtedy, jeżeli "auto-odebrany"/"wpisany ręcznie" klucz zostanie prawidłowo rozszyfrowany w aplikacji że jest to klucz dopasowany dla tego konkretnego numeru telefonu (albo PESELu). W ten sposób nie można robić wygłupów/"fałszywych warningów" co więcej adresy zebrane w LOKALNEJ bazie też są zaszyfrowane i jest to utrudnienie dla ich spamowania etc.
Dokładnie to samo jest w algorytmie A+G - nie da się robić wygłupów (żeby wysłać DTS na serwer trzeba mieć kod z GIS). Nikt nie zna DTS żadnego z użytkowników. Nie jest on nigdzie publikowany do momentu w którym nie zostanie wpisany kod z GIS. Nawet jeśli będziesz skanował BT identifiers osoby którą chcesz "wrobić" nie znasz jej DTS i nie jesteś w stanie tego kodu (zmieniającego się każdego dnia) zgadnąć.
Warning w mailu przychodzi defaultowo ANONIMOWY, ale użytkownik ma możliwość deanonimizacji i podania numeru telefonu jeśli chce (mogą być różne sytuacje np."służbowe" więc i taka opcja powinna być możliwa).
Ostrzeżenia będą generowane przez aplikację - lokalnie. Nie ma potrzeby wysyłania maila, ponieważ sprawdzenie czy miało się kontakt z osobą chorą odbywa się lokalnie na telefonie. Ale właśnie w przypadku osób starszych można wprowadzić jak wyżej - lokalnie przechowany numer telefonu który w przypadku stwierdzenia prawdopodobieństwa zarażenia będzue wysłany do GIS tak, aby mogli się telefonicznie (lub fizycznie) skontaktować. Wydaje mi się że to jest super funkcjonalność.
Niezależnie jakimś teoretycznym "kanałem zwrotnym" jest adres maila z którego warning przyszedł jeżeli założymy że nie będzie on anonimowy - do dyskusji...
Tak jak pisałem - nie ma potrzeby zakładania maila (czyli posiadania dodatkowego identyfikatora). Anonimowe identyfikatory generowane przez system są wystarczające do realizacji tej funkcjonalności inaczej.
Warning ma ustalony format maila, który w łatwy sposób pozwala odróżnić go od spamu (ale i tak preferowana jest to tego oddzielna skrzynka mailowa).
To będzie notyfikacja w aplikacji (więc nie trzeba formatu/oddzielnej skrzynki). Dodatkowo może być ten kanał zwrotny za pomocą telefonu z GIS (dla osób starszych).
Warning mógłby zawierać informacje od kiedy osoba zakażona zaobserwowala u siebie objawy kliniczne co może być ważne przy szacowaniu ryzyka zarażenia.
To możliwe akurat ale na etapie diagnozy. Każdy DTS ma określoną datę i algorytmy obliczające prawdopodobieństwo zarażenia na pewno będą uwzględniać czas który upłynął między spotkaniem a diagnozą. Myślę że to będzie jeden z najważniejszych punktów gdzie algorytm będzie miał jakieś parametry (na przykład można będzie podczas diagnozy określić przez ile dni wstecz osoba była zarażająca - i zamiast wysyłać wszystkie 14 DTS dla osoby zdiagnozowanej, będą wysyłane ostatnie 4 - bo z diagnozy wyniknie że osoba potencjalnie zarażała tylko ostatnie 4 dni). Tu myślę że właśnie potrzebny będzie czynnik lekarski/ludzki. Myślę że to powinno (i może) to być robione właśnie na tym etapie - przez lekarzy a nie przez pacjenta, czy innych użytkowników. Użytkownicy nie będą w stanie sami przeanalizować jakie mają prawdopodobieństwo zarażenia jeśli dostaną takie informacje. Użytkownik powinien jedynie dostać informację "jesteś zagrożony, w ciągu ostatnich 4 dni spotkałeś się przez > 10 minut blisko z osobą chorą, która wtedy zarażała. Izoluj się i zbadaj natychmiast". Albo coś w tym stylu.
Czy aplikacja powinna sama sprawdzać ten adres/skrzynkę i "wyłapywać" te warningi to sprawa otwarta do dyskusji; skoro i tak będzie mieć funkcje "aplikacji naukowej" do nadawania to może też niech i odbiera sama...(?)
Dokładnie tak ma być (ale bez niepotrzebnego adresu) - całe sprawdzanie jest lokalnie na bazie lokalnej historii spotkań z identyfikatoram BT i bazy DTS dostarczonej z serwera. Więc nie ma potrzeby sprawdzania dodatkowo maila.
W warningu przychodzą też konkretne przydatne informacje tzn. gdzie się zgłosić, co robić, gdzie zadzwonić...
ABSOLUTNIE TAK! I dodatkowo taka informacja powinna być od razu przepustką do darmowych i szybkich (<kilka godzin) testów. To jest najważniejsza część tego systemu i za to odpowiedzialność musi wziąć rząd i służba zdrowia. Bez tego cały pomysł jest wart funta kłaków.
Zabezpieczeniem aplikacji przed wygłupami (spamowanie/strasznie "złowionych" adresów e-mail rozglaszanych w BT to etc.) mogą być dwa mechanizmy:
Ale pewnie są bardziej eleganckie sposoby :-)
W rozwiązaniu G+A zabezpieczeniem jest kod podawany osobie zdiagnozowanej przez GIS. Bez niego nie można będzie wysłać danych. To jest część specyfikacji protokołu G+A.
Do rozważenia implementacja jakiejś opcji warningu "drugiego rzędu" czyli ja dostałem warning ale nie mam jeszcze objawów/potwierdzenia/czekam na test - i taka informacja idzie do kontaktów z "mojej" bazy danych z zastrzeżeniem że to alert niższego stopnia no i po takim należałoby jakis "ciąg dalszy" napisać w zależności od sytuacji ("jestem trafiony", "nie jestem trafiony-test ujemny", "nadal czekam na kwadrannie" etc.)
Myślę że jeśli częścią rozwiązania będą szybkie testy to nie będzie to potrzebne. Osoba zarażona nie zaraża przez przynajmniej kilka dni i jeśli zostanie szybko zdiagnozowana, to jest szansa że nawet jeszcze nie zacznie zarażać, a nawet jeśli to właśnie podczas diagnozy lekarz określi przez ile ostatnich dni osoba zarażała i .... poda kod i osoba ta wyśle dane na serwer - i wtedy wszyscy którzy się z nią spotkają dostaną informację o zagrożeniu przy użyciu tego mechanizmu który już będzie. To się bardzo wszystko spina bez konieczności zarażeń 2 stopnia, ale warunkiem jest to żeby rząd zorganizował każdej osobie zagrożonej możliwość przeprowadzenia szybkich testów. Tak jak już pisałem gdzie indziej - mam nadzieję, że właśnie nad tym jak taki system zorganizować strona rządowa właśnie pracuje, bo inaczej cały pomysł można odłożyć na półkę.
Tyle mojego wkładu/pomysłów, jedynym realnym ograniczeniem/wyzwaniem jest kwestia uwierzytelniania informacji przez GIS/SANEPID/MZ i ustalenie z nimi generowania tych "kluczy uwierzytelniających". Bo tylko w ten sposób aplikacja będzie odporna na "wygłupy".
Dokładnie. Ale to można zrobić bardzo prosto - dokładnie tak jak robi BLIK. Na przykład każda osoba która jest autoryzowana do postawienia pozytywnej diagnozy ma swój numer telefonu zarejestrowany w centralnej bazie GIS. Przy postawieniu diagnozy wysyła SMS do GIS i dostaje zwrotnie unikalny, jednorazowy kod który jest ważny przez następne 10 minut i ten kod należy podać osobie zdiagnozowanej, żeby wpisała go do aplikacji w celu wysłania DTS. Ten kod od razu może zawierać informację o tym ile dni wstecz trzeba wysłać (lekarz może wysłać to w swoim SMS-ie "Chcę kod do wysłania danych chorego pacjenta dla jego ostatnich 4 dni"
Cała reszta jest przypuszczalnie dla obecnego tutaj gremium IT banalna do wykonania w ciągu pojedynczych dni i nie są potrzebne żadne Google/Apple "extrasy" do tego.
No właśnie extrasy G+A są potrzebne. Choćby po to, żeby aplikacja która skanuje BT dookoła nie była "ubita". Domyślnie takie aplikacje są bardzo szybko zabijane przez system (kwestie oszczędności baterii) i trzeba je ręcznie uruchamiać i trzymać telefon odblokowany żeby tak się nie stało. Rozwiązanie G+A dostanie specjalną "whitelistę" - i nie bedzie takiej potrzeby.
Moim zdaniem przedstawione przeze mnie rozwiązanie ma dużą szansę się sprawdzić w praktyce i być odpornym na ataki a jednocześnie zachować info i prywatność użytkowników (lokalna baza spotkań w smartfonie, anonimowa skrzynka mailowa).
Niestety to rozwiązanie ma sporo wad. Od "User Experience" począwszy, przez, niestety olbrzymie problemy z prywatnością. "Anonimowe maile" które nie zmieniają się w czasie wcale nie są anonimowe - problem polega na tym że wystarczy raz stanąć koło jakieś osoby tak żeby być koło takiej osoby w zasadzie samemu i natychmiast wiadomo jaki ma identyfikator. Koniec anonimowości. To zostało bardzo dobrze opisane w wątku "Single Encounter" na DP-3T https://github.com/DP-3T/documents/issues/13. Jak już tylko masz taki identyfikator i jego połączenie z osobą, możesz bardzo dokładnie śledzić tą osobę cały czas. Zero prywatności. Dokładnie tak samo by było, gdybyśmy używali statycznych identyfikatorów nie zmieniających się w czasie. Rozwiązanie G+A gdzie są 3 poziomy identyfikatorów zapewnia faktyczną anonimowość. Jeszcze raz to spróbuję opisać:
1) Najbardziej prywatny Private Seed (PS)- wygenerowany raz, lokalnie. Nigdy nie opuszcza telefonu, przechowywany lokalnie, nie sposób go zgadnąć z nawet wielu Daily Tracking Seed.
2) Dally Tracking Seed - nieco mniej prywatny generowany (pseudolosowo) z PS (w jedną stronę) - nie jest rozgłaszany przez BT, jest tylko wysyłany na serwer w przypadku potwierdzonej diagnozy - tylko jeśli jest wpisany odpowiedni kod dostarczony przez GIS
3) BT id -> Bluetooth Tracking ID - > zmieniający się co 15 minut identyfikator, który jest generowany (pseudolosowo) z Daily Tracking Seed. Te indentyfiokatory są publicznie rozgłaszane ale zmieniają sie (z punktu widzienia osób z zewnątrz) kompletnie losowo i nie sposób stwierdzić że takie identyfikatory należą do tej samej osoby bez znajomości Daily Tracking Seed (dotyczy to kodów z tego samego dnia) a nawet Private Seed (dotyczy to kodów z różnych dni).
Zamiast "centralnego serwera rządowego" którego wiele osób się obawia, mamy prosty mechanizm oparty o anonimowe dedykowane prywatne skrzynki mailowe w dowolnych lokalizacjach.
No nie do końca, bo w jakiś sposób trzeba by te informacje autoryzować. Email jest beznadziejny jeśli chodzi o potwierdzenie że dostaliśmy to od konkretnej osoby. Ja w tej chwili (i każda inna osoba) mógłbym - znając email (dajmy na to) Dra Kownackiego wysłać email jako "Dr Kownacki" i większość ludzi by się nie zorientowała że nie jestem Drem Kownackim. Jedynie ci u których dostawcy mailowi zaimplementowali dodatkowe sprawdzenia a serwer mailowy Dra Kownackiego byłby dobrze skonfigurowane dostali by ostrzeżenie ("ten email jest jakiś dziwny") albo email wylądowałby w śmietniku automatycznie. W ten sposób bardzo łatwo było by sfałszować informacje o zarażeniu. Byłby to totalnie, nieogarnialny i nierozwiązywalny problem.
Aplikacja w żadnym momencie nie łączy się z serwerem "rządowym" i nie wymiana absolutnie żadnych danych, jest jedynie pasywnym "biorcą klucza" przez SMS - a i to tylko i wyłącznie w przypadku konieczności rozesłania warningu.
Jestem ciekaw komentarzy zawodowców - bo prawda jest taka że czas niestety ucieka i (jak ja to rozumiem) czeka się obecnie na ruch Apple/Google. W warstwie ogólnej powyższy pomysł z tym "nadchodzącym" rozwiązaniem też mógłby działać, chociaż wcale go nie potrzebuje moim skromnym (zastrzegam że jedynie "lekarskim" ) zdaniem.
Pozdrawiam.
Dr-Kownacki
commented
4 years ago @potiuk dzięki za bardzo dogłębne wyjaśnienia i oczywiście przyjmuję to za dogmat bez dyskusji i jasna sprawa, czapki z głów za super jasne wytłumaczenie :-)
Ale jeżeli chodzi o identyfikator BT to nawet jeżeli on będzie zmienny/szyfrowany etc. to czy jesteś pewien że MAC adress BT będzie się też losowo zmieniał ? Bo przecież analiza ruchu BT (są do tego "zabawki" na Allegro za ok 400pln :-) ), i tak przecież zobaczy chyba te MAC adresy, bo one chyba muszą się "jakoś" roglaszac więc i (stały) MAC tam jest (?)
Jeżeli tak jest, to nie ma chyba zatem różnicy czy pasywnie rozglosze "swój" identyfikator "a'la email" bo zarówno nim jak i MAC BT(BLE) możnaby kogoś śledzić potencjalnie jako po stałej wartości.
Natomiast jeżeli MAC będzie z przyczyn bezpieczeństwa np. cały czas "fejkowany" dynamicznie, to przecież "rozparuje" nam to wszelkie akcesoria BT i uniemożliwi korzystanie z czegokolwiek innego niż tracing (???)
Czy może zatem okazać się że będzie niezbędny drugi moduł BLE w komórce do "normalnych" rzeczy ?
Czy stanie się to niedługo po prostu standardem sprzętowym ? (dwa moduły w telefonie?)
Czy będziemy do tego czasu ew. dokupować mikro-moduly BLE (przelotowe jakieś) i wpinać je w złącza komórek żeby mieć "normalny Bluetooth" ?
Ja oczywiście rozumiem że to Apple/Google rozwiązanie jest bardzo wysublimowane, ale czy ten cały ruch na BT/wymiany kluczy/ "parowania" nie spowoduje również wykończenia baterii i to jeszcze szybciej niż "w moim-nasluchowym-pasywnym" prostym pomyśle ?
Dodatkowo jeżeli jedna strona takiego "handshake'u" będzie miała jakikolwiek chwilowy problem techniczny to przy takim rozwiązaniu fail jest na 100% a przy pasywnym tylko 50% bo przynajmniej jedna osoba coś zapisze...
Kolejna kwestia jest taka że to "permanentne mielenie kryptograficzne" i bilateralna łączność przecież wpłynie ogólnie na wszystkie akcesoria BT telefonu nawet jakby pakiety/protokoky/usługi były jakoś sprytnie odizolowane.
Mam dziwne wrażenie/przeczucie że to może i będzie super działać ale na "oryginalnych" siłą rzeczy iPhonach i "oryginalnych" zabawkach od Google... Kolejny skok na kasę ? :-)
Po prostu trudno uwierzyć że tak wysublimowana rzecz mocno warunkowana jednak sprzętowo będzie wiarygodnie działać na każdym chińskim smartfonie z marketu...
Na koniec refleksja - a kiedy i jak te miliony androidowych telefonów mają dostać te nowe API-cudenka. Wiadomo jak jest że wsparciem aktualizacji Androida i jak wiele jest "starych" ciągle w użyciu takich telefonów.
Mój wniosek finalny: Apple bierze wszystko ! 🤑
Będzie to zatem jedyny system/telefon "chroniący przed zarazą" z uwagi na ciągle wsparcie, po prostu z uwagi na aktualizacje, łatki etc.
Stąd przy tych wszystkich zastrzeżeniach to co zaproponowałem działać mogłoby teoretycznie "tu i teraz u wszystkich" . Jeśli chodzi o sprawdzenie czy warning jest real czy fejk w moim mailu to jak pisałem sprawę rozwiazywalby klucz na serwerze (porównanie klucza otrzymanego w warningu z kluczem w GIS) czyli obok 12 A) też 12 B).
Popieram w 200% oczywiście podejście z API (google/Apple) ale przyznacie że realnie go przecież nie ma fizycznie, a zatem:
a) czy jest gwarantowany termin kiedy to będzie dostępne ? Połowa maja ? Na pewno?
b) nie ma gwarancji że to będzie dobrze działać od samego początku, wiadomo ile jest zmiennych w sprawie...
c) jaki jest model przewidywań na REALNE upowszechnianie tego globalnie ? Pół roku ? Rok ?
d) nawet jeżeli będzie w połowie maja dostępne i polska aplikacja ruszy na koniec maja, to pomyślmy ile przez tą "zwłokę" (sic!) w międzyczasie pojawi się nowych zakażeń (i zgonów) w Polsce
Na ile byłem w stanie po amatorsku przedstawić pomysł, który oczywiście ma wady, to opisałem.
Kierowałem się trochę opinia głównego eksperta WHO od epidemii/pandemii na świecie /pogromcy EBOLi etc./ który napisał że "Aby wygrać z epidemią o wiele ważniejsza od perfekcji jest szybkość działania - tylko to daje skuteczność". Perfekcjonizm jest największym wrogiem. To mnie natchnęło żeby opisać Wam ten mój prosty pomysł.
Bardzo ważne jest to co @potiuk napisałeś też super - zgranie aplikacji z dostępnością do testów ( tutaj wspomniałem też #101 ) oraz implementacja "interakcji lekarza" w cały proces.
potiuk
commented
4 years ago @potiuk dzięki za bardzo dogłębne wyjaśnienia i oczywiście przyjmuję to za dogmat bez dyskusji i jasna sprawa, czapki z głów za super jasne wytłumaczenie :-)
Zauważyłem że sporo założeń które ludzie przyjmują jeśli chodzi o technologię w tym przypadu, są błędne - wynikają one albo z niewiedzy, albo z przestarzałej wiedzy, albo często z takich "urban legends" które krążą tu i ówdzie. Dlatego w mojej informacji poniżej postaram się trochę to wszystko wyjaśnić, bo zauważyłem, że jest to potrzebne. Wszędzie gdzie tylko to możliwe postarałem się dać wyjaśnienie i przy okazji od razu wiarygodne źródła, żeby trochę sprawy wyjaśnić.
Postarałem się też zrobić trochę obliczeń po inżyniersku (po angielsku nazywa się to "back of the envelope calculations") żeby pokazać, że współczesne telefony bez problemu "udźwigną" to zadania.
Ale jeżeli chodzi o identyfikator BT to nawet jeżeli on będzie zmienny/szyfrowany etc. to czy jesteś pewien że MAC adress BT będzie się też losowo zmieniał ? Bo przecież analiza ruchu BT (są do tego "zabawki" na Allegro za ok 400pln :-) ), i tak przecież zobaczy chyba te MAC adresy, bo one chuba muszą się "jakoś" roglaszac więc i (stały) MAC tam jest (?)
Tak było kiedyś ale już od dawnia nie jest. Więcej o tym tu: (https://www.bluetooth.com/blog/bluetooth-technology-protecting-your-privacy/ - specyfikacja Bluetooth) ale najfajniej to jest wytłumaczone tu: https://security.stackexchange.com/questions/200474/mac-randomization-for-bluetooth
Wszystkie telefony Apple i większość telefonów Google już od dawna ma zaimplementowaną randomizację rozgłaszanych MAC-ów. Nawet w przyadku telefonów które nie mają randomizacji na poziomie OS, to rozwiązanie będzie open-source i można będzie sprawdzić, że numer MAC nie będzie przechowywany po odczytaniu "rozgłaszanych" ramek i że przechowywany będzie jedynie BT-ID. Gdyby te MAC'i nie były randomizowane, to już dziś w każdym supermarkecie dostawałbyś natychmiast SMS-y na temat sklepów koło Ciebie. Były takie projekty ale po tym jak uwaga (!) Google i Apple wprowadziły randomizację w swoich systemach - natychmiast padły.
Jeżeli tak jest, to nie ma chyba zatem różnicy czy pasywnie rozglosze "swój" identyfikator a'la email bo zarówno nim jak i MAC BT(BLE) możnaby kogoś śledzić potencjalnie jako po stałej wartości.
No właśnie tak nie jest - patrz wyżej ^^
Natomiast jeżeli MAC będzie z przyczyn bezpieczeństwa np. cały czas "fejkowany" dynamicznie, to przecież "rozpatruje" nam to wszelkie akcesoria BT i uniemożliwi korzystanie z czegokolwiek innego niż tracing (???)
No włąśnie w przypadku "advertising info" randomizacja adresu MAC w niczym nie przeszkadza i już dawno została zaimplementowana - patrz wyżej. A urządzenia o których mówimy "parują" się używając zupełnie innych mechanizmów BLE. Jedno z drugim nie ma wiele wspólnego.
Czy może zatem okazać się że będzie niezbędny drugi moduł BLE w komórce do "normalnych" rzeczy ?
Nie. Patrz wyżej ^^
Czy stanie się to niedługo po prostu standardem sprzętowym ? (dwa moduły w telefonie?) Nie musi. Standardem już od dawna jest randomizacja. Patrz wyżej ^^
Czy będziemy do tego czasu ew. dokupować mikro-moduky BLE (przelotowe jakieś) i wpinać je w złącza komórek żeby mieć "normalny Bluetooth" ?
Nie ma takiej potrzeby. Patrz wyżej ^^
Ja oczywiście rozumiem że to Apple/Google rozwiązanie jest bardzo wysublimowane, ale czy ten cały ruch na BT/wymiany kluczy/ "parowania" nie spowoduje również wykończenia baterii i to jeszcze szybciej niż "w moim-nasluchowym-pasywnym" prostym pomyśle ?
Jeszcze raz powtórzę. NIE MA parowania ani wymiany kluczy. Cały protokół opiera się na dokładnie tym samym co Beacony - Advertising Info. Nie ma żadnego parowania i wymiany kluczy. Protokół A+G jest właśnie takim pasywnym beaconem tylko ze sprytnie wymyślonymi i rotującymi informacjami. Z resztą - to nie jest żadna nowość. Te idee już dawno były stosowane w różnych rozwiązaniach Beaconowych - na przykład w naszym rodzimym polskim Estimote z którym się dobrze znamy (https://community.estimote.com/hc/en-us/articles/201371053-How-does-Secure-UUID-work-). To nie jest "rocket science".. Naprawdę to nie jest jakiś "crazy math" tylko standardowy sposób działający od wielu lat. Tutaj jeszcze wątek z 2016 (!!!!!) w którym szczegóły rotujących ID są dyskutowane https://forums.estimote.com/t/secure-uuid-i-dont-understand-how-it-works/3769
Dodatkowo jeżeli jedna strona takiego "handshake'u" będzie miała jakikolwiek chwilowy problem techniczny to przy takim rozwiązaniu fail jest na 100% a przy pasywnym tylko 50% bo przynajmniej jedna osoba coś zapisze...
No właśnie to jest właśnie pasywne rozwiązanie. Powtórzę jeszcze raz. Do rozgłaszania nazwy telefonu i do rozgłaszania BT ID w protokole G+A używany jest dokładnie ten sam mechanizm. Różnica jest taka że co 15 minut aplikacja w tle zmienia BT-ID na inny losowy. Tak jakbyś ręcznie zmienił nazwę swojego telefonu. Tylko numerki są unikalne i zmieniają się same.
Kolejna kwestia jest taka że to "permanentne mielenie kryptograficzne" i bilateralna łączność przecież wpłynie ogólnie na wszystkie akcesoria BT telefonu nawet jakby pakiety/protokoky/usługi były jakoś sprytnie odizolowane.
Nie ma permanentego mielenia "kryptograficznego". Dokładnie raz dziennie generowane są lokalnie 244 = 96 ID do rozgłaszania przez cały dzień. I potem z tej puli losowo (żeby utrudnić zgadnięcie DTS na podstawie kolejności ID) co 15 minut ustawiany jest jeden z identyfikatorów. Wszystkie "skanowane" identyfikatory są po prostu zapisane lokalnie jako "widoczne" razem z siłą sygnału. Jeśli chodzi o sprawdzenie czy jestem zagrożony to zakładam też że będzie to robione raz dziennie (ale to kwestia decyzji twórców aplikacji) pobierane będą DTS osób które zostały w ciągu ostatnich 2 tygodni zdiagnozowane jako chore. W Polsce może być pewnie maksymalnie kilka tysięcy osób w ciagu 14 dni. Zakładam że 10.000, więc do pobrania jest 70.000 identyfikatorów - zakładając statystycznie 7 dni każdej osoby. To można zoptymalizować i pobierać inkrementalnie - zakładam że sprawdzać będziemy tylko nowo pobrane identyfkatory - czyli pewnie 5.000 dziennie (statystyka). Dla tych 5.000 identyfikatorów trzeba wygenerować 5.000 96 ~ 500.000 identyfikatorów do porównania z lokalnie zapisanymi spotkaniami. Przy optymalizacji tego typu algorytmów - to na moje oko jakieś kilka - kilkanaście minut pracy procesora. Raz dziennie. I może być robione wtedy kiedy telefon się ładuje albo kiedy śpimy (już teraz obecne telefony mają do tego gotowe mechanizmy - żeby uruchamiać pewne zadania wtedy kiedy telefon jest nieaktywny albo kiedy się ładuje). Pewnie całe to advertising + skanowanie skróci trochę czas na bateriach ale według mojej intuicji (nie mam gotowych danych) to nie będzie więcej niż 5, maksymalnie 10 %. Przy dobrej optymalizacji kodu - dużo, dużo mniej.
Mam dziwne wrażenie/przeczucie że to może i będzie super działać ale na "orginalnych" siłą rzeczy iPhonach i "oryginalnych" zabawkach od Google... Kolejny skok na kasę ? :-)
Niekoniecznie. U Apple - wiadomo - nie ma nie oryginalnych. Jeśli chodzi o Android - większość telefonów Android ma wbudowany sklep PlayStore i tego rodzaju API Google może dystrybuować (i już to robi) niezależnie od producenta telefonu. Nazywa się to "Google Play Services" i opis można znaleźć tu:
https://developers.google.com/android/guides/overview
Zacytuję: "With Google Play services, your app can take advantage of the latest, Google-powered features such as Maps, Google+, and more, with automatic platform updates distributed as an APK through the Google Play store. This makes it faster for your users to receive updates and easier for you to integrate the newest that Google has to offer."
I jeszcze to: " The benefits for your app Google Play services gives you the freedom to use the newest APIs for popular Google services without worrying about device support. Updates to Google Play services are distributed automatically by the Google Play Store. "
Funkcjonalność BT działa oczywiście odrobinę inaczej na różnych telefonach, ale zakładam że Google nie będzie tego wykorzystywał. Poza tym telefonów oryginalnych od Google jest śladowa ilość na rynku (tu ich nie ma w zestawieniu bo telefony Google robiło albo HTC albo LG albo Foxconn https://www.lifewire.com/google-pixel-phones-4152056 (a według https://www.appbrain.com/stats/top-manufacturers w sumie ZTE + LG mają 3% rynku jako producenci, Foxconna nawet tam nie ma). Cały pomysł opiera się na założeniu że będzie to rozwiązanie powszechne (niektórzy mówią >60%). Czy jest możliwe żeby Google chciało by i było w stanie zdobyć w kilka miesięcy udziału 60% w rynku telenów rozwijającym się od 15 lat w momencie w którym zakupy nowych telefonów spadły o > 50% z powodu niepewności związanej z koronawirusem ? Odpowiedź pozostawiam słuchaczom :).
Po prostu trudno uwierzyć że tak wysublimowana rzecz mocno warunkowana jednak sprzętowo będzie wiarygodnie działać na każdym chińskim smartfonie z marketu...
Na każdym pewnie nie, ale na > 90% na pewno. Nie musimy osiągnąć 100%. Jak czytałem - nasycenie >60% wystarczy, żeby aplikacja spełniała dobrze swoją rolę (przypomnę - chodzi o zbicie współczynnika zarażalności R0 do < 1. Nie do 0 (!). Do < 1 - czyli żeby jedna zarażona osoba zarażała statystycznie mniej niż jedną osobę. To wystarczy.
Aplikacje mobilne robię od > 12 la w sumie - trochę widziałem. BLE https://en.wikipedia.org/wiki/Bluetooth_Low_Energy powstał w 2011 i wtedy wszedł na rynek pierwszy telefon z BLE (iPhone 4S), wprowadzono powszechnie jakieś 4-5 lat temu (my zaczęliśmy się BLE zajmować jeszcze wcześniej), i od tego czasu stał się absolutnym standardem. Telefony wymienia(ło) się statystycznie co 2-3 lata - więc w zasadzie każdy ma telefon z BLE. Oficjalny raport Bluetooth.com https://www.bluetooth.com/wp-content/uploads/2018/04/2019-Bluetooth-Market-Update.pdf (na bazie danych z 2018) mówi że 100% (!) smartfonów, tabletów i laptopów ma Blietooth. Co prawda nie wszystkie mają BLE ale już od paru lat na rynku nie można dostać "chipsetów" które wspierały by tylko stary, tradycyjny Bluetooth 2.0. Telefony Androida wspierają BLE od wersji 4.3 (2012). Co prawda Google ostatnio przestało publikować dane na temat udziału różnych wersji Androida w rynku, ale np. tu https://www.appbrain.com/stats/top-android-sdk-versions widać że BLE jest wspierany na ponad 98% urządzeń.
Jeśli chodzi o procesor etc - to właśnie przy odpowiedniej optymalizacji algorytmów można to zrobić nawet na bardzo starych telefonach. Dzisiejsze telefony są naprawdę bardzo potężnymi komputerami. Zacytuję tu tytuł artykuły "Your smartphone is milions of times more powerful than the Apollo 11 guidance computers": https://www.zmescience.com/science/news-science/smartphone-power-compared-to-apollo-432/ . Polecam lekturę - fascynujące!
Na koniec refleksja - a kiedy i jak te miliony androidowych telefonów mają dostać te nowe API-cudenka. Wiadomo jak jest że wsparciem aktualizacji Androida i jak wiele jest "starych" ciągle w użyciu takich telefonów.
Tak jak pisałem wyżej - od kilku już lat Google ma wbudowany mechanizm w "Play Store" dzięki któremu już od dawna dystrybuje podobne API bez udziału producentów i bardzo szybko. Problemem może być Huawei w którego przypadku Google (ze względu na wojnę handlową USA-China) zabronił używać swoich aplkacji ale dotyczy to stosunkowo świeżych telefonów (kilka miesięcy) i pewnie to < 0.5% użytkowników, ale w środowisku krążą plotki że w tym wypadku Google i Huawei się dogadają żeby zrobić wyjątek.
Mój wniosek finalny: Apple bierze wszystko ! Będzie to zatem jedny system/telefon "chroniący przed zarazą" z uwagi na ciągle wsparcie, po prostu z uwagi na aktualizacje, łatki etc.
Pozwolę się nie zgodzić. Myślę że wynika to w dużej mierze z nieco już nieaktualne wiedzy na temat tego jak wygląda rynek i dystrybucja telefonw. Proszę przeczytać co napisałem powyżej, mam nadzieję, że zmieni pan na ten temat zdanie.
Stąd przy tych wszystkich zastrzeżeniach to co zaproponowałem działać mogłoby teoretycznie "tu i teraz u wszystkich" .
Pomijając problemy które opisałem dokładnie w poprzednim wpisie, w pana rozwiązaniu istnieje dokładnie ten sam komponent skanujący, przechowujący i wysyłający informacje - i musi być zainstalowany jako aplikacja (nie da się tego zrobić inaczej). Ten komponent ma potencjalnie dokładnie te same problemy które wskazał Pan powyżej (a które według mnie nie są problemami dyskfalifikujacymi). Pana rozwiązanie będzie działało na dokładnie tych samych urządzeniach na których rozwiązanie G+A. Nie ma tam nic co by sprawiało że będzie działało na "większej liczbie urządzeń".
Jeśli chodzi o sprawdzenie czy warning jest real czy fejk w moim mailu to jak pisałem sprawę rowiazywalby klucz na serwerze (porównanie klucza otrzymanego w warningu z kluczem w GIS) czyli obok 12 A) też 12 B).
Znaczy jak - z maila? Konkretnie kto i kiedy jakie klucze będzie porównywał? Użytkownik? Aplikacja? Po co mail w tym rozwiązaniu ? Albo ja czegoś nie rozumiem, albo Pan.
Popieram w 200% oczywiście podejście z API (google/Apple) ale przyznacie że realnie go przecież nie ma fizycznie, a zatem:
a) czy jest gwarantowany termin kiedy to będzie dostępne ? Połowa maja ? Na pewno?
Dajmy im szansę. Z tego co rozumiem zespół protego testuje używając swojego rozwiązania zanim pojawi się G+A a potem się przełączy zanim aplikacja będzie opublikowana. Jeśli API się nie pojawi, wtedy można się zastanawiać co dalej.
b) nie ma gwarancji że to będzie dobrze działać od samego początku, wiadomo ile jest zmiennych w sprawie...
Tak jak w każdym innym rozwiązaniu - również w Pańskiej propozycji. Niezależnie przez kogo robionym. Ja szczerze mówiąc wierzę że Google i Apple ma ludzi (paru z nich znam i są moimi przyjaciólmi )którzy stworzyli swoje systemy operacyjne dla smartfonów. I Ci ludzie zrobią wszystko żeby to działało dobrze, prawdopodobnie lepiej niż ktokolwiej inny. Nie wierzę żeby nasz rząd był w stanie znależć i opłacić 100.000 ludzi żeby testowali aplikację. A jak pisałem w innych wątkach - Google i Apple mają zasoby i możliwości żeby to zrobić - używając takich firm jak Applause (znam tą firmę - kiedyś współtworzyliśmy jej oddział w Polsce i sprzedaliśmy im oprogramowanie służące do właśnie tego - wspomaganiu testowania aplikacji mobiilnych przez rozproszonych użytkowników). Firmę która ma kilkaset tysięcy ludzi na całym świecie ze wszystkimi modelami telefonów i mogą taką aplikację poważnie przetestować (wiem że Applause i Google współpracują przy wielu projektach Google). Wydaje mi się że kto jak nie oni. Ale może się mylę. Może w tydzień można faktycznie napisać i przetestować pańską aplikację i ona będzie działała bezbłędnie. Choć moje doświadczenie mi podpowiada, że nie.
c) jaki jest model przewidywań na REALNE upowszechnianie tego globalnie ? Pół roku ? Rok ?
Myślę że o wiele większe niż w każdej aplikacji zrobionej lokalnie. Z tego co Google + Apple ogłaszało planują (po tym jak rządy zbudują swoje aplikacje i opublikują je) planują oni wprowadzić notyfikacje o tym że aplikację można zainstalować (dla każdego kraju oddzielnie) tak że każda osoba używająca smartfona będzie do tego (łagodnie) namawiana. Bardzo podobnie jak obecnie Facebook pokazuje notyikację namawiającą do subskrypcji do oficjalnych (innych w każdym kraju) informacji publikowanych przez rząd o Coronavirusie. Dodając do tego kampanie reklamowe które (mam nadzieję) nasz rząd planuje wprowadzić w mediach (tradycyjnych i społecznościowych) i zakładając, że uda się przekonać ludzi że jest to rozwiązanie potrzebne, bezpieczne i prywatne (o to będzie akurat najtrudniej) - myślę że dało by się sensowne upowszechnienie (np. w Polsce) w kilka miesięcy (ale to oczywiście czysta spekulacja). Gra Angry Birds (https://en.wikipedia.org/wiki/Angry_Birds) była po 5 latach od premiery zainstalowana DWA MILIARDY(!) razy, po 6 latach 3 MILIARDY. To znaczy że w ciągu roku zainstalowało ją MILIARD osób. A chodziło o strzelanie ptakami a nie o wychodzenie z izolacji. Pozostawiam to do myślenia.
d) nawet jeżeli będzie w połowie maja dostępne i polska aplikacja ruszy na koniec maja, to pomyślmy ile przez tą "zwłokę" (sic!) w międzyczasie pojawi się nowych zakażeń (i zgonów) w Polsce
Dokładnie 0 (Mogę tą liczbę określić bardzo precyzyjnie). Nie ma najmniejszych szans (ani nawet potrzeb ani możliwości) żeby contact tracing wprowadzać teraz. Ta aplikacja będzie potrzebna (pisałem o tym wielokrotnie) jak będziemy wychodzić z izolacji. Nie jak w niej jesteśmy. W tej chwili jej użyteczność jest żadna bo w izolacji jesteśmy. Obligatoryjnie. Wszyscy. Aplikacja ProteGo z Contact Tracing będzie potrzebna wtedy kiedy będziemy chcieli wrócić do normalnego życia, kiedy liczba zarażonych - dzięki izolacji - znacząco spadnie. I będzie można wrócić do "w miarę" normalnego życia. Realnie rzecz biorąc - lipiec/sierpień najwcześniej (ale to akurat są moje spekulacje). Na pewno nie w maju. Dzisiejsze dane wskazują, że do szczytu zachorowań jeszcze daleko (340 przypadków tylko rano)
Na ile byłem w stanie po amatorsku przestawić pomysł który oczywiście ma wady to opisałem.
Nie neguję. To bardzo dobrze że komuś się chce myśleć i przedstawiać swoje pomysły. Chciałem tylko zwrócić uwagę na bardzo duże luki w tym pomyśle. Przede wszystkim prywatność, ale też stopień skomplikowania (wbrew pozorom to rozwiązanie od Pana jest szalenie trudne do wdrożenia i wymaga od przeciętnego użytkownika wiedzy i działań które ich przerosną). Dało mi to też szansę jasnego opisania dlaczego według mnie takie "proste" rozwiązanie nie spełnia swojej roli.
Kierowałem się trochę opinia głównego eksperta WHO od epidemii/pandemii na świecie /pogromcy EBOLi etc./ który napisał że "Aby wygrać z epidemią o wiele ważniejsza od perfekcji jest szybkość działania - tylko to daje skuteczność". Perfekcjonizm jest największym wrogiem. To mnie natchnęło żeby opisać Wam ten mój prosty pomysł.
Bardzo dobrze, próbujmy! Tak jak napisałem powyżej - w tej chwili contact tracing jest niepotrzebny. Będziemy go potrzebować za kilka miesięcy. Zróbmy to dobrze jeśli możemy. Pańskie "szybkie" rozwiązanie wcale nie jest szybkie. Niestety nie ma pan doświadczenia w tworzeniu aplikacji mobilnych. Z mojego skromnego doświadczenia - paradoksalnie dużo łatwiej jest zaimplementować protokół G+A niż integrować się z dowolną liczbą skrzynek mailowych tak. żeby to było bezpiecznie (klucze i podpisywanie przez maila do dziś nie jest zrobione dobrze - ten protokół się do tego słabo nadaje). W naszej branży istnieje takie powiedzenie "Standing on the shoulder of Giants". Nawet całkiem niedawno napisałem o tym artykuł na blogu mojej firmy https://www.polidea.com/blog/the-evolution-of-open-source-standing-on-the-shoulders-of-giants/. Czasem o wiele szybciej i lepiej jest wziąć dobre i sprawdzone i przetestowane przez innych rozwiązanie (zwłaszcza jeśli znają się na rzeczy) niż myśleć, że my to możemy zrobić lepiej. W tym wypadku to nawet nie jest przypuszczenie - mam pewność że nie zrobimy tego lepiej.
Bardzo ważne jest to co @potiuk napisałeś też super - zgranie aplikacji z dostępnością do testów ( tutaj wspomniałem też #101 ) oraz implementacja "interakcji lekarza" w cały proces.
Absolutnie. I mam nadzieję że o tym właśnie @MateuszRomanow rozmawia teraz z Ministertwem Cyfryzacji ale też Ministerstwem Zdrowia, GIS i innymi. Bo według mnie będziemy mieli dobre rozwiązanie strony aplikacja + bluetooth ale żeby to zadziałało musi być prężnie działający system testów i reakcji dla osób zagrożonych, ale też zbudowana kampania medialna, kampania promująca bezpieczeństwo i prywatność, niezależne audyty ale też pewnie kampanie społecznościowe angażujące NGO i (uwaga) pewnie wszystkie siły polityczne - nie tylko rządowe - żeby przekonać wszystkich że jest to dobre, prywatne i potrzebne rozwiązanie - i że da się zbudować zaufanie społeczne do tego.
Myślę że to jest najważniejszy element całej układanki. Dobrze że rząd nie musi się już zajmować tworzeniem protokołów. Według mnie element poza-techniczny jest w tym projekcie najtrudniejszy i mam nadzieję że nasz rząd się w tym zadaniu sprawdzi.
J
Dr-Kownacki
commented
4 years ago Dzięki za tą skarbnicę wiedzy, na pewno będę się przez nią długo jeszcze przedzierał @potiuk
Na szybko tylko o kluczu weryfikacyjnym "z maila": @@@ Jeśli chodzi o sprawdzenie czy warning jest real czy fejk w moim mailu to jak pisałem sprawę rowiazywalby klucz na serwerze (porównanie klucza otrzymanego w warningu z kluczem w GIS) czyli obok 12 A) też 12 B).
Znaczy jak - z maila? Konkretnie kto i kiedy jakie klucze będzie porównywał? Użytkownik? Aplikacja? Po co mail w tym rozwiązaniu ? Albo ja czegoś nie rozumiem, albo Pan. @@@
Spróbuję ponownie wytłumaczyć, mail dlatego że "oparłem na mailach" ten pomysł i appka jest de facto jakimś trochę "klientem pocztowym":
Założenie ogólnie takie że czy to "true" czy "fejk" warning" może być dwustopniowo zweryfikowane: a) dostajesz maila i np. sprawdzasz (aplikacja sprawdza) czy "autorem" maila jest ktoś z listy "spotkań" zapisanych w bazie lokalnej na komórce
b) W treści maila jest literalnie i "wprost" wpisany klucz, którym aplikacja która to do Ciebie przesłała "autoryzowała" rozsyłanie tego warninga. Bo inaczej Twój warning nie miałby jak powstać przecież.
Stąd lokalnie aplikacja (sama albo ręcznie kliknieta, albo wręcz użytkownik klika w link w formacie wytworzony w formacie "https://ProteGo.gov.pl/klucz.htm" ) odszukuje ciąg znaków (klucz) w tym mailu. Jeżeli taki klucz został użyty przez GIS (bo został wygenerowany dla zakażonego to jest on opublikowany (ale w sposób niejawny, nie ma jawnej listy, musisz go "trafić") stąd ta weryfikacja przechodzi pozytywnie to jest wiadomo że to nie fejk - w przeciwnym razie - fejk bo nie ma tego klucza.
Wszystko co nie pasuje do ustalonego formatu teksu (a może nawet tylko tytułu) maila jest ignorowane i nawet jak ta nasza anonimowa skrzynka zapełnia się spamem/fejkami to jest to wszystko ignorowane i kasowane i nawet możemy nie mieć z tym żadnej styczności, bo apka to załatwia automatycznie za nas.
Jako jak podkreślam) - "tylko amator" jedynie taki szybki sposób weryfikacji true/false wymyśliłem przy kierunku "jednostronnym" pracy aplikacji (czyli ktoś niezakażony jest tylko "biorcą" danych).
@@@ Nie ma najmniejszych szans (ani nawet potrzeb ani możliwości) żeby contact tracing wprowadzać teraz. Ta aplikacja będzie potrzebna (pisałem o tym wielokrotnie) jak będziemy wychodzić z izolacji. Nie jak w niej jesteśmy. @@@
Tutaj niestety zupełnie nie mogę się zgodzić, nie jesteśmy w izolacji, a już na pewno ja nie jestem. Liczba zakażeń/zgonów wzrasta. Taka aplikacja (tracing) w moim przekonaniu jest potrzebna "od zaraz/na wczoraj" a już w szczególności dla służby zdrowia bo robi się coraz mniej ciekawie: https://wiadomosci.onet.pl/kraj/koronawirus-rekordowy-dzien-pod-wzgledem-zakazen-w-polsce-relacja-na-zywo/tmnrckg
Reasumując: a) mieliśmy mieć jakieś rozwiązanie (choćby i beta) przed Wialkanocą. Wiele osób na to czekało, choćby aby "spróbować". Zakładałem że u mnie w szpitalu cały personel mógłby to testować, może nawet zachęcić część pacjentów (?)
b) W międzyczasie G+A opublikowały dokument 5 (słownie pięć stron) założeń i tekstu jest tam może ze 2 strony A4. Chyba że jest jeszcze jakiś inny dokument ?
c) z powodu b) wszystko wstrzymano i tak naprawdę mamy jedno wielkie NIC. Brak pewników, dat - są idee i marzenia, to wszystko co mamy.
Na pewno zza biurka i klawiatury można mocno teoretyzować i spierać się o różne algorytmy, optymalizować funkcje, czekać na Apple/Google - OK, można zrobić "perfekcyjną appke" - zgoda też takiej chcę.
Ale tu i teraz np. ja (i ok 130tys. pozostałych lekarzy i kilkaset tys. innych pracowników służby zdrowia...) mamy ten kryzys TU i TERAZ na głowie jednak bardziej niż pozostała część społeczeństwa....
I chcielibyśmy mieć "cokolwiek co działa" nawet na początek i "na próbę" po prostu i stąd np. moje zaangażowanie tutaj w miarę moich możliwości i outdated ogólnej wiedzy :-)
potiuk
commented
4 years ago Spróbuję ponownie wytłumaczyć, mail dlatego że "oparłem na mailach" ten pomysł i appka jest de facto jakimś trochę "klientem pocztowym":
Implementacja takiego klienta pocztowego w aplikacji jest bardzo skomplikowana. Poza adresem mailowym przy konfiguracji musi Pan również podać: adres serwera, port, to czy jest używany SSL. Naprawdę myśli Pan że każda osoba w Polsce po stworzeniu konta "gdzieś" otworzy aplikację i wpisze te wszystkie dane?
W celach referencyjnych - tu jest instrukcja krok po kroku (Tych kroków jest dokładnie 7) jak skonfigurować takiego klienta pocztowego: https://pomoc.home.pl/baza-wiedzy/jak-skonfigurowac-program-do-obslugi-poczty-e-mail
Naprawdę pan myśli że wszyscy będą to umieć zrobić bez pomocy?
Założenie ogólnie takie że czy to "true" czy "fejk" warning" może być dwustopniowo zweryfikowane: a) dostajesz maila i np. sprawdzasz (aplikacja sprawdza) czy "autorem" maila jest ktoś z listy "spotkań" zapisanych w bazie lokalnej na komórce
Tak jak napisałem "autora maila" można bez problemu podmienić. Jeśli dostanę od Pana maila, to w ciągu paru minut wyślę panu maila jako pan. Nie ma z tym najmniejszego problemu. Tak niestety działa protokół mailowy dla "ogólnego" przypadku. Chyba że akurat zarówno pan, jak i odbiorca ma wdrożone odpowiednie zabezpieczenia. Ale nie jest to i długo nie będzie standardem.
b) W treści maila jest literalnie i "wprost" wpisany klucz, którym aplikacja która to do Ciebie przesłała "autoryzowała" rozsyłanie tego warninga. Bo inaczej Twój warning nie miałby jak powstać przecież.
Stąd lokalnie aplikacja (sama albo ręcznie kliknieta, albo wręcz użytkownik klika w link w formacie wytworzony w formacie "https://ProteGo.gov.pl/klucz.htm" ) odszukuje ciąg znaków (klucz) w tym mailu.
Kliknięcie linka to już jest całkiem niezły pomysł. Proponuję ćwiczenie. Tutaj jest przykład jak wygląda taka weryfikacja kluczy GnuPG (bo oczywiście sam pomysł nie jest nowy) https://pl.wikibooks.org/wiki/GnuPG/Weryfikacja_kluczy -> prosiłbym o napisanie jak szybko zrozumiał pan instrukcję która tam jest opisana (łącznie z przykładem) i ją wykonał?
Wszystko co nie pasuje do ustalonego formatu teksu (a może nawet tylko tytułu) maila jest ignorowane i nawet jak ta nasza anonimowa skrzynka zapełnia się spamem/fejkami to jest to wszystko ignorowane i kasowane i nawet możemy nie mieć z tym żadnej styczności, bo apka to załatwia automatycznie za nas.
Podpowiadam jeszcze raz. Żeby to zadziałało automatycznie, każdy musi wprowadzić do aplikacji (w 7 krokach) dane do swojego nowo założonego anonimowego konta. Powodzenia.
Jako jak podkreślam) - "tylko amator" jedynie taki szybki sposób weryfikacji true/false wymyśliłem przy kierunku "jednostronnym" pracy aplikacji (czyli ktoś niezakażony jest tylko "biorcą" danych).
No ale dokładnie tak działa algorytm A+G. Z resztą nie oni to wymyślili - oni tylko postanowili zaimplementować algorytmy na temat których dyskusja trwała przez kilka tygodni w róznych miejscach. I implementują od 2 tygodni. Naprawdę serio uważa Pan że jest pan w stanie stworzyć coś prostszego i lepszego i zaimplementować to szybciej? Serio?
Tutaj niestety zupełnie nie mogę się zgodzić, nie jesteśmy w izolacji, a już na pewno ja nie jestem. Liczba zakażeń/zgonów wzrasta.
Zgadza się dziś (przed chwilą oficjalnie) już ponad 500 osób - jesteśmy na fali wzrostowej.
Taka aplikacja (tracing) w moim przekonaniu jest potrzebna "od zaraz/na wczoraj" a już w szczególności dla służby zdrowia bo robi się coraz mniej ciekawie:
To jest inna aplikacja. Contact tracing w tej formule kompletnie nie sprawdzi się w szpitalach. Tam być może faktycznie lepsze były by beacony. Może warto o tym porozmawiać z Estimote? Mogę dać kontakt. Ta aplikacja ma zupełnie inne cele. wyjaśniałem to już kilka razy. Jeśli Chcemy zrobić aplikację dla służb medycznych to najlepiej to zacząć robić. ProteGo nie jest taką aplikacją. I nigdy nie będzie.
a) mieliśmy mieć jakieś rozwiązanie (choćby i beta) przed Wialkanocą. Wiele osób na to czekało, choćby aby "spróbować". Zakładałem że u mnie w szpitalu cały personel mógłby to testować, może nawet zachęcić część pacjentów (?)
Ale do czego? Ta aplikacja nie powoduje powstrzymywania przenoszenia się wurusa. Nie jest w stanie zastąpić maseczek, fartuchów, etc. To rozwiązanie zastosowane z BT nie ma szans na sprawdzenie się w obecnej chwili w szpitalach. To jest zupełnie inny "przypadek użytkowania". Tam natychmiast wszyscy zostali by oznaczeni jako zarażeni.
b) W międzyczasie G+A opublikowały dokument 5 (słownie pięć stron) założeń i tekstu jest tam może ze 2 strony A4. Chyba że jest jeszcze jakiś inny dokument ?
Tutaj są wszystkie dokumenty: 5 stron protokół BT, kolejne 5 kwestie kryptograficzne, 15 stron API: https://www.apple.com/covid19/contacttracing
Dla mnie idealny rozmiar - opisuje wszystkie szczegóły techniczne, łącznie z tym jakie API będzie udostępnione aplikacjom. Byłem w stanie poświęcić parę godzin na ich przeczytanie i zrozumienie i stwierdzam z całą mocą że jest to świetnie przygotowane, opisane i nie mam do czego się przyczepić jeśli chodzi o prywatność. Niebezpiecznik.pl który jest najbardziej znanym watchdogiem jeśli chodzi o prywatność technologii dał temu protokołowi 5+ https://niebezpiecznik.pl/post/google-i-apple-wspolnie-przeciw-koronawirusowi/
c) z powodu b) wszystko wstrzymano i tak naprawdę mamy jedno wielkie NIC. Brak pewników, dat - są idee i marzenia, to wszystko co mamy.
Nic nie wstrzymano. Zgodnie z odpowiedziami @MateuszRomanow - prace idą pełną parą a nawet testy są robione za pomocą oppubl;ikowanego już protokołu BlueTrace (z aplikacji w Singapurze) a jak tylko pojawi się API G+A, będzie na nie przełączone. Więcej informacji tu: https://github.com/ProteGO-app/specs/issues/94#issuecomment-615166223
Ale tu i teraz np. ja (i ok 130tys. pozostałych lekarzy i kilkaset tys. innych pracowników służby zdrowia...) mamy ten kryzys TU i TERAZ na głowie jednak bardziej niż pozostała część społeczeństwa....
Żadna z planowanych aplikacji TU i TERAZ nie rozwiąże obecnego problemu w szpitalach. Rozwiąze je więcej testów, lepszy sprzęt, izolacja ludzi. Pańskie rozwiązanie - pomijając problemy z prywatnością, funkcjonalnością, wdrożeniem etc. również tego problemu nie rozwiązuję. Rozumiem że jest Pan rozgoryczony tym co się dzieje w szpitalach (ja też) ale aplikacja w żaden sposób tego nie rozwiąże. Przykro mi.
I chcielibyśmy mieć "cokolwiek co działa" nawet na początek i "na próbę" po prostu i stąd np. moje zaangażowanie tutaj w miarę moich możliwości i outdated ogólnej wiedzy :-)
Pomijając już funkcjonalność, sposób działania, prywatność, użyteczność Pana propozycji - ze względów, które wymieniłem powyżej - wcale zaimplementowanie tej aplikacji nie będzie takie łatwe jak Panu się wydaje. To że pod spodem jest kryptografia, wcale nie utrudnia jej napisania. Dla większości programistów to jest po prostu chleb powszedni. Wiem że trudno to zrozumieć komuś z zewnątrz ale integracja z dowolną liczbą serwerów pocztowych i weryfikacja kluczy w mailach jest o wiele trudniejszym zadaniem niż zintegrowanie się z istniejącym rozwiązaniem (obecnie jest to BlueTrace a docelowo ma być G+A API).
Dodam jeszcze od siebie - mam nadzieję że @MateuszRomanow cieszy się że nie musi na te maile odpowiadać i że ma kogoś takiego, kto może próbować to wytłumaczyć innym co się dzieje. Lepiej. żeby on teraz zajmował się nadzorem nad tworzeniem aplikacji i upewnieniem się że po stronie rządowej ustalenia co do prywatności będą utrzymane i że rząd przygotowuje odpowiednie procedury na wdrożenie aplikacji.
Dr-Kownacki
commented
4 years ago Ok dobrze że jest lepiej niż myślałem i trzymam kciuki za postępy prac, dziękuję za krzepiące informacje oraz obszerny zasób linków @potiuk , szacun.
Do czego aplikacja i jak przydałaby się w szpitalu (nie-zakaźnym) pozwala ocenić ten drastyczny przykład: https://gazetawroclawska.pl/ten-lekarz-przyjmowal-w-wielu-miejscach-mogl-zarazic-setki-osob/ar/c1-14925210
Po 2 tygodniach nikt realnie nie pamięta czy/jak była interakcja stąd część (bezcennego) personelu jest wysłana niepotrzebnie na kwarantannę. Podczas gdy o informatyku (sic!) który akurat instalował tam drukarkę, elektryku który wymieniał żarówkę i salowej, która myła schody i korytarz niestety nikt nie będzie pamiętał...bo nie ma ich w planie pracy żadnego zespołu/odcinka i jest to nie do odtworzenia...Byl też kierowca z ratownikiem odebrać wypisanego pacjenta no i strażak sprawdzał czujki dymu akurat... Oczywiście funkcja "manuał scan" także byłaby bezcenna na jak już pisałem.
Aplikacja pocztowa - wiem o tych ustawieniach, cóż pewnie i na to znalazłby się automat i sposób jakiś. Ale rozumiem wyzwanie jakieś to jest...
Natomiast nadal podtrzymam teorię że mailem da się autoryzować (a fake-maile dla zabawy telnetem z unixa ćwierć wieku temu robilem na porty - była zabawa "Hallo, coś tam.. się pisało do serwera pocztowego, stare dzieje ;-) ).
To prawda że takiego maila możesz teraz na pewno świetnie spreparować, ale po pierwsze skąd będziesz wiedział "kogo udawać" ?
A jeżeli nawet trafisz i będziesz to wiedział, to skąd weźmiesz adekwatny klucz ? Musiałbyś mieć "jakiś prawdziwy" klucz, ale jeżeli założymy że taki klucz działa szybko i "katalizuje" rozsyłanie maili w ciągu wręcz minut (a potem się "przedawnia") to jednak taki lewy klucz dałoby się wykryć jednak i zignorować jeżeli "timer" klucza różniłby się od czasu wysłania maila.
Dziękuję bardzo za merytoryczną dyskusję, jeśli gdzieś/kiedyś powstanie dzięki niej choć pół linijki kodu albo ćwiartka funkcjonalności to i tak było warto i na pewno dużo się dowiedziałem.
Aktualnie testuję te MACi BT ponoć dynamicznie się zmieniające w iOS i Android i jak się to ma do utrzymania parowania peryferiów i dziękuję za linki do opisu tych specyfikacji.
potiuk
commented
4 years ago Ok dobrze że jest lepiej niż myślałem i trzymam kciuki za postępy prac, dziękuję za krzepiące informacje oraz obszerny zasób linków @potiuk , szacun.
Zawsze chętnie. Dobrze jest zbierać jak najwięcej danych żeby podejmować dobre decyzje :).
Po 2 tygodniach nikt realnie nie pamięta czy/jak była interakcja stąd część (bezcennego) personelu jest wysłana niepotrzebnie na kwarantannę. Podczas gdy o informatyku (sic!) który akurat instalował tam drukarkę, elektryku który wymieniał żarówkę i salowej, która myła schody i korytarz niestety nikt nie będzie pamiętał...bo nie ma ich w planie pracy żadnego zespołu/odcinka i jest to nie do odtworzenia...Byl też kierowca z ratownikiem odebrać wypisanego pacjenta no i strażak sprawdzał czujki dymu akurat...
Do tego naprawdę o wiele lepiej by było używać beaconów. Każdy pracownik/pacjent dostaje taki beacon na wejściu a potem już wszystko się dzieje samo. Naprawdę zupełnie serio mogę Cię polecić do osób z Estimote - oni nawet już zrobili do tego gotowe rozwiązanie które wydaje się w 100% realizować to o czym piszesz: https://estimote.com/wearable/
Aplikacja pocztowa - wiem o tych ustawieniach, cóż pewnie i na to znalazłby się automat i sposób jakiś. Ale rozumiem wyzwanie jakieś to jest...
Jest spore.
Natomiast nadal podtrzymam teorię że mailem da się autoryzować (a fake-maile dla zabawy telnetem z unixa ćwierć wieku temu robilem na porty - była zabawa "Hallo, coś tam.. się pisało do serwera pocztowego, stare dzieje ;-) ).
To prawda że takiego maila możesz teraz na pewno świetnie spreparować, ale po pierwsze skąd będziesz wiedział "kogo udawać" ? Stanę koło kogoś i po chwili będę znał maila.
A jeżeli nawet trafisz i będziesz to wiedział, to skąd weźmiesz adekwatny klucz ? No to już z tygodnia implementacji robią się 3-4. To już nie jest prosty system.
Dziękuję bardzo za merytoryczną dyskusję, jeśli gdzieś/kiedyś powstanie dzięki niej choć pół linijki kodu albo ćwiartka funkcjonalności to i tak było warto i na pewno dużo się dowiedziałem.
Myślę że kontakt z Estimote i https://estimote.com/wearable/ to jest idealny dla Ciebie pomysł.
Aktualnie testuję te MACi BT ponoć dynamicznie się zmieniające w iOS i Android i jak się to ma do utrzymania parowania peryferiów i dziękuję za linki do opisu tych specyfikacji.
Ciekaw jestem wyników.
potiuk
commented
4 years ago A tu bardzo jasne wyjaśnienie działania rozwiązania Estimote:
matsobdev
commented
4 years ago A tu bardzo jasne wyjaśnienie działania rozwiązania Estimote:
W sumie można uczyć się od lepszych ;) Plus że nadajniki mają widoczność optyczna i sygnał jest silniejszy vis-a-vis czyli w polu chuchu
potiuk
commented
4 years ago W sumie można uczyć się od lepszych ;) Plus że nadajniki mają widoczność optyczna i sygnał jest silniejszy vis-a-vis czyli w polu chuchu
No właśnie "Standing on the shoulders of giants". I to takich naszych "giants" z Krakowa
Dr-Kownacki
commented
4 years ago Dla treningu (podkreślam że rozumiem wady i ograniczenia tego pomysłu) zastanowiłem się czy ta moja amatorska/lamerska metoda byłaby także podatna na potencjalny problem #109
Co zaskakujące doszedłem do wniosku że nie byłaby absolutnie podatna:
1) Po pierwsze trudniej byłoby hurtowo "zakazić" całe piętro biurowca, bo musielibyśmy cierpliwie "nazbierać" od wszystkich ich adresy e-mail i wymagałoby to sporego nakładu czasu i pracy.
2) Następnie trzebaby te wszystkie adresy wyeksponować na przysłowiowej "izbie przyjęć szpitala zakaźnego" gdzie pobraliby je automatycznie pacjenci z dużym ryzykiem pozytywnej diagnozy i co za tym idzie uruchomienia ścieżki warningu j.w. w wątku.
Niby totalna katastrofa na pierwszy rzut oka, ale...
3) Po postawieniu diagnozy aplikacja wyśle e-mail z warningiem, ale w tym mailu byłyby zapisane koordynaty GPS i czas tego spotkania.
Jest zatem oczywistym że takiego "oszukanego warninga" moglibyśmy od razu rozpoznać ponieważ np. "nie byliśmy dzisiaj na izbie przyjęć szpitala zakaźnego w Łomży" :-)
Co więcej, rozpoznanie takiego fałszywego warninga mogłoby być automatycznie rozpoznane przez naszą lokalną aplikację, która prowadziłaby lokalnie nasz dziennik lokalizacji i po prostu porównywałaby konkretny przedział czasowy z maila z logiem naszych lokalizacji lokalnie i odrzuciłaby takie fałszywe zgłoszenie. Stąd nigdy byśmy tego ataku nie zauważyli a e-mail byłby oczywiście kasowany.
Oczywiście jest zagrożenie że taki rozgloszony publicznie e-mail byłby rozpropagowany i zostałby tak "spalony" że komórka już tylko tymi fałszywymi warningami zajmowałaby się. Ale wtedy wystarczyłoby założyć nową skrzynkę...
Reasumując: konkretnie w zakresie podatności na hipotetyczny #109 w porównaniu do API A+G ośmielam się przypuszczać że mój pomysł z mailami mógłby mieć przewagę ;-)
Jeżeli zatem jakieś API pozwalałoby po prostu "bezkarnie dla baterii" na zasadzie A+G rozsiewać te adresy e-mail co kilka minut to byłoby OK.
No i ostatnia rzecz: prywatność @potiuk - znalazłem rozwiązanie łącząc z GPS i chwilowy czas: Adres e-mail będzie ZASZYFROWANY tzn. będziemy się za każdym razem INACZEJ ROZGŁASZAĆ - a hasłem będzie algorytm łączący czas i lokalizację GPS !
Ten kto "odbierze" nasz beakon ma taki sam czas na zegarku i datę ale w dodatku JEST W TYM SAMYM MIEJSCU CO MY !
Chwilowym kluczem jest zatem "czas i lokalizacja" i to rozwiązanie jest moim zdaniem bardzo ciekawe, bo ten klucz nigdy się nie powtórzy ale osoby znajdujące się obok siebie z natury rzeczy MAJĄ TEN SAM KLUCZ :-)
W ten sposób okazuje się że nie ma możliwości śledzenia nas bo rozglaszany się cały czas inaczej i klucze cały czas się zmieniają bo czas upływa a my się przemieszczamy.
@potiuk : bardzo liczę na Twój komentarz fachowca w wolnej chwili:-)
Czy może Dr-Kownacki:API A+G 1:0 ? ;-) (W aspekcie #109 tylko oczywiście )
potiuk
commented
4 years ago Tak jak opisałem w https://github.com/ProteGO-Safe/specs/issues/108#issuecomment-618047273 - jako że nie jestem ekspertem (w przeciwieństwie wyraźnie do @Dr-Kownacki ) w warstwie bezprzewowdowej komunikacji BLE) barddzo chętnie podyskutuję po dostarczeniu wiarygodnych źródeł opisujący ten mechanizm ataku (i wykraczający poza to co już dawno opisali twórcy protokoły BlueTrace - https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf (rozdział 8). Bez tego w ogóle nie ma co dyskutować nad pomysłem. Choć z punktu widzenia kreyptografii zawiera on przynajmniej jedną dyskfalifikującą kwestię szyfrowania kluczami (tak zwany Man-In-The0Middle atack)- każdy kto może odszyfrować wiadomość lokalnie (a może bo jest lokalnie) może ją przesłać dalej i zaszyfrować używając docelewego klucza).
Dr-Kownacki
commented
4 years ago Troszkę odgrzeję temat - bardziej z autorskiej/kronikarskiej potrzeby i chęci doprowadzania (nawet w teorii tylko) ciągu przemyśleń jeśli nawet nie do końca - to chociaż może do pół kroku dalej :-)
Troszkę zoptymalizowałem moje podejście jak poniżej, głównie dzięki b.celnym uwagom @potiuk odnośnie pokręconego konfigurowania skrzynki pocztowej w aplikacji, co dla wielu osób może być zbyt skomplikowane ( chociaż prosta instrukcją "krok po kroku" mogłaby być przydatna...)
Zaznaczam że rozumiem iż API G+A i tak nas czeka pewnie, ale że lubię tematy konsekwentnie do przodu ciągnąć (nawet tylko teoretycznych rozważaniach) więc mam taki pomysł na ulepszenie:
A) Użytkownik zakładał by skrzynkę na jakimś serwisie wybieranym po prostu z jakiejś najpopularniejszej listy serwisópw pocztowych (z poziomu appki może jakiś "pół-automat"/asystent by pomagał ... ?) Gmail/ Onet/ WP/ Yahoo/ Interia/ Tlen/ iCloud - etc.
B) I wtedy mając tam dedykowaną skrzynkę po prostu z listy wybierałby podczas instalacji aplikacji gdzie ma skrzynkę - stąd aplikacja konfigurowała by się już "sama" do tej skrzynki dalej mając/znając wszystkie presety (pop etc.) dla konkretnych serwisów pocztowych, bo one przecież są stałe.
Konfigurując aplikację po prostu wpisywało by się login/hasło i z tej w/w. listy j.w. wybierało serwis. Jak na jednokrotne działanie z takim uproszczeniem moim zdaniem jest to w moim przekonaniu bardziej akceptowalne i łatwiejsze więc jest to zatem mały krok do przodu :-)
-ALBO JESZCZE PROŚCIEJ (?):
C) Tu już zupełny hardcore (ale chyba wykonalny ?): Druga możliwość to jakiś "automat" który podczas instalacji robiłby wszystko "za nas" zakładając skrzynki na losowych serwisach (albo tylko na jednym Gmailu/iCloud).
Użytkownik w zależności od serwisu tylko klikałby ręcznie "nie jestem robotem"/captcha etc. tam gdzie jest to niezbędne, a całą resztę załatwiała by aplikacja...
Użytkownik nawet nie musiałby wiedzieć jaki ma login i hasło a nawet w jakim serwisie, ale to już skrajność :-) Wszystko działo by się losowo tzn. adres byłby np. protego_fg345sf345gdh674gw3@gmail.com podobnie byłoby z hasłem. To nawet mogłoby być w aplikacji zaszyfrowane i ew. do odzyskania w SMS wysłanym "do samego siebie" na tym samym telefonie tylko po zdefiniowaniu numeru (też zaszyfrowanego?) podczas instalacji albo nawet ad hoc. w radzie potrzeby odzyskania.
D) Rozgłaszanie BT tego adresu maila zmieniane co 15 min. a kluczem do rozszyfrowania adresu rozgłaszanego przez nas maila jak już wcześniej pisałem byłby algorytm uwzględniający datę i numer kolejnego "kwadransa" w dobie oraz przybliżoną lokalizację geograficzną (coarse). Coś takiego jak na kształt pomysłów opisanych w #109 i pewnie znacznie lepsze patenty można wymyślić. Klucz szyfrujący/sposób szyfrowania nie byłby podany do powszechnej wiadomości ale nawet gdyby się zdarzył MIDM attack to jakby ktoś "podsunął" nasz zakodowany-odkodowany-ponownie zakodowany adres, to i tak "zakażony" telefon wysyłając nam (w dobrej wierze) "warninga" - bo ktoś mu podsunął nasz adres to poda w nim zarówno swój "klucz katalizujący od SANEPIDu" jak i LOKALIZACJĘ/CZAS kiedy się spotkaliśmy no ale wtedy to każdy sam się zorientuje a w dodatku apka (jak już pisałem) sama mogłaby okrywać takie nieprawdziwe maile po logu własnych lokalizacji/daty/czasu z których generowała szyfrem klucz do rozgłoszenia maila/
E) Jeśli chodzi o "budzenie" telefonu z ew. hibernacji a'propos adresowania hipotetycznych problemów z BT, to może nawet jakiś trywialny/prymitywny sposób z opisanych ostatnio przeze mnie w #59 ale pewnie jest wiele innych lepszych pomysłów i sposobów że nie wspomnę o API G+A, które jak rozumiem zapobiega "usypianiu" w kwestiach BT (?) Więc może nawet samo załadowanie API do systemu (nawet jeśli nieużywane do tracingu) i tak pozwalałoby zapobiegać hibernacji.
Podkreślam że w/w. wątek-issue to nie żadna "alternatywa/konkurencja" dla opisywanego tu rozwiązania ale raczej tylko rozwinięcie przedstawionego tutaj hipotetycznego pomysłu dla treningu wyobraźni przede wszystkim ale może do czegoś się przyda komuś :-)
kamilgthecoders
commented
4 years ago Temat nieaktualny w zakresie zastosowanego rozwiązania EN. Sprzątając, zamykam.
Poniżej moje spojrzenie na problem, co sądzicie ?
1) Użytkownik zakłada dedykowane anonimowe konto pocztowe na dowolnej darmowej skrzynce ale w ustalonym formacie np. protego---drkownacki@gmail.com
2) Użytkownik ustala nazwę BT swojego smartfona tożsamą do w/w. adresu mailowego i włącza rozgłaszanie tej nazwy. Czy da się skutecznie to na IOS zrobić jak na Androidzie?
3) Aplikacja na bieżąco co X sekund (15? 30?) skanuje rozgłaszane w pobliżu nazwy BT i jeżeli taka nazwa spełnia warunek początkowy protego---xxxxxx@xxxxxxxx.xxx to sprawdzana jest siła sygnału . Jeżeli siła sygnału dla rozglaszanej nazwy jest "wystarczająca" (tutaj do ustalenia jaka minimalna wartość -dBm ma sens), to taka nazwa (adres email) jest zapisywana wraz datą/czasem i lokalizacją "spotkania" w LOKALNEJ (zaszyfrowanej?) bazie.
4) Interakcja pomiędzy smartfonami ma charakter czysto "PASYWNY", zapisuje się LOKALNIE w smartfonie w lokalnej bazie rekordy spotkań "z nasłuchu". Nie ma żadnej interakcji pomiędzy smartfonami, nie ma żadnego serwera, wymieniania kluczy, handshake'ow etc. - wszystko dzieje się CAŁKOWICIE PASYWNIE ( i trywialnie ). Moim zdaniem to największy atut tego rozwiązania bo działa a'la beacon... Nie wymaga Internetu nawet przez 99% czasu ! Appka w takim pasywnymi trybie może nie wpłynie na odtwarzanie muzyki na słuchawkach BT co opisano/zglaszano przy aplikacjach na świecie chyba.
5) Aplikacja pozwala również dodatkowo na "ręczne" precyzyjne wpisanie danych spotkania, zeskanowanie się wzajemne osób na spotkaniu z "pewnym" kontaktem ew. wpisaniem czy były maski na twarzach, jaka była wielkość pomieszczenia albo czy na dworzu etc. itp. Wtedy też i "warning" dla takiego eventu będzie bardziej rozbudowany, do dyskusji. To szczególnie ważne m.in. dla personelu medycznego, już pisałem o tym w #63
6) Użytkownik przy instalacji LOKALNIE wpisuje w aplikację swój PESEL, albo numer telefonu (sam się może ew. zaczytac z SIM/sieci?). To musi być jedna z tych dwóch informacji, poniżej wyjaśniam dlaczego, być może lepszy będzie numer telefonu, bo nie każdy ma PESEL a każdy mający smartfona ma numer telefonu. Podkreślam że to tylko lokalnie jest przechowywane.
7) SANEPID/GIS/MZ mają bazę wszystkich przypadków zakażeń, a przy pobieraniu próbki zawsze jest zapisywany PESEL/numer telefonu pacjenta. Nawet jak gdzieś prywatnie/odpłatnie to badanie wykonamy to ustawowo te dane w przypadku pozytywnego wyniku MUSZĄ być przekazane do j.w. stąd te dane zawsze są zebrane.
8) Przy rejestracji pozytywnego przypadku SANEPID/GiS na podstawie PESEL/numeru telefonu generuje automatycznie jakimś algorytmem (biorąc w nim pod uwagę chwilowy czas generowania etc.itp.) unikalny klucz definiujący fakt POZYTYWNEGO wyniku i powiązanie go z PESEL/lub numerem telefonu osoby zakażonej.
Dla uproszczenia niech to będzie numer telefonu stąd bramka SMS GIS/SANEPID pod ten numer telefonu wysyła w SMS ten obliczony unikalny klucz w ustalonym formacie jako jakiś rozpoznawalny ciąg znaków np. PROTEGO-klucz--dgdegh1$&wt$&4vfea253
9) Aplikacja w smartfonie przy odebraniu takiego SMS rozpoznaje po kliknięciu w aplikacji SMS (albo nawet sama) format/link etc. i proponuje aktywację wysyłki ostrzeżenia dla osób z LOKALNEJ bazy danych, ale klucz można też wprowadzić ręcznie na wszelki wypadek.
10) Aplikacja wyśle warningi mailem do osób z LOKALNEJ bazy telefonu tylko wtedy, jeżeli "auto-odebrany"/"wpisany ręcznie" klucz zostanie prawidłowo rozszyfrowany w aplikacji że jest to klucz dopasowany dla tego konkretnego numeru telefonu (albo PESELu). W ten sposób nie można robić wygłupów/"fałszywych warningów" co więcej adresy zebrane w LOKALNEJ bazie też są zaszyfrowane i jest to utrudnienie dla ich spamowania etc.
11) Warning w mailu przychodzi defaultowo ANONIMOWY, ale użytkownik ma możliwość deanonimizacji i podania numeru telefonu jeśli chce (mogą być różne sytuacje np."służbowe" więc i taka opcja powinna być możliwa).
Niezależnie jakimś teoretycznym "kanałem zwrotnym" jest adres maila z którego warning przyszedł jeżeli założymy że nie będzie on anonimowy - do dyskusji...
Warning ma ustalony format maila, który w łatwy sposób pozwala odróżnić go od spamu (ale i tak preferowana jest to tego oddzielna skrzynka mailowa).
Warning mógłby zawierać informacje od kiedy osoba zakażona zaobserwowala u siebie objawy kliniczne co może być ważne przy szacowaniu ryzyka zarażenia.
Czy aplikacja powinna sama sprawdzać ten adres/skrzynkę i "wyłapywać" te warningi to sprawa otwarta do dyskusji; skoro i tak będzie mieć funkcje "aplikacji mailowej" do nadawania to może też niech i odbiera sama...(?)
W warningu przychodzą też konkretne przydatne informacje tzn. gdzie się zgłosić, co robić, gdzie zadzwonić...
12) Zabezpieczeniem aplikacji przed wygłupami (spamowanie/strasznie "złowionych" adresów e-mail rozglaszanych w BT to etc.) mogą być dwa mechanizmy:
A) aplikacja sprawdza czy nadawca maila jest na naszej liście kontaktów (czy nawzajem się kiedyś "złowiliśmy"), i od razu odszyfrowuje nam kiedy to miało miejsce i możemy to porównać z info z "warningu", stąd aplikacja potwierdza że to prawdziwe info (chociaż oczywiście z jakichś technicznych przyczyn "złowienie" może być jednostronne stąd B) )
B) W formacie maila warningu jest także zawarty ten "klucz uwierzytelniający" który pozwolił nam tego maila przesłać od osoby z potwierdzonym zakażeniem np. w postaci linku do serwera GIS/SANEPIDu w którym gromadzone i dostępne on-line będą wszystkie aktywujące klucze i będzie można potwierdzić czy jest on prawdziwy czy to oszustwo i spam i klucz jest nieprawdziwy. Najprostszy sposób to tworzenie gdzieś na WWW plików .htm o tożsamej dla klucza nazwie i takiej samej zawartości więc jeżeli klucz jest prawdziwy to otworzy się strona z nim, a jeżeli nie jest to brak adresu i wiadomo że fake a i serwer też może odpowiedzieć ładnie że fake (nie ma takiego numeru) zamiast "404" pisać w przeglądarce...
Ale pewnie są bardziej eleganckie sposoby :-)
13) Do rozważenia implementacja jakiejś opcji warningu "drugiego rzędu" czyli ja dostałem warning ale nie mam jeszcze objawów/potwierdzenia/czekam na test - i taka informacja idzie do kontaktów z "mojej" bazy danych z zastrzeżeniem że to alert niższego stopnia no i po takim należałoby jakis "ciąg dalszy" napisać w zależności od sytuacji ("jestem trafiony", "nie jestem trafiony-test ujemny", "nadal czekam na kwadrannie" etc.)
Tyle mojego wkładu/pomysłów, jedynym realnym ograniczeniem/wyzwaniem jest kwestia uwierzytelniania informacji przez GIS/SANEPID/MZ i ustalenie z nimi generowania tych "kluczy uwierzytelniających". Bo tylko w ten sposób aplikacja będzie odporna na "wygłupy".
Cała reszta jest przypuszczalnie dla obecnego tutaj gremium IT banalna do wykonania w ciągu pojedynczych dni i nie są potrzebne żadne Google/Apple "extrasy" do tego. Moim zdaniem przedstawione przeze mnie rozwiązanie ma dużą szansę się sprawdzić w praktyce i być odpornym na ataki a jednocześnie zachować info i prywatność użytkowników (lokalna baza spotkań w smartfonie, anonimowa skrzynka mailowa).
Zamiast "centralnego serwera rządowego" którego wiele osób się obawia, mamy prosty mechanizm oparty o anonimowe dedykowane prywatne skrzynki mailowe w dowolnych lokalizacjach. Aplikacja w żadnym momencie nie łączy się z serwerem "rządowym" i nie wymiana absolutnie żadnych danych, jest jedynie pasywnym "biorcą klucza" przez SMS - a i to tylko i wyłącznie w przypadku konieczności rozesłania warningu.
Jestem ciekaw komentarzy zawodowców - bo prawda jest taka że czas niestety ucieka i (jak ja to rozumiem) czeka się obecnie na ruch Apple/Google. W warstwie ogólnej powyższy pomysł z tym "nadchodzącym" rozwiązaniem też mógłby działać, chociaż wcale go nie potrzebuje moim skromnym (zastrzegam że jedynie "lekarskim" ) zdaniem.
Pozdrawiam.