Să presupunem că am un dispozitiv IoT, controlat de firma A, care cumpără o grămadă de servicii de la firma B. Voi fi responsabil pentru toate cheltuielile, chiar dacă nu aveam nicio idee că firma A avea de gând să facă aceste achiziții în numele meu.

În weekend, am descoperit că am un astfel de dispozitiv și că banii riscați nu sunt triviali. Un proces de fundal numit nsurlsessiond pe care Apple îl folosește pentru a gestiona serviciile iCloud a descărcat 400 GB (da, GIGA și da, BYTES) de date pe iMac-ul meu pe parcursul a 31 de ore. Apple face foarte dificil să vezi sau să înțelegi ce face acest proces. Așa că, de fapt, mi-a transformat iMac-ul într-un aparat IoT care a consumat lățime de bandă.

Am aflat că există o problemă doar pentru că am petrecut ceva timp lucrând de la distanță pe Macbook-ul meu, folosind conexiunea 4G a iPad-ului meu la internet. Acesta fusese, de asemenea, transformat într-unul dintre aceste aparate IoT, așa că în scurt timp am primit un avertisment de la furnizorul meu de servicii de internet care îmi spunea că deja îmi depășisem întreaga alocare lunară de 20 GB de date descărcate prin wireless. Am încetat să mă mai conectez prin 4G cât de repede am putut, dar tot m-am trezit cu 75 de dolari în taxe de date în exces.

Când am ajuns acasă, mi-am verificat iMac-ul. Nu am găsit o modalitate de a obține informațiile de care aveam nevoie pentru a-mi da seama ce se întâmpla din Monitorul de activitate încorporat. Din fericire, am rulat și un program numit Little Snitch care monitorizează traficul de rețea. Raportul său privind nsurlsessiond a arătat următoarele:

Pentru a cuantifica responsabilitățile de aici, dacă această descărcare ar fi fost efectuată prin conexiunea mea 4G, taxa de depășire a ISP-ului meu de 15 dolari pe GB, înmulțită cu 400 GB de date, ar implica 6000 de dolari în taxe de date. Conexiunea mea de acasă nu are un plafon de date, dar nu toată lumea are această protecție. Tehnicianul de la Apple a spus că, dacă m-aș confrunta cu taxe mari, uneori funcționează să sun la ISP și să cerșesc milă.

Apple și ISP-ul meu au o relație pe termen lung. Împreună, au un interes comun de a mă face să folosesc mult mai multe date pe care ISP-ul le poate taxa. ISP-ul meu poate răsplăti Apple prin încurajarea vânzărilor de dispozitive mobile Apple.

Presumabil, cei doi ar dori să evite un vârf de utilizare care să atragă atenția, precum cel cu care m-am confruntat eu. Acesta a fost cu siguranță cauzat de un bug. Dar este revelator faptul că Apple a configurat lucrurile astfel încât, în mod implicit, să nu am nicio vizibilitate asupra utilizării datelor în fundal și fără niciun fel de limitare sau plafon care ar putea limita daunele potențiale pe care atunci când lucrurile scapă de sub control.

Dacă trebuie să plătiți pentru date, fiți foarte atenți la utilizarea iCloud. Și pregătiți-vă pentru o mulțime de surprize din partea IoT.

Pentru oricine se confruntă cu o problemă similară cu nsurlsessiond

Rezumat

1. Dacă aveți nevoie de o soluție temporară care să oprească descărcările masive de date, o opțiune este să instalați Little Snitch și să adăugați o regulă pe care o puteți activa și dezactiva și care refuză orice conexiune de ieșire către nsurlsessiond. Deși acest lucru oprește doar cererile de ieșire, dar acest lucru pare să fie necesar pentru a susține descărcările de intrare.

2. Pentru a obține o soluție permanentă, a trebuit să nu mai folosesc iCloud în întregime. Am șters toate datele din iDrive și am șters toate datele din singura aplicație (Notability) care avea permisiunea de a stoca date în iCloud.

3. Dacă, la fel ca mine, aveți o problemă care este un adevărat bug, nu o caracteristică integrată a Photos – transferuri uriașe de date dacă aveți o bibliotecă foto mare și sunteți de acord să folosiți Photos cu iCloud – va trebui să petreceți mult timp și să depuneți mult efort cu cei de la Apple Tech Support pentru a-i convinge că Photos nu este sursa problemei dumneavoastră.

Detalii

1. nsurlsessiondExistă multe rapoarte ale utilizatorilor care s-au ales cu descărcări uriașe pe care nu le-au anticipat. Multe dintre rapoartele de la utilizatorii mai tehnici identifică nsurlsessiond ca fiind procesul care face descărcarea. Se pare că multe dintre acestea sunt rezultatul unor valori implicite și al unei interfețe înșelătoare care îi determină pe oameni să accepte să stocheze cantități mari de date foto în iCloud fără să realizeze consecințele acestei decizii. Am avut grijă să nu las niciuna dintre aplicațiile Apple să utilizeze iCloud. Pentru a face acest lucru, a trebuit să schimb valorile implicite pentru iCloud, care activează aplicațiile Apple.

