Coder Social home page Coder Social logo

specs's Introduction

Aplikacja STOP COVID - ProteGO Safe

Spis treści

  1. Wprowadzenie
  2. Grupy ryzyka zarażenia SARS-CoV-2
  3. Anonimowość i bezpieczeństwo
  4. Dalsze założenia
  5. Zakres funkcjonalności wersji 2.0
  6. Zakres funkcjonalności wersji 3.0
  7. Zakres funkcjonalności wersji 4.0
  8. Testy bezpieczeństwa
  9. Najczęściej zadawane pytania
  10. Chcę pomóc, zgłosić błąd, mam pomysł

Wprowadzenie

English version: https://github.com/ProteGO-Safe/specs/blob/master/README-ENG.md

Celem aplikacji mobilnej STOP COVID - ProteGO Safe jest dostarczenie narzędzia asystującego i chroniącego użytkownika i jego bliskich przed rozprzestrzenianiem się COVID-19, a docelowo także pomoc w przejściu z ogólnopolskiego lockdownu do selektywnej kwarantanny osób, które były narażone na ryzyko zakażenia COVID-19.

Od 13.03.2020 trzy zespoły: ProteGO (bluetooth tracing), SafeSafe (diagnostyka i profilaktyka) i Sigma Connectivity (bluetooth tracing) tworzyły swoje rozwiązania dla aplikacji mobilnych, które w założeniu miały przyspieszyć ten proces. Ministerstwo Cyfryzacji połączyło te zespoły i nadało nową nazwę dla aplikacji - STOP COVID - ProteGO Safe. Aplikacja przygotowywana jest dla Głównego Inspektora Sanitarnego, który ma największe kompetencje w specyfikowaniu założeń projektowych tak, aby aplikacja stanowiła efektywne narzędzie w walce z pandemią COVID-19. Minister Cyfryzacji i GovTech Polska z uwagi na swoje doświadczenie pełnią nadzór nad pracami projektowymi.

Aplikacja jest budowana zgodnie z zasadami wynikającymi z ogólnego rozporządzenia o ochronie danych osobowych (RODO), w tym minimalizacji danych, privacy by design, privacy by default, prawidłowości, integralności oraz poufności. Wzięto także pod uwagę wytyczne Europejskiej Rady Ochrony Danych Osobowych, Komisji Europejskiej oraz Toolbox opracowany w ramach sieci eHealth działającej przy Komisji Europejskiej. Wszystkie zaangażowane strony przykładają szczególną wagę do zapewnienia najwyższych standardów prywatności. Przyjęte rozwiązania zapewniają wsparcie organów zdrowia w walce z pandemią, wykorzystując przy tym możliwie minimalny zestaw danych koniecznych dla osiągnięcia tego celu.

Główny Inspektor Sanitarny w porozumieniu z Ministrem Cyfryzacji zdecydował się wstrzymać dalsze rozwijanie standardu Open Trace w modelu dążącym do rozproszenia systemu, z uwagi na zaawansowane prace nad narzędziem, które zapewni lepsze pokrycie przy zachowaniu modelu rozproszonego - „Privacy-Preserving Contact Tracing” przygotowywane przez konsorcjum Google i Apple (o roboczej nazwie „Exposure Notification”).

Zespół STOP COVID - ProteGO Safe został zaproszony do testów rozwiązania Exposure Notification, dzięki czemu możemy wdrożyć rozwiązanie, które od początku jest projektowane jako system rozproszony i dzięki temu umożliwia ochronę prywatności użytkowników aplikacji tracingowych opartych o ten standard.

STOP COVID - ProteGO Safe nie wymaga podania żadnych danych osobowych na jakimkolwiek z etapów korzystania z Aplikacji. STOP COVID - ProteGO Safe nie zbiera też danych osobowych. Wszystkie informacje przetwarzane przez STOP COVID - ProteGO Safe zbierane i przetwarzane są w taki sposób, aby uniemożliwić identyfikację użytkowników.

Obecnie dostępna jest podstawowa funkcjonalność STOP COVID - ProteGO Safe, która umożliwia dokonanie triażu tj. samooceny ryzyka zarażenia chorobą COVID-19. Funkcjonalność triażu dostarczana jest przez API Infermedica wykorzystywane również przez portal pacjent.gov.pl. Funkcjonalność ta jest w trakcie przepisywania na moduł, który będzie działał lokalnie (offline czyli nie po API).

Druga kluczowa funkcjonalność, która będzie oparta o Exposure Notification API umożliwia tzw. Bluetooth tracing. Jeśli użytkownik wyrazi stosowną zgodę – Aplikacja, wykorzystując wbudowany w urządzenie mobilne moduł Bluetooth rozgłaszać będzie generowany losowo, w pełni anonimowy klucz, który zamieniany będzie co 10 minut oraz jednocześnie skanuje otoczenie w poszukiwaniu innych telefonów na których zainstalowana jest aplikacja i zapisuje historię spotykanych anonimowych kluczy urządzeń, a także ocenia “jakość” kontaktów z użyciem Exposure Notification API opracowanego przez Google oraz Apple.

“Jakość” kontaktów oceniana jest na podstawie konfiguracji (parametrów) ustalonych przez lokalne Health Authority, zawierających m.in. określenie tego, jaki wpływ na wynik analizy ma długość samego spotkania, a jaki wpływ ma odległość w czasie od tego spotkania (ile dni od niego minęło), czy fizyczna odległość między użytkownikami. W oparciu o parametry moduł analityczny dostarczony przez G+A podaje wynik odpowiadający ryzyku ekspozycji na wirusa.

Poza szacowanym ryzykiem zwracane są również informacje, nt.: długości spotkania, które odnotowywane są co 5 minut. Z powodów bezpieczeństwa i prywatności górna granica rejestrowania czasu to 30 minut.

Dane te przechowywane są wyłącznie na urządzeniach użytkowników Aplikacji i nie są przesyłane na żaden serwer centralny, co zapewnia API Exposure Notification opracowane przez konsorcjum Google i Apple. Aplikacja usuwa dane zgromadzone na urządzeniu po 14 dniach od dnia ich zapisania w Aplikacji lub w każdej chwili na żądanie użytkownika (stosowna opcja w ustawieniach).

W kolejnej wersji aplikacji (4.1) funkcjonalności związane z zapobieganiem COVID-19 zostaną rozszerzone.

Na chwilę obecną, od początku epidemii a bez związku z posiadaniem lub nie aplikacji, każda z osób, u której zdiagnozowano chorobę COVID-19 jest telefonicznie informowana o wyniku testu przez upoważnionego przedstawiciela organu zdrowia. W nieodległej przyszłości ten upoważniony przedstawiciel organu zdrowia informując o pozytywnym wyniku testu na COVID-19 zapyta także, czy osoba chora ma zainstalowaną aplikację STOP COVID - ProteGO Safe i chce ostrzec innych ludzi, którzy przebywali w jej otoczeniu zgodnie z parametrami wyznaczonymi przez GIS. Jeśli tak, upoważniony przedstawiciel organu zdrowia proponuje użytkownikowi aplikacji wysłanie swojej historii Diagnosis Key (tylko osoby zarażonej - bez historii spotkanych urządzeń) z ostatnich maksymalnie 14 dni na serwer, z którego dane zostaną rozesłane dalej na urządzenia użytkowników końcowych aplikacji.

