Apple had een slechte week. Op 29 juli 2024 heeft het bedrijf updates uitgebracht voor al zijn besturingssystemen, met een paar kleine wijzigingen in macOS 14.6 Sonoma en niets dan bug- en beveiligingsfixes voor alle andere (zie “macOS 14.6 maakt ondersteuning voor twee beeldschermen mogelijk voor de 14 inch-M3 MacBook Pro”, 30 juli 2024). We merkten geen problemen na de installatie, dus we gaven onze gebruikelijke aanbeveling voor kleine updates die geen zero-day beveiligingslekken aanpakken - wacht met installeren tot het je uitkomt. Meestal worden kritieke problemen binnen een paar dagen gemeld en zal Apple de versie snel terugtrekken of vervangen. Deze keer duurde het meer dan een week.

Op 7 augustus 2024 bracht Apple macOS 14.6.1 Sonoma, iOS 17.6.1 en iPadOS 17.6.1 uit met de volgende toelichting: “Deze update bevat belangrijke bugfixes en verhelpt een probleem waardoor Geavanceerde gegevensbescherming niet kan worden in- of uitgeschakeld.” Apple kwam ook met macOS 13.6.9 Ventura met een iets bondigere toelichting: “Deze update verhelpt een probleem waardoor Geavanceerde gegevensbescherming niet kan worden in- of uitgeschakeld.” (Voor meer informatie over waar het hier om gaat, zie “De geavanceerde gegevensbescherming van Apple geeft je meer sleutels voor data op iCloud”, 8 december 2022.)

En inderdaad, toen ik naar Systeeminstellingen > Je naam > iCloud > Geavanceerde gegevensbescherming ging en op de knop Schakel in klikte, moest ik mijn Apple ID wachtwoord invoeren, maar het wachtwoorddialoogvenster verdween nadat ik één teken had ingevoerd, het scherm Systeeminstellingen knipperde en ik kreeg de volgende foutmelding te zien. Bij latere pogingen kwam de installatie verder, maar ik was niet bereid om mijn oude apparaten van mijn account te verwijderen om het installatieproces te voltooien.

Op de pagina met beveiligingsupdates van Apple staat dat de updates geen kwetsbaarheden met CVE entries aanpakken, en Howard Oakley meldt dat de enige wijzigingen betrekking hebben op het beveiligingsraamwerk en enkele sleutelhanger-gerelateerde bestanden. De vraag is dus wat er onder die “belangrijke bugfixes” valt.”

Er is een beperkt aantal klachten geweest over macOS 14.6. In TidBITS Talk meldde Ronald Lynch dat na het updaten naar macOS 14.6 hij geen toegang meer had tot Pages-sjablonen die hij in de sjabloonkiezer had opgeslagen en geen nieuwe kon aanmaken. macOS 14.6.1 bracht zijn voorheen opgeslagen sjablonen niet terug, maar liet hem wel nieuwe maken. Op andere forums hebben meerdere mensen melding gemaakt van extreme vertragingen en problemen met Bluetooth aanwijsapparaten, plus individuele klachten over geactiveerde NAS-volumes die verdwenen van het bureaublad en problemen met enterprise-authenticatie. Het is nog onduidelijk of dit algemene bugs waren of problemen die specifiek waren voor bepaalde instellingen. In vervolgberichten wordt ook niet gezegd of ze al dan niet zijn opgelost in macOS 14.6.1.

iOS 17.6 heeft klachten opgeleverd over onderbroken netwerkverbindingen en meldingen die niet werkten, samen met de eeuwige problemen met de batterijduur die meestal binnen een paar dagen verdwijnen zodra iOS de indexen en caches opnieuw opbouwt. Ook hier heb ik geen latere meldingen over iOS 17.6.1 gezien.

Er is één nieuwe klacht over macOS 14.6.1 met betrekking tot headless Macs (Macs zonder beeldscherm). Een TidBITS-lezer meldde dat hij na de update geen verbinding kon maken met een Mac mini zonder beeldscherm. Hij moest Extern beheer uit- en weer inschakelen om weer op afstand verbinding te kunnen maken. Als je een headless Mac bijwerkt, sluit hem dan aan op een toetsenbord, muis en beeldscherm voordat je de update uitvoert en schakel de instelling voor extern beheer uit in Systeeminstellingen > Delen > Extern beheer voordat je ze verwijdert.

