É seguro publicar logs de falha do iOS em público?

Um dos aplicativos iOS que eu uso está travando muito mais do que o normal ultimamente, por isso estou postando sobre isso no fórum deles. Eu tenho um monte de logs de falhas.

É seguro postar logs de falha do iOS em um local público? Existe alguma PII neles?

Eu vejo muitos hashes neles. Eles são completamente arbitrários / aleatórios ou contêm meu endereço de hardware ou algo assim?

— Ken
fonte

Se você inserir PII neles, é claro que a falha poderia muito bem contê-lo. Não há nada que impeça o programador de acessar dados da rede ou do dispositivo dentro do programa, assim você teria que ter acesso ao código fonte do aplicativo para saber se alguma falha em particular teria preocupações com a privacidade.

— bmike

Respostas:

Os registros de falha são seguros para postar em público. Não há informações de identificação sobre você nelas. Todo o texto de aparência aleatória que você vê é endereços dos vários métodos que são simbolizados pelo Xcode nos nomes dos métodos. Isso permite que os desenvolvedores vejam a linha exata de código que causou o problema.

~~Além disso, é mais difícil simbolizar os logs de falha que foram copiados e colados. Seria mais útil para os desenvolvedores obter seus logs de falha no arquivo .crash original.~~ Parece que esse não é mais o caso, não tive problemas em copiar e colar um log de falha e simbolizar usando o Xcode mais recente.

— Ben Baron
fonte

Isso não está correto: os .crasharquivos são apenas arquivos de texto simples. Os logs de falha copiados e colados podem ser salvos como .crasharquivos e visualizados no visualizador normal. Não que isso realmente tenha vantagens. O único problema em potencial é a perda de formatação quando a cópia e colagem removeu espaços em branco excessivos.

— Konrad Rudolph

Pelo menos na minha experiência pessoal, nunca consegui obter registros de falhas colados para simbolizar no Xcode. A menos que algo tenha mudado nas versões mais recentes do Xcode para permitir isso, ele não funcionará. Quando você tenta colar o conteúdo de um log de falha em um novo arquivo e salvar como .crash, o organizador do Xcode o ignora e deve ser simbolizado manualmente através da linha de comando, o que é frustrante.

— Ben Baron

Não tenho certeza do que você fez (errado), mas os .crasharquivos são apenas arquivos de texto. Você pode verificar isso facilmente.

— Konrad Rudolph

Fiz outro teste com o Xcode mais recente e simbolizou um log de falha de cópia / colado. Portanto, isso parece não ser mais um problema, mas quando estava usando o Xcode 3, juro que tive problemas com qualquer log de cópia / colado. Não sei qual era o problema, mas eles não funcionaram por algum motivo.

— Ben Baron

Não faz muito sentido publicar um relatório de falha não simbolizado. Responder que é seguro se não simbolizado é como dizer que fumar é seguro se você não acender o cigarro.

— Declan McKenna

Não - não é universal ou inequivocamente seguro.

Qualquer programador pode salvar dados muito pessoais de maneira clara, portanto, você está à mercê dos designers e programadores para higienizar e não expor nenhum dado pessoal em caso de falha.

A segurança pela obscuridade (os valores estão em hexadecimal) é muito boa e a chance de algo sensível ser exposto é muito baixa, mas compartilhar um relatório de falha publicamente pode ser perigoso para sua privacidade.

Eu diria que não poste nada até você realmente entender o que é um GUID do dispositivo e como ler um rastreamento de pilha ou caracteres hexadecimais. Além disso, seu risco é diretamente afetado pela natureza do programa. Tiny Wings não sabe nada porque eu não disse nada. Também é improvável que tenha digitalizado meu catálogo de endereços ou informações de localização / contato.

Por outro lado, meu programa bancário precisa armazenar números PIN e itens inseridos com clareza antes de criptografá-los. 1Password funciona com dados confidenciais como o meu número de segurança social. Mesmo que o programa possa eventualmente armazenar os dados criptografados - um relatório de falha pode falhar no ponto em que os dados estão sendo transformados em algo que você vê claramente na tela - uma sequência de dígitos. Basicamente, por um momento fugaz, os dados não estão protegidos.

A pergunta geral "É seguro postar?" tem que ser não , sem outras qualificações sobre os dados armazenados no aplicativo. Especialmente ao publicá-lo em algo tão público e permanente como a internet.

— bmike
fonte

ouvir, ouvir, a menos que você realmente analise todos os dados expostos e, portanto, não precise de conselhos, você realmente não terá garantias.

— ConstantineK

Você está reivindicando que os dados privados (valores da instância) vão para o Rastreio de pilha? Sei que o GUID do dispositivo faz, mas o que mais você afirma que entra em um rastreamento de pilha que é particular?

— Jason SALAZ

Não - as regras da loja de aplicativos tentam impedir esse tipo de coisa (código auto-modificável e tudo) - mas nada impede que, se o programador quiser ser criativo na codificação de dados para depuração remota. É muito improvável, mas os dados nos registros do ARM podem ser particulares. Altamente, altamente improvável - talvez eu deva editar minha resposta para ser menos forte? Eu não gostaria que meus logs de falha agregados ou a Chave CrashReporter fossem registros públicos. O relatório de falha foi intencionalmente projetado para não compartilhar dados particulares, mas os programas falham quando não se comportam conforme o planejado.

— bmike