Безпечно публікувати журнали аварійних збоїв iOS у загальнодоступних?

Один із додатків для iOS, який я використовую, останнім часом зазнає краху, ніж зазвичай, тому я розміщую інформацію про це на їхньому форумі. У мене є купа журналів аварійних ситуацій.

Чи безпечно публікувати журнали збоїв iOS у громадському місці? Чи є в них ПІІ?

Я бачу в них багато хешів. Вони абсолютно довільні / випадкові, чи містять мою апаратну адресу чи щось таке?

— Кен
джерело

Якщо ви введете PII в них, то, звичайно, аварія може цілком його містити. Ніщо не заважає програмісту отримувати доступ до даних мережі або пристрою всередині своєї програми, тому вам доведеться мати доступ до вихідного коду програми, щоб знати, чи виникне проблема з конфіденційністю.

— bmike

Відповіді:

Журнали аварійних обставин безпечно розміщувати у відкритому доступі. В них немає ідентифікаційної інформації про вас. Весь випадковий вигляд тексту, який ви бачите, - це адреси різних методів, які символізуються Xcode в назви методів. Це дозволяє розробникам бачити точний рядок коду, який спричинив проблему.

Також знайте, складніше символізувати журнали аварійних ситуацій, які були скопійовані та вставлені. Розробникам було б корисніше отримати ваші журнали збоїв у оригінальному файлі .crash. Схоже, це вже не так, у мене не було проблеми з копією та вставкою журналу аварійних ситуацій та символікою за допомогою останнього Xcode.

— Бен Барон
джерело

Це неправильно: .crashфайли - це просто текстові файли. Скопійовані та вставлені журнали збоїв можна просто зберегти у вигляді .crashфайлів та переглядати у звичайному переглядачі. Не те, що це насправді має якісь переваги. Єдиною потенційною проблемою є втрата форматування, коли копіювання та вставка вставили зайвий пробіл.

— Конрад Рудольф

Принаймні, з мого особистого досвіду, мені ніколи не вдалося отримати вклеєні журнали аварійних збоїв, щоб позначити їх у Xcode. Якщо щось не змінилося в нових версіях Xcode, щоб це дозволити, це не працюватиме. Коли ви намагаєтеся вставити вміст журналу аварійних ситуацій у новий файл і зберегти його як .crash, організатор Xcode ігнорує його, і його потрібно символізувати вручну через командний рядок, який засмучує.

— Бен Барон

Не впевнений, що ви зробили (неправильно), але .crashфайли - це лише текстові файли. Ви можете це легко перевірити.

— Конрад Рудольф

Я зробив ще один тест з останнім Xcode, і він символізував копію / вставлений журнал аварій. Тож, здається, це вже не є проблемою, але тоді, коли я використовував Xcode 3, клянусь, у мене виникли проблеми з будь-яким журналом копіювання / вставлення. Не впевнені, у чому проблема, але вони чомусь не спрацювали.

— Бен Барон

Немає сенсу розміщувати несимволізований звіт про аварійну ситуацію. Відповідь, що це безпечно, якщо це несимволічно, схоже на те, що куріння є безпечним, якщо ви не запалюєте сигарети.

— Деклан Маккенна

Ні - це не є універсально чи однозначно безпечним.

Будь-який програміст може однозначно зберігати дуже особисті дані, тож ви зобов’язані дизайнерів та програмістів санітувати та не піддавати жодних особистих даних під час аварії.

Захищеність від невідомості (значення є в шістнадцятковій формі) досить хороша, і шанс виявити щось чутливе дуже низький, але поділитися звітом про аварійне публічне може бути небезпечним для вашої конфіденційності.

Я б сказав, що не публікуйте нічого, поки ви дійсно не зрозумієте, що таке GUID пристрою та як прочитати трасування стека або шістнадцяткові символи. Також на ваш ризик безпосередньо впливає характер програми. Крихітні крила нічого не знають, бо я нічого не сказав. Також навряд чи просканували мою адресну книгу чи інформацію про місцезнаходження / контактну інформацію.

З іншого боку, моя банківська програма повинна зберігати PIN-коди та речі, які я вводить чітко, перш ніж вона їх шифрує. 1Password працює з конфіденційними даними, такими як мій номер соціального страхування. Навіть незважаючи на те, що програма з часом може зберігати зашифровані дані - звіт про аварійне завершення роботи може зазнати аварійного завершення в тому місці, коли дані перетворюються на те, що ви добре бачите на екрані - послідовність цифр. В основному, за швидкоплинний момент дані не захищені.

Загальне питання "Чи безпечно розміщувати повідомлення?" не повинно бути НЕ без інших кваліфікацій на дані , що зберігаються в додатку. Особливо, коли публікуєш його на щось таке публічне та постійне, як Інтернет.

— bmike
джерело

почуйте почуте, якщо ви фактично не пройдете всі відкриті дані, і тому не потребуєте поради, ви справді не можете мати гарантій.

— КонстантинК

Ви претендуєте на те, що приватні дані (значення екземплярів) потрапляють у Сліди стека? Я знаю, що GUID пристрою робить, але що ще ви заявляєте, що це приватна трасування стека?

— Джейсон Салаз

Ні - правила магазину додатків намагаються запобігти такі речі (самомодифікуючий код і все), але нічого не заважає, якщо програміст хоче проявити творчість у кодуванні даних для віддаленої налагодження. Це малоймовірно, але дані про регістри ARM можуть бути приватними. Сильно, дуже малоймовірно - можливо, я повинен редагувати свою відповідь менш менш сильною? Я б не хотів, щоб мої зведені журнали аварій або CrashReporter Key були загальнодоступними. Звіт про збої був навмисно розроблений так, щоб не обмінюватися приватними даними, але програми виходять з ладу, коли вони не ведуть себе так, як планували.

— bmike