Closed potiuk closed 4 years ago
@potiuk odpowiadam(y) na te dwa pytania ps kończymy duży update w readme, niestety jak ma to być zrobione dobrze to to wymaga czasu. Od naszej wczorajszej rozmowy do teraz cały czas jest to w procesie. Publikacja soon.
- Czy adres IP osoby zdrowej jest dostępny w systemach serwerowych ProteGO-Safe podczas odpytywania o status osoby zdrowej
odp.: Nie. Status osoby w niskiej grupie ryzyka wynika wyłącznie z testu samooceny stanu zdrowia i jest anonimowy.
Ważne: nie ma czegoś takiego jak status osoby zdrowej. Nikt nie jest zdrowy. Użytkownik może być w “Niskiej Grupie Ryzyka”. Aplikacja nigdy nie powie “jesteś zdrowy”.
- Czy (zakładając że rząd ma dostęp do danych łączących IP i konkretne osoby), możliwe jest odworzenie interakcji osób chorych z konkretnymi nie-anonimowymi osobami (w skrócie czy technicznie możliwa jest de-anonimizacja kontaktów osób zdrowych z osobami zdiagnozowanymi jako chore)
odp.: Kontakty ze stroną https://safesafe.app są chronione przez system Cloudflare i nawet operatorzy nie mają możliwości wygenerowania listy adresów IP które korzystały z usługi. Gdyby (hipoteza!) nawet do tego doszło z takiej informacji nie wynika jakim TempID posługuje się dany użytkownik. Dodatkowo aplikacja web korzysta z proxy co pozwala na anonimizację zapytań do API firmy Infermedica. Aplikacje mobilne również korzystają wewnętrznie z powyższego adresu i zyskują analogiczne gwarancje. W aplikacji nie występują “nie-anonimowe” osoby. Aplikacja pozwala na wysyłanie wiadomości ale wyłącznie do anonimowych TempID.
OK. Wyjaśnie o co chodzi:
"Osoba zdrowa" - tu mam namyśli że nie zdiagnozowana jako chora. Zakładając penetrację aplikacji na poziomie 30 milionów i przy (na przykład) 100.000 osób chorych jednocześnie - chodzi mi o 29.900.000 użytkowników aplikacji. Z tego jak rozumiem (nie wiem bo nie ma opisu) ma działać obecny protokół telefon tej osoby co jakiś czas wysyła na serwer (za pomocą protokołu HTTPS) zapytanie skonstruowane tak:
Aktualizacja. Wczytuję się w specyfikację i jest odrobinę inaczej niż początkowo zakładałem, ale z tym samym efektem:
1) Dostaję unikalne UID od serwera.
Te żądania są wysyłane (jak często? zakładam że np. raz dziennie do serwera https://safesafe.app. Jak w każdym systemie (a pisałem takich wiele i używałem również Cloudflare - jest to mój ulubiony front do aplikacji webowych) serwer który dostaje takie żądania, dostaje również IP z którego nastąpiło połączenie. W każdym serwerze, który kiedykolwiek pisałe, ten adres IP jest dostępny dla twórców aplikacji. Włączenie tego to jedynie przestawienie flagi w konfiguracji CloudFlare. Jak to zrobić jest opsane tu: https://support.cloudflare.com/hc/en-us/articles/206776727-What-is-True-Client-IP- . Węc niestety mijasz się z prawdą że nie ma takiej możliwości. Przy włączonej tek opcji adres IP jest przysyłany do serwera razem z listą TempID i może być zapisane w bazie.
Pytanie 1. Czy jest możliwe że serwer dostanie True IP razem informacją o liście TempID? Nie ptyam czy jest możliwe teraz, ale czy w przyszłości jest możlwe że tak się stanie bez wiedzy i zgody użytkowników ?
Dodatkowo aplikacja web korzysta z proxy co pozwala na anonimizację zapytań do API firmy Infermedica.
Pytanie 2. Czy proxy o którym mówisz pozwala na nie-anonimizację tych danych i czy (niezależnie od tego jak jest teraz) będzie możliwość włączenia nie-anonimizacji w przyszłości tak, żeby użytkownik o tym nie wiedział.
Pardzo proszę o proste odpowiedzi tak/nie (jeśli nie to dla czego). To naprawdę proste pytania na które można odpowiedzeć tak/nie.
Jeżeli cały ruch z aplikacji ma przechodzić przez cloudflare to dochodzą nam takie kwestie:
Jeśli prywatność użytkownika aplikacji nie ma byc tylko pustym hasłem to te dwa powyższe zagrożenia/ograniczenia są nieakceptowalne.
Dodałem moje sugestie do https://github.com/ProteGO-Safe/specs/pull/118 dotyczącego specyfikacji -dodałem tam poprawki które precyzują zapisy dotyczące prywatności (było wiele niedomówień i nieścisłości które moje poprawki naprawiają). Wszystkich, którym zależy na prawdziwości i kompletności tych specyfikacji zachęcam też do komentarzy i ewentualnie lajków.
- cloudflare jest znane z tego, że arbitralnie blokuje dostęp z adresów ip m.in węzłów TOR'a i VPN'ów. Zakladając, że w jakimś momencie używanie aplikacji zostanie przez rząd wymuszone, (choćby pośrednio przez promowanie jej jako "bramki" wejściowej), to oznacza naruszenie prawa użytkownika do prywatności nie tylko w tej aplikacji ale każdej innej skoro skoro warunkiem będzie używanie telefonu , który się przedstawia nie-anonimowym ip.
Bardzo dobra uwaga. Dodam w poprawkach że CloudFlare uniemożliwia prywatność adresu IP
Dodane: https://github.com/ProteGO-Safe/specs/pull/118/files#r417561210
Przecież pisałam postulaty tydzień temu, ale zignorowano i wątek zamknięto - postulowałam aby usługa ProteGO instalowała usługę Tor (torproject.org) i całą komunikację wykonywała przez Tora (proxy 127.0.0.1:9150 - nie zapomnijcie aby usługa proxy też działała w ten sposób - DNSPost i TransPort odpowiednio skonfigurowane). Rozwiązuje problem prywatności dotyczący IP. Jeżeli gdziekolwiek stoi Cloudflare itp. należy się tego pozbyć w imię prywatności użytkowników.
BTW. safesafe.app dobrze działa z Tor Browserem (poza zgłoszonymi drobnymi łatwonaprawialnymi błędami), więc możliwości są.
Oczywiście jeżeli poczas instalacji zostanie wykryty Tor - należy użytkownika poinstruować co musi dopisać do torrc.
Możliwość swodobnego dostępu cloudflare do całego odszyfrowanego ruchu z aplikacji jest również niezgodna z p.43 wytycznych EPDB ( https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf ) : "Any server involved in the contact tracing system must only collect the contact history or the pseudonymous identifiers of a user diagnosed as infected as the result of a proper assessment made by health authorities and of a voluntary action of the user.Alternately, the server must keep a list of pseudonymous identifiers of infected users or their contact history only for the time to inform potentially infected users of their exposure, and should not try to identify potentially infected users."
Pisząc o "blokadzie ip TOR/VPN" - wyraziłem się trochę nieprecyzyjnie bo formalnie to nie jest blokada tylko strona z captcha ale w przypadku api a nie strony dla endusera to defacto oznacza blokadę takich ip. ( https://blog.cloudflare.com/the-trouble-with-tor/ )
@miklobit popieram Cię całym sercem 👍 ❤️ . Dobrze, że ktokolwiek czyta zagraniczne polityki prywatności. W Polsce ich prawie nikt nie czyta. Prawda jest taka że serwer powinien być w Polsce bez żadnych pośredników i dostępny z Tora.
BTW. sorry za brak rysunków, ale jeden problem już zauważono - drugi to taki, że sam google może wysyłać któryś ID przez internet a więc powiązany z IP. Rysunków brak - skoro wątek zamknięto - nie poświęciłam temu czasu, jako że są prawdopodobnie zbędne, a nikt nie czyta zamkniętych chusteczek.
Kolejny raz apeluję o nie zadawanie pytań w formie oznajmującej. Taki styl przypomina mi brukowce i zaczynam się wtedy zastanawiać czy osoba, która to pisze ma na celu sianie chaosu czy faktycznie ma wątpliwości. Zakładając szczerość intencji postaram się przedstawić kilka faktów.
OpenTrace jest punktem wyjścia dla naszej architektury ale nie jest systemem kompletnym. Mam na myśli to, że nie wymaga istnienia publicznych stron internetowych z bieżącymi informacjami. Nie mówi nam jak zabezpieczyć system przed atakami internetowymi itd. Po długich analizach zdecydowaliśmy się na pominięcie w naszej implementacji sugerowanej w OpenTrace metody rejestracji z użyciem numeru telefonu. Owszem aplikacje ludzi zdrowych łączą się co jakiś czas z centralnym systemem - jednak nie po to aby otrzymać swój status osoby zdrowej! Robią to aby pobrać z serwera odpowiedni zapas unikatowych tymczasowych identyfikatorów. Wystarczy przeczytać teksty źródłowe
Cloudflare w naszym mniemaniu jest tutaj jednym z gwarantów poszanowania prawa do prywatności naszych użytkowników. Jest to firma, która nie boi się odmawiać wydania danych swoich klientów zainteresowanym rządom czy firmom. Jak widać z powyższych komentarzy część z obaw związanych z ich udziałem jako systemem bezpieczeństwa dla strony https://safesafe.app już się rozwiała, bo niestety były to tradycyjne zlepki plotek i interpretacji. Powtórzmy zatem - jeśli ktoś chce korzystać ze strony https://safesafe.app albo aplikacji która wewnętrznie pobiera dane z tego adresu za pomocą dodatkowych mechanizmów typu ToR to nie widzę technicznych przeszkód. Oczywiście korzystając z tego systemu trzeba się liczyć z tym, że możemy być przekierowani przez IP o delikatnie mówiąc marnej reputacji. Takie IP Cloudflare ma już podstawy zablokować, ba - tego od nich oczekujemy!
Jeżeli chcą państwo przekierowywać swój ruch przez serię bramek wykorzystywanych do ukrywania swojej tożsamości to proszę się liczyć z tym, że nie każda z tych bramek jest utrzymywana przez idealistów. Tak czy inaczej wybór użytkownika - nic nam do tego.
Sama strona internetowa jest pozbawiona integracji z systemem analitycznym. Na etapie testów korzystaliśmy z Google Analytics ale kody śledzące zostały ze strony usunięte a sam projekt GA usunięty. Tyle w temacie publicznej strony www i jej zabezpieczeń.
Wracając do funkcjonalności bluetooth i kontaktów z systemem centralnym naszej aplikacji. W tym przypadku ruch jest bezpośredni i Cloudflare nie dotyka tych danych nawet w tak zwanym przelocie. Jedynymi pośrednikami w takiej komunikacji stają się dostawcy internetu z usług których Państwo korzystacie. Następnie ruch przechodzi przez potencjalnie dziesiątki segmentów sieci internet obsługiwanych przez wielu różnych operatorów. Nikt nikomu nie ufa na 100% dlatego korzystamy z aktualnych wersji standardu TLS do szyfrowania ruchu. Rozumiem, że to może być abstrakcyjne ale Internet nie jest tworem jednolitym - w jego budowie i utrzymaniu uczestniczy tysiące podmiotów z rożnych krajów. Z naszych badań wynika, że większość użytkowników korzysta z domyślnych serwerów DNS konfigurowanych automatycznie przez dostawcę internetu. W praktyce to właśnie oni na dużą skalę sprzedają dane na temat naszych gustów i zwyczajów internetowych. Jeśli mogę coś zasugerować to proszę poszukać alternatywy bo ludzie, którym zależy na prywatności powinni od tego zacząć przykładowy link do fundacji mozilla.
Wracając do głównego tematu tego wątku czyli adresów IP. W większości przypadków urządzenia mobilne będą korzystały z adresów tymczasowych lub wręcz współdzielonych z innymi użytkownikami! To połączenie jest zestawiane przez operatora sieci komórkowej lub naszego dostawcę internetu w miarę potrzeb a adres który dostajemy może się zmieniać dowolnie często. Jak zatem autor wyobraża sobie nawet teoretyczną możliwość powiązania tożsamości użytkowników z ich danymi skoro same dane nie są transmitowane otwartym tekstem a adres IP jest zmienny?
Reasumując na świecie brakuje adresów IPv4 i nikt ich nie rozdaje za darmo. Nawet znając tymczasowy efemeryczny adres, który przypisał operator możemy co najwyżej poznać miasto lub województwo z którego ktoś się łączy. Na koniec jeszcze raz przypomnę, że samo namierzenie adresu IP nie wystarczy... trzeba jeszcze złamać szyfrowanie TLS... Powodzenia!
@bartosztomczak
Wracając do głównego tematu tego wątku czyli adresów IP. W większości przypadków urządzenia mobilne będą korzystały z adresów tymczasowych lub wręcz współdzielonych z innymi użytkownikami! To połączenie jest zestawiane przez operatora sieci komórkowej lub naszego dostawcę internetu w miarę potrzeb a adres który dostajemy może się zmieniać dowolnie często. Jak zatem autor wyobraża sobie nawet teoretyczną możliwość powiązania tożsamości użytkowników z ich danymi skoro same dane nie są transmitowane otwartym tekstem a adres IP jest zmienny?
Jako były administrator ISP, który NATował połączenia klientów: NAT nie jest problemem. Zapisywanie logów połączeń i łączenie ich z adresami za NATem jest bardzo prostym procesem, który pozwala zidentyfikować każde połączenie od źródła do celu. Potrafiliśmy odpowiadać ze 100% dokładnością na zapytania o udostępnienie danych w ramach prowadzonych postępowań mając tylko datę z dokładnością do sekundy. Oczywiście staje się to znacznie prostsze z IPv6, gdzie faktycznie NAT przestaje być potrzebny. Kilku operatorów obecnych na rynku świadczy usługi z wykorzystaniem IPv6, a:
$ ping6 safesafe.app
PING safesafe.app (2606:4700:20::681a:b94): 56 data bytes
64 bytes from 2606:4700:20::681a:b94: seq=0 ttl=58 time=19.395 ms
64 bytes from 2606:4700:20::681a:b94: seq=1 ttl=58 time=20.475 ms
64 bytes from 2606:4700:20::681a:b94: seq=2 ttl=58 time=19.213 ms
64 bytes from 2606:4700:20::681a:b94: seq=3 ttl=58 time=20.263 ms
Kolejny raz apeluję o nie zadawanie pytań w formie oznajmującej.
Nie bardzo rozumiem o czym mówisz? Które z poniższych pytań było w formie oznajmującej ? Pytam, po prostu czy scenariusz o którym piszę jest technicznie możliwy?
Pytanie 1. Czy jest możliwe że serwer dostanie True IP razem informacją o liście TempID? Nie ptyam czy jest możliwe teraz, ale czy w przyszłości jest możlwe że tak się stanie bez wiedzy i zgody użytkowników ?
Pytanie 2. Czy proxy o którym mówisz pozwala na nie-anonimizację tych danych i czy (niezależnie od tego jak jest teraz) będzie możliwość włączenia nie-anonimizacji w przyszłości tak, żeby użytkownik o tym nie wiedział.
Owszem aplikacje ludzi zdrowych łączą się co jakiś czas z centralnym systemem - jednak nie po to aby otrzymać swój status osoby zdrowej! Robią to aby pobrać z serwera odpowiedni zapas unikatowych tymczasowych identyfikatorów. Wystarczy przeczytać teksty źródłowe
Tak. Wiem że tak jest teraz. Nawet o tym napisałem jak już przeczytałem specyfikację w #118 jak już była wrzucona (PR powstał po moim pierwotnym wpisie) i natychmiast to poprawiłem i napisałem że zaktualizowałem to po przeczytaniu specyfikacji. Adres IP jest wysyłany w 3 miejscach. 1. 2. z mojego wpisu (pobranie i wygenerowanie unikalnego ID) oraz pobranie "paczki identyfikatorów" . W obu tych miejscach można "podejrzeć" adres IP i przypisać do unikalnego ID telefonu (czyli użytkownika) . Pkt 3. również ma się pojawić, ale zakładam że w wersji 3.2 bo ewidentnie w wersji 3.1 najistotniejsze są Galerie Handlowe (a nie muzea jak wspomina wasza dokumentacja i do czego wczoraj przez pół godziny przekonywał mnie @MateuszRomanow )
Sama strona internetowa jest pozbawiona integracji z systemem analitycznym. Na etapie testów korzystaliśmy z Google Analytics ale kody śledzące zostały ze strony usunięte a sam projekt GA usunięty. Tyle w temacie publicznej strony www i jej zabezpieczeń.
Słyszalem to trzy razy od @MateuszRomanow i za każdym razem uważam że to celowe odwracanie uwagi. Nikt nie mówi o stronie tylko o API. GA to coś zupełnie innego. Chodzi o możliwość identyfikacji użytkownika za pomocą adresu IP. Jedno z drugim nie ma kompletnie nic wspólnego (GA używa głównie cookies). I GA nie używa się do wywołań API na serwerze tylko do stron mobilnych/aplikacji mobilnych. Albo to co robicie to jest niewiedza albo śwadome wprowadzanie w błąd.
Z naszych badań wynika, że większość użytkowników korzysta z domyślnych serwerów DNS konfigurowanych automatycznie przez dostawcę internetu. W praktyce to właśnie oni na dużą skalę sprzedają dane na temat naszych gustów i zwyczajów internetowych. Jeśli mogę coś zasugerować to proszę poszukać alternatywy bo ludzie, którym zależy na prywatności powinni od tego zacząć przykładowy link do fundacji mozilla.
Podobnie. Albo to jest totalna niewiedza, albo świadome wprowadzanie w błąd. Nie mówimy o serwerach DNS i rozwiązywaniu adresów. Mówimy o komunikacji TCP/IP (również tej zaszyfrowanej TLS) w której wiadomo jakie są adresy strony wysyłającej i odbierającej ruch.
Wracając do głównego tematu tego wątku czyli adresów IP. W większości przypadków urządzenia mobilne będą korzystały z adresów tymczasowych lub wręcz współdzielonych z innymi użytkownikami! To połączenie jest zestawiane przez operatora sieci komórkowej lub naszego dostawcę internetu w miarę potrzeb a adres który dostajemy może się zmieniać dowolnie często. Jak zatem autor wyobraża sobie nawet teoretyczną możliwość powiązania tożsamości użytkowników z ich danymi skoro same dane nie są transmitowane otwartym tekstem a adres IP jest zmienny?
W taki sposób że przypisanie IP do osoby nawet jeśli to jest tymczasowe - jest zapisywane w logach operatora i dostęp do tego strona rządowa może łatwo uzyska - dokładnie tak jak to opisał @ayufan . Nie wiem czy wiesz jak działa protokół TCP/IP / TLS (chyba nie do końc) ale fakt szyfrowania połączoenia nie ma absolutnie żadnego wpływu na adresy IP. Polecam lekturę np. https://www.guru99.com/difference-tcp-ip-vs-osi-model.html.
Osobiście jestem commiterem i członkiem PMC (Project Management Commitee) w projekcie Apache Airflow (polecam - świetne narzędzie open-source do modelowania przepływów danych: http://airflow.apache.org/) który świetnie nadawałby się na przykład do stworzenia przepływu danych który co godzinę w parę chwil przetworzy parę milionów danych wejściowych od operatorów i połączeniu ich z danymi PRoteGO. Na wejściu logi operatora, baza ProteGO -> na wyjściu lista osób które się ze sobą kontaktowały z datami i długością kontaktóœ. Wyobrażam to sobie bardzo dobrze. Myślę że napisanie czegoś takiego zajęło by mi pół dnia. W sumie może powinienem napisać do MC, może jest robota do zrobienia ;).
Reasumując na świecie brakuje adresów IPv4 i nikt ich nie rozdaje za darmo. Nawet znając tymczasowy efemeryczny adres, który przypisał operator możemy co najwyżej poznać miasto lub województwo z którego ktoś się łączy. Na koniec jeszcze raz przypomnę, że samo namierzenie adresu IP nie wystarczy... trzeba jeszcze złamać szyfrowanie TLS... Powodzenia!
No włąśnie nie trzeba. Mylisz pojęcia. Strona serwerowa ma zarówno odszyfrowane dane jak i adres IP. Nic nie trzeba łamać - wszystko w jednym miejscu.
@potiuk zdefiniuj "Strona serwerowa" prosze
w modelu zagrozen bierzemy pod uwage wszystkie strony tj. wg. wytycznych DP-3T 5.1 Threat model
@potiuk zdefiniuj "Strona serwerowa" prosze
Kod który wywołuje się przy wywłołaniu "podaj mi paczkę BT ID". z tego co widzę w specyfikacji chcecie używać Cloud Functions z Firebase. Uzysktanie w takim Cloud Function "rzeczywistego" adresu IP klienta jest banalne https://stackoverflow.com/questions/48032909/how-to-get-client-ip-address-in-a-firebase-cloud-function
@qlb - wiem że jesteś inżynierem. Czy może ty - jeśli chodzi o techniczne możliwości możesz odpowiedzieć na te moje dwa proste pytania. Nie politycznie, tylko technicznie, czy to jest możliwe.
Pytanie 1. Czy jest możliwe że serwer dostanie True IP razem z listą TempID? Nie pytam czy jest możliwe teraz, ale czy w przyszłości jest możlwe że tak się stanie bez wiedzy i zgody użytkowników ?
Pytanie 2. Czy proxy o którym mówisz pozwala na nie-anonimizację tych danych i czy (niezależnie od tego jak jest teraz) będzie możliwość włączenia nie-anonimizacji w przyszłości tak, żeby użytkownik o tym nie wiedział?
Bardzo przepraszam - nie pisałem, że NAT'owanie jest jakimś problemem. Nie pisałem też nic na temat tworzenia lub nie odpowiednich logów przez operatorów. Zaprezentowany zrzut z konsoli udowodnił tylko że dotknięty został jeden z adresów firmy Cloudflare. Czy poznał Pan w ten sposób lokalizację naszego serwera? Nie bardzo rozumiem co to miało udowodnić. Pisałem powyżej, że dane w większości przypadków będą płynąć do aplikacji pobierającej co jakiś czas swoje identyfikatory a generalnie komunikacja modułu opentrace z systemem centralnym nie przechodzi przez systemy Cloudflare. Starałem się wyjaśnić, że do sugerowanego w tytule tego wątku naruszenia prywatności potrzeba nieco więcej niż tylko adres IP. To czy jest to adres publiczny czy lokalny nie ma dla tematu większego znaczenia. Chyba, że z praktyki zawodowej któregoś z przedmówców wynika również, że złamanie tunelu TLS w czasie rzeczywistym jest proste. Do takiego namierzenia połączeń przydaje się też dokładny czas. OK i co nam to daje w dyskutowanej potencjalnej sytuacji? Teoretycznie można udowodnić, że ktoś korzysta z naszej aplikacji. Ale zaraz do tego chyba trzeba by mieć adres docelowy (o nakazie sądowym nie wspomnę). Proszę mnie poprawić jeśli się mylę.
Na wejściu logi operatora, baza ProteGO -> na wyjściu lista osób które się ze sobą kontaktowały To już zakłada, jakąś omnipotencję na poziomie rządu. Aktualnie operatorem tej platformy jest MC. Dyskutujemy czy mogą się sami włamać do systemu, który utrzymują?
Dodatkowo użytkownicy w tym systemie się ze sobą nie komunikują przez internet. Temat wątku dotyczył osób zdrowych i ich telefony pytają o listę przygotowanych tymczasowych identyfikatorów z systemu centralnego - jest to jasne i publicznie znane - wynika z przyjętego modelu. Transmisja trwa prawdopodobnie ułamek sekundy i do następnej dochodzi po długiej przerwie w trakcie której adres IP klienta się zmieni a przynajmniej jest na to bardzo duża szansa. Zgodnie z koncepcjami przyjętymi w tym wątku już sam fakt korzystania z jakiejkolwiek strony rządowej jest naruszeniem prywatności bo po drugiej stronie serwer zapisał IP klienta.
Bardzo przepraszam - nie pisałem, że NAT'owanie jest jakimś problemem. Nie pisałem też nic na temat tworzenia lub nie odpowiednich logów przez operatorów. Zaprezentowany zrzut z konsoli udowodnił tylko że dotknięty został jeden z adresów firmy Cloudflare. Czy poznał Pan w ten sposób lokalizację naszego serwera? Nie bardzo rozumiem co to miało udowodnić.
To że mając dostęp do logów operatorów można dowiedzieć się kim jest osoba z niby "anonimowym" Unique ID.
Pisałem powyżej, że dane w większości przypadków będą płynąć do aplikacji pobierającej co jakiś czas swoje identyfikatory a generalnie komunikacja modułu opentrace z systemem centralnym nie przechodzi przez systemy Cloudflare.
Co innego pisał @MateuszRomanow w poście https://github.com/ProteGO-Safe/specs/issues/116#issuecomment-621233439 . CloudFlare pojawiło się bo on o tym napisał. Z tej odpowiedzi wszyscy słuchający wywnioskowali że Cloudflare jest używane również do komunikacji przez API. Faktycznie dziwny to wybór ale może po prostu @MateuszRomanow się pomylił ? Warto to wyjaśnić.
Starałem się wyjaśnić, że do sugerowanego w tytule tego wątku naruszenia prywatności potrzeba nieco więcej niż tylko adres IP. To czy jest to adres publiczny czy lokalny nie ma dla tematu większego znaczenia. Chyba, że z praktyki zawodowej któregoś z przedmówców wynika również, że złamanie tunelu TLS w czasie rzeczywistym jest proste.
Tak jak pisałęm - adres IP klienta w metodzie Cloud Function Firebase jest dostępny juz po odszyfrowaniu TLS. Albo nie wiesz o czym mówisz albo świadomie chcesz odwrócić uwagę. Polecam lekturę: https://stackoverflow.com/questions/48032909/how-to-get-client-ip-address-in-a-firebase-cloud-function
Do takiego namierzenia połączeń przydaje się też dokładny czas. OK i co nam to daje w dyskutowanej potencjalnej sytuacji? Teoretycznie można udowodnić, że ktoś korzysta z naszej aplikacji. Ale zaraz do tego chyba trzeba by mieć adres docelowy (o nakazie sądowym nie wspomnę). Proszę mnie poprawić jeśli się mylę.
Mylisz się poprawiam. w Cloud Function można zapisać adres IP, czas i temp ID i nie trzeba do tego niczego więcej (to już jest po TLS-ie). Połączenie tego z logami od operatorów jest banalne. Ich uzyskanie jest tylko kwestią odpowiedniego rozporządzenia jak wykazały kolejne zapisy w tarczach antykryzysowych. Zapisy w tarczy 2.0 umożliwiają dalsze połączenie tego z lokalizacją osób chorych, co automatycznie daje lokalizację osób zdrowych w pobliżu.
Na wejściu logi operatora, baza ProteGO -> na wyjściu lista osób które się ze sobą kontaktowały To już zakłada, jakąś omnipotencję na poziomie rządu. Aktualnie operatorem tej platformy jest MC. Dyskutujemy czy mogą się sami włamać do systemu, który utrzymują?
Po co włamywać, Wystarczy w ramach tarczy poprosić o logi operatora. Nie bardzo rozumiem kto i po co miałby się włamywać. Skoro można było bez ustawy przekazać dane PESEL do poczty, to równie dobrze można logi operatorów przekazać do MC. Czego nie rozumiesz ?
Temat wątku dotyczył osób zdrowych i ich telefony pytają o listę przygotowanych tymczasowych identyfikatorów z systemu centralnego - jest to jasne i publicznie znane - wynika z przyjętego modelu. Transmisja trwa prawdopodobnie ułamek sekundy i do następnej dochodzi po długiej przerwie w trakcie której adres IP klienta się zmieni a przynajmniej jest na to bardzo duża szansa.
I dokładnie w tym samym ułamku sekundy u operatora w logu jest zapamiętane że ten adres IP miał numer telefonu +4899999999 losuję). Połączenie tych dwóch rzeczy to naprawdę banał.
Zgodnie z koncepcjami przyjętymi w tym wątku już sam fakt korzystania z jakiejkolwiek strony rządowej jest naruszeniem prywatności bo po drugiej stronie serwer zapisał IP klienta.
Nie, bo nie mógł tego skojarzyć z "niby anonimowymi" BT ID których historię kontatków wysyłają do na serwer zdiagnozowani chorzy. Ze względu na zasięg BT chorzy będą wysyłać na serwer wszystkie ID które tylko na chwilę weszły w ich zasięg. Z moich szybkich kalkulacji wynika że wystarczy kilka procent osób zarażonych żeby w dużych miastach odtworzyć praktycznie kompletną sięć lokalizacji wszystkich osób. Przypomnę że rząd już będzie miał od operatorów historię lokalizacji osób chorych - więc z historii ich spotkań można wprost odtworzyć historię lokalizacji wszystkich osób. Pisałem już o tym w #83 w kontekście numeru telefonu ale to niestety działa tak samo w przypadku adresów IP (które - jak pokazałem wcześniej) są również daną osobową.
@potiuk 100% racji w każdym punkcie. I odpowiedzi odczytuję jako głęboką niewiedzę albo złą wolę odpowiadającego.
Oczywiście korzystając z tego systemu trzeba się liczyć z tym, że możemy być przekierowani przez IP o delikatnie mówiąc marnej reputacji. Takie IP Cloudflare ma już podstawy zablokować, ba - tego od nich oczekujemy!
Nieźle - wymagać od serwera blokowania anonimowego dostępu. Czyli inwigilacja. Więcej informacji nie trzeba, mam nadzieję, że każdy zobaczy tu zamordyzm na horyzoncie. #119
Ich uzyskanie jest tylko kwestią odpowiedniego rozporządzenia jak wykazały kolejne zapisy w tarczach antykryzysowych. Zapisy w tarczy 2.0 umożliwiają dalsze połączenie tego z lokalizacją osób chorych, co automatycznie daje lokalizację osób zdrowych w pobliżu.
To są TARCZE? Służa do bicia i do tej pory boli mnie głowa od tarczy antykryzysowej 1 i cały naród boli głowa od tarczy antykryzysowej 2 - od kiedy głosuje się zwykłą ustawę kowidową wraz z kodeksami, w tym zmianach do kodeksów wyborczych? Od kiedy zmienia się zasady gry (w wybory) w czasie wyborów, tworząc z nich Plebiscyt2020? Może najpierw zastanówmy się kto chce tą aplikację, kto ją zlecił i co *potencjalnie może z nią zrobić po leekim zmodyfikowaniu i uczynieniu obowiązkową?
Jak juz wyzej pisalem w aktualnym modelu zagrozen bierzemy pod uwage wszystkie strony tj. wg. wytycznych DP-3T 5.1 Threat model
Nie chcecie mi przeciez panstwo powiedziec, ze Wasze obawy zwiazane sa z tym, ze rzad demokratycznego kraju w porozumieniu "miedzygabinetowym" (o.O^?!<- wlasnie wymyslilem, moze byc?) zlamie konstytucyjne prawo do prywatnosci swoich obywateli a zarazem przyszlych wyborcow nakazujac lub wrecz indoktrynujac dostawcow mediow publicznych do przekazania danych osobowych ich klientow na "wlasny interes" skarbu panstwa lub "rzekomego" aparatu kontroli.
Pozwole sobie przytoczyc overview z w/w dokumentu zeby zejsc z tym wszystkim na ziemie.:
Reasumujac. Unlimited-budget adversary w postaci zmowionego konglomeratu skladajacego sie z State-level adversary wraz z operatorami Backend pod wprawnym okiem Tech-savvy users wykorzysta Regular user'a i ukradnie mu dane osobowe, ktore ten juz wczesniej zostawi w urzedzie GIS "doslownie" na probce badz tez u swojego operatora sieci komorkowej (Backend) pewnie nawet w postaci skanu PDF dowodu osobistego?
Zachowajmy wysoce posunieta powsciagliwosc w wyglaszaniu tego typu manifestacji gdyz godzi ona w nasze wlasne dobre imie. @potiuk @ayufan @miklobit @karwer @SeraMoon
Nie chcecie mi przeciez panstwo powiedziec, ze Wasze obawy zwiazane sa z tym, ze rzad demokratycznego kraju w porozumieniu "miedzygabinetowym" (o.O^?!<- wlasnie wymyslilem, moze byc?) zlamie konstytucyjne prawo do prywatnosci swoich obywateli a zarazem przyszlych wyborcow nakazujac lub wrecz indoktrynujac dostawcow mediow publicznych do przekazania danych osobowych ich klientow na "wlasny interes" skarbu panstwa lub "rzekomego" aparatu kontroli.
Przecież już to zrobił przy aplikacji "Kwarantanna Domowa" (telekomy też zmusił do przesłania danych). Przecież non stop łamią konstytucję i o demokracji nie ma już mowy. otwórzcie oczy.
Aplikacja na 99.9% stanie się aplikacją obowiązkową i aplikacją do dyskryminacji obywateli co już się pojawiło w projektach rozporządzeń (na początek wspomniane 10% w Centrach handlowych). Będzie to samo co w Chinach. Skoro uchwalono kilka ustaw niezgodnych z Konstytucją RP, zostaną uchwalone kolejne, a sądom zamknie się mordę Ustawą Kagańcową co już jest czynione w sprawie śledztw prokuratorskich dotyczących wyborów oraz już planowane w kontekście Niewyborów i protestów wyborczych - trafią do tej skompromitowanej izby sądu najwyższego i na podstawie ustawy kagańcowej zostaną umorzone jak te ślectwa.
Ws. prywatności - wszelkie orzeczenia sądowe można też potraktować wspomnianą ustawą obowiązującą od 14 lutego 2020 (ustawa kagańcowa).
@SeraMoon - aplikację wymyślił głównodowodzący tego projektu tutaj. Nie mam możliwości przetestowania tego cuda z Play Store, ale wygląda na to, że to nadal ten sam formularz zbierający jedynie dane i odpowiadający na pytania z formularza w postaci "jesteś / nie jesteś w grupie ryzyka". Ta aplikacja to albo:
Ja nie mam nic do zbierania moich danych zdrowotnych przez ogólnie rozumiany "aparat państwa" - bo to już się dzieje od dawna, ale udostępnianie ich prywatnym spółkom o kapitale 10000PLN - jest sporym nieporozumieniem.
@qLb Nie ma potrzeby by obawiać się o jakiekolwiek łamanie prawa, by otrzymać dane od dostawców mediów publicznych. Polecam zapoznać się z Ustawa z 15 stycznia 2016 r. o zmianie ustawy o Policji oraz niektórych innych ustaw (Dz. U. 2016, poz. 147) i jej ogólną oceną fundacji Panoptykon (link). W obecnym porządku prawnym, Państwo może zbierać takie informacje en-masse, bez potrzeby występowania o jakąkolwiek zgodę do sądu.
Jak juz wyzej pisalem w aktualnym modelu zagrozen bierzemy pod uwage wszystkie strony tj. wg. wytycznych DP-3T 5.1 Threat model
Nie chcecie mi przeciez panstwo powiedziec, ze Wasze obawy zwiazane sa z tym, ze rzad demokratycznego kraju w porozumieniu "miedzygabinetowym" (o.O^?!<- wlasnie wymyslilem, moze byc?) zlamie konstytucyjne prawo do prywatnosci swoich obywateli a zarazem przyszlych wyborcow nakazujac lub wrecz indoktrynujac dostawcow mediow publicznych do przekazania danych osobowych ich klientow na "wlasny interes" skarbu panstwa lub "rzekomego" aparatu kontroli.
W ciągu ostatnich kilku tygodni - to się właśnie stało. Pierwsza próba tarczy miała uzyskać dostęp do danych wszystkich użytkowników telefnów bez anonimizacji (łącznie z lokalizacją). Skończyło się na 1) tylko chorych (bez aonimizacji) i 2) pozostałych (w sposób zagregowany). Połączenie danych ProteGo i 1) pozwala na uzyskanie deanonimizacji lokalizacji wszystkich którzy choć przez chwilę znaleźli się w zasięgu osoby chorej (20-100 m w zależności od sytuacji) i automatycznie kontaktów między nimi, Dodająć to co pisze @aleksanderGondek - masz jasną ścieżkę jak to się może stać.
Unlimited-budget adversary w postaci zmowionego konglomeratu skladajacego sie z State-level adversary wraz z operatorami Backend pod wprawnym okiem Tech-savvy users wykorzysta Regular user'a i ukradnie mu dane osobowe, ktore ten juz wczesniej zostawi w urzedzie GIS "doslownie" na probce badz tez u swojego operatora sieci komorkowej (Backend) pewnie nawet w postaci skanu PDF dowodu osobistego?
Nikt nie posiada danych na temat lokalizacji i kontaków osób. GIS ma dane identyfikacyjne, To o czym piszemy to uzyskanie dynamicznych danych na temat lokalizacji i kontaktów między różnymi osobami.
Zachowajmy wysoce posunieta powsciagliwosc w wyglaszaniu tego typu manifestacji gdyz godzi ona w nasze wlasne dobre imie.
W czyje ? W jaki sposób? Nie rozumiem. Możesz to wyjaśnić proszę, bo naprawdę nie rozumiem kto i w czyje własne dobre imię godzi.
@potiuk 💯 +100, w sam cel. Do tego poczytajmy panoptykon.org z ostatnich 5 lat, poczytajmy oko.press z ostatnich 2 miesięcy i przeczytajmy
służącą do zamykania niewygodnych postępowań (wystarczy poczytać oko.press z ostatniego tygodnia). Przepraszam Państwo, którzy chcecie dalej prowadzić ten "projekt", ale chce mi się wymiotować (czy to objaw koronawirusa rządowego?) 🤮
Mamy ORWELL!! The Orwell Coronavirus. 2020-OCoV.
hmm. Czyli nie jest to naruszenie prywatności, skoro zmieniono temat?
Panowie i Panie. Ten scenariusz to byl armageddon. Jesli naprawde w to wierzycie to jest juz zdecydowanie za pozno zeby zareagowac. Co proponujecie? Ja proponuje wehikul czasu. Przeniesiemy sie do czasow Edisona i ukradniemy mu pomysl na zarowke. Wtedy nikt nie bedzie mial pradu i nasz problem z technologia rozwiazemy u zrodla. Skoro i tak nie potrafimy jej bezpiecznie uzywac.
Panowie i Panie. Ten scenariusz to byl armageddon. Jesli naprawde w to wierzycie to jest juz zdecydowanie za pozno zeby zareagowac. Co proponujecie?
Proponuję zamknąć projekt zanim zostanie włączony G+A. #119
Do tego proszę medialnie nagłościć temat, tak aby każdy, kto będzie rozwijał to dalej -- wiedział co robi i był tego świadomy.
@SeraMoon Nie. Nie jest - zgodnie z CoC CNCF zasady ogolne w dyskusji publicznej zabraniaja manifestowania pogladow w postaci oskarzen.
@SeraMoon Nie. Nie jest - zgodnie z CoC CNCF zasady ogolne w dyskusji publicznej zabraniaja manifestowania pogladow w postaci oskarzen.
Zasady Państwa demokratycznego zabraniają uchwalania ustaw z wielokrotnym łamaniem Konstytucji. Działam Pro Bono a nie według CoV VNCF.
@SeraMoon Zgadzamy sie!
@qlb -> pozwoliłem sobie przywrócić oryginalny tytuł po niezapowiedzianej zmianie z Twojej strony.
Widzę też że moje poprawki ktróre naprawiały błedy i niedomówienia w specyfikacji ze #118 zostały zamknięte i odrzucone bez dyskusji. To tyle jeśli chodzi o otwartość projektu i rzetelne trzymanie się faktów.
Tak skutecznie uniemozliwialy mi zaprezentowanie Panstwu zasad dyskusji na tym publicznym forum. @potiuk zasady komunikacji
@potiuk zasady komunikacji
Czyli ? Którą zasadę naruszyłem ?
Tak skutecznie uniemozliwialy mi zaprezentowanie Panstwu zasad dyskusji na tym publicznym forum. @potiuk zasady komunikacji
Można było wmergować same zasady CODE_OF_CONDUCT. Robię tak codziennie - dzielenie PRów na mniejsze.
zapraszam do docelowego manifestu CNCF jest w jezyku polskim. Naruszyles dzisiaj conajmniej ze dwie
zapraszam do docelowego manifestu CNCF jest w jezyku polskim. Naruszyles dzisiaj conajmniej ze dwie.
Które konkretnie i w którym miejscu ?
teraz mozemy zrobic tag anotowany na branchu master tak jak sam proponowales - taki do ktorego kazdy z nas bedzie mogl sie odniesc bo sie nie zmieni w przyszlosci a jednoczesnie stanowi najnowsze "co mamy". dodatkowo dzieki temu tagowaniu mozemy wersje cyfrowo podpisac tak abys w sklepie w przyszlosci mogl zweryfikowac, ze to co ogladasz na telefonie powstalo z tego wlasnie zrodla. - no coz tyle tutaj ludzi, ze moze to nawet nie Ty proponowales :)
teraz mozemy zrobic tag anotowany na branchu master tak jak sam proponowales - taki do ktorego kazdy z nas bedzie mogl sie odniesc bo sie nie zmieni w przyszlosci a jednoczesnie stanowi najnowsze "co mamy". dodatkowo dzieki temu tagowaniu mozemy wersje cyfrowo podpisac tak abys w sklepie w przyszlosci mogl zweryfikowac, ze to co ogladasz na telefonie powstalo z tego wlasnie zrodla.
????
Ataki osobiste Proszę o przykład.
Trollowanie, obraźliwe bądź urągające komentarze Również.
pokazuje przyklad pojawi sie tutaj pod spodem
Super że zamknąłeś ten wątek. Naprawdę świetnie.
Nie chcesz sie komunikowac w nalezyty sposob to nie bedziemy tego robic na "Twoich warunkach". W dokumencie pomocy technicznej znajdziesz instrukcje dotyczace zglaszania poprawek, pomyslow i bledow rowniez tych z punktu widzenia bezpieczenstwa. My w odroznieniu od MC odbieramy swoje wiadomosci email.
zapraszam do docelowego manifestu CNCF jest w jezyku polskim. Naruszyles dzisiaj conajmniej ze dwie
* Ataki osobiste * Trollowanie, obraźliwe bądź urągające komentarze a dalej: Opiekunowie projektu mają prawo i są odpowiedzialni za usuwanie, edycję oraz odrzucanie komentarzy, zmian w kodzie (commits), edycji Wiki, oraz innych treści, które łamią niniejszy Kodeks Postępowania.
Gdy argumenty się kończą i jedziemy po stosie.
ponieważ jego prawdziwy cel, jak i "zleceniodawca" pozostają nie w porządku wobec prywatności obywateli. Pragnę też zaznaczyć, że ten dla kogo to powstawało (MC / Ministerstwo Cyfryzacji) udostępniło nasze dane osobowe Poczcie Polskiej, w tym jak piszą na PANOPTYKONIE włącznie z naszymi skanami dowodów osobistych z przeszłości. Udostępnienie nastąpiło bez celu ponieważ adres zameldowania nie jest tożsamy z adresem zamieszkania, który ma nie Ministerstwo Cyfryzacji w bazie PESEL, ale samorządy w spisach wyborców.
Proszę o głosy poparcia poniżej - osoby, które się zgadzają aby ten projekt zamknąć - niech za dalszy jego los odpowiadają ci, którzy mieli ewentualne złe cele.
Mówki o CoV NVCF i trollingu to dla mnie adres 0xFFFFFFFD na stosie. Z doświadczenia gdy wyjdzie szydło z wora wtedy sypią się artykuły, regulaminy itp. formy w rozmowach.
KMODE_EXCEPTION_NOT_HANDLED
Please create new Issues in apropriate repository only using the correct issue template type:
New GitHub issues may be automatically closed/deleted if not related or not compatible with the templates provided.
If you would like to provide a new Issue template please create a Pull Request relating to at least one Issue.
Please do not use GitHub Issues for generic support questions or unreleated discussions. Instead please use Stack Overflow:
Czytam tę dyskusję, z wypiekami na twarzy i narastającym zażenowaniem. Kilka osób wyraża POWAŻNE obawy, a jakiś anonimowy gość, występujący pod nickiem, zlewa temat i kieruje do regulaminu. WTF?
Myślę, że warto byłoby uzyskać informacje na temat tego które wymagania tego projektu są podyktowane decyzjami politycznymi, a które są decyzjami realizatorów tego projektu. Być może jest tak, że rozmowa na tematy związane z wymaganiami dotyczącymi prywatności winna odbyć się na innym szczeblu.
Idąc za nowymi regułami wprowadzonymi wczoraj, stworzyłem (podążając za szablonami) "Bug Report" https://github.com/ProteGO-Safe/specs/issues/123 który opisuje zaistniałą niezgodność specyfikacji (mówiącej o anonimizacji) a implementacją (która zapewnie jedynie pseudonimizację).
Zachęcam do przeniesienia dyskusji tam, likeów. komentarzy. Ciekaw też jestem opini @qLb oraz @MateuszRomanow jako łącznika z MC na tematy które tam podsumowałem łącznie z zamieszczonymi źródłami. Z tego co udało mi się wyciągnąć z tej dyskusji powyżej, jestem absolutnie przekonany że strona rządowa ma w tej chwili pełne możliwości de-anonimizacji danych użytkowników i historii kontaktów, więc albo specyfikacja wprowadza w błąd mówiąc o anonimizacji, albo implementacja powinna być poprawiona.
Otworzyłem też https://github.com/ProteGO-Safe/specs/issues/124 - odzielny "Bug Report" który pokazuje niezgodność specyfikacji (w kontekście anonimizacji, lokalizacji i niezgodności z wytycznymi EDPB) z proponowanym rozwiązaniem wykorzystującym kody QR.
Zapraszam do komentarzy, lajków, krytycznych acz konstruktywnych dyskusjach w obu tych zgłoszeniach a Twórców aplikacji zachęcam do pochylenia się nad tymi problemami i ich rozwiązania.
Myślę, że warto byłoby uzyskać informacje na temat tego które wymagania tego projektu są podyktowane decyzjami politycznymi, a które są decyzjami realizatorów tego projektu. Być może jest tak, że rozmowa na tematy związane z wymaganiami dotyczącymi prywatności winna odbyć się na innym szczeblu.
Z tego co wiem to próby podejmowania rozmów na innych szczeblach do tej pory (wiem że takie próby były podemowane) były ignorowane przez Ministerstwo Cyfryzacji. Poczytać można o tym na przykład na stronie fundacji Panoptykon https://panoptykon.org/technologie-koronawirus-wytyczne-komisji-europejskiej
@potiuk @SeraMoon brawo za wytrwałość!
Chciałbym zaznaczyć, że jakiekolwiek porównywanie czy zestawianie w jednym zdaniu specyfikacji DT-3P do pomysłu ProteGO jest ogromnym nadużyciem. Podobnie z porównaniem do propozycji Apple/Google.
A przy okazji chciałem Was zapytać czy analizowaliście toolbox z EU "Mobile applications to support contact tracing in the EU’s fight against COVID-19"? Moim zdaniem, wczytując się w szczegóły, opisuje on rozwiązanie właśnie podobne do ProteGO (na pewno inne niż Google/Apple czy DP-3T), które niestety pozwala na śledzenie kontaktów opisanych tutaj. Może za bardzo wnikam i dosłownie zrozumiałem skróty myślowe z dokumentu, ale tak to mi wygląda.
Mam bardzo poważne obawy że obecnie proponowane rozwiązanie oparte o OpenTrace (podobno tymczasowe i do zastąpienia przez protoków A+G) ma dokładnie ten sam problem co wcześniejsze podejście z numerami telefonów i uważam że jest absolutnie nieakceptowalne i prace nad nim powinny zostać całkowicie wstrzymane.
Niestety, ze względu na tryb wrzucenia kodu i brak na ten temat jasnei informacji nie dane nam było się zapoznać z założeniami i wyborami dokonanymi przez @MateuszRomanow i MC przy wdrożonej wczoraj po cichu aktualizacji.
Za to poświęciłem trochę czasu żeby zrozumieć konsekwencję tych wyborów przy założeniach które (siłą rzeczy) muszę zgadywać bo mimo wczorajszych obietnic @MateuszRomanow w naszej ponad 2-godzinnej rozmowie specyfikacja i założenia w dalszym ciągu nie są w żaden sposób publiczne.
Dlatego - żeby też ułatwić zadanie @MateuszRomanow zdecydowałem się spisać założenia tak jak je rozumiem. @MateuszRomanow - proszę popraw mnie jeśli wasze założenia są inne.
1) Losowe TempId są rozgłaszane i publikowane przez BT w 15 minutowych cyklach
2) System jest scentralizowany i w momencie diagnozy osoba chora wysyła na serwer swój (nie anonimowy) identyfikator + kod wygenerowany w aplikacji + historię spotkań ze wszystkimi BT ID które przez ostatnie 2 tygodnie widziała.
3) Telefony wszystkich osób zdrowych co jakiś czas wysyłają na serwer swoje (przez ostatnie 2 tygodnie) wygenerowane BT ID i pytają o ich status. Algorytm na serwerze mówi "ok/zagrożony".
4) w systemie nie ma numeru telefonu.
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/
Nasz rząd wybrał rozwiązanie które dalej umożliwi mu bez żadnych problemów odtworzenie "Grafu spotkań" konkretnych osób - podobnie jak było to z numerem telefonu. Wyjaśniam dlaczego.
Kluczem jest punkt 3) powyżej. Żeby dowiedzieć się czy jesteśmy zagrożeni (będąc osobami zdrowymi) nasza aplikacja musi zapytać serwer i podać swoje TempID. Ale jednocześnie z tym pytaniem jest dostępne jeszcze coś - mianowicie adres IP z którego się łączymy. Adres IP w przypadku łączenia się z telefonu komórkowego - jest kwalifikowany jako dana osobowa (https://archiwum.giodo.gov.pl/pl/319/2258) i z punktu widzenia rządu bardzo łatwo (przez operatorów, z banków, etc. ) uzuskać informacje które jednoznacznie przypiszą adres IP (używany w jakmiś zakresie czasu) do konkretnej osoby, Czyl w zasadzie mamy sytuację tożsamą z tą, w której podany jest numer telefonu.
Dlatego mam parę pytań do @MateuszRomanow (te pytania również zostały wysłane do kilku fundacji NGO i organizacji technicznych zajmujących się prywatnością). Ponumerowane, żeby było łatwiej:
1) Czy adres IP osoby zdrowej jest dostępny w systemach serwerowych ProteGO-Safe podczas odpytywania o status osoby zdrowej
2) Czy (zakładając że rząd ma dostęp do danych łączących IP i konkretne osoby), możliwe jest odworzenie interakcji osób chorych z konkretnymi nie-anonimowymi osobami (w skrócie czy technicznie możliwa jest de-anonimizacja kontaktów osób zdrowych z osobami zdiagnozowanymi jako chore)
Tylko 2 pytania. Nic więcej. Naprawdę nie potrzeba dużo czasu @MateuszRomanow żeby na nie odpowiedziec.