Dzięki temu na urządzeniu użytkownika końcowego po otrzymaniu paczki DiagnosisKey anonimowego-chorego, zainicjowany zostanie proces analizy napotkanych urządzeń z zainstalowaną aplikacją STOP COVID - ProteGO Safe. Moduł analityczny najpierw sprawdzi, czy aplikacja “widziała się” z zarażonym Diagnosis Key.

Jeżeli doszło do takiego kontaktu, aplikacja na podstawie m.in. okresu spotkania, odległości między urządzeniami, a także innymi czynnikami wskazanymi w wytycznych GIS, zdecyduje, czy użytkownik końcowy aplikacji powinny otrzymać informacje o potencjalnym zagrożeniu.

Następnie aplikacja wyświetli dalsze komunikaty (w tym precyzyjny numer telefonu do kontaktu z Centrum Kontaktu) jak postępować w przypadku bycia w Wysokiej Grupie Ryzyka zarażenia się SARS-CoV-2.

Grupy ryzyka zarażenia SARS-CoV-2

Każdy użytkownik może po włączeniu aplikacji sprawdzić jaki jest jego spersonalizowany status:

  • Zielony - niska grupa ryzyka - można swobodnie wychodzić, zachowując obowiązujące regulacje i profilaktykę.
  • Pomarańczowy - średnia grupa ryzyka - Test Oceny Ryzyka lub potencjalny kontakt z osobą chorą wskazują na konieczność samoobserwacji.
  • Czerwony - wysoka grupa ryzyka - należy skontaktować się z GIS lub skontaktować się z lekarzem.

Kod aplikacji jest publicznie dostępny na znanej i otwartej licencji GPL-3.0.

Anonimowość i bezpieczeństwo

W jaki sposób STOP COVID - ProteGO Safe w wersji 4.0 opartej o Exposure Notifications zadba o anonimowość użytkowników i bezpieczeństwo danych?

System rozproszony:

  1. Dane przechowywane są na urządzeniach użytkowników. Wszystkie informacje (wpisy w Dzienniku Zdrowia), a także historia spotykanych urządzeń są przechowywane na urządzeniach użytkowników i tam analizowane.
  2. Dane wprowadzane do STOP COVID - ProteGO Safe umożliwiają zachowanie anonimowości użytkowników. Nie jest konieczna rejestracja, ani podawanie jakichkolwiek danych identyfikujących. Oprócz instalacji aplikacji użytkownik podaje jedynie swoją nazwę, która może być dowolna i jej jedyny cel to komfort użytkownika.
  3. Tylko osoby zweryfikowane medycznie jako chore na COVID-19 będą mogły zainicjować proces wysłania swoich Diagnosis Key (wcześniej wymagany jest kontakt osoby chorej z Centrum Kontaktu - warunek niezbędny. Kontakt ten jest wykonywany dobrowolnie przez osobę chorą, Centrum Kontaktu nie posiada takich danych nie ma więc możliwości skontaktować się z taką osobą), aby można było wysłać ostrzeżenie dla innych użytkowników.

Dalsze założenia

  • Numery telefonów osób u których wykryto chorobę COVID-19 są w Polsce przetwarzane przez upoważnione do tego organy zdrowia - nie ma zatem potrzeby angażowania aplikacji STOP COVID - ProteGO Safe w ich pozyskiwanie, a tym bardziej przechowywanie.
  • Zakładamy potrzebę interoperacyjności - wymiany danych z innymi projektami w Europie i kraju a to wymaga modelu federacyjnego, bezpiecznego standardu wymiany danych między systemami do CT oraz możliwości rozszerzenia modelu podstawowego.
  • Potrzebne jest dalsze rozwijanie części informacyjno-edukacyjnej aplikacji STOP COVID - ProteGO Safe.

Projekt jest rozwijany na zlecenie MC przez konsorcjum firm: Tytani24 Sp. z o.o. (lider), The Coders Sp. z o.o. , Webini Sp. z o.o. , Sigma Connectivity Sp. z o.o. , 25wat Sp. z o.o. , Klimas Legal, Mobile Flag, HOLDAPP wspierane przez wszystkich chętnych kontrybutorów.

Poniżej opis wersji Aplikacji:

[wykonana] Zakres funkcjonalności wersji 2.0

  • Użytkownik anonimowo, bez podawania danych umożliwiających jakąkolwiek identyfikację instaluje Aplikację na telefonie z systemem operacyjnym Android i iOS (czeka na publikację),
  • Użytkownik otwiera Aplikację i wyświetlają mu się informacje o sposobie jej działania i potrzebnych zgodach/uprawnieniach (akceptacja Regulaminu i Polityki Prywatności).
  • Użytkownik uzupełnia metrykę zdrowia. Użytkownik wypełnia pierwszy test oceny ryzyka (triaż).
  • Użytkownik dostaje pierwszy wynik klasyfikacji swojego stanu zdrowia (triaż).
  • Użytkownik odbiera notyfikacje push przypominające o potrzebie wypełnienia testu oceny ryzyka.
  • Aplikacja prowadzi użytkownika przez porady i zalecenia związane z jego stanem zdrowia na podstawie oceny ryzyka (triażu).
  • Użytkownik może wypełniać dowolną ilość razy dziennie: test oceny ryzyka (triaż) i dziennik zdrowia.
  • Po trzech dniach, w których użytkownik przynajmniej raz dziennie wypełnił test oceny ryzyka w Aplikacji wyświetla się odznaka “Dbam o siebie i bliskich”.
  • W przypadku Aplikacji dla systemu iOS - użytkownik musi wyrazić zgodę na “Pozwolenie na wysyłanie notyfikacji”.

Zakres:

  • Celowy i pożądany brak synchronizacji z Google Analytics.
  • Brak rejestracji użytkownika w Aplikacji przy użyciu numeru telefonu.
  • Dane z modułów: Metryka, test oceny ryzyka i dziennik zdrowia są zapisywane lokalnie na telefonie.

[wykonana] Zakres funkcjonalności wersji 3.0

Użytkownik pobiera lub aktualizuje aplikację STOP COVID - ProteGO Safe 3.0 z modułem OpenTrace i nie ma w niej możliwości (i widoku) podania numeru telefonu (użytkownik nie podaje numeru telefonu w aplikacji - nie zbieramy tych danych w żaden sposób).

