Możliwość de-anonimizacji danych i odtworzenia grafu kontaktów #123
Comments
potiuk
changed the title
|
Cieszę się, że w końcu jest jasne, że "zdecentralizowany" w tym przypadku nie znaczy "pozbawiony serwera", a określa tylko miejsce zapadania kluczowych decyzji: o tym "czy miałem kontakt z zakażonym", oraz jakim beaconem będę się ogłaszał. Nie widzę opcji (albo jeszcze sie na taką nie natknąłem) na scentralizowany system do śledzenia kontaktów, który zapewniałby tak dużą anonimowość jak nawet taki najprostszy system zdecentralizowany, o którym pisaliśmy tu od samego początku. |
Masz absolutną rację. Na szczęście mogliśmy o tym porozmawiać i wspólnie dojść do tego że faktycznie nawet bez numeru telefonu nie ma możlwości faktycznego zanonimizowania danych osobowych w tym przypadku. Teraz widzę to bardzo jasno. Lektura ekspertów z całego świata (dużo na ten temat czytam) bardzo pomogła mi to zrozumieć. |
|
Jak kwestia komunikowania się aplikacji przez Tora? Protokół Tora gwarantuje zanonimizowanie IP i tylko na prawdę nieproporcjonalnie mocne śledzenie korelacji umożliwiłoby deanonimizację. Byłoby to zgodne z (E)RODO. |
|
Czyli czekać na wersję, która obsługuje tylko i wyłącznie API GiA, nie wysyła nigdzie danych z dziennika zdrowia (lub go wcale nie posiada), łączy się z internetem tylko w przypadkach opisanych w dokumentacji GiA. A najlepiej czekać na w pełni natywną implementację od Google i Apple. |
|
Tak. To w tej chwili chyba jedyne wyjście. dodam że docelowo API G+A będzie miało (jeśli ktoś to włączy) funkcję logowania kontatków bez konieczności instalacji ProteGO Safe. Czyli w szczególności cała ta akcja z namawianiem do instalacji aplikacji nie ma sensu bo nie będzie do niczego potrzebna. |
|
Może Google i/lub Apple będzie szybsze w implementacji swojego rozwiązania, niż krajowe aplikacje. |
Tak ma być, ale chyba nie do końca. G+A dostarczy framework do zbierania kontaktów. Natomiast poszczególne kraje będą odpowiedzialne za dointegrowanie rozwiązania, korzystając z API od G+A, które to "zaznaczy" człowieka z pozytywnym testem (sprawdzi go w swojej bazie czy rzeczywiście wynik był pozytywny) i zapisze klucze chorego do rejestru z którego będą korzystać pozostali.
Może i tak, G+A zapowiedziało release na połowę maja. Dodać 2 tygodnie na integrację krajową i na początku czerwca może zobaczymy coś działającego. |
Dokładnie tak jak piszesz. Czyli aplikację ProteGO trzeba będzie zainstalować dopiero wtedy, kiedy będziesz zdiagnozowany, wysłać dane i będzie ją można od razu odinstalować. W tej chwili rząd próbuje wprowadzić w błąd wszystkich stawiając znak równości między a) rozwiązanie musi być powszchne a b) wszyscy powinni zainstalować aplikację. To jest celowe wprowadzanie w błąd. Instalowanie aplikacji będzie niepotrzebne do osiągnięcia powszechności. Osiągnięcie powszechności będzie możliwe przez Opt-In w systemie operacyjnym. Dlatego też uważam że krytykowanie obecnego rozwiązania ProteGo jest jak najbardziej moralnie słuszne. Nie dość, że nie zabijamy całej inicjatywy (bo instalowanie ProteGO nie jest warunkiem powszechności) to jeszcze podbijamy publiczną dyskusję na temat "contact tracing". Dla wielu ludzi informacja "nie musisz instalować tej rządowej aplikacji żeby wejśc w system" będzie bardzo dobrym sygnałem.
To trochę nieaktualne informacje. G+A przyspieszyło release i zespoły które pracują nad podobnymi aplikacjami już przedwczoraj dostały możliwość używania tego API (m.in, twórcy ProtegoSafe również - pisał o tym @MateuszRomanow ). Według mnie Twórcy aplikacji powinni rzucić wszystko inne (w szczególności QR-cody które według mnie #124 jest rozwiązaniem mocno nieprzemyślanym i bardzo narażonym na ataki). To jedyne sensowne rozwiązanie, zgodne z wcześniejszymi deklaracjami. I nie ma już uzasadnienia że "nie wiadomo czy będzie" które jeszcze do niedawna słyszałem od @MateuszRomanow . Wtedy też usłyszałem "jak będzie, to zaczniemy używać", @MateuszRomanow - pytanie kiedy będzie pierwsza wersja aplikacji oparta o G+A? Naprawdę chciałbym żeby choć raz w tym projekcie wcześniejsze deklaracje były realizowane. Na razie wygląda to tak (to tylko przykład z wczoraj):
Ja jestem zwolennikiem uczenia się i dostosowywania swoich działań do sytuacji. W innych projektach które znam działam zupełnie inaczej, ale tu - można już powiedzieć z doświadczenia - trzeba zmienić sposób działąnia. Wygląda na to że w tym projekcie nie możemy polegać na deklaracjach i punkt 3) jest niezbędnym krokiem w tym procesie, i przy każdej przyszłej zmianie i nowej funkcji szum medialny podnoszony przez niezależnych programistów będzie potrzebny. Na szczęście ja (i inni z tego co widzę) niezależni programiści jesteśmy zdeterminowani, żeby tak właśnie było. Mamy na szczęście (trochę dzięki COVID-19) czas żeby ów - 3) ewidentnie niezbędny - etap podejmowania decyzji następował. Szkoda że robimy to w czasie prywatnym, ale cóż, trudno, świetnie. Wolę to, niż 7-cyfrowy kontrakt na aplikację przez który godzę się na robienie rzeczy niemoralnych i nielegalnych i zasłaniam się "no ale taki mam kontrakt". Przypomina mi się kilka filmów w których pada "no ale ja tylko wykonuję swoją pracę". Często w tych filmach zaraz potem słychać strzał. Na szczęście nie wszystkim wizja zarobienia pieniędzy przesłania to czy robią coś słusznego, czy nie. |
|
Zainteresowane osoby zapraszam do przeczytania wywiadu który zrobił ze mną Artur Kurasiński w którym postarałem się podsumować, gdzie jesteśmy obecnie z aplikacją: J. |
Rzeczywiście, wydali wcześniej niż obiecali. Co prawda na razie to wersja beta, ale podejrzewam, że API na tyle stabilne, że można już śmiało zacząć implementację końcówki "rządowej". |
Prawda jest taka, że... jesteśmy w punkcie wyjścia ;) BlueTrace jest właściwie tożsamy z tym pierwotnym rozwiązaniem, które było tak krytykowane w #34, #54 i ciągle otwartym #84 Teraz jest tylko tyle gorzej, że kod serwera nie jest udostępniony, a o tyle lepiej, że aplikacja zdaje się nie wysyła zbędnych danych jak w #85 |
@potiuk nie jest jedyne, można to zrobić nie uzależniając się od G+A https://github.com/ProteGO-Safe/specs/issues/127#issuecomment-623019204 |
Jeśli mówisz o tym co rząd USA robi z reklamami - to jest zupełnie co innego - nie contact tracing. To rozwiązanie pozwala na stwierdzenie że w jednym miejscu pojawiło się dużo osób i że trzeba tam na przykład wysłać policję żeby sprawdzić czy to zgromadzenia nie narusza "social distancing". A - oczywiście - javascriptowe i w pełni lokalne implementacja algorytmu oceniająca zdrowie - jak najbardziej. To że ta część wysyła cokolwiek na serwer to samo to jest totalną dyskfalifikacją. |
|
Z powodu dłuższej nieaktywności w tym wątku, Jeżeli ktoś ma coś przeciwko to niech da znać, lub założy wątek zgodny z obecnymi założeniami |
Describe the bug
W związku z (niestety zamkniętą już) dyskusją w #116 zgłaszam poważny błąd w aplikacji. Niezgodnie ze specyfikacją opisaną w https://github.com/ProteGO-Safe/specs/blob/master/README.md#anonimowo%C5%9B%C4%87-i-bezpiecze%C5%84stwo oraz https://github.com/ProteGO-Safe/specs/blob/master/FAQ.md
Albo specyfikacja jest błędna, albo popełłniono błąd przy wyborze i implementacji protokołu. Jak szerko dyskutowano w #116 aplikacja pozwala na de-anonimizację danych osób które nie zostały zdiagnozowane jako chore dzięki ich adresowi IP.
Posiłkuję się dyskusjami które toczą się na temat - bardzo podobnie skonstruowanego protokołu ROBERT. Protokół był wspierany i "propagowany" do niedawna przez Francję i Niemcy, ale Niemcy się ostatnio z tego wycofały rakiem (https://techcrunch.com/2020/04/27/germany-ditches-centralized-approach-to-app-for-covid-19-contacts-tracing/) na rzecz protokołu zdecentralizowaneg DP-3T który będzie najprawdopodobniej tożsamy z tym zaproponowanym przez G+A.
Jak mówi powyższy artykuł - eksperci od privacy wyraźnie opowiadają się za zdecentralizowanym podejściem, (Niemcy już też) a lektura tego artykułu poniżej uświadomiła mi dlaczego:
https://techcrunch.com/2020/04/20/frances-inria-and-germanys-fraunhofer-detail-their-robert-contact-tracing-protocol/
Jeśli chodzi o interakcję z serwerem, obecne system działa następująco (aplikacja każdej z osób w której działa opcja z włączonym Bluetooth):
Aplikacja przy instalacji prosi serwer o unikalne UID.
Aplikacja (w regularnych odstępach czasu prosi serwer o unikalne TempID:
Zgodnie z założeniami, w przyszłej werrsji aplikacji (pewnie 3.2) będzie też dodatkowa komunikacja w regularnych odstępach czasu: Wysyłam [UID] => Analiza na serwerze => Dostaję [STATUS= OK/ZGŁOŚ SIE NA BADANIA]
Jako że nie mamy dostępu do kodu strony serwerowej rozwiązania (w każdym razie nie byłem w stanie tego znależć - proszę o przekierowanie w razie czego Twórców aplilkacji - system używa Cloud Functions do wywołań API. Wbrew wcześniejszym informacjom wydaje się że nie jest do tego używany system CloudFlare ale nie jest to istorne w zagadnieniu. Jak opisano w https://stackoverflow.com/questions/48032909/how-to-get-client-ip-address-in-a-firebase-cloud-function umożliwa to funkcjom aplikacji uruchamianym w Cloud Functions uzyskanie tymczasowego adresu IP telefonu łączącego się z serwerem.
Jak szeroko opisano w #116 w tym scenaruszu Cloud Functions w systemie mają możliwość połączenie TempID, UID, czasu oraz tymczasowego adresu IP użytkownika w taki sposób, żeby możliwa była de-anonimizacja tych danych - za pomocą logów od operatorów dostępnych dla strony rządowej. Strona rządowa już dziś takie logi może uzyskać na podstawie Ustawa z 15 stycznia 2016 r. o zmianie ustawy o Policji oraz niektórych innych ustaw (Dz. U. 2016, poz. 147). Istnieje też dalsza możliwość połączenia tego z danymi lokalizacyjnymi osób chorych uzyskanych przez rząd na podstawie zapisów w Tarczy 2.0 https://www.rpo.gov.pl/pl/content/koronawirus-tarcza-antykryzysowa-2-0-uwagi-rpo-dla-senatu (pkt "Prawo telekomunikacyjne i pocztowe" podpunkt A.1).
Ze względu na to że na serwerze przechowywana jest historia kontaktów (również z osobami nie zdiagnozowanymi jako chore) osób chorych, umożliwia to nie tylko de-anonimizację wszystkich osób które kiedykolwiek znalazły się w pobliżu osób chorych ale również tzw. "grafu połączeń" - czyli tego kto, kiedy z kim i gdzie przebywał. Jest to nie tylko niezgodne z wytycznymi Europejskiej Rady Ochrony Danych Osobowych na które specyfikacja się powołuje https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf
Możliwa deanonimizacja danych jest ewidentnym błęðem w stosunku do specyfikacji aplikacji w szczególności:
Wprowadzenie https://github.com/ProteGO-Safe/specs#wprowadzenie - mowa jest tam o anonimizacji (a nie pseudonimizacji) danych oraz zgodności z wytycznymi Europejskiej Rady Ochrony Danych Osobowych
Anonimowość i bezpieczeństwo:
https://github.com/ProteGO-Safe/specs#anonimowo%C5%9B%C4%87-i-bezpiecze%C5%84stwo pkt 2. Cytat "Dane wprowadzane do ProteGO Safe umożliwiają zachowanie anonimowości użytkowników"
Sformułowania, które tam padają mówią o anonimowości danych, podczas gdy w scenariuszu powyżej dane nie są anonimowe tylko pseudonimizowane, gdyź moźnsa dokonać ich de-anonimizacji.
Specyfikacja powinna być poprawiona, albo projekt aplikacji powinien poprawnie specyfikację implementować - implementując faktyczną anonimizację danych.
Proponowane poprawki w specyfikacji na licencji Public Domain zostały zaproponowane w #118
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Additional context
Dodatkowy kontekst i dyskusja w #1116
Proponowane rozwiązanie
Rozwiązanie powinno implementować anonimowy protokół zdecentralizowany taki jak https://github.com/DP-3T/documents a najpewniek (najprawdopodobnie tożsamy z DP3-T) https://www.apple.com/covid19/contacttracing/ . Obecna funkcjonalność BT powinna być natychmiast wyłączona żeby nie wprowadzać ludzi w błąd oraz żeby nie eskalować niechęci do instalacji aplikacji dodatkowo wzmocnionnej działaniami rządu (https://www.gov.pl/web/rozwoj/centra-handlowe oraz https://retailnet.pl/2020/04/29/28015-utrzymany-zakaz-dzialalnosci-kin-wysp-handlowych-i-klubow-fintness/ jak opisane w #119. Działania te wprowadzają dyskryminację osób które aplikacji nie mają (co również jest niezgodne z wytycznymi Europejskiej Rady Ochrony Danych Osobowych).
The text was updated successfully, but these errors were encountered: