Zaprzestanie działania aplikacji po okresie pandemii - funkcja "Kill Switch" #226
Comments
|
Ja mam spore zastrzeżenia do samej koncepcji tego co chcecie zrobić bo według mnie chyba źle zrozumieliście te zalecenia. Popraw mnie jeśli się mylę (i podaj odpowiednie cytaty) ale z tego co ja czytam to w tych zaleceniach nie ma mowy o tym żeby pokazywać komunikaty że kryzys minął. Komunikaty o których mowa mają jedenie namwiać użytkownika do usunięcia aplikacji, ale tylko w sytuacji jeśli nie można aplikacji usunąć z telefonu lub wyłaczyć automatycznie. Z tego co widzę to oczekiwanym działaniem jest właśnie wyłączenie lub usunięcie aplikacji. Żeby nie być gołosłownym, tu odpowiedni cytat z dokumentu który podlinkowałeś: "Apps should be disabled once the pandemic has passed. If it is not possible to Zarówno Google, jak i Apple mają możliwość zdalnego usunięcia aplikacji. Mówimy tu o telefonach które mają sklep Play (bo muszą być Play Services) i telefonach Apple, które sa kotrolowane przez AppStore. Wydaje się - skoro już jesteście w bliskim kontakcie z Apple i Gogle - że najpewniejszą metodą jest porozumienie się z Google i Apple że aplikację usuną jak będzie włączony Kill Switch. Przy okazji oni właśnie zdalnie mogą usunąć dane EN w ten sam sposób (a nawet jeśli nie to dane same się usuną po 14 dniach). Ze strony Ministerstwa/serwerów, to jest tylko kwestia wyłączenia serwerów natychmiast jak będzie Kill Switch (zarówno do wysyłania i pobierania danych) i upewnienia się że aplikacja to obsługuje (w sensie że nie raportuje niepotrzebnych błędów). Najprościej jest sprawić żeby serwery zwracały odpowiedź HTTP 410 "Gone" - które jest przewidziane na takie sytuacji. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410. W ten sposób osiągacie natychmiastowość wyłączenia zbierania danych - a po paru godzinach/dniach aplikacja zostanie usunięta przez mechanizmy Play/Appstore (razem z danymi i historią). Według mnie to najpewniejszy i najprostszy (a jednocześnie najtańszy dla podatników) sposób na implementację KillSwitch-a. Skoro już teraz polegacie na G+A jeśli chodzi o włączenie EN to podobnie należy zrobić do wyłączenia. |
|
Może rzeczywiście nie precyzyjnie się wyraziłem co do informacji że kryzys minął, chodzi po prostu o wyświetlenie informacji (do opracowania), że aplikacja już nie działa z takich i takich przyczyn podjętych przez taki i taki podmiot. Jaki to będzie komunikat nie wiem, ale chodzi o to żeby użytkownikowi nie wyświetlał się sam błąd ale i jakieś wyjaśnienie. Usunięcie aplikacji przez Google i Apple być może jest jakimś rozwiązaniem, ale też byłoby to dla użytkownika trochę niezrozumiałe że nagle aplikacja zniknęła z jego telefonu, nie wiem czy to jest najlepsze wyjście. |
Bardzo prosto -> 410 GONE z serwera i można wyświetlić komunikat namawiający do odinstalowania aplikacji. Odpowiedź "410 Gone" jest wyrażnym sygnałem (zgodnie ze specyfikacja 410) że nie ma już serwera i nie będzie.
To można wyświetlić ten komunikat jak wyżej (po 410 GONE) a usunięcie w Google i Apple ustawić na "pojutrze". Aplikacja przynajmniej raz dziennie pobiera dane i może wyświetlić komunikat w takiej sytuacji.
Tak jak piszę wyżej "410 GONE" nie powinien powodować błędu tylko komunikat "odinstaluj aplikację". To właśnie o takim komunikacie mówią zalecenia.
Gdzie? Czy mógłbyś proszę zacytować ten fragment, bo przyznam nie udało mi się znaleźć stwierdzenia że ma to być "wewnątrrz aplikacji". O którym fragmencie tych zaleceń mówisz?
Po uprzednim komunikacie wyświetlonym po "410 Gone" nie będzie to zaskoczeniem. Z resztą zakładam że będzie wcześniejsza informacja - tak jak ostatnio w TV "zainstaluj aplikację" tak będzie "już nie trzeba aplikacji". Poza tym - o ile się nie mylę Google i Apple mogą wyświetlić komunkat informujący o tym dlaczego aplikacja została usunięta. Myślę że warto to z nimi sprawdzić, bo było by to bardzo dobre rozwiązanie. Google ma to rozwiązanie już od 2011 roku https://www.scmagazine.com/home/security-news/google-remotely-killing-android-malware/ (nawet w tym artykule jest on nazwane kill-switch), Apple jeszcze wcześniej, więc zakładam, że mają to nieźle dopracowane, łącznie z komunikatami.
W zaleceniach które napisałeś jest wyraźnie mowa o "wyłączeniu lub odinstalowaniu aplikacji". Czy jest gdzieś napisane że jest coś innego ? Ponawiam cytat:
Ja bym was jednak zachęcał do trrzymania się zaleceń na które sami się powołujecie - bo wydaje mi się że trochę twórczo je interpretujecie. Nie trzymając się zaleceń, narażacie się na kolejną falę hejtu i ciąg dalszy podważania zaufania. |
|
W obecnym stanie rzeczy, każdy kto ma aplikację musi mieć smartfona, a więc telefon. Wystarczy ALERT RCB z instrukcją żeby:
Nie widzę więc potrzeby robienia dodatkowej funkcji, a Firebase jest do usunięcia jak wskazano w #215. Kod Exposure Notification [podobno] dostaliśmy (nie zapoznawałam się jeszcze z kodem). Jak i jakie dane pozyskuje Google innymi drogami jest nieznane, popieram więc usunięcie zarówno Firebase jak i SafetyNet. Czy to rozwiązuje problem? Moim zdaniem tak, skoro można było wszystkim wysłać alert RCB informujący, że elektorat pewnej partii (500+, 60+) ma dodatkowe przywileje wejścia na głosowanie w pierwszej kolejności, to tym bardziej uzasadnione jest wysłania alertu, gdy epidemia się skończy, wraz z wyłączeniem serwera do przesyłania TEKs. BTW. Czy nie powinno być funkcji w serwerze z aktualnymi TEKs, że wysłanie do Exposure Notification konkretnego komunikatu (np. błędu HTTP 599) po prostu sam wyłączy Exposure Notification? IMO implementacja "Kill switch" powinna leżeć po stronie G+A. |
|
Taki kill switch realizowany przez serwer sam w sobie jest zagrożeniem bezpieczeństwa. Np. stosując atak MITM można komuś dezaktywować aplikację. Klucze dzienne ściągane z serwera są dodatkowo zabezpieczone w tym celu podpisem kluczem ProteGo Safe, jeżeli już to ten komunikat pewnie też powinien być nim podpisany. |
|
Zdaje się że aplikacja ma zapinowane certyfikaty https - to powinno wystarczyć. |
Oczywiście, że wewnątrz takiego pakietu 599 powinna pójść wiadomośc podpisana cyfrowo, aby nie doszło do wspomnianego ataku.
Na to jest proste i tanie wspomniane rozwiązanie - alert RCB. Nawet gdy ktoś będzie miał niedoładowany telefon, ale wciąż aktywny (czyli nie wyłączą mu SIM karty) - wiadomość dostanie. Inne wymienione rozwiązania mu tego nie zapewniają, gdy nie ma środków na koncie. Poza tym:
|
Paczki pobierane są z CDNa, to nie serwer HTTP na którym możemy sobie dowolną odpowiedź zwrócić, ale jeszcze skonsultuję to z teamem backendowym. Plus tak jak wspominałem pobieranie jest realizowane w tle, niezależnie od tego czy aplikacja jest na froncie czy nie, to by wymagało dodatkowej komunikacji pomiędzy tymi warstwami lub raczej "zapisywania" lokalnie przy ostatnim pobieraniu takiej informacji i przy odpalaniu aplikacji sprawdzaniu tej zapisanej informacji. Ewentualnie dodatkowo należałoby pokazać notyfikację.
"Pojutrze" jest względne. Dla osób które wejdą do aplikacji i zobaczą komunikat "dziś" tak, ale co jeśli ktoś nie zagląda do aplikacji (bo i po co skoro nie dostał żadnej notyfikacji o zagrożeniu) lub zagląda rzadko, jemu aplikacja zniknie pojutrze i nadal nie będzie wiedział dlaczego.
Jak wyżej, sprawdzę ale nie sądzę żeby było bezpieczne bazowanie na HTTP kodach dla CDN, kod dla nieistniejącego CDNa (pewnie 404) może pojawić się również przy tymczasowych problemach z nim, problemach sieciowych.
Sprawdzimy opcję "odinstalowania" przez Google i Apple i takiego komunikatu wyświetlanego przez nich. Co do tego czy będzie publiczna kampania "odinstaluj" aplikację, komunikaty RCB i inne zewnętrzne rozwiązania się nie wypowiadam, to jest poza naszym zakresem odpowiedzialności. Poza tym uważam to za rozwiązanie potencjalnie dodatkowe, niegwarantujące dotarcia do wszystkich użytkowników, niegwarantujące odinstalowania lub wyłączenia funkcjonalności. |
|
Kilka razy było wspomniane o RCB - tylko czy ten kanał nadaje się do takich komunikatów? One mają być wysyłane tylko do osób na konkretnym obszarze w przypadku poważnego zagrożenia. Ostatnie spamy o wyborach były właśnie spamami - taka wiadomość nigdy nie powinna wyjść tym kanałem, łamie przyjęte założenia. |
A ile będzie kosztować implementacja każdej z tych opcji? Ja głosuję za przejściem w tryb najtańszego możliwego utrzymania. |
Nice nie stoi na przeszkodzie żeby zrobić to "dobrze" na długo pzed wyłączeniem. Każdy CDN ma możliwość ustawienia "wlasnego" adresu DNS. Więc pobierać możecie z adresu protegosage.mc.gov.pl który do momentu wyłączenia będzie wskazywał na CDN a w momencie wyłączenia systemu (wszak globalnego) przekieruje na serwer, który zawsze na wszystko będzie odpowiadał "410 Gone". To bardzo piękne rozwiązanie, natychmiastowo wyłączające wszystko.
No właśnie jeśli obsłużycie "410 Gone" to można to zrobić i za tydzień. Nikt nie musi zaglądać do aplikacj. Wystarczy że jak dostaniecie "410 Gone" wyświetllicie odpowiedni komunikat za pomocą "Push notification". Komunikat Push powinien być permanentny - bez możliwości usunięcia (namawiający do odinstalowania aplikacji). Jeśli ktoś nie pamięta o tym że ma aplikację, w ogóle się nie zdziwi że mu zniknie, a poza tym - jak pisałem, jest bardzo duża szansa że Google i Apple mogą wyświetlić taki komunikat. Więc nie strzępmy już języka na próżno na ten temat póki tego nie sprawdzicie.
Dlatego wyraźnie piszę o obsłudze tego jednego statusu "410 GONE". Nie 404. 404 trzeba obsłużyć inaczej. Żaden serwer czy CDN "przypadkiem" nie zwróci ci "410 GONE". Żadne problemy sieciowe (jeśli używacie SSL) nie spowodują przypadlowego zwrócenia 410, więc nie ma czego się obawiać. No i jak wytłumaczyłem powyżej - w ogóle nie trzeba do tego zaprzęgać CDN-a - wystarczy jednym ruchem przekierować ruch na serwer.
RCB - tu się zgadzam. Absolutnie nie można tego zrobić bo to jest po prostu niezgodne z prawem. Podobnie jak niezgodny z prawem był komunikat wysłany przy okazji wyborów. Na razie zdaje się nie wiadomo kto to zlecił, ale już parę osób wystąpiło o ujawnienie tej - wszak publicznej - informacji i mam nadzieję te osoby które to zleciły zostaną pociągnięte do odpowiedzialności - karnej i administracyjnej. @tomekziel -> w pełni się zgadzam. To rozwiązanie które zaproponowałem wygląda na zdecydowanie najtańsze. W świetle tego ze ta aplikacja i tak (według mnie) nie będzie potrzebna większości ludzi, nie inwestowałbym już w nią poza absolutne minimum. |
|
Ja co do Alertu RCB mam wciąż inne zdanie:
Jakie jest tańsze rozwiązanie i gwarantujące dotarcie do wszystkich? Odnośnie już kolejnych zarzutów łamania prawa: jaka ustawa i jakie rozporządzenie opisuje, co może być i kiedy wysyłane alertem RCB? Czy odwołanie epidemii nie może być nim wysłane, wraz z wytycznymi?
To już nie czekaj na tą publiczną informację, bowiem publicznie za Radio ZET:
Proponuję zająć się wersją web i zgłoszonymi tam błędami. Aplikacja wciąż po pierwszym żądaniu nie wyświetla informacji o ciastkach, jak też wciąż pyta o imię oraz wysyła żądania diagnosis na serwer wraz z udzielonymi odpowiedziami, o czym nie informuje polityka nieprywatności. Karę administracyjną to powinien dostać ten, kto taką aplikację utrzymuje online i zbiera dane osobowe medyczne wraz z IP bez odpowiednich informacji. Mam nadzieję, że ktoś tą karę wymierzy i ktoś napisze skargę do UODO i jasno tam wyrazi, że chodzi o stronę safesafe.app oraz że wnosi w interesie bezpieczeństwa publicznego o przeprowadzenie kontroli. |
|
A tu więcej na temat 'remote kill switch' Gdzie Google nawet wprost mowi o tym że mają taki mechanizm i że jest on w stanie usunac aplikacje 'rapidly' i 'in a scalable manner' https://android-developers.googleblog.com/2010/06/exercising-our-remote-application.html?m=1 I to już w 2010 roku. Według mnie nie skorzystanie z tej opcji jest po prostu narażaniem na niepotrzebne wydatki. Lepiej się dogadać z Google i Apple. Tu jeszcze swieżutki artykuł gdzie dyskutowane jest np. możliwe użycie killswitcha Google i Apple do odinstalowania TikToka w Stanach. W sytuacji kiedy Google, Apple i rządy współpracują i mają jasne wytyczne że te aplikacje powinno się usuwać jak pandemia się skonczy, nie wyobrażam sobie żeby Google i Apple miało coś przeciw użyciu killswitcha. @pkleczko - czy możemy liczyć na informacje co Google i Apple na taką propozycję mówią ? Chętnie się bym dowiedział też co sądzicie o mojej sugestii żeby przekierowywać DNS-y i reagować na 410 Gone wyświetleniem komunikatu. Dla mnie nadal kombinacja tych trzech rzeczy (przekierowanie + komunikat po praniu 410 Gone + usunięcie aplikacji za pomocą 'Google + Apple kilka switch' to zdecydowanie najtańszy i najprostszy sposób implementacji tej funkcjonalności. Jakieś za/przeciw ? |
|
tak @potiuk rozważamy Twoje propozycje jako opcje rozwiązania tej funkcjonalności. Chwilowo skupiliśmy się na innych pracach, ale w najbliższym czasie będziemy pracować również nad tym. Nie rozmawialiśmy jeszcze z Google i Apple o remote usunięciu aplikacji. |
|
Czy wiadomo już w jakim kierunku podjęliście działania i czy sprawdziliście, czy możecie wykorzystać mechanizmy Google i Apple? Nie przejrzałem jeszcze dokładnie raportu przygotowanego m.in. przez @PawelLitwinski (więcej na ten temat w #209) ale z tego co widziałem przeglądając go pobieżnie to jest to drugi największy brak o którym autorzy piszą:
Czy mógłbym prosić - już prawie miesiąc po tym jak był ostatni wpis - o informację o statusie, planach i o tym, co dowiedzieliście się od Google i Apple (ja w międzyczasie swoimi kanałami też sprawdzam czy jest taka możliwość) czy rozwiązanie, które zaproponowałem jest możliwe, i jakie podejmujecie działania w tym temacie. Jest okazja, żeby pokazać że faktycznie nie jest tak, że dopiero jak jest burza to Ministerstwo coś robi. Chciałbym uniknąć sytuacji podobnej jak w #209 w których wygląda jakby działania w tym zakresie są podejmowane tylko po kontrowersyjnych wpisach społeczności, które grożą zaognieniem sytuacji w social mediach - dlatego na razie nie robię jeszcze z tego żadnych afer a po prostu grzecznie, w imieniu społeczności pytam jaki jest status - zwłaszcza, że konstruktywnie zaproponowałem dobre (a przede wszystkim tanie dla podatnika) rozwiązanie które wymaga jedynie dogadania się z Apple i Google. Czekam na odpowiedż. @pawellipinski - mam nadzieję że to dobrze że domagam się działań o których w raporcie napisaliście że są "drugim najważniejszym obszarem". |
|
@potiuk niestety nie mogę pokazać Ci naszej korespondencji z Google i Apple, ale bardzo ogólnie mogę powiedzieć że dostaliśmy informację o tym, że wiedzą o problemie, ale aktualnie zdecydowali że zajmą się tym tematem po swojej stronie dopiero za kilka miesięcy (tak miesięcy) i dadzą znać jak podejmą jakieś decyzje i jaka jest ich rekomendacja. Póki co ze swojej strony na pewno mogą dzięki aktualizacji GPS/OS wymusić wyłączenie EN i usunięcie zapisanych kluczy, oczywiście nie jest to działanie natychmiastowe i nie rozwiązuje kwestii ewentualnych danych przechowywanych przez aplikacje korzystające z EN w lokalnym storage aplikacji. Z drugiej strony temat od kilku tygodni jest też konsultowany na poziomie europejskim, bo dotyczy rozwiązania wpisanego do Toolboxa kilka miesięcy temu, nad którym nikt się dokładnie nie zastanowił jakie niesie konsekwencje i czego w zasadzie się oczekuje w tym wymaganiu, co jest wystarczające a co pożądane. W okresie wakacyjnym takie konsultacje przedłużały się. Temat nie jest zamknięty, ale też nie pracujemy jeszcze nad jego implementacją, bo tak jak wyżej wspomniałem chcemy dobrze zrozumieć wymagania i możliwości. Stay tuned. |
|
Staying tuned. Mam nadzieję, że wspólnymi siłami uda się wprowadzić dobre (i tanie dla podatników) rozwiązanie problemu. Aktualizacje częstsze niż raz na miesiąc i transparentne informowanie o postępach były by w tym pmocne, żeby uniknąć sytuacji z #209 i podejrzeń o reakcje na kontrowersyjne wpisy. |
|
@potiuk od jakiegoś czasu staraliśmy w gronie zespół deweloperów/MC/MSZ (PermRep)/KPRM zainicjować międzynarodową (w ramach UE) dyskusję dot. wymogu SG-01 Toolboxa (Mobile applications to support contact tracing in the EU’s fight against COVID-19 - Common EU Toolbox for Member States link: https://ec.europa.eu/health/sites/health/files/ehealth/docs/covid-19_apps_en.pdf, czyli osławionego Kill Switcha. W tym samym czasie staraliśmy się ustalić jak inne Państwa Członkowskie UE, które rozwijają aplikacje contact tracingowe, podeszły do tego wymogu. Udało się zainteresować eHealth Network naszym problemem całkiem niedawno i zainicjować dyskusję w tym przedmiocie. Pierwsze rozmowy dot. wymogu SG-01 odbyły się 26 sierpnia 2020 roku (w zeszłym tygodniu). Miałem przyjemność na łamach eHealth Network przedstawić nasze (zespołu deweloperów/MC/KPRM) wątpliwości co do możliwości osiągnięcia pełnej zgodności z tym wymogiem. Dopiero podczas tego spotkania (poruszając ten problem) dowiedzieliśmy się, że Holendrzy doszli do bardzo podobnych wniosków jak my. Tym samym zyskaliśmy dość poważnego sojusznika w naszych staraniach o wyjaśnienie lub uszczegółowienie wymogu SG-01. Holendrzy opracowali następujący Termination Plan dla swojej aplikacji: https://github.com/minvws/nl-covid19-notification-app-coordination/blob/master/architecture/App%20Termination%20Plan.md Należy podkreślić, że podczas ubiegłotygodniowej dyskusji Holendrzy potwierdzili nasze wątpliwości i poparli nasz apel o wyjaśnienie wymogu uznając, że ich Termination Plan nie wydaje się być w pełni zgodny ze wspomnianym wymogiem. Niestety na agendzie spotkań było bardzo wiele istotnych kwestii do omówienia, a najwyższy priorytet ma interoperacyjność, więc kolejną dyskusję w sprawie wymogu SG-01 zaplanowano na najbliższą środę tj. na jutro 02.09.2020 r. Niestety jutro agenda spotkania jest jeszcze bardziej okazała (m.in. omówienie DPIA dla Federal Gateway'a), więc obawiam się, że rozmowy dot. SG-01 nie zostaną zamknięte. Mam szczerą nadzieję, że poświęcimy temu zagadnieniu na tyle czasu, aby inne PCz mogły się wypowiedzieć i zająć stanowisko w sprawie. Jak tylko otrzymam jakieś nowsze lub pełniejsze informacje co do kierunków prac lub decyzji - będę aktualizował w tym wątku. |
|
News z dziś: Jednak - tak jak przewidywałem i o co apelowałem - Apple i Google umożliwiają korzystanie z Exposure Notification bez instalowania aplikacji. Jeszcze nie w Polsce, ale myślę że już niedługo: Kolejny krok, który zbliża EN do tego co postulowałem w https://blog.kurasinski.com/2020/05/jarek-potiuk-musimy-zaufac-technologii/ @PawelLitwinski- może to faktycznie adresuje wszystkie kwestie związane z prywatnością o których pisałeś w raporcie z #209 ? Ciekaw jestem Twojej opinii. |
|
@potiuk świetna wiadomość, dzięki za udostępnienie. Potwierdzają się nasze oczekiwania jakie mieliśmy od samego początku pojawienia się inicjatywy G+A. Zapewne pomogły też liczby, bo w żadnym kraju aplikacje działające na G+A nie osiągnęły wymaganego poziomu ~60% pokrycia populacji. Teraz zaczyna mieć to sens, czekam z niecierpliwością. |
W ramach rozwoju chcemy wprowadzić funkcjonalność zwaną "kill switch", która pozwoli po zakończeniu pandemii/ustaniu zagrożenie wyłączyć funkcję contact tracingową i usunąć dane z nimi związane - zgodnie z zaleceniami eHealth Network (str. 37, SG-01). Innymi słowy, aplikacja każdego z użytkowników musi w jakiś sposób zostać poinformowana, że kryzys minął, należy zastopować funkcję EN, usunąć wszelkie dane w aplikacji* i pokazać użytkownikowi odpowiedni komunikat.
Jako, że ma być to raczej "instant", aktualizowanie aplikacji (które nie jest równoznaczne z jej instalacją przez wszystkich użytkowników, może potrwać kilka dni/tygodni) nie jest najlepszym rozwiązaniem. Rozwiązania które przychodzą nam do głowy to:
Czy ktoś ma jakieś inne sugestie rozwiązania? Czy ktoś ma jakieś zastrzeżenia do któregoś z powyższych rozwiązań?
*O ile aplikacja może usunąć dane przechowywane przez nią, o tyle dane zgromadzone przez EN należy usunąć ręcznie w Ustawieniach telefonu (aplikacja może tylko przekierować użytkownika w to miejsce).
The text was updated successfully, but these errors were encountered: