search

ProteGO-Safe / specs

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

Część serwerowa rozwiązania G+A #176

Closed pkleczko closed 4 years ago

pkleczko commented 4 years ago

Jak wiecie pracujemy nad wdrożeniem rozwiązania Exposure Notification (EN) od Google i Apple (przetłumaczonego na polski przez G+A jako "Powiadomienia o ryzyku ekspozycji na koronawirusa"). Co raz więcej informacji staje się publicznie dostępnych i możemy się do nich odnosić.

To na co warto zwrócić uwagę i czego nie udało się pominąć również w tym "zdecentralizowanym" rozwiązaniu to cześć serwerowa systemu, która pewne dane musi gromadzić i być swoistym łącznikiem dla aplikacji różnych użytkowników.

Dla przypomnienia lub streszczenia tego rozwiązania , działa ono w następujący sposób:

Częściami składowymi systemu są zatem:

Każda aplikacja korzystająca z EN odpowiada za część serwerową systemu. W zasadzie jedynym narzuconym rozwiązaniem jest format plików, które powinny być udostępniane aplikacjom do ich pobierania i analizy. Format ten opisany jest szerzej tutaj: Exposure Key File Format and Verification

Google udostępniło w ostatnich dniach przykładową implementację częsci serwerowej, z zaimlementowanym mechanizmem generowania i udostępniania odpowiednich plików. Tworzone są one periodyczne z danych przechowywanych w bazie danych na serwerze. Do bazy danych są zapisywane przychodzące dane od osób uprawnionych do ich uploadu (na podstawie "Mechanizmu weryfikacji osób potwierdzonych zarażeniem"). G+A proponują również kilka ważnych mechanizmów weryfikacji aplikacji, które mają chronić system przed próbą zuplodowania danych od osób trzecich. Dokumentacja tego rozwiązania znajduje się tutaj: Server Functional Requirements Przykładowa implementacja serwera znajduje się w tym samym repozytorium: Exposure Notification Server.

Proponowany przykład wdrożenia serwera wydaje się nam o tyle atrakcyjny, że może znacznie przyspieszyć prace nad integracją ProteGO Safe z EN. Również zawiera kilka dobrych rozwiązań związanych z bezpieczeństwem danych. Na pewno to co nas czeka to modyfikacja samego uploadowania danych, myślimy o dwu-stopniowym procesie, który w pierwszym kroku zautoryzuje aplikację ("Mechanizm weryfikacji osób potwierdzonych pozytywnym zarażeniem") a dopiero w drugim kroku wyśle dane na serwer (wykorzystując krótkotrwały token autoryzacyjny otrzymany w kroku pierwszym).

Google cały czas pracuje nad rozwiązaniem sporej ilości błędów i problemów udostępnionej części serwerowej (co można zauważyć po ilości Issue'sów otworzonych na GH), więc trzeba sobie zdać sprawę, że to też nie jest jeszcze dojrzały produkt.

Jesteśmy ciekawi Waszej opinii dotyczącej tej części systemu i analizy rozwiązania, zwłaszcza problemy i zagrożenia jakie w nim widzicie. Na ten moment skłaniamy się do wykorzystania kodu Google. Jednym z argumentów za tym przemawiających jest też to, że pomimo niewielu rozmów na temat interoperacyjności podobna architektura zastosowana w różnych systemach może ja w przyszłości znacznie ułatwić.

Dr-Kownacki commented 4 years ago

Czy mógłbyś ew. zaspokoić ciekawość naszego środowiska i ewentualnie ( oczywiście jeśli możesz / masz dostępny ) podlinkować nam tutaj taki przykładowy plik "z zebranymi-opublikowanymi kluczami" jaki będzie docelowo ściągany lokalnie na aplikację z takiego serwera ? Czy on jest jakoś "zaszyfrowany/skompresowany" etc. w tym przygotowywanym standardzie A+G ? Może ktoś tutaj chciałby to jakoś "zdekompilować/rozszyfrować" przez ciekawość nawet ;-)

Drugie moje pytanie dotyczy informacji na temat tego jak często wg.Waszej wiedzy aplikacja będzie pobierać te pliki ? Raz dziennie ? Częściej ?

