ProteGO-Safe / specs

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

Jak ma wyglądać przejście na rozwiązanie Google i Apple? #153

Closed jasisz closed 4 years ago

jasisz commented 4 years ago

Aplikacja działa teraz w sposób, który nie jest kompatybilny z, jak to rozumiem, docelowym rozwiązaniem Google i Apple.

Rodzi to wiele niełatwych pytań:

  1. Czy identyfikatory i spotkania używane teraz, przed wejściem nowego rozwiązania, będą jakoś używane później?
  2. Jeżeli tak, to jak będa używane? Czy będzie na ich podstawie również stwierdzane zagrożenie? Nie widzę w rozwiązaniu G+A opcji "zasilenia" go starymi identyfikatorami (by design), więc czy alert o zarażeniu będzie przez jakiś czas kombinacją alertu ze starego scentralizowanego systemu i nowego zdecentralizowanego? Może to budzić duże wątpliwości, nie wiadomo też czy Google i Apple w ogóle pozwolą na coś takiego w aplikacji używającej ich API.
  3. Co z problemami z adopcją? Ktoś może dalej nosić przy sobie starą wersję myśląc, że jest chroniony i rozgłaszać identyfikatory, które dawno nikogo już nie obchodzą.
  4. Co z okresem przejściowym, w którym o zagrożeniu może decydować połączenie danych ze starego i nowego podejścia (np. miałem jedno spotkanie na starym rozwiązaniu i jedno na nowym, a dopiero łączna ich długość stanowi o niebezpieczeństwie)?
potiuk commented 4 years ago

Zgadzam się i tu podbiłbym #137 , Wydaje się że po przejściu na G+A dane obecnie zbierane są kompletnie nieużytecznie i lepiej je wyłączyć?

jasisz commented 4 years ago

Też mam wrażenie, że obecnie zbierane niestety są bezużyteczne. Nie widzę chyba żadnego pozytywu w tym, że rozwiązanie odpalono wcześniej.

Oczywiście nie mogę winić twórców o to, że nie mają szklanej kuli, która powiedziałaby kiedy będzie gotowe rozwiązanie G+A, ale to tylko pokazuje, że zdeployowanie takiego niekompletnego rozwiązania tylko "aby narazie zbierało spotkania" (a coś takiego było i proponowane na samym początku tego projektu, za poprzedniej ekipy), nie ma żadnego sensu.

Jakie jest teraz uzasadnienie działania aplikacji, skoro nie spełnia ona żadnej roli, bo nie jest zaimplementowana część odpowiadająca za faktyczne powiadomienie kogoś o możliwości zarażenia, a danych nie będzie się dało użyć potem?

Dr-Kownacki commented 4 years ago

Już wcześniej sygnalizowałem (m.in. #126 i więcej), ale może dobitniej tutaj zapytam - CO KONKRETNIE DZIAŁA ? :-) (w BLE oczywiście).

Czy jest jakiś opis konkretny już (m.in. "na co się zgadza użytkownik włączając tą opcję - skanowanie/rozgłaszanie i co dalej z tym będzie/może być").

Ja tego nigdzie nie widziałem dotąd. Mam 3.0.3, chyba że jest nowsza wersja mówiąca o tym użytkownikowi ? (sprawdzę zaraz jeszcze, jeśli jest to z góry przepraszam :) )

Ponieważ aplikacja nie ma żadnego (postulowanego przeze mnie wcześniej) "licznika", który "nabijałby nam" - liczbowo/eventami po prostu fakt że:

a) "rozgłosiliśmy się" - Y razy

b) "usłyszeliśmy kogoś" - X razy

To dla mnie jest zasadnicze pytanie czy w końcu coś działa, czy nie (i CO?) bo ja już się w tym totalnie pogubiłem (jako lamer), za co tradycyjnie przepraszam prosząc zawodowców jak zwykle o oświecenie mnie ;-))))

Dzięki z góry ! :-)

EDIT: dla wygody kopiuję adekwatny cytat z #126

4) Zauważyłem że w aplikacji nie ma informacji, które prawdopodobnie mogłyby być przydatne dla użytkownika w zakresie oceny tracing'u:

a) jakiekolwiek informacje, że aplikacja rzeczywiście połączyła się z serwerem, coś sprawdziła "centralnie" oraz SKUTECZNIE (pełna sesja etc.) i kiedy miało to miejsce ostatni raz

b) zaproponowałbym jakiś "licznik" pokazujący "przebieg" aplikacjii tzn. takie info dla użytkownika LOKALNE pokazujące ile razy rzeczywiście to rozgłoszenie się miało miejsce. W ten sposób użytkownik miałby wgląd i dobre samopoczucie że wszystko działa OK i "przybywa" tych rozgłoszeń w czasie - licznik nabija je :-)

c) nie mam jeszcze możliwości sprawdzenia co realnie telefon rozgłasza i czy rzeczywiście coś rozgłasza zwł. jak jest uśpiony-nieużywany (zgaszony ekran). Nie ukrywam że ta ciekawość narosła we mnie po tak pozytywnym zaskoczeniu z baterią. Mam nadzieję w przyszłym tygodniu porobić trochę testów "nasłuchowych" żeby po prostu realnie "zobaczyć" że to działa i że działa bez zmian i zależności od tego co robi telefon i w jakim jest stanie.Jak to sprawdzę na moim urządzeniu to dam tutaj znać. Myślę że ten "licznik" zaproponowany powyżej w "b" też pozwalałby w przybliżeniu oszacować czy/jak to działa na każdym urządzeniu każdego użytkownika stąd ew. debugging byłby ułatwiony na pewno bo w ten sposób każde urządzenie/wersja byłoby weryfikowalne w prosty sposób przez użytkownika, a teraz to jest "black box".

d) kolejną kwestią mógłby być też jakiś prosty "licznik spotkań" czyli o ile w b) wiemy że my rozgłaszamy skutecznie to tutaj mielibyśmy wgląd w to, że "skutecznie nasłuchujemy innych - łapiemy tylko realne kontakty"" - moim zdaniem to byłoby spore ułatwienie dla weryfikowania jak działa algorytm weryfikujący czy to było "prawdziwe spotkanie".

W moim przekonaniu zarówno b) jak i d) mogłyby zostać pozytywnie odebrane przez użytkowników, który dostaliby "namacalny dowód że to rzeczywiście działa" co mogłoby wypłynąć pozytywnie na popularność instalowania tej aplikacji__

jasisz commented 4 years ago

Znalazłem stosowny paragraf w https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf

You and Your Contact Tracing App may not combine, correlate, link, use or otherwise associate any user data collected in another App through the use of the Apple Software (e.g., location data accessed through the location-based APIs may not be combined with user data from a Contact Tracing App, even if You own or operate the corresponding App) with user data collected or otherwise obtained in YourContact Tracing App, unless otherwise agreed by Apple and with user consent(e.g., for purposes of moving from an existing COVID-19 App to a Contact Tracing App).

Dr-Kownacki commented 4 years ago

A co z CZASEM (momentem ekspozycji), bo o ile mogłem zrozumieć to zgodnie z API G+A czas jest logowany i finalnie przez to "centralnie" przechowywany po wygraniu "zakażonych kluczy" ?

Pisałem o tym w innym wątku (zaraz znajdę) na przykładzie przysłowiowych "Vadima, Ludmiły i Nataszy". Zaraz odnajdę i wstawię, chodzi o to że jak Vadim na/(za)raził "skutecznie" Ludmiłę to ich klucze wzajemnie zrobią "match" czasowy jakby ktoś się zawziął (Wielki Brat) i z puli "zakażonych kluczy"/pacjentów na serwerze (przypominam że one tam już nie są anonimowe !) da się potencjalnie ciekawe informacje zdobyć.

Wystarczy te "matche" przesiać przez wzajemne logi BTSów i wiadomo dokładnie gdzie było spotkanie Vadima i Ludmiły, że o CCTV nie wspomnę (tak "wpadła" Natasza ;-) ).

Czy Waszym zdaniem "czas trafienia wzajemnego" przy dwóch osobach hospitalizowanych/rozpoznanych w ciągu np. 5 dni (obie osoby wgrywają klucze swoje bo obie są chore) nie pozwoli "dopasować" Vadima do Ludmiły (i jeszcze dodatkowo Nataszę namierzyć, która Ludmiłę podwiozła na spotkanie) ? ;-)))

jasisz commented 4 years ago

Ministerstwo Cyfryzacji odpowiedziało na to pytanie, ale dopiero w komentarzach na Play Store.

Zrzut ekranu 2020-06-9 o 20 19 30

Szkoda, że tutaj nie doczekalismy się odpowiedzi przez miesiąc.

KoderFPV commented 4 years ago

@jasisz Przykro mi, faktycznie mogło to być tutaj jasno napisane. Jednak teraz wszystko się wyjasniło. Możemy zamknąć ten wątek?

Dzięki.