iCloud : l'historique de Safari était parfois conservé pendant plus d'un an

iCloud : l’historique de Safari était parfois conservé pendant plus d’un an

Ninja strike

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

13/02/2017 4 minutes
32

iCloud : l'historique de Safari était parfois conservé pendant plus d'un an

iCloud conservait jusqu’à récemment un historique de navigation de Safari sur plus d’un an, au lieu des 30 jours prévus. Même si ces informations n’étaient pas stockées en clair, elles posent la question de leur utilité et d’éventuelles pratiques dont l’utilisateur ne serait pas informé.

iCloud est le service de synchronisation d’Apple. Il agit comme réceptacle des données de l’utilisateur et permet leur réplication et leur diffusion à travers les appareils reliés au même compte. S’il crée une note ou stocke des photos, les iPhone, iPad et autres Mac les affichent également, à moins bien sûr que tout ou partie des options aient été désactivées. Parmi ces informations, on trouve l’historique de Safari.

Cet historique est normalement sauvegardé pendant 30 jours, avant que les éléments les plus anciens ne commencent à être supprimés, via un classique mécanisme de roulement. La synchronisation permet à tous les appareils d’avoir le même historique, donc de ne pas perdre les habitudes de navigation. On trouve le même genre de fonctionnalité dans tous les navigateurs aujourd’hui. Sauf que dans le cas de Safari, il était possible de remonter jusqu’à plus d’un an en arrière.

Les données existaient dans une liste séparée

C’est la société russe Elcomsoft – éditrice de solutions logicielles pour récupérer les données protégées dans les appareils iOS – qui a fait la découverte. Son PDG Vladimir Katalov a ainsi expliqué qu’il avait pu retrouver des éléments d’historique remontant à décembre 2015. Les liens effacés, soit par le roulement automatique, soit manuellement, étaient ainsi toujours présents, mais avec un statut spécial.

Ces informations ne sont cependant pas accessibles de manière « naturelle ». Vladimir Katalov s’est en effet servi du logiciel maison Phone Breaker pour les obtenir. Ce dernier a d’ailleurs été mis à jour pour tenir compte de la découverte. Le PDG a fait part de sa découverte à Forbes, le journaliste Thomas Fox-Brewster confirmant la découverte : il avait retrouvé de son côté près de 7 000 liens censément effacés, mais bien présents dans un historique détaché, nommé a priori « tombstone ».

phone breaker ios historique safari icloud
Crédits : Elcomsoft

Les historiques ont été purgés

Se pose évidemment la question du « pourquoi » sur une telle rétention d’informations. Selon Forbes, il pourrait s'agir d'une erreur. D’ailleurs, peu de temps après la parution de l’article de Forbes, les comptes iCloud qui avaient été inspectés ont commencé à voir leur historique purgé. Apple n’avait pas encore répondu aux questions du magazine et ne l’a toujours pas fait à l’heure actuelle.

En fait, le contenu de « tombstone » ne devrait en théorie pas dépasser quelques semaines. Il est utilisé par Apple pour synchroniser la liste des éléments à supprimer sur les appareils reliés par le même compte. Il pourrait donc s’agir d’un « bug », la société le corrigeant actuellement sur l'ensemble des comptes concernés.

Un véritable flou

Selon une source de Forbes, en effet, effacer l’historique manuellement ou automatiquement transforme aussi tôt les liens en « hash ». Vladimir Katalov n’est pas d’accord. Selon lui, les informations sont chiffrées via AES, mais les clés sont stockées avec les données. En outre, iOS 9.3 est censé avoir géré justement un problème de données accessibles en clair, mais Elcomsoft a pu utiliser son Phone Breaker sur iOS 10.2.1.

Apple n’ayant toujours pas réagi, il est impossible de savoir si les historiques renégats ont été réellement supprimés ou simplement déplacés dans une zone hors d’atteinte. On ne peut pas savoir non plus s’il s’agissait réellement d’un bug ou d’un fonctionnement voulu. Les révélations d’Edward Snowden ont jeté un flou sur les grands services en ligne, et même si beaucoup d'éditeurs – Apple en tête – se démènent sur le vaste terrain de la sécurité et de la vie privée, ce type de découverte alimente la méfiance de nombreux utilisateurs. 

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les données existaient dans une liste séparée

Les historiques ont été purgés

Un véritable flou

Commentaires (32)