Serwer przyznaje aplikacji (a nie numerowi telefonu) UID czyli zanonimizowany unikatowy numer danej instalacji (aplikacji) - przez co jest w stanie komunikować się z aplikacją. Dla każdego UID backend generuje TempID (zapisuje na urządzeniu tablicę z listą numerów TempID na 2 tygodnie do przodu, które aplikacja będzie zmieniać co 15 minut). TempID służą do anonimizacji użytkowników w module tracingowym (kontakt Bluetooth).

Na początku korzystania z aplikacji użytkownik jest proszony o wyrażenie zgody na:

  • Android: "Korzystanie z usługi lokalizacja" (żeby skanować inne urządzenia w okolicy trzeba mieć zgodę na “Lokalizację”. W praktyce jest to wymagane do korzystania z modułu bluetooth. Aplikacja nie korzysta z geolokalizacji urządzenia za pośrednictwem GPS).
  • iOS: “Pozwolenie na używanie modułu Bluetooth”. Po wyrażeniu zgody, aplikacja uruchamia moduł OpenTrace, który działa w tle (tylko w systemie Android, w systemie iOS możliwości działania Bluetooth w aplikacji działającej “w tle” są bardzo ograniczone), również po opuszczeniu aplikacji i zablokowaniu ekranu (na tyle na ile pozwala na to system operacyjny).

Moduł bluetooth nie działa przy wyłączonej aplikacji. Moduł OpenTrace rozgłasza TempID przy użyciu Bluetooth. TempID aplikacji jest rotowane tj. zmieniane co 15 minut zgodnie z bazą zapisaną na urządzeniu - ilość kodów określona jest w parametrach. Częstotliwość pobierania nowej listy TempID jest również określana jako parametr w konfiguracji.

Moduł OpenTrace skanuje otoczenie w celu wykrycia innych użytkowników i zapisuje dane: timestamp, msg (TempID), siła sygnału bluetooth. Dane te są zapisywane wyłącznie w lokalnej pamięci telefonu.

[w trakcie] Zakres funkcjonalności wersji 4.0

Wersja 4.0 opiera się o implementację Exposure Notification API opracowane przez Google i Apple (G+A) w miejsce dotychczas stosowanego OpenTrace.

Zakres funkcjonalności dla wersji 4.0:

  • Użytkownik pobiera aplikację lub aktualizuję ją do wersji 4.0 korzystającą z API G+A.
  • Zgodnie z wymogami dotyczącymi korzystania z API: urządzenie użytkownika rozgłasza w sposób ciągły tymczasowe identyfikatory (TemporaryExposureKey), które pobierane są z poprzednio wygenerowanej przez użytkownika puli kluczy, zmienianych po upływie określonego czasu. Nasłuchuje jednocześnie na identyfikatory nadawane przez inne urządzenia.
  • Wszelkie identyfikatory są generowane w sposób uniemożliwiający ich powiązanie z konkretnym urządzeniem lub użytkownikiem.
  • Dane dotyczące kontaktu usuwane są z urządzenia użytkownika po upływie 14 dni [parametr].
  • Aplikacja przynajmniej raz na dobę pobiera identyfikatory użytkowników pozytywnie zweryfikowanych przez Generalny Inspektorat Sanitarny jako zakażonych i porównuje je z identyfikatorami zapisanymi na urządzeniu użytkownika, dokonując w razie potrzeby ich analizy i oceny ryzyka kontaktu.
  • W przypadku dłuższej nieobecności użytkownika końcowego, po włączeniu aplikacji pobierane są wszystkie DiagnosisKey chorych, z ostatnich 2 tygodni, których aplikacja nie posiada.
  • Analiza danych dotyczących bezpośredniości kontaktu przeprowadzana jest jedynie lokalnie na urządzeniu użytkownika końcowego.
  • W przypadku wykrycia kontaktu z chorym i ocenie siły tego kontaktu, użytkownik otrzymuje odpowiednie powiadomienie push.
  • W zależności od tego, do jakiej kategorii dany kontakt zostanie zakwalifikowany, użytkownik otrzymuje odpowiednie powiadomienie push.

Testy bezpieczeństwa

STOP COVID - ProteGO Safe and it's documentation is licensed under

Kod aplikacji jest publicznie dostępny na znanej i otwartej licencji GPL-3.0. Link do repozytorium GitHub: https://github.com/ProteGO-Safe GNU General Public License v3.0

Permissions of this strong copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights.

specs's People

Contributors

ad-m avatar bartosztomczak avatar bpaszcza avatar cierpliwy avatar d0han avatar dariuszaniszewski avatar jakublipinski avatar jasisz avatar koderfpv avatar mateuszromanow avatar mbrydak avatar mikolak avatar mikolevy avatar oskarhinc avatar pkleczko avatar qlb avatar theimowski avatar tomaszmnich avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

specs's Issues

Czy używacie Page-Rank do lokalizowania ryzykownych node'ów?

Ostatnio w rozmowie ze znajomym powstał taki pomysł (nie pochodził ode mnie a od niego) - aby zainicjować page-rank wektorem zerowym ludzi zarażonych i policzyć go z takim wektorem w celu zlokalizowania węzłów (ludzi) o dużym ryzyku zarażenia - i ich testować

Jednolite commit messages, udokumentowanie procesu developmentu

Jestem przekonany, że commit messages po polsku to zły pomysł - ogranicza partycypację zagranicznych developerów i wprowadza konwencję obcą większości polskich programistów.

Równolegle z tym proponuję wprowadzenie jednolitej konwencji commit messages (https://chris.beams.io/posts/git-commit/). Jeśli założenie jest takie, że projekt będzie open source'owy, to musimy się trzymać dobrych praktyk przestrzeganych w całej branży.

Prowadzenie dokumentacji w dwóch językach to spory overhead - czy na tym etapie są jakiekolwiek powody dla których warto to robić po polsku?

Informacja o projekcie

Rozmawiałem z kilkoma osobami / znajomymi ze świata dev'u i zachodzi pytanie o to, kto stoi za projektem. Przydałby się dokument, który jasno wyjaśnia, kto stoi za projektem i jakie jest jego
powiązanie z organami Państwa, tj. czy stoi za tym dodatkowa firma, jak wygląda finansowanie.

Widać tutaj, że dużo commit'ów jest z Warszawskiej firmy. Nie wiem, czy wrzucane commit'y są prezentem dla nas obywateli, czy idą za tym pieniądze. Ja osobiście nie mam nic przeciw, że ktoś być może zarobi, ktoś inny nie.. jednakże każdy, kto być może będzie chciał dorzucić swoją cegiełkę, na pewno jest zainteresowany informacją o projekcie, jego założeniach i (ewentualnym) finansowaniu.

Szczególnie ma to znaczenie w dobie ostatnich projektów, pojawiających się bardziej lub mniej prawdziwych informacji o ich finansowaniu itd. Brak informacji może być blockerem dla chcących angażować się w projekt.

Kto jest "konsultantem medycznym" w tym projekcie ?

To proste pytanie wynikające z poniższego opisu ze strony Ministerstwa Cyfryzacji, przy ogromnej moim zdaniem potrzebie aplikacji dla personelu medycznego:

"
Czerwony – miałeś kontakt z osobą zarażoną, skontaktuj się z lekarzem, poddaj kwarantannie.

Zielony – GO! Nie jesteś w grupie zagrożonych. Możesz być spokojny.
"

Tutaj wprost widać nietypowość całej sytuacji jeżeli zastosujemy tryb "auto-bluetooth":
cyt. SKONTAKTUJ SIĘ Z LEKARZEM

A niby na jakiej konkretnej podstawie ?

I co mu powiesz ? Przecież niczego nie wiesz, wszystko jest anonimowe/ automatyczne, masz tylko jakąś "lampkę" na telefonie czerwoną...

Jakich informacji udzielisz ?

Wreszcie z KTÓRYM lekarzem ?

W obecnej trudnej sytuacji będzie to dodatkowe obciążenie dla służby zdrowia i szum informacyjny. Realnie będzie to z powyższych powodów ignorowane po prostu ...

Zebranie logicznego wywiadu lekarskiego / epidemiologicznego będzie niemożliwe.

To jest medycznie nieprzemyślane i założę się że raczej żaden lekarz (dotąd) tego nie konsultował :-)

