Een paar weken terug vroegen we in Moeten we de financiële gegevens van Apple blijven volgen? (2 augustus 2024) of we aandacht zouden moeten blijven besteden aan het publiceren van de financiële kwartaalresultaten van Apple. Noch Michael Cohen noch ik heeft enige financiële achtergrond, en andere publicaties hebben uitgebreidere aandacht voor dit fenomeen. Ik heb deze vraag in een peiling gesteld aan jullie als lezers, en gaf je de mogelijkheid om je stem uit te leggen. Ik had op zich niet zo'n vastomlijnd beeld van hoe de stemmen verdeeld zouden zijn, maar de meerderheid wilde graag dat we door zouden gaan, dus deze dienst wordt kennelijk nog altijd gewaardeerd.

Degenen die zeiden dat ze het prima zouden vinden als we de berichtgeving stopzetten, zeiden dat ze de informatie uit andere bronnen meestal al hadden gezien en dus alles wat we schreven oversloegen. Dat was mijn angst geweest, maar zoals uit de stemmen en commentaren bleek, waren meer mensen van mening dat onze berichtgeving een goed punt was om de financiële informatie in context te plaatsen. Heel wat mensen zeiden dat ze niet zo geïnteresseerd waren in de financiële details, maar dat ze ons commentaar waardeerden en onze analyse waarin werd uitgelegd waarom bepaalde dingen waren gebeurd. Een ander veelgehoord refrein was dat TidBITS voor veel mensen de belangrijkste bron van Apple-informatie is, dus vinden ze de snelle overzichten van Apple's zaken nuttig om de algehele gezondheid van het bedrijf te begrijpen.

Dus ja, we zullen doorgaan met het bespreken van de financiële gegevens van Apple en ik zal meer moeite steken in de analyses en het commentaar dat mensen waardevol vinden, samen met grafiekaanpassingen om extra perspectief te bieden. Ik gok dat Apples inkomsten-presentatie voor het vierde kwartaal van 2024 op 31 oktober 2024 zal plaatsvinden, en met een beetje geluk zal het meer een 'treat' (traktatie) dan een 'trick' (streek) zijn. (Een Halloween-referentie, voor internationale lezers buiten het steeds groter wordende bereik van deze feestdag.)

Ken je dat, dat als je naar je fitnessles gaat buiten de normale openingstijden van het gebouw en de instructeur een wig in de deur heeft gedaan om hem open te houden, iemand per ongeluk de wig heeft laten losschieten, dus de deur op slot zit als je aankomt en je er dus niet in kan?

watchOS 10.6.1 is het digitale equivalent hiervan voor Apple Fitness+. Ik gok dat tvOS 17.6.1 hetzelfde doet, maar omdat het geen toelichting of informatie op het Software-updatescherm heeft, is er geen manier om het zeker te weten. Geen van beide bevat beveiligingsupdates met CVE-vermeldingen.

Als je Apple Fitness+ gebruikt, update dan watchOS in de app Watch op je iPhone in “Watch > Algemeen & Software-update” en update tvOS door “Instellingen > Systeem > Software-updates > Werk software bij” te openen. Anders raad ik aan om te wachten op de volgende watchOS-update en tvOS zichzelf te laten updaten.

In de nieuwste bèta van macOS 15.0 Sequoia heeft Apple iets toegegeven op de enorm toegenomen frequentie van toestemmingsverzoeken in de eerdere update; apps meldden om de haverklap dat ze toegang wilden tot de mogelijkheid om schermopnames te maken. (Zie “Overmatig vragen om toestemming in macOS 15 Sequoia zal beveiliging schaden,” 12 augustus 2024). Chance Miller van 9to5Mac meldt dat de nieuwste bèta van macOS 15.0 (maar niet die van macOS 15.1, die ik zelf heb) de teugels wat laat vieren. Toch blijven de herhaalde verzoeken - kennelijk voortkomend uit een misleid idee over de manier waarop mensen beveiligingsgevaar inschatten - onnodig.

In de voorgaande versie van macOS 15.0 bèta werd gebruikers in Sequoia elke week gevraagd of ze gegeven schermopname-toestemming wilden handhaven, en daarbij popte dezelfde vraag iedere keer dat herstart of uitgelogd werd nog eens op. Bedenk hierbij dat verschillende apps het schermopname-verzoek om volstrekt legitieme redenen doen. Ze zijn helemaal niet bezig om pixels zomaar in een foto- of videobestand te plakken. Ik denk aan apps als Adobe Photoshop, Adobe Premiere, Bartender, Default Folder X, Display Link, Google Chrome, Ice, Keyboard Maestro, Slack, Splashtop, TextSniper en Zoom.

Met deze laatste bèta van macOS 15.0 Sequoia krijg je de genoemde bevestigingsvragen maandelijks in plaats van wekelijks. Bovendien zijn de extra meldingen bij herstart of uitloggen verdwenen. Miller zegt dat de tekst van de vraag nu ook specifieker geformuleerd is:

[App-naam] vraagt om de private window picker van het systeem te omzeilen en rechtstreeks toegang te krijgen tot uw scherm en audio. Hiermee kan [App-naam] uw scherm- en systeemaudio opnemen, inclusief persoonlijke of gevoelige informatie die zichtbaar of hoorbaar kan zijn.

Het verminderen van de frequentie van deze herhaalde machtigingenprompts is een stap in de goede richting, maar de algehele verandering is nog steeds een vergissing. Een maandschema is minder vervelend dan wekelijkse prompts, maar het is irritanter dan wat we momenteel gewend zijn, zonder dat Apple aangeeft waarom de vermeende extra beveiliging nodig is. Er bestaan zeker voorbeelden van malware die stiekem opnames maakt van het scherm van geïnfecteerde Macs, maar de meeste daarvan dateren uit de tijd dat macOS gebruikers nog helemaal niet vroeg om toestemming voor schermopnames. Het ging bijvoorbeeld om FruitFly (2003–2017) en Mokes (2016). In 2021 gebruikte , XCSSET een zero-day-beveiligingslek waarmee het verzoek om toestemming omzeild werd. Dit deed het programma door zichzelf te injecteren in betrouwbare apps die dergelijke toestemming al hadden. Maar ook in die situatie hadden herhaalde verzoeken om toestemming niet geholpen.

En dan nog: het specifieker maken van de taal in systeemmeldingen heeft zeker een waarde, maar zelfs ik heb geen idee wat “vraagt om de private window picker van het systeem te omzeilen” betekent. Ik kan me niet voorstellen dat een gebruiker die minder bekend is met de hele techniek van macOS ook maar enig idee heeft. Het toelaten van obscure technische taal in een melding voor de gewone gebruiker is een probleem op zich. Zo'n melding is bedoeld om te informeren over een mogelijk beveiligingsrisico, maar deze taal versterkt het gevoel dom te zijn, dat veel mensen in deze situaties toch al hebben. Deze taal zal echt niet helpen: ook nu zal iemand die in een eerdere situatie positief op een prompt reageerde, bij de tweede keer echt niet opeens weigeren. Het is veel waarschijnlijker dat mensen zich afkeren van het prompt-koeterwaals, en nog minder waakzaam worden bij gebruik van hun systemen.

Veel mensen hopen dat het voorbeeld van de Persistent Content Capture-rechten uitkomst kunnen bieden. Ontwikkelaar Craig Hockenberry wees erop dat apps met toestemming op basis daarvan een uitzonderingspositie zouden kunnen krijgen. Maar Apple noemt deze rechten alleen als “een Booleaanse waarde die bepaalt of een Virtual Network Computing (VNC)-app blijvend toegang houdt tot het maken van schermopnames”, en zei niets over apps die om andere redenen om deze rechten vragen.

Als dat geen oplossing is, zal ik toch moeten volhouden wat ik in mijn eerdere artikel adviseerde. Toon de gebruiker een paar dagen na de eerste gegeven toestemming voor schermopname een "verleen langer toestemming"-verzoek. De gebruiker denkt dan nogmaals na, op het moment dat de installatie van de app nog vers in het geheugen ligt. Dit biedt de mogelijkheid om een machtiging in te trekken, of de app helemaal te verwijderen - als deze maar voor korte tijd nodig was. Stel nu, dat een app door iemand anders met admin-rechten geïnstalleerd werd, iemand met kwade bedoelingen (bijvoorbeeld iemand die zijn partner mishandelt), dan zou het handig zijn de tweede toestemmingsvraag op een willekeurig tijdstip te laten verschijnen. Het is dan minder makkelijk om zo'n app stiekem te installeren.

Negatieve reacties van ontwikkelaars, bètatesters en uit de media, heben al gezorgd dat Apple enigszins teruggekrabbeld is. Toch ben ik er niet voor om het huidige compromis te accepteren, want we weten nog steeds niet hoe Apple überhaupt tot deze foute keuze kwam. Ik raad iedereen aan om Apple te vertellen wat je ervan vindt. Als je de publieke bèta van Sequoia gebruikt, maak dan gebruik van de Feedback Assistant om nog een melding te doen over deze toestemmingsverzoeken. Wie niet in het bèta-testprogramma zit kan Apple bereiken via de Feedback-knop, bijvoorbeeld voor de Mac die je nog wilt kopen.

Jarenlang bestond het downloaden van back-ups van de internet-back-updienst Backblaze uit het gebruiken van een langzame, rammelende web-interface. Die is er nog, en je kunt ook een harde schijf krijgen met je bestanden, maar dat is alleen de moeite waard als je veel gigabytes aan gegevens terug wil plaatsen. (Zie Backblaze verhoogt de volledig restitueerbare prijs voor herstelschijven, 18 juli 2024.)

In september 2023 echter introduceerde Backblaze de app Backblaze Restore, tegelijk met Backblaze versie 9.0. Het is een native Mac-app die een eenvoudige maar effectieve interface biedt voor het terugplaatsen van bestanden op je Mac. Je kunt bepalen waar je ze wilt hebben, identieke bestanden op de oorspronkelijke plek overschrijven of juist behouden, of een specifieke download-locatie kiezen.

Het ophalen van de bestandenlijst bij Backblaze Restore kostte bij mij alleen meer dan tweeënalf minuut. Ik ga dan altijd even wat anders doen, maar als je te lang wacht krijg je een time-out en dan moet je opnieuw beginnen. En als je op de knop 'View Restore Progress' klikt moet je ook weer opnieuw beginnen. Idealiter zou Backblaze de lijst in de achtergrond moeten bewaren, zodat Backblaze Restore alleen bij het opstarten de wijzigingen zou hoeven te downloaden.

Zodra je de bestandenlijst geladen hebt kun je erdoorheen navigeren, de bestanden selecteren en op de knop Restore klikken. De snelheid is dan indrukwekkend: een bestand van 1 GB werd via mijn 300 Mbps verbinding in ongeveer 30 seconden gedownload.

Als het tenminste werkt. Toen ik het eerdere artikel schreef wilde ik de snelheid testen. Ik begon dus met een restore, en ik kreeg een wonderlijke foutmelding dat er iets helemaal verkeerd was gegaan. (Niet gewoon verkeerd, helemaal verkeerd. Dat wil je nu net zien als je verloren gewaande gegevens terug wil halen!) Opnieuw proberen maakte geen verschil.

Het is wel mogelijk om snel in de logbestanden van Backblaze Restore te kijken, en toen zag ik dat er sprake was met een probleem met bevoegdheden waardoor er geen tijdelijke map aangemaakt kon worden om de gedownloade bestanden in op te slaan. En daardoor konden de volgende stappen niet gezet worden.

Ik was toch al verwikkeld in een e-mailgesprek met Yev Pusin van Backblaze, dus ik vroeg hem naar deze fout. Hij reageerde snel met een suggestie van de helpdesk van Backblaze om te kijken of alle bevoegdheden van de map in de gearceerde tekst hierboven op zowel lezen als schrijven stond, en dat bleek inderdaad niet het geval. In het Toon info-venster van de Finder stonden ze op aangepaste instelling, en ontbraken de bevoegdheden om uit te voeren: drw-rw-rw-

Zodra ik deze in het Toon info-venster van de Finder alle drie had aangepast naar lezen en schrijven (strikt genomen is alleen de eerste noodzakelijk) kon ik bestanden terughalen. Yev zei dat de helpdesk een paar andere mensen met hetzelfde probleem geholpen had, en met mijn foutmelding als de aanleiding is er nu informatie toegevoegd aan de documentatie van Backblaze. Eind goed al goed, want nu zou iedereen met een vergelijkbaar probleem de oplossing snel moeten kunnen vinden.