ProteGO-Safe / specs

Opis, specyfikacja i zadania. Zacznij tutaj.
GNU General Public License v3.0
117 stars 29 forks source link

Zmiana modelu aplikacji na bardziej skuteczny - uwzględniający testy i otwarty algorytm #54

Closed potiuk closed 4 years ago

potiuk commented 4 years ago

Po chwili zastanowienia i analizy danych doszedłem do wniosku że aplikacja w obecnym kształcie nie będzie spełniać swojej roli - nie tylko ze względu na konieczność podawania swojego numeru telefonu (wiele osób tego nie zrobi) ale również ze względu na matematyczny model epidemii.

Obecnie aplikacja zakłada trzy statusy:

Status czerwony wynika najprawdopodobniej (algorytm decydujący o tym ani nie jest otwarty, ani nie jest zabezpieczony licencjamie) z faktu że analiza danych wykazała że jest duże prawdopodobieństwo, że było się blisko osoby która została zdiagnozowana na COVID-19. Nie jest jasne, co potem dzieje się z osobą która ma status czerwony. Czy ma zostać poddana kwarantannie od razu ? czy powinna się poddać testowi natychmiast i kwarantannie ? w jaki sposób status takiej osoby zmienia się z powrotem na zielony ? Trudno powiedzieć, obecna specyfikacja na ten temat nic nie mówi i jest to olbrzymia "dziura" w designie całego rozwiązania.

Nie jestem epidemiologiem, i nie wiem czy ktokolwiek (najlepiej specjalista-epidemiolog) spojrzał na możliwe wartości i policzył w jaki sposób "czerwone" będzie się propagowało przez społeczeństwo. Wydaje się - że przy zarażalności i częstej bezobjawowości rozprzeztrzeniania się wirusa, bardzo szybko status "czerwony" będzie dotyczył większości z nas. Mam nadzieję że przed wdrożeniem aplikacji epidemiolodzy zrobią odpowiednie symulacje a nie że będzie to jeden wielki eksperyment bez świadomości co robimy. W tym wypadku "szybkość" wdrożenia jest o wiele mniej ważna niż "poprawność" - aplikacja będzie potrzebna za 5-10 tygodni jak minie szczyt zarażeń i zaczniemy rozluźniać izolację.

Zwłaszcza że istnieje spore zagrożenie manipulacjami algorytmów po stronie analizy danych (dodam ponownie - algorytmy te nie są w żaden sposób udostępnione publicznie i nie podlegają kontroli społecznej). Problem rozwiązuje #34, gdzie algorytm wykonuje się na telefonie a nie w tajemniczej chmurze nad którym kontrolę będzie miała (zakładam) strona rządowa. Było na ten temat issue #4 kiedy algorytm miał być (chyba) po stronie aplikacji ale zostało ono zamknięte. W chiwili obecnej algorytm nie jest publiczną częścią rozwiązania.

Mam nadzieję że algorytmy te zostaną upublicznione.

Moja propozycja jest taka, żeby rząd pełnił w przypadku tej aplikacji - z resztą jak we wszystkim powinno być - rolę usługową dla ludzi a nie kontrolującą i infiltrującą. Aplikacja zamiast mówienia "poddaj się kwarantannie" powinna mówić "poddaj się testom" i w takiej sytuacji powinna być przepustką do natychmiastowego i darmowego wykonania testów na COVID-19 na koszt społeczeństwa (administrowany i na masową skalę udostępniony przez stronę rządową).

Status "podddaj się testowi" powinien wprowadzać pewne ograniczenia dla tej osoby - na przykład nie powinna mogła wchodzić na masowe imprezy. Wraz z wynikiem testu powinien zostać osobie testowanej kod identyfikujący czy wynik jest "chory" czy "zdrowy" i na tej podstawie powinien zostać zmieniony status w aplikacji ("chory" - "czerwony", "zdrowy" - zielony). Strona rządowa powinna zabezpieczyć odpowiednią liiczbę testów (na podstawie symulacji) oraz punktów w których szybko można się poddać testom - dopiero wtedy aplikacja taka będzie miała sens.

