search

SeraMoon / ProjektPrywatnosc

Rozmowy o prywatności i wolności. Kontrolujemy kontrolujących.
3 stars 0 forks source link

Całkowicie zdecentralizowane śledzenie kontaktów przez BlueTooth/BLE #3

Open SeraMoon opened 4 years ago

SeraMoon commented 4 years ago

Rozwiązanie Exposure Notification (zwane też jako G+A) ma być jednak scentralizowane, gdyż nie jest w pełni zdecentralizowane.

Tymczasem jak można to zrobić w sposób w pełni zdecentralizowany i działający bez internetu.

Poniższy tekst w tym poście publikowany jest na licencji Creative Commons CC-BY-SA-40. Pracując w oparciu o ten tekst lub implementując to rozwiązanie należy wspomnieć autorkę z nicka: "Misutoresu9".

Nazwa rozwiązania TrackVirusTogether.

  1. Każde urządzenie generuje klucz publiczny i prywatny, czyli losowy ciąg znaków co 15 minut. Zapisuje na smartfonie zarówno klucz jak i wysyłany losowy identyfikator, aby później móc ich użyć.

  2. Każde urządzenie rozgłasza identyfikator i klucz publiczny 15-minutowy na niskiej mocy BLE umożliwiającej zadziałanie wykrycia spotkania. Inne urządzenia nasłuchują i zapisują unikalne wystąpienia wraz z czasem podzielonym modulo 7.5 minuty.

  3. Każdy Health Authority posiada swój klucz publiczny i prywatny. Klucz publiczny znany jest użytkownikom aplikacji

  4. Każde urządzenie które wychwyci komunikat informacyjny poprawnie zaszyfrowany kluczem prywatnym - przekazuje go dalej na największej dostępnej mocy, aby usłyszały go urządzenia będące w okolicy - 10 do 100 metrów.

  5. Jeżeli komunikat zawierał identyfikator (i/lub klucz publiczny) mojego smartfona - nie następuje przekazanie dalej komunikatu ale poinformowanie mnie, że miałam "zły kontakt" z prośbą o skontaktowanie się z Sanepidem, Szpitalem, inne instrukcje.

  6. Każdy komunikat podpisany przez Health Authority posiada znacznik czasu kiedy został wygenerowany, identyfikator/klucz prywatny 15-minutowy użytkownika który spotkał się z tą osobą. Smartfony zapisują skróty tej wiadomości po rozesłaniu ich dalej aby nie spowodować DDoS oraz nie marnować baterii - rozgłaszają ten komunikat przez 1 dobę w odstępach 15-30 minutowych.

  7. Informacje są gromadzone przez 21 dni dla wirusa SARS-CoV-2 (1.5x maksymalny czas wylęgania danego wirusa). Po tym czasie usłyszane klucze są usuwane z pamięci smartfona, zaś własne klucze są usuwane po 23 dniach (2 dni na dotarcie informacji siecią BT od Health Autority, że mieliśmy "zły kontakt").

  8. W sytuacji kiedy aplikacja jest używana przez minimum 30% populacji (a tylko wtedy ma ona sens) - komunikat dojdzie przez sieć smartfonów do adresata niczym plotka powtórzona wielokrotnie trafia do osoby pomawianej. Funkcja TrackVirusTogether została więc spełniona jeżeli te kontakty są na prawdę częste, a tylko wtedy mamy możliwość realnie się zakazić SARS-CoV-2.

potiuk commented 4 years ago

Szczerze mówiąc nie bardzo rozumiem jak ten algortym miałby działać i w jaki sposób osoby zdiagnozowane jako chore są potwierdzane przez Health Authority, czy mogłabyś to wyjaśnić w bardziej przystepny sposób @SeraMoon (bo z tego opisu to nie wynika w żaden sposb). Czy są jakie whitepapers/peer reviewed specyfikacje, które to opisują? Chętnie poznałbym źródła, bo to wygląda na ciekawą koncepcję, ale nie bardzo wiadomo jak to miało by być zaprojektowane.

SeraMoon commented 4 years ago

@potiuk

Ogólnie komunikaty "codziennej widoczności" byłyby komunikatami typu 1. Komunikaty Health Autorities byłyby komunikatami typu 2.

Budowa komunikatu typu 2: Header, zaszyfrowany kluczem publicznym użytkownika widzianego jego identyfikator (lub cokolwiek innego - np. wyliczone ryzyko zakażenia, nazwa choroby, niekoniecznie COVID-19 - przyszłosciwo).

Komunikat ten po odebraniu przez właściwą osobę jest rozpoznawany jako własny, bo udało się poprawnie wiadomość rozszyfrować (uzyskać własny identyfikator, nazwę choroby zakaźnej, określone ryzyko choroby - np. "przebywanie z osobą chorą przez 6 godzin". Taki komunikat tym samym nie zawiera jawnie zapisanego 15-minutowego klucza danej osoby i nie da się go złośąliwie rozgłosić później, bowiem zaszyfrowany jest kluczem publicznym osoby. Do odszyfrowania potrzebny jest klucz prywatny, który zna tylko osoba przebywająca w okolicy osoby zdiagnozowanej (podejrzana).

Całość na razie jest koncepcją jak zrobić system zdecentralizowany w 100% bez jakiegokolwiek serwera i bez transmisji przez Internet (tą część zastępuje system zdecentralizowany "donoszenia" o infekcji - system podobny do roznoszenia plotek :wink: ).

Czy potrzebne są rysunki jak to ma działać w skupiskach ludzi, gdzie poruszają się oni i uzyskują zasięg pomiędzy nimi choćby kimś innym z aplikacją, jak taka informacja trafi do zakażonego całkiem anomimowo?

Źródeł brak, bo jest to koncepcja do dyskusji i implementacja powinna odbyć się po dyskusji osób zainteresowanych. Warto byłoby też potwierdzić prywatność i anonimowość takiej transmisji danych.

Szczegółowa procedura wysłania komunikatu od HealthAuthority:

  1. Health Authority po uzyskaniu informacji o dodatnim teście pobiera (przez BlueTooth po zgodzie użytkownika) identyfikatory 15-minutowe osób widzianych w ciągu 14-21 ostatnich dni.
  2. Zalecane jest potraktować każdy rekord oddzielnie. Identyfikator użytkownika, wraz z wyliczonym ryzykiem zakażenia (co innego widzieć się 15 minut, co innego 6h z chorą osobą). a) Mamy więc [identyfikator, nazwę choroby zakaźnej, ryzyko]. b) szyfrujemy kluczem widzianej osoby [identyfikator, nazwę choroby zakaźnej, ryzyko]. c) health authority dokonuje cyfrowego podpisania tej wiadomości kluczem prywatnym. d) na początku dopisuje "TVT\xF0\x02" (typ drugi komunikatu) - celem identyfikacji protokołu TrackVirusTogether) oraz typ komunikatu 02 - Informacja o zakażeniu. e) wysyła to w eter aby się w ciągu doby rozpropagowało jak najdalej w odstępach 15-minutowych przez smartfony tłumu.

