Zmiana modelu działania aplikacji na anonimowy i (być może) zdecentralizowany #34
Comments
|
Centralny rejestr wszystkich identyfikatorów użytkowników, dodatkowo powiązanych z ich numerami telefonów to badzo nietrafiony pomysł. Nie znam specyfikacji Pepp-Pt, ale po ogólnym opisie aplikacji spodziewałem się tego, że będą zwyczajnie "rozgłaszane" identyfikatory użytkowników, którzy mają mieć się na baczności z powodu bliskiego kontaktu, a urządzenia (mając historię również własnych identyfikatorów) będą w stanie łatwo to zweryfikować. Natomiast to co opisano w data_sharing.md (przeklejam tutaj dla widoczności) to jakaś katastrofa pod względem prywatności:
|
|
Aplikacja podczas pierwszego uruchomienia mogłaby generować losowy identyfikator (UUID) i zapisywać go w magazynie sekretów, a następnie posługiwać się nim w celu jednoznacznej identyfikacji danego użytkownika. Prawdopodobieństwo kolizji jest marginalne, ale podczas rejestracji można zrobić detekcję. |
|
@mateuszjablonski Ale... nie ma potrzeby rejestracji, ani identyfikacji użytkowników innej niż "lokalna". Ba! nie ma potrzeby przypisywania "tymczasowych" identyfikatorów do konkretnego użytkownika. Zarys idei jest bardzo prosty (nie wchodząc w detale).
W tych scenariuszach nie jest potrzebna żadna komunikacja z serwerem. Jedynym momentem, w którym trzeba wysyłać cokolwiek na serwer jest moment w którym dany użytkownik zostaje zbadany i ma pozytywny wynik testu. Wówczas używa jakiegoś specjalnego, jednorazowego kodu, który służy do wgrania historii jego spotkań (zebranej w scenariuszu 2) na serwer. Ta historia jest analizowana i wybierane są zagrożone jednorazowe identyfikatory innych użytkowników. Aplikacje mogą natomiast odczytywać z serwera ogłoszone "zagrożone" identyfikatory i porównywać je ze swoimi, zapisanymi lokalnie. |
|
@jasisz dzięki za wyjaśnienie. Czy ten mechanizm jest gdzieś opisany dokładniej? Przewertowałem dokumentację i nie udało mi się tego znaleźć. |
|
@jasisz - dokładnie tak. i aplikacja może odpytać o swoje unikalne identyfikatory |
|
@potiuk Odpytanie o dany identyfikator sugerowałoby, że to mój identyfikator i pozwalało mnie (przynajmniej w teorii) z nim powiązać. Dlatego piszę o oficjalnym "streamie" identyfiaktorów, odczytywanych przez wszystkich jednakowo. |
|
W ramach ciekawostki. https://lucumr.pocoo.org/2020/4/3/contact-tracing/ Unikalny identyfikator zaszyfrowany jakimś kluczem urzędowym. |
|
@rtpm Armin pominął bardzo ważny aspekt. Jego klucz jest unikalny ale też niezmienny. Pozwala więc na śledzenie użytkownika przez innych użytkowników oraz na ostracyzm w postaci "hej, ale twój klucz jest ogłoszony jako że jesteś potencjalnie zagrożony". |
|
@rtpm @jasisz @potiuk @jasisz podnosi ważny problem - modułu spotykania się z innymi i logowania tychże interakcji nie widziałem ( z tego co wiem to jest część w budowie i jest PR przynajmniej na appce androidowej ) , ale chciałbym tutaj od razu zaznaczyć, że na pewno jest imo potrzeba, aby oprócz swojego prywatnego unikalnego identyfikatora był identyfikator publiczny, który wymieniamy tylko na potrzeby "spotykania się". W sensie - dostając czyjś publiczny identyfikator powinniśmy być tylko w stanie zidentyfikować dwie osoby, które się widziały, natomiast mając czyjś identyfikator publiczny nie jesteśmy w stanie sprawdzić żadnych informacji, bo te są sprawdzane naszym identyfikatorem prywatnym. |
potiuk
changed the title
|
Zmieniłem opis - pozostawiając "clue" w międzyczasie kilkoro naukowców opublikowało whitepaper, kto który opisuje jak to zrobić dobrze - w sposób kompletnie anonimowy i zdecentralizowany https://github.com/DP-3T/documents |
Zgadza się. W ogóle nie powinno być możliwości zidentyfikowania osoby "zdrowej". Osoba chora i zdiagnozowana powinna jedynie dostać kod który "autoryzowałby" fakt że faktycznie osoba była potencjalnym zarażającym ale również nie powinien unikalnie identyfikować tej osoby. |
|
@potiuk Całkiem sensowny dokument! Przyszło mi do głowy jedno zagrożenie prywatności... niestety istnieje w obu tych rozwiązaniach. Gdyby atakujący był w stanie ustalić że w danym epoch "widział" (i był widziany przez) tylko jedną osobę, a potem identyfikator tej osoby (jak w publikacji) albo identyfikator atakującego (tak jak u mnie) byłby rozgłoszony... to oznaczałoby, że ta konkretna spotkana osoba została pozytywnie zdiagnozowana.
|
|
Chciał bym przestrzec wszystkich - wczoraj zostałem celem bardzo sprytnego ataku phishingowego który próbował wyłudzić moje credentiale na githuba. Uratował mnie mój klucz hardwarowy który używam jako 2FA. Jeśli dostaliście ostatnio jakiegoś maila z githuba mówiącego o podejrzanej aktywności - sprawdźcie uważnie skąd jest "sender" i w jaki link klikacie (u mnie było to githubs.com). |
|
Dziękuję za wszystkie głosy w tym wątku. Przeczytałem je wszystkie. Z ciekawością patrzę na inicjatywę PEPP-PT. Zabiegam o to abyśmy jako Polska/ProteGO przystąpili do niej. Kłopot z PEPP-PT jest taki, że na dzień dzisiejszy jest to tylko specyfikacja. My za kilka dni będziemy mieli aplikacje w sklepach i całość naszego kodu już jest otwarta. Nie wiem czy któryś kraj ogłosił już, że będzie używał tego co powstanie na bazie PEPP-PT. Wiem, że w Polsce Ministerstwo Cyfryzacji chce opublikować i promować ProteGO. Nie da się aplikacji typu Przyglądajmy się wspólnie temu co powstanie na bazie PEPP-PT i doświadczeniom krajów, które to wdrożą. Jeśli macie czas, zaangażujcie się i pomóżcie im przerobić specyfikacje w działające rozwiązanie. Mam nadzieję, że nie będzie z nią tak jak z wieloma innymi rozwiązaniami, które technicznie lepsze i bezpieczniejsze, nie są powszechnie używane (GPG vs. clear text email, Monero vs. fiat money, etc). Myślę, że ważną metryką na podstawie której powinniśmy podjąć decyzję o ew. przejściu na PEPP-PT będzie to ile osób zgłosi się samodzielnie do GIS po otrzymaniu informacji o zagrożeniu, a do ilu z nich będzie trzeba dzwonić. Jeszcze raz dziękuję za wasze głosy. Przepraszam jeśli nie jestem w stanie odpowiedzieć na wszystko, ale mój główny wysiłek jest teraz skupiony na dostarczeniu wersji PS. Też dziś miałem próbę resetu hasła do GitHub. Uważajcie na siebie. |
|
Nie chodzi o technicznie lepsze rozwiązania, ale o zachowanie prywatności. Tak naprawdę ta aplikacja w Polsce będzie potrzebna za 5-10 tygodni bo tyle potrwa wypłaszczanie wzrostu. Według mnie lepiej to zrobić dobrze niż szybko i naruszając prywatność, |
|
Otwarcie kodu nie znaczy że dane są prywatne. Poza tym nie są rozstrzygnięte podstawowe kwestie które tak naprawdę definiują co to znaczy otwarty kod. To o czym piszesz @jakublipinski jest "wydmuszką" open source - nie spełnia to podstawowych kryteriów
Dopóki te rzeczy nie są rozstrzygnięte - to nie jest projekt który nazwałbym w jakikolwiek sposób "open source".
Aktualizacja: zgodnie z wyjaśnieniami @jakublipinski - wiadomo kto jest właścicielem kodu - każda osoba która kontrybuuje jest właścicielem ale na mocy licencji oraz oświadczenia (https://github.com/ProteGO-app/specs/blob/master/files/oswiadczenie_licencja_GPL_AGPL.pdf) które pojawiło się po tej dyskusji - rezygnuje z wykonywania własnych, osobistych praw autorskich na okres minimum 10 lat (i te 10 lat tylko w przypadku, gdyby zobowiązanie do niewykonywania tych praw miało by być bezwględnie sprzeczne z obowiązującymi przepisami prawa). |
|
@jakublipinski Piszesz o ważnej kwestii pragmatycznej - łatwy kontakt GISu z zarażonymi użytkownikami - ale żeby ten projekt działał dobrze, musi być przede wszystkim bardzo szeroko rozpowszechniony. W sytuacji w której są wątpliwości co do możliwości nadużycia zbieranych danych, zarówno mainstreamowe media, jak i duża ilość osób "znających się" i niezależnych serwisów mogą wręcz bić na alarm i stanowczo odradzać używania tej aplikacji. Zwłaszcza w kraju, w którym zaufanie do instytucji publicznych jest dość niskie, ta kwestia jest fundamentalna dla sukcesu projektu. |
Z tego co wiem, to obecnie każda karta sim jest rejestrowana imiennie. Jeśli GIS wie kto jest zarażony, to może da się skorzystać z tego rejestru, aby znaleźć telefon danej osoby? Czy taka integracja byłaby możliwa? |
|
Wydaje mi się, że jednym z rozwiązań zapewniających jednocześnie prywatność, jak i zachowujące pragmatyzm, jest wysyłanie numeru telefonu do GIS w momencie, gdy właściciel staje się osobą potencjalnie zarażoną. (Z możliwością opt-out w ustawieniach aplikacji.) Osoby zdrowe nie wysyłają na serwer nic (poza zapytaniami). Już teraz pojawiają się głosy o tym, iż celem tego typu aplikacji jest jedynie śledzenie obywateli. Takie rozwiązanie będzie podobne do bycia dawcą, z możliwością opt-out. Jeśli ktoś widzi problem z takim rozwiązaniem, to proszę o zgłoszenie go.
Czy aby na pewno? |
|
Absolutnie się zgadzam. Numer telefonu jest kompletnie niepotrzebny - a na pewno w pierwszej wersji aplikacji kiedy lokalnie będą zbierane dane i kiedy będzie można rzetelnie przeprowadzić debatę publiczną na ten temat. Powiem więcej - polecam dyskusję w #37 #46 #48 #54 #55 #56 . Zwłaszcza to ostatnie podsumowujące - apel o publiukację aplikacji z wyłączeniem podawania numeru telefonu. |
|
Jeśli zakładane jest całkowite oddanie decyzyjności (od instalacji aplikacji, podjęcia odpowiednich działań w przypadku uzyskania z apki informacji o byciu potencjalnie zarażonym, a co za tym idzie kontakt z sanepidem czy też dobrowolna izolacja / większa ostrożność, to rozwiązanie bez numeru telefonu jest dobre. Jedynym weryfikatorem i motywatorem, czy użytkownik ze statusem potencjalnie zarażonego "słusznie" postępuje byłyby bramki/ograniczenia w dostępie do usług, ale o tym w ogólnie ma ma mowy i nie wiadomo czy będzie (patrzę na przykład innych krajów, gdzie obywatela się bardziej "kontroluje"...). |
|
Od początku (praktycznie) a w każdym razie od momentu w który poczytałem o obu systemach, decentralizacja nie była (dla mnie) warunkiem koniecznym. Natomiast anonimizacja tak. Z tego względu jak dla mnie (jeśli #83 będzie zrobione tak by informować użytkownika o utracie anonimowości - dla mnie jest to akceptowalne). |
|
Ciekawostka - w DP-3T dodano alternatywne rozwiązanie, w którym publikowane są Cuckoo filters na EphIDs zarażonych, a nie klucze prywatne zarażonych - https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf |
|
@jasisz -> myślę że pomysł jest całkiem niezły i na pewno warty ekslporacji I być może wdrożenia w przyszłych wersjach aplikacji - najlepsze w tym rozwiązaniu jest to, że dane w systemie mogą być przechowywyane przez max. 2 tygodnie - więc przyszłe wersje aplikacji mogą dość swobodnie zmieniać zarówno algorytmy wysyłania danych, optymalizować etc. Może warto żebyś założył issue w tym temacie? A może nawet warto by było spróbować to zaimplementować? |
|
@potiuk Jako użytkownik aplikacji nie mam żadnej gwarancji jak długo te dane są przechowywane na serwerze. Jeżeli natomiast mogą być użyte do black boxowych algorytmów - zakładam że mogą być przechowywane już zawsze. |
|
Zgadza się - nie ma. Ale to zupełnie inna kwestia kto i jak będzie o to dbał. Mam nadzieję, że będzie to kwestią publicznej debaty i ustanowienia jakiejś formy kontroli nad tym jak by to miało być docelowo. Po zmianie założeń że numer jest obowiązkowy i jasą na ten temat informacją - jak zaproponowałem w #83 (według mojej, osobistej opinii) system może startować (tak żeby był jak najszybciej przydatny) a dalsze zmiany można wprowadzać w trakcie działania. To o czym napisałem to tylko informacja że jest możliwa zmianie działania aplikacji już po jej opublikowaniu. I wszelkie pomysły na to będą na pewno rozpatrzone przez zespół ją budujący. Możesz mieć na ten temat oczywiście inną opinię. Podobnie jak ja mam swoja. Obawiam się że trudno tutaj o jakąś prawdę absolutną i jedynie słuszne rozwiązanie. |
|
@potiuk Trudno mi zrozumieć co się zmieniło od czasu, kiedy pisałeś:
|
|
Dalej pozostaje problem braku zaufania do oznaczania ludzi "na czerwono" (ta część backendu nie jest otwarta i nie ma też pewności, czy ktoś nie będzie sobie oznaczał ludzi ręcznie). W obecnej sytuacji nie ma możliwości zweryfikowania, czy użytkownik został oznaczony na podstawie "prawdziwego" spotkania. |
|
@jasisz @Przytua -> Bardzo dużo się zmieniło. Jak dla mnie to jest mocno inny świat. Zmieniła się anonimowość (pod warunkiem dobrego zaadresowania #83). I z tego wynika, że numer telefonu nie jest "kluczem" rozwiązania. Dzięki temu nie można argumentować "ale już nie możemy tego zmienić bo numer telefonu jest "kluczem głównym". W obecnym rozwiązaniu wiadomo że bez numeru wszystko będzie działać - i to jest super. Im szybciej zacznie sie zbierać dane, tym lepsze wypracuje się rozwiązanie. To że możliwe jest anonimowe działenie i nie ma potrzeby używania numeru telefonu jako klucza identyfikującego instalację gwarantuje według mnie że rozwiązanie jest otwarte na przetwarzanie danych anonimowo. Poza tym pierwsze dwa tygodnie od zainstalowania wszyscy mają status "pomaranńczowy" - niezależnie od tego co będzie na serwerze - i w międzyczasie można dyskutować nad potencjalnymi rozwiązaniami algorytmów. |
|
"_Poza tym pierwsze dwa tygodnie od zainstalowania wszyscy mają status "pomaranńczowy" - niezależnie od tego co będzie na serwerze - i w międzyczasie można dyskutować nad potencjalnymi rozwiązaniami algorytmów." - błąd; przez pierwsze dwa tygodnie nie będzie nikogo zielonego. Czerwoni mogą być już następego dnia |
|
Przeczytaj proszę uważnie @tomekziel : za https://github.com/ProteGO-app/specs/
|
|
Ktoś może być zdiagnozowany dzień po instalacji i stanie się czerwony. |
|
Ale to nie przychodzi z serwera tylko wynika z diagnozy konkretnej osoby zidentyfikowanej podczas diagnozy. To nie jest robione przez algorytm. |
|
Wszystkie statusy przychodzą z serwera. W kodzie nie ma nigdzie oznaczania osoby jako czerwonej. Nie ma nawet walidacji czy dany przez nią proof jest poprawny, bo ta też jest rozumiem "ręczna". |
|
@potiuk Warto przeczytać również głos krytyczny nt. PEPP-PT napisany przez ITO i proponowany w zamian alternatywny protokół TCN (następca STRICT) bardziej dbający o prywatność. Koalicja TCN ma już 10 członków, może warto doń dołączyć? |
|
Tak z ciekawości, bo nie znalazłem tych informacji nigdzie indziej - kto podejmuje decyzje projektowe i jaką rolę pełni MC? Z wypowiedzi ministra wynika model "my robimy z udziałem społeczności", ale już w GitHubie tak to nie wygląda. |
|
@tomekziel Wygląda na to, że Polidea, w osobach @jakublipinski i @potiuk - trudno natomiast mieć pewność, bo członkowie ProteGO na GitHubie nie są publiczni. |
|
Nie do końca. Ja nie jestem w projekcie, znam go dobrze, ale w większości jednak tylko komentuję i zwracam uwagę na pewne problemy - ale nie podejmuję decyzji w projekcie. Decyzje są podejmowane zgodnie z zapisem tu: https://github.com/ProteGO-app/specs/blob/master/CONTRIBUTING.md#kto-podejmuje-decyzje-w-tym-projekcie |
"Są podejmowane" ale nie wiadomo, przez kogo. Łącznik słucha ministerstwa i podejmuje decyzje? Ministerstwo podejmuje i przekazuje ją łącznikowi? Decydują ojcowie założyciele i informują ministerstwo? |
|
Myślę że bardzo ważne, rozsądnie podane i wyważone argumenty @cloudyfuel. Z wieloma się zgadzam. Tak jak pisałem w #83 - anonimowość jest faktycznie bardzo zależna od sposoby komunikacji (dark pattern o którym wspomniałeś) i mam nadzieję że będzie to rozwiązane dobrze. Faktycznie przekonanie do nie-obowiązkowości numeru to duża sprawa - tak jak to już wielokrotnie pisałem. Co do social scoring mam trochę inną opinię. Social scoring to jednak co innego, ale gdyby system był faktycznie anonimowy to część "fizyczna" statusu umożliwiająca obecność w miejscach które wiążą się z dużymi ryzykami, to może być całkiem ważny element walki z pandemiią. Ja to porównuję bardziej z tym w jako sposób wchodzi się na stadiony - osoby z zakazem stadionowym nie wchodzą. Oczywiście to zupełnie co innego, ale wydaje mi się że bycie osobą zagrożoną (jeśli nie da się tym indywidualnie manipulować) powinno skutkować jakąś formą ograniczeń. Cała idea tej aplikacji polega na tym że te ograniczenia nie mają dotyczyć wszystkich (tak jak teraz) tylko najbardziej pawdopodobnej grupy osób. Co do szybkości wypuszczenia - fakt, super szybko. Ale też w tym systemie jest wiele niewiadomych - i adopcja na pewno nie będzie szybka. Dane też "ważne" są 2 tygodnie więc to co będzie za 2 tygodnie może być czymś innym niż teraz. I jak opisano w . Dlatego uważam że (jeśli anonimowość jest zachowana) - im szybciej zacznie się analizować faktyczne działanie systemu - tym lepiej. A co do decyzji @tomekziel -> 🤷 . Nic więcej niestety nie wiem. |
|
https://www.apple.com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/ |
|
Szczegóły są pod https://www.apple.com/covid19/contacttracing/ - wgłębiam się. |
|
Nic odkrywczego - z grubsza to samo co DP-3T z tą różnicą, że są pośrednie klucze "dzienne". |
|
Przeczytałem już. W pełni zdecentralizowany algorytm garściami czerpiący z wszystkich dyskusji (Seed Tracking Key + generowany Daily Tracking Key + generowane BT identifiers co 15 minut). Żadne dane zdrowych ludzi nie trzymane na serwerze. Daily Keys żeby zminimalizować wymianę danych. Faktycznie nic odkrywczego - ale za to zebranie wszystkiego co najlepsze w jednym miejscu. Jedni drugim będą patrzeć na ręce i wszyscy im też będą patrzeć. Plus docelowo integracja na poziomie OS (na razie nie) która zapewni niskie zużycie baterii, brak usypiania etc. Pozamiatane. |
|
@potiuk Nie mogę znaleźć, ale jak widzę tutaj użytkownik sam oznacza się jako "chory" i decyduje się na udostępnienie danych? W sensie zastanawiam się czy system nie jest podatny na false positive bez weryfikacji zgłoszeń chorych (osoba zdrowa oznaczy się jako chora "dla żartu"). |
|
są klucze dostarczane przez "medical Authorities" - żeby wysłać takie dane trzeba te klucze dostarczyć. Standard w tego typu rozwiązaniach. |
A może, jak przystało na aplikację, która ma zapewnić prywatność i spowodować zaufanie obywateli nic nie powinna wysyłać sama tylko poprosić użytkownika o odbycie dobrowolnej kwarantanny i poprosić o skontaktowanie się z GIS / sanepidem (wyświetlając potrzebny numer / dane kontaktowe)? Zamordyzmem nic nie osiągniecie ponieważ ludzie mają jeszcze możliwość żyć bez smartfonów albo bez tej aplikacji. Sama będę nawływała do pozbycia się telefonów jeżeli będzie zamordyzm typu "mususz zainstalować jeżeli masz androida lub iOS" a w przypadku zamordyzmu typu "rejestracja na numer telefonu", "wyślemy twój numer instytucji X" będę odradzała używanie tego g...a. Tak g...a, bo tam można nazwać w tym PiSowskim kraju tego typu działania. |
No właśnie tak to miało być dla osób które numeru nie podadzą (numer/dane kontaktowe). A nawet powiem więcej - zmiana statusu na "zagrożony" powinna stanowić przepustkę do natychmiastowych i darmowych testów (pisałem o tym w #54). Ale jeśli podanie numeru miałoby być jako opt-in, to myślę że ta opcja z wysyłaniem numeru jest bardzo ok - zwłaszcza w przypadku osób starszych. Wyobrażam sobie, że wielu osobom (na przykład mojej teściowej) wnuczek czy syn mógłby zainstalować aplikację i podać numer po instalacji, żeby w razie czego to GIS mógł zadzwonić i porozmawiać z taką osobą/przekonać ją do kontaktu. Powtarzam - jeśli tylko nie byłby to wspomniany "dark pattern" który nachalnie "wymuszałby" podawanie numeru. Obecne API Google/Apple zostawia swobodę w tym jak kontakt "Health Authorities" z osobami instalującymi aplikację miałby wyglądać - i dobrze, bo w różnych krajach może być różnie. Jednocześnie uniemożliwia łączenie nawet podanego numeru z konkretnymi BT ID (do tego aplikacja nie ma dostępu przez API). Więc zaimplementowanie tego "opt-in" wygląda na całkiem sensowne rozwiązanie, a nie zamordyzm. |
Aplikacja ProteGO w obecnym kształcie zbytnio narusza prywatność osób zdrowych. Umożliwia to deanonimizację informacji wysyłąnych na serwer. Jest to niezgodne na przykład z zaproponowaną specyfikacją https://www.pepp-pt.org/ (pod warunkiem że ta specyfikacja pozostanie wierna temu żeby była zachowana pełna anonimowość).
Nie ma żadnej potrzeby, żeby aplikacja wymagała podania i potwierdzenia numeru telefonu przy instalacji. Komunikacja z zagrożonymi osobami zdrowymi może być zrobiona na poziomie aplikacji - niepotrzebny jest numer telefonu (i żaden inny identyfikator pozwalający zidentyfikować zarówno osobę zdrową jak i zdiagnozowaną).
Właśnie pojawił się protokół który opisuje jak to samo zrobić w wersji zdecentralizowanej i anonimowej:
https://github.com/DP-3T/documents
Zamiast identyfikacji, osoba zdiagnozowoana powinna otrzymać kod (nazwany TAN_ID w specyfikacji https://www.pepp-pt.org/) który powinien zostać wpisany w celu wysłania (dalej anonimowej) swojej historii spotkań jeśli było by to potrzebne do analizy. Ten numer również nie powinien identyfikować osoby - również po diagnozie, powinien służyć jedynie do autoryzacji danych i obrony przed spamem.
Uwaga! Zaktualizowałem pierwotny opis -> odwołałem się początkowo do specyfikacji, która nie była bardzo precyzyjna, a w międzyczasie pojawił sie opis protokołu który doskonale opisuje założenia jak zrobić to dobrze - prywatnie i w sposób zdecentralizowany.
Aktualizacja 06.04.2020 - > Wydaje się że model anonimowy można utrzymać zachowując jednocześnie konieczność obowiązkowej rejestracji za pomocą numeru telefonu. Apel o to w #56 .
#34 (comment)
The text was updated successfully, but these errors were encountered: