Apple heeft macOS Big Sur 11.5.2 uitgebracht. De toelichting heeft het alleen over “bug fixes”. Er zijn geen beveiligingsdetails. Maar wat is er dan gefixt? We hebben geen flauw idee! Moet je het meteen of later installeren? We hebben geen flauw idee! Mocht iemand het installeren, laat ons dan in de reacties weten of je ergens een verschil met de vorige versie merkt.

Twee zaken zonder geheimzinnigheid: de macOS 11.5.2 Big Sur-update is 2,54 GB groot op een 27-inch iMac van 2020 en je kunt hem installeren via Systeemvoorkeuren > Software-update.

Komt het voor dat je verschillende mogelijkhe internetverbindingen hebt — wifi, DSL, satelliet, mobiel — en niet één ervan voldoende snel en betrouwbaar is? Ik heb daar tegenwoordig geen last meer van, dus ik heb Speedify niet kunnen testen, maar ik vind het idee erachter interessant genoeg om het hier kort te vermelden.

Feitelijk is Speedify een VPN-in-software die belooft dat verschillende netwerkverbindingen gecombineerd worden tot één enkele verbinding die sneller, veiliger en betrouwbaarder is. Het koppelen van kanalen vebetert de prestaties, automatisch schakelen tussen de verschillende verbindingen ('failover') verhoogt de betrouwbaarheid, en automatische prioritering van audio- en videostromen maakt het ook geschikt voor streamen.

Ik kan me voorstellen dat Speedify handig is voor mensen die op het platteland wonen, met gammele DSL, slechte satelliet-dekking en onbetrouwbare mobiele verbindingen. Zelfs als geen van deze verbindingen op zichzelf betrouwbaar zijn, kunnen ze in combinatie uitstekend voldoen. Je zou het ook kunnen gebruiken als je veel met de trein reist; je kunt dan de wifi in de trein combineren met een mobiele verbinding om bijvoorbeeld onderweg te videobellen. Andere reizigers kunnen baat hebben bij het ondersteunen van de vaak overbelaste hotel- of congresinternetverbindingen met behulp van een mobiele verbinding. Met losse mobiele modems — sommige scenario's vereisen extra apparatuur — zou je zelfs mobiele verbindingen van twee verschillende aanbieders kunnen koppelen. Kort samengevat, als je bereid bent om te betalen voor meerdere accounts is Speedify wellicht de beste manier om sneller en betrouwbaarder internet te krijgen.

Speedify-apps zijn beschikbaar voor Mac, iOS, Windows, Android, en Linux. Je kunt het dertig dagen gratis uitproberen. Abonnementen met onbeperkte data zijn er vanaf $ 4,99 per maand, met een contract voor 3 jaar. Een los maandabonnement kost $ 14,99 per maand, je kunt er ook tussenin gaan zitten met een jaarabonnement voor $ 7,49 per maand. Je kunt maximaal vijf apparaten tegelijkertijd gebruiken en er zijn ook gezinsabonnementen met tot vijf afzonderlijke accounts.

Als je Speedify uitprobeert, laat ons dan in de reacties weten hoe je het gebruikt en hoe goed het werkt!

Met een van mijn andere petten op ben ik voorzitter en oproerkraaier van de Finger Lakes Runners Club. Vorig jaar ontwikkelde ik, vanwege de kans op meer door corona veroorzaakte annuleringen van races, de FLRC Challenge, een reeks van 10 virtuele races in de omgeving waarin renners meerdere parkoersen kunnen lopen, de resultaten kunnen registreren met de app Webscorer en de stand kunnen bekijken op een dynamisch scoreboard. Het was erg leuk om alle regels te bedenken, het ontwerp te coördineren en alle technologie in elkaar te zetten om het mogelijk te maken. Het is een grote hit in de gemeenschap. Dit jaar hebben 146 lopers tot nu toe meer dan 12.000 mijl bij elkaar gerend.

Om de FLRC Challenge in de gemeenschap te helpen promoten, heb ik tuinborden ontworpen en afgedrukt, die dingen die elk verkiezingsseizoen als paddestoelen uit de grond schieten. Clubleden schreven zich in om ze te ontvangen via een eenvoudig Google-formulier waarop ze hun naam en adres invulden. Toen de borden van Signs.com arriveerden, vroeg ik me af hoe ik deze het beste kon verspreiden. Onze omgeving is niet zo groot, dus Tonya en ik besloten om de middag van 4 juli rond te rijden en ze te plaatsen. (Het was heerlijk zomerweer, we reden in onze volledig elektrische Nissan Leaf en veel van de mensen die om borden vroegen zijn vrienden, dus het was een leuke manier om de dag door te brengen.)

Maar nu de vraag. Als je 43 verschillende adressen moet bezoeken, wat is dan de efficiëntste route? Het is gemakkelijk genoeg om een adres in te voeren in Apples Maps of Google Maps, en zelfs een of twee tussenstops toe te voegen. Maar 43 haltes in een optimale route? Het is mogelijk om een lijst met adressen te importeren in Googles My Maps, maar ik zag geen manier om een aangepaste kaart te laden in de iPhone-app Google Maps en deze van de ene plek naar de andere te laten navigeren.

Een beetje onderzoek wees uit dat MapQuest (herinner je je MapQuest nog uit de tijd dat we allemaal routebeschrijvingen afdrukten?) precies biedt wat ik nodig had. Met MapQuests RoutePlanner kun je tot 26 adressen invoeren die het programma kan herschikken om je de kortste route te geven. (Aanvankelijk zag ik niet in waarom het beperkt zou zijn tot 26 adressen, maar zodra ik een route bekeek, realiseerde ik me dat elk adres een enkele letter krijgt die de pin identificeert.) De beperking tot 26 haltes terwijl ik 43 adressen had bleek geen probleem te zijn, omdat het zinvoller was om naar enkele van de afgelegen haltes afzonderlijke trips te maken. Het was niet nodig om alles in één keer te doen.

Je kunt adressen één voor één invoeren, maar je kunt ook een lijst met adressen inplakken, één per regel, of een Excel- of CSV-bestand importeren, als je het adres, de stad, de staat en de postcode al in aparte kolommen hebt. Ik koos ervoor om te klikken op de adressen in de Google Sheet gemaakt door Google Forms, waarna ik de hele partij kopieerde en in RoutePlanner inplakte.

Door op de knop Get Directions te klikken, ging ik naar het tabblad Line by Line van RoutePlanner, waar ik naar beneden scrolde (en onderweg een foutief en daarom gemarkeerd adres repareerde), selecteerde ik “Allow us to re-order stops on your route”, en klikte ik op View Route Directions om mijn route op de kaart te zien. Ik heb toen de volgorde van een paar haltes aangepast op basis van lokale kennis.

Goed genoeg, maar de volgende vraag was hoe we die route konden vertalen naar iets waarmee een iPhone ons de weg kon wijzen. Het antwoord was om op de deelknop bovenaan te klikken. Dat leverde een dialoog op met een URL die ik kon sms'en, e-mailen of kopiëren naar mijn iPhone.

Toen ik die URL in Safari op de iPhone laadde, verscheen er een optie om te openen in de app MapQuest. Ik tikte op het kleine iPhone-pictogram om dat te doen en tikte vervolgens op de Start-knop.

(Om eerlijk te zijn, de vorige twee alinea's hebben me zojuist meer dan een week gekost om te schrijven, wat geen vertrouwen wekt in MapQuest. In het begin produceerden de korte URL's die MapQuest genereerde om de route te delen foutpagina's bij de meeste pogingen om te laden. Ik rapporteerde het probleem aan MapQuest en kreeg te horen dat ze eraan werkten om het op te lossen, maar kreeg nooit een bevestiging van een oplossing. Het lijkt nu echter te werken. Bovendien werkte bij recente pogingen noch de methode om via sms te delen, noch die om het via e-mail te doen, maar ik kon de URL wel op andere manieren naar mijn iPhone overzetten. Bij mijn pogingen om de problemen om te delen op te lossen, probeerde ik in teloggen op MapQuest om de route in My Maps op te slaan, maar ik werd steeds te snel uitgelogd om dat te doen. Vervolgens wilde, in Safari op de iPhone, de zwarte balk met de optie om in de app te openen pas verschijnen als ik Safari geforceerd afsloot en het opnieuw probeerde. Vorige maand had ik geen van deze problemen en deze keer heb ik ze uiteindelijk opgelost, maar het was wel frustrerend.)

Als je het in de auto eenmaal gebruikt, werkt de app MapQuest min of meer zoals Kaarten van Apple of Google Maps. Hij raakt soms een beetje in de war als je niet helemaal tot aan een bestemming komt. Eén keer vielen we terug op de lijstweergave en probeerden we te navigeren met behulp van lokale kennis, maar misten we de bestemming volledig. Ik raad aan om de aanwijzingen zorgvuldig te volgen en er zo min mogelijk van af te wijken, omdat je de app dan in de war brengt.

Net als “Een oplossing voor het maken van een certificaat met groepswensen ten tijde van een pandemie” (6 augustus 2021) is dit een oplossing voor een bepaald probleem dat de meesten van ons niet zullen hebben, maar als je het toch hebt, hoop ik dat je het nuttig vindt.

Het gebeurt niet vaak dat Apple toegeeft dat het er een rommeltje van heeft gemaakt, zeker niet na een aankondiging, maar in het interview met Apple software-chef Craig Federighi door Joanna Stern van Wall Street Journal werd vaak sorry gezegd. Het interview volgde op de eerste uitleg door het bedrijf van de strategie om materiaal van kindermisbruik (CSAM) te herkennen, en tegelijkertijd de mogelijkheid dat minderjaren worden bloodgesteld aan sexueel getinte afbeeldingen in Berichten te reduceren (zie “Veelgestelde vragen over Apples uitgebreide bescherming voor kinderen,” 7 augustus 2021).

De dwalingen van Apple begonnen met een verwarrende pagina op hun website die deze beide acties onterecht koppelden. Vervolgens werd er een FAQ gepubliceerd die veel vragen juist niet beantwoordde, werden er mediabijeenkomsten georganiseerd die soms wel, soms geen nieuwe informatie brachten, interviews gegeven door laaggeplaatste medewerkers voordat Federighi opdraafde voor het interview met de Wall Street Journal. Na CEO Tim Cook is Federighi met afstand de bekendste verantwoordelijke bij Apple en dat geeft aan dat hier echt wel wat moest worden rechtgezet. Na het interview plaatste Apple nog een document met uitleg, “Security Threat Model Review of Apple’s Child Safety Features.” En volgens Bloomberg heeft Apple personeel gewaarschuwd om op vragen voorbereid te zijn. PR-matig een ramp.

(Onze excuses voor onderstaande tekst als je hier nog niets over gelezen hebt. Er is te veel om samen te vatten, dus lees vooral eerst de eerder gepubliceerde materialen van Apple en onze artikelen - links hierboven.)

In het interview met de Wall Street Journal kreeg Stern meer dertails uit Federighi over wat Apple wel en niet scant en hoe CSAM herkend wordt en hoe hierover gerapporteerd zal worden. Ze heeft ook gezorgd voor meer verheldering over de beide ongelateerde technologieën die Apple tegelijkertijd aankondigde: CSAM herkenning en communicatieveiligheid in Berichten.

De eerste ontboezeming van Federighi is dat Apple “meerdere niveaus van controle” heeft ingebouwd in de CSAM herkenning. Hij vertelde Stern:

We brengen in China dezelfde software met dezelfde database uit als in Amerika en Europa. Als iemand Apple vraagt om ook op bepaalde andere content te letten zou Apple nee zeggen. Maar stel dat je dit niet vertrouwt. Je wil niet zomaar erop vertrouwen dat Apple nee zegt. Je wilt er zeker van zijn dat Apple er niet mee weg kan komen als het toch ja zou zeggen. Dat is feitelijk het doel dat we onszelf gesteld hebben met het uitbrengen van dit systeem. Er zijn meerdere niveaus van controle en dat zorgt ervoor dat je niet hoeft te vertrouwen op een enkele organisatie, of zelfs maar een enkel land, als het gaat om op welke afbeeldingen gescand worden.

Dit was de eerste keer dat Apple die niveaus ter sprake bracht in het systeem van CSAM-herkenning. Federighi zei verder dat er 30 afbeeldingen gematcht moeten worden bij de upload naar iCloud-foto's voordat Apple deze kan ontsleutelen via de overeenkomende veiligheidsvouchers. De meeste mensen weten waarschijnlijk ook niet dat de software van Apple overal dezelfde is. Tegelijkertijd werd er niet meer gezegd over die controlemechanismen in het interview.

Apple heeft na het interview ook een ander document gepubliceerd: “Security Threat Model Review of Apple’s Child Safety Features”. Hierop doelde Federighi toen hij sprak over meerdere niveaus. In dat document staat veel nieuwe informatie hierover, en over de architectuur.

Dit document geeft een betere uitleg over de CSAM-herkenning in het algemeen maar we vermoeden dat Apple ook nog wel wat aanpassingen heeft gemaakt aan het systeem na de eerste storm van protesten. Zou Apple anders deze informatie voor gebruikers - of veiligheidsonderzoekers - gepubliceerd hebben om te verifiëren dat de CSAM-hashes intact waren? Zou er dan gesproken zijn over de controle op het systeem door andere partijen op de campus van Apple? Afgezien van die vragen vonden we de volgende passages het belangrijkst:

• De CSAM hash-database op je apparaat wordt feitelijk genereerd door een dwarsdoorsnede te maken van twee databases van bekende illegale CSAM-afbeeldingen van organisaties voor kinderveiligheid, die onder controle staan van verschillende regeringen. In eerste instantie suggereerde Apple dat dit alleen de database van het National Center for Missing and Exploited Children (NCMEC) zou zijn. Materiaal wordt alleen herkend als het in beide databases voorkomt. Als er niet-CSAM materiaal in zo'n database komt is het onwaarschijnlijk dat dat in beide gebruikte databases het geval is.
• Omdat Apple wereldwijd dezelfde versie van elk van zijn besturingssystemen distribueert en de versleutelde CSAM hash-database wordt gebundeld in plaats van te worden gedownload of bijgewerkt via het internet, beweert Apple dat beveiligingsonderzoekers elke release zullen kunnen inspecteren. We zouden kunnen speculeren dat Apple een rechtszaak tegen beveiligingsbedrijf Corellium heeft laten vallen over zijn software (waarmee beveiligingsexperts gevirtualiseerde iOS-apparaten kunnen draaien voor onderzoeksdoeleinden) om zijn bewering over de waarschijnlijkheid van inspectie van buitenaf geloofwaardiger te maken.
• Apple zegt dat het een Knowledge Base-artikel zal publiceren met een root hash van de versleutelde CSAM hash-database die wordt meegeleverd met elke versie van elk Apple-besturingssysteem dat de functie ondersteunt. Onderzoekers (en gewone gebruikers) kunnen de root hash van de versleutelde database op hun apparaat vergelijken met de verwachte root hash in het Knowledge Base-artikel. Ook hier stelt Apple dat beveiligingsonderzoekers dit systeem zullen kunnen verifiëren. Wij geloven dat dit het geval is op basis van de manier waarop Apple cryptografie gebruikt om zijn besturingssystemen te beschermen tegen wijzigingen.
• Dit hashen van de database maakt ook auditing door derden mogelijk. Apple zegt dat het - in een beveiligde omgeving op een campus - een auditor technisch bewijs kan leveren dat de kruising van hashes en blinding correct is uitgevoerd. De suggestie is dat deelnemende kinderveiligheidsorganisaties zo'n audit zouden willen uitvoeren.
• NeuralHash is niet gebaseerd op classificeren door machinaal leren, zoals bijvoorbeeld Foto's afbeeldingen van katten kan identificeren. In plaats daarvan is NeuralHash puur een algoritme dat is ontworpen om te valideren dat een afbeelding hetzelfde is als een andere, zelfs als een van de afbeeldingen op bepaalde manieren is gewijzigd, zoals het formaat aanpassen, bijsnijden en opnieuw inkleuren. Bij de tests van Apple met 100 miljoen niet-CSAM-afbeeldingen werden 3 vals positieve resultaten gevonden in vergelijking met de database van NCMEC. Bij een aparte test van 500.000 pornografische afbeeldingen voor volwassenen vergeleken met de database van het NCMEC, werden geen vals positieven gevonden.
• Zoals in het interview wordt onthuld, zal Apples initiële match-drempel naar verwachting 30 afbeeldingen zijn. Dat betekent dat iemand minstens zoveel foto's van bekend illegaal CSAM moet hebben geüpload naar iCloud-foto's voordat het systeem van Apple ook maar weet dat er een match is. Op dat moment zouden menselijke reviewers op de hoogte worden gebracht om de lage-resolutievoorvertoningen te bekijken die gebundeld zijn met de matches die kunnen worden ontsleuteld, omdat de drempel is overschreden. Die drempel zou ervoor moeten zorgen dat zelfs een extreem onwaarschijnlijk vals positieve uitslag geen nadelig effect heeft.
• Omdat de reviewers van Apple wettelijk geen toegang hebben tot de originele databases van bekende CSAM, kunnen ze alleen bevestigen dat de gedecodeerde voorvertoningen CSAM lijken te zijn, en niet dat ze overeenkomen met bekende CSAM. (Men verwacht dat de beelden gedetailleerd genoeg zijn om menselijk naakt te herkennen zonder individuen te identificeren). Als een reviewer denkt dat de beelden CSAM zijn, schorst Apple het account en draagt de hele zaak over aan het NCMEC, dat de daadwerkelijke vergelijking uitvoert en de wetshandhaving kan inschakelen.
• In het hele document gebruikt Apple herhaaldelijk de zinsnede "is onderworpen aan code-inspectie door beveiligingsonderzoekers, net als alle andere beveiligingsclaims voor iOS-apparaten". Dat is niet per se auditing, maar het geeft aan dat Apple weet dat beveiligingsonderzoekers proberen om zijn beveiligingsclaims te bevestigen en dat het hen aanmoedigt om in deze specifieke gebieden te graven. Het zou een aanzienlijke reputatie- en financiële winst zijn voor een onderzoeker om een kwetsbaarheid in het CSAM-detectiesysteem te identificeren, dus Apple heeft waarschijnlijk gelijk als het stelt dat zijn besturingssysteem-uitgaven nog meer dan voorheen aan een kritisch onderzoek zullen worden onderworpen.

Ik ben verbijsterd over hoe grondig Apple deze aankondiging heeft verknoeid. Het aanvankelijke materiaal riep te veel vragen op zonder bevredigende antwoorden voor zowel technische als niet-technische gebruikers, zelfs na meerdere interviews en documenten. Het lijkt erop dat Apple dacht dat we ze een schouderklopje zouden geven en ze zouden bedanken voor hun transparantie, omdat ze überhaupt iets hadden gezegd. Andere aanbieders van foto-opslag in de cloud scannen immers al alle geüploade foto's op CSAM zonder hun gebruikers daarvan op de hoogte te stellen - alleen al in 2020 heeft Facebook meer dan 20 miljoen CSAM-meldingen ingediend bij het NCMEC.

Maar Apple heeft zwaar onderschat hoezeer het impliceren van "Vertrouw ons" niet te rijmen valt met "Wat op je iPhone gebeurt, blijft op je iPhone". Het lijkt er nu op dat Apple ons in plaats daarvan voorhoudt, "Vertrouwen is goed, controle is beter" (een uitdrukking met een fascinerende geschiedenis die zijn oorsprong vond als een parafrase van Vladimir Lenin en Jozef Stalin voordat hij in het Engels werd gepopulariseerd door Ronald Reagan). We zullen zien hoe beveiligings- en privacy-experts op deze nieuwe onthullingen reageren maar Apple lijkt nu in ieder geval beter zijn best te doen om alle relevante details te delen.