2. iCloud DriveCa parte a iCloud, am folosit iDrive, care îmi permite să am o parte din sistemul de fișiere în cloud. Pot vedea aceste fișiere în Finder sub iCloud Drive. Acesta se comportă ca și Dropbox sau Google Drive, dar cu o diferență crucială. Nu am niciun control asupra procesului de sincronizare cu stocul local de date. Dacă iDrive este activat, un proces din fundal (probabil nsurlsessiond, dar este posibil să existe și altele) sincronizează fișierele de pe iDrive cu o memorie cache de pe mașina mea. Aveam aproximativ 30 GB de date pe iDrive.

3. Să las o aplicație să folosească iCloudAm lăsat doar o singură aplicație (Notability) să își stocheze datele în iCloud. Această aplicație rulează atât pe dispozitive IOS, cât și pe OSX. Sub OSX, și acest lucru implică o sincronizare între datele stocate în cloud și o memorie cache locală. Diferența constă în faptul că, așa cum v-ați putea aștepta din lumea IOS, fișierele nu sunt vizibile prin Finder. Când am verificat iCloud în Preferințe de sistem, am putut vedea că Notability stoca aproximativ 3 GB în iCloud. (Acest lucru este mult mai mult decât Notability pare proiectat să gestioneze. Această cantitate mare de date a apărut în parte pentru că, pe un dispozitiv IOS, Notability dublează fiecare notă dacă dezactivați și apoi activați din nou accesul la iCloud. Aparent, dezactivarea acestuia transformă memoria cache locală într-un depozit de date local permanent. Apoi, dacă activați din nou iCloud, Notability descarcă o altă copie a fiecărei note din iCloud și le pune într-o nouă memorie cache. În timp ce încercam să depanez probleme cu Notability, am ajuns să am 4 copii ale fiecărei note.)

4. Sursa problemei meleAm văzut indicii de erori atât în Notability, cât și în iDrive, așa că nu sunt sigur ce a cauzat descărcările masive.

Arhivele cache se află sub Biblioteca utilizatorului, pe care o puteți accesa prin Finder ținând apăsată tasta de opțiune atunci când faceți clic pe Go. Pentru a vedea ce se întâmplă în Bibliotecă, este util să selectați Show View Options for Finder (din meniul View) și să bifați Calculate All Sizes (Calculați toate dimensiunile) pentru ca Finder să poată afișa dimensiunea tuturor dosarelor dintr-un director.

În Bibliotecă, dosarul Mobile Documents (Documente mobile) pare să fie memoria cache pentru iDrive. Avea aceeași cantitate de date, 30 GB, pe care am încărcat-o inițial în iDrive.

Suspectez că Notability a pus în cache informațiile din Library/Caches/CloudKit. În momente diferite, acest folder a ajuns să aibă ceva între 5 și 20 GB, ceea ce, desigur, este mult prea mult în raport cu cei 3 GB pe care Notability ar fi trebuit să-i gestioneze. Luând cele două la un loc, nu există niciun motiv pentru care sincronizarea unui total de 30+3 GB de date ar trebui să necesite 400 GB de descărcări pe o singură mașină. Ceva trebuie să fi continuat să încerce, din nou și din nou, să realizeze ceva care nu funcționa.

Cahierul mare din CloudKit a sugerat că Notability era problema. Am încercat să șterg folderul CloudKit și chiar întregul folder Caches. Când acestea se aflau în coșul de gunoi, erau încă folosite de diverse procese de sistem. După o repornire, am văzut uneori o memorie cache mare reapărând în CloudKit prea repede pentru ca acest lucru să fie rezultatul descărcărilor, așa că bănuiesc că aceleași procese care au folosit fișierele în timp ce se aflau în Coșul de gunoi le-au recuperat în CloudKit după o repornire. Singura modalitate pe care am găsit-o pentru a preveni acest lucru a fost: i) să închid conexiunea la internet, ii) să șterg dosarul CloudKit, iii) să repornesc, iv) să golesc coșul de gunoi, v) să pornesc din nou conexiunea la internet. Dar apoi, cache-ul CloudKit părea să continue să se reconstruiască prin intermediul unei descărcări. Acest lucru părea să continue chiar și după ce am șters toate datele mele din interiorul Notability. (În retrospectivă, ar fi trebuit să încerc să șterg această memorie cache atât de pe iMac, cât și de pe MacBook, pentru a exclude posibilitatea ca memoria cache de pe o mașină să încerce să reconstruiască memoria cache de pe cealaltă.)

Problemele mele s-au rezolvat numai după ce mi-am șters, de asemenea, toate datele din iDrive, făcând acest lucru pe fiecare mașină și pentru fiecare utilizator cu acces la iDrive. Pe parcurs, am încercat, de asemenea, de mai multe ori să șterg folderul cache CloudKit. (Acum are foarte puține date.)

Principiul meu este că Notability a fost vinovatul, dar este posibil ca iDrive să fi folosit, de asemenea, memoria cache CloudKit într-un anumit fel și că aceasta a fost adevărata sursă a problemei; sau că există o interacțiune între Notability și iDrive; sau că a existat o întârziere sau o interacțiune între memoriile cache de pe cele două mașini, astfel încât eliminarea datelor Notability a rezolvat problema, dar aceasta nu a apărut decât după ce am șters toate datele din iDrive; sau …

.