Informacja ta trafia do kogoś po środku. Po rozszyfrowaniu widzi coś losowego co nie jest niczyim identyfikatorem, reszta informacji jest do niczego. Sprawdza więc podpis wiadomości - jeżeli jest prawidłowy rozsyła to dalej robiąc za repeater i przedłuża zasięg wiadomości.

Informacja trafia w końcu do odpowiedniej osoby: po rozszyfrowaniu widzi swój identyfikator sprzed 3 dni oraz dodatkowe infoemacje o chorobie, ryzyku itp. Na ekranie komórki widzi: "Miałeś kontakt z osobą chorą na GRUŹLICĘ 3 DNI temu przez PÓŁ DNIA". Skontaktuj się pilnie z ośrodkiem zakażeń ble ble ble. Jeżeli podpis cyfrowy się nie zgadza (klucz publiczny znany aplikacji) - komunikat nie wystąpi.

W przypadku choroby COVID-19 - komunikat aby zadzwonił na 800-190-590 i zasięgnął informacji jak postępować + informacja, że ma wysokie ryzyko infekcji COVID-19.

potiuk commented 4 years ago

@SeraMoon Nie bardzo wiem o którym wątku mówisz ? - Czy to wszystko co tu opisujesz powyżej? bo jeśli tak to dalej niestety nie rozumiem i obraki na pewno by się przydały.

Z tego co rozumiem to jedyna zaleta tego rozwiązania jest taka że "oficjalne" informacje potwierdzone przez Health Authority (za pomcą kludcza) są rozsyłane przez zdecentralizowaną sieć urządzeń.

Nie bardzo rozumiem w czym takie rozwiązanie miało by być lepsze niż serwer z tego samego Health Authority publikujący publiczne dane za pomocą serwera ? Przed czym miało by to chronić i dlaczego miao by to być rozwiązanie lepsze niż centralny serwer z informacjami które już (patrząc na specyfikacje Google + Apple https://static.googleusercontent.com/media/www.google.com/pl//covid19/exposurenotifications/pdfs/Exposure-Key-File-Format-and-Verification.pdf - już są podpisane za pomocą prywatnego klucza Health Authority i aplkacja powinna je weryfikować za pomocą klucza publicznego.

Według mnie jedyna różnica jest w braku serwera - przeplyw informacji jest wolniejszy i uzależniony od tego czy spotkaliśmy inne urządzenia. Ale nie jest to ani bardziej prywatne, ani bardziej bezpecznie ani mniej podatne na hackerów/manupulacje. Chyba że się mylę? I jest jakiś powód?

Czy mogłabyś opisać czemu to "bezserwerowe" rozwiązanie miało by być lepsze?

SeraMoon commented 4 years ago

@potiuk Sorry, edytowałam po drodze - byłam wcześniej w wątku 176. Proszę więc jeszcze raz przeczytaj całość. Przepraszam za pomyłkę.

Z tego co rozumiem to jedyna zaleta tego rozwiązania jest taka że "oficjalne" informacje potwierdzone przez Health Authority (za pomcą kludcza) są rozsyłane przez zdecentralizowaną sieć urządzeń.

Tak - chodzi o to, aby wszystko poszło przez zdecentralizowaną sieć, i jednocześnie aby nie dało się wysyłać fałszywych alarmów.

Nie bardzo rozumiem w czym takie rozwiązanie miało by być lepsze niż serwer z tego samego Health Authority publikujący publiczne dane za pomocą serwera ?

  • Niepotrzebne łącze internetowe
  • Żaden serwer w tym Google, Apple inne firmy nie otrzymują tych informacji
  • Informacja jest zaszyfrowana i o zakażeniu i "mieniu kontaktu" dowiedzieć się może tylko osoba, która powinna (zauważ że identyfikator i nazwa choroby, czas inne dane są możliwe do pozyskania tylko u osoby, która podała swój identyfikator i klucz publiczny do zaszyfrowania komunikatów do niej - tak jak jest w GPG). Inni nic nie pobiorą, mimo że mogę repeatować i nic się nie dowiedzą z tej wiadomości.

Według mnie jedyna różnica jest w braku serwera - przeplyw informacji jest wolniejszy i uzależniony od tego czy spotkaliśmy inne urządzenia.

Czy trudno spotkać przez dobę inne urządzenia? Każdy się porusza i nawet gdy jest na odizolowanej wsi - ktoś "wywiezie" tą informację na teren innej wsi / miasta. Dokładnie tak samo jak wywiózł wirusa. Tylko wirus ma zasięg 8 metrów a bluetooth do 100 metrów. Edit: i BT ma dużo szybszą propagację niż Wirus, który potrzebuje się "wykluć".

potiuk commented 4 years ago

@potiuk Sorry, edytowałam po drodze - byłam wcześniej w wątku 176. Proszę więc jeszcze raz przeczytaj całość. Przepraszam za pomyłkę.

Czytałem. W dalszym ciągu mam pytanie - co takie zdecentralizowane podejście daje? Przed czym chroni? W czym jest lepsze? Nie bardzo widzę jakiekolwiek zalety tego rozwiązania w porównaniu z tym które jest zaimplementowane przy okazji serwera z - wyłącznie publicznymi - tymi samymi danymi które miały by być dystrybuowane w Twojej propozycji - podpisanymi w ten sam sposób.

SeraMoon commented 4 years ago

Lepsze jest:

Jakie daje to jeszcze możliwości:

Dla średnich odległości (do 30 km) - może się okazać nawet, że informacja z Health Autority trafi szybciej do użytkownika, który ma być poinformowany. Przy zasięgu BT 30m będzie to w najgorszym scenariuszu 1000 powtórzeń wiadomości, gdy ludzie są nieruchomi i nadają jednocześnie (czego trzeba uniknąć choćby ze względu na kolizje radiowe). Ludzie jednak mają tendencję do cześtego ponownego spotykania się w tym samym tygodniu - więc w scenariuszach mieszkania blisko (do 3 km) lub ciągłego jeżdżenia w te same miejsca (praca, sklep) informacja dotrze do nich szybko.

Rozgłaszanie można przyspieszyć, gdy w zasięgu znajdzie się smartfon, który właśnie nadał, że jest w kontakcie (i go zapisaliśmy) - wtedy bez zwiększonej mocy BT. Przy rozwiązaniu na cały kraj z serwerem - pozostaje pobierać informację w interwałach czasowych, gdzie najczęśćiej proponowany interwał to 24 godziny.

Jedynie spotkania zagraniczne (np. prezydenta USA z kimś z Polski) lub z drugiego końca Polski będą kłopotliwe, bo jedynie tam nie znajdzie się droga radiowa do przekazania informacji (oceany mogą być problemem, ze względu na niekursujące samoloty). Wisła nie jest problemem. Ktoś w samochodzie usłyszy komunikat i nada go za 15 minut po drugiej stronie mając w zasięgu innych kierowców i pieszych.

Całe rozwiązanie więc nie różni się od drogi jaką ludzie się infekują wirusem drogą kropelkową - tyle, że działa dużo szybciej dając informację zwrotną o zakażeniu.

potiuk commented 4 years ago
  • w decentralizacji samej jako sobie

To niczym nie poparta teoria. Nie barzdzo rozumiem czemu miało by tak być? Nie znam jakiejś uniwersalnej prawdy "decentralized lepszy od centralized". W zależności od kryteriów, które chcemy przyjąć centralized może być lepszy niż decentralized. Możesz to, proszę rozwinąć skąd taki pomysł, że centralized jest zawsze gorszy ?

  • braku potrzeby posiadania łącza i środków na koncie,

W obecnych czasach, kiedy mnóstwo osób korzysta z FB/Youtube/... etc, to jest raczej słaby powód - zwłaszcza że np.conocny download może działać przez WiFi. Czy masz jakieś dane mówiące o tym że znaczący procent osób nie posiada dostępu do internetu raz dziennie (wśród posiadaczy telefonów zdolnych do działania z BT 4.0+). Z doświadczenia to będą raczej promile, zwłaszcza że dostęp do internetu jest potrzebny choćby do zainstalowania aplikacji. Jakieś dane które by wskazywały, że dostęp do internetu jest problemem?

  • informacje kto jest chory są zaszyfrowane - w szyfrogramach nie widać identyfikatorów 15-minutowych.

W danych G+A tych informacji w ogóle nie ma. Tam są jedynie Diagnosis Keys (1 na dzień),

  • można wprowadzić wiadomośc typu 03 - symulacja propagacji wirusa w terenie - gdy 60% użytkowników będzie miało aplikację - będzie dało się znając parametry wirusa - przeprowadzić symulację jego propagacji, czyli przewidzieć gdzie będzie "na prawdę ciepło" jeżeli chodzi o ilość infekcji, dobowe przybliżone wzrosty itp. Całość wykona się nie na jednym komputerze obciązonym na maxa, ale na komórkach użytkowników w realnym terenie i przy realnej aktywności.

Nic nie stoi na przeszkodzie żeby to zrobić w modelu w którym jest serwer z Diagnosis Keys.

potiuk commented 4 years ago

Całe rozwiązanie więc nie różni się od drogi jaką ludzie się infekują wirusem drogą kropelkową - tyle, że działa dużo szybciej dając informację zwrotną o zakażeniu.

Myślę że przydało by się to skonfrontować z faktycznymi opóźnieniami w propagacji. W tej chwili protokół A+G jest zoptymalizowany pod kątem zużycia baterii i szybkości wykrycia sąsiednich "advertisments". I tu podstawowe kryterium to "wykryć te ID w ciągu 5 minut", nie natychmiast. Ze względu na ograniczenia technologii BT, tego się nie da zrobić lepiej/efektywniej. Więc każdy "Hop" to jest co najmniej dodatkowe 5 minut (średnio). 1000 powtórzeń wiadomości to 5000 minut = 83 godziny = 3.5 dnia.. Wolno. Naprawdę wolno.

potiuk commented 4 years ago

Już nie wspominam o tym że protokół BT jest bardzo, bardzo wolny jeśli chodzi o wysyłanie większej ilości informacji (Advertisment o którym mówimy to 32 bajty danych). Wysłanie tysięcy kluczy zarażonych osób do wszystkich sąsiednich telefonów może zająć wiele godzin (nie tylko minut). Jeśli to uwzględnimy, to mówimy o propagacji liczonej w tygodniach, jeśli nie miesiącach.

SeraMoon commented 4 years ago

Nie znam jakiejś uniwersalnej prawdy "decentralized lepszy od centralized

Mówił o tym Panoptykon w kontekście prywatności. Tam też odeślę do podcastów i do tekstu. System scentralizowany nigdy nie da pełnej anonimowości, choćby w zakresie kto korzysta z aplikacji - czy w wątku ProteGO-Safe, nie Ty o tym mówiłeś w kontekście IP?

W "projekcie Prywatność" kładziona jest maksymalna uwaga na właśnie prywatność, wolność i anonimowość - jako wartości, które każde rozwiązanie musi spełnić.

W obecnych czasach, kiedy mnóstwo osób korzysta z FB/Youtube/... etc, to jest raczej słaby powód

Jak będzie druga "awaria T-Mobile" przez to że ktoś zachorował, umarł na miejscu pracy i czegoś nie dopilnował - możliwa jest i awaria sieci telekomunikacyjnej i brak prądu jak też brak terminali do doładowań. Mi niejednokrotnie zabrakło środków na koncie zwykłej komórki bez androida. Zwyczajnie dlatego, że bałam się wyjść w czasie epidemii by ją doładować, a część sklepów była zamknięta "z powodu koronawirusa do odwołania". Inne z kolei nie przyjmowały gotówki. :/

WiFi - w dzisiejszych czasach 99% z nich jest zabezpieczone hasłem. Nie zamierzam kogoś prosić o dostęp. Po co prosić skoro można korzystać z darmowej technologii BT?

Z doświadczenia to będą raczej promile, zwłaszcza że dostęp do internetu jest potrzebny choćby do zainstalowania aplikacji

Aplikację instaluje się raz. Korzysta się z niej wiele miesięcy (to kilka do kilkunastu doładowań po drodze).

Jakieś dane które by wskazywały, że dostęp do internetu jest problemem?

Przepraszam, ale billingów nie prowadzę, ale miałam 2 razy brak możliwości nawet zadzwonienia, zanim dowiedziałam się, że to jest druga grypa i że ją przechorowałam. Gdybym tego nie wiedziała (o prawdziwej śmiertelności względem populacji) - dalej bym siedziała w kwarantannie ile się da - często nie mając nic na koncie (z banku nie doładowuję).

W danych G+A tych informacji w ogóle nie ma. Tam są jedynie Diagnosis Keys (1 na dzień),

Jak one są powiązane z kluczami użytkownika? W RODO mówi się o tym, że dane zaszyfrowane mocnym hasłem i mocnym algorytmem - gdy wyciekną - nie stanowią wycieku. Oczywiście do czasu odszyfrowania. Szyfrowanie tych informacji jest więc silniejszym lub równie silnym rozwiązaniem (zależnie czym jest diagnosis key). Proponowane tu rozwiązanie ma za zadanie być funkcjonalne (ma działać), zawarantować prywatność i anonimowość i być proste do zaimplementowania - im prostsze tym łatwiej będzie laikowi zrozumieć że jest anonimowy. Tym łatwiej też zrozumie je fundacja typu Panoptykon.

Rozwiązanie docelowe ma być w pełni otwarte, bez serwerów i bez wierzenia na słowo, że z tymi danymi ktoś czegoś nie zrobi jeszcze (nie wiemy co dzieje się tak na prawdę na serwerze).

Myślę że przydało by się to skonfrontować z faktycznymi opóźnieniami w propagacji.

To da się zrobić tylko gdy ludzie chętnie zainstalują aplikację.

Ze względu na ograniczenia technologii BT, tego się nie da zrobić lepiej/efektywniej. Więc każdy "Hop" to jest co najmniej dodatkowe 5 minut (średnio). 1000 powtórzeń wiadomości to 5000 minut = 83 godziny = 3.5 dnia.. Wolno. Naprawdę wolno.

Skąd wynika 5 minut? Po usłyszeniu sygnału typu 02 - mogłoby się to odbywać niezwłocznie, aby usłyszały inne urządzenia (im więcej usłyszy, tym więcej potem sygnałów powtórkowych z różnych urządzeń). Ile czasu trwa nadanie 1 ramki zawierającej do 500 bajtów (mowa tu o ramkach od Health Autority) - ile to zużyje mikrowatów?

Załóżmy pierwszy sygnał(nadawany co 15 minut) usłyszy 5 komórek. Ten sygnał w kierunku osoby zakażonej usłyszy następne 10 komórek (czyli średnio już co 1.5 minuty), dalej to może być już nawet 30 komórek które usłyszą kolejną propagację (mamy już repeatowanie co pół minuty (pamiętamy o istnieniu samochodów i komórek wewnątrz - co przyspiesza przekazanie informacji "do miejsca", jak też o telefonach z zasięgiem BT do 100m).

Niestety najgorsze jest to, że nie da się ustawić aplikacji aby działając w tle mogła nadawać sygnał BT. Jeżeli Google się nie zgodzi by użytkownik mógł to ustawić to i tak skazane jest to na porażkę o politykę gigantów.

wykryć te ID w ciągu 5 minut

Nie wróży to dobrze. Advertisement na niskiej energii powinien trwać znacznie częściej, aby dało się stwierdzić, czy z kimś rozmawialiśmy czy tylko go minęliśmy. Rozmowa 4 minutowa z osobą zakażoną (potwierdzoną potem jako test dodatni) w odległości 1 metra powinna być brana jako czynnik ryzyka.

Ponadto: Ile możemy mieć dziennie nowych wiadomości od Health Authority? Patrząc na Włochy nie jest to więcej niż 10 tys. w zakresie całego kraju. Czy rozesłanie tylu ID (razy 96) zje aż tak dużą część baterii? Pytam dlatego - bo usłyszawszy nową (rózną od poprzednich) prawidłową wiadomość typu 02 można by powtórzyć ją pierwszy raz minutę lub pół po usłyszeniu. To jej dostarczenie na odległość 30 km znacznie by przyspieszyło.

potiuk commented 4 years ago

@SeraMoon -> wyraźnie nie orientujesz się co do różnic w działaniu BT między urządzeniami a połączeniem z internetem z urządzenia. Technicznie propagacja danych o których mówisz będzie trwała (znowu według moich szacunków powyżej) - dni, tygodnie, może miesiące. Chętnie poznam od Ciebie wiarygodne wyliczenia bazujące na rzetelnych podstawach w tym temacie, bo na razie prezentujesz pogląd że informacja za pomocą BT rozpowszechnia się natychmiast, a zgodnie z moją wiedzą tak nie jest. Czekam na obliczenia "back-of-the-envelope" wskazujące że to ma w ogóle szanse działać.

Mówił o tym Panoptykon w kontekście prywatności. Tam też odeślę do podcastów i do tekstu. System scentralizowany nigdy nie da pełnej anonimowości, choćby w zakresie kto korzysta z aplikacji - czy w wątku ProteGO-Safe, nie Ty o tym mówiłeś w kontekście IP?

Nie. Mówiłem że rozwiązanie w którym dane o kontaktach ludzi przechowywane na centralnym serwerze są złe, nie że (tak jak ty sugerujesz) "każde w pełni zdecentralizowane rozwiązanie jest lepsze niż każde zcentralizowane". Nigdy tego nie mówiłem ani Panoptykon też nie - zawsze było to w kontekście "tego konkretnego scentralizowanego" lub "tego konkretnego zdecentralizowanego" rozwiązania.

Ile możemy mieć dziennie nowych wiadomości od Health Authority? Patrząc na Włochy nie jest to więcej niż 10 tys. w zakresie całego kraju. Czy rozesłanie tylu ID (razy 96) zje aż tak dużą część baterii? Pytam dlatego - bo usłyszawszy prawidłową wiadomość typu 02 można by powtórzyć ją pierwszy raz minutę lub pół po usłyszeniu. To jej dostarczenie na odległość 30 km znacznie by przyspieszyło.

Bardzo proszę. 10 tys. Id * 32 Bajty = 320 KB danych. W przypadku technologii BT można zrobić 2 rzeczy a) wysyłać te dane w "advertisment id" po 32 Bajty na raz, albo nawiązać połączenie z drugim urządzeniem, otworzyć kanał i przesyłać te dane w strumieniu - to drugie wymaga interakcji i potwierdzenia za każdym razem więc odpada, bo za każdym razem użytkownik musiałby potwierdzić połączenie z innym telefonem, Przesyłanie 10.000 advertisment ids (różnych) i połączenie ich w całość to bardzo skomplikowany protokół który musi opierać się na tym że są interferencje między telefonami nadającymi w tym samym czasie, więc taki advertisment ID musi być nadawany odpowiendnio długo, co spowalnia cały protokół. Przykro mi, ale dopóki ktoś, kto jest ekspertem w dziedzinie transmisji Bluetooth, nie opisze tego jak to chcesz zrobić - z tego co ja widzę, to jest niestety oparta na błędnych założeniach teoria,

SeraMoon commented 4 years ago

Chętnie poznam od Ciebie wiarygodne wyliczenia bazujące na rzetelnych podstawach w tym temacie, bo na razie prezentujesz pogląd że informacja za pomocą BT rozpowszechnia się natychmiast, a zgodnie z moją wiedzą tak nie jest.

Nic nie propaguje się z nieograniczoną prędkością. Przesyłałam przez BT pliki i nie miałam problemu z przesłaniem pliku 1 magabajtowego. Prosiłabym o źródła, które mówią, że kolejny "hop" można wykonać po 5 minutach. Chcę wiedzieć skąd się wzięło 300 sekund tutaj.

każde w pełni zdecentralizowane rozwiązanie jest lepsze niż każde zcentralizowane

Nie twierdzę, że kaźde, bo nie będzie dobre gdy będzie przekazywany numer telefonu, imię, nazwisko itp. Chodzi mi o to, że każde scentralizowane rozwiązanie wymaga aby wraz z anonimowym ID poszedł nieanonimowy IP (o ile nie leci to przez Tora czy I2P - serwer centralny wtedy wie kto używa aplikacji). Przy decentralizacji - nikt nie wie od kogo te dane dostał a w szczególności w przedstawionym rozwiązaniu - kogo dotyczą (brak nawet jawnego ID). Brak też informacji kto pytał o te dane, bo nikt nie pyta a jedynie słucha.

back-of-the-envelope

Jak na razie - gdy aplikacje usypiają będzie to 0. Dla nieusypiających aplikacji postaram się w czasie najbliższym to policzyć - zakładając transmisję BLE, która nie wymaga potwierdzania, jednak będę musiała przeczytać trochę literatury jakie ma ograniczenia Android. Niestety tych obliczeń w tym momencie dokonać nie mogę.

Ale co całości zadam pytanie - jak obecnie rozgłaszany był / jest sygnał w różnych rozwiązaniach jako "advertisement" swojej obecności? Co ile on jest wysyłany?

Przyznam, że ograniczenie 32 bajty tutaj może być problematyczne. @potiuk czy te 32 bajty dotyczą samej wiadomości już sformatowanej wysyłanej przez smartfony, czy te 32 bajty są ilością danych, jaką można zapakować do jednej "ramki"?

potiuk commented 4 years ago

Nic nie propaguje się z nieograniczoną prędkością. Przesyłałam przez BT pliki i nie miałam problemu z przesłaniem pliku 1 magabajtowego. Prosiłabym o źródła, które mówią, że kolejny "hop" można wykonać po 5 minutach. Chcę wiedzieć skąd się wzięło 300 sekund tutaj.

Żródło: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf

Ja też przesyłałem pliki po BT. Pytanie o a) konieczność nawiązania potwierdzenia, b) zestawienie kanału strumienia c) czas wysłania d) wpływ na to że ma to być "broadcast" a nie "peer-rto-peer", To o czym piszesz zakłada, że jedna osoba wysyła na raz informację do wielu odbiorców. w protokole "peer-to-peer" dwa urządzenia komunikują się tylko między sobą. To są zupełnie inaczej działąjące protokoły.

każde w pełni zdecentralizowane rozwiązanie jest lepsze niż każde zcentralizowane

Nie twierdzę, że kaźde, bo nie będzie dobre gdy będzie przekazywany numer telefonu, imię, nazwisko itp. Chodzi mi o to, że każde scentralizowane rozwiązanie wymaga aby wraz z anonimowym ID poszedł nieanonimowy IP (o ile nie leci to przez Tora czy I2P - serwer centralny wtedy wie kto używa aplikacji). Przy decentralizacji - nikt nie wie od kogo te dane dostał a w szczególności w przedstawionym rozwiązaniu - kogo dotyczą (brak nawet jawnego ID). Brak też informacji kto pytał o te dane, bo nikt nie pyta a jedynie słucha.

Zawsze pytanie jest - co to IP daje stronie "centralnej" w tym wypadku. Wedug mnie nic. Jako inżynier zawsze zadaję sobie pytanie ("po co to robię", "czy to ma sens", "co jeśli nie") - to o czym piszes zpo pierwsze nie jest prawdą (bo jeśli serwer rządowy ma coś podpisać swoim kluczem prywatnym i tak zna IP, więc już w samym podpisie mógłby taką informację zakodować). po drugie nie ma powodu dla którego te akurat dane miały by być jakoś specjalnie zabezpieczane - bo i tak za chwilę będą publiczne. Nie można przyjmować pewnych "dogmatów" bez kontkestu - wtedy staje się to "religią" a nie "nauką".

Jak na razie - gdy aplikacje usypiają będzie to 0. Dla nieusypiających aplikacji postaram się w czasie najbliższym to policzyć - zakładając transmisję BLE, która nie wymaga potwierdzania, jednak będę musiała przeczytać trochę literatury jakie ma ograniczenia Android. Niestety tych obliczeń w tym momencie dokonać nie mogę.

To nie kwestie Androida, tylko protokołu Bluetooth. Polecam zapoznanie się. Nawet jak aplikacja nie śpi, to narzut na propagację nie jest zerowy - jest dużo więjszy

Ale co całości zadam pytanie - jak obecnie rozgłaszany był / jest sygnał w różnych rozwiązaniach jako "advertisement" swojej obecności? Co ile on jest wysyłany?

https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf

Przyznam, że ograniczenie 32 bajty tutaj może być problematyczne. @potiuk czy te 32 bajty dotyczą samej wiadomości już sformatowanej wysyłanej przez smartfony, czy te 32 bajty są ilością danych, jaką można zapakować do jednej "ramki"?

To jest kwestia użycia "Bluetooth Advertising" opisanego np. tu: https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/02/10/bluetooth_advertisin-hGsf - to protokół w którym wszystkim dookoła rozgłaszasz jakąś "krótką" informację. Na tym polegają wszystkie praktycznie rozwiązania "contact tracing". To działą m.in. w taki sposób że co 250 - 300 ms nadajesz to samo, w nadziei, że ktoś to usłyszy (ale jeśli ktoś w tym czasie będzie nadawał swoje, to Cię może zagłuszyć). M.in dlatego jest to 5 minut (bo statystycznie w tym czasie choć raz usłyszysz, to co wszyscy nadają). W Twoim rozwiązaniu musiałabyś - zamiast wysyłania wszystkim krótkiej informacji, musiałabyś z każdym oddzielnie nawiązać połączenie i wysłać więcej danych niż tylko 32 bajty). To jest ok jak masz się skomunikować z 1 telefonem, ale żeby robić "broadcast" musisz z każdym telefonem nawiązać oddzielne połączenie i do każdego wysłać wszystkie dane. Jeden po drugim, bo nie da się takiej informacji wysłać do "wszytstkich naraz". to niemożliwe bo jak wysyłasz dane, to odbiorca co jakiś czas musi potwierdzić, że tą "porcję" danych już odebrał. Dlatego właśnie możesz wysłąć 1MB plik do jednej osoby, ale wysłanie do 10 osób będzie wymagało 10x więcej czasu.

