Closed potiuk closed 4 years ago
Proponuję, zanim przejdziemy do rozwiązania G+A, należy wykonać analizę obecnych rozwiązań i usunąć całą maszynkę inwigilacyjną i dopiero potem implementować G+A. W repozytorium można się cofać i Złe Ministerstwo może wykorzystać rozwiązanie pośrednie, gdzie G+A jest zaimplementowany, a ankiety dziennnika i oceny zdrowia cały czas wysyłane na serwer.
Proponuję użycie odpowiedniego debuggera celem stwierdzenia czy aplikacja gdziekolwiek jeszcze wysyła dane na Androidzie zanim przejdziemy do G+A (nie mam urządzenia z Androidem, toteż ja tego nie sprawdzę).
"The public health authority will define the way in which the app determines if someone has been exposed"
Tu widzę pewne zagrożenie dla transparentności. Bo w/w nie determinuje czy:
W drugim przypadku możemy nigdy nie poznać kryteriów jakie sobie przyjął rząd - może on wtedy manipulować wagami i parametrami kontaktów które dostał z aplikacji zarażonego. Czyli trzeba żądać, żeby ta analiza była robiona w otwartym kodzie aplikacji klienta.
Tu widzę pewne zagrożenie. Bo w/w nie determinuje czy:
- ocena ma być wykonana wewnątrz aplikacji klienta i wysłane na rządowy serwer będą tylko id-kontaktów które zostały uznane wg algorytmu za zagrożone
W protokole G+A to jest dokładnie opisane akurat. Wszystkie obliczenia są przeprowadzane na telefonie - to jest dokładnie opisane w specyfikacji. Ten obrazek u góry opisuje algorytm. Ale w skrócie - rząd może decydować o parametrach tego algorytmu ale sam algorytm wykonuje się wewnątrz API. Polecam przejrzenie FAQ i specyfikacji - ona jest naprawdę krótka i bardzo przejrzyście napisana (to jest jej kolejna zaleta)
Na rządowy serwer wysyłane są tylko Temporary Exposure Keys osób ZDIAGNOZOWANYCH a nie zagrożonych. I to za ich zgodą. To są osoby u których właśnie testy wykryły wirusa, albo (i to się ostatnio pojawiło do "secondary contact detection") jeśli z wywiadu wynika że osoba miała kontakt z osobą zarażoną i wykazuje symptomy i czekamy na wyniki testu (albo testu nie można zrobić). Wtedy taka osoba można wysłać Temporary Exposure Keys jako osoby "Najprawdopodobniej chorej". Ale to wszystko pod kontrolą służb sanitarnych (służba musi dostarczyć odpowiedni kod) i za zgodą osoby chorej/prawdopodobnie chorej. Żadne dane nie są wysyłane "automatycznie". Wszytkie wymagają potwierdzenia (i w specyfikacji jest powiedziane że takie potwierdzenie jest na poziomie API - czyli nie da się go obejść w aplikacji).
- ocena będzię wykonana na rządowym serwerze po przesłaniu z aplikacji wszystkich zabranych id-kontaktów zarażonego
Nie ma w ogóle takiej możliwości. Na serwerach NIE MA żadnej informacji o:
Jedyna informacja jaka jest na serwerze to lista "temporary exposure keys" osób ziagnozowanych (lub najprawdopodobniej chorych). Kropka. Nie ma, i nigdy nie będzie nic więcej.
W drugim przypadku możemy nigdy nie poznać kryteriów jakie sobie przyjął rząd - może on wtedy manipulować wagami i parametrami które dostał z aplikacji zarażonego. Czyli trzeba żądać, żeby ta analiza była robiona w otwartym kodzie aplikacji klienta.
W protokole G+A tak to będzie.
"The public health authority will define the way in which the app determines if someone has been exposed"
Tu widzę pewne zagrożenie dla transparentności. Bo w/w nie determinuje czy:
- ocena ma być wykonana wewnątrz aplikacji klienta i wysłane na rządowy serwer będą tylko id-kontaktów które zostały uznane wg algorytmu za zagrożone
- ocena będzię wykonana na rządowym serwerze po przesłaniu z aplikacji wszystkich zabranych id-kontaktów zarażonego
W drugim przypadku możemy nigdy nie poznać kryteriów jakie sobie przyjął rząd - może on wtedy manipulować wagami i parametrami kontaktów które dostał z aplikacji zarażonego. Czyli trzeba żądać, żeby ta analiza była robiona w otwartym kodzie aplikacji klienta.
Inaczej być nie może z technicznego punktu widzenia. Rozwiązanie Google i Apple nie umożliwia porównania danych na serwerze, bo co najwyżej można tam wysłać swoje klucze (TEK, i, zwane dalej DKs). Tutaj chodziło o rządowe ustalenie czułości Exposure Risk Level (czy można się zarazić przez 5 minut czy 10).
Poza tym, co jest w dokumentacji (mn. umożliwianie użytkownikowi wył./wł. działania skanowania i rozgłaszania) byłaby wskazana manualna aktualizacja z systemem - pobranie listy TEK osób zdiagnozowanych. Mogłoby to być też połączone z wł./wył. tracingu.
Faktycznie - dopiero po objerzeniu w specyfikacji diagramu wszystkich interakcji api z aplikacjami po obu stronach sprawa się rozjaśnia. Czyli (jeżeli teraz już dobrze rozumiem :thinking: ) to wszystko na co rząd/twórcy aplikacji będa miec wpływ to te 4 parametry-wagi użyte w równaniu oceny ryzyka, które będzie liczone wewnątrz API ale jest jawne. Ale z tego samego diagramu wynika też, że to aplikacja ma inicjować żądanie (przez api) zgody usera na nadawanie/skanowanie przez BT. Chyba, że user , który nie ma aplikacji bęðzie to mógł również włączyć z poziomu ustawień OS'a (?)
Faktycznie - dopiero po objerzeniu w specyfikacji diagramu wszystkich interakcji api z aplikacjami po obu stronach sprawa się rozjaśnia. Czyli (jeżeli teraz już dobrze rozumiem ) to wszystko na co rząd/twórcy aplikacji będa miec wpływ to te 4 parametry-wagi użyte w równaniu oceny ryzyka, które będzie liczone wewnątrz API ale jest jawne.
Tak.
Ale z tego samego diagramu wynika, że to aplikacja będzie inicjować żądanie (przez api) zgody usera na nadawanie/skanowanie przez BT. Chyba, że user , który nie ma aplikacji bęðzie to mógł również włączyć z poziomu ustawień OS'a (?)
Docelowo z poziomu OS. Na razie inicjuje to aplikacja, ale "pop-up" i potwierdzenie jest wyświelane z wnętrza API i nie można go "przejąć". To użytkownik musi faktycznie na ekranie pacnąć "Tak zgadzam się". Nie będzie zdaje się też można zmodyfikować tekstu wyświetlanej notyfikacji ani zmienić np. kolejności wyświetlania przycisków etc. Czyli nie wchodzą w grę potencjalne "Dark Patterns" ze strony aplikacji.
Jeszcze inna wątpliwość jest : Czy nowo dodane uprawnienie (w tym wypadku nie tylko dla aplikacji ale dla samego OS'a ) do skanowania/nadawania COVID-ID udzielane przez usera na pewno będzie oznaczać że OS z tym uprawieniem może z BT korzystać wyłacznie na potrzeby COVID. Żeby nie było tak jak w przypadku androida, że udzielona OS'owi zgoda na dokładną lokalizację skutkuje nasłuchiwanien i wysyłaniem do google id napotkanych urządzeń BT nawet jeśli BT jest w telefonie wyłączone: https://qz.com/1169760/phone-data/ . Czyli żeby user miał jasność, nadając uprawnienie do COVID,że to działa niezależnie od innych funkcji BT. Bo jak widać z tego linku w przypadku budowania jakiejś usługi na bazie kilku różnych modułów hardware'u user nie ma pewności czy wyłączenie w ustawieniach danego modułu RF faktycznie go wyłacza dla wszystkch usług/aplikacji czy nie. W przypadku zgody na dokładną lokalizację user jest faktycznie oszukiwany co do aktywności BT w telefonie. Myśli że skoro BT wyłaczył to żadna aplikacja ani OS z niego nie korzysta a tak nie jest. W przypadku COVID jeżeli user ma byc traktowany fair to globalny przełacznik BT w ustawieniach OS'a powinien mieć wyższy priorytet niż zgoda na BT-tracing. Alternatywnie OS musiałby wyświetlać w widoczny sposób osobny status/ikonę że jest aktywny BT-tracing.
To w/w nie leży oczywiście w gestii twórców aplikacji tylko OS'ów ale skoro rozważamy bezpieczeństwo całego rozwiazania i prawa usera do pełnej wiedzy/kontroli nad swoimi danymi to musi być brane pod uwage.
globalny przełacznik BT w ustawieniach OS'a powinien mieć wyższy priorytet niż zgoda na BT-tracing. Alternatywnie OS musiałby wyświetlać w widoczny sposób osobny status/ikonę że jest aktywny BT-tracing.
Donre pytania na szczęście specyfikacja udziela na nie odpowiedzi:
Jeden z błędów zwracanych przez aplikację to "ENErrorCodeBluetoothOff". Jest też taka informacja jeśli chodzi o status aplikacji:
"ENStatusBluetoothOff Bluetooth has been turned off on the system. Bluetooth is required for Exposure Notification."
I tu ciekawostka:
"Note: this may not match the state of Bluetooth as reported by CoreBluetooth. Exposure Notification is a system service and can use Bluetooth in situations when apps cannot. For the purposes of Exposure Notification, it's better to use this API instead of CoreBluetooth.
I tu tłumaczę o co chodzi. Z punktu widzenia aplikacji Bluetooth może być "wyłączony" jeśli użytkownik wyłączył go dla tej konkretnej aplikacji (wtedy CoreBluettoth mówi "off" nawet jeśli BT jest włączony w systemie. ExposureNotification działa z uprawnieniami systemowymi, więc nie trzeba nawet aplikacj ProteGO-Safe nadawać uprawniania do używania BT. Ona tego nie potrzebuje - aplikacja "Contact Tracing" w tym przypadku będzie prawdopodobnie potrzebowało tylko uprawnienia do "ExposureNotification" które stanie się nową "usługą systemową". I w związku z tym status BT trzeba sprawdzić przez API Exposure Notification (bo dopiero ono powie czy faktycznie BT jest wyłączony).
Reasumując: Jest tak jak oczekiwałeś - przy wyłączonym BT dla całego urządzenia serwis "Exposure Notification" nie będzie działał.
Zamykam poniewaz jak dobrze wiecie dokladnie taki byl "nasz" plan od poczatku tego projektu #94. Zachecam do zadawania pytan dotyczacych tematu G+A tutaj: #134
Komentarz dotyczył również zaniechania implementacji obecnego rozwiązania na razie są to tylko deklaracje, a implementacja kodów QR temu przeczy
Is your feature request related to a problem? Please describe.
Dokończyłem lekturę https://www.apple.com/covid19/contacttracing/ i jestem absolutnie przekonany że obecne rozwiązanie trzeba całkowicie i natychmiast wyrzucić, nie wdrażać dalszych funkcji i zastąpić je rozwiązaniem Google + Apple.
Protokół zcentralizowany zaimplementowany obecnie jest w zasadzie protokołem inwigilacyjnym. Opisano to dokładnie w #123, dokładny opis dlaczego znajduje się tu: https://blog.kurasinski.com/2020/05/protego-safe-dlaczego-nie-nalezy-instalowac-aplikacji-ministerstwa-cyfryzacji/ ale dokładne wyjaśnienie na ten temat znajduje się w liście 300 wiodących naukowców z całego świata: https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/view?fbclid=IwAR3h4c8RsjrSiZaK3aZGCRwqrK80H22fBsuTE1KNMhimnfVfijzjJmK7RgY
Rozwiązanie z QR kodami jak opisano w #124 naraża Galerie Handlowe na ataki cyberprzestępców i nie jest w żaden sposób przemyślane i przedyskutowane. Zamiast realizować funkcje "Contact Tracing" daje tylko i wyłącznie możliwości inwigilacyjne.
Ze względu na ograniczenia technologii BT obecne rozwiązanie jest również nieskuteczne, ponieważ bez wpisania na listę wyjątków Aplikacja ProteGO-Safe w wielu przypadkach nie będzie w efektywny i ciągły sposób działała w tle - co jest warunkiem żeby takie rozwiązanie w ogóle wprowadzać.
Uważna lektura rozwiązania Google + Appple https://www.apple.com/covid19/contacttracing/ pokazuje że jest to protokół w pełni zdecentralizowany, anonimowy, bardzo dobrze przemyślany i z wieloma rozwiązaniami dyskutowanymi we wcześniejszych wątkach.
Obrazki ze specyfikacji
Co najważniejsze - wymuszanie (lub namawianie do instalacji) aplikacji ProteGO-Safe jest niepotrzebne na tym etapie. System nie ma szans działania bez szerokiej akceptacji a ostatnie działania Ministerstwa Cyfryzacji bardzo nadszarpnęły reputacją aplikacji ProteGO-Safe. Zgodnie z zapowiedziami Apple i Google. Instalacja aplikacji wkrótce już nie będzie potrzebna do wspomagania tradycyjnego "contact tracing".
Polecam przeczytanie FAQ: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-FAQv1.0.pdf ale tu kilka wyjątków:
"In the second phase, available in the coming months, this capability will be introduced at the operating system level to help ensure broad adoption, which is vital to the success of contact tracing. After the operating system update is installed and the user has opted in, the system will send out and listen for the Bluetooth beacons as in the first phase, but without requiring an app to be installed. If a match is detected the user will be notified, and if the user has not already downloaded an official app they will be prompted to download an official app and advised on next steps. Only public health authorities will have access to this technology and their apps must meet specific criteria around privacy, security, and data control."
Również wprost jest napisane jakie dane będą dostępne dla kogo:
"Access to the technology will be granted only to public health authorities. Their apps must meet specific criteria around privacy, security, and data control. The public health authority app will be able to access a list of beacons provided by users confirmed as positive for COVID-19 who have opted in to sharing them. The system was also designed so that Apple and Google do not have access to information related to any specific individual."
"The public health authority will define the way in which the app determines if someone has been exposed. To support this the system provides and the app can use both an estimate of time the user has been in contact with someone who has tested positive for COVID-19 and the approximate distance between the users. Public health authorities will set a minimum threshold for time spent together, such that a user needs to be within Bluetooth range for at least 5 minutes to register a match. If the contact is longer than 5 minutes, the system will report time in increments of 5 minutes up to a maximum of 30 minutes to ensure privacy"
I to że to jest tylko jeden z elementów układanki:
"Exposure notification is only one element of the response to COVID-19 and is hoped to be a useful technology in the toolbox of public health authorities. As the response to the pandemic evolves technological solutions will need to continue to adapt as well so the efforts of public health authorities can be amplified."
Describe the solution you'd like
Usunięcie obecnych rozwiązań (BT i QR Code) i zastąpienie ich rozwiązaniem Google + Apple.
Describe alternatives you've considered
Implementacja protokołu D3-PT. W przec
Additional context Add any other context or screenshots about the feature request here.