Sztuczne dopełnianie liczby kluczy w publikowanych plikach

[tomekziel]

Wśród obecnie dystrybuowanych plików z kluczami mamy:

• 1599609600-1599652800-00001.zip (1031 kluczy ważnych jeden dzień)
• 1599825600-1599868800-00001.zip (1011 kluczy z 2 tygodni, 64-82 klucze z każdego dnia)

Jak interpretować taką anomalię?

[pkleczko]

@tomekziel, duża ilość kluczy nie jest wynikiem testów na produkcji (nie robimy tego, mamy oddzielne środowisko do tego celu i tylko tam przeprowadzamy sprawdzenia systemu) a aktualizacji serwera GENS (serwera kluczy). Wraz z nową wersją zmienił się nieco sposób generowania paczek z kluczami (można to również zauważyć po nazwie plików zawierającej 2 timestampy), który wymaga teraz minimum 1000 (plus losowy 'jitter') kluczy w paczce i jeśli tych kluczy jest mniej to uzupełnia je losowo wygenerowanymi kluczami. Ten mechanizm ma dodatkowo zabezpieczać przed próbą deanonimizacji kluczy, co teoretycznie byłoby możliwe jeśli ilość wgrywanych kluczy jest niewielka.

Jeśli potrzebujesz więcej technicznych informacji na ten temat mogę poprosić o bardziej precyzyjne wyjaśnienie od zespołu opiekującego się tą częścią infrastruktury, natomiast jeśli intencją było odpytanie o testy na produkcji to mam nadzieję że udało mi się wyjaśnić.

[tomekziel]

Ten mechanizm ma dodatkowo zabezpieczać przed próbą deanonimizacji kluczy, co teoretycznie byłoby możliwe jeśli ilość wgrywanych kluczy jest niewielka

Tego nie zrozumiałem. Rozwiniesz myśl?

Czy tego typu multiplikacja jest dokonywana gdziekolwiek indziej na świecie? W przypadku Niemiec mieliśmy onegdaj do czynienia z wielokrotnością wysłanych kluczy, ale dopychanie do tysiąca?

[tomekziel]

Rozwinę temat. Na stronie https://down.dsg.cs.tcd.ie/tact/tek-counts/ widzimy liczniki kluczy wysyłanych przez zarażonych w poszczególnych krajach. Nawet w czasie, gdy w Niemczech do każdego prawidłowego klucza dorzucano X dodatkowych, znane było owo X.

Czy w PL możliwe jest obecnie śledzenie skuteczności ProteGO Safe poprzez sprawdzanie, ile kluczy użytkownicy wysłali każdego dnia i ile dni wstecz sięgała historia w przypadku każdego z tych użytkowników?

[bartosztomczak]

Witam,
Nie możemy się wypowiadać za inne zespoły ale z naszych informacji wynika, że w Europie przynajmniej trzy kraje stosują lub stosowało podobną metodę. Cytowane źródło podaje jak X jest "wyliczane" w przypadku Niemiec.
Przykładowo: 20200719: the German ratio of fake/real TEKs changed from 9:1 to 4:1. X nie jest więc realną liczbą, a wyłącznie szacunkiem. 1000 kluczy jako minimum w sytuacji kiedy mamy powyżej kilkuset przypadków dziennie nie wydaje się przesadne. Jest to wartość domyślna referencyjnego serwera kluczy https://github.com/google/exposure-notifications-server/blob/release-0.7/internal/export/config.go#L48
Co do drugiego pytania to centrum kontaktu posiada informację ile kodów pin zostało przekazanych użytkownikom w celu przesłania danych na serwer danego dnia. Od strony systemu serwerowego można określić ilu użytkowników przekazało klucze. Określanie jak daleko sięgała historia jest utrudnione. W obecnym modelu ilość kluczy przekazanych w pojedynczej sesji nie odpowiada już bezpośrednio ilości dni historii. Klucz może zostać obrócony przed upływem jego ważności.
Reasumując pojedynczy klucz mógł być używany od x do 24h. Nie jestem pewien czy dobrze odczytuje pytanie z pierwszego postu w tym wątku ale nie ma czegoś takiego jak dwutygodniowy klucz.

[tomekziel]

@bartosztomczak "Od strony systemu serwerowego można określić ilu użytkowników przekazało klucze" - czy to oznacza, że niezależni badacze nie będą już w stanie samodzielnie ocenić skuteczności ProteGo Safe? Czy od teraz jedyną możliwością będzie wysyłanie pytań do, no właśnie - dokąd?

[pkleczko]

@tomekziel wdrożenie tego mechanizmu nie miało na celu zaciemnienia ilości przesyłanych kluczy dla 'niezależnych badaczy', ale rozumiem problem i że takiej możliwości teraz już nie ma. Tak jak wspomnieliśmy z @bartosztomczak postanowili skorzystać z tego rozwiązania ze względów czysto związanych z bezpieczeństwem. Mogę odesłać Cię do opisu zagrożenia w dokumentacji Google i ich rekomendowanych mitygacji (które zresztą zostały wdrożone w kodzie serwera): https://github.com/google/exposure-notifications-internals/blob/main/en-risks-and-mitigations-faq.md#linking-diagnosis-keys-through-export-file-analysis.
Jeśli wyczerpałem odpowiedzi na Twoje wątpliwości czy testujemy na produkcji i dlaczego dopełniamy liczbę kluczy i nie masz więcej pytań proponuję zamknąć Issue.

[tomekziel]

Dane dotyczące popularyzacji aplikacji covidowych i ich wpływu na epidemię w różnych krajach będą analizowane, porównywane i przetwarzane na różne sposoby przez wiele lat. Uważam za krytycznie ważne, aby rzeczywiste statystyki użycia były swobodnie dostępne dla wszystkich zainteresowanych - niekoniecznie w postaci surowych kluczy TEK pobieranych z backendu ProteGO Safe.

@pkleczko @bartosztomczak @MateuszRomanow - czy podzielacie tę opinię? Jaką propozycję publikacji danych możecie wysunąć? Ryzyko "linking diagnosis keys through export file analysis" nie ma zastosowania, gdyż w Polsce diagnozujemy pozytywnie setki osób dziennie.

[bartosztomczak]

@tomekziel pełna zgoda co do potrzeby powstania otwartego zbioru danych. Proponuję jednak pominąć publiczne repozytorium kluczy jako źródło takich danych. W najbliższej przyszłości mogą się w tym zbiorze kluczy pojawić takie, które nie pochodzą z lokalnego systemu ochrony zdrowia. Europejski system federacyjny zbliża się do finalnych testów.
Co do powodu powstania nowej funkcjonalności GENS podzielam tutaj zdanie autorów tego oprogramowania. Podobnego zdania było kilka krajów UE i osobiście uważam, że miało to wpływ silnie motywujący.

[MateuszRomanow]

Wiesz co @tomekziel trochę nie wiem co mam Ci (od)powiedzieć. Z jednej strony szanuję Twoją pracę, wiedzę, to, że wiele razy merytorycznie rozmawialiśmy o technologii, wymiarze społecznym, współpracy z administracją publiczną i oczywiście działania samej aplikacji ProteGO Safe.

Z drugiej strony dostarczasz clickbaitowych tytułów, z niesprawdzonymi tezami, z których następnie się wycofujesz. Musimy się zdecydować czy rozmawiamy o merytoryce, czy tworzymy technologiczny FAKT i nabijamy wyświetlenia i kliki.

1. Masz intencję, chcesz zadać merytoryczne pytanie "Dlaczego w aplikacji pojawiła się anomalia z kluczami?", na które chętnie osoby technicznie związane z projektem odpowiedzą. Ale to się słabo klika i nie ma sensacji. Zadajesz więc pytanie "Test na produkcji?" stawiasz tezę, wprowadzasz w błąd.
2. Koledzy technicznie i merytorycznie odpowiadają, okazuje się, że nie ma sensacji na GH. Że nic się nie dzieje. Jest spokojnie. Jest dobrze, bo zmiana ma na celu zwiększenie prywatności. Że zmiana jest Googla (!) a nie twórców aplikacji czy MC. Ale w międzyczasie twittujesz w sposób, który przeradza się w kolejne nieprawdziwe insynuacje.

Jednocześnie masz 100% wiedzy, że w 100% skuteczność contact tracingu jest uzależniona od ilości pokrycia, które to pokrycie jest uzależnione od jakościowych informacji i edukowania, a nie straszenia. Piszesz o tym, że skuteczność jest niska - żeby była wyższa potrzebne jest pokrycie.

Zadam Ci więc proste pytania, odpowiedz na nie proszę, żeby pokazać własne intencje i wartości:

• Czy zależy Ci na zwiększeniu bezpieczeństwa w obszarze zachorowalności na COVID-19 bez względu na skalę wzrostu tego bezpieczeństwa?

Jeżeli tak, to grajmy w końcu do jednej bramki i w jednej drużynie. Jeżeli zaś w Twojej opinii sensowność pomocy zaczyna się tylko od osiągnięcia 'jakiejś' skali i musi magicznie pomóc większości, to tu się nie dogadamy. Bo my pomagamy szeroko. I każdemu. Także tysiącom użytkowników, którzy codziennie monitorują swój stan zdrowia i mierzą temperaturę zapisując ją w aplikacji. A na których nie ma konsekwentnie miejsca w "analizach" i "clicbaitach".

• Czy czujesz się na siłach żeby wyceniać ile jest warte życie ludzkie jednej osoby ochranianej przez contanc tracing i narzędzia pomagające w monitorawniu stanu zdrowia, a ile życiu 10, 100 czy 1000 osób?

My tego nie wyceniamy, rozwijamy system, którego skala pomocy zwiększa się w zależności od skali pokrycia. Skala jest uzależniona od rzetelnej komunikacji. Jeżeli chcesz rzetelnie rozmawiać, to jesteśmy tu od 4 miesięcy - i rozmawiamy. Jeżeli chcesz robić clickbaity i kręcić ruch na swoim blogu - rób to, ale nie mieszaj nas do tego - proszę.

@pkleczko @bartosztomczak @MateuszRomanow - czy podzielacie tę opinię? Jaką propozycję publikacji danych możecie wysunąć? Ryzyko "linking diagnosis keys through export file analysis" nie ma zastosowania, gdyż w Polsce diagnozujemy pozytywnie setki osób dziennie.

Tak, co do zasady podzielamy. Na najbliższym statusie z MC przedstawimy ten (Twój) głos z GH tak jak to robimy pośrednicząc pomiędzy naszą GitHubową społecznością i MC. I tak jak to robimy zawsze - wrócimy z jakąś odpowiedzią, z jakąś propozycją.

[potiuk]

Tak - spojrzałem na to i pamiętam, że google rekomendowało to w swoim serwerze od początku. Pytanie na ile ma to sens, ale do tego przydało by się wyjaśnienie kiedy, jak i ile takich danych jest dodawanych - czyli opis algorytmu po prostu. Dodatkowo, przydała by się po prostu gdziekolwiek (np. w meta-danych pliku) publikowana liczba fake'owych kluczy dodanych.

Z tego jak ja rozumiem te rekomendacje Google'a to to ILE jest tych fakeów może być upublicznione, ważne żeby nie mówić KTÓRE to są.

This may be feasible specifically in situations where very few individuals are diagnosed positive in a given timeframe. If a diagnosis key batch only contains one diagnosis key for each day, the keys in the batch must correspond to the same individual. To mitigate this potential for correlation, we recommend that diagnosis key servers pad out diagnosis key batches with random keys, with some jitter so exports don't leak the fact that they were padded. This is implemented in our reference server (code).

Przy okazji opisywania tego algorytmu, warto dopisać też, czy implementujecie też tą drugą rekomendację dotyczącą randomizacji porządku raportowanych danych przed publikacją pliku - również zaimplementowaną w ich referencyjnym serwerze.

The natural order in which diagnosis keys are stored in the diagnosis server's database may confer some information about their association at time of upload. To ensure this information is not leaked in diagnosis key export batches, we recommend that batches are re-ordered before publication, as we've done in our reference implementation.

