Closed SeraMoon closed 4 years ago
tor nie jest etyczny, ipfs lepszy https://github.com/ipfs/ipfs#readme jest też wersja js https://github.com/ipfs/js-ipfs#readme https://github.com/ProteGO-Safe/specs/issues/84
tor nie jest etyczny, ipfs lepszy https://github.com/ipfs/ipfs#readme
@KonoromiHimaries, Co to znaczy, że Tor nie jest etyczny? Używam latami i tego nie widzę, poza tym, że część stron go lepiej lub słabiej blokuje?
Tylko chcę rzeczowe informacje a nie typu "przestępcy używają Tora do przestępstw", bo przytoczę Ci podobną mówkę z nożem, gdy reszta używa go do krojenia chleba.
co mam z tego linka wyczytać? Nie mam czasu na analizę tylu repozytoriów.
@SeraMoon sieci zdecentralizowane mają przewagę w przytoczonych 7 filarach zaufania. filmik poglądowy https://www.youtube.com/watch?v=5Uj6uR3fp-U
A przetwarzanie oparte bez użycia scentralizowanego systemu (np. na smartfonie) - mają tą zaletę, że nie wysyłają w ogóle danych i to jest jeszcze lepsze.
Gdy komuś się tor i scentralizowany system nie podoba - istnieje jeszcze I2P, ale nie wiem na ile jest możliwy do użycia w tym miejscu. Poza tym przy wysyłaniu informacji do scentralizowanego systemu w formie szyfrogramów, do których hasło zna tylko użytkownik (i na tym może polegać jego zgoda na ujawnienie się, że rozszyfruje te dane dotyczące jego zainfekowanej persony), reszta jest już nieistotna - nie ma jawnych danych, nie ma IP, więc w sumie nie ma dalszej rozmowy, bo nikt nie przeznaczy wszystkich komputerów na świecie aby złamać kilka szyfrogramów.
no więc skoro mamy problemy na smartfonach z I2P, więc można użyć Tora, który na smartfonach (na pewno na Andoidzie, nie znam szczegółów odnośnie iOS) i dodatkowego szyfrowania wysyłanych danych na serwer (np. na wypadek awarii smartfona, aby móc sobie je ponownie pobrać na nowy pamiętając hasło).
Tor to zupełnie idiotyczny pomysł dla takiego projektu. Nie dość, że wszyscy dzielimy się już danymi z telekomami oraz Google i Apple to jeszcze ma dojść do tego 3 poziom w postaci "operatorów" Tor?
Tor to zupełnie idiotyczny pomysł dla takiego projektu. Nie dość, że wszyscy dzielimy się już danymi z telekomami oraz Google i Apple to jeszcze ma dojść do tego 3 poziom w postaci "operatorów" Tor?
Tu muszę się zgodzić, że Tor to nie najlepszy pomysł. Wydaje mi się że jedyne sensowne rozwiązanie to faktycznie to co robi A+G -> na serwerze nie ma w ogóle żadnych prywatnych danych. I można sobie to IP wtedy logować jak się chce.
Opisałem to dość szczegółowo w wywiadzie z Arturem https://blog.kurasinski.com/2020/05/protego-safe-dlaczego-nie-nalezy-instalowac-aplikacji-ministerstwa-cyfryzacji/
W sytuacji gdy wykorzystany będzie protokół G+A, zaś nic nie będzie przesyłane przez standardowe łącze w zakresie "diagnoz" (chodzi o wszelkiej maści ankiety medyczne) - wtedy Tor nie ma sensu, ponieważ aplikacja nie łączy się bezpośrednio z internetem przekazując IP instytucjom od których można cokolwiek żądać. Tora oczekiwwałam tutaj dla tych ankiet, gdy faktycznie niemożliwe (w co wątpię) byłoby przetworzenie ich na offline JS.
Wskażę tutaj jednak, że samo użycie G+A po pierwsze wyprowadza dane poza obszar Unii Europejskiej (i wracamy do punktu wyjścia ED... coś tam) oraz nie spełnimy wszystkich filarów zaufania, ponieważ nie będziemy mieć otwartego kodu protokołu G+A (czy się mylę i Google dostarczy kod protokołu i serwerów z którymi może się to łączyć?).
Trzeciego pośrednika w rozumieniu RODO w przypadku Tora nie mamy, ponieważ:
Oczywiście o ile poprawią I2P tak aby stabilnie działał na Androidzie - nie mam nic przeciwko użyciu takiego zdecentralizowanego rozwiązania.
@potiuk - łapka w górę za aktywne publiczne pisanie o problemie prywatności w niniejszej aplikacji. :-)
Wskażę tutaj jednak, że samo użycie G+A po pierwsze wyprowadza dane poza obszar Unii Europejskiej (i wracamy do punktu wyjścia ED... coś tam) oraz nie spełnimy wszystkich filarów zaufania, ponieważ nie będziemy mieć otwartego kodu protokołu G+A (czy się mylę i Google dostarczy kod protokołu i serwerów z którymi może się to łączyć?).
I tu chciałbym sprostować. Mylisz się. Ani Google, ani Apple nie mają dostępu do żadnych danych. Ten protokół jest stworzony zgodnie z zasadą "privacy by design". Wygląda to tak że w każdym regionie (u nas - Polska) "health authorities" w swojej aplikacji dostarczą adres pod jaki dane mają być wysyłane w momencie w którym osoba zostaje zdiagnozowana jako chora, oraz adres spod którego mają być pobierane wszystkie Temporary Exposure Keys osób zdiagnozowanych.
Przy czym aplikacja dostarcza tylko adres i może "poprosić" żeby te dane wysłać. Sama aplikacja nie ma dostępu do danych przechowywanych na telefonie.
To jest naprawdę świetnie zaprojektowany protokół który jest nie do wykorzystania w żaden inny sposób - ani dla Apple, ani dla Google ani dla rządu. Dlatego to jest tak interesujące że to G+A uczą rządy co to znaczy prywatność. Świat stanął na głowie.
@potiuk - łapka w górę za aktywne publiczne pisanie o problemie prywatności w niniejszej aplikacji. :-)
Proszę bardzo :). Tak trzeba. Walczyć tam gdzie się ma wpływ. Zapewniam, że to nie koniec :).
@potiuk będzie dane nam poznać kod tego protokołu? Dla transparentności - powinien zostać udostępniony jako open source po jego opracowaniu, m.in. aby móc zbadać podatności.
Dlatego to jest tak interesujące że to G+A uczą rządy co to znaczy prywatność. Świat stanął na głowie.
Tak to jest bardzo dziwne...
@potiuk będzie dane nam poznać kod tego protokołu? Dla transparentności - powinien zostać udostępniony jako open source po jego opracowaniu, m.in. aby móc zbadać podatności.
Jestem pewien że tak sie stanie. G+A jeszcze tego wprost nie napisali. Myślę że patrząc na to co się dzieje w repozytorium ProteGO stwierdzili że otworzą trochę później ;) . Ale już serio - jeśli ten kod nie będzie publicznie dostępny i zaudytowany, to będę pierwszym który będzie namawiał do nie włączania (z resztą myślę że wtedy wkroczy choćby unia europejska, która już niejedno wymogła) - myślę że nie będą mogli sobie na to pozwolić.
W przypadku Androida mam nadzieję że kod wyląduje w AOSP (Android Open Source Project) https://source.android.com/ które jest publiczne). Tam ląduje większość rzeczy implementowanych przez Google na poziomie OS. To nie jest projekt rozwijany przez community tylko przez konsorcjum 84 firm - Open Handset Alliance (https://www.openhandsetalliance.com/) - w którym Google gra najważniejszą rolę. Tam kod pojawia się "paczkami" (co samo w sobie nie jest godne pochwały ale przynajmniej Google nie twierdzi że jest to rozwijane przez "społeczność"). Firmy z OHA mają dostęp do kodu rozwijanego na bieżąco i kontrybuują do niego. Wiem bo sam kontrybuowałem (miałem akurat przyjemność implementować fork Android OS do systemów płatniczych gdzie implementowaliśmy dodatkowe wartstwy bezpieczeństwa i API systemowe)
W przypadku Apple, nie jestem pewien jak i w jakim trybie otworzą źródła. Oni mniej publikują kodu (choć zdarza im się coraz częściej).
Uważam w ogóle że najbardziej prawdopodbny scenariusz to że protokół Google + Apple zostanie referencyjną (i jedyną) implementacją protokołu DP-3T - zarówno DP-3T wypowiada się ciepło o G+A jak i w drugą stronę. Więc najbardziej prawdopodobnym scenariuszem będzie ustanowienie Fundacji która ten kod upublikuje i weźmie "pod skrzydła" - podobnie jak to się ma z projektami w "Apache Software Foundation". Myślę że rozmowy na ten temat się toczą.
Powtórzę z całą mocą - jeśli ten kod nie będzie otwarty/zaudytowany to będę pierwszym, który powie "nie".
Dlatego to jest tak interesujące że to G+A uczą rządy co to znaczy prywatność. Świat stanął na głowie.
Tak to jest bardzo dziwne...
W przypadku Androida mam nadzieję że kod wyląduje w AOSP (Android Open Source Project) https://source.android.com/ które jest publiczne). Tam ląduje większość rzeczy implementowanych przez Google na poziomie OS. To nie jest projekt rozwijany przez community tylko przez konsorcjum 84 firm - Open Handset Alliance
To byłoby dobre. Fajnie by było gdyby licencja była zgodna z GPL / MPL, aby można to było też wkompilować w Linuxa oraz użyć na "podróbach Androida", które mają nieco lepsze podejście do innych aspektów prywatności 😸 związanych już samym Androidem, nie zaś protokołem.
co samo w sobie nie jest godne pochwały ale przynajmniej Google nie twierdzi że jest to rozwijane przez "społeczność"
"Społeczność" i "solidarność" w Polsce to w wielu projektach jest niestety nazwijmy to wprost - rak. Dziwię się, że dla Polski tam gdzie widać na GitHubie obrazek z obserwowaną pluskwą przez lupę nie wstawili jeszcze rakowiska. 😹 Nie mówię o wszystkich Polakach, ale podsieć rządową mogliby wydzielić do takiej "klasy". 😉
W przypadku Apple, nie jestem pewien jak i w jakim trybie otworzą źródła. Oni mniej publikują kodu (choć zdarza im się coraz częściej).
Nie stanowi to problemu - to już problem ajfonowców. Ważne aby były źródła i aby dało się używać tego zwyczajnie na dowolnym systemie po dostosowaniu wywołań systemowych.
Powtórzę z całą mocą - jeśli ten kod nie będzie otwarty/zaudytowany to będę pierwszym, który powie "nie".
3xNIE ma mocniejszą siłę przebicia niż "nie" 😉 - jak widać dobrze przebija się przez "solidarność rządową" 😹 i przez "opornych na wiedzę"
Dorzucam fajną (check-)listę od NGO a propos zasad-filarów, które powinna spełniać apka tego typu. https://www.accessnow.org/privacy-and-public-health-the-dos-and-donts-for-covid-19-contact-tracing-apps/
Fajnie też opisuje zalety i wady, czy wręcz sensowność rozwiązań typu contact-tracing.
"Even though the contact pinging protocols were strictly Bluetooth-based, there was always the possibility that the apps could request permission for the system's location information. Today, the companies have explicitly announced that any apps using its APIs will not be allowed to request that data. In addition to privacy benefits, this also rules out the inherent margin of error that GPS inherently gives and reduces power consumption. Governments that already have a contact tracing app and want to adopt this SDK will need to conform to this requirement."
Super @tomekziel - dzięki za informację.
No i teraz czekamy na aktualizację #147 mówiącą o tym że MC zdecydowało się postawić wyłącznie na G+A (bo już po prostu nie da się inaczej).
Dodatkowe materiały, trochę starych, trochę nowych: https://www.google.com/covid19/exposurenotifications/
No i proroczo. Google + Apple na straży prywatności. Naprawdę - świat stanął na głowie przez tego coronavirusa. Dzięki @tomekziel - dziś pierwszy raz od jakiegoś czasu, to ja będę mógł spokojnie spać. I mam nadzieję wszyscy projektanci i programiści ProteGO również.
I tego im serdecznie życzę. Zupełnie szczerze i od serca.
Mam nadzieję że moja wiedza w tym nowym projekcie będzie przydatna. Bardzo chętnie będę pomagał w miarę możliwości @MateuszRomanow .
@tomekziel - no i nawet jest referencyjna aplikacja na Androida. Hm - może szybciej będzie wziąć ich aplikację i przenieść waszą funkkcjonalność do niej @MateuszRomanow -> to by mogło zaoszczędzić sporo czasu IMHO.
@tomekziel - no i nawet jest referencyjna aplikacja na Androida. Hm - może szybciej będzie wziąć ich aplikację i przenieść waszą funkkcjonalność do niej @MateuszRomanow -> to by mogło zaoszczędzić sporo czasu IMHO.
Biorąc pod uwagę, że przygotowania "końcówek" modułów pod decentralizację (np. obliczenia analizy ryzyka zarażenia lokalne a nie na serwerze) trwają po naszej stronie od jakiegoś czasu, a spora część tych prac pokrywa się z G+A raczej zostaniemy przy integracji naszej app, ta praca jest cały czas wykonywana. Dodam jeszcze, że w dużej mierze G+A nie dają wielu elementów, więc to nie jest niestety automagiczne rozwiązanie, wymaga dużo pracy po stronie lokalnych zespołów developerskich i lokalnych Health Authorities.
Jasne. Dzięki za wytłumaczenie!
Napisałem artykuł o tym, jak sprawdzać zawartość komunikatów nadawanych przez aplikację: https://informatykzakladowy.pl/co-tak-naprawde-aplikacja-protego-safe-nadaje-przez-bluetooth/
Do dziś nikt nie powiedział ministrowi, że z tą prywatnością rodem z OpenTrace to nie do końca jest tak, jak on mówi.
Propsy. Czytałem. Pochwalam 👍
Aktualizacja od Ponoptykonu: https://panoptykon.org/czy-instalowac-protego-safe . W związku z rozwiązaniem tych wątpliwości wątek można zamknąć w ciągu kilku dni.
Describe the bug Bug ten dotyczy kwestii spełnienia 7 filarów zaufania, aby ludzie chętnie chcieli instalować aplikację i jednocześnie rząd nie mógł ich inwigilować.
Filary zaufania:
Niespełniony: aplikacja prosi m.in. o imię - informację niepotrzebną do przeprowadzenia oceny ryzyka infekcji. Aplikacja wysyła IP wraz z zaznaczonymi odpowiedziami, mimo, że mogłaby użyć Tora do anonimizacji tej informacji lub ocenę przeprowadzić lokalnie (i tym sposobem też szybciej). Aplikacja woli wysyłać dane, zamiast zassać z serwera template lub JavaScript do lokalnej oceny ryzyka / prowadzenia dziennika.
Czy regulamin zawiera informację jak długo (najdłuższy możliwy czas) będą przechowywane logi żądań do serwera oraz inne informacje?
Niespełnione - dane w żądaniach safesafe.app lecą w zapytaniach "diagnosis" na serwer, podczas, gdy wyliczenie ryzyka infekcji można wykonać lokalnie.
Trudno mówić o anonimizacji wysyłanych danych, gdy te po stronie serwera do oceny ryzyka są rozszyfrowywane przez serwer docelowy i jednocześnie serwer ten zna IP nadawcy. Nawet jeżeli łączymy się z proxy - aby wysłać dane dalej po https - musi dojść do rozszyfrowania żądania (i jest tu komplet danych - zaznaczone i wpisane choroby + IP) a następnie zaszyfrowania kolejnym kluczem i wysłać na serwer dokonujący właściwej oceny ryzyka. Wciąż istnieje serwer, który wie za dużo (zna prawdziwe IP).
Zastosowanie Tora (i nieblokowanie go) pozwoliłoby ten punkt spełnić. Pozwoli też spełnić ten punkt lokalna ocena ryzyka.
Niespełniona. Ekipa nie dba o tworzenie specyfikacji (specs) na bieżąco i zgodnie ze stanem faktycznym aplikacji. "Nie mamy czasu" pogarsza tylko spełnienie tego punktu. może nie należy tak szybko kodować? Może warto tworzyć ją automatycznie w oparciu o Doxygen?
Niespełnione w zakresie przejrzystości - specyfikacja nieaktualizowana na bieżąco, co nie pozwala zapoznać się "nieprogramistom". Nie tylko programiści powinni móc się zapoznać z rzeczywistym stanem aplikacji.
Kod serwera nie jest otwarty. Niespełniony jest więc też wymóg otwartego kodu.
Niespełnione - brak audytu. Gazeta.pl już napisała w jak opłakanym stanie zdaniem ekspertów jest stan poszanowania prywatności użytkowników.
To Reproduce Steps to reproduce the behavior: Po prostu uruchom aplikację, włącz tryb F12 przeglądarki lub uruchom odpowiedni debugger pozwalający stwierdzić komunikację aplikacji z serwerami.
Expected behavior Spełnione 7 filarów zaufania organizacji zajmującej się prywatnością i wolnością obywateli Polski - Panoptykonu.
Screenshots Nie przewidziano - wystarczy wejść na stronę Panoptykonu i wykonać screenshota ich strony.
Desktop (please complete the following information): Nieistotne dla tego problemu.
Smartphone (please complete the following information): Każdy z zainstalowaną aplikacją Protego-Safe lub uruchomioną aplikacją safesafe.app.
Additional context Spełnienie wymagań stawianych przez społeczeństwo (obywateli, nie rząd) od aplikacji, która śledzi "prognozę infekcji".