Moje wątpliwości opisane tutaj: #63

Nawet jeśli uda się jakoś odkodować to na serwerze, to na pewno nie jest to zadanie dla lekarza tylko dla SANEPIDu raczej...

Tłumaczenia na angielski

Zdecydowaliśmy się na opis projektu po polsku, ze względu na to, że jego docelowi (pierwsi) użytkownicy będą z Polski i chcieliśmy aby był dla nich transparentny.

Jako że jesteśmy pierwszym rozwiązaniem typu contact-tracing które jest open-source, jest spore zainteresowanie naszym kodem także z zagranicy.

Potrzebujemy tłumaczeń na język angielski wszystkich dokumentów, najlepiej wg. kolejności:

  • specs/README-en.md które zastąpi ENGLISH.md
  • specs/specs/README-en.md tłumaczenie specs/specs/README.md
  • specs/specs/data_sharing-en.md tłumaczenie specs/specs/data_sharing.md
  • specs/specs/api-en.md tłumaczenie specs/specs/api.md
  • CONTRIBUTING-en.md tłumaczenie CONTRIBUTING.md

send_encounters performance

How many requests to the send_encounters endpoint to you expect?
Why don't you use HTTP for this endpoint? Do you think about other protocols? MQTT for example.

Zasięg bluetooth

Cała aplikacja ma działać używając bluetooth i wykryte przez niego urządzenia.
Czy i w jaki sposób system będzie weryfikował i obliczał "realną" odległość pomiędzy urządzeniami?
Czy wszyscy będą wrzucani do tego samego worka?
W dzisiejszych czasach nowe bluetooth mają dosyć potężny zasięg (nawet do 400 m).
Jeżeli założone zostanie, że wszystkie wykryte urządzenia są potencjalnymi zarażonymi, możemy wrzucać do worka bardzo dużą ilość osób, które w ogóle styczności z osobą zarażoną nie miały.

Nie rozumiem tych zagadnień - trochę za dużo szans na FP

My tworząc CoronaHack rozważaliśmy takie sytuacje jako słabe:

  1. Jadą dwa autobusy obok siebie - wszyscy komunikują się bluetooth, liczba false positive ogromna (nie wspomnę o pociągu itp)
  2. Czy nie lepiej zrobić jak u nas - włączamy tryb jesteśmy w pobliżu i świadomie zgłaszamy i świadomie potwierdzamy? Coś jak spotkanie?

Idea CoronaHack jest zbieżna z założeniami ProteGO (szczegóły w załączonym i wysłanym PDF), gdzie dodatkowo uwypuklono szczególnie ważny aspekt pracowników służby zdrowia ponieważ wiemy jakie są konsekwencje dla szpitali przy nieprzerwanym w porę łańcuchu zakażeń.
Jako lekarz dr Kownacki zwraca uwagę na definicję "kontaktu" zgodną z WHO, ponieważ aplikacja puszczona w trybie całkowite "auto na Bluetooth" wywołać może więcej szkód (panika/niepewność) niż korzyści. Stąd adekwatne założenia opisane w CoronaHack.

Zgłoszenie robiliśmy na Hack the Crisis.
http://coronalog.pl/?page_id=2

Mamy design okna O Aplikacji

Użytkownik może otworzyć okno O Aplikacji. Znajdzie tam następujące dane:

  • Wersję aplikacji
  • Identyfikator użytkownika (Jest to pierwsza ćwiartka user_id, 8 pierwszych bajtów w formacie hex np. Identyfikator użytkownika: a809-8c1a-f86e-11da)
  • Przycisk Prześlij historię który kieruje do wysyłki danych.

Branding i design system

Im bardziej projekt rośnie, tym istotniejsza jest spójna warstwa graficzna i UX (szczególnie w aplikacji przeznaczonej dla ogółu populacji). Czy istnieje w tym momencie jakakolwiek specyfikacja jednego lub drugiego?

Przymusowa aplikacja "kwarantanna domowa" wysyłająca zdjęcia na serwer

Niestety po tym jak dobrowolna aplikacja "kwarantanna domowa" mimo zapewnień danych publicznie, że nie stanie się obowiązkowa - stała się obowiązkowa - nie zamierzam pomagać w rozwoju aplikacji, która potencjalnie później może zostać użyta do kolejnych tak "szczytnych celów" przez dodanie kolejnych funkcji. Skompromitowaliście się państwo z Ministerstwa Zdrowia (Ministry of Health in Poland).

Za takie traktowanie obywateli + dążenie do władzy po trupach przez PiS (jedna z partii politycznych), niszczenie gospodarki rodzimej i jednego z kandydatów na prezydenta- nie ma wybaczenie i nie będzie. Do widzenia, wolę wspierać inne krainy.

Odebraliście nam nawet prawo do bezpośredniego głosowania, wbrew zapisom Konstytucji. WStYD!

Nie macie też za grosz poszanowania dla prywatności obywateli, zmuszając ich wbrew RODO do wyrażenia PRZYMUSOWEJ zgody na przesyłanie ich danych biometrycznych na serwery firmy trzeciej lub rządowe. Nie informujecie, że ich dane będą PRZYMUSOWO wysłane do Google (Android) oraz Apple (iOS) i tą zgodę wymuszacie. Ludzie mając Anroida i iOS, mogli mieć do tej pory zaklejoną kamerę i nie dzielić się z Google i iOS zdjęciami.

Co z trollowaniem?

Skoro użytkownik z aplikacji będzie mógł ustawić swój status - w jaki sposób aplikacja ma zapobiec trollowaniu i wysyłaniu nieprawdziwych sytuacji?
Skoro i tak aplikacja ma być podpięta pod GIS (GIS dostanie info o sieci kontaktów zarażonego), to może GIS powinien wprowadzać zarażonych?

