Sæt, jeg har en IoT-enhed, der kontrolleres af virksomhed A, og som køber en række tjenester fra virksomhed B. Jeg vil være ansvarlig for alle udgifterne, selv om jeg ikke havde nogen anelse om, at virksomhed A ville foretage disse indkøb på mine vegne.

I løbet af weekenden opdagede jeg, at jeg har en sådan enhed, og at de penge, der er i fare, ikke er ubetydelige. En baggrundsproces kaldet nsurlsessiond, som Apple bruger til at administrere iCloud-tjenester, downloadede 400 GB (ja, GIGA og ja, BYTES) data til min iMac i løbet af 31 timer. Apple gør det meget svært at se eller forstå, hvad denne proces laver. Så i realiteten forvandlede det min iMac til et IoT-apparat, der brændte båndbredde af.

Jeg fandt kun ud af, at der var et problem, fordi jeg brugte noget tid på at arbejde eksternt på min Macbook ved hjælp af min iPad’s 4G-forbindelse til internettet. Den var også blevet omdannet til et af disse IoT-apparat, så jeg fik snart en advarsel fra min internetudbyder om, at jeg allerede havde overskredet hele min månedlige tildeling på 20 GB downloadede data via trådløs forbindelse. Jeg stoppede forbindelsen via 4G så hurtigt jeg kunne, men endte alligevel med 75 dollars i overskydende dataafgifter.

Da jeg kom hjem, tjekkede jeg min iMac. Jeg kunne ikke finde en måde at få de oplysninger, jeg havde brug for til at finde ud af, hvad der foregik, fra den indbyggede aktivitetsovervågning. Heldigvis kører jeg også et program kaldet Little Snitch, som overvåger netværkstrafikken. Dets rapport om nsurlsessiond viste dette:

For at kvantificere ansvaret her, hvis denne download havde været over min 4G-forbindelse, ville min internetudbyders overprisgebyr på 15 dollars pr. GB, ganget med 400 GB data, betyde 6000 dollars i dataafgifter. Min forbindelse derhjemme har ikke et dataloft, men det er ikke alle, der har denne beskyttelse. Teknikeren hos Apple sagde, at hvis jeg skulle stå over for store gebyrer, kan det nogle gange fungere at ringe til internetudbyderen og bede om nåde.

Apple og min internetudbyder har et langvarigt forhold. Sammen har de en fælles interesse i at få mig til at bruge meget mere data, som internetudbyderen kan opkræve penge for. Min internetudbyder kan belønne Apple ved at tilskynde til salg af Apple-mobiludstyr.

Modentlig vil de to gerne undgå en opmærksomhedsskabende forbrugsspids som den, jeg stod over for. Det var helt sikkert forårsaget af en fejl. Men det er sigende, at Apple har konfigureret tingene, så jeg som standard ikke har nogen indsigt i baggrundsdataforbruget og uden nogen begrænsning eller loft, der kunne begrænse den potentielle skade, når tingene løber løbsk.

Hvis du skal betale for data, skal du være meget forsigtig med at bruge iCloud. Og gør dig klar til masser af overraskelser fra IoT.

For alle, der står over for et lignende problem med nsurlsessiond

Summary

1. Hvis du har brug for et midlertidigt fix, der stopper de massive dataoverførsler, er en mulighed at installere Little Snitch og tilføje en regel, som du kan slå til og fra, og som nægter alle udgående forbindelser til nsurlsessiond. Selv om dette kun stopper de udgående anmodninger, men dette synes at være nødvendigt for at opretholde de indgående downloads.

2. For at få et permanent fix måtte jeg helt holde op med at bruge iCloud. Jeg slettede alle data fra iDrive, og jeg slettede alle data fra det eneste program (Notability), der havde tilladelse til at gemme data i iCloud.

3. Hvis du som jeg har et problem, der er en ægte fejl og ikke en indbygget funktion i Photos – store dataoverførsler, hvis du har et stort fotobibliotek og accepterer at bruge Photos med iCloud – skal du bruge en masse tid og kræfter på at overtale Apple Tech Support til at overbevise dem om, at Photos ikke er kilden til dit problem.

Detaljer

1. nsurlsessiondDer er mange rapporter om brugere, der er endt med enorme downloads, som de ikke havde forudset. Mange af rapporterne fra mere tekniske brugere identificerer nsurlsessiond som den proces, der foretager downloadet. Mange af disse er tilsyneladende resultatet af standardindstillinger og en misvisende grænseflade, der får folk til at acceptere at gemme store mængder fotodata i iCloud uden at være klar over konsekvenserne af denne beslutning. Jeg var omhyggelig med ikke at lade nogen af Apples programmer bruge iCloud. For at gøre dette var jeg nødt til at ændre standardindstillingerne for iCloud, som slår Apple-apps til.

2. iCloud DriveSom en del af iCloud har jeg brugt iDrive, som lader mig have en del af mit filsystem i skyen. Jeg kan se disse filer i Finder under iCloud Drive. Dette opfører sig som Dropbox eller Google Drive, men med én afgørende forskel. Jeg har ingen kontrol over synkroniseringsprocessen med det lokale lager af data. Hvis iDrive er slået til, synkroniserer en baggrundsproces (sandsynligvis nsurlsessiond, men der kan være andre) filerne på iDrive med en cache på min maskine. Jeg havde ca. 30 GB data på iDrive.

3. At lade en applikation bruge iCloudJeg lader kun én applikation (Notability) gemme sine data i iCloud. Denne app kører både på IOS-enheder og OSX. Under OSX indebærer dette også en synkronisering mellem de data, der er gemt i skyen, og en lokal cache. Forskellen er, at som du måske forventer fra IOS-verdenen, er filerne ikke synlige via Finder. Da jeg tjekkede iCloud under Systemindstillinger kunne jeg se, at Notability lagrede ca. 3 GB på iCloud. (Det er langt mere end Notability tilsyneladende er designet til at håndtere. Denne store datamængde opstod til dels fordi Notability på en IOS-enhed duplikerer alle noter, hvis du slår iCloud-adgang fra og derefter til igen. Tilsyneladende gør det at slå den fra den lokale cache til et permanent lokalt datalager. Hvis du så slår iCloud til igen, downloader Notability en ny kopi af alle noter fra iCloud og lægger dem i en ny cache. Da jeg forsøgte at fejlfinde problemer med Notability, endte jeg med at have 4 kopier af hver note.)

4. Kilden til mit problemJeg så tegn på fejl i både Notability og iDrive, så jeg er ikke sikker på, hvad der forårsagede de massive downloads.

Cachefilerne ligger under brugerbiblioteket, som du kan få adgang til via Finder ved at holde valgknappen nede, når du klikker på Gå. For at se, hvad der foregår i Bibliotek, hjælper det at vælge Vis visningsindstillinger for Finder (fra menuen Vis) og markere Beregn alle størrelser, så Finder kan vise størrelsen på alle mapper i en mappe.

I Bibliotek ser det ud til, at mappen Mobile Documents er cache for iDrive. Den havde den samme mængde data, 30 GB, som jeg oprindeligt uploadede til iDrive.

Jeg mistænker, at Notability lagde oplysninger i cache i Library/Caches/CloudKit. På forskellige tidspunkter endte denne mappe med noget mellem 5 og 20 GB, hvilket naturligvis er alt for meget i forhold til de 3 GB, som Notability skulle forvalte. Når man tager de to ting sammen, er der ingen grund til, at synkronisering af i alt 30+3 GB data skulle kræve 400 GB downloads til en enkelt maskine. Noget må være blevet ved med at forsøge igen og igen at opnå noget, der ikke virkede.

Den store cache i CloudKit tydede på, at Notability var problemet. Jeg prøvede at slette CloudKit-mappen og endda hele Caches-mappen. Da disse var i papirkurven, blev de stadig brugt af forskellige systemprocesser. Efter en genstart så jeg nogle gange en stor cache genopstå under CloudKit for hurtigt til, at dette kunne være resultatet af downloads, så jeg mistænker, at de samme processer, der havde brugt filerne, mens de lå i papirkurven, genetablerede dem til CloudKit efter en genstart. Den eneste måde jeg fandt for at forhindre dette var at i) slå min internetforbindelse fra, ii) slette CloudKit-mappen, iii) genstarte, iv) tømme papirkurven, v) slå min internetforbindelse til igen. Men så syntes CloudKit-cachen stadig at blive ved med at genopbygge sig selv via en download. Dette syntes at fortsætte, selv efter at jeg havde slettet alle mine data inde fra Notability. (Set i bakspejlet burde jeg have prøvet at slette denne cache fra både min iMac og min MacBook for at udelukke, at cachen på den ene maskine forsøgte at genopbygge cachen på den anden.)

Mine problemer blev først løst, efter at jeg også slettede alle mine data fra iDrive, og gjorde dette på hver maskine og for hver bruger med adgang til iDrive. Undervejs prøvede jeg også flere gange mere at slette CloudKit-cachelappen. (Den har nu meget få data.)

Min fornemmelse er, at Notability var synderen, men det er muligt, at iDrive også brugte CloudKit-cachen på en eller anden måde, og at det var den egentlige kilde til problemet; eller at der er en eller anden interaktion mellem Notability og iDrive; eller at der var en forsinkelse eller en interaktion mellem cachen på de to maskiner, så det at slippe af med Notability-dataene løste problemet, men det viste sig først, efter at jeg slettede alle data fra iDrive; eller …