Wdrożenie i udokumentowanie rozwiązań dotyczących prywatności

[potiuk]

Is your feature request related to a problem? Please describe.

Zasadą jest że "issue" na githubie zamyka się, kiedy dana funkcjonalność zostanie zrealizowana a nie, kiedy jest zadeklarowana. Niestety twórcy aplikacji pozamykali sporo issue jedynie deklarując rozwiązania dotyczące prywatności, bez implementacji i bez wdrożenia rozwiązania.

Uważam to za przedwczesne, zwłaszcza że wyjaśnienia w niektórych issue są niepełne, więc aby pomóc twórcom aplikacji stworzyłem zbiorcze issue w którym umieściłem te rozwiązania, które zostały zadeklarowane jako "zrobimy", ale też te, które należy wyjaśnić, uzupełnić dokumentację etc.:

• Audit Request - audyt bezpieczeństwa i prywatności aplikacji #141 - Audit Request - audyt bezpieczeństwa i prywatności aplikacji: czekamy na wynik audytu. Jednocześnie apelujemy o nie promowanie aplikacji dopóki audyt nie zostanie przeprowadzon i upubliczniionu
• Ratingi aplikacji lecą na łeb na szyję #140 - Ratingi aplikacji lecą na łeb na szyję - myślę że warto monitorować rating dopóki nie osiągną solidnej 3 i dopiero wtedy można tą sprawę zamknąć.
• Natychmiastowe wyłączenie wysyłania danych z ankiet do api.safesafe.app #139 - Natychmiastowe wyłączenie wysyłania danych z ankiet do api.safesafe.app - tu należy na pewno uaktualnić dokumentację i być może zmienić komunikację i usunąć proxy rządowe
• Implementacja protokołu Google + Apple zamiast własnego rozwiązania BT i QR Code #132 - Implementacja protokołu Google + Apple zamiast własnego rozwiązania BT i QR Code - - tu czekamy aż API Apple + Gppgle zostanie faktycznie zaimplementowane
• Naruszenie prywatności - Łączenie adresu IP osób zdrowych z ich TempID w obecnej implementacji (OpenTrace) #116 - Naruszenie prywatności - Łączenie adresu IP osób zdrowych z ich TempID w obecnej implementacji (OpenTrace) - tu czekamy aż obecne rozwiązanie zostanie usunięte
• Planowany sposób użycia kódów QR łamie wytyczne EDPB #124 - Planowany sposób użycia kódów QR łamie wytyczne EDPB - tu czekamy na uaktualnienie specyfikacji i wyjaśnienia dotyczące funkcjonalności/działania z kodami QR
• Możliwe szpiegowanie przez rząd #110 - Możliwe szpiegowanie przez rząd - czekamy na wyjaśnienia, dolumenty, plan zarzadzania jakością, niezależne opinie etc.

Bardzo bym prosił o nie zamykanie tego issue, jako że pomoże on Twórcom aplikacji śledzenie co jeszcze zostało do zrobienia - głównie w kwestii prywatności.

Describe the solution you'd like
Kod, dokumentacja, wyniiki audytu i wszystkie pozostałe artefakty powinny być publicznie dostępne w tym repozytorium

Describe alternatives you've considered
Ponowne otwarcie faktycznie nie wdrożonych issue - ewidentnie nie jest to na rękę osobom tworzącym aplikację.

[KoderFPV]

@potiuk
Hej,
Na wszystkie issue odpowiedzieliśmy.
Dużo z nich nie ma związku z nami a duża częśc powinna być przekierowana do
https://github.com/opentrace-community/opentrace-cloud-functions

Odpowiem poraz drugi na to samo. Pana posty zakrawają o spam.

#141 - Audyty są prowadzone i zostaną opublikowane
#140 - Monitorujemy ratingi
#139 - Dokumentacja jest aktualizowana a proxy jest potrzebny (chociażby aby zahardkodować klucze API)
#132 - Nie pracujemy nad QR Code
#116 - Tak jak napisane: prosimy o kontakt z https://github.com/opentrace-community/opentrace-cloud-functions
#124 - Nie pracujemy nad kodami QR
#110 - Tak jak napisane w odpowiedzi, pracujemy nad dokumentacją oraz transparentnością. Cały czas dokumentacja będzie aktualizowana w najbliższych dniach

Pozdrawiam
Issue do zamknięcia. Wszystko zostało wyjaśnione.

[potiuk]

Nie chodzi mi odpowiedź tylko o wdrożenie zmian. Jednak nalegam na otwarcie.

[potiuk]

Czy to jest właśnie ta otwartość i transparentność w temacie ?

[SeraMoon]

Nalegam na re-open zamkniętych issue. Issue zamyka się po ich:

• zaimplementowaniu (najczęściej jest to usunięcie buga),
• sprawdzeniu (zweryfikowaniu) - w bugzilli odpowiada to statusowi "Verified Fixed".

Wtedy issue wraz z komentarzem można zamknąć.

Na razie to wygląda jak wynajęcie armii rosyjskich trolli do zamykania issue zamiast ich czytania i naprawiania. To scenariousz jeszcze gorszy niż wcześniejszy.

@potiuk proszę zaalarmuj o tym Panoptykon - art wyjdzie jutro - mogą go jeszcze uzupełnić o powyższą nietransparentność.

@potiuk jesteś w stanie dać na małpkę tu wszystkich programistów pracujących w tym projekcie aby wiedzieli że należy zacząć od czytania zamkniętych issue? Niestety nie wiem jak uzyskać tą listę tu na GitHubie. Dostaną wtedy e-mail i przeczytają.

@Tarvald rzygać mi się chce suchymi zapewnieniami oraz taką właśnie manipulacją jaką wskazał w tym wątku @potiuk.