Beaucoup d’humour chez la Pomme

Dénommer cette sauvegarde “Pierre tombale” ;)


Lol. Excuse en mousse.

“On attend pour effacer, le temps de synchroniser ce qu’on doit effacer”…



C’est si compliqué de faire une routine qui efface ce qui est anterieur a une certaine date, sur tous les devices ?




et même si beaucoup d’éditeurs – Apple en tête – se démènent sur le

vaste terrain de la sécurité et de la vie privée, ce type de découverte

alimente la méfiance de nombreux utilisateurs.





Ceux qui défendent Apple sur ce terrain sont assez naïfs.<img data-src=" />


Apple n’ayant toujours pas réagi, il est impossible de savoir si les historiques renégats ont été réellement supprimés ou simplement déplacés dans une zone hors d’atteinte.



Hum, désolé mais quoi que dise Apple vous n’aurez la certitude d’absolument rien de plus (si ce n’est qu’ils auront réagi, certes).








Drepanocytose a écrit :



Lol. Excuse en mousse.

“On attend pour effacer, le temps de synchroniser ce qu’on doit effacer”…



C’est si compliqué de faire une routine qui efface ce qui est anterieur a une certaine date, sur tous les devices ?





Clairement ???? Absolument pas.<img data-src=" />



C’est surtout étonnant que ça ait pris autant de temps à être découvert !


Pour l’instant ils ne sont pas expliqué donc n’allons pas non plus interpréter.



Le plus important est de savoir si c’est intentionnel ou non et l’objectif de cette conservation dans le premier cas.








Drepanocytose a écrit :



Lol. Excuse en mousse.

“On attend pour effacer, le temps de synchroniser ce qu’on doit effacer”…



C’est si compliqué de faire une routine qui efface ce qui est anterieur a une certaine date, sur tous les devices ?







Je ne défends pas Apple, juste montrer que c’est pas si simple. Dans ton exemple, ca ne fonctionne pas. Tu supprimes tout l’historique avant une date. Mais que ce passe t’il si tu veux supprimer juste 1 entrée.



Si sur l’iphone tu supprime 1 entrée de ton historique, elle qu’elle est supprimée de icloud comme tu le préconise.



Alors sur le mac, qd il va comparer son historique avec icloud, comment savoir si il doit supprimer l’entrée de l’historique du mac, ou bien s’il doit ajouter l’entrée manquante dans icloud…



C’est pas si simple, et c’est un problème qui arrive dès que tu veux “synchroniser de l’asynchrone”.



Bon y a une solution, qui est celle relaté par Forbes, qui dit que la ligne d’historique est “hashée” (donc difficilement reversible) et marqué comme “deleted”. Du coup, le mac peut comparé les hash de ses entrées et voir si il doit supprimer ou non ses entrées.



Bah comme partout, effacer revient à passer le flag “shown_to_customer” de 1 à 0…


Ca représente quand même du volume de données, toutes ces petites sauvegardes.



Personne aux commandes pour faire des économies d'échelle. A coup de millions voire de millards de comptes iCloud, ça représente quelques dollars quand même? Sans compter les sauvegardes.

Firefox et windows quand j’efface l’historique avec cc cleaner,reste t’il des trace sur un cloud? Question très performante je sais ^^


On sait faire du traitement beaucoup plus lourd sur des fichiers que de les effacer si + de 30 jours. Par exemple,&nbsp; chez Google.

<img data-src=" />








kurgan187 a écrit :



Firefox et windows quand j’efface l’historique avec cc cleaner,reste t’il des trace sur un cloud? Question très performante je sais ^^





