Closed SeraMoon closed 4 years ago
KoderFPV
commented
4 years ago Obawiam się że usuwanie funkcji ratujących życie ludzkie może być trudne do przeforsowania.
A w #129 ustalenia były pomiędzy @seraMoon a @potiuk. Wygląda że wy to ustaliliście a nie projekt.
potiuk
commented
4 years ago Obawiam się że usuwanie funkcji ratujących życie ludzkie może być trudne do przeforsowania.
A w #129 ustalenia były pomiędzy @SeraMoon a @potiuk. Wygląda że wy to ustaliliście a nie projekt.
Może dlatego, że nie raczyliście się odnieść do tego. A może tu napiszesz @Tarvald dlaczego ocena zdrowia wymaga łączenia się z serwerem? Czy jest choć jeden konkretny powód?
potiuk
commented
4 years ago Obawiam się że usuwanie funkcji ratujących życie ludzkie może być trudne do przeforsowania.
To już jest jawna manipulacja, niestety. @SeraMoon nie twierdzi, żeby usunąć tą ratującą życie funkcjonalność, tylko żeby była uruchamiana lokalnie. A ty mówisz że powiedziała co innego.
KoderFPV
commented
4 years ago @potiuk Powodem jest wykorzystywanie https://infermedica.com/ do oceny ryzyka pacjenta. Ponad 20 lekarzy pracuje nad algorytmem i wiele instytucji na świecie.
Temat #129 na tą chwile nie porwał społeczności ProteGo. Narazie to wasza wewnętrzna dyskusja.
A profilaktyka w zapobieganiu COVID ratuje życie. To nie manipulacja, a fakt.
SeraMoon
commented
4 years ago Może dlatego, że nie raczyliście się odnieść do tego. A może tu napiszesz @Tarvald dlaczego ocena zdrowia wymaga łączenia się z serwerem? Czy jest choć jeden konkretny powód?
Napiszę za niego - dlatego by była niedostępna w razie przeciążenia serwera i aby dało się zrobić DDoS i odebrać prywatność użytkownikom. 😹 Również po to by musieli płacić za internet lub nie mając internetu nic nie mogli zrobić np. gdy dojdzie do jakiejś klęski takiej jak NIEREALNE spalenie centrum T-Mobile, które miało miejsce nie tak dawno i nie było połączenia. Aplikacja działająca lokalnie dalej oceniałaby zdrowie w sensie Covid-19 z tą różnicą że robiłaby to o brak aktualizacji wg o tydzień przeterminowanych reguł - wciąż lepszych niż nic.
Powodem jest wykorzystywanie https://infermedica.com/ do oceny ryzyka pacjenta. Ponad 20 lekarzy pracuje nad algorytmem i wiele instytucji na świecie.
Pracuje w sposób zamknięty i nie jest to publicznie dostępne? Czyli jednak losowanie z kapelusza?
Na powyższe problemy - wszystkie - zaradziała zrobienie tego w czystym JS bez XHR.
KoderFPV
commented
4 years ago @SeraMoon Aplikacja działająca lokalnie nie mogła by tak dobrze oceniać ryzyka jak https://infermedica.com/. Nie mamy takiego doświadczenia jak oni.
Obrone przed atakiem DDoS zapewnia nam cloudflare, jak większości światowego internetu.
A faktycznie, w przypadku kataklizmów i braku internetu nie mamy jeszcze rozwiązania. Ale jak tylko uporamy się z COVID to się tym zajmiemy :)
SeraMoon
commented
4 years ago Więc nie ma solidarności bo kod jest pseudootwarty. Skoro może działać lokalnie to tak powinna działać a my powinniśmy zapytać gdzie jest spisany ten algorytm i go co tydzień sprawdzać czy nie uległ zmianie. Nie generuje to nakładów, bo zmiany specyfikacji można śledzić botem.
Ale jak tylko uporamy się z COVID to się tym zajmiemy :)
Kataklizm może nastąpić nawet niebawem, gdy palą maszty 5G! Po ustaniu COVID-19[84] to już nie ma po co robić tej aplikacji, szczególnie gdy się okaże, że nabywamy odporność.
KoderFPV
commented
4 years ago @SeraMoon W sprawie algorytmów infermedia, kieruj pytania do nich. Z tego co wiem dostęp do ich dokumentacji może dostać każdy :)
SeraMoon
commented
4 years ago @SeraMoon W sprawie algorytmów infermedia, kieruj pytania do nich. Z tego co wiem dostęp do ich dokumentacji może dostać każdy :)
Jestem programistką, ale nie programuję w tym projekcie abym ja o to prosiła. Swoją prośbę o dokumentację intermedici - poproś aby programiści zaangażowani w rozwijanie projektu ją uzyskali. Jeżeli ja uzyskam tą dokumentację to ja zrobię stronę do oceny ryzyka zdrowotnego i cały projekt straci sens, bo przeglądarkę ma każdy, a androida i iOS tylko wybrani 😉
Mając dokumentację intermedici - zwyczajnie siądę - napiszę to w 5 dni i kupię domenę i tyle.
KoderFPV
commented
4 years ago @SeraMoon Możesz sobie sama załątwić tą dokumentacje. Naprawde nas nie potrzebujesz do tego :) Dasz rade. Skoro każdy może ją dostać, to napewno i ty :)
Mając dokumentację intermedici - zwyczajnie siądę - napiszę to w 5 dni i kupię domenę i tyle.
Smiało! Możesz też zrobić pull requesta i ulepszyć już ten nasz istniejący proces.
SeraMoon
commented
4 years ago Ja dyskusję kończę pozostawiając dokument z ECDC dotyczący oceny ryzyka COVID-19. https://www.ecdc.europa.eu/sites/default/files/documents/covid-19-rapid-risk-assessment-coronavirus-disease-2019-ninth-update-23-april-2020.pdf
Zakończenie z mojej strony (rtzynajmniej czasowo) dyskusji nie oznacza, że inne osoby nie będą chciały też zając stanowiska w tym temacie. Stwierdzam nadal, że zrobienie algorytmu oceny stanu zdrowia jest możliwe lokalnie chociażby w kilku scenariuszach:
BTW. przypominam o możliwości użycia Tora lub I2P do czasu implementacji lokalnej oceny ryzyka.
KoderFPV
commented
4 years ago @SeraMoon Przy obecnej stanie epidemii, dynamiki działań oraz priorytetów, znacznie rozsądniejszym jest skorzystanie z doświadczenia naszych partnernerów w postaci https://infermedica.com/ na tym etapie developmentu, kiedy nie mamy własnych rozwiazań.
@SeraMoon Może zrobisz forka repozytorium i pokażesz jak łatwo i szybko wydevelopować takie algorytmy lokalne, aby jak najszybciej wspomóc walke z COVID?
potiuk
commented
4 years ago @SeraMoon Aplikacja działająca lokalnie nie mogła by tak dobrze oceniać ryzyka jak https://infermedica.com/. Nie mamy takiego doświadczenia jak oni.
@Tarvald Czy ja dobrze rozumiem że odpowiedzi na prosty kilku-krokowy kwestionariusz ryzyka nie jesteście w stanie ocenić lepiej niż https://infermedica.com/. A już to czy kontakt BT jest grożny potraficie ocenić lepiej niż Google + Apple w ich algorytmie opisanym w https://www.apple.com/covid19/contacttracing ? Czy ja to dobrze rozumiem ?
@Tarvald - proszę popraw mnie jeśli się mylę, ale tak to wygląda.
Poza tym Muszę Cię znowu @Tarvald wyprowadzić z błędu. Telemedi nie publikuje algorytmu ale mówią o "Outstanding AI technology". Według mojej wiedzy na temat AI - a 1.5 roku pracowałem w firmie która zajmowała się AI - to jest problem, który nie wymaga AI w ogóle, tylko o wiele lepiej sprawdziło by się podejście klasyczne, Mam zamiar to jeszcze sprawdzić z dr habilitowanym z Uniwersytetu Warszawskiego, który jest światowym ekspertem od sztucznej inteligencji i zapytać go o to, ale moim skromnym zdaniem AI do tego jest słabym pomysłem.
Poza tym - nawet jeśli musicie to wysłać do Intermedica, to obecna specyfikacja wprowadza użytkowników w błąd. Mówi o anonimowej informacji przekazywanej do Intermedica. A nie mówi że ta informacja jest przekazywana na serwery którymi zarządza Ministerstwo Cyfryzacji. Ta informacja nie jest nigdzie umieszczona.
Cytuję za https://github.com/ProteGO-Safe/specs#anonimowo%C5%9B%C4%87-i-bezpiecze%C5%84stwo
Co do zasady dane przechowywane są na urządzeniach użytkowników. Wszystkie informacje dotyczące zdrowia (wpisy w Dzienniku Zdrowia), a także historia spotkanych urządzeń (Temp ID) są przechowywane na urządzeniach użytkowników. Na serwer zewnętrzny (API Infermedica) przekazywana jest anonimowa informacja związana z triażem (samooceną stanu zdrowia/ Test Oceny Ryzyka).
Tak jak już szeroko opisywałem w #123 - jeśli adres IP jest wysyłany na serwer rządowy to powinien być traktowany jako dana osobowa, więc - paradoksalnie - o wiele lepszym rozwiązaniem niż przechodzenie danych przez serwer rządowy jest komunikacja bezpośrednia z serwerem Intermedica.
potiuk
commented
4 years ago @SeraMoon Przy obecnej stanie epidemii, dynamiki działań oraz priorytetów, znacznie rozsądniejszym jest skorzystanie z doświadczenia naszych partnernerów w postaci https://infermedica.com/ na tym etapie developmentu, kiedy nie mamy własnych rozwiazań.
Czy zatem nie lepiej skorzystać z rozwiązania Google + Apple do BT contact tracing ?
SeraMoon
commented
4 years ago Skoro można się kontaktować z intermedicą poprzez serwer MC - można się też kontaktować z nim bardziej anonimowo poprzez Tora lub I2P. Obecnie użytkownicy są wprowadzani w błąd.
I2P i Tor są za darmo, choć i tak lokalne rozwiązanie będzie lepsze bo zadziała po prostu nawet podczas problemów technicznych.
BTW. Sprawdzał ktoś co się stanie gdy w Response wróci
<sctipt> Alert(1); </script>
KoderFPV
commented
4 years ago @potiuk
@Tarvald Czy ja dobrze rozumiem że odpowiedzi na prosty kilku-krokowy kwestionariusz ryzyka nie jesteście w stanie ocenić lepiej niż https://infermedica.com/.
Tak, sądze że doświadczenia https://infermedica.com/ nie da się zreplikować w tak krótkim czasie, a napewno nie opiera się ono o proste formularze. Pod spodem dzieje się duzo wiecej rzeczy.
Mówi o anonimowej informacji przekazywanej do Intermedica. A nie mówi że ta informacja jest przekazywana na serwery którymi zarządza Ministerstwo Cyfryzacji.
Nic mi nie wiadomo o przekazywaniu takich informacji na serwery. Wydaje mi się że u nas działa tylko proste PROXY do https://infermedica.com/
Czy zatem nie lepiej skorzystać z rozwiązania Google + Apple do BT contact tracing ?
Lepiej, każdy z zespołu Protego to potwierdzi. Ale niestety rozwiązanie G+A jest nie dostępne, do tego jest w fazie testów i nie ma potwierdzonej daty premiery. A zegar tyka, ludzie umierają, chorują i tracą prace. Dlatego tak długo jak rozwiązania G+A nie będzie, to będziemy bazować na https://github.com/opentrace-community/opentrace-cloud-functions Wszelkie wątpliwości co do bezpieczeństwa oraz prywatności open trace prosilibysmy o dyskutowanie na ich forum.
@SeraMoon Obecnie komunikujemy się w aplikacji przez nasz serwer proxy.
SeraMoon
commented
4 years ago Nic mi nie wiadomo o przekazywaniu takich informacji na serwery. Wydaje mi się że u nas działa tylko proste PROXY do https://infermedica.com/
Problem w tym, że to proxy też loguje IP użytkownika i w ten sposób można za pośrednictwem ustawy o policji pozyskać dane (minimum imię, nazwisko i PESEL, lokalizację - bo tyle wymaga rejestracja SIM) wraz z udzielonymi odpowiedziami.
A zegar tyka, ludzie umierają, chorują i tracą prace.
Dlaczego nie było tego problemu w 2009 roku? Zbędny lockdown? Ile ludzi na świecie umarło na świńską i ptasią grypę? Sth went wrong na poziomie zakładania lockdownów i zamrażania gospodarki bez pomyślunku? A potem [zacytowałabym Korwina] "i...i mordują gospodarkę tarczami"?
Obecnie komunikujemy się w aplikacji przez nasz serwer proxy.
Czyli inwigilujemy użytkowników po to, aby przy pomocy "ustawy inwigilacyjnej" (o policji) MÓC zażądać potem imienia naziwksa, PESELu i lokalizacji osoby potencjalnie chorej wg systemu, który odpowiedź losuje z kapelusza (black box).
Gdu idzie wszystko przez proxy - prawda jest taka że mamy tmpID, wprowadzone ankiety wraz z IP na tym serwerze. Więcej mieć już się po prostu nie da bez zażądania dostępu do zdjęć, plików itp.
Kończę rozmowę ze swojej strony, ponieważ ktoś tu udaje, że nie widzi problemu zgłaszanego przeze mnie i zgłaszanego przez użytkowników aplikacji - może oni tu to lepiej wyjaśnią, bo widzę, że nie mam daru tłumaczenia problemów - przynajmniej Tarvaldowi. Szkoda mojego czasu.
KoderFPV
commented
4 years ago @SeraMoon
Dlaczego nie było tego problemu w 2009 roku? Zbędny lockdown? Ile ludzi na świecie umarło na świńską i ptasią grypę? Sth went wrong na poziomie zakładania lockdownów i zamrażania gospodarki bez pomyślunku? A potem [zacytowałabym Korwina] "i...i mordują gospodarkę tarczami"?
To nie jest miejsce na tego typu tematy. Nie dotyczy to bezpośrednio aplikacji ani kodu z nią związnego.
Problem w tym, że to proxy też loguje IP użytkownika i w ten sposób można za pośrednictwem ustawy o policji pozyskać dane (minimum imię, nazwisko i PESEL, lokalizację - bo tyle wymaga rejestracja SIM) wraz z udzielonymi odpowiedziami.
Będą prowadzone nad tym prace. Narazie bez https://infermedica.com/ nie ma profilaktyki. Jeżeli znasz albo potrafisz wytworzyc lokalne narzędzie do tego to zapraszamy do kolaobracji.
potiuk
commented
4 years ago Nic mi nie wiadomo o przekazywaniu takich informacji na serwery. Wydaje mi się że u nas działa tylko proste PROXY do https://infermedica.com/
O to proxy mi chodzi. Jak już wielokrotnie pisałem w #123 i #127 jeśli chodzi o klasyfikację IP jako dane osobowe nie świadczy to czy ktoś go aktywnie "de-anonimizuje" ale czy "może" to zrobić. Jako że proxy jest kontrolowane przez Minsterstwo Cyfryzacji, mają taką możliwość.
Skopiuję jeszcze raz tutaj żebyś nie musiał szukać:
zgodnie z obowiązującymi przepisami, adres IP jeśli może być używany do identyfikacji osoby jest daną osobową w szczególności jeśli podmiot który je przetwarza ma dostęp do danych pozwalających na powiązanie adresu IP z konkretną osobą:
Cytat: "Niemniej adres IP będzie uznawany za dane osobowe jedynie wówczas, gdy podmiot przetwarzający adres IP ma jednocześnie dostęp do danych łączących adres IP z innymi danymi identyfikującymi osobę. Do czasu, gdy podmiot nie uzyska pewności, że sam nie jest w stanie łączyć adresu IP z innymi danymi identyfikującymi osobę, powinien zabezpieczać adres IP tak jakby był on daną osobową."
Cytat ze strony GIODO: https://archiwum.giodo.gov.pl/pl/319/2258
Czy zatem nie lepiej skorzystać z rozwiązania Google + Apple do BT contact tracing ?
Ale niestety rozwiązanie G+A jest nie dostępne, do tego jest w fazie testów i nie ma potwierdzonej daty premiery.
Zdaje się że zapisaliście się do beta testów przedwczoraj. A wasze rozwiązanie jest dużo bardziej niesprawdzone i dalekie od wdrożenia, zwłaszcza że zdecydowaliście się je właśnie mocno zmienić (Jak opisał @MateuszRomanow w #134)
A zegar tyka, ludzie umierają, chorują i tracą prace. Dlatego tak długo jak rozwiązania G+A nie będzie, to będziemy bazować na https://github.com/opentrace-community/opentrace-cloud-functions
Zmowu manipulacja - i to bardzo gruba. Naprawdę prosiłbym Cię o nie używaniu argumentu o ratowaniu życia i pracy w tym kontekście. To jest nie do obronienia według mnie.
Aplikacja z Singapuru TraceTogether oparta na Open Trace osiągnęła po miesiącu 20% adopcji i w zasadzie to się zatrzymało (https://www.reuters.com/article/us-health-coronavirus-apps/bluetooth-phone-apps-for-tracking-covid-19-show-modest-early-results-idUSKCN2232A0). Jak możesz też przeczytać w tym artykule - aplikacja nawet gdyby była powszechna była by bardzo mało użyteczna w okresie "lock-down".
Ta aplikacja nie jest na czas lock-down, ale po "lock-down" a do tego jeszcze daleko. A poza tym jak twierdzi ponad 300 naukowców z całego świata (https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/view?fbclid=IwAR0uTvKD7HIbxo2QhyBQQaWdn2dCT-Q1-wVQiE3n8BuMGX_f0WCxvER-tUE) BT contact tracing jest tylko uzupełnieniem klasycznego "contact tracing".
Wszelkie wątpliwości co do bezpieczeństwa oraz prywatności open trace prosilibysmy o dyskutowanie na ich forum.
Zgodnie z #134 Wy teraz modyfikujecie "Open Trace" więc pytania kierujemy do Was.
KoderFPV
commented
4 years ago @potiuk
Zgodnie z #134 Wy teraz modyfikujecie "Open Trace" więc pytania kierujemy do Was. Nie modyfikujemy "Open Trace", używamy wersji nie zmodyfikowanej.
O to proxy mi chodzi. Jak już wielokrotnie pisałem w #123 i #127 jeśli chodzi o klasyfikację IP jako dane osobowe nie świadczy to czy ktoś go aktywnie "de-anonimizuje" ale czy "może" to zrobić. Jako że proxy jest kontrolowane przez Minsterstwo Cyfryzacji, mają taką możliwość.
Ministerstwo cyfryzacji nie zapisuje danych na temat profilaktyki. Jest to tylko proxy. Prosty skrypt nginx który zostanie opublikowany niebawem.
Zdaje się że zapisaliście się do beta testów przedwczoraj. A wasze rozwiązanie jest dużo bardziej niesprawdzone i dalekie od wdrożenia, zwłaszcza że zdecydowaliście się je właśnie mocno zmienić (Jak opisał @MateuszRomanow w #134)
Nasze rozwiązanie jest na bardzo zaawansowanym poziomie implementacji. Jest bliskie wdorżenia.
Zmowu manipulacja - i to bardzo gruba. Naprawdę prosiłbym Cię o nie używaniu argumentu o ratowaniu życia i pracy w tym kontekście. To jest nie do obronienia według mnie
To nie manipulacje. Profilkatyka oraz walka z koronowirusem ratuje życia i zdrowie ludzkie.
A co do sukcesu czy porażki TraceTogether, był spowodowany wieloma innymi czynnikami niż opentrace. To nie miejsce na takie dysksuje.
Możesz otworzyć wątek tutaj: https://github.com/opentrace-community/opentrace-cloud-functions
matsobdev
commented
4 years ago Może się nie znam. Już to wspomniałem gdzie indziej - 2 latek może wypalać 40 papierosów dziennie. Ponad 20 lekarzy nie może się mylić...
potiuk
commented
4 years ago @potiuk
Zgodnie z #134 Wy teraz modyfikujecie "Open Trace" więc pytania kierujemy do Was. Nie modyfikujemy "Open Trace", używamy wersji nie zmodyfikowanej.
No to teraz mamy @MateuszRomanow vs. @Tarvald.
Może dogadajcie się panowie (obaj mężczyźni więc pozwolę sobie zachować tę formę): Cytuję za #134:
@MateuszRomanow:
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).
vs.
@Tarvald
Nie modyfikujemy "Open Trace", używamy wersji nie zmodyfikowanej.
Komu mam wierzyć ?????????
Ministerstwo cyfryzacji nie zapisuje danych na temat profilaktyki. Jest to tylko proxy. Prosty skrypt nginx który zostanie opublikowany niebawem.
Jeszcze raz powtórzę cytat - chyba go nie przeczytałeś: "ma DOSTĘP do danych POZWALAJĄCYCH na powiązanie adresu IP z konkretną osobą". Przetłumaczę: nie chodzi o to co ktoś "robi" tylko czy "ma dostęp do danych POZWALAJĄCYCH" . Nie wiem czy to jest wystarczająco jasno napisane po polsku. Więc tłumaczę raz jeszcze: nie chodzi o to co ktoś w danej chwili rob, tylko to co "może" zrobić i ma dostęp do danych, które na to pozwalają.
Czy możesz mi odpowiedzieć na pytanie czy rozwiązanie o którym napisałęś UNIEMOŹLIWIA w przyszłości powiązanie IP z konkretną osobą?
To jest cytat ze strony rządowej. Więc chyba wiarygodny ?
Zdaje się że zapisaliście się do beta testów przedwczoraj. A wasze rozwiązanie jest dużo bardziej niesprawdzone i dalekie od wdrożenia, zwłaszcza że zdecydowaliście się je właśnie mocno zmienić (Jak opisał @MateuszRomanow w #134)
Nasze rozwiązanie jest na bardzo zaawansowanym poziomie implementacji. Jest bliskie wdorżenia.
Co to znaczy ? Czy rozwiązanie ze #134 już jest zaimplementowane? Czy chodzi o inne rozwiązanie. Przyznam że już trochę się gubię w tych zwrotach akcji.
Zmowu manipulacja - i to bardzo gruba. Naprawdę prosiłbym Cię o nie używaniu argumentu o ratowaniu życia i pracy w tym kontekście. To jest nie do obronienia według mnie
To nie manipulacje. Pozwolę się nie zgodzić. Jeśli TraceTogether Singapur nie działa do dziś po miesiącu i 20% adopcji to nie ma najmniejszych szans żeby zadziałało to szybko u nas https://www.wsj.com/articles/singapore-built-a-coronavirus-app-but-it-hasnt-worked-so-far-11587547805 - a rozwiązanie G+A ma działać bez aplikacji więc ma dużo większą szansę na adopcję.
Profilkatyka oraz walka z koronowirusem ratuje życia i zdrowie ludzkie.
Tu akurat się w 100% zgodzę. Jak już wielokrotnie pisałem, Czekam na to co rząd zaproponuje jeśli chodzi o darmowe i szybkie testy, klasyczny contact tracing. etc. Ale nie robi tego Aplikacja z BT contact tracing - w tej chwili i w takiej formie, ani nawet w najbliższej przyszłości. Niestety, to manipulacja.
A co do sukcesu czy porażki TraceTogether, był spowodowany wieloma innymi czynnikami niż opentrace. To nie miejsce na takie dysksuje.
Myślę że właśnie to jest miejsce na takie dyskusje - rozumiem że nie interesują was fakty dotyczące tej technologii już sprawdzanej przez innych, tylko wiecie sami lepiej. Pierwszy raz widzę inżynierów którzy bardziej polegają na ślepej wierze w coś a nie na faktach.
SeraMoon
commented
4 years ago Komu mam wierzyć ?????????
Nikomu, trzeba by wprowadzić trzecią osobę, która zawsze kłamie i ją zapytać 😉
Jeszcze raz powtórzę cytat
Never Ending Story... Choć tą bajkę się oglądało przyjemniej niż te chusteczki.
KoderFPV
commented
4 years ago No to teraz mamy @MateuszRomanow vs. @Tarvald. Może dogadajcie się panowie (obaj mężczyźni więc pozwolę sobie zachować tę formę): Cytuję za #134:
Nie mam żadnego @MateuszRomanow vs @Tarvald Obecnie używamy nie zmodyfikowanego https://github.com/opentrace-community/opentrace-cloud-functions Backend tak czy inaczej będzie przechodził dość sporo transformacji, ale obecna aplikacja wrzucona do sklepu korzysta z niezmodyfikowanych wersji open trace cloud functions.
Co to znaczy ? Czy rozwiązanie ze #134 już jest zaimplementowane? Czy chodzi o inne rozwiązanie. Przyznam że już trochę się gubię w tych zwrotach akcji.
Dlatego własnie że bardzo się gubisz w tym wszystkim, wprowadzasz społeczność w nieścisłości i zarzucasz inwigilacje. Obecnie korzystamy z: https://github.com/opentrace-community/opentrace-cloud-functions
I do czasu aż google i apple nie wyda oficjalnie swoich narzędzi, będziemy polegać na https://github.com/opentrace-community/opentrace-cloud-functions
W tym samym czasie, jest implementowana wersja beta oraz bedą prowadzone testy rozwiązania od G+A
Myślę że właśnie to jest miejsce na takie dyskusje - rozumiem że nie interesują was fakty dotyczące tej technologii już sprawdzanej przez innych, tylko wiecie sami lepiej. Pierwszy raz widzę inżynierów którzy bardziej polegają na ślepej wierze w coś a nie na faktach.
Nie, repozytorium GH nie jest miejscem na dywagacje polityczne, problemy egzystencjonalne oraz rozterki osobiste. Jeżeli masz lepsze technologiczne rozwiązanie, prosimy o stworzenie odpowiedniego pull requesta.
Jeszcze raz powtórzę cytat - chyba go nie przeczytałeś: "ma DOSTĘP do danych POZWALAJĄCYCH na powiązanie adresu IP z konkretną osobą". Przetłumaczę: nie chodzi o to co ktoś "robi" tylko czy "ma dostęp do danych POZWALAJĄCYCH" . Nie wiem czy to jest wystarczająco jasno napisane po polsku. Więc tłumaczę raz jeszcze: nie chodzi o to co ktoś w danej chwili rob, tylko to co "może" zrobić i ma dostęp do danych, które na to pozwalają.
Kupując, rejestrując i używając karty SIM dokładnie narażasz się na te same problemy.
Wątek już dawno odbiegł od treści tematu. Więc przypomne, nie zamierzamy na tą chwile rezygnować z rzeczy które mogą ratować życie i zdrowie.
SeraMoon
commented
4 years ago Wątek już dawno odbiegł od treści tematu. Więc przypomne, nie zamierzamy na tą chwile rezygnować z rzeczy które mogą ratować życie i zdrowie.
To może jeszcze sami wezwijcie karetkę zamiast wyświetlać czerwony status XD skoro nie chcecie tego zrobić
Piszę jak do MC - bo MC jest opiekunem tego projektu.
potiuk
commented
4 years ago Obecnie używamy nie zmodyfikowanego https://github.com/opentrace-community/opentrace-cloud-functions
Czy możesz potwierdzić i wykazać że nie zrobiliście ani jednej zmiany w tym kodzie? Czy jest to napisane gdzieś w speyfikacji? W jaki sposób to nie jest zmodyfikowane skoro opentrace używa numerów telefonów a wy nie? Czy mógłbyś to wytłumaczyć @Tarvald ? W jaki sposób można to zweryfikować?
Co to znaczy ? Czy rozwiązanie ze #134 już jest zaimplementowane? Czy chodzi o inne rozwiązanie. Przyznam że już trochę się gubię w tych zwrotach akcji.
Dlatego własnie że bardzo się gubisz w tym wszystkim, wprowadzasz społeczność w nieścisłości i zarzucasz inwigilacje.
Kolejna manipulacja. To wy wprowadzacie co chwila zmiany nie odpowiadacie na pytania (na przykład w tym wpisie pierwszy raz - mimo zadawania pytań wielokrotnie) dostajemy odpowiedź (z resztą chyba niepełną na temat backendu). Mętnie się tłumaczycie, nie aktualizujecie specyfikacji, informujecie o zmianach w pobocznych wątkach (np. #134), To nie ja wprowadzam zamęt, tylko wy.
Obecnie korzystamy z: https://github.com/opentrace-community/opentrace-cloud-functions
Powtarzam:
Czy możesz potwierdzić i wykazać że nie zrobiliście ani jednej zmiany w tym kodzie? Czy jest to napisane gdzieś w speyfikacji? W jaki sposób to nie jest zmodyfikowane skoro opentrace używa numerów telefonów a wy nie? Czy mógłbyś to wytłumaczyć @Tarvald ? W jaki sposób można to zweryfikować?
I do czasu aż google i apple nie wyda oficjalnie swoich narzędzi, będziemy polegać na https://github.com/opentrace-community/opentrace-cloud-functions
Znowu mamy @MateuszRomanow vs. @Tarvald :
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
Jeśli ja dobrze rozumiem tą zmianę - to na serwer ma być wysyłana: a) lista kontaktów z innymi osobami b) tylko lista własnych TempID
Czy możesz potwierdzić ty lub @MateuszRomanow który z tych wariantów wchodzi w grę?
Jeśli a) to nic to nie zmienia w kwestii prywatności i wracamy do punktu wyjścia Jeśłi b) to trzeba zmodyfikować cloud function
Z Twojego wytłumaczenia zakładam że a) - czyli mogę spokojnie poinformować Panoptykon, że nic się nie zmieniło (jeśli nie dostanę odpowiedzi, to tak zakładam) Jeśli b) to obecnie zbierane dane są bezużteczne i należy natychmiast zaprzestać ich zbierania.
A może jest opcja c) o której nie pomyślałem? proszę bardzo o odpowiedź.
W tym samym czasie, jest implementowana wersja beta oraz bedą prowadzone testy rozwiązania od G+A Super.
Myślę że właśnie to jest miejsce na takie dyskusje - rozumiem że nie interesują was fakty dotyczące tej technologii już sprawdzanej przez innych, tylko wiecie sami lepiej. Pierwszy raz widzę inżynierów którzy bardziej polegają na ślepej wierze w coś a nie na faktach.
Nie, repozytorium GH nie jest miejscem na dywagacje polityczne, problemy egzystencjonalne oraz rozterki osobiste.
Czytałe CODE of CONDUCT? Prosiłbym o brak wycieczek osobistych - moje uwagi są tylko do rozwiązania, konkretnych stwierdzeń które padły w dyskusjach, i uwag w kwestii prywatności. Te ostatnie są jak najbardziej na miejscu, a to że cytuję filozofów i mówię o zewnętrznych warunkach które sprawiają że na "state level adversary" powinno się zwracać uwagę i dlaczego, jest zwykłym uzasadnieniem moich opinii. Staram się podawać źródłą moich opinii żeby były wiarygodne.
Jeżeli masz lepsze technologiczne rozwiązanie, prosimy o stworzenie odpowiedniego pull requesta.
Mam. Protokół G+A. Nie będę tracił czasu sam na implementację. Czytając uważnie specyfikację, widzę że to jest możliwe - co proponują, ma szansę być skuteczne i dobrze zrobione. Nie byłbym w stanie tego wymyślić i zrobić lepiej, bardziej prywatnie i bezpiecznie. Jestem w stanie zaufać, że zrobią to lepiej.
Jeszcze raz powtórzę cytat - chyba go nie przeczytałeś: "ma DOSTĘP do danych POZWALAJĄCYCH na powiązanie adresu IP z konkretną osobą". Przetłumaczę: nie chodzi o to co ktoś "robi" tylko czy "ma dostęp do danych POZWALAJĄCYCH" . Nie wiem czy to jest wystarczająco jasno napisane po polsku. Więc tłumaczę raz jeszcze: nie chodzi o to co ktoś w danej chwili rob, tylko to co "może" zrobić i ma dostęp do danych, które na to pozwalają.
Kupując, rejestrując i używając karty SIM dokładnie narażasz się na te same problemy.
Nie rozumiem. To zdanie jest bez sensu w kontekście tego co powyżej.
Wątek już dawno odbiegł od treści tematu. Więc przypomne, nie zamierzamy na tą chwile rezygnować z rzeczy które mogą ratować życie i zdrowie.
A ja powtórzę że powtarzanie czegoś nie sprawia że staje się prawdą. Jeśli odpowiedź na moje pytanie powyżej jest a), to jutro Panoptykon będzie miał jasną sytuację (bo na razie są zagubieni). Jeśli b) to to co jest teraz powinno się wyłączyć. Czekam na odpowiedź.
SeraMoon
commented
4 years ago Podsumowując - zaczęło się jechanie po stosie pod adrese od 0xFFFFFFFD do 0x00400000. Coś nie wytrzymało tu próby czasu i zamazany jest nawet adres powrotu z funkcji. :wink: Trzeba powiadomić Panoptykon. Niebezpiecznik już napisał rzeczowy artykuł - robiąc też przy okazji zapewne audyt kodu i sprawdzając fakty. Warto aby Panoptykon skontaktował się z Niebezpiecznikiem i również co nie co napisał w jakiej atmosferze powstaje projekt:
Przy takich niedociągnięciach to
potiuk
commented
4 years ago @SeraMoon -> Panoptykon jest cały czas zaangażowany. Żeby nie być gołosłownym. Tu jest link do komentarza który Kasia Szymielewicz napisała w komentarzu do wpisu minister Anny Streżyńskiej na temat mojego wywiadu u Artura Kurasińskiego: https://www.linkedin.com/feed/update/urn:li:activity:6662730656147218432?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6662730656147218432%2C6662760981564796928%29
Zacytuję wpis w całości:
Tak, nasza analiza #ProteGOSafe właśnie się pisze. Korzystamy z resztą garściami z dyskusji programistów na githubie, min. z argumentów Jarek Potiuk (dzięki!). Z drugiej strony konfrontujemy te ryzyka z Mateusz Romanów (dzięki za otwarty kanał komunikacji), co powoduje, że od piątku kręcimy się trochę w kółko.... Przyznam, że pierwszy raz śledzę proces tak dynamiczny, pełen niezrozumiałych zwrotów akcji i sprzecznych komunikatów, którego owocem "ma być" (bo przecież że ta aplikacja już działa na telefonach żywych ludzi!!!) narzędzie sygnowane przez organy państwa, służące celom publicznym. Bardzo bym chciała móc przeczytać porządne DPIA albo niezależną ocenę ryzyka, a nie tracić czas na śledzenie wątków na githubie. Jedynym słowem: to najcięższa analiza narzędzia, z jaką miałam do czynienia. Ale opublikujemy nasze "best understanding" we wtorek rano.
miklobit
commented
4 years ago Im głębiej kopię po polityce prywatnosci aplikacji tym katastrofa prywatności robi się większa.
W polityce prywatności , §3 , jest przywołany zewnętrzny link do https://infermedica.com/privacy-policy
A tam możemy tam przeczytać m.in. co firma zamierza robić z otrzymanymi od nas (czyli wysłanymi do niej z aplikacji) danymi. Np jakim innym firmom je udostępnia lub daje sobie takie prawo.
W p.5. "What we can do with your data" mamy tam m.in. "...HubSpot, Google, Facebook, LinkedIn, Twitter, HotJar" oraz "subcontractors with whom we cooperate. Infermedica przyznaje tam również, że dane moga trafić poza obszar EU i zakres ochrony RODO.
To jeszcze raz, WIELKIMI LITERAMI: przyznanie sobie prawa do dzielenia się naszymi medycznymi danymi ze wszystkimi największymi światowymi gigantami internetu, powinno natychmiast i nieodwołanie dyskwalifikować taką firmę jako wiarygodnego partnera tej aplikacji.
Mam nadziejęm że Panoptykon nie pominie tego mega zagrożenia w swojej analizie.
SeraMoon
commented
4 years ago Proponuję też spojrzeć na przykład tutaj na triaż. The Lancet raczej cieszy się zaufaniem. Całkiem inny zakres zmierzonej temperatury do podjęcia działań.
https://www.thelancet.com/journals/lanres/article/PIIS2213-2600(20)30071-0/fulltext#fig1
Jak patrzę na te formularze i oficjalne wytyczne diagnostyczne to zaczynam odnosić wrażenie, że api zwraca dane z kapelusza.
Tak, nasza analiza #ProteGOSafe właśnie się pisze.
Czyli już pora zmienić nazwę aplikacji na ProtamteGO :wink: i zacząć pracę w innym zespole, który podoła tematowi prywatności, jako aplikacji zamiennej dla ProteGO.
bartosztomczak
commented
4 years ago Proszę państwa - jeśli ktokolwiek z państwa jest w stanie napisać odpowiedni moduł do aplikacji web, iOS czy Android to zapraszamy do współpracy w formie nowej gałęzi repozytorium dla wymienionych platform. Zaznaczam, że dla zachowania jakichkolwiek standardów wymaganych obecnie od aplikacji takich jak nasza jest. a) opracowanie takiego testu zgodnie z wytycznymi WHO, Instytutu Roberta Kocha
kierepka
commented
4 years ago Proszę państwa - jeśli ktokolwiek z państwa jest w stanie napisać odpowiedni moduł do aplikacji web, iOS czy Android to zapraszamy do współpracy w formie nowej gałęzi repozytorium dla wymienionych platform. Zaznaczam, że dla zachowania jakichkolwiek standardów wymaganych obecnie od aplikacji takich jak nasza jest. a) opracowanie takiego testu zgodnie z wytycznymi WHO, Instytutu Roberta Kocha
Prośba o podanie tego repozytorium. Nasza aplikacja wykonana podczas hackhathonu HackTheCrisis pod nadzorem @Dr-Kownacki była całkowicie zdecentralizowana i tylko i wyłącznie użytkownik decydował o danych i co z nimi się stanie. Chętnie napisałbym to jeszcze raz bazując na nowych wytycznych i zrobił to tak by było zgodne z protokołem użytym zarówno tutaj w tej aplikacji jak i zgodne z nowymi wytycznymi G&A (można by jeszcze dodać wykrywanie innych protokołów) - czyli w pełni zgodna z wytycznymi aplikacja i jeszcze łącząca z innymi protokołami. Nasze repozytorium to CoronaLog
KoderFPV
commented
4 years ago Hej, Wątek już dawno odbiegł od tematu więc i tutaj podsumuje
Nie zamierzamy usuwać w pełni działającego i pomagającego ludziom modułu profilaktycznego. Ludzie potrzebują narzędzi aby być zdrowymi i wrócić do pracy. Pomaga ona w zapobieganiu oraz rozprzestrzenianiu się choroby.
https://infermedica.com/ nie zna IP użytkowników. Są one wycinanie na poziomie proxy.
@SeraMoon @potiuk Następnym razem prosilibyśmy o zakładanie osobnych wątków na poszczególne nieścisłości, a najbardziej zachęcamy do tworzenia pull requestów ze zmianami!
Ale dziękuje za zaangażowanie :)
@kierepka Zapraszam do dyskusji w innym wątku. Ten został przyciemniony przez wiele nie związanych z nim problemów.
SeraMoon
commented
4 years ago https://infermedica.com/ nie zna IP użytkowników. Są one wycinanie na poziomie proxy.
Ale proxy zna a Ministerstwo Cyfryzacji może te dane nagrywać po stronie proxy i dane imienne pozyskać od telekomów. @potiuk czy ten wątek zamknięto poprawnie?
bartosztomczak
commented
4 years ago Wątek nie jest usuwany. To issue można ponownie otworzyć - jeśli ktokolwiek z was jest w stanie napisać albo zna osobę, która może napisać odpowiedni moduł do aplikacji web, iOS czy Android. Taki który zastąpi proponowana do wyłączenia funkcjonalność to zapraszamy do współpracy najlepiej w formie nowej gałęzi repozytorium wybranej platformy.
Od tej i wszystkich aplikacji takich jak nasza - wymagana jest współpraca z lekarzami i opracowanie testu zgodnie z wytycznymi WHO, Instytutu Roberta Kocha oraz lokalnych instytucji zdrowia publicznego. Firma z której usługi obecnie korzystamy spełnia wymogi RODO, jest oparta na lokalnej myśli technicznej i medycznej oraz zaufało jej wiele europejskich firm nie mówiąc już o polskim PZU. Powstała w 2012 roku. Zatrudnia ponad 85 osób. Ma silnik diagnostyczny o dokładności 93%. Wspiera 17 języków. Dokonano w ten sposób ponad 5-ciu milionów diagnoz.
To co w tej chwili jest zintegrowane w aplikacji web to test samooceny czyli pierwsze, istotne źródło wiedzy o aktualnym stanie użytkownika. Nie ma również funkcjonalnego odpowiednika w propozycji google+apple ani innych znanych nam dystrybuowanych systemach. Skupiają się one wyłącznie na informacjach z modułów bluetooth.
Jeszcze raz podkreślę - jeśli istnieje dzisiaj jakieś alternatywne rozwiązanie tego typu, które można uruchomić lokalnie w pamięci przeglądarki albo na urządzeniu mobilnym to prosimy o ich wskazanie.
Chętnie zintegrujemy taką funkcjonalność. Ustalmy tylko założenia minimalne: a) rozwiązanie istnieje i spełnia powyższe wymagania dotyczące metody diagnozy b) jest przynajmniej tak dobrze opisane i funkcjonujące jak obecne c) nie obniża bezpieczeństwa platformy
bartosztomczak
commented
4 years ago Proxy działające w ramach naszego backend'u będzie miało znaną publicznie konfigurację. Z wyłączeniem kluczy autoryzacyjnych do api.infermedica.com oczywiście. Szukamy również metody na dostarczenie dowodu na to, że wewnętrznie proxy nie będzie logowało adresów IP normalnych połączeń. Jest to jednak poważne naruszenie zasad bezpieczeństwa systemów informatycznych. W normalnych projektach brak logowania zdarzeń dla tak istotnego elementu infrastruktury byłby ( i słusznie) poczytany jako skrajne zaniedbanie. Brak informacji w logach to brak śladu po ewentualnych nadużyciach i czerwona lampka u audytora.
potiuk
commented
4 years ago @bartosztomczak - zaproponowałem alternatywne rozwiązanie - bezpośredni kontakt z intermedica
Są dwa problemy:
Nie uważam że ten problem jest rozwiązany.
bartosztomczak
commented
4 years ago @miklobit Przytoczony dokument to część dotycząca strony www.infermedica.com. Nie API. Nawet tutaj można przeczytać, że w wymienionych systemach analitycznych do których się oficjalnie przyznają i stosują na własnej stronie www stosowane są mechanizmy pseudonimizacji adresów IP klienta. Na przykład sekcja dotycząca google analytics. W temacie API proponuję zadać firmie bezpośrednie pytanie o to jakich standardów przestrzega w odniesieniu do swojej usługi. My naprawdę nie jesteśmy ich działem prasowym. Można również poprosić o wgląd w zgromadzone na nasz temat dane. Ciekawi mnie jak odpowiedzą na to pytanie bez prawdziwych danych personalnych. Wydaje się to sensowne skoro część z Państwa proponuje teraz dla odmiany wysyłanie tych danych bezpośrednio do tej firmy. To o co w końcu chodzi? W kontekście istnienia rozwiązania apple i google i rzekomego zamieszania. My nic nie kręcimy. Część naszego zespołu pracuje nad rozszerzeniem opentrace (nie jest to jeszcze w środowisku produkcyjnym ani w aplikacjach dostępnych w sklepach). Druga część zespołu analizuje rozwiązanie które dla jednych już jest, według innych dopiero się tworzy a wg. nas jest z założenia niekompletne. Pierwszą porcję prawdziwej dokumentacji otrzymaliśmy jeśli mnie pamięć nie myli w piątek. Na tym etapie nie jest to rozwiązanie które można kompleksowo choćby przetestować. I co jest super ważne w kontekście tego wątku Nie ma nawet w planach integrowania w nim testu oceny ryzyka. Uwzględnia wyłącznie sygnały płynące z analizy naszej listy kontaktów zebranych po bluetooth. To na podstawie tych danych i publikowanych kluczy osób zarażonych jest wyliczane ryzyko ekspozycji. Zwracam też uwagę na to, że dane o zakażonych mają w założeniu "dostać" się do systemu od Odpowiednich organów zdrowia dla danego kraju. A wyniki tego wszystkiego co się w tak piękny zdecentralizowany sposób dzieje na telefonie mają docelowo trafić na "centralny serwer". To tyle co mam do powiedzenia w temacie tak zwanych zdecentralizowanych systemów MEDYCZNYCH. Reasumując nie mylmy testu oceny ryzyka z kalkulacją potencjalnej ekspozycji bo to są dwie kompletnie różne rzeczy. Biorąc natomiast pod uwagę skalę możliwości tych firm. Na przykład możliwość wystawienia dodatkowych api we własnych sklepach czy wpływania bezpośrednio na posiadane platformy. Większe możliwości w przygotowywaniu profili kalibracyjnych (głównie w tym względzie liczymy na apple). Nie możemy ignorować istnienia tej inicjatywy. Dlatego bez namysłu godzimy się na udział w testach beta. O ich terminach będziemy informować na bieżąco.
potiuk
commented
4 years ago Znowu jest przykład kiedy (moim zdaniem błędne) opinie są prezentowane jako fakty. Chciałem sprostować bo albo nie znasz tej specyfikacji, albo wprowadzasz ludzi w błąd celowo.
I co jest super ważne w kontekście tego wątku Nie ma nawet w planach integrowania w nim testu oceny ryzyka. Uwzględnia wyłącznie sygnały płynące z analizy naszej listy kontaktów zebranych po bluetooth. To na podstawie tych danych i publikowanych kluczy osób zarażonych jest wyliczane ryzyko ekspozycji.
@bartosztomczak - Analiza oceny ryzyka jest częścią API Google + Apple.
Transmission Risk — An app-defined flexible value to tag a specific positive key. This value could be tagged based on symptoms, level of diagnosis verification, or other determination from the app or a health authority
Zwracam też uwagę na to, że dane o zakażonych mają w założeniu "dostać" się do systemu od Odpowiednich organów zdrowia dla danego kraju. A wyniki tego wszystkiego co się w tak piękny zdecentralizowany sposób dzieje na telefonie mają docelowo trafić na "centralny serwer". To tyle co mam do powiedzenia w temacie tak zwanych zdecentralizowanych systemów MEDYCZNYCH.
Nieprawda. na serwer trafiają tylko "Temporary Exposure Keys". Wynik obliczeń nie trafiają na serwer. Polecam uważną lekturę https://www.apple.com/covid19/contacttracing/
Reasumując nie mylmy testu oceny ryzyka z kalkulacją potencjalnej ekspozycji bo to są dwie kompletnie różne rzeczy.
No właśnie API Google to bardzo dobrze łączy i daje wam możliwość odpowiedniego sparametryzowania tych algorytmów.
bartosztomczak
commented
4 years ago @potiuk Zanim wrócimy kolejny raz do "State Level adversary" proponuję zaznajomić szerszą publiczność z pozostałymi wrogimi aktorami. Pan się skupia na najwyższym możliwym poziomie i takie ma Pan prawo. Są też jednak bardziej "trywialne" przypadki a w kontekście aplikacji, która chociaż dotyka danych medycznych wszystkie powinniśmy traktować poważnie. Apeluję zatem o podzielenie się kompletnym modelem zagrożeń. Przydadzą się też jakieś konkretne wektory ataku.
W zasadzie tworzy Pan jeszcze wyższą klasę: "State Level adversary + kooperujący lokalny ISP + Google + Cloudflare". O ile w przypadku naszego kraju pierwsze dwa komponenty tego "Hiper Level adversary" potrafię sobie z łatwością wyobrazić to już Google, Apple i Cloudflare raportujące grzecznie i po cichu do naszego rządu maja w moim modelu prawdopodobieństwo dążące do zera. Oczywiście nie jest to to samo co zero. Na tym poziomie powinniśmy zakładać, że nie wiemy jakie są obecne możliwości technologiczne takiego przeciwnika a nawet który to może być "State".
Przepraszam jeśli przy poprzednich próbach podniesienia tego tematu odniósł Pan wrażenie, że nie traktujemy tematu poważnie. Jest dokładnie odwrotnie. Z tą jednak różnicą: Wiemy, że w obecnej sytuacji pozyskanie tych danych bezpośrednio od ISP's jest łatwiejsze, szybsze i istnieją do tego stosowne legalne procedury. Potwierdziła to również pośrednio inna osoba z doświadczeniami w pracy z takimi zapytaniami. Jeśli zatem Pana największym zmartwieniem jest nasz lokalny "State Level adversary" ... to proponowana metoda pozyskania czyjejś tożsamości jest bardziej skomplikowana i ryzykowna niż tego wymaga sytuacja prawna w tym kraju. Każdy telefon ma właściciela, nawet te na kartę. Stąd też nasza koncepcja ukrywania docelowego adresu samego systemu. Owszem koncepcja też nie idealna, ale do rekonstrukcji o której była mowa przydaje się docelowy adres IP. W naszym przypadku są to adresy wirtualne. Tysiące lub setki tysięcy użytkowników interntu w Polsce łączą się codziennie z adresami należącymi do cloudflare i google. Czy w przypadku wymieszania ruchu do naszego systemu z ruchem do tysięcy popularncyh serwisów nadal sprawia to dla Pana wrażenie "trywialne do zestawienia"? Jak widać z niektórych komentarzy trudno jest niektórym zrozumieć, że adres IP to nie to samo co lokalizacja. Pana o to nie podejrzewam. Oczywiście do pełni szczęścia brakuje nam implementacji "DNS over HTTPS" po stronie klientów bo w przeciwnym wypadku gotowy log zapytania o konkretną domenę usłużnie może podsunąć system DNS operatora internetu. Zbagatelizował Pan ostatnio ten wątek moich wypowiedzi. Bardzo proszę o informację dlaczego droga którą wyciekają nasze nawyki internetowe do sieci reklamowych wydaje się Panu mniej ważna niż własna hipoteza wielkiego skoku na adresy IP użytkowników tej jednej aplikacji. Co wg. Pana uzyskuje nowego nasz rodzimy "State Level adversary"? Poza pośrednim dowodem na to, że ktoś jeszcze korzysta z tej aplikacji. Piszę pośrednim bo z takiego połączenia nie wynika jeszcze co dzieje się w danym tunelu. Może właśnie aplikacja jest odinstalowywana?
Przy okazji tego strasznego kryzysu stała się też jedna, niewielka zmiana na którą od dawna liczyliśmy. Oczy całego świata technologicznego są skupione na jednym temacie. Czy uda się zrobić system bezpieczny dla prywatności użytkowników. Jeśli tak to czy jest na tyle użyteczny aby mogły go przyjąć np: wszystkie kraje członkowskie UE. A może będzie na tyle dobry, że zechcemy na jego podstawie zbudować prawdziwy system ochrony danych medycznych dla lokalnej służby zdrowia? Chcemy w tym uczestniczyć bo w końcu jest szansa coś w tym temacie zmienić. Jaka jest aktualna kondycja systemów bezpieczeństwa w placówkach medycznych i urzędach dowiadujemy się z mediów. Pytanie czy chcemy tylko krytykować czy proponujemy jakieś kompleksowe rozwiązanie.
Wracając do Pańskiej aktualnej propozycji. Czym dokładnie ma się różnić taki nowy ale jednak ten sam dostawca api? Ma Pan jakieś zakulisowe informacje, że ich ten "problem" nie dotknie? Czy jeśli zrezygnujemy hipotetycznie z własnego proxy to poprze Pan takie rozwiązanie? Nie będzie już nikomu przeszkadzało, że do tej firmy lecą prawdziwe IP klientów bez żadnej choćby próby anonimizacji?
Prawdziwa ironia polega na tym, że my staramy się obecnie bronić tego, co było już raz osiągnięte przez pionierską ekipę ProteGO. To pokazało ludziom zgromadzonym wokół safsafe.app, że jest metoda na współprace ze stroną rządową w modelu Open Source. To ProteGO miało odwagę zaproponować chmurę Google jako środowisko dla części serwerowej projektu. Powtarzam wybór odważny ale dla nas oczywisty. Szybkość i wysoka dostępność... oraz to, że i tak większość potencjalnych użytkowników takiej aplikacji ma już konto w tej firmie. Utworzyli je podczas pierwszej instalacji telefonu z Androidem... Naszą uwagę zwróciło też bardzo skrupulatne prowadzenie repozytoriów i dokumentacji. Niestety prace zostały zarzucone. Szkoda, może wtedy zamiast dopasowywania opentrace'a do rosnących wymogów opinii publicznej moglibyśmy korzystać z doskonałego rozwiązania ProteGO.
Projekt jest otwarty nie tylko do wglądu i krytyki. Jest otwarty bo niezbędny jest materiał edukacyjny do rozmów o bezpieczeństwie nowoczesnych systemów reagowania kryzysowego. Czekamy zarówno na review kodu jak i na propozycje usprawnień. Sterowanie infrastrukturą będzie się odbywało w ramach CI/CD zintegrowanego w tych konkretnych repozytoriach GitHub. Inaczej mówiąc jeśli dany nowy fragment kodu nie zostanie pozytywnie zaopiniowany przez wybraną przez nas liczbę osób w organizacji na GH - nic nowego się w systemie nie pojawi. To możemy zrobić i na to mamy wpływ. Przynajmniej do momentu kiedy ta organizacja będzie istnieć.
Transmission Risk — An app-defined flexible value to tag a specific positive key. This value could be tagged based on symptoms, level of diagnosis verification, or other determination from the app or a health authority
Magiczne słowo could znaczy może. Wspaniałomyślnie przewidziano takie rozszerzenie. W tym samym akapicie jest podane źródło tych danych. Nie pochodzą one z magicznego api ani z telefonów innych użytkowników tylko muszą do niego zostać podane. To czy to podawanie będzie realizowane bezpośrednio przez serwer GIS czy za pośrednictwem np: Google Play Services nie ma znaczenia dla pracownika GIS czy innego podmiotu lokalnego odpowiedzialnego za informowanie chorych o tym, że są chorzy. Bo oni i tak znają numer telefonu chorego i do niego dzwonią. Wystarczy spojrzeć niewprawnym okiem na te 2 kwestie by zobaczyć różnicę między:
1) autodiagnozą zmartwionych swoim zdrowiem ludzi, którzy w obecnym stresie zapominają nawet o regularnym pomiarze temperatury i nie są jeszcze zarażeni oraz nie mieli kontaktu a 2) algorytmem liczącym prawdopodobieństwo ekspozycji na patogen wynikające z kontaktów, które bluetooth łaskawie zdołał zarejestrować
Oczywiście kształtuje się trzecia ścieżka wspomniana przez Pana ale chwilowo jest w budowie. Ja z istniejącej dokumentacji wyczytałem, że do pełnego funkcjonowania tego modelu potrzebna jest możliwość wysyłki danych na jakiś serwer oraz możliwość otrzymania danych od instytucji posiadającej w danym kraju status centrum kontaktu / służby zdrowia. Czyli część obiegu tych informacji jest nadal niejawna. Centrum Kontaktu pozostaje tworem, który ma sobie jakoś poradzić w tej sytuacji. Z pana perspektywy to jest ok?
potiuk
commented
4 years ago Naprawdę serio cieszę się że powoli zaczynamy rozmawiać (z obu stron) a nie krzyczeć na siebie. Z opublkowanych dziś informacji w #147 (jeśli potwierdzi je MC) wynika że projekt idzie w dobyrm kierunku i jeśli założenia zostaną zrealizowane to jest spora szansa na wspóldziałanie. Szczerze bym tego chciał i mam nadzieję, że tak się stanie.
@potiuk Zanim wrócimy kolejny raz do "State Level adversary" proponuję zaznajomić szerszą publiczność z pozostałymi wrogimi aktorami. Pan się skupia na najwyższym możliwym poziomie i takie ma Pan prawo.
Mi właśnie o to chodzi. żeby było "privacy by design" a nie "privacy by trust" - zwłaszcza że to można zrobić. Naprawdę zależy mi tylko na tym. W ogóle nie skupiałem się na innych aspektach tyko na tym jednym - zależy mi, żeby system był prywatny i żeby miał szansę spełnić swoją rolę (to czy to drugie się da - tego jeszcze nikt nie wie, ale dopóki nie sprawdzimy, nie wiadomo).
Są też jednak bardziej "trywialne" przypadki a w kontekście aplikacji, która chociaż dotyka danych medycznych wszystkie powinniśmy traktować poważnie. Apeluję zatem o podzielenie się kompletnym modelem zagrożeń. Przydadzą się też jakieś konkretne wektory ataku.
Na kompletne analizy, niestety nie mam czasu. Komentuję tu z doskoku - między jednym projektem a drugim (właśnie zaczynam drugi) i wybrałem zagadnienie, które mi najbardziej leżało na sercu.
W zasadzie tworzy Pan jeszcze wyższą klasę: "State Level adversary + kooperujący lokalny ISP + Google + Cloudflare".
Nie nie. Chodziło mi tylko o StateLevel Adversary. Ani mniej ani więcej. Moje główne zastrzeżenia do adresu IP dotyczyły poprzedniej (zakładam) implementacji scenrtralizowanego systemu, gdzie wysyłane były konktakty do osób zdrowych i algorytm "contact tracing" był wykonywany na serwerze. To że adres IP pojawił się przy okazji wysyłania danych do intermedica, to druga, niezależna kwestia - która była zgłoszona "przy okazji". Faktycznie w tej sytuacji - nawet jeśli te dane są na temat oceny zdrowia - to (przynajmniej jeśli będzie to dobrze skomunikowane uzytlkownikom) "State Level Adversary" nie może wiele z tym zrobić. Zwłaszcza że ten adres IP jest wysyłany jednorazowo, przy wysyłaniu kwestiornariusza i nikt nikogo do wysyłania kwestionariusza nie zmusza. Kwestie "Contact Tracing" są o wiele bardziej wrazliwe, bo są włączane raz a potem rozgłaszane bez przerwy.
Jeśli tylko wysyłanie danych do Intermedica będzie zgodne z regulaminem, RODO i przejdzie audyt bezpieczeństwa i prywatności - a w ten sposób nie będą wysyłane dane o kontaktach - to dla mnie jest to akceptiowalne rozwiązanie.
Chcemy w tym uczestniczyć bo w końcu jest szansa coś w tym temacie zmienić. Jaka jest aktualna kondycja systemów bezpieczeństwa w placówkach medycznych i urzędach dowiadujemy się z mediów. Pytanie czy chcemy tylko krytykować czy proponujemy jakieś kompleksowe rozwiązanie.
I tu się absolutnie zgadzam. Jeśli tylko założenia ze #147 będą dotrzymane i przejdą próby otwartej dyskusji, czasu, audytu, opinii społecznej etc., to ja takie rozwiązanie nawet mogę polecać. Zakładam że i tak przyjdzie rozwiązanie Google + Apple które musi zastąpić własne. Ale rozumiem że chcielibyście mieć własną "opcję". Jeśli będzie zdecentralizowana i nie będzei wysyłała kontaktów, to jest to ok.
Projekt jest otwarty nie tylko do wglądu i krytyki. Jest otwarty bo niezbędny jest materiał edukacyjny do rozmów o bezpieczeństwie nowoczesnych systemów reagowania kryzysowego. Czekamy zarówno na review kodu jak i na propozycje usprawnień.
Czekam niecierpliwie - mam nadzieję że bęðzie on faktycznie otwarty w przyszłości - zarówno na dystkusję, jak i propozycje. Jeśli założenia ze #147 się utrzymają - to jest na to nadzieja, że Ministerstwo i wy wzięliście pod uwagę głos niezależnych osób i że będziecie to robić. Było trochę szorstko, ale mam szczerą nadzieję że w przyszłości będzie lepiej.
Sterowanie infrastrukturą będzie się odbywało w ramach CI/CD zintegrowanego w tych konkretnych repozytoriach GitHub. Inaczej mówiąc jeśli dany nowy fragment kodu nie zostanie pozytywnie zaopiniowany przez wybraną przez nas liczbę osób w organizacji na GH - nic nowego się w systemie nie pojawi. To możemy zrobić i na to mamy wpływ. Przynajmniej do momentu kiedy ta organizacja będzie istnieć.
Magiczne słowo could znaczy może. Wspaniałomyślnie przewidziano takie rozszerzenie. W tym samym akapicie jest podane źródło tych danych. Nie pochodzą one z magicznego api ani z telefonów innych użytkowników tylko muszą do niego zostać podane. To czy to podawanie będzie realizowane bezpośrednio przez serwer GIS czy za pośrednictwem np: Google Play Services nie ma znaczenia dla pracownika GIS czy innego podmiotu lokalnego odpowiedzialnego za informowanie chorych o tym, że są chorzy. Bo oni i tak znają numer telefonu chorego i do niego dzwonią. Wystarczy spojrzeć niewprawnym okiem na te 2 kwestie by zobaczyć różnicę między:
Tak jak ja to rozumiem (i pisałem wcześniej) to akurat może wynikać z testu intermedica (czy innego) - samoocena zdrowia i jej wynik mogą a nawet w G+A powinny być przekazywane jako "Transmission Risk". Przynajmniej ja tak to rozumiem. I jeśli kwestii przekazywania kontaktów na serwer nie będzie, ato nawet dobrze jest że samoocena zdrowia będzie elementem całościowej oceny ryzyka.
Oczywiście kształtuje się trzecia ścieżka wspomniana przez Pana ale chwilowo jest w budowie.
Mam nadzieję już niedługo.
Ja z istniejącej dokumentacji wyczytałem, że do pełnego funkcjonowania tego modelu potrzebna jest możliwość wysyłki danych na jakiś serwer oraz możliwość otrzymania danych od instytucji posiadającej w danym kraju status centrum kontaktu / służby zdrowia. Czyli część obiegu tych informacji jest nadal niejawna. Centrum Kontaktu pozostaje tworem, który ma sobie jakoś poradzić w tej sytuacji. Z pana perspektywy to jest ok?
Tak - i tak włąśnie jest ok - bo na serwer wysyłane są tylko "Temporary Exposure Keys" - moje własne. I nic więcej. W szczególności osoby zdiagnozowane nigdy nie wysyłają żadnej informacji o osobach zdrowych. To był absolutnie podstawowy, nienegocjowalny jak dla mnie problem. Od czasu jak zrozumiałem jakie to niesie konsekwencje, jestem absolutnie przeciw takiemu rozwiązaniu. Z #147 wnioskuję, że to się zmieniło do modelu zdecentralizowanego. i jeśli tylko MC potwierdzi że tak faktycznie jest, to dla mnie jest to ok.
miklobit
commented
4 years ago @bartosztomczak Ponieważ przedstawiane tu objasnienia dt. wymiany danych z API infermedica robią sie coraz bardziej zagmatwane to prosiłbym bardzo o przedstawienie w formie diagramu/grafu wszystkich elementów/węzłów tego procesu wraz z informacją:
Bez takiego jasnego i czytelnego dokumentu trudno jest uchwycić wszystkie zagrożenia prywatności i bezpieczęnstwa tego procesu a mam wrażenie ,że próbujecie tutaj pomijać najsłabsze punkty. Np. jeżeli pierwszym węzłem przez który dane wychodzą z aplikacji jest cloudflare, który ma pełny dostęþ do wszystkiego o co pytam w p.3/4 to TEN węzeł jest krytyczny w zakresie ochrony prywatności i danych osobowych a nie jakies kolejne proxy na którym obiecujecie nie logować ip. itd.
Taki diagram powinien zostać włączony do repozytorium jako część specyfikacji.
pingwinwzakiecie
commented
4 years ago Na czym polega to darmowe API? No bo czy nie można by uruchomić go albo fragmentu jego kodu lokalnie?
Is your feature request related to a problem? Please describe.
Ponieważ w #129 ustalono, że aby chronić prywatność użytkowników nie należy wysyłać danych na inne serwery, gdy możliwe jest opracoiwanie danych lokalnie - należy wyłączyć żądania do api.safesafe.net zamieniając jego IP na 0.0.0.0 lub 127.0.0.1, tak że żądania nie opuszczą maszyny lokalnej.
Ustalono też, że obecne działanie aplikacji jest niezgodne z wytycvznymi EDPB, toteż blokada tej funkcji pozwoli przywrócić zgodność z EDPB oraz RODO.
W wątku #127 pokazano, że dane te mają charakter medyczny, zaś Ministerstwo, dla którego projekt przygotowujemy ma MOŻLIWOŚĆ zdeanonimizowania w łatwy sposób każdego użytkownika.
W obecnym kształcie, gdzie większość ludzi (nawet kaszlących, ale bez gorączki) uzyskuje wyniki "zielone" jedyne do czego dochodzi to do inwigilacji ludzi używających apki.
Dużo na ten temat jest na Niebezpieczniku z końca kwietnia oraz na stronie https://blog.kurasinski.com/2020/05/protego-safe-dlaczego-nie-nalezy-instalowac-aplikacji-ministerstwa-cyfryzacji/
Żeby zabezpieczyć się przed takimi oskarżeniami i budować zaufanie społeczne (co twórcy aplikacji oraz Ministerstwo Cyfryzacji deklarują od początku) należałoby moim zdaniem natychmiast wyłączyć tą funkcję śledząca.
Po wyłączeniu należy zaimplementować ocenę objawów i chorób z ankiet (ocena ryzyka, dziennik) z wykorzystaniem jedynie lokalnych algorytmów JavaScriptu, HTML i CSS.
Describe the solution you'd like Natychmiastowa zmiana w aplikacji IP z którym się łączy na 0.0.0.0 lub 127.0.0.1 oraz wyłączenie serwera api.safesafe.app.
Describe alternatives you've considered Aktualizacja aplikacji, która usunie ją ze smartfonów o ile to wykonalne oraz usunięcie jej ze sklepu Google.