SeraMoon commented 4 years ago

Ja też przesyłałem pliki po BT. Pytanie o a) konieczność nawiązania potwierdzenia, b) zestawienie kanału strumienia c) czas wysłania d) wpływ na to że ma to być "broadcast" a nie "peer-rto-peer", To o czym piszesz zakłada, że jedna osoba wysyła na raz informację do wielu odbiorców. w protokole "peer-to-peer" dwa urządzenia komunikują się tylko między sobą. To są zupełnie inaczej działąjące protokoły.

Zdecydowanie chodzi mi o tryb BLE bez nawiązywania kanału. Z nawiązywaniem (i prośbami o potwierdzenie) zwyczajnie nie ma to sensu. I tak mówię o wysyłaniu tego jako broadcast.

Widzę, że latency dla BLE wynosi 6 ms zaś szybkość transmisji 0.27-1.3 Mb/s. Będę musiała więc wziąć to pod uwagę podczas wyliczeń - wyliczając czas co jaki można to ponownie nadawać i jaka będzie kolizja.

Czy można założyć tutaj, że urządzenie z BLE w zakresie nasłuchiwania - słucha cały czas?

W Twoim rozwiązaniu musiałabyś - zamiast wysyłania wszystkim krótkiej informacji,

W moim rozwiązaniu miałam też na myśli broadcast. Wysyłanie zarówno rozgłoszenia swojej obecności jako broadcast, jak też informacje od Health Autority miałyby trafiać w BLE w broadcascie. Muszę jednak przeliczyć czy w 32 bajtach zmieści mi się nagłówek, informacje o ramce, podpis cyfrowy, czyjś identyfikator, informacje o ryzyku i chorobie.

Tak więc pojedyncze pakiety miały być na prawdę pojedynczymi a nie złożoną transmisją.

potiuk commented 4 years ago

Tu chodzi o coś więcej. To 0.27 - 1.3 Mb/s to jest właśnie dla transmisji kiedy dwie (dokładnie dwie) strony się połączyły i ustaliły protokół w którym odebrane dane są potwierdzane.

Advertisment jest wysyłaniem tej samej informacji wielokrotnie w eter, bez sprawdzenia czy dotarła. W komunikacji bezprzewodowej (w przewodowej z resztą też) - trzeba uwzględnić to, że są interferencje i równolegle (w Bluetooth dostępne są tylko 3 różne kanały) nadające urządzenia nie "zakrzykują" się nawzajem.

Nie da się wedug mnie - po BT robić broadcastu dużej ilości danych - bo (jak w każdym protokole) - każda wysłana ramka musi być potwierdzona przez odbiorcę (w tym wypadku - przez wszystkich odbiorców, których trzeba zidentyfikować i potwierdzić). Badzo podobnie działa WiFi i Ethernet - tylko tam jest dużo większe pasmo. Tak działa na przykład protokół TCP - w którym potwierdzaa jest transmisja między dwoma węzłami sieci) - tam odbiór każdego pakietu jest potwierdzony przez informację zwrotną.

"Broadcast" działa podobnie jak UDP - gdzie wysyłasz informację w eter ale nie masz żadnej gwarancji że ona trafi do wszystkich odbiorców. I jak jest duży ruch, to dużo pakietów UDP jest gubionych. I żeby wysłać listę TempID do wszystkich trzeba przy każdym pakiecie czekać na odpowiedż od wszystkich odbiorców (!)

SeraMoon commented 4 years ago

Po co robić potwierdzenie po każdym broadcascie? Miałam na myśli nadanie broadcastu (fakt, może trzeba nadać go kilkukrotnie) i potem ci którzy ten broadcast usłyszą - nic nie potwierdzają a jedynie zapisują co usłyszeli celem ponownego nadania po minięciu określonego czasu (bez potwierdzeń) i tak w kółko, jeżeli dane urządzenie nie nadawało tego komunikatu do tej pory (zablokowanie cyklicznego nadawania między 2 czy 3 urządzeniami co doprowadzi do zagłuszenia).

I żeby wysłać listę TempID do wszystkich trzeba przy każdym pakiecie czekać na odpowiedż od wszystkich odbiorców (!)

No właśnie nie. Po to nadawałabym to 96 razy (w ciągu doby) aby była duża pewność (bez potwierdzeń), że cel to otrzyma. Fakt, że będzie to nie 1 broadcast a pewnie seria broadcastów przez każde okno 15 minutowe (bez potwierdzeń). Częstość i ilość powtórzeń w ciągu jednego okna 15-minutowego - do ustalenia, tak aby zminimalizować wpływ interferencji, dostępnych kanałów oraz możliwego zagłuszenia (urządzenie musiałoby słuchać czy jest w miarę cicho przed tym gdy chce ponowić każde ponowne nadanie).

Skąd jest przeświadczenie, że chcąć coś rozpropagować przez dużą ilość repeaterów (w Polsce liczmy 10 milionów) muszę mieć potwierdzenia dostarczenia? O potwierdzeniu (opcjonalnym) można jedynie myśleć - z ostatniego węzła, choć nie wiem czy to ma sens (zwiększy ruch dwukrotnie).

Jeżeli poinformowanie miałoby być "gwarantowane" możnaby opcjonalnie przewidzieć odpowiedzi gwarantujące, że usłyszał przynajmniej jeden inny telefon (nie wszyscy - zakładamy dobre intencje tego telefonu, że powtórzy to innym w postaci broadcastu) - a to wiemy stąd, że jeżeli urządzenie A wyśle broadcast do urządzenia B, C i D z intencją jego powtórzenia - może nasłuchiwać czy rzeczywiście doszło do powtórzenia tego sygnału raz albo 2 razy (ma więc potwierdzenie - w postaci kopii tego co wysłał usłyszanej w eterze).

potiuk commented 4 years ago

Proszę o konkrety - nadawanie 100 razy tego samego co 200 ms (= 20 s na jedno ID) nie pozwala ci nadać więcej niż 24*3600/20 ~ 4000 Temp ID na dobe - maks.. Prosze - policz to sobie a zobaczysz, ze BT i decentralizacja nie ma w tym wypadku sensu.

potiuk commented 4 years ago

Pomijam, ze nie rozwiazuje zadnego problemu poza hipotetycznym brakiem dostepu do internetu, ale tu tez czekamy na liczby i zrodla wskazujace ze to jest w ogole problem

SeraMoon commented 4 years ago

Dlaczego mam nadawać 100x to samo co 200 ms? Dlaczego tak dużo? Opcją jest nadanie tego 2-3 razy, posłuchanie, czy ktoś to rozpropagował dalej i zatrzymanie tej "kolejki nadawczej". Jeżeli w sieci pojawi się wiele różnych wiadomości od Health Authority - każda byłaby powtarzana 2-3 razy, potem czekanie, czy ktoś powtórzył daną wiadomośc i usunięcie jej z kolejki "do nadania" i przesunięcie do "nadano". Jeżeli nie słychać "echa" - po około minucie (losowe) nadaję ponownie. Czy to nie rozwiąże tego problemu?

ale tu tez czekamy na liczby i zrodla wskazujace ze to jest w ogole problem

Liczba mnoga - kto oprócz Ciebie czeka? Skąd wziąć informacje i kto je zbiera - ile osób nie miało internetu w komórce lub miało przerwy w czasie epidemii?

potiuk commented 4 years ago

To ty pisałaś o 96 rozgłoszeniach. czekanie na powtórzenie to właśnie "potwierdzenie odbioru" o którym pisałem powyżej. Policz to wszystko sama. Ale najlepiej z kimś kto to potwierdzi i ma szeroką wiedzę na temat komunikacii Bluetooth..

Liczba mnoga - kto oprócz Ciebie czeka?

Nie wiem, kto słucha. Dyskusja jest publiczna, Ja czekam na pewno.

Generalnie - jak będa konkretne dane, to podejmuję ten wątek, Jeśli nie - już wszystko na ten temat powiedziałem.

Według mojej wiedzy - to ani nie rozwiązuje żadnych problemów (poza nie potwierdzonym dogmatem decenteralizację), ani nie ma szansy działać (ze względu na problemy techniczne).

Ja już się dośc wypowiadałem - mam nadzieję że w dyskusję włączą się inni eksperci który znają się na tym lepiej ode mnie. Dobranoc.

SeraMoon commented 4 years ago

To ty pisałaś o 96 rozgłoszeniach.

Miały być wykonywane rozgłoszenia co 15-30 aby zapewnić że usłyszy to więcej urządzeń w okolicy (można by decydować po ilości ech które wrócą, czy trzeba aż tyle aby zapewnić, że cel prawie na pewno dowie się o "zakażeniu"). Opcjonalną powtórkę (dodatkową) można by przemyśleć po ustaleniu za pomocą GPS (koordynaty nie byłyby wysyłane) - że nastąpiło przemieszczenie o 4 kilometry (aby wyeliminować przypadek, że przy braku pokrycia całej doby, sygnał nie przejdzie przez Wisłę).

Policz to wszystko sama.

Owszem, policzę w wolnym czasie - mam inny projekt na głowie a chciałabym to policzyć uwzględniając gęstośc zaludnienia (czyli ilość urządzeń które mogą utrudnić komunikację) i policzyć co ważne nie o tej godzinie.

Ale najlepiej z kimś kto to potwierdzi i ma szeroką wiedzę na temat komunikacii Bluetooth..

Sama też prosiłabym o specyfikacje (szczegółowe) dotyczące tego tematu. Czyli czy Bluetooth ma ciągle nasłuch, realna możliwość powtarzania komunikatu (czasy itp). Bardziej się orientuję w kwestiach radiowych niż konkretnie BT. Więc pomocna byłaby tego typu literatura by policzyć to wszystko.

Ja czekam na pewno.

Niestety zmartwię Cię, ale nie wiem skąd można wziąć dane ile userów nie mogło się połączyć z internetem. Jednak gdyby udało się zrobić to co planuję - w tym rozwiązaniu internet mógłby być zbędny lub technologia tu opisana mogłaby służyć tym, którzy go nie mają w danej chwili. Przypomnę o licznych skargach od ludzi, którzy używali VPN - problem ten może się powtórzyć u nich z rozwiązaniem G+A.

Generalnie - jak będa konkretne dane, to podejmuję ten wątek, Jeśli nie - już wszystko na ten temat powiedziałem.

Wyspecyfikuj więc konkretnie jakie dane chcesz oprócz obliczeń na odwrocie koperty - dla ilu zgłoszeń infekcji dziennie jest to wykonalne.

ani nie ma szansy działać (ze względu na problemy techniczne

To postaram się obliczyć.

Ja już się dośc wypowiadałem - mam nadzieję że w dyskusję włączą się inni eksperci który znają się na tym lepiej ode mnie. Dobranoc.

Liczę na to, że włączą się inni też do dyskusji.

potiuk commented 4 years ago

Czekam zatem na obliczenia - z uwzględnieniem wiarygodnych źródeł:

Specyfikacja BT 4.0 ( o tej wersji mówimy ) jest tu: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

kwiszowaty commented 4 years ago

Idea bardzo ciekawa, ale chyba nie do końca przemyślana. Czytając komentarze i wyjaśnienia myślę, że @SeraMoon podjęłaś przynajmniej 2 błędne założenia:

  1. To, że coś rozgłosisz nie znaczy, że ktoś to usłyszy/odbierze. Tak jak pisał @potiuk , algorytm G+A jest optymalny ze względu na użycie baterii, dyskutowaliśmy o tym w #134. Założenie, że coś rozgłosisz 2-3 razy jest zupełnie nie na miejscu i nie zda egzaminu. Nawet 100x o których pisał @potiuk to za mało. Nasłuch, w pesymistycznym przypadku (a taki trzeba przyjąć), będzie co 5 minut (przez krótką chwilę), więc może się zdarzyć, że nawet jak będziesz to powtarzać to nie trafisz w czas gdy ktoś słucha. Żeby można było słuchać cały czas, to dużo fajniejsze rzeczy można by robić ;-)

  2. Odnośnie HealthAuthority opisujesz:

Health Authority po uzyskaniu informacji o dodatnim teście pobiera (przez BlueTooth po zgodzie użytkownika) identyfikatory 15-minutowe osób widzianych w ciągu 14-21 ostatnich dni.

Co samo w sobie tworzy serwer scentralizowany, którego chcesz uniknąć. Do tego przekazujesz nie TYLKO SWÓJ KLUCZ, ale klucze osób które spotkałaś. Czyli od razu HA widzi kontakty ludzi o które tak walczyliśmy by ich nie było. Co do "de-centralności" rozwiązania, dla mnie to jest identyczne z podejściem G+A, bo jest miejsce gdzie mamy te kontakty (przy czym w G+A mamy tam o wiele mniej informacji) i niem jest HA.

SeraMoon commented 4 years ago

Nawet 100x o których pisał @potiuk to za mało. Nasłuch, w pesymistycznym przypadku (a taki trzeba przyjąć), będzie co 5 minut (przez krótką chwilę), więc może się zdarzyć, że nawet jak będziesz to powtarzać to nie trafisz w czas gdy ktoś słucha. Żeby można było słuchać cały czas, to dużo fajniejsze rzeczy można by robić ;-)

@kwiszowaty możesz mi wyjaśnić o co chodzi ze słuchaniem raz na 5 minut? Czy to oznacza, że systemy operacyjne z właczonym BT-BLE mają otwarte okno do nasłuchiwania transmisji co około 5 minut? Skąd bierze się te 5 minut? Czy może te 5 minut wynika z zaspamowania pasma BT (nie mam jak tego sprawdzić na tę chwilę)?

Co samo w sobie tworzy serwer scentralizowany, którego chcesz uniknąć. Do tego przekazujesz nie TYLKO SWÓJ KLUCZ, ale klucze osób które spotkałaś. Czyli od razu HA widzi kontakty ludzi o które tak walczyliśmy by ich nie było.

Tyle, że widzi ich identyfikatory losowe zmienne co 15 minut. Aby dojść czyj był to klucz trzeba by uzyskać dostęp fizyczny do twojego telefonu i sprawdzić czy to twój czasowy identyfikator lub kto go zasłyszał i puścić detektywa za tymi osobami. Sądzę, że zbyt duży nakład pieniężny na taką deanonimizację. Ponieważ nie ma IP w komunikacji BT i nikt nie dostaje odpowiednika IP w BLE - nie byłoby wiadomo, czy korzystasz z aplikacji. W rozwiązaniu G+A nadal da się określić czy ktoś korzysta z aplikacji lub protokołu i przy nakazie obligatoryjnej instalachi lub włączenia zawartego w "złej ustawie" możliwe będzie ściganie tych osób, które nie używają aplikacji - a skąd wiadomo że nie używają - bo nie było żądania do serwera EN z ich telefonu (IP). Przed tym też miało to rozwiązanie (opisane tu) z broadcastami BT chronić. Chodzi o uniemożliwienie władzy naruszenia prywatności w jakikolwiek łatwy sposób. Gdy będzie to mocno utrudnione - nie będą myśleli o takich ustawach.

To, że coś rozgłosisz nie znaczy, że ktoś to usłyszy/odbierze.

Stąd czekam aż ktokolwiek to powtórzy i to dotrze do mojego urządzenia. Wtedy wiem czy ktokolwiek to odebrał.

kwiszowaty commented 4 years ago

@SeraMoon

@kwiszowaty możesz mi wyjaśnić o co chodzi ze słuchaniem raz na 5 minut? Czy to oznacza, że systemy operacyjne z właczonym BT-BLE mają otwarte okno do nasłuchiwania transmisji co około 5 minut? Skąd bierze się te 5 minut? Czy może te 5 minut wynika z zaspamowania pasma BT (nie mam jak tego sprawdzić na tę chwilę)?

Bierze się to ze specyfikacji algorytmu G+A, który został zaprojektowany tak by oszczędzać baterie. Czyli rozgłasza non-stop, nasłuchuje co 5 minut (i/lub oportunistycznie). Cytat z spec:

The scanning interval and window shall have sufficient coverage to discover nearby Exposure Notification Service advertisements within 5 minutes. The scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 minutes

Przez to cały pomysł pada...

SeraMoon commented 4 years ago

Bierze się to ze specyfikacji algorytmu G+A, który został zaprojektowany tak by oszczędzać baterie. Czyli rozgłasza non-stop, nasłuchuje co 5 minut (i/lub oportunistycznie). Cytat z spec:

@kwiszowaty Ale przecież to miało działać niezależnie od G+A. Czy są inne czynniki, z których to wynika? Chodzi mi o czysty BT-BLE na przykład zainstalowany na Windowsie lub Linuxie w postaci oddzielnego dongla? Jak wygląda nasłuchiwanie na BLE na Androidzie w zwykłym trybie BLE nie mającym nic wspólnego z "G+A"? Moje rozwiązanie tu opisywane nie ma nic współnego z G+A oraz EN.

kwiszowaty commented 4 years ago

@SeraMoon w swojej aplikacji możesz zrobić co zechcesz, nie ma ograniczeń. Alle wiąże się to z ogromnym zużyciem baterii i nikt takiej aplikacji nie zainstaluje (koledze w testach baterii starczało średnio na 2-3h). Jak słuchasz, to musisz odbierać i analizować, a to wymaga procesora i wybudzania telefonu - dlatego jest to tak "ciężkie" w porównaniu z samym nadawaniem, które idzie prosto z chipa BT.

SeraMoon commented 4 years ago

@kwiszowaty dzięki za wyjaśnienie. Nie sądziłam, że smartfon nie ma trybów LPM2 lub LPM3, gdzie tylko część aplikacji by się odpalała (tych, które coś od BT chcą) i z wybudzeniem tylko części urządzeń. Przykra wiadomość, że aby działać w tle, musi wybudzać siebie i wszystkie inne aplikacje... pewnie tu jest problem, bo sam BT na nasłuchu przecież nie powinien dużo pobierać energii.

Zakładając nawet baterię 1000mAh, działając 2-3h to te smartfony żrą 300-500mA - nawet gdy chcą odebrać pakiet i go przeanalizować (a jak podejrzewam - większość to i tak cisza w eterze). Niezbyt przemyślana technologia. Faktycznie przy takim rozwiązaniu technologicznym to na smartfonie nie ma to sensu.

W tym co piszesz to, jak pisał Panoptykon - faktycznie to rozwiązanie G+A też jest wątpliwe w skuteczności, skoro jest tylko cień szansy, że w 5 minut usłyszy identyfikator i nie wiadomo czy bliska rozmowa trwała minutę czy 9 minut. Super technologia G+A / Exposure Notification...