Closed MateuszRomanow closed 4 years ago
Przenoszę swoje pytania z #188 :
Kiedy #141 Audyt i kto go wykona?
ad 1 - tak, będziemy także udostępniać kod backendu (w ramach dostępności czasowej - mam nadzieję jeszcze na weekend, ale nie mogę obiecać) ad 2 - 4.0 nie miała działających Exposure Notifications, których skończenie i podpięcie okazało się dla Googla i dla nas znacznie dłuższą pracą. W tym czasie do aplikacji weszło tyle fixów, że ostatecznie planujemy wydać to jako 4.1.0 lub 4.1.1 . ad 3 - audyty są w trakcie. Opublikujemy raporty poaudytowe w przyszłym tygodniu, przed "premierą" a po fixach.
@MateuszRomanow - super że są postępy, z tego co zrozumiałem jesteście w ścisłej czołówce (3 kraje tylko tak zaawansowane ?) działań w Europie ?
Jak już wcześniej - znów pomęczę trochę o funkcjonalność "ręcznego znakowania realnych spotkań" za pomocą QR-kodów (chodzi o LOKALNE przechowywanie listy spotkań np. służbowych w pracy za pomocą bilateralnej/unilateralnej zgody, z najprostszym zapisaniem kontaktu z QR-kodu np. numer. telefonu pod który w przypadku bycia zakażonym aplikacja roześle info na żądanie zakażonego użytkownika z LOKALNEJ bazy z ostatnich np. 14 dni).
Czy na obecnym etapie widzicie możliwość dodania tego rozwiązania do ProteGo Safe równoległego dla API (nie związanego z nim kodem) oraz istniejących już aktualnie funkcjonalności aplikacji ? Jeżeli to jest realne to jaki byłby przybliżony horyzont czasowy ?
Tak jak już wcześniej pisałem taka funkcjonalność może być szczególnie pomocna dla służby zdrowia (ale nie tylko).
Chodzi tylko o lokalne logowanie numerów telefonów z QR-kodu, do których zakażony/potwierdzony użytkownik rozsyłałby informację SMS z własnej woli i inicjatywy o jakiejś miminalistycznej treści np. takiej:
"Tu Jan Kowalski (tel. 600 123 321). Mam dodatni wynik rtPCR na obecność koronawirusa. Spotkaliśmy się w dniu 24 maja 2020, o godz. 13:26. Informacja wysłana za pomocą aplikacji ProteGo Safe"
Prośba o info w tej sprawie, jak już pisałem chętnie potestuję jakąś wersję beta j.w. w szpitalu z moim zespołem i innymi kolegami w pracy - ta deklaracja jest stale aktualna.
BTW: Przy okazji ciekawe info że od tygodnia funkcjonuje centralny rejestr wszystkich badań COVID-19 ujednolicony dla całej polskiej służby zdrowia i wszystkich laboratoriów. Każdy podmiot zlecający ma tam swoje konto i zarządza w ten sposób badaniami swoich pacjentów i pracowników:
https://rejestrcovid.mz.gov.pl/
Format szybkiego pobierania "informacji o wyniku" został ujednolicony dla placówek medycznych i laboratoriów w całym kraju.
@Dr-Kownacki Dzięki za słowa otuchy. Jednak czy mogłbym prosić o wydzielenie tej prośby o dodatkową funkcjonalność do osobnego wątku? Nie dotyczy to statusu wersji 4.1, a chcielibyśmy żeby ten wątek był "wmiare" przejrzysty. Dzięki z góry :)
@Dr-Kownacki nie chcę tutaj offtopować, ale tematu kodów QR działających lokalnie w obecnej wersji nie ma. To wymaga kooperacji z G+A, a tam jest też ogień, więc można do tego wrócić za kilka tygodni w osobnym wątku jak się wszystko "ułoży".
[MożeOT] Jak dla mnie to z jednej strony duma, że tak jest jak pisze @Dr-Kownacki, z drugiej trochę słabo, że nikt z zewnątrz lub biorących udział nie mógł brać udział w takim pokazie dla Google/Apple. Może wydaje mi się za dużo, ale wypadałoby podać, że będzie spotkanie i zaprosić przynajmniej jednego przedstawiciela do sprawdzenia czy, rzeczywiście będzie to tak jak piszecie - tak moim zdaniem.
@kierepka słusznie, zrobimy taki otwarty pokaz dla wszystkich zainteresowanych. Jak będą szczegóły założymy osobne issue z ustaleniem terminu i szczegółów.
@pkleczko @thecodersio @MateuszRomanow
Obejrzałem sobie kod aplikacji Androidowej w wersji 4.1.0-rc.1 (commit 5b0a414, krwawiące ostrze technologii). A raczej - androidowego kadłubka, którego jedynym zadaniem jest pośrednictwo między aplikacją webową zanurzoną w webview a natywnymi funkcjami Androida.
Mam w związku z tym jedno zajebiście, ale to zajebiście ważne pytanie: czy aplikacja webowa umieszczona w webview będzie: a) osadzona w paczce APK z aplikacją Androidową, by można było tę aplikację zaudytować i uruchamiać offline b) pobierana z internetu podczas uruchomienia aplikacji, co oznacza, że nie da się aktywować funkcji Exposure Notification bez połączenia z internetem?
EDIT: proszę o wskazanie, która z opcji jest prawdziwa lub szczegółowy opis architektury, jeśli żadna z opisanych opcji nie oddaje dokładnie docelowego stanu rzeczy (choć RC sugeruje gotowość do wydania).
@tomekziel b
@tomekziel b
Umysł bronił się przed tą odpowiedzią, ale przepona była gotowa. Obśmiałem się jak norka.
Chyba was Bóg opuścił.
Co do punktu b
z zapytania - potrzebujesz połączenia z internetem chociaż raz, żeby w procesie onboardingu pozwolić aplikacji na korzystanie z ExposureNotification.
@tomekziel wypowiedzi w takim tonie na forum są niepoważne i żałosne - szczególnie biorąc pod uwagę to, że od niedawna legitymujesz się jako dziennikarz. Z jednej strony próbujesz doprosić się o umowę na wykonanie projektu robiąc to w bardzo potulny sposób, a z drugiej stosujesz tutaj zbędne wulgaryzmy i obśmiewasz udzielone ci odpowiedzi. Poważny i szanujący się dziennikarz tak się nie zachowuje.
@Tarvald proszę o interwencję, bo takie zachowania nie powinny mieć tu miejsca.
potrzebujesz połączenia z internetem chociaż raz, żeby w procesie onboardingu pozwolić aplikacji na korzystanie z ExposureNotification
Dlaczego? W diagramach nie widziałem nic o połączeniu z internetem podczas onboardingu, zaś aktualna dokumentacja mówi tak: "Your app must be able to communicate with an internet-accessible server that you own and that performs the following functions: ● Collects diagnosis keys from users who have been diagnosed with COVID-19. ● When polled, distributes diagnosis keys of confirmed cases to devices"
Z jednej strony próbujesz doprosić się o umowę na wykonanie projektu robiąc to w bardzo potulny sposób
Nie podoba mi się dobór słów. Nie dopraszam się tylko żądam udostępnienia umowy, bo mam do tego prawo. Wasi mocodawcy mi je ograniczają.
@tomekziel jeśli przyjrzysz się dokładnie źródłom, to zauważysz że komunikacja appki z PWA odbywa się przez JSBridge. W jednym z kontraktów (dokładnie dataType = 52) pytamy użytkownika o pozwolenie na korzystanie z EN. Żeby taki kontrakt miał szansę dojść do skutku, najpierw potrzebujesz połączenia z internetem żeby odpalić PWA i do tego kontraktu w ogóle dotrzeć.
Co do doboru słów i zastosowanego cytatu - kompletnie mijasz się z celem mojej wypowiedzi. Osobiście jestem zniesmaczony językiem którego tu używasz, a także jak odnosisz się do @pkleczko - do tego już się nie odniosłeś.
Żeby taki kontrakt miał szansę dojść do skutku, najpierw potrzebujesz połączenia z internetem żeby odpalić PWA i do tego kontraktu w ogóle dotrzeć.
Otóż to. Ja uważam, że aplikacja powinna realizować tę funkcję bez połączenia z internetem, a ponieważ mamy do czynienia z aplikacją której publiczność przygląda się szczególnie uważnie, to nie powinna istnieć żadna możliwość wstrzykiwania logiki biznesowej z zewnątrz. Aplikacja powinna działać offline i korzystać z sieci tylko do realizowania komunikacji wynikającej z protokołu Exposure Notification.
jestem zniesmaczony językiem którego tu używasz
Już się poprawiam. Poproszę o uzasadnienie tej kontrowersyjnej decyzji. W mojej opinii obecna architektura aplikacji sprawia, że spośród "7 filarów zaufania" numery 6 i 7 są trudne lub niemożliwe do spełnienia zaś 3 i 4 - co najmniej dyskusyjne.
@tomekziel
Otóż to. Ja uważam,
Dobrze że to zaznaczyłeś. Ja uważam że dużo aplikacji używa internetu i nie sadze żeby to było bardziej niebezpieczne niż COVID, ani nic co nacodzień mogłoby mi zaszkodzić.
Chyba was Bóg opuścił.
A na pewno nie na tyle żebyś musiał odbiegać od powszechnie akceptowalnej retoryki medialnej. Jeżeli Ci się nie podoba architektura to załóż osobnego taska na to. Porozmawiamy o tym.
Wstrzykiwanie PWA jest dużo łatwiejsze do audytowania niż zaszyty kod w aplikacje który trzeba analizować za pomocą inżynierii wstecznej.
Panowie @tomekziel @pkleczko @RMalczynski rozmowa zeszła daleko od statusu, a zeszła bardzo mocno na architekture.
@tomekziel Jeżeli masz jakieś wątpliwości co do architektury, o której jawnie mówimy od dawien dawna to prosze założ osobny wątek. Może w wersji późniejszej powstaną zmiany które Cie usyfakcjonują. W tym momencie trzymamy się założeń z #147 #187
A jak nie to zawsze, możesz zrobic forka naszych repozytoriów i zaproponować zmiane w PR.
Feel free to join!
Markuje pare ostatnich postów jako offtopic i zapraszam do dyskusji na temat architektury w osobnych wątkach. Najlepiej w repozytorium /backend.
Pozdrawiam
@Tarvald bardzo słabo, że markujesz tak ważne kwestie jako off-topic. Na pewno nimi nie są. @tomekziel proszę otwórz poruszane tematy w oddzielnych wątkach tak by nie przepadły.
Jak dla mnie wymaganie internetu do aplikacji, w której nie jest wcale potrzebny to zdecydowanie zła decyzja. Nie rozumiem dlaczego nagle poszło to w tą stronę. Wyjaśnienia typu:
Ja uważam że 90% aplikacji używa internetu i nie sadze żeby to było bardziej niebezpieczne niż COVID, ani nic co nacodzień mogłoby mi zaszkodzić.
są bardzo nieprofesjonalne, by nie napisać po prostu śmieszne. Tutaj mówimy o aplikacji którą ma zainstalować 80% społeczeństwa, nie może być miejsca na takie rzeczy. Wykorzystując PWA zostawiacie sobie furtkę na wprowadzanie zmian bez wiedzy użytkowników. Wyjaśnienie o łatwiejszym audytowaniu możesz wsadzić między bajki - nikt nie robi audytu inżynierią wsteczną...
W takiej formie i z takimi decyzjami nie zaufam temu podejściu i będę odradzał aplikację innym.
Myślę że zaznaczenie powyższych wypowiedzi jako off-topic jest bardzo dużym nadużyciem i jest niezgodne z regulaminem który sami sobie narzuciliście.
Uważam też osobiście że komentarz Tomka nie był wulgarny ale dowcipny, Również obśmiałem się jak norka słysząc jak to jest zaimplementowane.
@tomekziel ma absolutną rację jeśli chodzi o pobieranie PWA wewnątrz aplikacji - o ile faktcyznie niewielka część aplikacji tak robi, nie wydaje mi się żeby była konieczność pobierania większości kodu aplikacji z serwera. Zwłaszcza w tego rodzaju aplikacji. W tym momencie jakiekolwiek mówienie o audycie i ocenie działania aplikacji mija się z celem bo nie sposób zaudytwać kodu który w każdej chwili może się zmienić.
Uważam że wkraczacie znowu na cienką linię w której podniesie się publiczny hejt na waszą aplikację (i znowu dlatego że nie Tworzyliście jej - mimo zapowiedzi - w otwarty sposób tylko bardzo poważne decyzje dotyczace również prywatności podjęliście znowu w zaciszu gabinetów bez konsultacji z opnią publiczną - mimo publicznych deklaracj że będzie inaczej.
Z Kasią z Panoptykonu widzę się w przyszłym tygodniu a zarówno @tomekziel jak i ja na bieżaco się z Panoptykonem (i innymi podobnymi organizacjami) kontaktujemy.
Na waszym miejscu (i tu piszę do @MateuszRomanow ) zastanowiłbym się, czy znowu chcecie się angażować w kolejną burzę (a taka się zapowiada jeśli rzetelne komentarze będziecie traktować "z buta". Daliśmy wam szansę żebyście choć spróbowali dotrzymać obietnic, ale na razie bardzo słabo ją wykorzystujecie.
@MateuszRomanow - myślę że parę dni i jeśli tak dalej pójdzie to parę nowych artykułów i stanowisk w tej sprawie wkrótce się ukaże.
Panowie @potiuk @kwiszowaty @tomekziel Nie markuje ich jako offtopic żeby coś ukryć, ani w złej intencji. Po po prostu jeżeli zostawię to tak jak teraz jest, to nikt nie będzie chciał czytać tego wątku bo w ciągu paru postów odbiega on od tematu.
Załóżcie osobny wątek i wtedy będzie można tam dyskutować. Nie jest to problem do rozwiązania w 2 min.
Ponownie zapraszam do otwierania nowych wątków! Off topowanie nie jest zgodne z regulaminem.
Jeszcze raz pozdrawiam wszystkich zaangażowanych.
ps. Sam otworzyłbym taki wątek, ale wolałbym żeby ktoś z was to zrobił, kto dokładnie opisze swój problem związany z PWA @potiuk @kwiszowaty @tomekziel
Ja nie miałem ochotę wchodzić w dalszą polemikę na takim poziomie, ale jak zaczęły się pojawiać merytoryczne argumenty to mogę do dyskusji wrócić. Mimo, że nie jestem największym fanem tego rozwiązania (bo co native to native) to jednak ma ono wiele plusów. Ot takich jak to że możemy teraz nie przerywać procesu review aplikacji w sklepach tylko nanieść uwagi do warstwy UI od audytorów z Google i Apple w krótkim czasie, bez konieczności updatowania aplikacji. Przypominam, że mamy w aplikacji moduł Triage którego drzewo decyzyjne nie jest małe, w łatwy sposób można było je przenieść z API zewnętrznego do lokalnego JS, budowanie tego osobno na iOS i Android wydłużyłoby czas dostarczenia aplikacji (co nie zmienia faktu że przyszłościowo fajnie byłoby je zrobić natywnie i wszyscy chcielibyśmy to zrobić). Dane wymieniane pomiędzy wartstwą PWA i natywną można łatwo sprawdzić w kodzie, opisaliśmy je również tutaj (tak wiem, dopiero przed chwilą ale ciągle uzupełniamy dokumentację): https://github.com/ProteGO-Safe/android/blob/release/4.1.0-rc.1/doc/JavaScriptBridge.md
Jest to minimum danych, poza całościowym stanem ryzyka w skali 1-3 nie ma tam nic wrażliwego i każda próba dostania się do większej ilości danych wymaga update'u kodu źródłowego aplikacji natywnej. Tak jak w normalnej aplikacji. Moduł PWA nie ma żadnych uprawnień dostępu do danych telefonu.
Warstwa UI nie różni się od tego co było w poprzedniej wersji aplikacji i w tym etapie nie było planów na jej zmianę na natywny kod.
Proszę o merytoryczne uwagi, a nie hejt i clickbaitowe posty na Twitter :)
Ale to jest komentarz na temat statusu właśnie. To nie jest off-topic w żaden sposób. Myślę że to świetne miejsce do dyskusji.
@potiuk Nie wolałby Pan wydzielić tego do osobnego wątku i dać się wypowiedzieć osobą które potencjalnie mogą być zaanażowane architekture? Obawiam się że w tym wątku będzie cieżko dojść do jakiegos podsumowania czy konkluzji. Mechanizmy GH są bardzo ubogie jeżeli chodzi o zarządzanie komentarzami.
@pkleczko: Jasne że to jest zaleta z szybszą aktualizacją, ale w przypadku tego rodzaju wrażliwej aplikacji wydaje się to niepotrzebne i mało przydatne (zwłaszcza ze funkcjonalność tej aplikacji będzie mocno ograniczona jeśli chodzi o UI).
Zacytuję tu informację, którą przesłałem do Panoptykonu (nie dosłownie ale mniej więcej).
Oczywiście API Exposure Notification narzuca spore ograniczenia na to co mogą zrobić ale jednak wydaje się że w tak ważnej sprawie to jest bardzo poważna decyzja i raczej niezgodna - jak to Tomek ujął - z waszymi punktami 6. i 7. z filarów zaufania. To umożliwia też w przyszłości na przykład monetyzowanie albo wykorzystanie do marketingu tego jak zachowują się i co robią użytkownicy aplikacji. W tym wypadku nie chodzi o prywatność danych przed rządem - ale przed monetyzowaniem i wyciąganiem informacji na temat zachowań użytkowników. Dynamiczna aplikacja PWA mocno to ułatwia i na pewno Twórcy aplikacji sobie z tego zdają sprawę bo z tego co rozumiem (poprawcie mnie jeśli się mylę) to większość ich aplikacji bardzo mocno z tego korzysta.
Z racji że społeczność nie zamierza wydzielić tematu do osobnego wątku, postanowiłem odmarkować posty zamarkowane jako offtopic, do czasu aż faktycznie dyskusja nie przeniesie się do osobnego wątku.
Ale to jest komentarz na temat statusu właśnie. To nie jest off-topic w żaden sposób. Myślę że to świetne miejsce do dyskusji.
Przekonał mnie Pan! @potiuk
Jak dla mnie wymaganie internetu do aplikacji, w której nie jest wcale potrzebny to zdecydowanie zła decyzja. Nie rozumiem dlaczego nagle poszło to w tą stronę.
@kwiszowaty chyba nie rozumiesz jak działa koncepcja wykrywania Exposures - w momencie gdy załączy się task w backgroundzie, musisz mieć połączenie z internetem - w innym przypadku nie jesteś w stanie pobrać kluczy Diagnosis Keys z serwera, które to potem są potrzebne do analizy Exposures. Połączenie z internetem jest konieczne - nie jest ważne czy aplikacja korzystałaby z PWA, czy zrobiona by była w pełni natywnie.
@RMalczynski Pytanie brzmi czy połaczenie z internetem naprawdę jest wymagane w momencie włączania Exposure Notification. Ściąganie kluczy zarażonych to oddzielny temat.
@jasisz do samego włączenia EN połączenie z internetem rzeczywiście nie jest wymagane przez sam framework, ale z racji że korzystamy z PWA, no to musimy z internetu korzystać. Ściąganie kluczy to nie jest całkowicie osobny temat - jakby nie było, to to jest podstawowy mechanizm na którym opiera się proces prowadzący do wykrywania Exposures. Pisanie, że aplikacja nie potrzebuje połączenia z siecią to konsekwencja nie zrozumienia podstawowych założeń projektowych.
@RMalczynski Nie do końca... Exposure Notifications od G+A nie wymaga połączenia z internetem, w takim sensie że dalej będzie działać - nawet jeżeli ktoś zupełnie wyłączy internet, to po prostu nigdy nie dowie się o kontakcie z zarażonym.
Dalej natomiast będzie mógł się rozgłaszać i zbierać kontakty, a włączyć internet może w dowolnym momencie, np. dopiero w momencie kiedy dowie się o własnym zakażeniu i zechce zuplodować swoje dane.
O ile dobrze rozumiem to zapytania o klucze zarażonych są robione już bezpośrednio na poziomie Exposure Notifications, to nie sama aplikacja ProteGO je wykonuje. Tutaj natomiast mamy komunikację z serwerem po stronie waszej aplikacji, co właśnie dziwi dyskutantów.
@RMalczynski - ale nic nie stoi na przeszkodzie żeby całą logikę PWA dołączyć do aplikacji jako zasoby i nie pobierać javasriptu/html-a dynamicznie. Wtedy to by było audytowalne przed każdym releasem. I praktycznie nie wymaga zmian w architekturze.
Tu nikt nie dyskutuje o tym jaka technologia została wybrana tylko o tym że logika działania jest pobierana dynamicznie z serwera a nie jest częścią aplikacji.
@jasisz masz rację co do tego, że klucze są rozgłaszane na poziomie EN, bez połączenia z internetem. Zapytania o klucze Diagnosis Keys są jednak wykonywane bezpośrednio przez aplikację w backgroundzie. Exposure Notification samo nie pobiera kluczy z serwera, to appka jest odpowiedzialna za dostarczenie ich do analizy.
@RMalczynski
@kwiszowaty chyba nie rozumiesz jak działa koncepcja wykrywania Exposures - w momencie gdy załączy się task w backgroundzie, musisz mieć połączenie z internetem - w innym przypadku nie jesteś w stanie pobrać kluczy Diagnosis Keys z serwera, które to potem są potrzebne do analizy Exposures. Połączenie z internetem jest konieczne - nie jest ważne czy aplikacja korzystałaby z PWA, czy zrobiona by była w pełni natywnie.
Bardzo dobrze rozumiem koncepcję działania EN, natomiast zupełnie nie rozumiem po co została wprowadzona idea PWA? Od miesięcy dyskutujemy, że wszystko co można należy przenieść do aplikacji natywnej. Jak się bardziej wczytasz w specyfikacje G+A to znajdziesz tam wytyczne kiedy i tylko kiedy musimy mieć dostęp do Internetu. Pobieranie kluczy osób zarażonych i wysyłka swoich (jeżeli jestem zarażony), to zupełnie inny temat o którym nie dyskutujemy.
Dla mnie problemem jest PWA które zostawia furtkę do wielu rzeczy. I wszystkie zalety przytoczone przez @pkleczko są dla mnie wadami w tego typu aplikacji, która ma dotrzeć do takiego grona ludzi. Komentarz w stylu
możemy teraz nie przerywać procesu review aplikacji w sklepach tylko nanieść uwagi do warstwy UI od audytorów z Google i Apple w krótkim czasie, bez konieczności updatowania aplikacji
to wg mnie wielka dziura - bo tak samo można przez nią dodać cokolwiek. Jestem ciekawy, czy w ogóle takie podejście, w takiego typu aplikacji, przejdzie audyt G+A
@kwiszowaty @potiuk
Bardzo dobrze rozumiem koncepcję działania EN, natomiast zupełnie nie rozumiem po co została wprowadzona idea PWA?
To że aplikacja działa w taki sposób łącząc się z PWA, jest z nami od wersji 3 (a nawet wcześniej) i jest to powszechna wiedza. Nie zostało to wprowadzone na potrzeby wersji 4.
To że aplikacja działa w taki sposób łącząc się z PWA, jest z nami od wersji 3 (a nawet wcześniej) i jest to powszechna wiedza. Nie zostało to wprowadzone na potrzeby wersji 4.
Było to wtedy kiedy aplikacja miała tylko moduł samooceny - dodatkowo korzystający z Intermedica - wtedy miało to sens. Ale od samego początku wszystkie komentarze były "zmieńmy to, żeby kod był nawet jawascriptem ale lokalny". Ja osobiście nie mam prolemu z używaniem PWA jako takiego, pod warunkiem że kod javascript + css + html będzie częścią aplikacji a nie będzie ściągany. To jest zero wysiłku z waszej strony żeby to zmienić żeby tak było - ten kod powinien być - podobnie jak cała aplikacja częścią audytu przy KAŻDYM releasie aplikacji. Jeśli tak nie będzie to naruszacie filary zaufania o których pisze Panoptykon.
Jeśli jeszcze sobie nie zdajecie z tego sprawy - to to podejście kompletnie dyskfalifikuje według mnie (i innych osób, którym zależy na zaufaniu, prywatności etc.) jakiekolwiek zaufanie do tej aplikacji. I jeśli tak będzie opublikowana to kolejny artykuł "Nie instalujcie ProteGO" już zaraz będzie się pisał.
Nie mówię żebyście z tym polemizowali, czy argumentowali - to troche nie ma sensu bo założenia są nieakceptowalne. Po prostu zastanówcie się @MateuszRomanow czy znowu chcecie żeby rozpętała się burza. Wiecie że ten temat jest dla nas ważny i go nie odpuścimy, Trochę wasz wybór czy chcecie znowu wchodzić w konflkt, czy wsłuchacie się w to, co piszemy.
Ja osobiście nie mam prolemu z używaniem PWA jako takiego, pod warunkiem że kod javascript + css + html będzie częścią aplikacji a nie będzie ściągany. To jest zero wysiłku z waszej strony żeby to zmienić żeby tak było
To nie prawda, bo zaimplementowaliśmy moduł diagnostyczny lokalnie, zgodnie z głosami społeczności :)
Ja osobiście nie mam prolemu z używaniem PWA jako takiego, pod warunkiem że kod javascript + css + html będzie częścią aplikacji a nie będzie ściągany. To jest zero wysiłku z waszej strony żeby to zmienić żeby tak było
To nie prawda, bo zaimplementowaliśmy moduł diagnostyczny lokalnie, zgodnie z głosami społeczności :)
Nie wiem co jest nieprawdą. Wiem że tak się stało. Tylko niech ten moduł diagnostyczny (i cała reszta aplikacji) będzie zawarta w aplikacji a nie ściągana z serwera. To jest dokładnie to, o co nam chodzi. Niech tam sobie będzie javascript html i css. Ale nie ściągany tylko włączony do aplikacji i audytowalny (przy każdym releasie). Wcześniej jak rozmawiałem z @MateuszRomanow to mówił że tak właśnie będzie - że aplikacja przy każdym releasie będzie audytowana.
Nie wiem co jest nieprawdą. Wiem że tak się stało. Tylko niech ten moduł diagnostyczny (i cała reszta aplikacji) będzie zawarta w aplikacji a nie ściągana z serwera. To jest dokładnie to, o co nam chodzi. Niech tam sobie będzie javascript html i css. Ale nie ściągany tylko włączony do aplikacji i audytowalny.
Wygląda to jak "Feature request"
Wygląda to jak "Feature request"
Raczej naturalna konsekwencja waszych obietnic ("Cały kod jest audytowany").
@Tarvald
To że aplikacja działa w taki sposób łącząc się z PWA, jest z nami od wersji 3 (a nawet wcześniej) i jest to powszechna wiedza. Nie zostało to wprowadzone na potrzeby wersji 4.
Sorry za nieścisłość i skróty myślowe. Oczywiście chodziło mi o to, że nie rozumiem po co wprowadziliście PWA nawet do samego włączenia EN?
Wygląda to jak "Feature request"
Możesz to nazwać jak chcesz - bez tego aplikacja nie ma przyszłości, wielu ludzi temu nie zaufa.
Raczej naturalna konsekwencja waszych obietnic ("Cały kod jest audytowany").
Jest audytowany przez zewnętrzne firmy, przez Google i Apple a teraz przez was czyli społeczność. Wynikiem audytów są feature requesty i bug requesty.
@kwiszowaty Ok dzięki za wyjaśnienie.
Naprawdę proponuje otworzyć nowe wątki. I tak jak wcześniej wiele razy posłuchaliśmy głosu społeczności tak i tym razem zrobimy co w naszej mocy.
Jednak z developerskiego punktu widzenia, przepisanie PWA na native nie jest zadaniem trywialnym. Osobiście jako developer (daily), nie znam takiego combo pt. native + lokalne PWA.
Ale to wszystko do wyjaśnienia. Dzięki za zaangażowanie.
Jednak z developerskiego punktu widzenia, przepisanie PWA na native nie jest zadaniem trywialnym.
Dalej moze to być PWA, tylko pliki będą assetem aplikacji.
Dalej moze to być PWA, tylko pliki będą assetem aplikacji.
@jasisz Podrzucisz jakiegoś doc'a do swifta i kotlina, dla społeczności?
@potiuk @jasisz @kwiszowaty
Trochę wasz wybór czy chcecie znowu wchodzić w konflkt, czy wsłuchacie się w to, co piszemy.
Wszyscy developerzy ProteGo zostali poinformowani o podniesionych tutaj kwestiach.
https://informatykzakladowy.pl/architektura-aplikacji-protego-safe-kolejne-kontrowersje/ - powiedzmy, że to taki feature request z przydługim uzasadnieniem
Podrzucisz jakiegoś doc'a do swifta i kotlina, dla społeczności?
Wątek jakoś zamarł, więc ja tylko napiszę, że w Androidzie można załadować zawartość osadzonego w assetach pliku html do webview komendą webview.loadurl("file:///android_asset/plik.html");
. Jeśli potrzebna jest dokładniejsza kontrola, to za pomocą setWebViewClient
wstrzykujemy do webview obiekt, w którym za pomocą przeciążonych metod shouldInterceptRequest oraz shouldOverrideUrlLoading możemy karmić webview spreparowanymi odpowiedziami na generowane żądania HTTP jak również reagować na nieprzewidziane zachowania użytkownika.
Myślę @MateuszRomanow (i piszę celowo do Ciebie bo ty jesteś odpowiedzialny za projekt a nie @Tarvald czy @RMalczynski ) że Twoim zadaniem jest teraz zaproponowanie rozmowy na temat tego dlaczego uważacie że takie rozwiązanie jest dobre, jakie macie argumenty, jak to chcecie audytować, wysłuchanie naszych argumentów i podjęcie świadomej decyzji co z tym robicie.
Ja się absolutnie zgadzam z Tomkiem (i to też przekaszujemy dalej) że w obecnej formie to jest nieakceptowalne rozwiązanie - i podobnie jak Tomek, nie wiedząc nic o założeniech, waszych argumentach a przede wszystkim przez brak jakiejkolwiek rozmowy na ten temat, możemy założyć że wybierając takie rozwiązanie a nie inne chcecie osiągnąć (wy lub wasi mocodawcy) zupełnie inne cele. Nie wiemy jakie, możemy się tylko domyślać, niestety brak dialogu z Waszej strony powoduje, że właśnie takie domysły powstają.
@MateuszRomanow - jeśli tego nie zrobicie i nie zaangażujecie społeczności w sposób który zapowiadaliście, że chcecie to robić - otwarty, z dialogiem i nadzorem społecznym - to będzie Wasza wina jeśli więcej tego rodzaju artykułów będą się pojawiać.
Przemyśl to proszę - i piszę to bezpośrednio do Ciebie. bo potem możesz być jednoosobowo odpowiedzialny za porażkę medialną tego projektu.
Z mojej (i rozumiem też Tomka i Panoptykonu i innych osób zaangażowanych) jest wola rozmowy na ten temat. Pytanie czy z Twojej i zespołu prowadzącego aplikację też?
Odpowiedz sobie na to pytanie i weź na siebie ciężar tej odpowiedzialności.
@potiuk Napewno się ustosunkujemy do tego. Jak w każdym projekcie, zadania są kolejkowane.
@Tarvald poza kolejką weźcie proszę pod uwagę priorytety Też jak w każdym projekcie ;-)
@potiuk Napewno się ustosunkujemy do tego. Jak w każdym projekcie, zadania są kolejkowane.
@Tarvald (ale tak ja pisałem przede wszystkim @MateuszRomanow bo wygląda na to, że mamy jakiś "głuchy telefon" a osoba odpowiedzialna za projekt się nie wypowiada).
Mam nadzieję że jeszcze zanim aplikacja znajdzie się w sklepie. Metoda faktów dokonanych nie jest najlepszą metodą do budowania zaufania. Jeśli opublikujecie aplikację bez rzetelnego odniesienia się i dyskusji z osobami ze społeczności - to nie dziwcie się, że pojawiają się takie artykuły jak ten od @tomekziel (I pewnie mój jeśli tak zrobicie). Tak jak pisałem @MateuszRomanow - to Twoja, jednoosobowa odpowiedzialność przede wszystlkim za wizerunek medialny tego projektu, i jeśli nie wyjdziecie naprzeciw społeczności, to będzie Twoja osobista wina, że nie potrafiłeś się odnieść do uwag tej społeczności.
Czekam na Twój ruch - piłeczka jest w 100% po Twojej stronie. To od Twoich działań i decyzji @MateuszRomanow zależy, jak projekt będzie odbierany przez społeczność.
@potiuk Tak w skrócie to chodzi o to by @MateuszRomanow powiedział, czy zaaplikują kody HTML/Javascript - bezpośrednio w aplikacji (w dowolny sposób, ale statyczny), w celu zapewnienia, że aplikacja nie będzie zmieniana "w locie" i by zapewnić większą transparentność? Jeżeli tak to jestem za.
@MateuszRomanow
Planowana publikacja produkcyjna 4.1 to przyszły tydzień, jeżeli będzie green light po audytach i review.
Na czym to stanęło? Było zielone światło i appka jest w review, czy nie było zielonego światła i deploy później?
Cześć, już odpowiadam. Pracujemy w dwóch strefach czasowych - od rana do 19:00 w PL i od 19:00 do 3-4 w nocy z Googlem i Applem (Kalifornijskim) co mocno obniża responsywność. 1) Fundamentalna kwestia to po co jest aplikacja? Przypomnę, że założenia były robione przez lekarzy na pierwszej linii frontu (w trakcie pandemii - która wciąż przecież trwa), epidemiologów, farmaceutów. Aplikacja jest po to, żeby efektywnie:
[lista będzie aktualizowana] 9) Na spotkaniu ekspertów zostały przedstawione również kwestie poruszane w tym wątku. Zobowiązałem się, że zaktualizuję tutaj wszystko, oraz, że zespół deveoperski odpisze od strony TECH a Ministerstwo Cyfryzacji przedstawi szczegóły w kolejnych oficjalnych komunikatach. 10) Jednocześnie przedstawiłem potrzebę zorganizowania otwartej prezentacji przed premierą aplikacji (rozmawialiśmy o tym wcześniej w tym wątku - dzięki za sugestię!). Został wyznaczony roboczo termin poniedziałek 08.06.2020 w godzinach (roboczo) 15:00/16:00. My ze swojej strony zaprezentujemy aplikację od strony TECH, na wszystkie (inne) pytania odpowiedzą przedstawiciele Ministerstwa Cyfryzacji, przedstawiłem sugestię żeby w spotkaniu uczestniczył osobiście Minister Cyfryzacji Pan Marek Zagórski. Po potwierdzeniu przez MC założymy osobne Issue do potwierdzania chęci uczestniczenia w spotkaniu - żeby zobaczyć ile osób będzie chętnych. Robocza formuła to wideo konferencja, żeby wszyscy mogli zadawać pytania. 11) Na wczorajszym spotkaniu ekspertów Prof. Tyll Kruger wraz ze swoim zespołem naukowym, przedstawili modele matematyczne wskazujące predykcję rozwoju pandemii w Polsce w scenariuszach:
@potiuk jestem, ale jak wspomniałem mało responsywny dlatego koledzy pomagają. Wszyscy czytają co piszesz :) , dzięki za głos(y). Oprócz wykonania aplikacji, proces ten angażuje także w niekończące się spotkania ze wszystkimi interesariuszami, w co zostałem w pełni wciągnięty. @Kamil98 dzięki za iOS#95 tak, dokumentacja cały czas się tworzy, koledzy @pkleczko @thecodersio i @lukasz-szyszkowski koordynują ten proces. @hubciorz tak, appka dostała zielone światło i jest w review. Nie mamy tutaj klasycznego cyklu audytowego, bo zmiany zachodzą codziennie więc czekamy na opracowanie (złożenie) finalnego raportu i go opublikujemy. "Dzienne" audyty są zarówno po stronie firm prywatnych jak i samego Googla i Appla.
Cześć, wracamy z paczką aktualizacji w sprawie wersji 4.1 :
dokumentacje koordynują: Android - @pkleczko iOS - @lukasz-szyszkowski Web (PWA) - @thecodersio
prosimy o wyrozumiałość w jej aktualizacji. Nie chciałem wrzucać tego do dyskusji bez dokumentacji, ale ponieważ w #188 temat się pojawił - aktualizuję.
27.05.2020 o godzinie 19:15-20:30 mieliśmy prezentację przed G+A (w sumie 26 osób) gdzie prezentowaliśmy wersje beta 4.1. Odbiór był dobry. 3 kraje w UE w tym my pracujemy w podobnym tempie.
28.05.2020 o godzinie 13:00-15:00 mieliśmy prezentację bety przed - robocza nazwa - "Zespół Ekspertów", do której Ministerstwo Cyfryzacji zaprosiło niezależnych ekspertów (na wczoraj 9 osób, m.in. NGOs, organizacje security, eksperci w tytułach dr. i prof. od analizy matematycznej, modelowania (modelujący m.in. predykcję rozwoju COVID-19 w PL). Czekam na informację, kiedy i czy możemy powiedzieć kto oprócz nas tam był.
Planowana publikacja produkcyjna 4.1 to przyszły tydzień, jeżeli będzie green light po audytach i review.
Największe zmiany w wersji 4.1:
Zaktualizuję #147 w wolnym slocie czasowym.