Mijn herziene advies over het updaten naar deze set updates is als volgt:

• Als je macOS 14.5, macOS 13.6.8, iOS 17.5 en iPadOS 17.5 nog steeds zonder problemen gebruikt, blijf er dan nog even mee doorgaan. Geen van de geïdentificeerde beveiligingslekken in deze versies wordt actief in het wild misbruikt, dus het is geen groot voordeel om meteen te updaten. Bekijk het over een paar weken opnieuw.
• Als je hebt bijgewerkt tot macOS 14.6, macOS 13.6.8, iOS 17.6 en iPadOS 17.6 maar geen problemen ondervindt en niet van plan bent om Geavanceerde gegevensbescherming in of uit te schakelen, wacht er dan nog een week of twee mee om er zeker van te zijn dat Apple niet nog meer bugs heeft geïntroduceerd in de nieuwste updates.
• Als je hebt bijgewerkt naar macOS 14.6, macOS 13.6.8, iOS 17.6 en iPadOS 17.6 en je hebt problemen of je wilt Geavanceerde gegevensbescherming in- of uitschakelen, werk dan meteen bij om te profiteren van de oplossingen van Apple.

Het staat buiten kijf dat Apple hier een steekje heeft laten vallen. Geavanceerde gegevensbescherming mag dan een relatief nieuwe functie zijn die slechts door een klein percentage van het Apple-publiek wordt gebruikt, geautomatiseerde tests hadden de fout die ik hierboven heb laten zien, moeten ontdekken. Misschien heeft Apple het grootste deel van zijn testmiddelen overgeheveld naar de aankomende macOS 15 en iOS 18, maar dat is geen excuus om de huidige gebruikers in de problemen te brengen met een zwak geteste update.

Netwerkhulpprogramma was een vast onderdeel van macOS vanaf de begindagen tot en met macOS 11 Big Sur, toen Apple het liet vallen, en gebruikers in plaats daarvan aanmoedigde opdrachtregelprogramma's te gebruiken. Het argument van Apple leek te zijn dat de enige mensen die de gereedschappen nodig hadden die Netwerkhulpprogramma bood (zaken als netstat, ping, lookup, whois, traceroute, whois en finger) geavanceerde gebruikers waren die al bekend waren met het gebruik van die gereedschappen op de opdrachtregel.

Misschien geldt dat voor systeembeheerders die betrokken zijn bij het netwerk, maar ik vermoed dat velen van ons af en toe een aantal van deze gereedschappen willen gebruiken en de voorkeur geven aan een grafische interface boven een hoop tekst die voorbij scrolt in een Terminal-venster. En ik bedoel af en toe: het duurde waarschijnlijk een jaar voordat ik besefte dat Netwerkhulpprogramma verdwenen was, en sindsdien heb ik het maar een paar keer gemist.

Maar ik heb het wel degelijk gemist, dus ik was heel blij om te horen dat de aardige mensen van DEVONtechnologies, Eric Böhnisch-Volkmann en Christian Grunenberg, zojuist Neo Network Utility hebben uitgebracht, een bijna-kloon van de app waar we met veel plezier aan terugdenken. Hij is gratis via de Download-pagina van DEVONtechnologies. Hij vereist macOS 13 Ventura, dus op Macs met macOS 11 Big Sur en macOS 12 Monterey zul je Terminal moeten blijven gebruiken, hoewel ontwikkelaar Jeff Johnson me vertelde dat je een oude versie van Apples Netwerkhulpprogramma kunt gebruiken als je deze ad hoc code-ondertekent. Dat blijft een oefening voor de lezer.

Hoewel ik het niet gemakkelijk kan vergelijken met het origineel, lijkt Neo Network Utility dezelfde mogelijkheden en meer te bieden. Ik geloof bijvoorbeeld niet dat het Lookup-scherm voorheen een keuze uit informatieproviders bood (nslookup, dnscacheutil en dig).

Het Speed-scherm is geheel nieuw en maakt gebruik van het hulpprogramma voor netwerkkwaliteit dat Apple samen met Monterey heeft geïntroduceerd. (Zie “Gebruik Apples hulpprogramma voor netwerkkwaliteit om de internetrespons te testen”, 22 april 2022.)

