Ponha que eu tenho um dispositivo IoT, controlado pela firma A, que compra um monte de serviços da firma B. Eu serei responsável por todos os encargos, mesmo que eu não tivesse idéia de que a firma A iria fazer essas compras em meu nome.

No fim de semana, descobri que eu tinha um dispositivo desse tipo e que o dinheiro em risco não é trivial. Um processo de fundo chamado nsurlsessiond que a Apple usa para gerenciar os serviços iCloud baixou 400 GB (sim, GIGA e sim BYTES) de dados para o meu iMac ao longo de 31 horas. A Apple torna muito difícil ver ou compreender o que este processo está a fazer. Então, na verdade, ele transformou meu iMac em um aparelho IoT que queimou largura de banda.

Eu aprendi que só havia um problema porque eu passava algum tempo trabalhando remotamente no meu Macbook, usando a conexão 4G do meu iPad com a internet. Ele também foi transformado em um desses aparelhos IoT, então logo recebi um aviso do meu provedor dizendo que eu já havia excedido toda a minha alocação mensal de 20 GB de dados baixados via wireless. Eu parei de conectar mais de 4G assim que pude, mas ainda assim acabei com $75 em taxas de dados em excesso.

Quando cheguei em casa, eu chequei meu iMac. Eu não consegui encontrar uma maneira de obter a informação que eu precisava para descobrir o que estava acontecendo a partir do Monitor de Atividades embutido. Felizmente, eu também executei um programa chamado Little Snitch que monitora o tráfego de rede. Seu relatório sobre nsurlsessiond mostrou isto:

Para quantificar as responsabilidades aqui, se este download tivesse sido sobre a minha conexão 4G, a taxa de excesso de ISP de $15 por GB, multiplicada por 400 GB de dados, implicaria $6000 em taxas de dados. A minha conexão em casa não tem um limite de dados, mas nem todos têm esta protecção. O técnico da Apple disse que se eu enfrentasse grandes encargos, às vezes funciona ligar para o ISP e implorar por misericórdia.

Apple e meu ISP têm um relacionamento de longo prazo. Juntos, eles têm um interesse conjunto em me fazer usar muito mais dados que o ISP pode cobrar. Meu provedor pode recompensar a Apple incentivando as vendas de dispositivos móveis Apple.

Presumivelmente, os dois gostariam de evitar um pico de atenção como aquele que eu enfrentei. Certamente foi causado por um bug. Mas está dizendo que a Apple configurou as coisas para que, por padrão, eu não tenha visibilidade do uso de dados em segundo plano e sem qualquer acelerador ou tampa que poderia limitar os danos potenciais que quando as coisas saírem do controle.

Se você tiver que pagar pelos dados, tenha muito cuidado ao usar o iCloud. E prepare-se para muitas surpresas do IoT.

Para qualquer pessoa que enfrente um problema similar com nsurlsessiond

Sumário

1. Se você precisar de uma correção temporária que pare os downloads massivos de dados, uma opção é instalar o Little Snitch e adicionar uma regra que você pode ligar e desligar que nega qualquer conexão de saída ao nsurlsessiond. Embora isto apenas pare as requisições de saída, mas isto parece ser necessário para manter os downloads recebidos.

2. Para obter uma correção permanente, eu tive que parar de usar o iCloud por completo. Eu excluí todos os dados do iDrive e excluí todos os dados de uma aplicação (Notabilidade) que tinha permissão para armazenar dados no iCloud.

3. Se, como eu, você tem um problema que é um verdadeiro bug, e não uma funcionalidade integrada de transferências de dados do Photos-huge se você tem uma grande biblioteca de fotos e concorda em usar Photos com o iCloud- você terá que gastar muito tempo e esforço com o suporte técnico da Apple convencendo-os de que Photos não é a fonte do seu problema.

Details

1. nsurlsessiondHá muitos relatórios de utilizadores que acabaram por fazer grandes downloads que não anteciparam. Muitos dos relatórios de usuários mais técnicos identificam o nsurlsessiond como o processo de fazer o download. Muitos deles são aparentemente o resultado de inadimplências e uma interface enganosa que faz com que as pessoas concordem em armazenar grandes quantidades de dados de fotos no iCloud sem perceber as conseqüências desta decisão. Eu tive o cuidado de não deixar nenhuma das aplicações da Apple utilizar o iCloud. Para fazer isso, tive que alterar os padrões do iCloud, que ativam as aplicações Apple.

2. iCloud DriveComo parte do iCloud, tenho usado o iDrive, que me permite ter parte do meu sistema de arquivos na nuvem. Posso ver estes ficheiros no Finder em iCloud Drive. Isto se comporta como Dropbox ou Google Drive, mas com uma diferença crucial. Eu não tenho controle sobre o processo de sincronização com o armazenamento local de dados. Se o iDrive estiver ligado, um processo de fundo (provavelmente nsurlsessiond mas pode haver outros) sincroniza os arquivos no iDrive com um cache na minha máquina. Eu tinha cerca de 30 GB de dados no iDrive.

3. Deixando um aplicativo usar iCloudI deixo apenas um aplicativo (Notability) armazenar seus dados no iCloud. Este aplicativo é executado tanto em dispositivos IOS quanto em OSX. Sob OSX, isso também envolve uma sincronização entre os dados armazenados na nuvem e um cache local. A diferença é que, como você pode esperar do mundo IOS, os arquivos não são visíveis através do Finder. Quando verifiquei o iCloud em Preferências do Sistema, pude ver que o Notability estava armazenando cerca de 3 GB no iCloud. (Isto é muito mais do que o Notability parece ter sido projetado para lidar. Esta grande quantidade de dados surgiu em parte porque em um dispositivo IOS, o Notability duplica cada nota se você desligar o acesso ao iCloud e depois ligar novamente. Aparentemente, desligá-lo transforma o cache local em um armazenamento de dados local permanente. Depois, se voltar a ligar o iCloud, o Notability descarrega outra cópia de cada nota do iCloud e coloca-as numa nova cache. Como tentei depurar problemas com o Notability, acabei com 4 cópias de cada nota.)

4 A origem do meu problemaVi indicações de erros tanto no Notability como no iDrive, por isso não tenho a certeza do que causou os downloads massivos.

Os ficheiros da cache estão debaixo da biblioteca do utilizador, que pode aceder através do Finder, mantendo premida a tecla de opção quando clica em Ir. Para ver o que se passa na Biblioteca, ajuda a seleccionar Mostrar Opções de Visualização do Finder (no menu Ver) e marcar Calcular Todos os Tamanhos para que o Finder possa mostrar o tamanho de todas as pastas de um directório.

Na Biblioteca, a pasta Documentos Móveis parece ser a cache para o iDrive. Ela tinha a mesma quantidade de dados, 30 GB, que eu carreguei originalmente no iDrive.

E suspeito que a Notability estava armazenando informações em cache na Library/Caches/CloudKit. Em momentos diferentes, esta pasta acabou com algo entre 5 e 20 GB, o que, claro, é muito relativo aos 3 GB que o Notability deveria estar gerenciando. Tomando os dois juntos, não há razão para que a sincronização de um total de 30+3 GB de dados deva requerer 400 GB de downloads para uma única máquina. Algo deve ter continuado a tentar, repetidamente, realizar algo que não estava a funcionar.

O grande cache no CloudKit sugeriu que a Notabilidade era o problema. Eu tentei apagar a pasta do CloudKit e até mesmo a pasta inteira dos Caches. Quando estes estavam no Lixo, eles ainda estavam sendo usados por vários processos do sistema. Após uma reinicialização, por vezes vi uma grande cache reaparecer sob o CloudKit demasiado depressa para que isto fosse o resultado de downloads, por isso suspeito que os mesmos processos que tinham estado a utilizar os ficheiros enquanto estavam no Lixo os recuperaram para o CloudKit após uma reinicialização. A única forma que encontrei para evitar isto foi i) ligar a minha ligação à Internet, ii) apagar a pasta CloudKit, iii) reiniciar, iv) esvaziar o lixo, v) ligar novamente a minha ligação à Internet. Mas depois o cache do CloudKit parecia continuar a reconstruir-se a si próprio através de um download. Isto pareceu continuar mesmo depois de apagar todos os meus dados de dentro da Notabilidade. (Em retrospectiva, eu deveria ter tentado apagar esta cache do meu iMac e do meu MacBook para descartar a possibilidade de que a cache de uma máquina estivesse tentando reconstruir a cache da outra.)

Os meus problemas só foram resolvidos depois de eu também ter apagado todos os meus dados do iDrive, fazendo isso em cada máquina e para cada usuário com acesso ao iDrive. Ao longo do caminho, também tentei várias outras vezes apagar a pasta de cache do CloudKit. (Agora ele tem muito poucos dados.)

O meu palpite é que o Notability foi o culpado, mas é possível que o iDrive também estivesse usando o cache do CloudKit de alguma forma e que ele fosse a verdadeira fonte do problema; ou que haja alguma interação entre o Notability e o iDrive; ou que houvesse um atraso ou uma interação entre os caches nas duas máquinas, de modo que se livrar dos dados do Notability foi resolvido o problema, mas isso só apareceu depois que eu excluí todos os dados do iDrive; ou …