Niespójność opisu i zapowiedzi co do decentralizacji protokołu BT

[potiuk]

Describe the bug

W issue #134 @MateuszRomanow zapowiedział że (zakładam że po dość dużym oporze społecznym który obudził się dzięki https://blog.kurasinski.com/2020/05/protego-safe-dlaczego-nie-nalezy-instalowac-aplikacji-ministerstwa-cyfryzacji/ ) obecny protokół będzie zdecentralizowany - a jednocześnie napisał o tym że będzie tam "serwer" który robi coś specjalnego u w jakiś sposób zabezpiecza coś (Nie bardzo wiadomo co????).

Nie bardzo wiadomo o co chodzi, bo jeśli ten protokół będzie zaimplementowany podobnie do G+A to na serwerze w zasadzie nic nie trzeba zabezpieczać - bo wszystkie uploadowane dane (lista Temporary Exposure Key od osób zdiagnozowanych) i tak jest publicznie dostępna, więc nie ma potrzeby dodatkowo zapobiegać zapisywaniu tych danych.

Niezależnie cały czas tworzymy pozostałe komponenty na bazie OpenTrace, które także powoli decentralizujemy np.: a) brak zapisu danych i ich analizy na serwerze centralnym w celu predykcji poziomu ryzyka kontaktu -> na rzecz obliczeń lokalnych na urządzeniu b) zamiana centralnego nadawania ID + lokalnie TempID w OpenTrace na rzecz tylko TempID generowanych lokalnie c) serwer, który jedynie propaguje dalej bez zapisu zuploadowaną historię kontaktu; (co ciekawe, taki PoC stworzyliśmy razem z Sigmą jeszcze na etapie SafeSafe 4-5 tygodni temu. Zastąpiliśmy go później znacznie dojrzalszym rozwiązaniem OpenTrace).

Ten punkt c) jest niepokojący w kwestii tego na ile faktycznie ma być to protokół zdecentralizowany a na ile na serwer ma być wysyłane więcej danych.

Żeby uniknąć w przyszłości podobnych sytuacji w których raz zaimplementowane rzeczy są usuwane (poprosiłem o natychmiastowe usunięcie niepotrzebnej funkcjonalności śledzenia w #137) myślę że warto było uaktualnić specyfikację, tak, aby można ja było wcześniej poddać przeglądowi przez zaangażowaną społeczność, inaczej jest ryzyko, że znowu trzeba będzie coś wycofy

To Reproduce Zajrzenie do specyfikacji i #134 i porównanie tego co jest w obu miejscach.

Expected behavior Specyfikacja powinna odzwierciedlać bieżące plany, zwłaszcza jeśli zmieniły się o 180 stopni (tu mam nadzieję nie aż o 360 stopni)

[SeraMoon]

bo wszystkie uploadowane dane (lista Temporary Exposure Key od osób zdiagnozowanych) i tak jest publicznie dostępna, więc nie ma potrzeby dodatkowo zapobiegać zapisywaniu tych danych.

Publicznie dostępna bez IP, zaś na serwer uploadowane z IP 😾 Coś tu nie gra i pachnie inwigilacją dalej... Czy osoby odpowiedzialne za przeszłe działania inwigilacyjne i obecnie proponowane, rozumieją, że poziom zaufania społeczeństwa spadł do -1%? W szczególności tego świadomego i tego mniej świadomego, którym świadomi powiedzą "nie instaluj tego bo cię inwigiluje"?

Kiedy założeniami do aplikacji zajmie się osoba mająca pojęcie o rzeczywistej prywatności, przetwarzaniu danych i zdolności znajdowania miejsc, gdzie dane identyfikowalne się pojawiają i mogą zostać przekazane?

[potiuk]

Publicznie dostępna bez IP, zaś na serwer uploadowane z IP Coś tu nie gra i pachnie inwigilacją dalej... Czy osoby odpowiedzialne za przeszłe działania inwigilacyjne i obecnie proponowane, rozumieją, że poziom zaufania społeczeństwa spadł do -1%? W szczególności tego świadomego i tego mniej świadomego, którym świadomi powiedzą "nie instaluj tego bo cię inwigiluje"?

Kiedy założeniami do aplikacji zajmie się osoba mająca pojęcie o rzeczywistej prywatności, przetwarzaniu danych i zdolności znajdowania miejsc, gdzie dane identyfikowalne się pojawiają i mogą zostać przekazane?

Poczekajmy co @MateuszRomanow będzie miał do powiedzenia.

[KoderFPV]

Aplikacja nie zapisuje, nie inwigiluje i nikt nie jest odpowiedzialny za przeszłe jak i przyszłe działanie inwigilacyjne.

Jeżeli macie państwo zastrzeżenia do działania, to zachęcamy do poruszenia dyskusji na: https://github.com/opentrace-community/opentrace-cloud-functions

Zachęcamy także do stworzenia pull requesta po ich stronie, tak tylko jak zostanie on dołączony do repozytorium tak szybko zaktualizujemy naszą wersje: https://github.com/opentrace-community/opentrace-cloud-functions

W przyszłości planujemy integracje z rozwiązaniem G+A tak szybko jak będzie dostępna publicznie.

Obecnie nie ma żadnego serwera. Korzystamy z oficjalnej implementacji: https://github.com/opentrace-community/opentrace-cloud-functions

[SeraMoon]

Wątek czekał na odpowiedź @MateuszRomanow, której się nie doczekał. Tymczasem zamnięto go jako potrzebującego obsługi. Mimo, że w aplikacji możliwa nadal jest inwigilacja, stwierdzono, że nie ma tu inwigilacji. A IP lecące do serwerów aplikacji w tym proxy, którego kodu tu nie znamy i którego kodu się nie da sprawdzić?

@potiuk - czy możesz wątek otworzyć i powtórzyć to co pisałeś o IP jako danej osobowej, możliwości śledzenia przez rząd itd.?

[potiuk]

@SeraMoon - niestety nie mam mocy otwarcia zamkniętych wątków. natomiast w kontekście zamknięcia większości - jeśli nie wszystkich issue. mam inny pomysł moment