jasisz
commented
4 years ago 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.
potiuk
SeraMoon
matsobdev
kwiszowaty
KonoromiHimaries
KoderFPV
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 https://github.com/ProteGO-Safe/specs/pull/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).