[potiuk]

@MateuszRomanow - widzę że emocjonalnie reagujesz a @tomekziel nie chodzi o ujawnianie danych albo o wycenianie życia ludzkiego tylko o rzetelny dostęp do publicznych danych, które pozwolą niezależnym badaczom robić właśnie to .. niezależne badania. Proponuję bardziej konstruktywnie - moja propozycja powyżej będzie dobra i prosta do implementacji a zaspokoi oczekiwania @tomekziel

[MateuszRomanow]

widzę że emocjonalnie reagujesz

Sorry, ale ręce mi opadają.

[bartosztomczak]

@potiuk w przypadku naszej aplikacji zaplecze obsługujące klucze to "czysta" implementacja serwera referencyjnego Google. Projekt rozwija się z dużą szybkością i staramy się go nie modyfikować. Funkcja losowo zmieniająca próg sprawdzanego minimum jest również domyślnie aktywna. Niestety nie znalazłem lepszego opisu algorytmu - może to będzie pomocne:
https://github.com/google/exposure-notifications-server/blob/release-0.3/internal/export/worker.go#L373

[KoderFPV]

Dzienna statystyka losowo generowanych kluczy rozwiązałaby problem?

[tomekziel]

@MateuszRomanow
Zespół realizujący ProteGO Safe po raz kolejny został zaskoczony faktem, że ktoś obserwuje postęp prac i kształt projektu. Wdrożyliście zmianę której efektem jest pozorny kilkudziesięciokrotny wzrost skuteczności aplikacji - bez zapowiedzi ani uprzedzenia, za to z efektami działającymi dwa tygodnie wstecz.

Potem okazuje się, że zaburzenie dotychczasowych danych jest celowe, przy czym zmiana nie ma formy "X * prawdziwe klucze" (jak to bywało w innych krajach) tylko "prawdziwe klucze + 1000 + random", co uniemożliwia śledzenie skuteczności aplikacji. Dochodzi do efektów komicznych, np. w pliku 1599609600 doszła niewielka liczba kluczy z jednego dnia, więc automat pracowicie dolosował tysiąc ileś kluczy z... tego właśnie jednego dnia.

Na Twitterze napisałem, że nie mam już możliwości dalszego liczenia statystyk skuteczności ProteGO Safe. Kilka godzin później @pkleczko potwierdza, że nie mam już możliwości dalszego liczenia statystyk skuteczności ProteGO Safe.

No i teraz robi się smutno i niemiło, bo w internetach zupełnie przypadkiem publikowane są heheszki, że aplikacja o jakoś tak płynnie zmieniającej się marce zaczęła ukrywać prawdziwe liczby a ja jej nie bronię, więc znienacka jestem przepytywany w temacie wyceny ludzkiego życia, grania do jednej bramki i nierzetelnych clickbaitów.

@Tarvald
Ja chciałbym wiedzieć, ile osób wysyła każdego dnia swój zestaw kluczy. Nasi międzynarodowi partnerzy bardziej chcieliby wiedzieć, ile kluczy z danego dnia podlegało dystrybucji. Jeśli miałbym wybierać, to wybrałbym tę drugą opcję, bo w dłuższej perspektywie niesie ona więcej informacji.

[Dr-Kownacki]

Witam wszystkich,

Bardzo ciekawie się tu zrobiło i fajnie czytać taka korespondencję kompetentnych osób mnie - laikowi.

Natomiast jeśli chodzi o mechanizm leżący u podstaw uploadu kluczy to przecież to tak naprawdę realny poziom na którym należy przeprowadzić statystykę to nie jest moment kiedy serwer "ogłasza klucze" (tym bardziej że jak widzimy poziom abstrakcji hipotetycznych zagrożeń korelacji przy kilku osobach na kraj przesyłających wymusił "rozcieńczanie" kluczy), ale w momencie ich "UPLOADU" od zakażonych użytkowników.