Wcześniej dyskutowaliśmy już na temat optymalnej częstości sprawdzania tych "opublikowanych kluczy" ( https://github.com/ProteGO-Safe/specs/issues/107#issuecomment-617115544 ) a także na temat hipotetycznej "ilości danych" krążących z tego powodu w sieci m.in. z @potiuk (to ostatnie jak pamiętam miało teoretycznie nie być realnym problemem).

pkleczko commented 4 years ago

@Dr-Kownacki nie mamy jeszcze własnego example'a żeby się podzielić, ale we wspomnianym repo jest taki przykładowy plik. Ten plik składa się z dwóch części: pliku z danymi i pliku weryfikacyjnego. Plik z danymi będzie podpisywany odpowiednim certyfikatem, a aplikacje żeby zostać zatwierdzone przez G+A będą musiały im dostarczyć odpowiedni klucz publiczny.

Co do drugiego pytania to analiza raz dziennie będzie wystarczająca i raczej taką zastosujemy, natomiast w zależności od ilości danych może być podzielona na kilka 'cykli' - pobierane pliki nie mogą być zbyt duże, więc trzeba je podzielić. Tutaj mamy pewien rozjazd między rekomendacjami Google (16MB) i Apple (0,5MB) co do wielkości pliku i jeszcze ustalamy prawidłową wartość.

tomekziel commented 4 years ago

Jesteśmy ciekawi Waszej opinii dotyczącej tej części systemu i analizy rozwiązania, zwłaszcza problemy i zagrożenia jakie w nim widzicie.

Ja to na przykład jestem bardzo ciekaw treści NDA które podpisaliście. To już prawie dwa tygodnie ignorowania (#145), tymczasem minister Zagórski tak pięknie opowiadał o otwartości...

REDACTED -- Panie Tomku, proszę nie powielać wątków. Rozumiem rozczarowanie związane z brakiem odpowiedzi ale nie może to wpływać na komunikację na tym forum. Przypominam, iż Pana wątek #145 pozostaje otwarty nie bez powodu.

SeraMoon commented 4 years ago

Skoro to rozwiązanie ma mieć serwer i coś musi być wysyłane, to mam inne rozwiązanie, które może być zaimplemetowane jakie jest lub po analizie podatności ulepszone i zaimplementowane - nie ufam komuś, kto musi wraz z moim IP zapisywać "anonimowe" klucze, ponieważ wraz z IP te informacje są co najwyżej pseudonimizowane.

TrackVirusTogether

Trzeba jednak w jakiś sposób usunąć ze standardowych komunikatów BLE nazwę telefonu.

Dr-Kownacki commented 4 years ago

@pkleczko w moim przekonaniu sprawdzanie (jak postulujesz) "raz dziennie" może jednak być niewystarczające, dla ułatwienia ponowię moją tezę wprost z #107

=

Przyjmijmy że spotkaliśmy kogoś 9 dni temu, kto albo zaczął mieć objawy "następnego dnia" albo po prostu jest "bezobjawowym nosicielem" i informacja o zakażeniu u niego wynikła tylko z przypadkowych okoliczności (bo testy robiono wszystkim w pracy - vide np. szpital gdzie jest ognisko etc.), generalnie: ten człowiek 9 dni temu już zarażał.

Stąd jeżeli my go spotkaliśmy i zaraziliśmy się to jesteśmy albo w okresie inkubacji choroby - zarażamy ale objawy będą dopiero jutro/pojutrze (są różne szacunki nawet +-4 dni ponoć), albo my również będziemy "bezobjawowymi/ skąpo objawowymi nosicielami).

Dzisiaj jest wtorek, minionej nocy z poniedziałku/wtorek moja komórka sprawdziła wszystkie klucze i pokazuje że nie miałem (uchwyconej przez system) ekspozycji.

O 8:00 rano idę więc do pracy na 12 godzinny dyżur, spotykam mnóstwo osób w tym czasie ale już potencjalnie mogę każdego zarazić o czym oczywiście nie wiem.

Natomiast osoba która mnie zaraziła została zdiagnozowana dzisiaj o godz.10:00 i jej klucze zostały wgrane do systemu, jednakże o tym że ja zostałem potencjalnie "trafiony" dowiem się dopiero w nocy z wtorku/środę i dopiero we środę dostanę warninga i zacznę się izolować/badać od środy...

"Stracona" została więc praktycznie całą doba, i miałem w tym czasie kontakt z 50 osobami. z których część mogłem potencjalnie zarazić.

Gdybym dostał warninga wcześniej (po prostu tego samego dnia) to zrobiłbym od razu test i przede wszystkim wyszedłbym z pracy na kwarantannę domową do czasu otrzymania wyniku testu.

Nie spotkałbym się np. z 30 osobami więc nie mógłbym ich potencjalnie zarazić i nie zrobiłbym być może wielu potencjalnie ryzykownych dla pozostałych osób rzeczy...

Co Wasz Zespół sądzi o takim spojrzeniu na problem ? Czy nie należałoby jednak przynajmniej ze 4x na dobę tego sprawdzać ?

SeraMoon commented 4 years ago

Gdybym dostał warninga wcześniej (po prostu tego samego dnia) to zrobiłbym od razu test i przede wszystkim wyszedłbym z pracy na kwarantannę domową do czasu otrzymania wyniku testu.

@Dr-Kownacki

a co z faktem, że wiele osób pracuje nie-zdalnie i mimo komunikatu, próby udania się na test, test robiony jest im dopiero 3 dni później (typowe w Polsce), musi czekać na wynik załóżny 2 dni, a Pan musi iść do pracy (i zarażać)? Dni urlopu na żądanie może nie starczyć, a pracodawca nie ma obowiązku dać urlopu.

Poza tym Kwarantanna - czy na niej dostaje się L4 czy dopiero po pozytywnym wyniku dostaje się w Izolacji (Kwarantanna =/= Izolacja - mimo, że mogą przebiegać podobnie)?

potiuk commented 4 years ago

@SeraMoon -> co do danych osób chorych i zdiagnozowanych - to faktycznie w połączeniu z IP są pseudonimizowane, ale za to rząd nie ma żadnego powodu żeby te IP przechowywać - bo rząd i tak wie, kto te dane wysyłą (każda osoba wysyłająca dostaje unikalny PIN który utoryzuje upload).

W tym wypadku - według mnie, jest OK żeby "Exposure Keys" były wysyłąne i potem były publiczne.

Dr-Kownacki commented 4 years ago

W moim przekonaniu jeżeli zostanie dyskutowane tutaj rozwiązanie oficjalnie (przecież przez rząd) usankcjonowane i wprowadzone, to muszą za nim pójść adekwatne zapisy (jak to zrobić to już do ZUS etc. pytania) pozwalające na:

a) z żelazną dyscypliną dostęp do testów w najkrótszym możliwym czasie

b) osoby na kwarantannie nie powinny dostawać bynajmniej L4 (70% wynagrodzenia ?) tylko w moim przekonaniu powinno być to pełne 100% bo to że ta osoba siedzi w domu na izolacji jest w interesie całego społeczeństwa przecież a już w szczególności pracodawcy/współpracowników