Samenvattend: als je je bezighoudt met netwerktesten en net als ik het Netwerkhulpprogramma van Apple mist, raad ik je aan om de Neo Network Utility van DEVONtechnologies te downloaden. Bewaar het in de map Hulpprogramma's voor de volgende keer dat je nieuwsgierig bent naar wat er gebeurt met jouw netwerk of internetservers.

Ik heb een project voor een enthousiasteling! Zoals ik de afgelopen jaren al meerdere keren heb toegegeven, zijn mijn ontwikkelvaardigheden op zijn best matig, maar ik heb een idee voor een gereedschap waarvan veel Apple-beheerders en -consultants zouden kunnen profiteren, en dat misschien ook handig zou kunnen zijn voor veel anderen.

Apple houdt een uitgebreide bibliotheek bij van duizenden ondersteuningpagina's, die veel technische aspecten van de besturingssystemen, apps en apparaten beschrijven. In TidBITS verwijzen we regelmatig naar deze artikelen, en dankzij een suggestie van lezer Jolin Warren heb ik nu een macro waarmee ik de URL's kan verkorten zodat je naar de juiste pagina voor jouw land wordt verwezen.

Een tijdje terug realiseerde ik me dat de URL's voor de ondersteuningspagina's een numeriek patroon volgen. Kijk maar eens naar de pagina's voor de toelichting op de recentste veiligheidsupdates:

• iOS 16.7.9 en iPadOS 16.7.9: https://support.apple.com/nl-nl/HT214116
• iOS 17.6 en iPadOS 17.6: https://support.apple.com/nl-nl/HT214117
• macOS 12.7.6: https://support.apple.com/nl-nl/HT214118
• macOS 14.6: https://support.apple.com/nl-nl/HT214119
• macOS 13.6.8: https://support.apple.com/nl-nl/HT214120
• Safari 17.6: https://support.apple.com/nl-nl/HT214121
• tvOS 17.6: https://support.apple.com/nl-nl/HT214122
• visionOS 1.3: https://support.apple.com/nl-nl/HT214123
• watchOS 10.6: https://support.apple.com/nl-nl/HT214124

Zoals je kunt zien wordt het zescijferige getal na 'HT' voor iedere versie met één verhoogd, maar is het random voor de release zelf. Door zelf van die URL's te maken en sommige getallen te proberen te raden kwam ik erachter dat Apple met de tijd andere series van die getallen had gebruikt. Veel recente URL's beginnen met 213 of 214, maar ik heb ook URL's gevonden die begonnen met 100-119 of 201-212. Ik heb hier geen patroon in ontdekt, en Apple slaat om onbekende redenen soms ook ID's over.

Wat met dit besef te doen?

Toen ik voor het eerst zag wat Apple deed overwoog ik om Simon te gebruiken, de web monitoring app van Dejal. Deze app zou me misschien kunnen vertellen of een van deze pagina's veranderd was. Daar kwam ik echter niet ver mee, omdat ik niet kon bedenken hoe ik op een systematische manier duizenden pagina's in Simon kan laden, en het leek me dat het ook een overbelasting van mijn Mac zou zijn. Andere vergelijkbare apps hadden hetzelfde probleem: ze waren ontworpen om een paar pagina's in de gaten te houden, niet duizenden.

Als volgende stap maakte ik een Google Sheet aan met een kolom voor het getal van zes cijfers, een kolom met het URL-deel en een kolom die met de formule =Hyperlink($A2, IMPORTXML($A2",//title")) de titel opzocht en een verwijzing naar de pagina toonde. Niet alle getallen verwijzen naar actieve pagina's, dus soms stond er in die laatste kolom '#N/A'.

Was dit een succes? Het probleem is dat als ik de rijen van boven naar beneden vul, Google Sheets er op een gegeven moment mee ophoudt omdat er teveel externe verwijzingen worden gedaan naar de ondersteuningssite van Apple. Dan zie ik alleen nog maar 'Loading', ook al zie ik wel de voorvertoning van de URL als ik erop klik.

Kort hierna kreeg ik een persbericht van een bedrijf met de naam Neptyne, dat een add-on voor Google Sheets had uitgebracht waarmee een programmeur kon werken met de gegevens in Google Sheets door middel van Python. Ik heb geen ervaring met Python, maar toen ik mijn doel uitlegde aan de oprichter van Neptyne, Douwe Osinga, ging hij aan de slag met wat ik wilde. Omdat het om Python ging kon hij een lus maken waardoor Google Sheets niet langer vastliep. Verder was Douwe in staat om uit de pagina's van Apple de datum en de versie te extraheren, waardoor ik op de datum kon sorteren. Daaruit kon ik weer afleiden welke pagina's recent gewijzigd waren. (Ik heb niet kunnen achterhalen hoe Apple versienummers genereert.)