[KoderFPV]

@SeraMoon @potiuk
Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.

Pozdrawiam

[potiuk]

Problemy nie zo

@SeraMoon @potiuk
Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.

Pozdrawiam

Deklaracje != poprawienie problemów. Issue nie powinny być zamykane bez ich poprawienia. Jeszczed nigdy czegoś takiego nie widziałem w żadnym projekcie.

[SeraMoon]

@SeraMoon @potiuk
Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.

Pozdrawiam

Nie otrzymaliśmy i nalegamy na re-otwarcie tych wątków. 🤦‍ Brak Committee uniemożliwia odwołanie się od decyzji. #143

@potiuk potwierdzam, ja też nie widziałam czegoś takiego w żadnym projekcie. Nieaktualne speki widziałam, ale nie zamykanie issue przed usunięciem problemu, którego dotyczą.

Dla nietechnicznych: i programistów początkujących: issue (zgłoszenie) trzyma się w stanie otwartym (open / opened / re-open, new) do czasu kiedy nie zostanie załatany błąd i sprawdzone rozwiązanie. Są potrzebne więc 3 etapy:

• zaprogramowanie (praca nad nim) - zazwyczaj prowadzi to do zmiany statusu z "new" na "open" (gdy przewidziany jest new),
• przetestowanie rozwiązania (uzyskuje status Fixed),
• weryfikacja i audyt wewnętrzny wraz z ponownym przeczytaniem zgłoszenia, czy zostało zrealizowane - często z pytaniem autora wątku, czy zostało to zrobione i działa (zyskuje status Fixed+Verified lub odpowiednik na githubie "Closed").

Zamknąć można zgłoszenie jeszcze w przypadku kiedy jest nieprawidłowe. Jednak wtedy należy udowodnić jego nieprawidłowość komentarzem.

Nie cierpię JS5. Wolę programować w ES2015.

[SeraMoon]

"Closed" i jednocześnie "0 of 7 tasks complete". Super.

[zbyszek-matuszewski]

Nie spotkałem się jeszcze z zamykaniem issue przed rozwiązaniem.

Uważam, że niektóre issue można było zamknąć na zasadzie, że nie jest to issue z którym można coś zrobić, naprawić (ratingi) lub dotyczy czegoś, co w końcu z tego co rozumiem nie powstanie (QR kody). Tylko to należałoby tam podać jasny powód dlaczego to jest "not an issue" lub "won't fix".

Pozostałe zgodnie z podstawowymi zasadami należy trzymać otwarte dopóki nie zostaną finalnie rozwiązane.

Co do przerzucenia odpowiedzialności na bibliotekę - to by było OK gdyby ta część była opcjonalna. Czyli np. macie swój soft i niektórzy używają go razem z zewnętrzną biblioteką lub innym softem i narzekają, że to nie działa lub nie jest bezpieczne. Tutaj jest inaczej - importujecie tamto rozwiązanie (opentrace), więc odpowiadacie za luki spowodowane jego użyciem. To nie może być won't fix - powinniście albo to naprawić albo nie używać.

To takie moje uwagi jako programisty zajmującego się nieco innymi rzeczami i do tej pory tylko obserwującego dyskusję.

[mimi89999]

Nie spotkałem się jeszcze z zamykaniem issue przed rozwiązaniem.

Ja się z tym spotkałem w projekcie Signal. Wszystkie issue powiązane z dostosowaniem aplikacji do polityki F-Droida były od razu zamykane i blokowane. Było to po prostu niezgodne z kierunkiem rozwoju projektu i z ich potrzebami. (to było kilka lat temu, nwm jak jest teraz)

[kaczynski88]

Co za małpki pracują w tym projekcie to ja nawet nie wiem typowa państwówka robiona na odwal się xD

[zbyszek-matuszewski]

Ja się z tym spotkałem w projekcie Signal. Wszystkie issue powiązane z dostosowaniem aplikacji do polityki F-Droida były od razu zamykane i blokowane. Było to po prostu niezgodne z kierunkiem rozwoju projektu i z ich potrzebami. (to było kilka lat temu, nwm jak jest teraz)

Jeszcze rozumiem, że feature requesty można w pewnych sytuacjach tak zamykać bo kierunek totalnie niezgodny z wizją itp., ale nie issue (problemy z prywatnością i bezpieczeństwem).

[piotr-zuralski]

Jeśli "transparentność" i "otwartość" mają być realizowane właśnie w taki sposób jak pokazuje Pan Artur Slomowski @Tarvald, to życzę powodzenia.

A jak jeszcze macie kogoś z MC od PM-owania i dzieją sie takie rzeczy... to bardzo ciekawie by było.

[KoderFPV]

@piotr-zuralski
Tak jak pisałem wcześniej w wielu miejscach (facebook, linkedin, github).

1. Prowadzone są prace porządkowe na GH
2. Pewne wątki zostały ponownie otworzone Wdrożenie i udokumentowanie rozwiązań dotyczących prywatności #148
3. Część wątków była nie aktualna
4. Cześć była nie zgodna z obecnymi założeniami [Update] Założenia projektu ProteGO Safe #147

Zachęcamy do zakładania nowych wątków zgodnych z #147

Komentarze do #147 będą mile widziane w osobnych wątkach. Wątek główny pokrywa za dużą tematyke, żeby można prowadzić w nim dyskusje.

Na GH nadal są prowadzone prace porządkowe.

Prosimy o wyrozumiałość i pomoc w postaci Pull Request'ów.
Każdy może zaproponować poprawkę do każdego z 4 repozytoriów.

[piotr-zuralski]

@Tarvald właśnie przejrzałem część issues, dobrze, że zmieniliście zdanie 🙂 👍