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

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

¿Es seguro publicar registros de bloqueo de iOS en un lugar público? ¿Hay alguna PII en ellos?

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

— Conocer
fuente

Si ingresa PII en ellos, 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.

— bmike

Respuestas:

Los registros de fallos 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 los nombres de los métodos. Esto permite a los desarrolladores ver la línea exacta de código que causó el problema.

También sepa, 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 sus registros de bloqueo en el archivo original .crash. 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.

— Ben Baron
fuente

Esto no es correcto: los .crasharchivos son solo archivos de texto sin formato. Los registros de fallos copiados y pegados se pueden guardar como .crasharchivos y ver en el visor normal. No es que esto realmente tenga ninguna ventaja. El único problema potencial es la pérdida de formato cuando la copia y el pegado eliminan espacios en blanco excesivos.

— Konrad Rudolph

Al menos en mi experiencia personal, nunca he podido pegar registros de bloqueo para simbolizar en Xcode. A menos que algo haya cambiado en las nuevas versiones de Xcode para permitir esto, no funcionará. Cuando intenta pegar el contenido de un registro de bloqueo en un archivo nuevo 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.

— Ben Baron

No estoy seguro de lo que hiciste (mal) pero los .crasharchivos son solo archivos de texto. Puedes verificar esto fácilmente.

— Konrad Rudolph

Hice otra prueba con el último Xcode y simbolizaba un registro de bloqueo copiado / pegado. 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.

— Ben Baron

No tiene mucho sentido publicar un informe de bloqueo no simbólico. Contestar que es seguro si no está simbolizado es similar a decir que fumar es seguro si no enciende el cigarrillo.

— Declan McKenna

No, no es universal o inequívocamente seguro.

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

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

Yo diría que no publiques nada hasta que realmente entiendas 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 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 los números PIN y las cosas que ingreso claramente antes de encriptarlos. 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 bloquearse en el punto donde 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 en los datos almacenados en la aplicación. Especialmente cuando lo publicas en algo tan público y permanente como Internet.

— bmike
fuente

escuchar escuchar, 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.

— ConstantineK

¿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 dice que va a un seguimiento de pila que es privado?

— Jason Salaz

No, las reglas de la tienda de aplicaciones intentan evitar ese tipo de cosas (código auto modificable 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 en los registros ARM podrían ser privados. Muy, muy poco probable: ¿tal vez debería editar mi respuesta para que sea menos fuerte? No quisiera que mis registros de bloqueo agregados o la clave de CrashReporter sean registros públicos. El informe de bloqueo se diseñó intencionalmente para no compartir datos privados, pero los programas se bloquean cuando no se comportan según lo planeado.

— bmike