Deze oplossing werkte aanvankelijk beter, maar was broos. Toen er rijen werden toegevoegd stopte het geheel te werken, en met mijn kennis van Python kon ik het probleem niet oplossen, zelfs niet met de hulp van een AI chatbot.

Het leek er echter wel op dat wat ik wilde mogelijk was. Stel je een wereld voor waarin je meteen op de hoogte bent van technische veranderingen bij Apple zodra ze uitgebracht worden, en niet pas nadat je erover gestruikeld bent met een zoekopdracht die je later uitvoert.

Apple Support Article Tracker

De mogelijkheid om het universum van Apples ondersteuningsartikel-URL's te doorlopen, de inhoud op te halen en de lijst te sorteren op datum was een goede proof of concept. Ik denk niet dat Google Sheets hiervoor het juiste platform is, en mijn onderzoek suggereert dat Excel en Numbers ook geen kanshebbers zijn. Ik vermoed dat we in plaats daarvan een database nodig hebben met een web-interface die iedereen kan gebruiken. In mijn ideale wereld zou het webschrapen ongeveer als volgt verlopen:

• Regelmatig alle mogelijke Apple support URL's doorlopen, misschien één keer per dag of week. (Omdat het zich als een webspider zou gedragen, zou het robots.txt-uitsluitingen moeten respecteren, op beperkte snelheid moeten werken en zich netjes gedragen.)
• De eerste keer wordt elke pagina in een database geladen, waarbij velden voor titel, datum, versie en volledige tekst worden ingevuld.
• Bij volgende passages wordt de inhoud lokaal opgeslagen als deze is gewijzigd ten opzichte van de vorige keer.

Met de database die de metadata, volledige tekst en versies opslaat, zou de openbare website het volgende moeten doen:

• Een lijst weergeven met alle titels van Apples ondersteuningsartikelen, gesorteerd op datum, met toegang tot eerdere versies.
• Voor elk geselecteerd artikel en versie een venster weergeven met de gerenderde HTML.
• Een weergave bieden die de verschillen tussen twee versies van een artikel laat zien.
• Waarschuwingen bieden voor nieuwe en gewijzigde artikelen, bijvoorbeeld via RSS of e-mail.
• Een mogelijkheid bieden om de volledige tekst te doorzoeken. (De zoekmachine van Apple is bijzonder zwak, zie “Apple introduceert Documentatie-site voor handleidingen, specificaties en downloads”, 25 maart 2024.)
• Voor extra punten een discussieonderwerp per artikel bieden voor annotaties.
• Voor dubbel extra krediet een AI chatbot toevoegen die conversaties met de kennisbank mogelijk maakt, waarbij antwoorden verwijzen naar bronpagina's.

Ik wil graag geloven dat dit niet al te moeilijk zou zijn voor iemand met fatsoenlijke webontwikkelingsvaardigheden, maar het valt ver buiten mijn vaardigheden. (Hoewel Glenn Fleishman zich niet vrijwillig aanmeldde om het te maken, suggereerde hij dat een Wiki-site een gemakkelijke manier zou kunnen zijn om de gegevens op te slaan, te verspreiden en te presenteren, plus opties te bieden voor annotatie door de gemeenschap.) Ik deel het idee in de hoop dat iemand het een boeiende uitdaging vindt en het ook echt bouwt. Ik wil graag meewerken aan het proces en helpen met de hosting als dat nodig is. Doe je mee? Zijn er andere functies die je in zo'n gereedschap zou willen zien?

Ik schrijf zelden over de bètaversies van Apple-besturingssystemen, omdat belangrijke zaken kunnen veranderen in de tijd tussen de publicatie van mijn artikel en het bijwerken van de bètaversie of het uitbrengen van de productieversie door Apple. Ik wil jouw tijd en de mijne niet graag verspillen.

Het wordt echter een ander verhaal wanneer er iets zou moeten veranderen, zoals nu bij, naar mijn gevoel, een van de grootste potentiële blunders die Apple in de bètaversie van macOS aangebracht heeft, maar waar het bedrijf nog steeds op terug zou kunnen komen. MacOS 15 Sequoia vraagt voortdurend om toestemming om apps die gebruik maken van schermopnames opnieuw te autoriseren, dat geldt trouwens voor meer hulpprogramma’s dan alleen apps voor schermafbeeldingen. Dit is niet goed voor de gebruiksvriendelijkheid, verhoogt de frustratie bij gebruikers en vermindert het beveiligingsbewustzijn.

Toegang blijven verlenen

Een paar dagen nadat ik de bètaversie van macOS 15.1 Sequoia voor ontwikkelaars op mijn M1 MacBook Air had geïnstalleerd, realiseerde ik me dat er iets goed mis was. Ik vertrouw op CleanShot X voor de vele schermafbeeldingen die ik tijdens het schrijven van artikelen voor TidBITS en TCN maak, en ik was niet verbaasd dat ik bij het eerste gebruik nadat ik CleanShot X bijgewerkt had de vraag kreeg of ik de app toestemming wilde blijven geven om schermafbeeldingen te maken. Na een volledige upgrade van het besturingssysteem begrijp ik dat Apple graag heeft dat we eerder gegeven toestemmingen, waar we al een tijdje niet meer aan gedacht hadden, bevestigen. (Voor sommige mensen is dat het moment waarop ze ontdekken dat ze nog steeds een hulpprogramma of andere app draaien waarmee ze al jaren niet meer hebben gewerkt.)

Korte tijd later stond ik echter versteld dat ik nogmaals dezelfde vraag kreeg. Ik raakte nog meer geïrriteerd toen het me een dag of twee later weer werd gevraagd. En vervolgens nog een keer. En nog eens. Uiteindelijk besloot ik erover te schrijven en probeerde ik een schermafbeelding van het dialoogvenster te maken. Dat bleek lastig, want voordat ik op 'Continue To Allow' klikte (en ja, de Apple Style Guide [stijlgids van Apple, nvdv] geeft duidelijke aanwijzingen dat het "Continue to Allow" zou moeten zijn), had CleanShot X nog geen toestemming gekregen om een schermafbeelding te maken. Bij het maken van een schermafbeelding werd een tweede dialoogvenster bovenop het eerste geplaatst en reageerde macOS een paar minuten niet. Uiteindelijk kon ik in beide dialoogvensters op 'Continue To Allow' klikken en zo verder werken. Het probleem was dat CleanShot X alle muisklikken vastlegde tijdens het selecteren van het dialoogvenster voor de schermafbeelding, waardoor ik niet goed op 'Continue To Allow' kon klikken. De juiste manier om deze schermafbeeldingen te maken was door op Escape te drukken zodat de modus voor het maken van schermafbeeldingen in CleanShot X geannuleerd wordt, waarna je het ingebouwde schermafbeeldinggereedschap van Apple kunt gebruiken. Vreemd genoeg heeft klikken op 'Open System Settings' hetzelfde effect als 'Continue To Allow' en Systeeminstellingen geeft geen extra informatie over dit verzoek.

Voordat ik dit artikel af had, publiceerde Chance Miller op 9to5Mac: 'MacOS Sequoia voegt wekelijkse verzoeken om toestemming toe voor schermafbeelding- en schermopname-apps.' Hij geeft een goede beschrijving van de situatie en merkt op dat de herhaling van de verzoeken opzettelijk is geplaatst door Apple en dus geen fout is. De meldingen verschijnen elke week, iedere keer als je opnieuw opstart of, zoals ik ontdekte, als je uitlogt en weer inlogt. Hoewel een opmerking van de bekende ontwikkelaar Craig Hockenberry in een bijgewerkte versie van het artikel van Miller aangehaald wordt, waarin hij zegt dat ontwikkelaars misschien toestemming van Apple kunnen vragen om deze verzoeken te omzeilen, heeft het bedrijf daar zelf geen informatie over gedeeld. Michael Tsai heeft bovendien de verontwaardiging binnen de gemeenschap van Mac-ontwikkelaars opgetekend en Jason Snell, John Gruber en Nick Heer hebben ook bijdrages geleverd.

Hoewel ik deze dialoogvensters over het algemeen tijdens het werken met een schermafbeelding-app tegenkwam, zijn er veel apps die om toestemming aan Scherm- en systeemaudio-opname van macOS vragen om interface-elementen op het scherm te herkennen en te plaatsen of om andere taken uit te voeren. Enkele van deze apps zijn Adobe Photoshop, Adobe Premiere, Bartender, Default Folder X, Display Link, Google Chrome, Ice, Keyboard Maestro, Slack, Splashtop, TextSniper en Zoom. Als Apple met Sequoia op deze weg doorgaat, zullen er iedere week (of nog vaker) een heleboel toestemmingen verleend moeten worden.

Beveiliging door eindeloze waarschuwingsvensters

Velen hebben de toename van het aantal toestemmingsaanvragen in de afgelopen jaren betreurd. In “De (privacy)beveiliging van Mojave staat voor uitdagingen op het vlak van bruikbaarheid” (10 september 2018), schreef beveiligingsexpert Rich Mogull met een vooruitziende blik:

Balanceren van beveiligingsmeldingen en autorisatieverzoeken is notoir lastig. Als gebruikers te vaak worden gevraagd, raken ze geïrriteerd en klikken ze reflexmatig op OK. Een beveiligingsfunctie is mislukt als het lawaai van zoveel waarschuwingen ertoe leidt dat gebruikers ze niet meer lezen - en dat leidt er uiteindelijk toe dat malware om autorisatie vraagt en autorisatie krijgt. Het is een moderne versie van "De jongen die wolf riep".

We zijn het punt van beveiligingswaarschuwingen al gepasseerd. De eerste twee keer dat de Sequoia-bèta me vroeg om opnieuw te autoriseren, geef ik toe dat ik de tekst van de waarschuwing niet heb gelezen, behalve dat ik moest klikken op ‘Continue To Allow’ om de schermafbeelding te maken die ik nodig had voor wat ik aan het schrijven was. Het dialoogvenster kwam als directe reactie op de sneltoets die ik net had ingedrukt en ik gebruik en vertrouw CleanShot X al jaren. Pas toen het dialoogvenster nog een paar keer verscheen, heb ik het aandachtig gelezen om te zien of ik iets over het hoofd zag. Dat was niet het geval.

Apple lijkt aan te nemen dat alle apps van derden die het scherm (of de audio) monitoren, kwaadaardig kunnen zijn. Dat is misschien geen problematische basis om een beveiligingsraamwerk op te ontwikkelen, maar in de echte wereld is het duidelijk niet het geval. Ik denk dat meer dan 99% van de programma's op alle Macs legitiem is, om de eenvoudige reden dat niemand van plan is een kwaadaardig programma te installeren of regelmatig te gebruiken.

Er zijn geïsoleerde voorbeelden geweest van updates van legitieme apps die werden misbruikt (Transmission en Handbrake), maar dat was in 2016 en 2017 - het is gewoon geen alledaags probleem. We hebben ook onlangs het gedoe gehad hoe Bartender, dat lange tijd schermopnamemachtigingen had vereist, werd verkocht aan een nieuwe eigenaar zonder gebruikers op de hoogte te stellen (zie “Het onuitsprekelijke belang van bedrijfscommunicatie”, 5 juni 2024). In geen van deze gevallen zouden extra prompts enig verschil hebben gemaakt omdat gebruikers op geen enkele manier konden weten dat er iets was veranderd.

Door te blijven vragen om toestemming, vraagt Apple ons of we de apps die we eerder vertrouwden nog steeds vertrouwen. Wat zou er in korte tijd veranderen waardoor we deze actie zouden heroverwegen? We zouden nieuwe informatie nodig hebben om een andere keuze te maken. Ik zie wel iets in een dubbele controle van de machtigingen een paar dagen na de eerste lancering om ervoor te zorgen dat de gebruiker weet dat de app nog steeds actief is, maar herhaalde controles? Na elke herstart?

Het was logisch toen Apple locatiewaarschuwingen in iOS toevoegde die af en toe verschijnen na weken of maanden van locatietoegang op de achtergrond. De waarschuwing laat zien hoe vaak je bent gevolgd, toont een kaart met locaties die je apparaat heeft opgegeven en laat je een verstandige actie ondernemen. Met het dialoogvenster kun je de locatiemachtigingen wijzigen in "alleen tijdens gebruik". Misschien was je vergeten dat je een app toestemming had gegeven tijdens een reis en realiseerde je je niet dat de app je thuis bleef volgen. Misschien kun je je niet herinneren dat je die app hebt geïnstalleerd en toestemming hebt gegeven. Hoe dan ook, het proces is logisch - en het komt maar zelden voor.

Het toevoegen van beveiligingen tegen vrijwel onbestaande bedreigingen en het geven van waarschuwingen zonder dat er een zinnige actie kan worden ondernomen, schaadt actief de Mac-ervaring. Meer dan één schrijver heeft het spookbeeld van Windows Vista naar voren gebracht, dat bekend werd door overdreven beveiligingsdialogen en leidde tot spot van Apple. Net als de meeste Mac-gebruikers heb ik Windows Vista nooit gebruikt toen het uitkwam in 2007, dus deze vergelijkingen uit de tweede hand voelden vaag totdat ik dit stuk uit 2006 van Stack Overflow en Discourse mede-oprichter Jeff Atwood opdook. Hij waarschuwde dat "beveiliging door eindeloze waarschuwingsdialogen" niet werkt om precies de reden die waar is gebleken:

Al deze serieuze waarschuwingsmeldingen vloeien samen in één immense knop: "Klik Hier Om Aan Het Werk Te Kunnen". Niemand heeft meer zin om ze nog te lezen. Het besturingssysteem roept zo vaak "Wolf!", dat een echte wolf, in de vorm van een virus of malware, vrij spel heeft. Je stemt gedachteloos in bij ieder verzoek dat je krijgt, puur uit gewoonte.

Het is triest om te zien dat Apple fouten herhaalt die Microsoft 15 jaar geleden maakte.

En wat is Apple’s eigenlijke intentie?

Ik blijf zitten met de vraag waarom Apple al deze extra bevoegdheid-vragen ingebouwd heeft. Het makkelijkste antwoord is dat Apple's beveiligingsteam werkelijk gelooft dat apps regelmatig binnen een week overlopen naar "de duistere zijde", en dat wij dit gevaar ook zullen zien door een herhaalde herinnering aan onze keuze om de app toestemming te geven om het scherm op te nemen. Maar deze uitgangspunten zijn volkomen idioot! Als de gebruiker een app op een maandag vertrouwt, en er op een volgende maandag niets aan de app veranderd is, dan is er geen reden om dat eerder verleende vertrouwen te betwijfelen. Als er wel zo'n gegronde reden zou zijn, dan had Apple, met zijn anti-malware-systemen, allang gezorgd dat deze app helemaal niet meer opgestart kon worden, toch?

Misschien komt de beleidswijziging voort uit het recente succes dat Apple had, toen ze stilletjes de pincode-eisen voor Touch ID en Face ID opkrikten. Dit gaat nu zo: naast de bekende situaties waarin je een pincode moet invoeren op de iPhone of iPad (of een wachtwoord op de Mac), zoals bij opnieuw opstarten, voerde Apple aan aftel-systeem met een klok van 6,5 dag in, die iedere keer herstartte als je een pincode intoetste. Na afloop van die periode start er een timer van 4 uur. Als je binnen die 4 uur je apparaat niet ontsluit met Touch ID of Face ID, dan moet je verplicht je pincode intoetsen in plaats van Touch of Face ID. Je ervaart als gebruiker een klein ongemak omdat je die code elke week een keer moet invoeren, maar overall is het een voordeel qua beveiliging, aangezien je de routine om je code af en toe in te voeren versterkt, wat betekent dat je die code minder snel vergeet.

Maar als het gaat om deze permissie-dialoogjes: hier is geen versterking van een routine noodzakelijk, het is een excessieve eis. We worden juist minder gevoelig voor alle beveiligingswaarschuwingen. Bovendien hoort een computer ons herhalend werk uit handen te nemen, het apparaat zou ons geen extra zinloze handelingen moeten opdringen.

Hoplijk brengt de sterke reactie uit de gebruikersgemeenschap Apple ertoe om de ingeslagen weg te heroverwegen. Hier bovenop helpt het als mensen zelf ook direct bij Apple gaan klagen. Als je de publieke bèta van Sequoia gebruikt, dan kan je de Feedback Assistant gebruiken om een fout te melden bij het werken met deze meldingen. Wie de beta niet heeft zou kunnen werken met Apple's Feedback-pagina, bijvoorbeeld als je erover denkt om je Mac een upgrade te geven.