Stworzenie gittera na potrzeby rozmowy o aplikacji.

Stworznie gittera jako najbardziej zintegrowanego z github'em, w celu rozmowy na temat aplikacji.
Plusem gittera jest to że nie trzeba go instalować, oraz można zalogować się loginem githuba.

Alternatywą mógłby byc slack albo inny komunikator.

Przydałby się przynajmniej 4 pokoje.

  • Android
  • iOS
  • Backend
  • Specs

Sposób podejmowania decyzji w projekcie - czym jest community w tym projekcie?

W tej chwili nie wiadomo w jaki sposób podejmowane są decyzje projektowe. Kto decyduje o tym jakie rzeczy wchodzą a jakie nie wchodzą, jaki jest protokół. W Projektach open-source zawsze istnieje "governance model" . Na przykład w fundacji Apache i jej projektach jest on zdefiniowany i jasno udokumentowany:

https://www.apache.org/foundation/governance/

Jeśli nie ma zdefiniowanego modelu, i nie wiadomo, kto jest właścicielem kodu ani projektu, nie ma mowy o tym, żeby był to projekt rozwijany przez community a taka jest narracja Minsterstrwa Infrastruktury.

Czy można się dowiedzieć jak ten model wygląda ?

[enhancement] Dodanie urządzeń 'hubów' - urządzeń BT w miejscach publicznych

Dodanie funkcjonalności pozwalającej na ustawienie urządzenia BT w sklepie / transporcie publicznym - pozwoli to na powiadomienie osób, które mogły zetknąć się z wirusem w przestrzeni publicznej.

W ten sposób będziemy w stanie znaleźć osoby korzystające z tego samego sklepu/tramwaju/autobusu. Trzeba natomiast dobrze 'dobrać' czasy ekspozycji dla takich urządzeń, aby nie 'zainfekować' wszystkich użytkowników będących w danym miejscu przez ostatnie 14 dni, natomiast wskazać potencjalne ryzyko tym, którzy mogli mieć bliski kontakt przez dotykanie rzeczy.

Wymagania prawa człowieka - requirements from international civil society

Here is the document prepared by multiple international human rights groups on requirements from governments and from software such as this:
https://www.amnesty.org/download/Documents/POL3020812020ENGLISH.pdf

There are eight requirements listed. The technical aspects that I see are:

  • points 2 and 3 - "timebound" - make sure that the tokens are destroyed after, say 21 days?
  • point 4 - data security, anonymity: by free-licensing the code and distributing it on git repositories, this is likely to be satisfied by this project

The other points seem mostly political/administrative tasks - people developing the software can at the most remind GIS that Amnesty International, Human Rights Watch, and about 100 or so smaller human rights and digital rights community groups want this to be done properly, not North Korean/Microsoft style.

Połączenie CoronaLog z ProteGO

  1. Nasza aplikacja nie będzie działać cały czas - tylko na zasadzie "cześć spotykamy się to wyciągamy apkę i potwierdzamy, że się widzieliśmy".
  2. Weryfikacja telefonu i wysyłanie informacji - po informacji, jestem w grupie ryzyka lub jestem chory

CoronaLog - będzie udostępniać wszelkie materiały (loga, kolory, układy itp) na takich samych zasadach jak ProteGO

CoronaLog działać będzie na wszystkich platformach w oparciu o te same założenia co ProteGO (wymiana danych po BLE).
Zespół CoronaLog - będzie aktywnie testować i współdziałać z ProteGO

Kolaboracja z innymi podobnymi projektami

Zamiast od podstaw tworzyć własny projekt, nie lepiej połączyć szyki z innymi podobnymi projektami i współtworzyć jedną, ale skuteczną aplikację do śledzenia podejrzanych o koronawirusa?

  • WHO pracuje nad oficjalną aplikacją, w kolejnych wersjach ma być śledzenie zarażonych koronawirusem,
  • MIT już w marcu stworzył podobny projekt Private Kit: Safe Paths (landing page, github), który mocno skupia się na zachowaniu prywatności użytkowników - przechowywane dane są anonimowe,
  • Stanford University pracuje nad COVID Watch (github) korzystającym z BLE,
  • Rząd Singapuru wydał aplikację TraceTogether (baza wiedzy, kod źródłowy ma być opublikowany wkrótce),
  • Ministerstwo Zdrowia Izraela wydało aplikację HaMagen (github, opis),
  • CoEpi (github) jest anonimowe i korzysta z Bluetooth,
  • Pandoa (github) korzysta z GPS,
  • ITO STRICT (github) skupia się na zachowaniu prywatności korzystając z BLE,
  • CoronaTrace (github) projekt podobny do Safe Paths,
  • PEPP-PT (od jutra ma być na githubie) - pan-europejska inicjatywa śledzenia koronawirusa korzystając z Bluetooth z zachowaniem prywatności.

Zamiast wynajdywać koło na nowo i tworzyć n-tą aplikację do tego samego, nie lepiej dołączyć do obecnej inicjatywy w duchu open source?

Informations about used communication protocol

Current specs just states that "application continuously gather devices within proximity radius" however it do not states how data is exchanged and what are the security considerations.

Konieczność włączenia Bluetooth na stałe / Necessity to permanently enable Bluetooth

Dziękuję za opublikowanie kodu źródłowego tej aplikacji, zanim wprowadzono obowiązek instalowania jej przez obywateli.

Mam uwagę co do wymogu, żeby włączać Bluetooth na stałe w telefonie. Taki wymóg jest dość kontrowersyjny. W przeszłości w technologii Bluetooth znajdowano wiele luk bezpieczeństwa. Dlatego wielu ekspertów bezpieczeństwa radzi wyłączać Bluetooth w miejscach publicznych. Np. następująca publikacja zgłębia tę tematykę:
https://www.researchgate.net/publication/326511381_Security_Vulnerabilities_in_Bluetooth_Technology_as_Used_in_IoT

Wybrane cytaty z tej publikacji:

"Mitigating Bluetooth vulnerabilities differ significantly from mitigating vulnerabilities in a computer system. While application software patches are used to resolve vulnerabilities in computer systems, Bluetooth devices require upgrades in device firmware [2]. These upgrades cannot be developed by the general public and/or user community [2]. Therefore, Bluetooth devices will continue to be vulnerable to attacks even if mitigation solutions become available [2,29]."

" (...) Mitigation techniques (...) Turning off a device’s Bluetooth when not needed or in use, especially while in certain public areas such as shopping malls, coffee shops, public transportation, clubs, bars, etc [2]. This can prevent users from receiving advertisements from other Bluejackers."

Pozdrawiam,
Aleksander Korzyński

Bluetooth - nadawanie i jednoczesne skanowanie w tle, IOS

Cześć

Czy ktoś sprawdził czy można jednocześnie skanować (słuchać) i nadawać pakiety Bluetooth/Bluetooth Low Energy przez aplikacje IOS pracująca w tle ?
Może to nie być w ogóle możliwe ze względu na ograniczenia IOS API.
Jeżeli jest możliwe, to jak bardzo zużywa to baterię ? Zarówno skanowanie jak i nadawanie zużywa energię.

Apel o usunięcie numeru telefonu przy rejestracji lub odłączenie numeru od identyfikatorów BT

Numer telefonu jest niepotrzebny przy rejestracji. Dużo o tym jest napisane w #34 #55 #54 więc nie będę się więcej rozpisywał.

Jeśli obecnie jest potrzeba szybkiego wdrożenia aplikacji żeby zacząć gromadzić dane na telefonach, apeluję do osób tworzących o usunięcie konieczności rejestracji przynajmniej z pierwszej wersji aplikacji i debatę publiczną na temat wdrożenia rozwiązania nie naruszającego prywatności.


Aktualizacja 6.04.2020

Wydaje się że akceptowalnym rozwiązaniem będzie podawanie numeru telefonu przy rejestracji, które nie będzie w żaden sposób związane z identyfikatorami BT generowanymi tylko na urządzeniiu i wysyłanymi na serwer. Jest to opisane tu:

#34 (comment)

To rozwiązanie (pod warukiem nadzoru organizacji NGO nad procesem publikacji aplikacji i przeglądania kodu źródłowego) spełnia wszystkie warunki postawione zarówno przez osoby które dbają o prywatność, jak i Ministerstwo Cyfryzacji:

  1. Nie można zidentyfikować i zdeanonimizować identyfikatorów BT po stronie serwera
  2. Numer telefonu jest obowiązkowy (ale przechowywany tylko lokalnie)
  3. Aplikacja po sprawdzeniu że jej identyfikatory są zagrożone wysyła informację o swoim numerze telefonu do serwera tak aby GIS wiedział, że powinien się z taką osobą skontaktować. Ta informacja nie zawiera identyfikatorów bluetooth i uniemożliwia ich połączenie z numerem telefonu.

Zmiana modelu działania aplikacji na anonimowy i (być może) zdecentralizowany

Aplikacja ProteGO w obecnym kształcie zbytnio narusza prywatność osób zdrowych. Umożliwia to deanonimizację informacji wysyłąnych na serwer. Jest to niezgodne na przykład z zaproponowaną specyfikacją https://www.pepp-pt.org/ (pod warunkiem że ta specyfikacja pozostanie wierna temu żeby była zachowana pełna anonimowość).

Nie ma żadnej potrzeby, żeby aplikacja wymagała podania i potwierdzenia numeru telefonu przy instalacji. Komunikacja z zagrożonymi osobami zdrowymi może być zrobiona na poziomie aplikacji - niepotrzebny jest numer telefonu (i żaden inny identyfikator pozwalający zidentyfikować zarówno osobę zdrową jak i zdiagnozowaną).

Właśnie pojawił się protokół który opisuje jak to samo zrobić w wersji zdecentralizowanej i anonimowej:
https://github.com/DP-3T/documents

Zamiast identyfikacji, osoba zdiagnozowoana powinna otrzymać kod (nazwany TAN_ID w specyfikacji https://www.pepp-pt.org/) który powinien zostać wpisany w celu wysłania (dalej anonimowej) swojej historii spotkań jeśli było by to potrzebne do analizy. Ten numer również nie powinien identyfikować osoby - również po diagnozie, powinien służyć jedynie do autoryzacji danych i obrony przed spamem.


Uwaga! Zaktualizowałem pierwotny opis -> odwołałem się początkowo do specyfikacji, która nie była bardzo precyzyjna, a w międzyczasie pojawił sie opis protokołu który doskonale opisuje założenia jak zrobić to dobrze - prywatnie i w sposób zdecentralizowany.

Aktualizacja 06.04.2020 - > Wydaje się że model anonimowy można utrzymać zachowując jednocześnie konieczność obowiązkowej rejestracji za pomocą numeru telefonu. Apel o to w #56 .

#34 (comment)

Zasady wspolpracy - branching strategy

Witam wszystkich, wraz z moim zespolem jestesmy zainteresowani wsparciem ProteGo. Na ta chwile celujemy w aplikacje iOS/Android. Czy jest gdzies opisana zasada wspolpracy z uwypukleniem tego na jakiej zasadzie dziala 'branchowanie' projektu?

Pozdrawiam
Michal

Zapisy na testowanie - nie dostałem mejla

Hej,

Zapisałem się na testowanie aplikacji w piątek, nie dostałem do dziś mejla z instrukcjami. Jakiś błąd po mojej stronie czy "zapchała się" kolejka do wysyłki?

A way to tie given app version to its code

Users need simple way to check from what source exactly was built given app.
It have to be transparent that no modified with non-disclosed code version of app is suddenly pushed to production env. This regards all elements of the ProteGO system.

Zagrożenie demokracji jeśli BT nie będzie anonimowe na serwerze

W obecnej wersji aplikacji algorytm decydujący o statusie osoby nie jest publiczny i nie wiadomo kto go kontroluje. Mówienie w tej sytuacji że rozwiązanie jest "otwarte" i rozwijane przez "społeczność" jest nadżyciem. Rozwijany jest w ten sposób jedynie "interfejs" a najważniejsza część - czyli przetwarzanie danych - nie jest publiczne.

W ten sposób jest to podatne na manipulacje i wykorzystanie do bardzo złych celów celów. Strona serwerowa (czyli zakładam strona rządowa) ma wiedzę na temat tego, kto jest kim i może takiej osobie ustawić status "czerwona" niezależnie od użytych algorytmów. Izolując taką osobę od społeczeństwa. To jest absolutnie niedopuszczalne, żeby status taki nie podlegał żadnej kontroli - ani publicznej, ani sądowej.

Jeśli chodzi o upublicznienie algorytmu - było na ten temat issue #4 kiedy aplikacja (ewidentnie) miała o tym podejmować decyzję sama. Istnieje również alternatywa opisana w #34 które opisuje jak to zrobić w sposób otwarty i zdecentralizowany.

Najprostszym rozwiązaniem, żeby tego uniknąć jest usunięcie konieczności rejestrowania się numerem telefonu - tak żeby dane były faktycznie anonimowe - bo w tej chwili nie są.

Brak ruchomego elementu na ekranie statusu

Domyslam sie, ze aplikacja bedzie wykorzystywana do potwierdzenia mozliwosci wejscia dla osob z zielonym statusem do miejsc dotychczas zamknietych, na przyklad kina, restauracji itd. W zwiazku z tym warto by dodac jakis element ruchomy obok statusu np. aktualna godzine z sekundami (lub date aktualizacji statusu rowna aktualnemu dniu), bo inaczej mozna screenshotem manipulowac wlasnym statusem.

Kilka słów od doktora - ProteGO / CoronaLog / CoronaHack

Cześć Wszystkim,

Jak już @kierepka wspomniał w innych wątkach temat logowania/bluetooth obmyślamy de facto od początku marca i zgłosiliśmy na HackCrisis 16 marca taki koncept:

CoronaHack_4_kownacki_final.pdf

=================
Mamy kilka pomysłów na różne podejście do algorytmu jak realnie-skutecznie zrobić to z bluetooth, ale najważniejsze jest kiedy taka aplikacja i jak używana będzie miała sens. Przede wszystkim ważne jest przemyślenie definicji "kontaktu", jest w PDF ale jeszcze raz przypomnę wg. WHO:

Co to znaczy, że ktoś miał kontakt z osobą zakażoną koronawirusem SARS-CoV-2?

  • Pozostawał w bezpośrednim kontakcie z osobą chorą lub w kontakcie w odległości mniej niż 2 metrów przez ponad 15 minut.

  • Prowadził rozmowę z osobą z objawami choroby twarzą w twarz przez dłuższy czas.

  • Osoba zakażona należy do grupy najbliższych przyjaciół lub kolegów (to odpuszczamy raczej...)

  • Osoba mieszkająca w tym samym gospodarstwie domowym, co osoba chora, lub w tym samym pokoju hotelowym.

==================

Powyższe jasno wskazuje, że tryb "auto-bluetooth" (aczkolwiek ciekawy i fajny aspekt) przy tym konkretnym zastosowaniu traci sens i spowoduje więcej paniki niż korzyści moim zdaniem.
Dla zobrazowania: jedziemy pociągiem i jesteśmy sami w przedziale. Na dworcu na innym peronie ale "stycznym" do naszego torze stoi pociąg pełen pasażerów. Aplikacja zaloguje potencjalnie kilkuset ludzi i chociaż dzieliło nas od nich 2 metry i 2 warstwy podwójnego szkła (!)- jeżeli my zachorujemy to ci wszyscy ludzie z drugiego pociągu dostaną irracjonalny warning...
Takie przykłady można mnożyć - wiadomo o co chodzi, "auto bluetooth" to jest zły pomysł, a w dodatku jak już napisano (informatyk zakładowy - #59) mnoży się wiele problemów, że o zużyciu baterii nie wspomnę.

Stąd nasz projektowany soft CoronaHack/CoronaLog działać będzie w sposób kontrolowany tzn. wracając do pociągu: jeżeli siedzimy z kimś w przedziale albo jesteśmy na spotkaniu w pracy to wtedy wszyscy uczestnicy "nawzajem się skanują" za wzajemną zgodą oczywiście, stąd wszystko robione jest ŚWIADOMIE/ UCZCIWIE/ TRANSPARENTNIE . Każdy godzi się świadomie jeśli chce i ma aplikację. Pytanie jedynie czy te dane powinny być zaszyfrowane również dla użytkownika i niewidoczne wprost - chodzi o poszanowanie prywatności np. przykładowa "dziewczyna z przedziału w pociągu" nie chce rozdawać numeru telefonu współpasażerom. Są różne okoliczności do wzięcia pod uwagę.

Ja osobiście dodatkowo widzę ogromne zastosowanie aplikacji typu ProteGo (po w.w. zmianach) jako wsparcie personelu medycznego i de facto pacjentów. My lekarze w większości nie możemy pracować zdalnie ani "solo". ProteGO MED ?
Widzieliście w newsach co się w szpitalach dzieje i jak trudno jest zapanować nad rozprzestrzenianiem zakażeń w placówkach medycznych - ustalenie kontaktów z ostatnich 14-dni, pacjentów, lekarzy, pielęgniarek - to jest moim zdaniem bez adekwatnej aplikacji wręcz UTOPIA.
A problem jest ogromny i de facto leży u podstaw wszystkiego bo przecież gdzieś pacjenci będą się przecież leczyć i system służby zdrowia nie może się zawalić wykonując "zadanie" poprzez wykonywanie tego "zadania" - taki paradoks obecnej sytuacji...

W moim przekonaniu "kanałem zwrotnym" pewnie SMS jest preferowanym chociaż niekoniecznie. Appka mogłaby automatycznie śledzić SMSy po jakiś prefixie i je "wyłapywać" - robią tak np. softy do namierzania GPSów dzieci (appka do Kizon LG na przykład tak robiła kiedyś), czyli da się w tle to analizować.

Podsumowując:

  1. Moim zdaniem rozwiązanie "a teraz wyciągamy telefony i włączamy apkę" jest raczej niezbędne.

  2. Aspekty zmiennych poza tymi zapisanymi w PDF mogą być dodatkowo uzupełnione:

  • czy uczestnicy (kto) mieli na sobie maski etc. (ew. jakie: chirurgiczna/FFP2.3/osłona etc.)
  • jak blisko siebie siedzieli (bluetooth to potrafi zmierzyć w przybliżeniu)
  • jak duże było pomieszczenie

Te wszystkie informacje są ważne do oszacowania ryzyka, wiadomo że niedoskonałe, ale zawsze coś.

  1. Opcje bluetooth są fajne ale i trudne potencjalnie, stąd zostają jeszcze inne możliwości jak chociażby:

a)
NFC - ale wiadomo że nie chcemy "bliskości" więc niekoniecznie...

b)
QR kody - j.w. niekoniecznie, ale jeżeli np. przyjmiemy że każdy będzie miał znaczek QR kod jakiś większy na ubraniu przypinany w miarę potrzeb to i z daleka złapie (wydruk A4), żarcik raczej ale ... :-)

c)
jakieś "wariacje" na Wi-Fi ale z duży zasięg może być problemem, zagrożenia etc. itp.

d)
bluetooth ale zupełnie pasywny tzn. łapiemy to co użytkownik rozgłasza pasywnie (po prostu swoją nazwę urządzenia i w niej w jakimś standardzie jest kontakt. Czyli aplikacja "na chwilę" rozgłasza urządzenie wg. kodu ustalonego np. "corona__+48xxx xxx xxx" albo "[email protected]" i wiadomo o co chodzi, bo pasywnie appka zbiera te dane które jednocześnie są kontaktem-wizytówką

e)
bluetooth ale MAC i wtedy nieważne jaką kto ma nazwę ale taki MAC jest gdzieś zarejestrowany ( niestety tu też serwer się kłania) no i wtedy taki MAC też jest przecież pasywnie cały czas rozgłaszany. Tutaj jednak jest zagrożenie że jak za ścianą ktoś też ma włączony BT to jego też przypisze do spotkania, stąd pomysł jak powyżej i wiadomo "kto jest kto" na spotkaniu

f)
wymyśliłem też coś "old-schoolowego" i proszę o Waszą opinię (zakładam że spotkanie jest w pomieszczeniu cichym) pamiętacie o "starym dobrym DTMF "? a co jeżeli każdy telefon uczestnika spotkania po prostu "zagrałby" głośno swój numer a inne telefony bo go usłyszały i zapisały ?
To może prymitywne rozwiązanie ale pomyślcie jak bardzo skuteczne, pozwala wręcz wpisać nawet kogoś kto ma Nokię sprzed 20 lat i "zagra" wszystkim swój numer-namiar zakodowany w DTMF
Generalnie to rozwiązanie niekoniecznie musi podać "nasz" numer prywatny ale jakiś numer w serwisie w necie, ale tu z kolei kłania się przesyłanie na serwer, internet, prywatność etc. a to jest problematyczne. Może ciekawostka, ale musiałem napisać.

