Envoi du rapport de bug chez Apple: confidentiel ou pas?

Si vous utilisez un Mac, vous avez déjà pu voir cette fenêtre:

 Le bouton Rapport... envoie un rapport à apple, dont le contenu est présenté dans une seconde fenêtre:

On lit qu'aucune information personnelle n'est transmise. Est-ce le cas, et peut on avoir confiance dans cette déclaration d'intention? Petit exercice technique pour s'en assurer.

0/ Préalablement: obtenir une méthode provoquant un crash d'application :-)
Je sais comment crasher à volonté le serveur X de mac OS X.5 via une méthode parfaitement reproductible; c'est suffisant.


1/ Cassons du SSL dans la joie et la bonne humeur.
L'envoi des données se fait chez https://radarsubmissions.apple.com ; étant chiffré par SSL, il est difficile d'en connaître le contenu à l'aide d'un simple tcpdump.
Je dispose d'un outil appelé mitmproxy qui permet de répondre à ce genre de problèmes. Ce proxy sait "casser" le SSL en générant à la volée un certificat du nom du site distant consulté. Il suffit alors de se positionner sur le proxy pour connaître le contenu des échanges malgré le SSL [lire ce post de blog et celui-là pour plus d'infos sur la fiabilité de SSL].
Il est toutefois nécessaire d'importer dans MacOS la CA de mitmproxy afin qu'il truste les certificats générés sans aucun warning.

J'installe donc le certificat racine, puis crash X11, et consulte la page envoyée:
headers

content-length: 12064

proxy-connection: close

host: radarsubmissions.apple.com

user-agent: SubmitReport (unknown version) CFNetwork/438.16 Darwin/9.8.0 (i386) (iMac8%2C1)

connection: close

content-type: multipart/form-data; boundary=\"Apple-Multipart-Form-Message-327837225\"

timestamp: 1306144341.509594

method: POST

content: LS1BcHBsZS1NdWx0aXBhcnQtRm9ybS1NZXNzYWd(snip le base64..)

2/ décodage des données envoyées:
Le content est en base64. Ca se décode très facilement. Nous obtenons donc un Apple-Multipart-Form-Message:
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="url_from"^M
Content-Type: text/plain^M
^M
3D2666A2-BAF0-4C1F-B163-2ED70C4EE55F^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="os_version"^M
Content-Type: text/plain^M
^M
10.5.8:9L30^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="machine_config"^M
Content-Type: text/plain^M
^M
iMac8,1 (2048 MB)^M
--Apple-Multipart-Form-Message-327837225^M
Content-Disposition: form-data; name="crashreporter_key"^M
Content-Type: text/plain^M
^M

Ceci ce lit très bien puisqu'il s'agit de texte, sauf deux champs:
Content-Disposition: form-data; name="page_source"^M
Content-Type: text/plain^M
Content-Transfer-Encoding: deflate^M
Pour décoder ce champ, il existe pleins de solutions, j'ai fait au plus simple avec zpipe.c. Ce champ correspond à l'onglet "Détails du problème" du rapport de problème.

Le second champ:

Content-Disposition: form-data; name="system_profile"^M

Content-Type: text/plain^M

Content-Transfer-Encoding: base64^M

est de nouveau du base64 qui se décode aussi très bien; on constate que le contenu est celui de l'onglet "Configuration système" du rapport de problème. Une remarque amusée sur ce champ: La configuration système est un simple texte. Ce texte est wrappé en xml, puis en base64. L'embonpoint guette :-)

3/ Tout est honnête, alors?
Eh bien il faut avouer que le SSL n'est pas employé dans le but cacher quelque chose à l'utilisateur. Le contenu de ce qui est envoyé à apple n'est ni plus ni moins que ce qui est indiqué dans la fenêtre de "Rapport de problème".

Le seul point qui me gène reste cette notion d'"Anonymous UUID". La documentation chez Apple dit que l'identifiant unique permet d'identifier de manière unique une machine sans identifier son utilisateur.

La doc du Mac reste assez muette sur cet UUID. Le programme /usr/bin/uuidgen permet de générer des UUID sans qu'ils ne soient jamais identiques à celui-ci. Cet UUID reste étonnement stable dans le temps et au travers des reboots. Je suis curieux de savoir ou cet identifiant est utilisé et ce qu'il permet de corréler comme information. Je ne pense pas qu'il soit essentiel pour apple de différencier de manière certaine les machines émettrices des rapports de problèmes. Les détails et la configuration système devrait être suffisante.