Supongamos que tengo un dispositivo IoT, controlado por la empresa A, que compra un montón de servicios a la empresa B. Seré responsable de todos los cargos, incluso si no tenía ni idea de que la empresa A iba a hacer estas compras en mi nombre.

Durante el fin de semana, descubrí que tenía un dispositivo de este tipo y que el dinero en riesgo no es trivial. Un proceso en segundo plano llamado nsurlsessiond que Apple utiliza para gestionar los servicios de iCloud descargó 400 GB (sí, GIGA y sí BYTES) de datos en mi iMac en el transcurso de 31 horas. Apple hace muy difícil ver o entender lo que este proceso está haciendo. Así que, en efecto, convirtió mi iMac en un aparato IoT que quemaba ancho de banda.

Me enteré de que había un problema sólo porque pasé un tiempo trabajando remotamente en mi Macbook, usando la conexión 4G de mi iPad a Internet. También se había convertido en uno de estos aparatos IoT, por lo que pronto recibí un aviso de mi ISP diciendo que ya había superado toda mi asignación mensual de 20 GB de datos descargados vía inalámbrica. Dejé de conectarme a través de 4G tan pronto como pude, pero aun así acabé con 75 dólares en cargos por exceso de datos.

Cuando llegué a casa, comprobé mi iMac. No pude encontrar una manera de obtener la información que necesitaba para averiguar lo que estaba pasando desde el Monitor de Actividad incorporado. Afortunadamente, también ejecuto un programa llamado Little Snitch que monitoriza el tráfico de red. Su informe sobre nsurlsessiond mostraba lo siguiente:

Para cuantificar las responsabilidades aquí, si esta descarga hubiera sido a través de mi conexión 4G, el cargo por exceso de uso de mi ISP de 15 dólares por GB, multiplicado por 400 GB de datos, implicaría 6000 dólares en cargos de datos. Mi conexión en casa no tiene un límite de datos, pero no todo el mundo tiene esta protección. El técnico de Apple me dijo que si me enfrentaba a grandes cargos, a veces funcionaba llamar al ISP y pedir clemencia.

Apple y mi ISP tienen una relación a largo plazo. Juntos, tienen un interés conjunto en conseguir que use muchos más datos que el ISP pueda cobrar. Mi ISP puede recompensar a Apple fomentando las ventas de los dispositivos móviles de Apple.

Es de suponer que a los dos les gustaría evitar un pico de uso que llame la atención, como el que yo sufrí. Seguramente fue causado por un error. Pero es revelador que Apple haya configurado las cosas de manera que, por defecto, no tenga visibilidad del uso de datos en segundo plano y sin ningún tipo de acelerador o tope que pueda limitar el daño potencial que cuando las cosas se salen de control.

Si tienes que pagar por los datos, ten mucho cuidado con el uso de iCloud. Y prepárate para muchas sorpresas del IoT.

Para cualquiera que se enfrente a un problema similar con nsurlsessiond

Resumen

1. Si necesitas una solución temporal que detenga las descargas masivas de datos, una opción es instalar Little Snitch y añadir una regla que puedas activar y desactivar que niegue cualquier conexión saliente a nsurlsessiond. Aunque esto sólo detiene las solicitudes salientes, pero esto parece ser necesario para mantener las descargas entrantes.

2. Para obtener una solución permanente, tuve que dejar de usar iCloud por completo. Eliminé todos los datos de iDrive y borré todos los datos de la única aplicación (Notability) que tenía permiso para almacenar datos en iCloud.

3. Si, como yo, tienes un problema que es un verdadero error, no una característica incorporada de Fotos -enormes transferencias de datos si tienes una gran biblioteca de fotos y aceptas usar Fotos con iCloud- tendrás que pasar mucho tiempo y esfuerzo con el soporte técnico de Apple para persuadirles de que Fotos no es el origen de tu problema.

Detalles

1. nsurlsessiondHay muchos informes de usuarios que acabaron con descargas enormes que no habían previsto. Muchos de los informes de usuarios más técnicos identifican a nsurlsessiond como el proceso que realiza la descarga. Muchos de ellos son aparentemente el resultado de los valores predeterminados y de una interfaz engañosa que consigue que la gente acepte almacenar grandes cantidades de datos de fotos en iCloud sin darse cuenta de las consecuencias de esta decisión. Tuve cuidado de no dejar que ninguna de las aplicaciones de Apple utilizara iCloud. Para ello, tuve que cambiar los valores predeterminados de iCloud, que activan las aplicaciones de Apple.

