¿Es seguro publicar registros de fallas de iOS en público?

Una de las aplicaciones de iOS que uso se ha bloqueado mucho más de lo normal últimamente, así que estoy publicando sobre esto en su foro. Tengo un montón de registros de fallos.

¿Es seguro publicar registros de fallas de iOS en un lugar público? ¿Hay algún PII en ellos?

Veo muchos hashes en ellos. ¿Son completamente arbitrarios/aleatorios, o contienen mi dirección de hardware o algo así?

Si ingresa PII en ellos, entonces, por supuesto, el bloqueo podría contenerlo. No hay nada que impida que el programador acceda a los datos de la red o del dispositivo dentro de su programa, por lo que tendría que tener acceso al código fuente de la aplicación para saber si algún bloqueo en particular tendría problemas de privacidad.

Respuestas (2)

Los registros de fallas son seguros para publicar en público. No hay información de identificación sobre usted en ellos. Todo el texto de aspecto aleatorio que ve son direcciones de los diversos métodos que Xcode simboliza en nombres de métodos. Esto permite a los desarrolladores ver la línea exacta de código que causó el problema.

También tenga en cuenta que es más difícil simbolizar los registros de fallas que se han copiado y pegado. Sería más útil para los desarrolladores obtener los registros de fallos en el archivo .crash original. Parece que este ya no es el caso, no tuve problemas para copiar y pegar un registro de bloqueo y simbolizar usando el último Xcode.

Esto no es correcto: .crashlos archivos son solo archivos de texto sin formato. Los registros de fallos copiados y pegados pueden guardarse como .crasharchivos y verse en el visor normal. No es que esto realmente tenga alguna ventaja. El único problema potencial es la pérdida de formato cuando al copiar y pegar se eliminan los espacios en blanco excesivos.
Al menos en mi experiencia personal, nunca he podido pegar registros de fallas para simbolizar en Xcode. A menos que algo haya cambiado en las versiones más nuevas de Xcode para permitir esto, no funcionará. Cuando intenta pegar el contenido de un registro de bloqueo en un nuevo archivo y guardarlo como .crash, el organizador de Xcode lo ignora y debe simbolizarse a mano a través de la línea de comando, lo cual es frustrante.
No estoy seguro de lo que hizo (mal), pero los .crasharchivos son solo archivos de texto. Puedes verificar esto fácilmente.
Hice otra prueba con el último Xcode y simbolizó un registro de fallas de copiar/pegar. Así que parece que ya no es un problema, pero cuando estaba usando Xcode 3, juro que tuve problemas con cualquier registro copiado/pegado. No estoy seguro de cuál era el problema, pero no funcionaron por alguna razón.
No tiene mucho sentido publicar un informe de falla no simbolizado. Responder que es seguro si no está simbolizado es similar a decir que fumar es seguro si no enciendes el cigarrillo.

No, no es universal o inequívocamente seguro.

Cualquier programador podría guardar datos muy personales claramente, por lo que está a merced de los diseñadores y programadores para desinfectar y no exponer ningún dato personal en un bloqueo.

La seguridad por oscuridad (los valores están en hexadecimal) es bastante buena y la posibilidad de que algo sensible quede expuesto es muy baja, pero compartir un informe de bloqueo públicamente podría ser peligroso para su privacidad.

Diría que no publique nada hasta que realmente comprenda qué es un GUID de dispositivo y cómo leer un seguimiento de pila o caracteres hexadecimales. Además, su riesgo se ve directamente afectado por la naturaleza del programa. Tiny Wings no sabe nada porque yo no le he dicho nada. También es poco probable que haya escaneado mi libreta de direcciones o mi ubicación/información de contacto.

Por otro lado, mi programa bancario tiene que almacenar números PIN y cosas que ingreso claramente antes de cifrarlos. 1Password funciona con datos confidenciales como mi número de seguro social. Aunque el programa eventualmente puede almacenar los datos cifrados, un informe de bloqueo puede colapsar en el punto en que los datos se convierten en algo que se ve claramente en la pantalla: una secuencia de dígitos. Básicamente, por un momento fugaz, los datos no están protegidos.

La pregunta general "¿Es seguro publicar?" tiene que ser no sin otras calificaciones sobre los datos almacenados en la aplicación. Especialmente cuando se publica en algo tan público y permanente como Internet.

escuche escuche, a menos que realmente revise todos los datos expuestos usted mismo y, por lo tanto, no necesite el consejo, realmente no puede tener garantías.
¿Está afirmando que los datos privados (valores de instancia) van a Stack Traces? Sé que el GUID del dispositivo lo hace, pero ¿qué más afirmas que entra en un Stack Trace que es privado?
No, las reglas de la tienda de aplicaciones intentan evitar ese tipo de cosas (código automodificable y todo), pero nada lo impide si el programador quiere ser creativo en la codificación de datos para la depuración remota. Es muy poco probable, pero los datos de los registros ARM podrían ser privados. Muy, muy poco probable: ¿tal vez debería editar mi respuesta para que sea menos fuerte? No quiero que mis registros de fallas agregados o la clave de CrashReporter sean un registro público. El informe de bloqueo se diseñó intencionalmente para no compartir datos privados, pero los programas fallan cuando no se comportan según lo planeado.
¿Es seguro publicar registros de fallas de iOS en público?
RespuestasAquíPolítica de privacidad1y, 0v