Stąd chyba prostym rozwiązaniem byłby jakiś publicznie wyświetlany licznik, który pokazywałby jak w osi czasu (kalendarza) zmieniają się te statystyki uploadu np.

a) dla całego kraju
b) dla województw
c) (dla powiatów ?)

Pomiar "skuteczności/penetracji" aplikacji w społeczeństwie na bazie "nasłuchiwania" kluczy jest fajnym pomysłem i pamiętam że @tomekziel miał to opracowane już po moich pierwszych zapytaniach "na ile realnie to działa" - jak było jeszcze bardzo mało kluczy w obiegu. BTW: ile jest aktualnie ???

Ale z drugiej strony w/w. opiera się na założeniu że "wszystko działa jak trzeba", a przecież wcale tak nie musi być i teoretycznie jakiś błąd serwera może czegoś (teoretycznie, np. bug jakiś) nie opublikować.

Stąd statystyka robiona i upubliczniania (bez podawania kluczy, tylko "liczba sztuk kluczy" jakie poszły do uploadu) liczb pokazujących upload w zestawieniu z liczbą kluczy rozgloszonych przez serwer o wiadomym poziomie "rozcieńczenia" fejkami np.1000x pozwoli od razu monitorować (także niezależnym badaczom jak @tomekziel ) jednocześnie jaka jest penetracja/"skuteczność" aplikacji ale też czy ona "DOBRZE" działa.

Tu od razu komentarz dla Autorów że bynajmniej nie chcę podawać w wątpliwość (bo nie mam do tego absolutnie żadnych podstaw) poprawności działania całego systemu, ale wskazuję po prostu pomysł jednocześnie na zaspokojenie ciekawości zainteresowanych "jaka jest skuteczność/penetracja" jak i na sprawdzanie/dokumentowanie/wykazanie wszystkim (również i samym autorom jako QA procesu) że wszystko jest OK.

Co do wprowadzenia "rozcieńczania/mieszania" kluczy to miło się to mnie-lamerowi czyta w kontekście kiedyś tutaj opisanej hipotetycznej historii Vadima, Swietłany i Nataszy gdzie wskazałem że istnieją potencjalne zagrożenia korekowania ze sobą kluczy, może to niektórzy Forumowicze pamiętają ;-)))

Wracając do meritum sprawy to statystyki uploadu kluczy dla kraju/województw/powiatów mogłyby zostać przestawione tak jak statystyki rozpoznań zakażeń COVID jako "flourishing chart", i co więcej korelowanie tego w podobny sposób powinno (niby) dawać w skali kraju jakieś w miarę równolegle krzywe.

Ale już rozbicie tego na mniejsze obszary statystyczne (województwo/powiat) mogłoby dać potencjalnie bardzo ciekawe info na temat "bliskiej przyszłości".
Bo możnaby teoretycznie "przepowiadać przyszłość" w danym rejonie gdzie np. 100osob zakażonych odebrało 10000 kluczy jako LEPSZĄ, niż w rejonie gdzie 100 osób zakażonych odebrało 6000 kluczy - bo tam jest zatem potencjalnie większe realne natężenie źródeł zakażeń.

Dlatego bardzo ciekawy byłby mechanizm który wewnątrz aplikacji/API (lojalnie!) prowadziłby statystykę cały czas i mógł sprawdzić ile spośród wszystkich zebranych (prawdziwych, czyli realnie zageszczonych do reala 1000x) było kluczami "zakażonymi".

Na koniec (jeżeli dobrze zrozumiałem) aktualnie algorytm rozcieńcza klucze dodając "do pełnego tysiąca" fejki, ale przecież może wystarczy rozcieńczyć może poprzez stałe mnożenie np. X*5=N i wtedy znając N zawsze wiemy ile było X (N/5) natomiast liczba fejków to byłoby zawsze (4/5)*N.

Czy takie rozwiązanie ma Waszym zdaniem sens i wszystkie strony byłyby zadowolone ?

Serdecznie pozdrawiam wszystkich zaangażowanych bardziej światłych w technologiach IT ode mnie i wybaczcie jeśli coś niezgodnego z logiką systemu napisałem ;-)