Supposons que j’ai un dispositif IoT, contrôlé par la firme A, qui achète un tas de services à la firme B. Je serai responsable de tous les frais, même si je n’avais aucune idée que la firme A allait faire ces achats en mon nom.

Au cours du week-end, j’ai découvert que j’avais un tel dispositif et que l’argent à risque n’est pas anodin. Un processus d’arrière-plan appelé nsurlsessiond qu’Apple utilise pour gérer les services iCloud a téléchargé 400 Go (oui, GIGA et oui BYTES) de données sur mon iMac en l’espace de 31 heures. Apple fait en sorte qu’il soit très difficile de voir ou de comprendre ce que fait ce processus. Donc, en fait, cela a transformé mon iMac en un appareil IoT qui brûlait de la bande passante.

J’ai appris qu’il y avait un problème seulement parce que j’ai passé un certain temps à travailler à distance sur mon Macbook, en utilisant la connexion 4G de mon iPad à Internet. Il avait également été transformé en l’un de ces appareils IoT, de sorte que j’ai rapidement reçu un avertissement de mon FAI disant que j’avais déjà dépassé toute mon allocation mensuelle de 20 Go de données téléchargées via le sans fil. J’ai arrêté de me connecter en 4G dès que j’ai pu, mais je me suis quand même retrouvé avec 75 $ de frais de données excédentaires.

Quand je suis rentré chez moi, j’ai vérifié mon iMac. Je n’ai pas trouvé le moyen d’obtenir les informations dont j’avais besoin pour comprendre ce qui se passait à partir du moniteur d’activité intégré. Heureusement, j’utilise aussi un programme appelé Little Snitch qui surveille le trafic réseau. Son rapport sur nsurlsessiond a montré ceci:

nsurlsessiond

Pour quantifier les responsabilités ici, si ce téléchargement avait été sur ma connexion 4G, les frais de dépassement de mon FAI de 15 $ par Go, multipliés par 400 Go de données, impliqueraient 6 000 $ de frais de données. Ma connexion à la maison n’a pas de plafond de données, mais tout le monde ne bénéficie pas de cette protection. Le technicien d’Apple a dit que si je devais faire face à de gros frais, il est parfois efficace d’appeler le FAI et de le supplier pour qu’il ait pitié.

Apple et mon FAI ont une relation à long terme. Ensemble, ils ont un intérêt commun à me faire utiliser beaucoup plus de données que le FAI peut facturer. Mon FAI peut récompenser Apple en encourageant les ventes d’appareils mobiles Apple.

Vraisemblablement, tous deux voudraient éviter un pic d’utilisation qui attire l’attention comme celui auquel j’ai été confronté. Il a sûrement été causé par un bug. Mais il est révélateur qu’Apple ait configuré les choses de telle sorte que, par défaut, je n’ai aucune visibilité sur l’utilisation des données en arrière-plan et sans aucun étranglement ou plafond qui pourrait limiter les dommages potentiels que lorsque les choses deviennent incontrôlables.

Si vous devez payer pour les données, soyez très prudent en utilisant iCloud. Et préparez-vous à de nombreuses surprises de la part de l’IdO.

Pour toute personne confrontée à un problème similaire avec nsurlsessiond

Summary

  1. Si vous avez besoin d’une solution temporaire qui arrête les téléchargements massifs de données, une option consiste à installer Little Snitch et à ajouter une règle que vous pouvez activer et désactiver et qui refuse toute connexion sortante à nsurlsessiond. Bien que cela n’arrête que les demandes sortantes, mais cela semble être nécessaire pour soutenir les téléchargements entrants.

  2. Pour obtenir un correctif permanent, j’ai dû arrêter d’utiliser iCloud entièrement. J’ai supprimé toutes les données d’iDrive et j’ai supprimé toutes les données de la seule application (Notability) qui avait la permission de stocker des données dans iCloud.

  3. Si, comme moi, vous avez un problème qui est un véritable bug, et non une fonctionnalité intégrée de Photos – d’énormes transferts de données si vous avez une grande photothèque et acceptez d’utiliser Photos avec iCloud – vous devrez passer beaucoup de temps et d’efforts avec le support technique d’Apple pour les persuader que Photos n’est pas la source de votre problème.

Détails

1. nsurlsessiondIl existe de nombreux rapports d’utilisateurs qui se sont retrouvés avec des téléchargements énormes qu’ils n’avaient pas prévus. Beaucoup de rapports d’utilisateurs plus techniques identifient nsurlsessiond comme le processus effectuant le téléchargement. Nombre d’entre eux sont apparemment le résultat de valeurs par défaut et d’une interface trompeuse qui incite les gens à accepter de stocker de grandes quantités de données photographiques dans iCloud sans se rendre compte des conséquences de cette décision. J’ai pris soin de ne laisser aucune des applications d’Apple utiliser iCloud. Pour ce faire, j’ai dû modifier les valeurs par défaut d’iCloud, qui activent les applications Apple.

2. iCloud DriveDans le cadre d’iCloud, j’ai utilisé iDrive, qui me permet d’avoir une partie de mon système de fichiers dans le nuage. Je peux voir ces fichiers dans le Finder sous iCloud Drive. Cela se comporte comme Dropbox ou Google Drive, mais avec une différence cruciale. Je n’ai aucun contrôle sur le processus de synchronisation avec le magasin local de données. Si iDrive est activé, un processus en arrière-plan (probablement nsurlsessiond mais il peut y en avoir d’autres) synchronise les fichiers sur iDrive avec un cache sur ma machine. J’avais environ 30 Go de données sur iDrive.

3. Laisser une application utiliser iCloudJe laisse une seule application (Notability) stocker ses données dans iCloud. Cette application fonctionne à la fois sur les appareils IOS et sous OSX. Sous OSX, cela implique également une synchronisation entre les données stockées dans le nuage et un cache local. La différence est que, comme on peut s’y attendre dans le monde IOS, les fichiers ne sont pas visibles via le Finder. Lorsque j’ai vérifié iCloud sous Préférences Système, j’ai pu constater que Notability stockait environ 3 Go sur iCloud. (C’est beaucoup plus que ce que Notability semble être conçu pour gérer. Cette grande quantité de données est due en partie au fait que sur un appareil IOS, Notability duplique chaque note si vous désactivez puis réactivez l’accès à iCloud. Apparemment, le fait de le désactiver transforme le cache local en un magasin de données local permanent. Ensuite, si vous réactivez iCloud, Notability télécharge une autre copie de chaque note à partir d’iCloud et les place dans un nouveau cache. Comme j’ai essayé de déboguer des problèmes avec Notability, je me suis retrouvé avec 4 copies de chaque note.)

4. La source de mon problèmeJ’ai vu des indications de bugs à la fois dans Notability et iDrive, donc je ne suis pas sûr de ce qui a causé les téléchargements massifs.

Les fichiers de cache sont sous la Bibliothèque de l’utilisateur, à laquelle vous pouvez accéder via le Finder en maintenant la touche option lorsque vous cliquez sur Go. Pour voir ce qui se passe dans la Bibliothèque, il est utile de sélectionner Afficher les options d’affichage du Finder (dans le menu Affichage) et de cocher Calculer toutes les tailles pour que le Finder puisse afficher la taille de tous les dossiers d’un répertoire.

Dans la Bibliothèque, le dossier Documents mobiles semble être le cache pour iDrive. Il contenait la même quantité de données, 30 Go, que celle que j’ai initialement téléchargée sur iDrive.

Je soupçonne que Notability mettait en cache des informations dans Library/Caches/CloudKit. À différents moments, ce dossier s’est retrouvé avec quelque chose entre 5 et 20 Go, ce qui est bien sûr beaucoup trop par rapport aux 3 Go que Notability était censé gérer. Si l’on prend les deux, il n’y a aucune raison pour que la synchronisation d’un total de 30+3 Go de données nécessite 400 Go de téléchargements sur une seule machine. Quelque chose a dû continuer à essayer, encore et encore, d’accomplir quelque chose qui ne fonctionnait pas.

Le grand cache de CloudKit a suggéré que Notability était le problème. J’ai essayé de supprimer le dossier CloudKit et même l’ensemble du dossier Caches. Lorsque ceux-ci étaient dans la corbeille, ils étaient encore utilisés par divers processus système. Après un redémarrage, j’ai parfois vu un grand cache réapparaître sous CloudKit trop rapidement pour que cela soit le résultat de téléchargements. Je soupçonne donc que les mêmes processus qui avaient utilisé les fichiers lorsqu’ils étaient dans la Corbeille les ont récupérés dans CloudKit après un redémarrage. Le seul moyen que j’ai trouvé pour éviter cela était de i) couper ma connexion Internet, ii) supprimer le dossier CloudKit, iii) redémarrer, iv) vider la corbeille, v) rétablir ma connexion Internet. Mais le cache de CloudKit semblait toujours se reconstruire via un téléchargement. Cela semblait continuer même après avoir supprimé toutes mes données de Notability. (En rétrospective, j’aurais dû essayer de supprimer ce cache à la fois de mon iMac et de mon MacBook pour exclure la possibilité que le cache d’une machine essaie de reconstruire le cache de l’autre.)

Mes problèmes ne se sont résolus qu’après avoir également supprimé toutes mes données d’iDrive, en le faisant sur chaque machine et pour chaque utilisateur ayant accès à iDrive. En cours de route, j’ai également essayé plusieurs autres fois de supprimer le dossier cache de CloudKit. (Il a maintenant très peu de données.)

Mon intuition est que Notability était le coupable, mais il est possible qu’iDrive utilisait également le cache CloudKit d’une certaine manière et qu’il était la véritable source du problème ; ou qu’il y a une certaine interaction entre Notability et iDrive ; ou qu’il y avait un retard ou une interaction entre les caches sur les deux machines de sorte que se débarrasser des données de Notability était bien résoudre le problème, mais cela n’est pas apparu jusqu’à ce que je supprime toutes les données d’iDrive ; ou …

.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.