search

ProteGO-Safe / specs

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

Zagrożenie demokracji jeśli BT nie będzie anonimowe na serwerze #55

Closed potiuk closed 4 years ago

potiuk commented 4 years ago

W obecnej wersji aplikacji algorytm decydujący o statusie osoby nie jest publiczny i nie wiadomo kto go kontroluje. Mówienie w tej sytuacji że rozwiązanie jest "otwarte" i rozwijane przez "społeczność" jest nadżyciem. Rozwijany jest w ten sposób jedynie "interfejs" a najważniejsza część - czyli przetwarzanie danych - nie jest publiczne.

W ten sposób jest to podatne na manipulacje i wykorzystanie do bardzo złych celów celów. Strona serwerowa (czyli zakładam strona rządowa) ma wiedzę na temat tego, kto jest kim i może takiej osobie ustawić status "czerwona" niezależnie od użytych algorytmów. Izolując taką osobę od społeczeństwa. To jest absolutnie niedopuszczalne, żeby status taki nie podlegał żadnej kontroli - ani publicznej, ani sądowej.

Jeśli chodzi o upublicznienie algorytmu - było na ten temat issue #4 kiedy aplikacja (ewidentnie) miała o tym podejmować decyzję sama. Istnieje również alternatywa opisana w #34 które opisuje jak to zrobić w sposób otwarty i zdecentralizowany.

Najprostszym rozwiązaniem, żeby tego uniknąć jest usunięcie konieczności rejestrowania się numerem telefonu - tak żeby dane były faktycznie anonimowe - bo w tej chwili nie są.

potiuk commented 4 years ago

W przypadku pełnej anonimizacji danych BT (patrz #56 ). Jeśli zostanie wdrożone #56 to można to zamknąć i upublicznienie algorytmu nie jest konieczne do zachowania prywatności. W dalszym ciągu istotna jest jakość algorytmu i jego poprawność. Jakość i poprawność powinny być weryfikowane, aby na przykład nie generowały paniki, ale zważywszy na to, że algorytm będzie operował na anonimowych danych nie ma potrzeby jego upubliczniania.

jakublipinski commented 4 years ago

W świetle https://github.com/ProteGO-app/specs/issues/34#issuecomment-609993832 sugeruję zamknąć ten wątek.

potiuk commented 4 years ago

OK. Widzę że założenia z anonimowością już opisane faktycznie można zamknąć.

potiuk commented 4 years ago

@cloudyfuel -> akurat jeśli chodzi o bluetooth to transmitowane ID są anonimowe (tak długo jak nie są połączone z numerem telefonu). Więc tu akurat nie widzę problemu - to jest robione bardzo podobnie (choć inaczej) do https://github.com/DP-3T/documents/ - tam można sporo na ten temat poczytać.

Nie jestem bardzo radykalny w tych opiniach. To że faktycznie tak "powinno" być, nie znaczy że musi i że kompromisowe rozwiązania w których prywatność jest zachowania nie są ok. Jeśli spełniają inne założenia - na przykład anonimowość przetwarzania danych i sprawienie że algorytmy będą lepsze, to pewne kompromisy są ok.

potiuk commented 4 years ago

Ten opis powyżej jest jednak trochę zmanipulowany. Nie można porównywać MAC/WiFI urządzeń do identyfikatorów rozgłaszanych przez ProteGO. MAC/WiFi urządzeń są na stałe przypisane do urządzenia a identyfikatory publikowane przez ProteGO zmieniają się w czasie i są losowe.

To jest rozwiązanie bardzo podobne do tego które zastosował Apple w IOS 8 - https://appleinsider.com/articles/14/06/09/mac-address-randomization-joins-apples-heap-of-ios-8-privacy-improvements i było to bardzo dobrze przyjęte jako mechanizm ochrony prywatności.

SeraMoon commented 4 years ago

ale zważywszy na to, że algorytm będzie operował na anonimowych danych nie ma potrzeby jego upubliczniania.

Jak ja lubię pseudo FOSS. Za takie podejście do tematu powinna być kara śmierci. Abyśmy zaufali - całość musi być otwarta, w tym kod od Google i Apple, z możliwością uruchomienia go również na Linuxie i Windowsie.