Mam nadzieję że Was nie zanudziłem ale jak widzicie temat wałkujemy z Kolegami z zespołu ArtApp już od kilku tygodni i bardzo się ucieszyłem o inicjatywie ministerstwa na ProteGo, do której jak widzicie chcemy się włączyć żeby nie zmarnować energii poświęconej na hackcrisis.com

A jakbyście przy okazji chcieli zobaczyć koronawirusa w Mixed Reality (HoloLens) to zapraszam tutaj:
https://youtu.be/2b01wEZZFN8

Serdeczne Pozdrowienia dla Wszystkich i dużo zdrowia !

Czy trzeba być z Warszawy aby brać udział w projekcie? Problemy z oświadczeniem

Sam tytuł issuesa jest oczywiście żartem, ale proces udzielania licencji jest bardzo niedoskonały.

  1. Nie ma w tej chwili możliwości potwierdzenia że podpisujący dokument jest jednocześnie właścicielem "identyfikatora na platformie GitHub".
  2. Nie każdy jest z Warszawy, więc nie każdy może wypełnić ten formularz. Rozumiem że mogę sobie zmienić akurat ten fragment, ale nie mogę zmienić innych fragmentów? Na przykład licencję na której udostępniam kod?
  3. Wydaje mi się, że jest to po prostu proces, którego większość osób potencjalnie zainteresowanych kontrybuowaniem nie będzie chciała pzrechodzić. Podobne oświadczenia w przeszłosci wielokrotnie odrzuciły mnie od przeróżnych projektów.

Nadmiar danych w protokole

Wysyłanie os_version oraz device_type przy każdym zapytaniu brzmi jak zbędna operacja. Zastanowiłbym się też nad potrzebą trzymania tego w bazie. Jaki jest tego cel?

Zmiana modelu aplikacji na bardziej skuteczny - uwzględniający testy i otwarty algorytm

Po chwili zastanowienia i analizy danych doszedłem do wniosku że aplikacja w obecnym kształcie nie będzie spełniać swojej roli - nie tylko ze względu na konieczność podawania swojego numeru telefonu (wiele osób tego nie zrobi) ale również ze względu na matematyczny model epidemii.

Obecnie aplikacja zakłada trzy statusy:

  • zielony - jesteś bezpieczny
  • pomarańczowy - nie wiadomo
  • czerwony - poddaj się kwarantannie

Status czerwony wynika najprawdopodobniej (algorytm decydujący o tym ani nie jest otwarty, ani nie jest zabezpieczony licencjamie) z faktu że analiza danych wykazała że jest duże prawdopodobieństwo, że było się blisko osoby która została zdiagnozowana na COVID-19. Nie jest jasne, co potem dzieje się z osobą która ma status czerwony. Czy ma zostać poddana kwarantannie od razu ? czy powinna się poddać testowi natychmiast i kwarantannie ? w jaki sposób status takiej osoby zmienia się z powrotem na zielony ? Trudno powiedzieć, obecna specyfikacja na ten temat nic nie mówi i jest to olbrzymia "dziura" w designie całego rozwiązania.

Nie jestem epidemiologiem, i nie wiem czy ktokolwiek (najlepiej specjalista-epidemiolog) spojrzał na możliwe wartości i policzył w jaki sposób "czerwone" będzie się propagowało przez społeczeństwo. Wydaje się - że przy zarażalności i częstej bezobjawowości rozprzeztrzeniania się wirusa, bardzo szybko status "czerwony" będzie dotyczył większości z nas. Mam nadzieję że przed wdrożeniem aplikacji epidemiolodzy zrobią odpowiednie symulacje a nie że będzie to jeden wielki eksperyment bez świadomości co robimy. W tym wypadku "szybkość" wdrożenia jest o wiele mniej ważna niż "poprawność" - aplikacja będzie potrzebna za 5-10 tygodni jak minie szczyt zarażeń i zaczniemy rozluźniać izolację.

Zwłaszcza że istnieje spore zagrożenie manipulacjami algorytmów po stronie analizy danych (dodam ponownie - algorytmy te nie są w żaden sposób udostępnione publicznie i nie podlegają kontroli społecznej). Problem rozwiązuje #34, gdzie algorytm wykonuje się na telefonie a nie w tajemniczej chmurze nad którym kontrolę będzie miała (zakładam) strona rządowa. Było na ten temat issue #4 kiedy algorytm miał być (chyba) po stronie aplikacji ale zostało ono zamknięte. W chiwili obecnej algorytm nie jest publiczną częścią rozwiązania.

Mam nadzieję że algorytmy te zostaną upublicznione.

Moja propozycja jest taka, żeby rząd pełnił w przypadku tej aplikacji - z resztą jak we wszystkim powinno być - rolę usługową dla ludzi a nie kontrolującą i infiltrującą. Aplikacja zamiast mówienia "poddaj się kwarantannie" powinna mówić "poddaj się testom" i w takiej sytuacji powinna być przepustką do natychmiastowego i darmowego wykonania testów na COVID-19 na koszt społeczeństwa (administrowany i na masową skalę udostępniony przez stronę rządową).

Status "podddaj się testowi" powinien wprowadzać pewne ograniczenia dla tej osoby - na przykład nie powinna mogła wchodzić na masowe imprezy. Wraz z wynikiem testu powinien zostać osobie testowanej kod identyfikujący czy wynik jest "chory" czy "zdrowy" i na tej podstawie powinien zostać zmieniony status w aplikacji ("chory" - "czerwony", "zdrowy" - zielony). Strona rządowa powinna zabezpieczyć odpowiednią liiczbę testów (na podstawie symulacji) oraz punktów w których szybko można się poddać testom - dopiero wtedy aplikacja taka będzie miała sens.

W tym modelu - powtórzę to z #34 - nie ma konieczności podawania numeru telefonu przy starcie aplikacji. Nawet jeśli chcemy zacząć zbierać dane już teraz i wypuścić aplikację szybko.

Apeluję o wypuszczenie aplikacji bez podawania numeru telefonu w jej pierwotnej wersji i przemyślenie modelu aplikacji wraz z epidemiologami i uwzględniając status "poddaj się testom" i możliwość ich zrealizowania zapewnioną przez rząd Rzeczpospolitej Polskiej.

Dorejestrowanie numer telefonu, usunięcie konta

W kolejnej wersji apki powinniśmy pozwolić na dorejestrowanie numeru telefonu dla użytkownika który nie zrobił tego przy pierwszych uruchomieniu.
Potrzebujemy też opcji: usuń konto.
To issue powinno być zamienione na issues w poszczególnych podprojektach.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.