Apparemment Firefox (Sync) se contente de répliquer le profil local sur les différentes machines (pas de sauvegarde chez eux si on en croit leurs explications



Pour Windows, ça doit dépendre de si tu ouvres ta session via un compte MS (auquel cas c’est probable) ou si c’est un compte local (auquel cas je dirais que non)









Ricard a écrit :



On sait faire du traitement beaucoup plus lourd sur des fichiers que de les effacer si + de 30 jours. Par exemple,&nbsp; chez Google.

<img data-src=" />





Ah ouais quand même…

Mais du coup il ne sont plus hébergeurs là, non?&nbsp;



Ce n’est pas très lourd comme traitement de tester un hash.

Et si le fichier devait être partagé, ils ont bien raison de s’éviter une éventuelle demande de retrait en évitant sa publication.


C’est un peu bancal comme manière de faire non ? Suffit de changer les meta-data du fichier en question pour modifier le hash par exemple.


ça dépend de la méthode de hash, si c’est un hash unique sur le fichier oui changer les métadonnées le rend indétectable.



si c’est du piece-wise hashing et qu’on détecte que le fichier est à plus de 90% identique à un fichier connu piraté, faudra changer plus que quelques métadonnées ^^








jackjack2 a écrit :



Ah ouais quand même…

Mais du coup il ne sont plus hébergeurs là, non?





Pas vraiment. Le système de Google présenté dans le lien t’empêche d’uploader du contenu flaggé. Il n’édite (i.e modifie le contenu ou sa présentation) pas au sens strict.



Après ça dépendra aussi de combien de temps l’excuse du saint algorithme neutre tiendra pour garantir ce statut…







fred42 a écrit :



Ce n’est pas très lourd comme traitement de tester un hash.

Et si le fichier devait être partagé, ils ont bien raison de s’éviter une éventuelle demande de retrait en évitant sa publication.





voila. Comme ils l’indiquent, ils “ne font que” faire respecter leurs CGU







Liara T’soni a écrit :



C’est un peu bancal comme manière de faire non ? Suffit de changer les meta-data du fichier en question pour modifier le hash par exemple.





auquel cas il suffit d’appliquer le hash de telle sorte qu’il ne prenne pas en compte les méta-data (il y a pas mal de vidéo sur youtube où l’image est zoomée et le son accélérer ou ralenti pour éviter le bot de nettoyage qui marche sur un principe similaire)



J’espère pour eux qu’ils sont indemnisés par les ayant droit parce que le coût en matos et traitement du bousin doit être colossal !








WereWindle a écrit :



Pas vraiment. Le système de Google présenté dans le lien t’empêche d’uploader du contenu flaggé. Il n’édite (i.e modifie le contenu ou sa présentation) pas au sens strict.



Après ça dépendra aussi de combien de temps l’excuse du saint algorithme neutre tiendra pour garantir ce statut…





Modérer au sens censurer suffit à te faire perdre ton statut d’hébergeur il me semble

Ici c’est bien ce qu’ils font d’après moi



Par exemple :http://www.village-justice.com/articles/Affaire-TF1-Dailymotion-sur-statut,18516…



Pour l’essentiel, la cour confirme la&nbsp;qualité d’hébergeur de la SA Dailymotion&nbsp;en rappelant que son rôle passif implique l’absence de connaissance et de contrôle a priori des données stockées.&nbsp;

&nbsp;Ce qui sous-entend qu’en cas de connaissance/contrôle a priori, la qualité d’hébergeur est refusée









Liara T’soni a écrit :



C’est un peu bancal comme manière de faire non ? Suffit de changer les meta-data du fichier en question pour modifier le hash par exemple.





Oui, ou de le zipper par exemple.









fred42 a écrit :



Ce n’est pas très lourd comme traitement de tester un hash.

Et si le fichier devait être partagé, ils ont bien raison de s’éviter une éventuelle demande de retrait en évitant sa publication.





J’ai pas dit que c’était lourd, j’ai dit que ça l’était plus que de comparer deux dates. Sans oublier la question d’échelle. G-Drive, c’est autre chose qu’iCloud, niveau volume de données.

Je note au passage que pour toi le secret des correspondances est superfétatoire, et que tu es pour le DPI.



Merci des precisions








Ricard a écrit :



Je note au passage que pour toi le secret des correspondances est superfétatoire, et que tu es pour le DPI.





Merci de ne pas me faire dire ce que je n’ai pas dit.

Nul besoin de DPI pour faire un hash lors d’un upload et le secret des correspondances n’est pas violé dans le calcul d’un hash, surtout que le partage depuis G-drive est soumis au respect des CGU.



Mais on sait tout que tu n’apprécies pas google, cela ne doit pas t’empêcher d’éviter les outrances dans tes propos.









jackjack2 a écrit :



Modérer au sens censurer suffit à te faire perdre ton statut d’hébergeur il me semble

Ici c’est bien ce qu’ils font d’après moi



Par exemple :http://www.village-justice.com/articles/Affaire-TF1-Dailymotion-sur-statut,18516…

 Ce qui sous-entend qu’en cas de connaissance/contrôle a priori, la qualité d’hébergeur est refusée





Tu compares un peu des choux et des carottes là. Dailymotion et Google Drive ont des activités radicalement différentes. Si tu as une affaire similaire mais impliquant cette fois un véritable hébergeur (Dailymotion et Youtube sont vraiment sur le fil entre les deux notions - hébergeur et éditeur - voire se promène d’un côté ou de l’autre selon le cas…) ça m’intéresse.

(Question bonus, par pure curiosité : si on upload un truc copyrighté sur youtube, il nous jette direct ou le fichier est-il supprimé/rendu indisponible dans les secondes/minutes/jours qui suivent ? Dit autrement, c’est une barrière à l’entrée ou un nettoyage après upload ?)



NB : je prends G-Drive et Youtube mais c’est interchangeable avec n’importe qui. Je prends Google Alphabet parce que c’est le plus gros et qu’il fait les deux…



Edit NB 2 : “amusant” comme les questions qu’on se pose là ressemblent aux problématiques du TES… identité (juste un hash) VS identification

NB 3 : on est HS à mort <img data-src=" />









WereWindle a écrit :



Tu compares un peu des choux et des carottes là. Dailymotion et Google Drive ont des activités radicalement différentes. Si tu as une affaire similaire mais impliquant cette fois un véritable hébergeur (Dailymotion et Youtube sont vraiment sur le fil entre les deux notions - hébergeur et éditeur - voire se promène d’un côté ou de l’autre selon le cas…) ça m’intéresse.

(Question bonus, par pure curiosité : si on upload un truc copyrighté sur youtube, il nous jette direct ou le fichier est-il supprimé/rendu indisponible dans les secondes/minutes/jours qui suivent ? Dit autrement, c’est une barrière à l’entrée ou un nettoyage après upload ?)



NB : je prends G-Drive et Youtube mais c’est interchangeable avec n’importe qui. Je prends Google Alphabet parce que c’est le plus gros et qu’il fait les deux…



Edit NB 2 : “amusant” comme les questions qu’on se pose là ressemblent aux problématiques du TES… identité (juste un hash) VS identification

NB 3 : on est HS à mort <img data-src=" />





Je n’ai pas d’autre exemple mais je ne vois pas en quoi des activités différentes donnent des lectures différentes de la LCEN

J’y vois juste des mentions à des services de communication au public

Après je suis loin d’être calé sur ces choses-là, je serais heureux d’apprendre mais là je vois pas



Pour la question Youtube, je sais au moins pour l’utilisation de bande son : ils font des vérif régulièrement donc ils te laissent uploader et en quelques heures ton contenu est purgé de son son (Véronique n’approuve pas)

&nbsp;

Et oui, léger HS <img data-src=" />









fred42 a écrit :



Merci de ne pas me faire dire ce que je n’ai pas dit.

Nul besoin de DPI pour faire un hash lors d’un upload et le secret des correspondances n’est pas violé dans le calcul d’un hash, surtout que le partage depuis G-drive est soumis au respect des CGU.



Mais on sait tout que tu n’apprécies pas google, cela ne doit pas t’empêcher d’éviter les outrances dans tes propos.





Calculer le hash d’un fichier, afin de le comparer à un autre dans ses bbd, c’est savoir exactement ce que le client partage/envoie comme fichier. Google n’a pas à savoir ce que tu partages. Secret des correspondances.

&nbsp;Le respect des CGU, ça reste à voir, surtout si celles-ci ne respectent pas les lois françaises. Les CGU sont (très) souvent illégales.

&nbsp;



Google Chrome la corbeille Gmail :



“les messages se trouvant dans la corbeille depuis plus de 30 jours sont automatiquement supprimés”



pourtant en vérifiant les plus anciens datent de plus d’un an








popolski a écrit :



Google Chrome la corbeille Gmail :



“les messages se trouvant dans la corbeille depuis plus de 30 jours sont automatiquement supprimés”



pourtant en vérifiant les plus anciens datent de plus d’un an





c’est des jours comptés en ‘minutes Windows’ spourça <img data-src=" />









Ricard a écrit :



On sait faire du traitement beaucoup plus lourd sur des fichiers que de les effacer si + de 30 jours. Par exemple,  chez Google.

<img data-src=" />







parceque c’est complexe ça ? me fait pas rire









boglob a écrit :



parceque c’est complexe ça ? me fait pas rire





Relis les posts suivants… Tu comprendras mieux.<img data-src=" />