2. iCloud DriveComo parte de iCloud, he estado utilizando iDrive, que me permite tener parte de mi sistema de archivos en la nube. Puedo ver estos archivos en Finder bajo iCloud Drive. Esto se comporta como Dropbox o Google Drive, pero con una diferencia crucial. No tengo ningún control sobre el proceso de sincronización con el almacén local de datos. Si iDrive está activado, un proceso en segundo plano (probablemente nsurlsessiond pero puede haber otros) sincroniza los archivos en iDrive con una caché en mi máquina. Tenía unos 30 GB de datos en iDrive.

3. Dejar que una aplicación use iCloudDejo que sólo una aplicación (Notability) almacene sus datos en iCloud. Esta aplicación funciona tanto en dispositivos IOS como en OSX. En OSX, esto también implica una sincronización entre los datos almacenados en la nube y un caché local. La diferencia es que, como se puede esperar del mundo IOS, los archivos no son visibles a través del Finder. Cuando comprobé iCloud en Preferencias del Sistema, pude ver que Notability estaba almacenando unos 3 GB en iCloud. (Esto es mucho más de lo que Notability parece diseñado para manejar. Esta gran cantidad de datos surgió en parte porque en un dispositivo IOS, Notability duplica cada nota si desactivas el acceso a iCloud y lo vuelves a activar. Aparentemente, al desactivarlo se convierte la caché local en un almacén de datos local permanente. Luego, si vuelves a activar iCloud, Notability descarga otra copia de cada nota de iCloud y las pone en una nueva caché. Al tratar de depurar los problemas con Notability, terminé con 4 copias de cada nota.)

4. El origen de mi problemaVi indicios de errores tanto en Notability como en iDrive, así que no estoy seguro de cuál fue la causa de las descargas masivas.

Los archivos de la caché están bajo la Biblioteca del usuario, a la que se puede acceder a través del Finder manteniendo pulsada la tecla de opción al hacer clic en Ir. Para ver lo que ocurre en la Biblioteca, ayuda seleccionar Mostrar opciones de vista para el Finder (en el menú Ver) y marcar Calcular todos los tamaños para que el Finder pueda mostrar el tamaño de todas las carpetas de un directorio.

En la Biblioteca, la carpeta Documentos móviles parece ser la caché de iDrive. Tenía la misma cantidad de datos, 30 GB, que subí originalmente a iDrive.

Sospecho que Notability estaba almacenando información en caché en Library/Caches/CloudKit. En diferentes momentos, esta carpeta terminó con algo entre 5 y 20 GB, que por supuesto es demasiado en relación con los 3 GB que se supone que Notability estaba gestionando. Tomando los dos juntos, no hay razón para que la sincronización de un total de 30+3 GB de datos requiera 400 GB de descargas en una sola máquina. Algo debe haber seguido intentando, una y otra vez, lograr algo que no estaba funcionando.

La gran caché de CloudKit sugería que Notability era el problema. Probé a borrar la carpeta CloudKit e incluso toda la carpeta Caches. Cuando éstas estaban en la Papelera, seguían siendo utilizadas por varios procesos del sistema. Después de un reinicio, a veces vi un gran caché resurgir bajo CloudKit demasiado rápido para que esto sea el resultado de las descargas, así que sospecho que los mismos procesos que habían estado usando los archivos mientras estaban en la Papelera los recuperaron a CloudKit después de un reinicio. La única forma que encontré para evitar esto fue i) apagar mi conexión a internet, ii) borrar la carpeta de CloudKit, iii) reiniciar, iv) vaciar la papelera, v) volver a encender mi conexión a internet. Pero entonces la caché de CloudKit parecía seguir reconstruyéndose a través de una descarga. Esto parecía continuar incluso después de borrar todos mis datos desde dentro de Notability. (En retrospectiva, debería haber intentado borrar esta caché tanto de mi iMac como de mi MacBook para descartar la posibilidad de que la caché de una máquina estuviera intentando reconstruir la caché de la otra.)

Mis problemas se resolvieron sólo después de que también borrara todos mis datos de iDrive, haciendo esto en cada máquina y para cada usuario con acceso a iDrive. En el camino, también intenté varias veces más para eliminar la carpeta de caché CloudKit. (Ahora tiene muy pocos datos.)

Mi corazonada es que Notability era el culpable, pero es posible que iDrive también estaba usando la caché de CloudKit de alguna manera y que era la verdadera fuente del problema; o que hay alguna interacción entre Notability y iDrive; o que había un retraso o una interacción entre las cachés en las dos máquinas para que deshacerse de los datos de Notability era resolvió el problema, pero esto no apareció hasta después de que borré todos los datos de iDrive; o …