c) informacja z aplikacji z powyższych przyczyn raczej MUSI być traktowana jako oficjalny dokument przedstawiany przez daną osobę, ale tutaj z kolei powstaje problem, bo przecież nawet na niniejszym forum większość osób jest jednak przeciwna wobec "rejestracji użytkownika". W moim przekonaniu jedyna techniczna droga na udowodnienie że to jest warning, który przyszedł do konkretnego użytkownika telefonu (czyli osoby na którą telefon jest zarejestrowany), to po prostu jakieś LOKALNE powiązanie fizycznego numeru karty SIM z wewnętrznym logiem otrzymanych/zapisanych kluczy.

d) kwestia adekwatnych rekompensat dla osób samozatrudnionych - przypuszczalnie do minimalnej albo średniej krajowej (?)

Jak rozwiązać kwestie komórek "firmowych" czyli nieprzypisanych do konkretnych osób - tego nie wiem, ale z drugiej strony jakieś "kadry w firmie" są w stanie poświadczyć że ten człowiek - ich pracownik jest po prostu użytkownikiem tego telefonu i w moim odczuciu byłoby to wystarczająco oczywiste poświadczenie dla ZUS etc. .

Reasumując: wszystko w/w. powinno być wręcz uregulowane co do adekwatnych rozporządzeń/ustaw w przeciwnym razie cały ten pomysł straci sens, bo albo poważnie podchodzi się do tematu albo wszystko będzie totalną fikcją.

Trudno dokładnie określić jak długi powinien być ten okres izolacji/kwarantanny ale na pewno w cały proces trzeba co najmniej 2 testy rtPCR włączyć oraz być może wiarygodne testy w oparciu o przeciwciała - jak już będą odpowiednio zwalidowane i adekwatnie dostępne.

potiuk commented 4 years ago

Google udostępniło w ostatnich dniach przykładową implementację częsci serwerowej, z zaimlementowanym mechanizmem generowania i udostępniania odpowiednich plików. Tworzone są one periodyczne z danych przechowywanych w bazie danych na serwerze. Do bazy danych są zapisywane przychodzące dane od osób uprawnionych do ich uploadu (na podstawie "Mechanizmu weryfikacji osób potwierdzonych zarażeniem"). G+A proponują również kilka ważnych mechanizmów weryfikacji aplikacji, które mają chronić system przed próbą zuplodowania danych od osób trzecich. Proponowany przykład wdrożenia serwera wydaje się nam o tyle atrakcyjny, że może znacznie przyspieszyć prace nad integracją ProteGO Safe z EN. Również zawiera kilka dobrych rozwiązań związanych z bezpieczeństwem danych. Na pewno to co nas czeka to modyfikacja samego uploadowania danych, myślimy o dwu-stopniowym procesie, który w pierwszym kroku zautoryzuje aplikację ("Mechanizm weryfikacji osób potwierdzonych pozytywnym zarażeniem") a dopiero w drugim kroku wyśle dane na serwer (wykorzystując krótkotrwały token autoryzacyjny otrzymany w kroku pierwszym).

Google cały czas pracuje nad rozwiązaniem sporej ilości błędów i problemów udostępnionej części serwerowej (co można zauważyć po ilości Issue'sów otworzonych na GH), więc trzeba sobie zdać sprawę, że to też nie jest jeszcze dojrzały produkt.

Patrząc na te issuesy - to tam nie ma zbyt wielu "błędów". Są tam głównie potencjalne refaktory, usprawnienia, TODOs, rzeczy które można poprawić, ale nie ma tam - z tego co widziałem "błędów". Praktycznie wszystkie "issues" są stworzone przez samych twórców aplikacji. To akurat wygląda na "zdrowy" projekt prowadzony publicznie - tak że można widzieć co się dzieje. BTW. Życzyłbym Wam też takiej otwartości i publikowania wszystkiego co się dzieje i kodu na bieżąco na GitHubie. Trochę sie dziwię że tak jeszcze nie jest, mimo wcześniejszych zapewnień. Trochę wygląda na to, że chcecie pomocy od community (np. w tym isssue) a sami nie dzielicie się swoją pracą. To bardzo niesymetryczne i zniechęcające do współpracy.

Jesteśmy ciekawi Waszej opinii dotyczącej tej części systemu i analizy rozwiązania, zwłaszcza problemy i zagrożenia jakie w nim widzicie. Na ten moment skłaniamy się do wykorzystania kodu Google. Jednym z argumentów za tym przemawiających jest też to, że pomimo niewielu rozmów na temat interoperacyjności podobna architektura zastosowana w różnych systemach może ja w przyszłości znacznie ułatwić.

Ten kod serwrera wygląda ogólnie ok. Chętnie podzieliłbym się szczegółowymi komentarzami - jak tylko zaczniecie publikować swój kod na bieżąco. Nie wiemy co z tego kodu wzięliście/chcecie wziąć, więc trudno się w jakkolwiek sposób na ten temat wypowiadać.

potiuk commented 4 years ago

W moim przekonaniu jeżeli zostanie dyskutowane tutaj rozwiązanie oficjalnie (przecież przez rząd) usankcjonowane i wprowadzone, to muszą za nim pójść adekwatne zapisy (jak to zrobić to już do ZUS etc. pytania)

@Dr-Kownacki - jestem absolutnie za. Dodatkowo, musi być robiony klasyczny "contact tracing" osób zdiagnozowanych i BT musi być tylko dodatkiem (o przyczynach pisaliśmy już wcześniej). Nie wiem czy Twórcy aplikacji się do tego jakoś odniosą (bo to przecież nie jest w ich kompetencjach), ale już MC w porozumienu z innymi Ministerstwami powinno. Od początku uważam że status "zagrożony" powinien być przepustką dla szybkich i darmowych testów. Kwestie L4/etc. do tej pory w ogóle nie rozważałem a to faktycznie ważne i mam nadzieję że rząd się tym zajmie. Ja bym raczej był za skierowaniem do pracy zdalne (jeśli to możliwe) a jeśli nie możliwe to płacenie 100% do momentu wykonanania testu (co by przyspieszyło wykonanie testu właśnie - państwu wtedy by się "opłacało" robić szybkie testy).

Według mnie nie ma potrzeby de-anonimizacji. Wystarczy potwierdzić autentyczność aplikacji - w formatach plików opisanych przez Google i Apple są dodatkowe dane ("device attestation") które pozwalają na stwierdzenie czy aplikacja/urządzenie są "legit" - czyli czy nie są rootowane/aplikacja podstawiona. I wydaje się że była by możliwość wygenerowania na serwerze anonimowego potwierdzenia, podpisanego kluczem prywatnym "Health Authority" - takiego kodu który dawalby możliwość zweryfikowania faktu "jestem zagrożony" wewnątrz kodu aplikacji.

Poza tym - osoba która jest zagrożona i chciała by się zbadać i tak musi ujawnić swoją tożsamość, więc pole do nadużyć jest niewielkie i można nadużycia wykryć w tym właśnie momencie (na przykład przez weryfikację autentyczności aplikacji - wbudowaną w aplikację). Robiliśmy coś bardzo podobnego w przypadku implementacji aplikacji IKO (PKO BP) - pierwszej implementacji BLIK-a. Można dość skutecznie zobfuskować taki kod (napisać, skompilować i zobfuskować w kodzie w języku programowania C) - dodając do tego sprawdzenie "hash-a" binarki aplikacji (żeby upewnić się, że nie była zmodyfikowana). Tu się pochwalę - ale audyt aplikacji który wtedy zrobiliśmy - nie ja, więc chwalę się w imieniu osób z firmy, które nad tym pracowały - przeszedł "śpiewająco". Poważny audytor powiedział że to była pierwsza aplikacja na Androida w której nie udało im się podsłuchać, co aplikacja wysyła na serwer.

Jeszcze za dużo o tym nie myślałem, ale nie wydaje się to niemożliwe. Pewnie nie da się wszystkich "oszustów" wyelimnować, ale na pierwszy rzut oka trzeba by się było nieźle napocić żeby to wykorzystać.

miklobit commented 4 years ago

Jeszcze za dużo o tym nie myślałem, ale nie wydaje się to niemożliwe. Pewnie nie da się wszystkich "oszustów" wyelimnować, ale na pierwszy rzut oka trzeba by się było nieźle napocić żeby to wykorzystać.

Wg mnie aplikacja i regulacje prawne które musza jej towarzyszyć nie powinny sie w ogóle zajmować "oszustami" , tylko wyelimnowaniem problemów dla zwykłych użytkowników, które się pojawią jak tylko pierwsze zdiagnozowane osoby przekażą rządowi urobek zebranych kontaktów i te kontakty otrzymają automatyczne powiadomienia. Właściwa reakcja na takie powiadomienie jest kluczowa więc pytanie czy odpowiednie regulacje będą gotowe na moment oddania nowe wersji aplikacji. Np kwestia czy kwarantanna (która normalnie wymaga wydania decyzji - i to jest umocowane w ustawie) będzie dla delikwenta obligatoryjna już od momentu otrzymania powiadomienia, czy dopiero od momentu kiedy sam się zgłosi na badanie (bo nikt go nie zmusi do ujawnienia że w ogóle dostał powiadomienie). Niewykluczone, że regulacje prawne potrzebne do sensownego ustalenia takich spraw będą musiały mieć rangę ustawy bo będa ingerowować w wolność i prawa jednostki w sposób do tej pory nie uwzględniony. Czyli czas na wydanie regulacji się wydłuża (nawet przy ekspresowych terminach na których pracuje u nas nierząd) a aplikacja już działą i stawia ludzi przed konkretnymi decyzjami które mają dla nich życiowe i finansowe skutki. Czy zespół który realizuje prace dla MC ma odpowiedni feedback ze strony rządowej, że te prace (techniczne i prawne - te drugie będą angażować co najmniej 2 a może 3 różne ministerstwa) zostaną odpowiednio zsynchronizowane ? Bo nawet jeśli technicznie aplikacja wystartuje ale użytkownik nie będzie mieć pewności , że instalacja nie wpędzi go w kłopoty (np te problemy prawno/finansowe, niejasne/niesprawiedliwe zasady ) to będzie wielka klapa, która położy nadzieje na dobrowolne masowe użycie.

potiuk commented 4 years ago

Bo nawet jeśli technicznie aplikacja wystartuje ale użytkownik nie będzie mieć pewności , że instalacja nie wpędzi go w kłopoty (np te problemy prawno/finansowe, niejasne/niesprawiedliwe zasady ) to będzie wielka klapa, która położy nadzieje na dobrowolne masowe użycie.

W 100% się zgadzam. Wydaje mi się że na twórcach aplkikacj na zamówienie, zwłaaszcza takiej która potencjalnie ma wpływać na wszystkicj powinni czuć ciężar odpowiedzialności jaki na nich spoczywa. W przeciwieństwie do Twórców "bibliotieki" czy "API" (na przykład "Exposure Notfication") to Twórcy Aplikacji pownni przynajmniej zadawać pytania co do tego, czy to co robią ma sens - zwłaszcza że np. komunikacja w aplikacji zależy od tego w jaki sposob strona rządowa zapewni "obsługę" osób które dostały informację, że zostały zagrożone. Mam nadzieję że @MateuszRomanow na ten temat rozmawia z rządem.

@MateuszRomanow - może jakiś komentarz w tej sprawie jako łącznik ? Czy są plany ze strony ministerstwa co ludzie mieli by robić po "zagrożeniu"?

SeraMoon commented 4 years ago

Można dość skutecznie zobfuskować taki kod (napisać, skompilować i zobfuskować w kodzie w języku programowania C) - dodając do tego sprawdzenie "hash-a" binarki aplikacji (żeby upewnić się, że nie była zmodyfikowana).

Security by obscurity / obfuscity? 😹 Nie podoba mi się to rozwiązanie.

Raczej przydałby się weryfikator czy klucze się zgadzają - już po stronie Google. Przypominam, że nie można blokować urządzeń z VPN czy rootowanych (root znów padł w komentarzach).

Samo zgłoszenie wykonania testu powinno być przepustką na L4v2 (płatne 100%) - w końcu można mieć "złe spotkanie" w rzeczywistości i dowiedzieć się bez aplikacji, że osoba choruje na koronawirusa. Testy są tak niemiłosiernie niemiłe że i tak nikt nie będzie chciał odejść na dzień czy 2 z pracy, aby przejść ten ból i dostać 2 minusy po 2 kolejnych bolesnych pobraniach (o bolesności opowiadali sami pacjenci, zakładam, że mówili prawdę, że bolało i czuli jakby im ktoś w mózgu wiercił).

Przy takich testach to bardziej prawdopodobny jest scenariusz odwrotny - niezrobienie testu mimo informacji o potencjalnym zakażeniu.

że instalacja nie wpędzi go w kłopoty (np te problemy prawno/finansowe, niejasne/niesprawiedliwe zasady ) to będzie wielka klapa, która położy nadzieje na dobrowolne masowe użycie.

@miklobit niestety mam dla Ciebie złe wieści - aby to prawo było dobrze skonstruowane musielibyśmy my i przedsiębiorcy (+ niezależni prawnicy) być zaproszenie do jego tworzenia. Niestety Sejm (a raczej jego większość) nie zaprasza do żadnych rozmów międzyresortowych czy konsultacji społecznych. Bez konsultacji społecznych skończy się jak z tarczami antykryzysowymi. Ciężar obu czuję nadal na głowie jako miażdżący.

może jakiś komentarz w tej sprawie jako łącznik ? Czy są plany ze strony ministerstwa co ludzie mieli by robić po "zagrożeniu"?

Obecnie muszą to robić; https://oko.press/gorny-slask-masowe-zakazenia-w-kopalniach/

MateuszRomanow commented 4 years ago

Dzisiaj o 19:00 ma wejść ważne publiczne info od Googla w sprawie Exposure Notifications. Po tej informacji będziemy mieli dużo "pewnych" a nie "być może" informacji. Stay tuned!

KoderFPV commented 4 years ago

https://github.com/ProteGO-Safe/backend

Część serwerowa dostępna dla 4.1. Wątek dłuższego czasu nie aktywny.

Pytania / wątpliwości co do backendu zadajemy tutaj: https://github.com/ProteGO-Safe/backend/issues/