Het was een van die weken waarin ik de hele tijd bezig was, maar er schijnbaar niet zo veel van terechtkwam. Een groot deel van mijn week ging op aan het oplossen van een merkwaardig probleem dat een handvol TidBITS-leden trof. Hoewel de eerste dagen van het probleem behoorlijk frustrerend waren, was de oplossing zowel bevredigend als een bewijs hoe wonderbaarlijk behulpzaam TidBITS-lezers kunnen zijn.

De eerste aanwijzing dat we een probleem hadden kwam van onze helpdesk-held, Lauri Reinhardt. Ze hielp een TidBITS-lid wiens verlenging was geweigerd door de bank. Hij had contact opgenomen met Citibank en de vertegenwoordiger van de klantenservice zei dat de transactie was mislukt omdat het werd doorgegeven als cryptocurrency. (Dit was ronduit belachelijk, vooral gezien ons publieke wantrouwen jegens het hele veld, zie “Begrijp cryptovaluta, maar investeer er niet in”, 20 april 2022.) Zijn protesten waren aan dovemansoren gericht, dus schreef hij naar Lauri. Zij bekeek de transactie-logs van Stripe, maar kon niets vinden dat verband hield met cryptocurrency. Maar ze merkte wel een toename in mislukte abonnementsverlengingen.

Toen zij dit meldde, keek onze ontwikkelaar Eli mee en ontdekte dat de meeste mislukte transacties de afwijzingscode transaction_not_allowed hadden en die waren allemaal afkomstig van Citibank. Tegelijkertijd hoorde ik van een van mijn TidBITS Content Network-abonnees over een mislukte verlenging en het bleek dat ook hij een creditcard van Citibank gebruikte.

Het was tijd om contact op te nemen met de ondersteuningsafdeling van Stripe. Het probleem treft misschien slechts 10 mensen tot nu toe deze maand, maar het zou alleen maar erger worden en niet iedereen kan overschakelen naar een creditcard van een andere bank. Op dat moment dacht ik ook dat het misschien een meer algemeen Stripe-probleem was, maar dat bleek niet het geval te zijn.

Op een lang verhaal korter te maken: de e-mailondersteuning van Stripe, in de persoon van Tristan, zei vriendelijk maar beslist: het lag absoluut niet aan Stripe. Ondertussen voerden meerdere TidBITS-leden gesprekken met Citibank, die er allemaal op uitdraaiden dat wij volgens Citibank cryptomunten zouden verkopen. En dit wordt door Citibank en andere creditcard-bedrijven al jaren gewoonweg niet toegestaan. (Ik denk dat het ermee te maken heeft dat veel rondom de munten en hun koers onvoorspelbaar is). Geen van onze leden slaagde erin Citibank van gedachten te doen veranderen en de lidmaatschapsbetaling goed te keuren. Een van deze mensen zei dat hij net zo goed tegen een muur had kunnen praten.

Omdat ik zelf geen Citibank-klant ben, lukte het mij niet om met ze in gesprek te komen, dus ik heb Tristan telkens gevraagd om de klacht op te schalen. Uiteindelijk deed ik Stripes ondersteuningsoptie een verzoek om teruggebeld te worden. Grappig genoeg werd ik een paar minuten later opgebeld door Tristan, die toevallig die dag telefoondienst had, en erg verbaasd was mij aan de lijn te krijgen. Hij heeft een sterk Iers accent en is een aardig iemand. Hij bleef herhalen dat hij niets kon vinden wat zou wijzen op een fout bij Stripe (waar ik het overigens mee eens was), maar hij begreep ook heel goed, dat vanuit mijn gezichtspunt alleen Stripe iets kon doen om tot een oplossing te komen. Hij beloofde om iemand anders te zoeken die mij wel zou kunnen helpen. Vervolgens kreeg ik Tony aan de lijn, en daarna ook nog Charles, maar beiden bleven bij het bedrijfsstandpunt, hoe hard ik ook aandrong dat zij Citibank moesten bellen. Toen ik op een gegeven moment meldde dat ik over de situatie een artikel in TidBITS zou schrijven, verbond Charles me door met Matt.

Misschien hadden er op de achtergrond verschillende mensen met elkaar gepraat, en misschien schoot Matt mij daardoor te hulp, maar in ieder geval las Matt TidBITS al jarenlang. Hij wist daardoor ook heel goed dat wij niets met cryptomunten te maken hebben. Hij beloofde intern bij Stripe op zoek te gaan naar mensen die wel met Citibank zouden kunnen bellen. En hij bracht een nieuw onderwerp in, namelijk de zogenaamde Merchant Category Code. Hij vertelde dat veranderingen in zo'n MCC soms leiden tot problemen zoals de onze. Maar omdat er op dat gebied bij ons niets recent was veranderd, dacht hij niet dat dit het probleem was.

“Wacht eens even!”, dacht ik. Ik was me er nooit van bewust geweest dat wij iets als een MCC hadden, maar stel dat die van ons nu niet klopte: misschien had Citibank om de een of andere reden wel iets aan onze MCC veranderd. En dan zou het daardoor komen, dat ze onze transacties verkeerd interpreteerden. Matt vertelde nu, dat onze MCC de volgende verandereringen ondergaan had:

• Computersoftwarewinkels (van februari 2018 tot juli 2018)
• Programmering van computers (juli 2018 tot augustus 2018)
• Computers, randapparatuur en software (augustus 2018 toto oktober 2020)
• Programmeren van computers (oktober 2020 tot heden)

Allemaal veranderingen die door een algoritme bij Stripe bepaald waren, en geen ervan beschrijft correct wat wij doen. Matt zei dat soms een handmatige interventie nodig was voor de toekenning van een correcte MCC en gaf me een lijst. Voor lidmaatschappen van TidBITS koos ik nu “Publiceren en drukken” en (dit was ondertussen de volgende dag, toen ik deze optie pas goed zag) “Media over digitale goederen: boeken, films en muziek” als MCC voor het TidBITS Content Network. Matt veranderde de codes voor mij. Daarna werkten alle nieuwe betalingsverzoeken zonder enige vertraging. Eindelijk!

Eind goed, al goed. Hoewel ik drammeriger moest zijn dan ik graag ben, loonde het toch de moeite. Ik vond uiteindelijk de oplossing van het probleem, toen ik bij het bedrijf Stripe een TidBITS-lezer tegenkwam die bereid was om wat meer inzicht te geven in de processen achter de schermen.

En in feite was dit de tweede keer in de afgelopen maand dat een TidBITS-lezer ons uit de brand hielp. Toen ik onze problemen met de Automatic Platform Optimization van Cloudflare beschreef in het artikel “LittleBITS: veranderingen in snelheid en beveiliging van onze website” van 6 juni 2022, was het Jonas, ook een TidBITS-lezer, die ons een heel goed advies mailde, vanuit zijn werk in een technische afdeling van Cloudflare. Dus: veel dank aan zowel Matt als Jonas! Zoals Eli droog opmerkte: 32 jaar werken aan het opbouwen van een loyaal publiek, is ook een manier om op tijd technische ondersteuning te krijgen. Zelf zie ik het graag als het opbouwen van een mooi karma.

iPadOS 16 biedt een mix aan langverwachte mogelijkheden (zie “Tien "Het werd tijd"-functies van WWDC 2022,” 6 juni 2022) en een aantal die ons verbazen (zie “Zeven raadselachtige mogelijkheden van WWDC 2022,” 13 juni 2022). Op veel manieren is de meest opvallende mogelijkheid Stage Manager, waarmee een venstersysteem mogelijk is die wat meer lijkt op wat bekend is van de Mac, hoewel het wel wat beperkter is.

Er is wel een probleem: Stage Manager vereist een snelle iPad met een M1-processor (“De werkelijke systeemvereisten van Apples besturingssystemen uit 2022,” 9 juni 2022). Dat zijn op dit moment maar drie modellen: de iPad Air van de vijfde generatie, de 12,9 inch iPad Pro van de vijfde generatie en de 11 inch iPad Pro van de derde generatie. (Stage Manager werkt ook op alle Macs die macOS 13 Ventura draaien, maar zelfs Apple verwacht dat de overgrote meerderheid van Mac gebruikers zal vasthouden aan de oude werkgewoontes in plaats van op het nieuwe paradigma van Stage Manager over te stappen.)

Veel gebruikers, in het bijzonder die met recente iPads die geen M1-processor hebben, zijn niet blij en Apple probeert de schade te beperken door de overwegingen uit te leggen.

De uitleg van Apple: Stage Manager heeft prestaties op M1-niveau nodig

De eerste reactie van Apple was een Twitter-bericht gericht aan YouTuber ervaren Apple commentator Rene Ritchie:

Stage Manager is een volledige geïntegreerde ervaring met een volledig nieuwe vensterervaring die erg snel is en responsief, en waarmee tot 8 apps tegelijkertijd gedraaid kunnen worden op een iPad en een extern scherm met een resolutie tot 6K. Deze ervaring bieden met de snelheid die gebruikers verwachten met de aanraakbediening van de iPad, vereist veel intern geheugen, hele snelle opslag en snelle communicatie met het externe scherm en dat kan geleverd worden door iPads met een M1-processor.

Om kort te gaan zegt Apple dat Stage Manager niet draait op een andere processor dan de M1 van Apple. Of goed genoeg draait, zoals Craig Federighi van Apple aan Forbes uitlegde:

We zijn onze testen nog wel met andere systemen begonnen maar het bleek al vroeg dat we op die andere processoren niet de ervaring konden bieden waarvoor we ontwierpen. We zouden natuurlijk graag iedere nieuwe mogelijkheid brengen op elk systeem dat we hebben maar we willen ook geen compromis treffen waar het om de gebruikerservaring gaat en het fundament voor toekomstige ontwikkelingen. En het lukte echt alleen maar op de M1.

Federighi legde ook de nadruk op reactiesnelheid op TechCrunch:

Het ontwerpen voor de M1 was ook een kritische stap. Al vanaf het begin staat de iPad bekend om zijn hoge reactiesnelheid en interactiviteit. Die directe interactie van iedere app reageert snel op iedere aanraking, alsof je echt met een fysiek apparaat omgaat. Ik denk dat het soms moeilijk is voor mensen om zich te beseffen hoe moeilijk het is om dat te realiseren.

Om kort te gaan: Macs komen er soms mee weg om enige vertraging te hebben, op een iPad is dat niet zo. Daar is de suggestie dat je met echte voorwerpen omgaat belangrijk. We zijn eraan gewend dat je soms de strandbal ziet op een Mac maar er wordt hard aan gewerkt om dat te voorkomen op de iPad. Federighi zei dat Apple heeft geworsteld om die snelle reactie te houden bij verschillende apps op het scherm:

En zodra het gaat om veel apps en grote hoeveelheden schermoppervlak moet je ervoor zorgen dat al die apps net zo snel blijven reageren en dat betekent sneller dan met een app op een Mac. Er is dus sprake van een andere verzameling beperkingen.

Hij voegde ook een technischer uitleg toe:

Alleen iPads met een M1-processor combineren de benodigde hoge DRAM-capaciteit met voldoende snel NAND met hoge capaciteit waarmee de wisseling in virtueel geheugen snel genoeg kan. Nu we het mogelijk maken om vier apps op een scherm te hebben en nog vier op een ander scherm, dus in totaal maximaal 8, is die capaciteit nodig en dat kan echt niet op andere systemen.

Stage Manager staat vier open apps op een iPad tegelijkertijd toe maar je kunt je bureaublad uitbreiden met nog vier apps als je een extern scherm hebt. Theoretisch gezien zou Apple die ondersteuning voor externe schermen uit Stage Manager kunnen halen om het ook te laten draaien op minder krachtige iPads maar Apple ziet dat juist als een essentieel onderdeel van Stage Manager. Federighi zei ook:

We zien Stage Manager als een totaalervaring waarbij de mogelijkheid om een extern scherm aan te sluiten noodzakelijk is. En de M1 maakt meer mogelijk dan op voorgaande iPads: er kunnen 4K, 5K en 6K schermen aangesloten worden en je kunt de resolutie instellen. Dat kan niet op andere iPads.

Ten slotte kun je deze vereiste gedeeltelijk de schuld geven voor wat de eerbiedwaardige e-mailclient Eudora 'trendy 3D-rommel' noemt, hoewel Federighi het in andere termen formuleert:

We hebben Stage Manager echt ontworpen om volledig te profiteren [van de M1]. Als je kijkt naar de manier waarop de apps kantelen en schaduwen werpen en hoe ze in en uit bewegen. Om dat met hele hoge framesnelheden te kunnen doen op zeer grote schermen en op verschillende schermen, zijn de hoogste grafische prestaties vereist die niemand anders kan leveren.

Zou Apple Stage Manager ontworpen kunnen hebben om op minder krachtige iPads te werken?

In de kringen van Apple-enthousiasten heeft de discussie plaatsgevonden over de vraag of Stage Manager echt niet zou werken op iPads zonder M1-processor óf dat Apple het voor een deel zo heeft ontworpen dat ze meer high-end iPads kunnen verkopen. Als ik de verklaringen van Federighi zorgvuldig lees, geloof ik dat beide waar zijn. In zijn TechCrunch-interview maakte Federighi duidelijk dat Apple de functie op geen enkele manier wilde beperken en op de toekomst mikt in plaats van op het verleden:

Als je dit allemaal bij elkaar optelt, kunnen we de volledige Stage Manager-ervaring niet leveren op een minder krachtig systeem. Ik bedoel, we zouden het heel graag overal beschikbaar maken maar dit is wat het nodig heeft. Dit is de ervaring die we meenemen naar de toekomst. We wilden ons ontwerp niet beperken tot iets minder, we zetten de maatstaf voor de toekomst.

In de meest botte bewoordingen: Apple had Stage Manager kunnen ontwerpen om te werken op iPads zonder M1-processor maar het wilde gewoon de algehele ervaring niet verslechteren om dat mogelijk te maken. Dit zijn niet per se snode plannen van Apple maar eerder de standaardwijze waarop Apple zakelijke beslissingen neemt. Vanuit het perspectief van Apple is het een algehele overwinning. Stagemanager:

• Biedt een rijke multitasking-ervaring waardoor mensen iPads willen hebben
• Moedigt gebruikers met iPads zonder M1-processor aan om te upgraden
• Rechtvaardigt de aankoop door klanten die al een M1-iPad bezitten

Apple gebruikt deze manier van denken op veel gebieden. De Transparency-functie voor app-tracking, waarmee gebruikers kunnen voorkomen dat apps hun gedrag volgen, is bijvoorbeeld een enorme privacy verbetering en een sterk verkoopargument voor het Apple-ecosysteem. En het verzwakt ook nog eens de advertentiekanalen van concurrenten zoals Facebook en versterkt de advertentie-arm van Apple zelf.

Hoe Apple ontwikkelaars (en getroffen tech-auteurs) gerust kan stellen

De meeste iPad-gebruikers zijn zich niet bewust van deze discussie en zullen Stage Manager dan ook niet missen. Voor niet-technische gebruikers is de iPad een eenvoudig en handig computerapparaat, terwijl ervaren gebruikers vaak al een hoogwaardige iPad hebben of hun werk veelal op een Mac uitoefenen. Stage Manager is een speciale functie gericht op ervaren iPad-gebruikers en diegenen die geen M1-iPad hebben, hebben nu een reden om bij een volgende upgrade erin te investeren.

Ontwikkelaars zouden zich nog meer aan de M1-vereiste kunnen storen dan gebruikers. Ontwikkelaar Steve Troughton-Smith laat weten dat de meeste ontwikkelaars geen M1-iPad bezitten en dat Stage Manager officieel niet door de iOS Simulator ondersteund wordt, wat het optimaliseren van apps voor Stage Manager bemoeilijkt. Bezitters van M1-iPads zouden teleurgesteld kunnen zijn dat Stage Manager niet meteen naar verwachting met hun favoriete apps van derden werkt.

Flipside of the Stage Manager/M1 iPad situation: your favorite app dev probably doesn’t have one, either. And, right now, the iOS Simulator doesn’t officially support Stage Manager — so not unreasonable to expect the vast majority of third-party apps won’t, come September, either

— Steve Troughton-Smith (@stroughtonsmith) June 13, 2022

[Keerzijde van de Stage Manager/M1-iPad-situatie: je favoriete app-ontwikkelaar heeft er waarschijnlijk ook geen. Daar komt nog bij dat Stage Manager op dit moment niet officieel door de iOS Simulator ondersteund wordt en is het niet onredelijk om te veronderstellen dat de meerderheid van de apps van derden dat in September ook niet zullen doen.]

Troughton-Smith stelt voor dat Apple de app Stage Manager voor bèta-testers op non-M1-iPads activeert. Ik juich dat idee om de volgende redenen toe:

• Meer ontwikkelaars kunnen zo hun apps optimaliseren zodat die goed met Stage Manager werken, wat zal resulteren in tevredenere bezitters van M1-iPads.
• Ervan uitgaande dat Apple eerlijk is over de prestaties van Stage Manager, zal dit aantonen dat Stage Manager wel degelijk een M1-chip nodig heeft.
• Bèta-testers die werken op iPads die Stage Manager niet ondersteunen, zullen eventuele onderprestaties aan de bètaversie toe kunnen schrijven.
• Zielige, getroffen tech-auteurs zoals ik kunnen de functie dan documenteren.

Apple is natuurlijk niet geïnteresseerd in het laatste punt en het bedrijf ziet onafhankelijke programmeurs vaak zelfs als onwelkome competitie. Zoals het er nu voorstaat zit ik met mijn vervolg op Take Control of iOS 15 and iPadOS 15 in een lastig parket, omdat ik slechts een basismodel-iPad van vorig jaar heb, dat ik aangeschaft heb om functies te testen die een A12 Bionic-chip vereisten. Ik gebruik mijn iPad eigenlijk alleen om te testen en ik twijfel dan ook of ik moet upgraden, of dat ik me misschien aan de hand van video’s een voorstelling kan maken hoe de app werkt, of dat ik wellicht een M1-iPad moet kopen en binnen 14-dagen terugbrengen of zelfs dat ik een middag bij een verafgelegen Apple Store moet gaan bivakkeren.

De oorsprong van Stage Manager

Grappig genoeg blijkt dat Stage Manager oorspronkelijk in 2006 bedacht is als een prototype dat “shrinkydink” [“verkleinvormpje”, nvdv] heette, zoals aangetoond door een oud-ontwikkelaar van Apple die schermafbeeldingen gepost heeft om te laten zien hoe weinig het aanvankelijke ontwerp veranderd is. De oorspronkelijke post is verwijderd (waarschijnlijk op aandringen van Apple Legal) maar je kunt nog steeds een gearchiveerde versie bekijken.

We zien de laatste tijd een constante stroom van klachten over het laden van websites; de details zijn niet altijd hetzelfde, maar de verbindende factor is dat de problemen altijd begonnen na installeren van macOS 12.4 Monterey. In sommige gevallen ging het alleen over Safari, bij anderen trad het probleem ook op in Chrome en andere browsers. Soms werden pagina's helemaal niet geladen, terwijl bij anderen pagina's maar half werden geladen.

De oplossing voor de problemen die ik tot nu toe tegenkwam is betrekkelijk eenvoudig: ga naar Systeemvoorkeuren > Netwerk en zet 'Beperk IP-adrestracking' uit voor elke netwerk-adapter die je werkelijk gebruikt (ethernet en wifi hieronder - ze zien er opmerkelijk verschillend uit).

Bij sommige gebruikers treedt het probleem ook op in iOS 15 en iPadOS 15. Apple biedt dezelfde Beperk IP-adrestracking-functie in Instellingen > Wifi > JouwNetwerk en Instellingen > Mobiel netwerk > Opties mobiele data.

Als je de kleine lettertjes onder de schermafbeeldingen van de iPhone hierboven bestudeert, zul je zien dat er het volgende staat: “Als je dit uitschakelt, wordt Privédoorgifte in iCloud ook uitgeschakeld voor dit netwerk.” Dat bericht wordt op mijn iPhone getoond omdat ik Privédoorgifte in iCloud op de iPhone heb geactiveerd; op mijn Mac staat het uit.

Ik zou willen dat ik begreep wat er hier precies aan de hand is, maar het is hondsmoeilijk om een functie te testen die tracking door kwaadaardige derden verhindert, met name omdat ik niet kwaadaardig èn geen derde ben. En het helpt ook niet dat je op drie volstrekt verschillende plekken functies vindt die claimen dat ze IP-adres-tracking beperken of je IP-adres verbergen:

• Privédoorgifte in iCloud: Deze overkoepelende privacy-functie stuurt al je internetverkeer via twee afzonderlijke internet relays, om je IP-adres te af te schermen voor de site waar je contact mee maakt. Je kunt deze functie aan- en uitzetten in Systeemvoorkeuren > Apple ID op de Mac en Instellingen > JouwNaam in iOS en iPadOS.
• Beperk IP-adrestracking: Deze instelling vind je bij elk netwerk dat je gebruikt, of dat nou wifi, ethernet of een mobiel netwerk is. Zoals hierboven opgemerkt, verandert de omschrijving afhankelijk van of Privédoorgifte in iCloud aan of uit staat.
• Verberg IP-adres: Safari en Mail hebben allebei deze instelling in hun voorkeuren, maar maken niet duidelijk wat het verband is met Privédoorgifte in iCloud.

Hier is mijn idee wat er precies aan de hand is, maar ik ben niet overal zeker van. Hopelijk kun je deze informatie gebruiken om een compromis te bereiken tussen privacy en verbindingsproblemen.

Privédoorgifte in iCloud

Het eerste waar je naar moet kijken als je af en toe netwerkproblemen hebt is Privédoorgifte in iCloud. Deze functie, alleen beschikbaar voor iCloud+-abonnees die Apple betalen voor extra opslagruimte, stuurt al je internetverkeer via twee internet-relays, eentje van Apple en eentje van een grote informatiedoorstuurdienst zoals Akamai, Cloudflare of Fastly. Apple heeft een technisch bulletin dat het tot in details uitlegt, maar in beginsel komt het daar op neer.

Het privacyvoordeel is dat alleen je provider en Apple je IP-adres kennen, omdat je provider en de eerste relay (de zogenaamde 'proxy van binnenkomst') de verbinding moeten kunnen koppelen aan jouw machine, om de gevraagde informatie te kunnen afleveren. Het adres van de website die je wilt laden is echter versleuteld, waardoor noch Apple, noch je provider weet waar je naar toe gaat.

De volgende relay (de zogenaamde 'proxy van uitgang') voorziet het verzoek van een nieuw, tijdelijk IP-adres, ontsleutelt het adres van de website waar je naar toe wilt gaan en zet de verbinding met die website op. Anders gezegd: de proxy van uitgang weet niet wat jouw IP-adres is - hij weet alleen waar je je globaal bevindt, zodat er geen probleem is met geolocatie.

Apple bevestigt dat Privédoorgifte in iCloud tot problemen kan leiden, deels door de nieuwe transportprotocollen die de functie gebruikt. Privédoorgifte in iCloud neemt ook de taak van je normale DNS-servers over, wat ook tot problemen zou kunnen leiden; zeker één gebruiker had een Pi-hole advertentie-blokker geïnstalleerd. macOS vertelt je dit als je DNS-servers specificeert in Systeemvoorkeuren > Netwerk > JouwNetwerk > Geavanceerd > DNS.

Als je echter als gebruiker problemen hebt, zijn er maar twee dingen die je hoeft te proberen, zoals boven reeds aangehaald:

• Privédoorgifte in iCloud helemaal uitzetten. Je kunt het makkelijk aan- of uitzetten, dus het is geen groot probleem om met die knop te spelen als dat nodig blijkt.
• Zet Beperk IP-adrestracking uit voor een specifiek netwerk. Zo kun je het bijvoorbeeld uitzetten op je iPhone voor je wifi-netwerk thuis, maar aan laten staan voor je mobiele dataverbinding.

Je zult niet snel denken dat Beperk IP-adrestracking voor een bepaald netwerk Privédoorgifte in iCloud uit zou schakelen, en Apple noemt dit zelf ook maar één keer in de documentatie over Privédoorgifte in iCloud:

Privédoorgifte kan worden in- of uitgeschakeld voor een specifiek netwerk met de instelling ‘Beperk IP-adrestracking’.*

Het sterretje verwijst naar een voetnoot, waarin staat:

* In eerdere versies van iOS, iPadOS en macOS heet deze optie Privédoorgifte in iCloud.

Waarom heeft Apple die optie hernoemd? Nu wordt het allemaal wat vaag. Volgens mij komt het doordat Beperk IP-adrestracking meer doet dan alleen iCloud Privédoorgifte uitschakelen.

Beperk IP-adrestracking

Apple heeft bekend gemaakt dat bij het uitschakelen van Beperk IP-adrestracking voor een bepaald netwerk Privédoorgifte in iCloud uitgezet wordt. Volgens mij kun je inderdaad stellen dat als je zowel Privédoorgifte in iCloud als Beperk IP-adrestracking uitschakelt, er weer normaal verkeer van en naar je ISP en doelwebsites zal plaatsvinden.

Maar hoe zit het met de resterende mogelijkheid, waarbij Privédoorgifte in iCloud; uitgeschakeld is, maar Beperk IP-adrestracking aanstaat? Hier gaan de kleine lettertjes een rol spelen. Als Privédoorgifte in iCloud aanstaat, zeggen de kleine lettertjes:

Beperk IP-adrestracking door je IP-adres te verbergen voor bekende trackers in Mail en Safari. Als dit uitgeschakeld is, zal Privédoorgifte in iCloud voor dit netwerk ook uitgezet zijn.

Als Privédoorgifte in iCloud uitstaat, worden de kleine lettertjes nog kleiner:

Beperk IP-adrestracking door in Mail en Safari je IP-adres te verbergen voor bekende trackers.

Ik kan bij Apple hierover geen toelichting vinden, maar ik neem aan dat Apple bedoelt dat de Privédoorgifte in iCloud-methode van verkeer doorsturen via twee internet-relays in Mail en Safari ingebed zit, zodat het alleen consequenties heeft voor verzoeken vanuit die apps. Ik weet alleen niet wat “je IP-adres verbergen voor bekende trackers” betekent en hoe dit verschilt van het verbergen van je IP-adres in het algemeen. Laten we dit eens onder de loep nemen.

Verberg IP-adres

Op de Mac, kun je naar Safari > Instellingen > Privacy gaan om nog een Verberg IP-adres-instelling te vinden. In Mail, zoek je in Mail > Voorkeuren > Privacy. Je moet wel Bescherm activiteiten in Mail uitschakelen om de Verberg IP-adres-optie apart in te stellen. (In het algemeen gesproken moet je Bescherm activiteiten in Mail zoveel mogelijk ingeschakeld laten.)

In iOS en iPadOS vindt je gelijkwaardige opties bij Instellingen > Safari > Verberg IP-adres en Instellingen > Mail > Privacybescherming. In Mail moet je nu ook weer Bescherm activiteiten in Mail uitschakelen om de controle apart in te stellen voor Verberg IP-adres.

Dus wat doen deze Verberg IP-adres-instellingen nu eigenlijk? Bij Safari is dat moeilijk om te weten. Als je op de Meer informatie-koppeling klikt of tikt op de Mac of iPhone, kom je terecht op een uitlegpagina over Privédoorgifte in iCloud, die geen inzicht geeft over het verband met Safari.

Bij Mail daarentegen is de informatie duidelijker. Klik of tik op de Meer informatie-koppeling en je krijgt behoorlijk veel informatie hoe de Bescherm activiteiten in Mail een tweestaps-systeem heeft dat erg veel lijkt op Privédoorgifte in iCloud. Het legt ook uit dat wanneer Bescherm activiteiten in Mail uitgeschakelt en Verberg IP-adres aan laat staan, het nog steeds "je IP-adres verbergt in dezelfde configuratie met twee afzonderlijke internet-relays”.

Bovendien stuurt Bescherm activiteiten in Mail alle inhoud die van buiten wordt gedownload door Mail door twee afzonderlijke relays die door twee verschillende entiteiten worden beheerd. De eerste kent je IP-adres, maar niet de Mail-inhoud die je ontvangt. De tweede kent de inhoud van wat je binnenkrijgt via Mail, maar niet het IP-adres en geeft een gegeneraliseerde identiteit aan de bestemming. Op deze manier heeft geen enkele entiteit informatie om je te identificeren en te koppelen aan de Mail-inhoud die je ontvangt. Afzenders kunnen je IP-adres niet gebruiken voor unieke identificatie om verbindingen te leggen met je activiteiten op andere websites of applicaties om een profiel van je op te bouwen. Als je kiest om Bescherm activiteiten in Mail niet te selecteren, zal het Bescherm IP-adres nog steeds je IP-adres afschermen door gebruik te maken van hetzelfde ontwerp met twee afzonderlijke internet-relays.

Ik schat dat het allemaal gewoon Privédoorgifte in iCloud is.

Conclusie

Hier is hoe we volgens mij moeten denken over deze samenhangende instellingen.

• Privédoorgifte in iCloud: Op het hoogste niveau staat Privédoorgifte in iCloud. Als je dit inschakelt, wordt al je verkeer via de in- en uitgaande proxies geleid, wat de hoogste mate van privacy biedt. Het is echter zeer waarschijnlijk dat Privédoorgifte in iCloud problemen zal veroorzaken, dus geeft Apple gebruikers de mogelijkheid om terug te vallen naar een lager privacyniveau.
• Beperk IP-adrestracking: Dat is waar de optie Beperk IP-adrestracking op netwerkniveau van pas komt. Je kunt deze optie uitschakelen om Privédoorgifte in iCloud selectief uit te schakelen of aanzetten (met Privédoorgifte in iCloud uitgeschakeld) om Privédoorgifte in iCloud-achtige verkeersroutering toe te passen op verkeer van Safari en Mail. Maar omdat deze apps nogal van elkaar verschillen - Safari moet verbinding kunnen maken met een veel gevarieerdere verzameling servers dan Mail - heeft Apple ze ook gescheiden.
• Verberg IP-adres: Daarom heeft elke app zijn eigen instelling voor Verberg IP-adres. Het kan zijn dat je Privédoorgifte in iCloud uitschakelt, Beperk IP-adrestracking uitschakelt en Safari's instelling Verberg IP-adres uitschakelt, maar dat je de optie Verberg IP-adres van Mail ingeschakeld wilt houden. Het is denkbaar dat je de volgbeveiliging van Mail uitschakelt en die van Safari inschakelt, maar dat lijkt minder waarschijnlijk.

Als je Verberg IP-adres voor Safari en Beperk IP-adrestracking voor je netwerk uitschakelt en vervolgens Privédoorgifte in iCloud inschakelt, wordt eerst gevraagd om IP-adres verbergen in Safari in te schakelen (linksonder) en krijg je vervolgens een waarschuwing dat het voor jouw netwerk is uitgeschakeld (rechtsonder).

Wederom weet ik niet wat Apple bedoelt wanneer het zegt dat Beperk IP-adrestracking en Verberg IP-adres alleen betrekking hebben op "bekende trackers". Het scherm Verberg IP-adres in Safari maakt het onderscheid duidelijk: zolang Privédoorgifte in iCloud is ingeschakeld, kun je kiezen tussen Trackers en websites of alleen Trackers. Als Privédoorgifte in iCloud niet is ingeschakeld, kun je alleen je IP-adres verbergen voor Trackers.

Ik heb geen documentatie van Apple kunnen vinden over hoe het bedrijf bekende trackers identificeert en het verkeer in Safari en Mail zo masseert dat je IP-adres daartegen wordt beschermd. Wat gebeurt er als je verbinding maakt met een externe site die geen bekende tracker is? Stuurt Apple dan je IP-adres ongecodeerd door? Misschien kan iemand die weet hoe je netwerkverkeer analyseert daar achter komen, maar dat gaat mijn vaardigheden te boven.

Wat echter belangrijk is, is dat als je problemen hebt, je eerst Privédoorgifte in iCloud uit kunt zetten, en als dat het probleem niet oplost, je Beperk IP-adrestracking uit kunt zetten. Als zelfs dat nog niet genoeg is, schakel je Verberg IP-adres voor Safari of Mail uit.

In alle andere gevallen laat je ze gewoon allemaal aan staan en geniet je van de extra privacy die ze bieden.