« Apple suit à la trace les utilisateurs d'iPhone », « l'intolérable indiscrétion du mouchard de l'iPhone » : tout ou presque a été dit depuis la publication d'iPhoneTracker. Apple n'est pas exempte de critiques sur ce point : oui, les iPhone et iPad 3G stockent leur position dans un fichier non protégé et facile à récupérer et lire. Mais non, ce fichier n'est pas un mouchard, et il faut bien veiller à démêler le vrai du faux. Explications.
Un mouchard dans l'iPhone le jour du lancement de Skynet ?
Cette « affaire » a commencé avec la publication par le Guardian d'un article détaillant la trouvaille d'Alasdair Allen et Pete Warden, deux chercheurs en sécurité pour O'Reilly. En travaillant sur des systèmes de visualisation de la localisation, ils sont tombés par hasard sur un fichier stockant toutes les données de localisation des iPhone et iPad 3G. Ce fichier est stocké en clair, sauvegardé par iTunes et donc stocké sur Mac ou PC : ils ont donc développé iPhoneTracker, un outil permettant de le lire et d'afficher son contenu sur une carte.
« Apple permet ainsi à n'importe qui (une épouse jalouse, un détective privé…) pouvant accéder à votre iPhone ou votre ordinateur d'obtenir des informations détaillées sur les lieux dans lesquels vous vous êtes rendus » expliquait Warden, repris bien vite par la presse généraliste qui, comme la presse spécialisée, a fini par parler de mouchard. Problème : comme nous l'expliquions hier, cette découverte n'en est pas une, et ce fichier n'est pas un mouchard (lire : iPhone et iPad 3G laissent trop facilement filtrer leur position).
Consolidated.db
Le fichier en question est une base de données nommée Consolidated.db. Comme elle est stockée dans la partition utilisateur des iPhone et iPad 3G, elle est sauvegardée par iTunes et donc accessible sur PC ou sur Mac si la sauvegarde n'est pas chiffrée. Ce n'est pas la seule base de données ainsi accessible : tous vos SMS, par exemple, sont stockés dans une base de données tout aussi facilement accessible, même si votre iPhone ou iPad n'est pas jailbreaké, et à condition que votre sauvegarde ne soit pas chiffrée.
On peut utiliser un simple utilitaire (comme iPhone Backup Extractor, installation de Mono obligatoire) pour récupérer ces bases, donc cette fameuse base Consolidated.db (dans /private/var/root/Library/Caches/locationd). Elle se révèle alors être une base SQLite dont la table CellLocation contient la majeure partie des données : chaque position est enregistrée sous la forme d'une latitude et d'une longitude associées à un timestamp (date et heure de l'enregistrement à la seconde près).
Paul Courbis parlait de ce fichier en septembre 2010. Mieux encore : dès l'été 2010, c'est-à-dire dès la disponibilité d'iOS 4, Alex Levinson avait repéré Consolidated.db, au point d'en faire le sujet d'une conférence en novembre 2010, et d'en parler dans un livre sur l'informatique numérique légale appliquée à iOS un mois plus tard !
Géolocalisation : une histoire ancienne et connue
Consolidated.db est spécifique à iOS 4, mais Levinson rappelle qu'Apple enregistre depuis bien plus longtemps la localisation des appareils dotés d'une puce 3G ou CDMA. Dans les versions précédentes d'iOS et ce depuis février 2008 (lancement du SDK iPhone), la localisation était cependant enregistrée dans un fichier qui n'était accessible ni à l'utilisateur, ni aux applications, et qui ne sortait pas de l'iPhone ou de l'iPad.
Le fichier en question, h-cells.plist, était stocké dans /root/Library/caches/locationd, la partition système. Cela ne veut pas dire qu'il était particulièrement difficile d'accès : Levinson, qui travaille dans le domaine de l'informatique légale, a déjà réussi à le manipuler par le passé sans trop de problèmes. Le problème de Consolidated.db est donc bien qu'il est facile d'accès.
Trop facile d'accès ? Non : il faut avoir un accès physique à la machine de l'utilisateur ou à son smartphone pour l'extraire. Quitte à y être, autant lire son courriel, jeter un œil à son historique de navigation, et scanner son disque à la recherche de photos compromettantes. Quitte à aussi fouiller dans les bases de données contenues par une sauvegarde iPhone non chiffrée, autant extraire la base de SMS. Bref, Consolidated.db est un des symptômes d'un malaise plus grand, mais pas le malaise lui-même.
Core Location
Ne reste donc qu'un seul problème potentiel : que ce fichier soit utilisé par Apple ou ses partenaires à des fins légales, mais pas forcément sympathiques (publicité ciblée par exemple). Ce fichier est en fait utilisé à des fins internes : comme l'explique Alex Levinson, il est utilisé par Core Location, le framework qui permet aux applications d'accéder à la localisation du téléphone. Comme h-cells.plist avant lui, Consolidated.db une forme de « cache » généré automatiquement par l'iPhone ou l'iPad à intervalles réguliers (entre 1 et 10 minutes) que les applications peuvent lire pour accéder rapidement à la localisation de l'iPhone.
Avant iOS 4 et le multitâche, les applications n'avaient besoin de la localisation que lorsqu'elles étaient à l'avant-plan : le fichier h-cells.plist, dans la partition système, suffisait donc. Avec iOS 4 et le multitâche, les applications peuvent désormais utiliser la localisation en arrière-plan : parce qu'Apple a changé certaines de ses APIs et met les applications dans un bac à sable, ce cache de la localisation devait être déplacé dans la partition utilisateur.
Core Location peut être utilisé de deux manières par les applications : par défaut, les applications ayant besoin de connaître la position de l'iPhone n'utilisent que la triangulation cellulaire et WiFi ; celles qui ont besoin d'une grande précision (logiciels de navigation) peuvent en plus demander à utiliser le GPS. La structure de la base Consolidated.db le reflète : les tables CellLocation et CDMACellLocation stockent les données de triangulation cellulaire (réseaux GSM/UMTS et CDMA), la table WiFiLocation stocke les données de triangulation WiFi.
Ces données ne sont pas toujours fiables : si vous avez utilisé iPhoneTracker, vous aurez remarqué que les positions qu'il liste sont parfois fantaisistes. Par défaut, il n'utilise que les données de triangulation cellulaire, en les simplifiant d'ailleurs pour éviter d'être transformé en outil d'espionnage. Son code étant librement disponible, nous l'avons modifié pour qu'il prenne en compte les données de la triangulation WiFi : il devient alors bien plus précis.
Nous n'avons par contre jamais été en mesure d'utiliser les données de la triangulation GPS, qui permettraient d'obtenir des données précises au mètre près. La base Consolidated.db contient une table Location qui pourrait contenir les données GPS, mais celle-ci est vide, même après avoir utilisé des applications utilisant bien le GPS. Il semble donc que Consolidated.db n'enregistre pas les positions GPS (Will Clarke n'a semble-t-il pas non plus réussi à trouver ces données, ce qui semble confirmer notre hypothèse). Cela semble logique : si une application a besoin du GPS, c'est qu'elle a besoin de données précises mises à jour en temps réel, et pas de données mises en cache.
Nous avons par contre remarqué que la base de données continue à être remplie même si les services de localisation sont désactivés, ce qui confirme que c'est iOS lui-même qui effectue ses relevés à intervalles réguliers (de 1 à 10 minutes).
Apple et la géolocalisation : cartes sur table
Mais de mouchard il n'y a pas. On peut difficilement reprocher à Apple de ne pas être transparente au sujet de son utilisation des données de géolocalisation. Elle précise ainsi dans le contrat de licence de logiciel iPhone :
On rappelle sans se faire d'illusions que tout utilisateur est censé avoir lu ce contrat avant de l'accepter, et que ce contrat est d'ailleurs disponible en ligne, le paragraphe ci-dessus étant situé à la page 18. C'est d'ailleurs en publiant la mise à jour de ces conditions à l'occasion de la sortie d'iOS 4 qu'Apple s'est fait épingler (à raison) par le Congrès américain (lire : Apple collecte vos infos de localisation : le Congrès US n'apprécie pas).
Apple précise en effet qu'elle collecte une partie des données de géolocalisation, les anonymise et les transmet à ses serveurs pour « améliorer les produits et services basés sur la géolocalisation ». Comme Google avec Android, Apple se sert d'iOS pour scanner les SSIDs des réseaux WiFi environnants pour améliorer sa base de données de triangulation WiFi. Elle le fait depuis avril 2010, puisqu'elle utilisait auparavant la base de données de Skyhook pour cette fonction.
Ces données sont envoyées deux fois par jour en utilisant un identifiant aléatoire changé toutes les 24 heures et en empêchant toute forme d'identification personnelle (lire : Collecte des données : Apple s'explique). La firme de Cupertino est susceptible de transmettre ces données à ses partenaires, mais elle ne l'a pour le moment fait qu'avec Google et Skyhook.
Apple collecte aussi certaines données de localisation pour son service de publicité iAd. Cette fois, Apple ne stocke pas la position en base de données : elle déduit de la localisation un code postal, qu'elle stocke, là encore en anonymisant les résultats. Les données ne sont conservées que six mois pour « administrer et améliorer le réseau iAd », puis étêtées.
Dans les deux cas, les données ne sont pas transmises en temps réel. Apple ne pourrait d'ailleurs pas le faire sans tomber dans l'illégalité : la loi californienne, applicable dans le cas d'Apple, interdit « l'utilisation d'un appareil électronique de suivi pour déterminer l'emplacement ou les mouvements d'une personne », sauf si l'utilisateur lui-même a demandé à être localisé (code pénal californien, section 637.7).
Ni Allen, ni Warden, ni Levinson n'ont jamais vu Consolidated.db être transmis à des serveurs externes : l'hypothèse du mouchard tombe. Cela ne veut pas dire que l'on ne puisse pas critiquer Apple quant à son utilisation des informations de localisation à des fins commerciales, comme le prouvent les deux points soulevés ci-dessus. Mais il s'agit alors d'un tout autre débat.
Les cartes, les cartes, les cartes
Comment donc interpréter cette réaction épidermique face à cette « découverte » ? Le cartographe Brian Harley parlait du « pouvoir des cartes », et il y a sans doute de cela. La collecte des données de localisation par Apple n'est en effet ni nouvelle ni particulièrement secrète, mais l'affichage de ces données sur une carte a une certaine force « pédagogique » qui a certainement permis une prise de conscience chez des gens qui l'ignoraient.
Alors que de plus en plus de services pistent divers aspects touchant à la vie privée de leurs utilisateurs pour des motifs divers, Consolidated.db peut apparaître comme une goutte d'eau chez certains. Mais les faits sont là : cette base de données est une fonction d'iOS et non un mouchard, et une fonction qui ferait hurler les mêmes utilisateurs si elle n'était pas présente.
Cela ne veut pas dire qu'il faille accepter que cette base de données contienne tant de données (tout l'historique alors qu'elle pourrait effacer les traces plus anciennes — ce n'est peut-être pas un hasard si les experts en informatique légale la connaissent si bien), et encore moins qu'elle soit exploitable sur Mac sans que l'iPhone ne soit branché. C'est là un des aspects pervers de la sauvegarde complète des appareils iOS, avec dans le lot des données assez sensibles transmises sans chiffrement. Il est bien entendu possible de chiffre sa sauvegarde d'iPhone ou d'iPad, ce que nous vous conseillons d'ailleurs de faire.
Mais alors qu'Apple entend préserver la vie privée de ses utilisateurs et pénétrer le marché de l'entreprise, elle aurait peut-être tout intérêt à renforcer la sécurité de son mécanisme de sauvegarde, qui est finalement le seul point véritablement important dans toute cette affaire.
[MàJ@17h40] John Gruber, traditionnellement (très) bien informé (lire : directement par des ingénieurs Apple) confirme que Consolidated.db est bien une base de données de cache pour Core Location.
Il qualifie cependant le fait que cette base de données conserve tout l'historique de géolocalisation de « bogue » : « l'historique de localisation devrait être supprimé mais ne l'est pas, soit que ce soit un bogue ou plus probablement un oubli. Quelqu'un a dû écrire le code pour mettre en cache les données de localisation mais n'a jamais écrit le code pour supprimer les données les plus anciennes — ce qui était censé être une base de données de vos positions récentes devient un historique complet de votre localisation. »
Pour lui, aucun doute : Consolidated.db sera toujours là dans la prochaine mise à jour d'iOS car c'est une fonction importante, mais il perdra la mémoire plus facilement. On ne s'en plaindra pas, bien au contraire.
Image (cc) Matt Gibson
Un mouchard dans l'iPhone le jour du lancement de Skynet ?
Cette « affaire » a commencé avec la publication par le Guardian d'un article détaillant la trouvaille d'Alasdair Allen et Pete Warden, deux chercheurs en sécurité pour O'Reilly. En travaillant sur des systèmes de visualisation de la localisation, ils sont tombés par hasard sur un fichier stockant toutes les données de localisation des iPhone et iPad 3G. Ce fichier est stocké en clair, sauvegardé par iTunes et donc stocké sur Mac ou PC : ils ont donc développé iPhoneTracker, un outil permettant de le lire et d'afficher son contenu sur une carte.
« Apple permet ainsi à n'importe qui (une épouse jalouse, un détective privé…) pouvant accéder à votre iPhone ou votre ordinateur d'obtenir des informations détaillées sur les lieux dans lesquels vous vous êtes rendus » expliquait Warden, repris bien vite par la presse généraliste qui, comme la presse spécialisée, a fini par parler de mouchard. Problème : comme nous l'expliquions hier, cette découverte n'en est pas une, et ce fichier n'est pas un mouchard (lire : iPhone et iPad 3G laissent trop facilement filtrer leur position).
Consolidated.db
Le fichier en question est une base de données nommée Consolidated.db. Comme elle est stockée dans la partition utilisateur des iPhone et iPad 3G, elle est sauvegardée par iTunes et donc accessible sur PC ou sur Mac si la sauvegarde n'est pas chiffrée. Ce n'est pas la seule base de données ainsi accessible : tous vos SMS, par exemple, sont stockés dans une base de données tout aussi facilement accessible, même si votre iPhone ou iPad n'est pas jailbreaké, et à condition que votre sauvegarde ne soit pas chiffrée.
Si la sauvegarde n'est pas chiffrée, un simple utilitaire permet d'extraire la fameuse base de données en question.
On peut utiliser un simple utilitaire (comme iPhone Backup Extractor, installation de Mono obligatoire) pour récupérer ces bases, donc cette fameuse base Consolidated.db (dans /private/var/root/Library/Caches/locationd). Elle se révèle alors être une base SQLite dont la table CellLocation contient la majeure partie des données : chaque position est enregistrée sous la forme d'une latitude et d'une longitude associées à un timestamp (date et heure de l'enregistrement à la seconde près).
Paul Courbis parlait de ce fichier en septembre 2010. Mieux encore : dès l'été 2010, c'est-à-dire dès la disponibilité d'iOS 4, Alex Levinson avait repéré Consolidated.db, au point d'en faire le sujet d'une conférence en novembre 2010, et d'en parler dans un livre sur l'informatique numérique légale appliquée à iOS un mois plus tard !
Géolocalisation : une histoire ancienne et connue
Consolidated.db est spécifique à iOS 4, mais Levinson rappelle qu'Apple enregistre depuis bien plus longtemps la localisation des appareils dotés d'une puce 3G ou CDMA. Dans les versions précédentes d'iOS et ce depuis février 2008 (lancement du SDK iPhone), la localisation était cependant enregistrée dans un fichier qui n'était accessible ni à l'utilisateur, ni aux applications, et qui ne sortait pas de l'iPhone ou de l'iPad.
La table CellLocation de la base de données : on y croise latitude, longitude et timestamp.
Le fichier en question, h-cells.plist, était stocké dans /root/Library/caches/locationd, la partition système. Cela ne veut pas dire qu'il était particulièrement difficile d'accès : Levinson, qui travaille dans le domaine de l'informatique légale, a déjà réussi à le manipuler par le passé sans trop de problèmes. Le problème de Consolidated.db est donc bien qu'il est facile d'accès.
Trop facile d'accès ? Non : il faut avoir un accès physique à la machine de l'utilisateur ou à son smartphone pour l'extraire. Quitte à y être, autant lire son courriel, jeter un œil à son historique de navigation, et scanner son disque à la recherche de photos compromettantes. Quitte à aussi fouiller dans les bases de données contenues par une sauvegarde iPhone non chiffrée, autant extraire la base de SMS. Bref, Consolidated.db est un des symptômes d'un malaise plus grand, mais pas le malaise lui-même.
Core Location
Ne reste donc qu'un seul problème potentiel : que ce fichier soit utilisé par Apple ou ses partenaires à des fins légales, mais pas forcément sympathiques (publicité ciblée par exemple). Ce fichier est en fait utilisé à des fins internes : comme l'explique Alex Levinson, il est utilisé par Core Location, le framework qui permet aux applications d'accéder à la localisation du téléphone. Comme h-cells.plist avant lui, Consolidated.db une forme de « cache » généré automatiquement par l'iPhone ou l'iPad à intervalles réguliers (entre 1 et 10 minutes) que les applications peuvent lire pour accéder rapidement à la localisation de l'iPhone.
Les points relevés par notre iPhone le 29 mars 2011. Les lieux précis dans lesquels nous sommes allés ne sont pas listés, mais les points sont autour.
Avant iOS 4 et le multitâche, les applications n'avaient besoin de la localisation que lorsqu'elles étaient à l'avant-plan : le fichier h-cells.plist, dans la partition système, suffisait donc. Avec iOS 4 et le multitâche, les applications peuvent désormais utiliser la localisation en arrière-plan : parce qu'Apple a changé certaines de ses APIs et met les applications dans un bac à sable, ce cache de la localisation devait être déplacé dans la partition utilisateur.
La carte ressemble en fait à deux gouttes d'eau à celle des antennes-relais dans le quartier, plus quelques bornes WiFi, dont les SSIDs sont d'ailleurs stockés dans un champ.
Core Location peut être utilisé de deux manières par les applications : par défaut, les applications ayant besoin de connaître la position de l'iPhone n'utilisent que la triangulation cellulaire et WiFi ; celles qui ont besoin d'une grande précision (logiciels de navigation) peuvent en plus demander à utiliser le GPS. La structure de la base Consolidated.db le reflète : les tables CellLocation et CDMACellLocation stockent les données de triangulation cellulaire (réseaux GSM/UMTS et CDMA), la table WiFiLocation stocke les données de triangulation WiFi.
Ces données ne sont pas toujours fiables : si vous avez utilisé iPhoneTracker, vous aurez remarqué que les positions qu'il liste sont parfois fantaisistes. Par défaut, il n'utilise que les données de triangulation cellulaire, en les simplifiant d'ailleurs pour éviter d'être transformé en outil d'espionnage. Son code étant librement disponible, nous l'avons modifié pour qu'il prenne en compte les données de la triangulation WiFi : il devient alors bien plus précis.
iPhoneTracker modifié pour lire les données de triangulation WiFi et ne pas simplifier la précision.
Nous n'avons par contre jamais été en mesure d'utiliser les données de la triangulation GPS, qui permettraient d'obtenir des données précises au mètre près. La base Consolidated.db contient une table Location qui pourrait contenir les données GPS, mais celle-ci est vide, même après avoir utilisé des applications utilisant bien le GPS. Il semble donc que Consolidated.db n'enregistre pas les positions GPS (Will Clarke n'a semble-t-il pas non plus réussi à trouver ces données, ce qui semble confirmer notre hypothèse). Cela semble logique : si une application a besoin du GPS, c'est qu'elle a besoin de données précises mises à jour en temps réel, et pas de données mises en cache.
Nous avons par contre remarqué que la base de données continue à être remplie même si les services de localisation sont désactivés, ce qui confirme que c'est iOS lui-même qui effectue ses relevés à intervalles réguliers (de 1 à 10 minutes).
Apple et la géolocalisation : cartes sur table
Mais de mouchard il n'y a pas. On peut difficilement reprocher à Apple de ne pas être transparente au sujet de son utilisation des données de géolocalisation. Elle précise ainsi dans le contrat de licence de logiciel iPhone :
« Apple, ainsi que ses partenaires et titulaires de licence, peuvent vous fournir certains services basés sur des informations géographiques via l’iPhone. Pour fournir et améliorer ces services, lorsqu’ils sont disponibles, Apple, ainsi que ses partenaires et titulaires de licence, peuvent transmettre, recueillir, conserver, traiter et utiliser les données concernant votre localisation, notamment la position géographique en temps réel de votre iPhone et des demandes de recherche de localisation.
Les données et demandes de localisation sont recueillies par Apple dans un formulaire qui ne vous identifie pas personnellement et peuvent être utilisées par Apple, ainsi que par ses partenaires et titulaires de licence, pour fournir et améliorer des produits et services géodépendants. En utilisant sur votre iPhone l’un des quelconques services gérant la localisation, vous acceptez qu’Apple, ainsi que ses partenaires et titulaires de licence, transmettent, recueillent, conservent, traitent et utilisent les données concernant votre localisation pour vous fournir lesdits produits et services et les améliorer. »
On rappelle sans se faire d'illusions que tout utilisateur est censé avoir lu ce contrat avant de l'accepter, et que ce contrat est d'ailleurs disponible en ligne, le paragraphe ci-dessus étant situé à la page 18. C'est d'ailleurs en publiant la mise à jour de ces conditions à l'occasion de la sortie d'iOS 4 qu'Apple s'est fait épingler (à raison) par le Congrès américain (lire : Apple collecte vos infos de localisation : le Congrès US n'apprécie pas).
Apple précise en effet qu'elle collecte une partie des données de géolocalisation, les anonymise et les transmet à ses serveurs pour « améliorer les produits et services basés sur la géolocalisation ». Comme Google avec Android, Apple se sert d'iOS pour scanner les SSIDs des réseaux WiFi environnants pour améliorer sa base de données de triangulation WiFi. Elle le fait depuis avril 2010, puisqu'elle utilisait auparavant la base de données de Skyhook pour cette fonction.
Ces données sont envoyées deux fois par jour en utilisant un identifiant aléatoire changé toutes les 24 heures et en empêchant toute forme d'identification personnelle (lire : Collecte des données : Apple s'explique). La firme de Cupertino est susceptible de transmettre ces données à ses partenaires, mais elle ne l'a pour le moment fait qu'avec Google et Skyhook.
Apple collecte aussi certaines données de localisation pour son service de publicité iAd. Cette fois, Apple ne stocke pas la position en base de données : elle déduit de la localisation un code postal, qu'elle stocke, là encore en anonymisant les résultats. Les données ne sont conservées que six mois pour « administrer et améliorer le réseau iAd », puis étêtées.
Dans les deux cas, les données ne sont pas transmises en temps réel. Apple ne pourrait d'ailleurs pas le faire sans tomber dans l'illégalité : la loi californienne, applicable dans le cas d'Apple, interdit « l'utilisation d'un appareil électronique de suivi pour déterminer l'emplacement ou les mouvements d'une personne », sauf si l'utilisateur lui-même a demandé à être localisé (code pénal californien, section 637.7).
Ni Allen, ni Warden, ni Levinson n'ont jamais vu Consolidated.db être transmis à des serveurs externes : l'hypothèse du mouchard tombe. Cela ne veut pas dire que l'on ne puisse pas critiquer Apple quant à son utilisation des informations de localisation à des fins commerciales, comme le prouvent les deux points soulevés ci-dessus. Mais il s'agit alors d'un tout autre débat.
Les cartes, les cartes, les cartes
Comment donc interpréter cette réaction épidermique face à cette « découverte » ? Le cartographe Brian Harley parlait du « pouvoir des cartes », et il y a sans doute de cela. La collecte des données de localisation par Apple n'est en effet ni nouvelle ni particulièrement secrète, mais l'affichage de ces données sur une carte a une certaine force « pédagogique » qui a certainement permis une prise de conscience chez des gens qui l'ignoraient.Alors que de plus en plus de services pistent divers aspects touchant à la vie privée de leurs utilisateurs pour des motifs divers, Consolidated.db peut apparaître comme une goutte d'eau chez certains. Mais les faits sont là : cette base de données est une fonction d'iOS et non un mouchard, et une fonction qui ferait hurler les mêmes utilisateurs si elle n'était pas présente.
Cela ne veut pas dire qu'il faille accepter que cette base de données contienne tant de données (tout l'historique alors qu'elle pourrait effacer les traces plus anciennes — ce n'est peut-être pas un hasard si les experts en informatique légale la connaissent si bien), et encore moins qu'elle soit exploitable sur Mac sans que l'iPhone ne soit branché. C'est là un des aspects pervers de la sauvegarde complète des appareils iOS, avec dans le lot des données assez sensibles transmises sans chiffrement. Il est bien entendu possible de chiffre sa sauvegarde d'iPhone ou d'iPad, ce que nous vous conseillons d'ailleurs de faire.
Mais alors qu'Apple entend préserver la vie privée de ses utilisateurs et pénétrer le marché de l'entreprise, elle aurait peut-être tout intérêt à renforcer la sécurité de son mécanisme de sauvegarde, qui est finalement le seul point véritablement important dans toute cette affaire.
[MàJ@17h40] John Gruber, traditionnellement (très) bien informé (lire : directement par des ingénieurs Apple) confirme que Consolidated.db est bien une base de données de cache pour Core Location.
Il qualifie cependant le fait que cette base de données conserve tout l'historique de géolocalisation de « bogue » : « l'historique de localisation devrait être supprimé mais ne l'est pas, soit que ce soit un bogue ou plus probablement un oubli. Quelqu'un a dû écrire le code pour mettre en cache les données de localisation mais n'a jamais écrit le code pour supprimer les données les plus anciennes — ce qui était censé être une base de données de vos positions récentes devient un historique complet de votre localisation. »
Pour lui, aucun doute : Consolidated.db sera toujours là dans la prochaine mise à jour d'iOS car c'est une fonction importante, mais il perdra la mémoire plus facilement. On ne s'en plaindra pas, bien au contraire.
