search

ProteGO-Safe / specs

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

Zmiana modelu działania aplikacji na anonimowy i (być może) zdecentralizowany #34

Closed potiuk closed 4 years ago

potiuk commented 4 years ago

Aplikacja ProteGO w obecnym kształcie zbytnio narusza prywatność osób zdrowych. Umożliwia to deanonimizację informacji wysyłąnych na serwer. Jest to niezgodne na przykład z zaproponowaną specyfikacją https://www.pepp-pt.org/ (pod warunkiem że ta specyfikacja pozostanie wierna temu żeby była zachowana pełna anonimowość).

Nie ma żadnej potrzeby, żeby aplikacja wymagała podania i potwierdzenia numeru telefonu przy instalacji. Komunikacja z zagrożonymi osobami zdrowymi może być zrobiona na poziomie aplikacji - niepotrzebny jest numer telefonu (i żaden inny identyfikator pozwalający zidentyfikować zarówno osobę zdrową jak i zdiagnozowaną).

Właśnie pojawił się protokół który opisuje jak to samo zrobić w wersji zdecentralizowanej i anonimowej: https://github.com/DP-3T/documents

Zamiast identyfikacji, osoba zdiagnozowoana powinna otrzymać kod (nazwany TAN_ID w specyfikacji https://www.pepp-pt.org/) który powinien zostać wpisany w celu wysłania (dalej anonimowej) swojej historii spotkań jeśli było by to potrzebne do analizy. Ten numer również nie powinien identyfikować osoby - również po diagnozie, powinien służyć jedynie do autoryzacji danych i obrony przed spamem.

Uwaga! Zaktualizowałem pierwotny opis -> odwołałem się początkowo do specyfikacji, która nie była bardzo precyzyjna, a w międzyczasie pojawił sie opis protokołu który doskonale opisuje założenia jak zrobić to dobrze - prywatnie i w sposób zdecentralizowany.

Aktualizacja 06.04.2020 - > Wydaje się że model anonimowy można utrzymać zachowując jednocześnie konieczność obowiązkowej rejestracji za pomocą numeru telefonu. Apel o to w #56 .

https://github.com/ProteGO-app/specs/issues/34#issuecomment-609676552

kierepka commented 4 years ago

Super! Czy pozostałe jakoś uda się też ustalić? Czy pozostałe też uda się dodać jako opcje (praca w tle jako opcja - tj "wyciągamy telefony")?

potiuk commented 4 years ago

Cieszę się bardzo @jakublipinski że to idzie w tę stronę i że MC dało się przekonać.

Będę na pewno uważnie obserwował to w którym kierunku idzie projekt.

Dodatkowo (tu informacja dla osób zainteresowanych tym wątkiem) będę też próbował zaangażować się w inicjatywę Szefa Eurpejskiego Urzędu Ochrony Danych osobowych - https://www.bbc.com/news/technology-52189551 i dam znać na pewno czy coś z tego wyniknie dla ProteGo. Było by bardzo dobrze sprawić żeby podobne rozwiązania były zrobione jednolicie w całej Europie z poszanowaniem prywatności i danych osobowych.

ProteGO jest na bardzo zaawansowanym etapie rozwoju - jeszcze lepiej by było gdyby udało się - ProteGo przedstawić jako referencyjną (a może nawet bazową) implementację dla innych państw. Bardzo chętnie o to powalczę i na pewno to że kwestie prywatności będą traktowane bardzo poważnie może w tym pomóc.

@jakublipinski -> najchętniej zrobiłbym to razem z Tobą.

jasisz commented 4 years ago

Na DP-3T pojawiło się ciekawe FAQ - https://github.com/DP-3T/documents/blob/master/FAQ.md Myślę, że warto iść "w tę stronę" jaką nakreślili, nawet jeżeli się do końca nie zgadzamy z niektórymi decyzjami.

potiuk commented 4 years ago

@jasisz -> zgadzam się . Kilka decyzji podjętych przez DP-3T jest bardzo ciekawych - na przykład Seed zamiast BT ids generowanych na serwerze. To jest bardzo ciekawe rozwiązanie, proste w implementacji i rozwiązujące bardzo dobrze kwestię skali/wydajności całego systemu na poziomie europejskim. Unika się konieczności częstego dystrybuowania unikalnych ephemeral IDs. Super rozwiązanie.

potiuk commented 4 years ago

No i to jest bardzo ciekawe:

P7: Why do you call your design "decentralized" while having a backend?

We call our design decentralized because there is not central point of trust for security and privacy. All critical operations: creating EphIDs and matching observations are done locally in each phone. The backend server is only needed to ensure availability. However, it does not maintain any secrets. Attackers do not gain anything by compromising the backend. All privacy-sensitive information is decentralized, and stored on individual’s phones.

potiuk commented 4 years ago

Zdecydowanie dobry kierunek

jasisz commented 4 years ago

@potiuk Nikt tu chyba nigdy nie proponował generowania ich na serwerze! Od początku rozumiałem to jako generowanie ich na telefonach. Główna kwestia co jest publikowane dla wszystkich, bo do wyboru były: seed, idki zarażonych, idki zagrożonych, identyfikatory spotkań. Oni postawili na seed, co znacząco ułatwia skalowanie, natomiast jest pewnym kompromisem. Ale zgadzam się - trzeba isć w tym kierunku.

potiuk commented 4 years ago

W obecnym rozwiązaniu ProteGo ID są generowane na serwerze @jasisz

jasisz commented 4 years ago

@potiuk Wiem, zwracałem na to uwagę m.in. tutaj https://github.com/ProteGO-app/specs/issues/34#issuecomment-609627412

jakublipinski commented 4 years ago

Zwróćcie uwagę, że jeśli ephemeral ids chorych będą wysyłane na telefony, to ktoś może zrobić narzędzie do deanonimizacji zakażonych np. przy pomocy kamerki spiętej ze skanerem Bluetooth. Zbierze pary beacon_id - zdjęcie osoby i będzie sprawdzał czy któreś z tych id nie okazało się należeć do chorego.

jasisz commented 4 years ago

@jakublipinski Tak będzie również, gdy będzie wysyłany seed, idki "potencjalnie" zarażonych (mogę co chwila go zmieniać w tym celu), albo klucze spotkań (to samo). To jest problem, który poruszyłem tam w https://github.com/DP-3T/documents/issues/13 a który w sumie jest już zasygnalizowany nawet w oryginalnej pracy. Ale ten problem występuje i w ProteGO (w obecnej postaci), chociaż w mniejszej skali: jeżeli wiem, że spotkałem jedną osobę, a dzwoni do mnia sanepid -> wiem że ta osoba była zarażona.

potiuk commented 4 years ago

Ciekawy problem faktycznie. skometnowałem to - wydaje mi się że faktycznie w pełni zdecdentralizowany system może to rozwiązać przez kolizje jak pisałeś @jasisz ale jeśli jednak zdecydujemy się na centralizację (w pełni anonimowych i tylko dotyczących chorych) danych na serwerze, to jest to problem do rozwiązania przez odpytywanie tylko o swój Seed.

jakublipinski commented 4 years ago

W świetle tego, że główny, tytułowy cel tego issue został osiągnięty (https://github.com/ProteGO-app/specs/issues/34#issuecomment-609993832) proponuję powyciągać z niego najciekawsze wątki do ew. twórczego rozwinięcia do osobnych issues, a ten zamknąć.

potiuk commented 4 years ago

Myślę, że dopóki nie jest to zaimplementowane, to warto mieć ten wątek otwarty. Świetnie że MC się zgadza na opcjonalny numer, ale z zamkniędiem może warto by było poczekać aż będzie to zaimplementowane - wtedy można by nawet w PR-ze umieścić referencję do tego issue i napisać "Closes #..." wtedy issue samo się zamknie.

potiuk commented 4 years ago

Ale faktycznie. Skoro już w założeniach aplikacji jest napisane b486959, 694cc66, 336a7bb że ma być anonimowość na początku, to dobrze i można zamknąć. Zawsze można otworzyć albo zrobić nowe issue w przyszłości jeśli by były wątpliwości.

KoderFPV commented 4 years ago

Ale faktycznie. Skoro już w założeniach aplikacji jest napisane b486959, 694cc66, 336a7bb że ma być anonimowość na początku, to dobrze i można zamknąć. Zawsze można otworzyć albo zrobić nowe issue w przyszłości jeśli by były wątpliwości.

Dobra robota! Bo wielu wielu postach wreszcie dopiąłeś swego. Gratuluje i pozdrawiam

jasisz commented 4 years ago

@Tarvald Jedyna zmiana, to że system nie wymaga teraz podania numeru telefonu. Poza tym nic się nie zmieniło, dalej jest scentralizowany.

potiuk commented 4 years ago

Od początku (praktycznie) a w każdym razie od momentu w który poczytałem o obu systemach, decentralizacja nie była (dla mnie) warunkiem koniecznym. Natomiast anonimizacja tak. Z tego względu jak dla mnie (jeśli #83 będzie zrobione tak by informować użytkownika o utracie anonimowości - dla mnie jest to akceptowalne).

jasisz commented 4 years ago

Ciekawostka - w DP-3T dodano alternatywne rozwiązanie, w którym publikowane są Cuckoo filters na EphIDs zarażonych, a nie klucze prywatne zarażonych - https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf

potiuk commented 4 years ago

@jasisz -> myślę że pomysł jest całkiem niezły i na pewno warty ekslporacji I być może wdrożenia w przyszłych wersjach aplikacji - najlepsze w tym rozwiązaniu jest to, że dane w systemie mogą być przechowywyane przez max. 2 tygodnie - więc przyszłe wersje aplikacji mogą dość swobodnie zmieniać zarówno algorytmy wysyłania danych, optymalizować etc.

Może warto żebyś założył issue w tym temacie? A może nawet warto by było spróbować to zaimplementować?

jasisz commented 4 years ago

@potiuk Jako użytkownik aplikacji nie mam żadnej gwarancji jak długo te dane są przechowywane na serwerze. Jeżeli natomiast mogą być użyte do black boxowych algorytmów - zakładam że mogą być przechowywane już zawsze.

potiuk commented 4 years ago

Zgadza się - nie ma. Ale to zupełnie inna kwestia kto i jak będzie o to dbał. Mam nadzieję, że będzie to kwestią publicznej debaty i ustanowienia jakiejś formy kontroli nad tym jak by to miało być docelowo. Po zmianie założeń że numer jest obowiązkowy i jasą na ten temat informacją - jak zaproponowałem w #83 (według mojej, osobistej opinii) system może startować (tak żeby był jak najszybciej przydatny) a dalsze zmiany można wprowadzać w trakcie działania.

To o czym napisałem to tylko informacja że jest możliwa zmianie działania aplikacji już po jej opublikowaniu. I wszelkie pomysły na to będą na pewno rozpatrzone przez zespół ją budujący.

Możesz mieć na ten temat oczywiście inną opinię. Podobnie jak ja mam swoja. Obawiam się że trudno tutaj o jakąś prawdę absolutną i jedynie słuszne rozwiązanie.

jasisz commented 4 years ago

@potiuk Trudno mi zrozumieć co się zmieniło od czasu, kiedy pisałeś:

Nie chodzi o technicznie lepsze rozwiązania, ale o zachowanie prywatności. Tak naprawdę ta aplikacja w Polsce będzie potrzebna za 5-10 tygodni bo tyle potrwa wypłaszczanie wzrostu. Według mnie lepiej to zrobić dobrze niż szybko i naruszając prywatność,

Przytua commented 4 years ago

Dalej pozostaje problem braku zaufania do oznaczania ludzi "na czerwono" (ta część backendu nie jest otwarta i nie ma też pewności, czy ktoś nie będzie sobie oznaczał ludzi ręcznie). W obecnej sytuacji nie ma możliwości zweryfikowania, czy użytkownik został oznaczony na podstawie "prawdziwego" spotkania.

potiuk commented 4 years ago

@jasisz @Przytua -> Bardzo dużo się zmieniło. Jak dla mnie to jest mocno inny świat.

Zmieniła się anonimowość (pod warunkiem dobrego zaadresowania #83). I z tego wynika, że numer telefonu nie jest "kluczem" rozwiązania. Dzięki temu nie można argumentować "ale już nie możemy tego zmienić bo numer telefonu jest "kluczem głównym". W obecnym rozwiązaniu wiadomo że bez numeru wszystko będzie działać - i to jest super.

Im szybciej zacznie sie zbierać dane, tym lepsze wypracuje się rozwiązanie. To że możliwe jest anonimowe działenie i nie ma potrzeby używania numeru telefonu jako klucza identyfikującego instalację gwarantuje według mnie że rozwiązanie jest otwarte na przetwarzanie danych anonimowo.

Poza tym pierwsze dwa tygodnie od zainstalowania wszyscy mają status "pomaranńczowy" - niezależnie od tego co będzie na serwerze - i w międzyczasie można dyskutować nad potencjalnymi rozwiązaniami algorytmów.

tomekziel commented 4 years ago

"_Poza tym pierwsze dwa tygodnie od zainstalowania wszyscy mają status "pomaranńczowy" - niezależnie od tego co będzie na serwerze - i w międzyczasie można dyskutować nad potencjalnymi rozwiązaniami algorytmów." - błąd; przez pierwsze dwa tygodnie nie będzie nikogo zielonego. Czerwoni mogą być już następego dnia

potiuk commented 4 years ago

Przeczytaj proszę uważnie @tomekziel : za https://github.com/ProteGO-app/specs/

Pomarańczowy - nie minęły jeszcze 2 tygodnie od zainstalowania aplikacji, nie mamy wystarczająco dużo danych aby określić status. Należy zachować ostrożność.

jasisz commented 4 years ago

Ktoś może być zdiagnozowany dzień po instalacji i stanie się czerwony.

potiuk commented 4 years ago

Ale to nie przychodzi z serwera tylko wynika z diagnozy konkretnej osoby zidentyfikowanej podczas diagnozy. To nie jest robione przez algorytm.

jasisz commented 4 years ago

Wszystkie statusy przychodzą z serwera. W kodzie nie ma nigdzie oznaczania osoby jako czerwonej. Nie ma nawet walidacji czy dany przez nią proof jest poprawny, bo ta też jest rozumiem "ręczna". Kontakty tej osoby według specyfikacji też mają status zmieniony na czerwony, a to robi już niewidzialny algorytm. Sugerujesz że przez te pierwsze tygodnie aplikacja nie będzie robiła nic opróćz zbierania danych, nawet jeżeli ktos bedzie zarażony?

niutech commented 4 years ago

@potiuk Warto przeczytać również głos krytyczny nt. PEPP-PT napisany przez ITO i proponowany w zamian alternatywny protokół TCN (następca STRICT) bardziej dbający o prywatność. Koalicja TCN ma już 10 członków, może warto doń dołączyć?

tomekziel commented 4 years ago

Tak z ciekawości, bo nie znalazłem tych informacji nigdzie indziej - kto podejmuje decyzje projektowe i jaką rolę pełni MC? Z wypowiedzi ministra wynika model "my robimy z udziałem społeczności", ale już w GitHubie tak to nie wygląda.

jasisz commented 4 years ago

@tomekziel Wygląda na to, że Polidea, w osobach @jakublipinski i @potiuk - trudno natomiast mieć pewność, bo członkowie ProteGO na GitHubie nie są publiczni.

potiuk commented 4 years ago

Nie do końca. Ja nie jestem w projekcie, znam go dobrze, ale w większości jednak tylko komentuję i zwracam uwagę na pewne problemy - ale nie podejmuję decyzji w projekcie. Decyzje są podejmowane zgodnie z zapisem tu: https://github.com/ProteGO-app/specs/blob/master/CONTRIBUTING.md#kto-podejmuje-decyzje-w-tym-projekcie

tomekziel commented 4 years ago

Decyzje są podejmowane

"Są podejmowane" ale nie wiadomo, przez kogo. Łącznik słucha ministerstwa i podejmuje decyzje? Ministerstwo podejmuje i przekazuje ją łącznikowi? Decydują ojcowie założyciele i informują ministerstwo?

potiuk commented 4 years ago

Myślę że bardzo ważne, rozsądnie podane i wyważone argumenty @cloudyfuel. Z wieloma się zgadzam. Tak jak pisałem w #83 - anonimowość jest faktycznie bardzo zależna od sposoby komunikacji (dark pattern o którym wspomniałeś) i mam nadzieję że będzie to rozwiązane dobrze. Faktycznie przekonanie do nie-obowiązkowości numeru to duża sprawa - tak jak to już wielokrotnie pisałem.

Co do social scoring mam trochę inną opinię. Social scoring to jednak co innego, ale gdyby system był faktycznie anonimowy to część "fizyczna" statusu umożliwiająca obecność w miejscach które wiążą się z dużymi ryzykami, to może być całkiem ważny element walki z pandemiią. Ja to porównuję bardziej z tym w jako sposób wchodzi się na stadiony - osoby z zakazem stadionowym nie wchodzą. Oczywiście to zupełnie co innego, ale wydaje mi się że bycie osobą zagrożoną (jeśli nie da się tym indywidualnie manipulować) powinno skutkować jakąś formą ograniczeń. Cała idea tej aplikacji polega na tym że te ograniczenia nie mają dotyczyć wszystkich (tak jak teraz) tylko najbardziej pawdopodobnej grupy osób.

Co do szybkości wypuszczenia - fakt, super szybko. Ale też w tym systemie jest wiele niewiadomych - i adopcja na pewno nie będzie szybka. Dane też "ważne" są 2 tygodnie więc to co będzie za 2 tygodnie może być czymś innym niż teraz. I jak opisano w . Dlatego uważam że (jeśli anonimowość jest zachowana) - im szybciej zacznie się analizować faktyczne działanie systemu - tym lepiej.

A co do decyzji @tomekziel -> :shrug: . Nic więcej niestety nie wiem.

tajchert commented 4 years ago

https://www.apple.com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/ Na razie brak konkretów i na pewno z tego powodu bym nie wstrzymywał prac nad ProteGO ale na pewno warto mieć mocno na oku. Bo jeśli to ma być rozwiązanie na po etapie "lockdown" to musi być międzynarodowe (lub opart o wspólny standard).

jasisz commented 4 years ago

Szczegóły są pod https://www.apple.com/covid19/contacttracing/ - wgłębiam się.

jasisz commented 4 years ago

Nic odkrywczego - z grubsza to samo co DP-3T z tą różnicą, że są pośrednie klucze "dzienne".

potiuk commented 4 years ago

Przeczytałem już. W pełni zdecentralizowany algorytm garściami czerpiący z wszystkich dyskusji (Seed Tracking Key + generowany Daily Tracking Key + generowane BT identifiers co 15 minut). Żadne dane zdrowych ludzi nie trzymane na serwerze. Daily Keys żeby zminimalizować wymianę danych. Faktycznie nic odkrywczego - ale za to zebranie wszystkiego co najlepsze w jednym miejscu. Dodatkowo - algorytm matchowania chorych ludzi na telefonie. API dla każdego kraju który chciałby zaimplementować swoje apki - API w pełni anonimowe - dla każdego kraju ale również dla Google'a i Apple'a.

Jedni drugim będą patrzeć na ręce i wszyscy im też będą patrzeć. Plus docelowo integracja na poziomie OS (na razie nie) która zapewni niskie zużycie baterii, brak usypiania etc.

Pozamiatane.

tajchert commented 4 years ago

@potiuk Nie mogę znaleźć, ale jak widzę tutaj użytkownik sam oznacza się jako "chory" i decyduje się na udostępnienie danych? W sensie zastanawiam się czy system nie jest podatny na false positive bez weryfikacji zgłoszeń chorych (osoba zdrowa oznaczy się jako chora "dla żartu").

potiuk commented 4 years ago

są klucze dostarczane przez "medical Authorities" - żeby wysłać takie dane trzeba te klucze dostarczyć. Standard w tego typu rozwiązaniach.

SeraMoon commented 4 years ago

Wydaje mi się, że jednym z rozwiązań zapewniających jednocześnie prywatność, jak i zachowujące pragmatyzm, jest wysyłanie numeru telefonu do GIS w momencie, gdy właściciel staje się osobą potencjalnie zarażoną. (Z możliwością opt-out w ustawieniach aplikacji.)

A może, jak przystało na aplikację, która ma zapewnić prywatność i spowodować zaufanie obywateli nic nie powinna wysyłać sama tylko poprosić użytkownika o odbycie dobrowolnej kwarantanny i poprosić o skontaktowanie się z GIS / sanepidem (wyświetlając potrzebny numer / dane kontaktowe)?

Zamordyzmem nic nie osiągniecie ponieważ ludzie mają jeszcze możliwość żyć bez smartfonów albo bez tej aplikacji. Sama będę nawływała do pozbycia się telefonów jeżeli będzie zamordyzm typu "mususz zainstalować jeżeli masz androida lub iOS" a w przypadku zamordyzmu typu "rejestracja na numer telefonu", "wyślemy twój numer instytucji X" będę odradzała używanie tego g...a. Tak g...a, bo tam można nazwać w tym PiSowskim kraju tego typu działania.

potiuk commented 4 years ago

A może, jak przystało na aplikację, która ma zapewnić prywatność i spowodować zaufanie obywateli nic nie powinna wysyłać sama tylko poprosić użytkownika o odbycie dobrowolnej kwarantanny i poprosić o skontaktowanie się z GIS / sanepidem (wyświetlając potrzebny numer / dane kontaktowe)?

No właśnie tak to miało być dla osób które numeru nie podadzą (numer/dane kontaktowe). A nawet powiem więcej - zmiana statusu na "zagrożony" powinna stanowić przepustkę do natychmiastowych i darmowych testów (pisałem o tym w #54). Ale jeśli podanie numeru miałoby być jako opt-in, to myślę że ta opcja z wysyłaniem numeru jest bardzo ok - zwłaszcza w przypadku osób starszych. Wyobrażam sobie, że wielu osobom (na przykład mojej teściowej) wnuczek czy syn mógłby zainstalować aplikację i podać numer po instalacji, żeby w razie czego to GIS mógł zadzwonić i porozmawiać z taką osobą/przekonać ją do kontaktu. Powtarzam - jeśli tylko nie byłby to wspomniany "dark pattern" który nachalnie "wymuszałby" podawanie numeru.

Obecne API Google/Apple zostawia swobodę w tym jak kontakt "Health Authorities" z osobami instalującymi aplikację miałby wyglądać - i dobrze, bo w różnych krajach może być różnie. Jednocześnie uniemożliwia łączenie nawet podanego numeru z konkretnymi BT ID (do tego aplikacja nie ma dostępu przez API). Więc zaimplementowanie tego "opt-in" wygląda na całkiem sensowne rozwiązanie, a nie zamordyzm.