Czy można bezpiecznie publikować dzienniki awarii systemu iOS?

Jedna z używanych przeze mnie aplikacji na system iOS ostatnio znacznie się zawieszała, więc piszę o tym na ich forum. Mam kilka dzienników awarii.

Czy bezpiecznie jest publikować dzienniki awarii iOS w miejscu publicznym? Czy jest w nich jakaś informacja PII?

Widzę w nich wiele skrótów. Czy są całkowicie arbitralne / losowe, czy zawierają mój adres sprzętowy czy coś takiego?

— Rozpoznać
źródło

Jeśli wpiszesz w nich PII, to oczywiście katastrofa może bardzo dobrze je powstrzymać. Nic nie stoi na przeszkodzie, aby programiści uzyskali dostęp do danych sieci lub urządzeń w swoim programie, więc musiałbyś mieć dostęp do kodu źródłowego aplikacji, aby wiedzieć, czy jakaś awaria miałaby obawy dotyczące prywatności.

— bmike

Odpowiedzi:

Dzienniki awarii można bezpiecznie publikować publicznie. Nie ma w nich żadnych danych identyfikujących. Cały losowo wyświetlany tekst to adresy różnych metod, które Xcode symbolizuje w nazwy metod. Dzięki temu programiści mogą zobaczyć dokładną linię kodu, która spowodowała problem.

~~Również wiedz, że trudniej jest symbolizować dzienniki awarii, które zostały skopiowane i wklejone. Przydałoby się deweloperom uzyskanie dzienników awarii w oryginalnym pliku .crash.~~ Wygląda na to, że już tak nie jest, nie miałem problemu z skopiowaniem i wklejeniem dziennika awarii i symbolizowaniem użycia najnowszego Xcode.

— Ben Baron
źródło

To nie jest poprawne: .crashpliki są zwykłymi plikami tekstowymi. Skopiowane i wklejone dzienniki awarii można po prostu zapisać jako .crashpliki i wyświetlić w zwykłej przeglądarce. Nie to, że faktycznie ma to jakieś zalety. Jedynym potencjalnym problemem jest utrata formatowania, gdy kopiowanie i wklejanie usuwa nadmierne białe znaki.

— Konrad Rudolph

Przynajmniej z mojego osobistego doświadczenia nigdy nie udało mi się wkleić dzienników awarii, które symbolizują Xcode. O ile coś się nie zmieniło w nowszych wersjach Xcode, aby to umożliwić, to nie będzie działać. Podczas próby wklejenia zawartości dziennika awarii do nowego pliku i zapisania go jako .crash, organizator Xcode ignoruje go i musi być ręcznie symbolizowany przez wiersz poleceń, co jest frustrujące.

— Ben Baron,

Nie jestem pewien, co zrobiłeś (źle), ale .crashpliki to tylko pliki tekstowe. Możesz to łatwo zweryfikować.

— Konrad Rudolph,

Zrobiłem kolejny test z najnowszym Xcode i to symbolizowało kopię / wklejony dziennik awarii. Wydaje się, że to już nie jest problem, ale w przeszłości, gdy używałem Xcode 3, przysięgam, że miałem problem z jakimkolwiek dziennikiem kopiowania / wklejania. Nie jestem pewien, na czym polega problem, ale z jakiegoś powodu nie działały.

— Ben Baron,

Publikowanie niesymbolnego raportu o awarii nie ma sensu. Odpowiedź, że jest bezpieczna, jeśli nie jest symboliczna, przypomina mówienie, że palenie jest bezpieczne, jeśli nie zapalisz papierosa imo.

— Declan McKenna

Nie - nie jest powszechnie ani jednoznacznie bezpieczny.

Każdy programista może zapisać bardzo osobiste dane, więc jesteś na łasce projektantów i programistów, aby zdezynfekować i nie ujawnić żadnych danych osobowych w wypadku.

Bezpieczeństwo wynikające z niejasności (wartości są w systemie szesnastkowym) jest dość dobre, a szansa na ujawnienie czegoś wrażliwego jest bardzo bardzo niska, ale publiczne udostępnianie raportu o awarii może być niebezpieczne dla twojej prywatności.

Powiedziałbym, że nie publikuj niczego, dopóki naprawdę nie zrozumiesz, czym jest identyfikator GUID urządzenia i jak odczytać ślad stosu lub znaki szesnastkowe. Również na twoje ryzyko ma bezpośredni wpływ charakter programu. Tiny Wings nic nie wie, bo nic nie powiedziałem. Jest również mało prawdopodobne, aby zeskanowałem moją książkę adresową lub informacje o lokalizacji / dane kontaktowe.

Z drugiej strony mój program bankowy musi przechowywać numery PIN i rzeczy, które wprowadzam wyraźnie, zanim zostaną zaszyfrowane. 1Password działa z poufnymi danymi, takimi jak mój numer ubezpieczenia społecznego. Nawet jeśli program może ostatecznie zapisać dane zaszyfrowane - raport o awarii może ulec awarii w miejscu, w którym dane są przekształcane w coś, co widać wyraźnie na ekranie - ciąg cyfr. Zasadniczo dane chwilowo nie są chronione.

Ogólne pytanie „Czy publikowanie jest bezpieczne?” musi być nie bez zaświadczeń o danych przechowywanych w aplikacji. Zwłaszcza, gdy publikujesz go w tak publicznym i stałym miejscu jak Internet.

— bmike
źródło

słyszeć słyszeć, chyba że faktycznie przejrzysz wszystkie ujawnione dane, a zatem nie potrzebujesz porady, naprawdę nie możesz mieć żadnych gwarancji.

— ConstantineK

Czy twierdzisz, że prywatne dane (wartości instancji) przechodzą do śladów stosu? Wiem, że działa identyfikator GUID urządzenia, ale co jeszcze, jak twierdzisz, trafia do stosu śledzenia, który jest prywatny?

— Jason Salaz,

Nie - reguły sklepu z aplikacjami starają się temu zapobiec (samodomodyfikujący się kod i inne) - ale nic nie stoi na przeszkodzie, jeśli programista chce wykazać się kreatywnością w kodowaniu danych do zdalnego debugowania. Jest to bardzo mało prawdopodobne, ale dane w rejestrach ARM mogą być prywatne. Bardzo, bardzo mało prawdopodobne - może powinienem edytować swoją odpowiedź, aby była mniej silna? Nie chciałbym, aby moje zagregowane dzienniki awarii lub klucz CrashReporter były publiczne. Raport o awarii został specjalnie zaprojektowany, aby nie udostępniać prywatnych danych, ale programy ulegają awarii, gdy nie zachowują się zgodnie z planem.

— bmike