W tym modelu - powtórzę to z #34 - nie ma konieczności podawania numeru telefonu przy starcie aplikacji. Nawet jeśli chcemy zacząć zbierać dane już teraz i wypuścić aplikację szybko.

Apeluję o wypuszczenie aplikacji bez podawania numeru telefonu w jej pierwotnej wersji i przemyślenie modelu aplikacji wraz z epidemiologami i uwzględniając status "poddaj się testom" i możliwość ich zrealizowania zapewnioną przez rząd Rzeczpospolitej Polskiej.

KoderFPV commented 4 years ago

Tylko że utrzymując taki algorytm na urządzeniu jest pewne ryzyko jego manipulacji.

Myśle że bardzo szybko powstałaby druga aplikacja albo "crack" do niej, który umożliwiłby zmiane statusu. Strona serwerowa jest tutaj potrzebna własnie, żeby mieć pewność że nikt takimi danymi nie manipuluje.

Zastanawiam się nad tą decentralizacją i użyciem technologii blockchain do tego. Ale wydaje mi się że opiera się ona na tym że dużo osób udostępnia moc kart graficznych podczas kopania waluty, co jednocześnie zasila tą sieć blockchainową. Nie jestem ekspertem, ale nie wiem po co i co miało by się kopać.

Chyba że jak wykopie się chorego to dostaje się kase xD

potiuk commented 4 years ago

Ale akurat to nie byłby problem. Wystarczy po stronie serwerowej trzymać jedynie dane autoryzujące osoby "chore". W momencie którym masz status "zdiagnozowany" Twoje dane powinny zostać zautoryzowane specjalnym kodem wygenerowanym po stronie serwera i dopiero wtedy mogły by być rozpowszechniane. Można bez problemu zapewnić autoryzację tych danych po stronie aplikacji (tej nie zmanipulowanej). Wystarczy żeby te dane były podpisane odpowiednim kluczem.

Przy okazji podawania kodu (czyli rzadko - wtedy kiedy diagnoza jest "chory") można też bez problemu opracować metodę która zweryfikuje, czy aplikacja nie została zmanipulowana (choćby wykorzystując mechanizmy Play Store czy AppStore).

potiuk commented 4 years ago

Zupełnie nie trzeba do tego blockchainu - wystarczy żeby centralny serwer robił to co do niego należy - służył społeczeństwu zapewniając mechanizmy autoryzacyjne, jednocześnie nie przechowując danych osobowych i nie umożliwiając de-anonimizacji osób zdrowych.

KoderFPV commented 4 years ago

Brzmi super.

Ale podsumowując, w tym modelu jest szansa że ktoś kto będzie zagrożony, nic sobie z tego nie zrobi?

potiuk commented 4 years ago

Brzmi super.

Ale podsumowując, w tym modelu jest szansa że ktoś kto będzie zagrożony, nic sobie z tego nie zrobi?

Podobnie jak taka że taka osoba w ogóle nie będzie miała zainstalowanej aplikacji. Bo po co miała by ją instalować jeśli miała by zamiar nic sobie z tego nie robić ?

niutech commented 4 years ago

Zobaczcie jak sobie poradziły z ochroną prywatności inne projekty, np. Safe Paths.

jakublipinski commented 4 years ago

Skoro numer telefonu jest już opcjonalny to można to zamknąć?

potiuk commented 4 years ago

Myślę że warto by opisać konkretnie jak ten model będzie działać z /bez telefonue - i wtedy to zamknąć? Może tak będzie bardziej sensownie?

jakublipinski commented 4 years ago

Opisałem wszystko tutaj: https://github.com/ProteGO-app/specs/commit/b48695999c90dda5c18f448cffb59e20ee8a20c3, https://github.com/ProteGO-app/specs/commit/694cc66b6e7010e77e316d2849eaa4f246fec0f9, https://github.com/ProteGO-app/specs/commit/336a7bb176bd1e36dc67cec237027d409cfc41bf

Zrób PR jeśli widzisz że można to jeszcze jaśniej opisać

potiuk commented 4 years ago

Jest dobrze opisane! Dzięki!

jasisz commented 4 years ago

@potiuk Algorytm dalej nie jest publiczny, dalej użytkownicy są oznaczani ręcznie, a nie automatycznie "na telefonach". Myśle, że to issue trzeba ponownie otworzyć.

potiuk commented 4 years ago

Tutaj są dwie sprawy.

Pierwsza i najważniejsza - jeśli (a takie jest w tej chwili założeie) użytkownicy są domyślnie anonimowi (zakładam że tak będzie docelowo domyślnie - to znaczy że użytkownicy nie będą namawiani nachalnie do podania numeru) to nie ma to znaczenia. Jeśli strona serwerowa nie wie czyimi danymi manipuluje, to nie będzie tego robiła (bo i po co?). To miało znaczenie tylko wtedy jeśli można było wykorzystać niejawny algorytm do manipulowania stanem konkretnej (znanej) osoby. Jeśli zamiast tego będzie można manipulować stanem anonimowych ID to nie ma to znaczenia.

Raczej nikomu nie będzie zależało na masowym "anonimowym" przekłamywaniu danych. Wręcz przeciwnie - stronie rządowej będzie zależało na tym żeby unikać przypadków w których algorytmy były by błędne (i wprowadzały by chaos/zamieszanie/panikę). Można oczywiśce polegać na zdecentralizowanym algorytmie i decyzjach podejmowanych na telefonie, ale w mojej osobistej opini lepiej jest żeby ten algorytm był ciągle rozwijany i testowany.

Druga rzecz:

Najprawdopodobniej i tak algorytm będzie jakąś odmianą modelu AI / uczenia maszynowego - która bedzie bardzo trudna do zrozumienia z samej zasady modelu (będą to pewnie wagi w modelu sieci). I lepiej to porządnie przetestować na anonimowych danych (również potencjalnie historycznych) i kontrolować na serwerze niż implementować po stronie telefonu (bo wtedy jego aktualizacja i testowanie będzie szalenie trudne). Więcej o tym napisałem w https://github.com/DP-3T/documents/issues/13#issuecomment-610301814 - w gronie Europejskim jest obecnie dążenie do zaimplementowania jednego standardu dla wszystkich i obecnie toczy się dyskusja nad jego formą - zdecentralizowany lub scentralizowany (oba mają wady i zalety). Wydaje mi się że zdecentralizowana forma będzie bardzo trudna do implementacji (ze względu na powyższe) ale jakaś forma hybrydowa pewnie też jest możliwa.

Oczywiście wszystko pod warunkiem anonimowości na serwerze. Mam szczerą nadzieję że tak właśnie będzie w ProteGO - i że docelowo nawet przy podaniu numeru telefonu nie bedzie on "przywiązywany" do konkretnych BT ID (co jest całkiem możliwe do realizacji i mam nadzieję żę MC i autorzy się nad tym pochylą). Mam nadzieję że to o co apeluje Wojciech Wiewiórowski (Inspektor Europejskiego Biura Ochrony Danych) https://www.youtube.com/watch?v=g8b9hvZDjq0 i https://www.bbc.com/news/technology-52189551 wpłynie na MC i implementację ProteGO tak że dane będą kompletnie anonimowe również w tym przypadku. To by na przykład umożliwiło ProteGO (lub jakiemuś "forkowi" ProteGO - w końcu licencja GPL/AGPL umożliwia każdemu zaimplementowanie wersji z poprawioną prywatnością - stanie się bazą / wzorem dla innych implementacji a może nawet było by "tą" implementacją. Uważnie to obserwuję i w razie czego będę kwestię na pewno podnosił.

Oczywiście było by super, gdyby ten model również mógł być publiczny ale jak dla mnie - przy faktycznej anonimowości danych BT to nie jest zagrożenie. To oczywiście należy bardzo dokładnie weryfikować i tu istotne jest przegląd/audyt kodu i wdrożenie #58 w celu publicznego nadzoru nad projektem ale mam nadzieję że żeby osiągnąć swój cel autorzy projektu i MC zrobią wszystko i zaangażują odpowiednie organizacje, żeby zdobyć zaufanie społeczne.

Uważnie wszyscy patrzmy na ten kod i opublikowaną aplikację - wydaje się że zadziałało to na tą chwilę z obowiązkowym numerem telefonu (ale patrzmy i sprawdzajmy). Świetnie żę to jest kod otwarty i że można to śledzić na bieżąco.

jasisz commented 4 years ago

@potiuk To nadal ma znaczenie, bo:

  1. Nie wszyscy użytkownicy będą anonimowi w samym systemie (część będzie miała numery telefonu).
  2. Sam system ściągania swojego statusu bezpośrednio z jakiegoś endpointa jest bardzo podatny na manipulacje i ataki (MITM, włamanie na centralny serwer, błąd operatora). Przy scenariuszu z publikowaniem klucza są one niemożliwe, bo klucza prywatnego nie da się nijak "zgadnąć" i opublikować.

Nie rozumiem jednej podstawowej kwestii - jak mają działać te całe algorytmy, kiedy w takim zanonimizowanym scenariuszu brakuje im podstawowej danej. Same tymczasowe identyfikatory bez powiązania ich ciągu z konkretną osobą (co jest niemożliwe z samej zasady protokołu) są bezużyteczne dla liczenia prawdopobieństwa zarażenia. Tego nie da się liczyć centralnie, da się jedynie lokalnie...

Dalej można iść tą drogą, że system tylko powie "hej, wykryliśmy że spotkałeś się z zagrożoną osobą, trwało to tyle i tyle, według naszej wiedzy ryzyko Twojego zarażenia jest niskie, ale dla pewnosci zastosuj samoizalacjęl jeżeli chcesz zeby nasze super fajne i tajne algorytmy się tym zajęły, wrzuć proszę i swoje dane dla AI, to powiemy Ci więcej i przyczynisz się blablablblblalab".

potiuk commented 4 years ago

@jasisz -> otworzyłem #83 w którym o tym piszę i przedsatwiam tam opcje podawania numeru i informowania o konsekwencjach wyboru. Myślę że najlepiej by było, gdyby faktycznie zaimplementować w pełni anonimowe przechowywanie identyfikatorów bluetooth niezależnie od podania lub nie numeru telefonu (wariant 4 w #83) to było by to bardzo ok. W innych przypadkach też jest to akceptowalne - pod warunkiem jasnego powiązania podawania numeru z utratą anonimowości i komunikowanie to użytkownikowi żeby świadomie mógł podjąć decyzję. Myślę że warto tą dyskusję kontynuować tam.

Odpowiadając na Twoje pytanie:

Nie rozumiem jednej podstawowej kwestii - jak mają działać te całe algorytmy, kiedy w takim zanonimizowanym scenariuszu brakuje im podstawowej danej. Same tymczasowe identyfikatory bez powiązania ich ciągu z konkretną osobą (co jest niemożliwe z samej zasady protokołu) są bezużyteczne dla liczenia prawdopobieństwa zarażenia. Tego nie da się liczyć centralnie, da się jedynie lokalnie...

Identyfikatory jednej osoby w obecnym rozwiązaniu ProteGO są związane ze sobą. Aplikacja pobiera identyfikatory z serwera - podając swój unikalny identyfikator - i odpowiednie BT id dostępne na serwerze są ze sobą powiązane. W ten sposób identyfikujesz je z "instalacją" aplikacji. Obecnie są również powiązane z numerem telefonu użytkownika (ale jest on opcjonalny). Modyfikacja zaproponowana i opisana w pkt. 4 w #83 usunęła by powiązanie z numerem telefonu (to powiązanie było by przechowywane tylko lokalnie w aplikacji użytkownika) ale dalej identyfikatory BT były by związane ze sobą i z konkretną "instalacją aplikacji".

Takie rozwiązanie umożliwia anonimową identyfikację "zagrożonych instalacji" na serwerze a jednocześnie umożlwia aplikacji wysłanie numeru telefonu do GIS (bez powiązania z identyfikatorami BT) w momencie wykrycia "stanu zagrożenia".

jasisz commented 4 years ago

@potiuk Otworzyłem zatem https://github.com/ProteGO-app/specs/issues/84