Van alle processen die zich onder de motorkap van macOS afspelen zijn er maar weinig zo mysterieus als MobileDeviceUpdater. Als macOS een update nodig heeft van de driver die de communicatie verzorgt met een via USB verbonden iPhone of iPad, dan start dit proces een installatieprogramma dat niet lijkt op enige andere macOS-activiteit.

Ondanks deze waarschuwing van MobileDeviceUpdater denken mensen soms dat er sprake is van kwaadwillende software of een poging tot phishing. Het is echter een echte en noodzakelijke update die je moet installeren om je Mac te laten communiceren met je iPhone of iPad. Omdat updates van je apparaten niet synchroon lopen, kan het zomaar gebeuren dat je in een situatie terecht komt waarbij een oudere versie van macOS niet weet hoe om te gaan met een nieuwere versie van iOS of iPadOS.

Als je deze waarschuwing ziet nadat je je iPhone of iPad aan je Mac gekoppeld hebt, moet je op de knop Installeren klikken. Je zult dan een venster zien dat de voortgang aangeeft van het downloaden en installeren. Daarna kun je weer gewoon verder - of tenminste, dat zou moeten!

De installatie kan een foutmelding geven. Wat doe je dan? Apple geeft geen oplossingen voor de gevallen waarin je onderstaande foutmelding ziet.

Ik liep zelf een maand geleden voor het eerst tegen dit probleem aan toen ik mijn iPad Pro via USB verbond met een 27-inch iMac uit 2020 die macOS 12 Monterey draaide. Ik was niet eens van plan om te synchroniseren, ik wilde alleen maar laden. Hoewel ik anders nooit op deze manier laadde, dacht ik dat ik maar beter de software kon installeren zodat ik in de toekomst van dit venster gevrijwaard zou blijven. Dus je kunt je mijn irritatie voorstellen toen het installatieprogramma dat ik eigenlijk niet eens wilde draaien vastliep. Ik probeerde of het herstarten van de iPad of de Mac zou helpen, maar dat maakte beide keren geen verschil.

Toeval bestaat niet: een paar dagen later plaatste TidBITS-lezer James Weil een oplossing op TidBITS Talk. Een geluksdag voor mij, en vandaag is het dat misschien ook voor jou. Volg deze stappen:

1. In macOS van vóór macOS 13 Ventura open je Systeemvoorkeuren > Delen; in Ventura open je Systeminstellingen > Algemeen > Delen.
2. Haal daar de vinkjes weg voor iedere voorziening die ingeschakeld is. In mijn geval was dat Mediadeling, Materiaalcaching en AirPlay-ontvanger.

   

3. Haal de kabel uit de iPhone of iPad en doe hem er weer in.
4. Als MobileDeviceUpdater daar om vraagt, start je de installatie. Deze keer zou de software-update moeten downloaden en installeren. Opvallend genoeg duurde de download flink langer dan toen hij vastliep (enige minuten). Dat lijkt er op te wijzen dat het probleem gerelateerd is aan de download.
5. Vervolgens kun je de voorzieningen die je in Delen had uitgeschakeld weer inschakelen.

Omdat ik dit in december succesvol kon afronden na het bericht van James, was ik een beetje verrast dat ik nu weer dezelfde foutmelding kreeg. Het lijkt erop dat het probleem kan terugkeren, waardoor je elke keer als je Mac en iPhone of iPad niet meer 'in sync' zijn dit proces moet herhalen.

Ik vond het ook verwarrend dat niet een van de voorzieningen zelf het probleem leek te veroorzaken. Deze keer schakelde ik de drie voorzieningen één voor één uit, waarna ik de installatie probeerde voordat ik de volgende uitschakelde. Ik verwachte niet dat Mediadeling of Airplay-ontvanger het probleem zou zijn, maar ik kon me een probleem voorstellen tussen MobileDeviceUpdater en Content Caching. Maar nee: het probleem trad elke keer op als ik een van deze voorzieningen aan had gelaten. Pas toen ik ze alledrie had uitgeschakeld, verliepen de download en installatie goed, net zoals James suggereerde.

Deze oplossing is nogal frustrerend, vergelijkbaar met de gekke oplossingen uit een ver verleden als het opnieuw opbouwen van je bureaublad of het legen van de PRAM. Als iemand denkt te weten wat het probleem veroorzaakt hoor ik het graag, maar tot die tijd kan ik niet garanderen dat deze oplossing voor jou zal werken. Gelukkig is het wel eenvoudig om hem uit te proberen. (En als het niet werkt, zet het dan in het commentaar op TidBITS Talk, zeker als je een andere oplossing gevonden hebt.)

Apple zou er tijd in moeten steken om een definitieve oplossing voor dit probleem te vinden.

Ik hou van kookboeken. Ik blader ze gretig door en probeer me voor te stellen hoe moeilijk de recepten zijn en hoe de gerechten zullen smaken. Sommige schrijvers, zoals J. Kenji López-Alt en Deb Perelman, zijn erg grappig en daarbij hebben kookboeken vaak aantrekkelijke foto’s die er altijd mooier uitzien dan wat uiteindelijk op mijn borden belandt.

Ik schaam mij er niet meer voor dat een kookboek vaak na de eerste euforie op de boekenplank terecht komt en dat ik het alleen nog af en toe open voor een handjevol recepten. Soms zijn die favoriete recepten gemarkeerd met indextabs of boekenleggers, maar vaker nog vertrouw ik op de index. Hoezeer ik de receptenzoekmachine Eat Your Books ook toejuich, heb ik de site nooit in mijn kookroutine op kunnen nemen (zie “Gebruik het web om met je boeken te koken,” 17 maart 2022) en moet ik dus vaak door een kookboek bladeren om dat ene recept te vinden dat ik regelmatig maak.

Een paar jaar geleden ging Tristan studeren en op kamers en begon hij zelf te koken. Hij wilde van ons recepten hebben van wat hij in zijn jeugd zoal had gegeten, dus gingen we voor Paprika, een briljante recepten-app, die je zowel op iPhone, iPad, en Mac kunt gebruiken, en zelfs op Android en Windows. We schreven hier eerder over, zie “FunBITS: Paprika, receptenbeheer voor iPhone, iPad en Mac,” 14 maart 2014. Ik weet niet zeker of er toen een bundel bestond, maar nu zijn de apps alleen afzonderlijk te koop. Hoe dan ook, het toont maar weer eens aan hoe handig Delen met gezin is, want Tonya, Tristan en ik kunnen nu allemaal bij onze familierecepten, op elk apparaat dat we bij de hand hebben.

Een lastiger punt met Paprika - en alle digitale alternatieven voor papieren kookboeken - is het importeren van recepten. Paprika doet het prima als het gaat om recepten op websites die werken met de standaard deelextensie, of wanneer je een website bekijkt in Paprika's ingebouwde browser. Maar de meeste papieren kookboeken hebben geen zuster-websites, en kooktijdschriften zoals Cook’s Illustrated zijn vaak zo onaardig om extra geld te vragen voor toegang tot de online recepten die je op papier kunt lezen.

Mijn aanvankelijke methode om het proces van een recept van een kookboek overzetten naar Paprika te versnellen was om Stembediening te gebruiken, wat nog steeds beter is dan de verbeterde dicteerfunctie beschikbaar die beschikbaar is op het toetsenbord van iOS/iPadOS 16 (zie “Hoe iOS en macOS dicteren kan leren van dicteren met stembediening,” 31 augustus 2020). Het is eenvoudig om een recept zo voor te lezen dat het goed genoteerd wordt, hoewel je interpunctie en nieuwe regels er wel bij moet zeggen. Met wat we geïmporteerd hebben van het web en wat we hebben gedicteerd hebben we nu zo'n 200 favorieten in Paprika, maar ik moet nog vaak recepten in kookboeken opzoeken.

Met de opkomst van door AI gedreven scan-mogelijkheden, vroeg ik me onlangs af of ik in Paprika een foto kon nemen van een recept, vervolgens OCR op de tekst kon uitvoeren waarbij de opmaak en verdeling zou worden herkend om de omschrijving, ingrediënten, bereidingswijzen en notities juist uit te splitsen. Helaas blijkt het antwoord hierop nee, en hoewel een dergelijke functie wel bestaat in andere recepten-apps, waaronder CookBook, het door lezers aangedragen Mela en Recipe Keeper, wil ik niet overstappen van Paprika, alleen maar om die functie.

Toen ik echter over het scannen nadacht, bedacht ik me dat de Livetekst-functie die Apple introduceerde in iOS 15 tekst kan invoeren die het detecteert in de zoeker van de camera. Hoewel Livetekst zeker cool is, had ik er tot nog toe geen nut voor gevonden. Met Paprika blijkt het importeren van een recept van een kookboek maar een paar minuten te duren, veel minder tijd dan dicteren.

Hier volgt hoe ik Livetekst heb gebruikt om het recept voor “gemarineerde boerenkoolsalade met kikkererwten en sumac-uien” uit J. Kenji López-Alt’s The Food Lab, te importeren, inclusief wat handgeschreven notities.

Begin met het aanmaken van een nieuwe recept in Paprika. Neem dan de volgende stappen, die zijn geïllustreerd in de schermafbeeldingen hieronder:

1. Tik op het Naam-veld alsof je een tekst gaat typen.
2. Tik op de Scan tekst-knop die verschijnt. De Livetekst camera-zoeker vervangt het toetsenbord onderaan het scherm.
3. Positioneer de tekst die je wilt scannen in de zoeker en verifieer dat er gele randen omheen staan.
4. Tik op de blauwe voeg in-knop. (En nee, ik heb geen idee waarom Apple die in kleine letters heeft gezet.)
5. Herhaal met de andere velden in het recept: Omschrijving, Ingrediënten, Bereidingswijze en meer.

 

 

Enkele opmerkingen en tips naar aanleiding van de schermafbeeldingen:

• In dit recept is de naam opgedeeld in meerdere korte regels, wat goed werkt met Livetekst. Wanneer je wordt geconfronteerd met een lange regellengte voor de naam of andere delen van het recept, is het moeilijk om de gewenste tekst in de zoeker te krijgen zonder ook meer tekst boven of onder het recept vast te leggen. Het kan zijn dat je meer tekst moet invoegen dan je wilt en die achteraf moet verwijderen.
• Receptnamen zijn vaak in hoofdletters, die Livetekst bewaart. Dat stoorde me, dus heb ik een opdracht gemaakt die geselecteerde tekst omzet in een titel. Helaas is hij een beetje omslachtig in gebruik. Om een naam in hoofdletters te veranderen nadat hij is ingevoegd, moet je in het Naam-veld tikken, op Alles selecteren tikken, op het deelpictogram tikken, deze opdracht Change Case selecteren, het deelblad sluiten, op de nog geselecteerde tekst tikken en op Plakken tikken. Met de app Text Case ($ 2,99) hoef je wellicht het deelblad niet meer te sluiten, maar dat is geen grote winst. Een eervolle vermelding voor TidBITS Talk-lezer Nalarider, die erop wees dat wie de Mac-versie van Paprika heeft, Keyboard Maestro of een ander Mac-hulpprogramma kan gebruiken.
  
• Livetekst geeft een voorbeeld van de tekst die moet worden ingevoegd in het doelveld, waardoor je kan denken dat de taak is voltooid. Maar nee, het is pas klaar als je op de blauwe voeg in-knop tikt om de voorbeeldtekst vast te zetten. Die fout maak ik nog wel eens.
• Regeleinden zijn lastig voor Livetekst. Soms voegt het onnodige regeleinden toe; op andere momenten laat het tekst door elkaar lopen die over regels verdeeld zou moeten zijn. Het is niet verschrikkelijk, maar je moet vaak wat bewerken om de gewenste visuele ruimte te maken.
• Ingrediëntenlijsten bevatten vaak breuken zoals ½, en ik was onder de indruk dat Livetekst deze correct opnam en invoegde. Paprika bevat speciale sneltoetsen voor het invoegen van gewone breuken, maar met dicteren worden alleen gewone tekens ingevoegd, zoals 1/2.
• Het is niet ongewoon dat een ingrediëntenlijst verdeeld is over twee kolommen. Als dat gebeurt, scan dan eerst de linkerkolom en dan de rechter. Beide tegelijk scannen levert niet het gewenste resultaat op. Nadat je de linkerkolom hebt gescand, tik je eronder in het veld Ingrediënten, je zult zien dat de knop ‘Tekst scannen’ is geslonken tot een pictogram. Maar het werkt nog steeds hetzelfde.
• Hoewel Livetekst meer moeite heeft met handschriften dan met gedrukte tekst, doet het het nog steeds goed genoeg dat het meestal de moeite waard is om de gescande tekst te accepteren en later te bewerken.
• Lees na het scannen het hele recept door om er zeker van te zijn dat Livetekst geen fouten heeft gemaakt die tot ernstige toestanden leiden, zoals het interpreteren van een gekrabbelde "¼ theelepel zout" als "4 theelepel zout". Ook "t" en "T" door elkaar halen zou slecht zijn. Ik heb in de recepten die ik heb geïmporteerd geen fouten van deze aard opgemerkt, maar sommige zijn onvermijdelijk, vooral bij handgeschreven notities.

Het bijzondere aan het scannen van recepttekst is natuurlijk dat veel mensen grote verzamelingen recepten op papier hebben. Livetekst zal zijn magie doen op elke analoge tekst die je wilt digitaliseren, of het in een speciale app zoals Paprika is of willekeurig welke andere app die tekstinvoer accepteert.

Hoe heb jij Livetekst gebruikt om tekst te scannen?

LastPass CEO Karim Toubba heeft aangekondigd dat het bedrijf in wachtwoordbeheer afgelopen maand doelwit is geweest van een cyberaanval, waarbij de aanvallers niet-versleutelde gegevens van klantenaccounts en -kluizen met versleutelde gebruikersnamen en wachtwoorden hebben buitgemaakt .

Voor LastPass is dit een potentiële nachtmerrie maar de meeste klanten hebben weinig te vrezen, omdat de Zero Knowledge beveiigingsarchitectuur van het bedrijf voorkomt dat ze toegang hebben tot of kennis van het primaire wachtwoord van hun gebruikers - de gestolen gegevens omvatten geen primaire wachtwoorden. Vanwege deze beveiligingsmaatregel zou het niet mogelijk moeten zijn dat de aanvallers de gestolen gebruikersnamen en wachtwoorden kunnen ontcijferen.

LastPass is betrekkelijk open geweest over de aanval; ze hebben laten weten wanneer het gebeurde en kwamen deze week ook met aanvullende gegevens. Hoewel het op dezelfde locatie aanwezige ontwikkelgedeelte van LastPass niet is aangevallen was de aanvaller wel in staat om informatie die bij een eedere aanval in augustus 2022 op het account van een ontwikkelaar werd buitgemaakt te gebruiken om het account van een andere medewerker aan te vallen en informatie uit een cloud-opslag te ontvreemden die LastPass als back-up gebruikt. (Naar het zich laat aanzien zijn al deze gebeurtenissen onderdeel van een enkele aanval.)

Dit incident toont wel kwetsbaarheden in de beveiligingsaanpak van LastPass. De gestolen gegevens omvatten onversleutelde klantaccount-informatie (namen, adressen en telefoonnummers maar geen credit card-gegevens) en versleutelde klantenkluis-gegevens. LastPass beveiligt gebruikersnamen, wachtwoorden, beveiligde notities en formulier-gegevens met een 256-bit AES versleuteling; die kunnen alleen ontsleuteld worden met een unieke sleutel die gebaseerd is op het primaire wachtwoord van een gebruiker. In gebruikerskluizen zijn URLs van websites die geassocieerd zijn met wachtwoorden echter niet versleuteld. Dat is wel een probleem.

Ernstiger is dat LastPass volledig afhankelijk is van dat door een gebruiker gekozen primaire wachtwoord om gegevens te versleutelen. Hoewel het bedrijf de minimumeisen die aan die wachtwoorden gesteld worden heeft verzwaard, kunnen gebruikers hun wachtwoord nog steeds zo zwak maken dat ze kwetsbaar zijn voor kraken. Apple’s iCloud Keychain, de cloudopslag van 1Password en een aantal andere oplossingen combineren apparaat-specifieke sleutels met primaire wachtwoorden of account logins en zijn daarmee veel minder kwetsbaar - een aanvaller moet naast een kluis of wachtwoord ook toegang krijgen tot het betreffende apparaat.

Wat moeten LastPass-gebruikers nu doen?

Als je je primaire LastPass wachtwoord uitsluitend bij LastPass hebt gebruikt en de standaardinstellingen van het bedrijf niet hebt gewijzigd adviseert het bedrijf op dit moment geen specifieke acties. (De standaardinstellingen vereisen een primair wachtwoord van minimaal 12 tekens en specificeren een hoog aantal iteraties - 100,100 — in het PBKDF2 algoritme voor het versterken van wachtwoorden.)

Een brute-krachtaanval op je primaire wachtwoord zou succesvol kunnen zijn als je dat ook op een andere gecompromitteerde site hebt gebruikt, als je een wachtwoord van minder dan 12 tekens hebt ingesteld (doe dat nooit!), of de standaardinstellingen voor het versterken van wachtwoorden minder hard hebt gemaakt. (Sommige oude gebruikers kwamen er achter dat hun instellingen voor het PBKDF2 algoritme veel lager waren, van 500 tot 5000 — je kunt dat hier controleren.) Als een van deze zaken op jou van toepassing is wijzig dan onmiddellijk je primaire wachtwoord en zet multifactor verificatie aan. (Gebruik de LastPass Authenticator app: klik voor instructies Features & Tools en dan Multifactor Authentication in het LastPass ondersteuningsportaal.)

Omdat de kluizen gestolen werden is het niet mogelijk om de integriteit van de gegevens in die kluizen te beschermen - die gegevens zijn al in de handen van de dieven. LastPass adviseert mensen die het risico lopen dat hun primaire wachtwoord gekraakt kan worden om wachtwoorden op alle opgeslagen websites te wijzigen, te beginnen bij kritieke accounts die derden kunnen gebruiken om zich voor jou uit te geven, zoals in e-mail, telefoon en sociale media en websites die financiëe gegevens bevatten. Als je je ongerust maakt, wijzig dan ook wachtwoorden op minder gevoelige websites. (Normaliter zou je sterke, unieke wachtwoorden niet hoeven te vervangen maar in dit geval zijn centrale gegevens gestolen, ook al kunnen ze niet ontsleuteld worden.)

Als je een zwak primair wachtwoord hebt zou je dat ook moeten vervangen en multifactor verificatie aanzetten voor je LastPass account. Hoewel de geest inmiddels uit de fles is kun je wel een nieuwe geest krijgen en zorgen dat de fles in het vervolg dicht blijft: toekomstige aanvallen hebben minder kans van slagen als je de wachtwoorden in je kluis hebt vernieuwd en ze hebt beveiligd met een nieuw sterk en uniek wachtwoord.

Ongeacht de sterkte van hun primaire wachtwoorden moeten LastPass gebruikers nu ook alert zijn op gerichte phishing-aanvallen. Omdat de kluis-reservekopieën van LastPass website URLs niet versleutelen, kunnen phishers die combineren met een e-mailadres uit je niet-versleutelde accountgegevens.

Als je er helemaal niet zeker van bent dat een e-mail of sms-bericht met een link naar een inlogpagina legitiem is, navigeer dan rechtstreeks naar de website in je browser en log in met behulp van links op de site. Vertrouw URL-voorbeelden niet - het is te gemakkelijk om domeinnamen te vervalsen op manieren die bijna onmogelijk te identificeren zijn. Pas vooral op voor creditcard-waarschuwingen en pakket tracering-waarschuwingen - beide zijn normaal al gemakkelijke paden voor phishers en zij hebben nog meer kans om gebruikers voor de gek te houden tijdens de feestdagen.

Vragen en zorgen

Het is duidelijk dat LastPass hier fouten heeft gemaakt maar het bedrijf is tenminste transparant over wat er is gebeurd. Het lijkt er niet op dat LastPass arrogant was over de beveiliging - dit klinkt als een geavanceerde, meervoudige aanval die maanden duurde om uit te voeren. Het is een waardevolle les voor alle organisaties om te beseffen dat gerichte aanvallen op de ene werknemer en vervolgens op de andere uiteindelijk de toegang tot enorme hoeveelheden gegevens mogelijk maakten. Toch roept de uitkomst vragen en zorgen op.

Moeten LastPass-gebruikers overwegen over te stappen op een andere oplossing voor wachtwoordbeheer? 

Ja, om twee redenen. Ten eerste is het verontrustend dat LastPass geen geheime sleutel gebruikt die verweven is in het hoofdwachtwoord om zich te beschermen tegen dit soort diefstallen. Ten tweede kunnen de aanvallers de gestolen informatie mogelijk misbruiken om de systemen van LastPass opnieuw in gevaar te brengen. LastPass verhardde zijn systemen als reactie op de inbreuk op het account van een ontwikkelaar in augustus maar dat was niet voldoende om de aanval in november op de tweede medewerker te dwarsbomen.

Omgekeerd blijft de Zero Knowledge-architectuur van LastPass, voor zover wij weten, veilig, dus als u tevreden bent met de kracht van uw hoofdwachtwoord en u vertrouwt op de algehele architectuur van LastPass, zou u deze zonder extra zorgen kunnen blijven gebruiken.

Als iemand die LastPass al vele jaren als primaire oplossing gebruikt – Tonya gebruikt 1Password en we delen een familiekluis met Tristan – ben ik niet van plan om alleen op basis van deze inbreuk over te stappen. Ik heb echter last van andere irritaties met LastPass: de multifactor-authenticatie mislukt op de Apple Watch, het kan maar niet onthouden dat ik wil dat gegenereerde wachtwoorden symbolen bevatten en 20 tekens lang zijn en de Chrome-extensie raakt vaak beschadigd (zie “Verdwijnen Chrome-extensies? Klik op Repareren,” 24 augustus 2021) — dus ik heb besloten over te stappen op 1Password wanneer ik daar tijd voor heb.

Is deze inbreuk een aanklacht tegen het hele concept van cloudgebaseerde wachtwoordbeheerdiensten?

Hoewel sommigen ongetwijfeld ja zullen zeggen, met als argument dat lokaal beheerde wachtwoorden niet vatbaar zijn voor aanvallen op een bedrijf, heeft het probleem meer te maken met hoe cloudgebaseerde gegevens worden beveiligd. Hoewel LastPass niet de encryptiesleutels voor jouw gegevens bevat, is de encryptiemethode niet zo sterk als zou kunnen, omdat alle encryptiekracht is opgesloten in één enkel hoofdwachtwoord dat overal kan worden ingevoerd, in plaats van dat het meer componenten vereist, waarvan sommige of alle van elkaar worden gescheiden.

Het afzweren van cloudgebaseerde opslag ten gunste van lokaal beheerde wachtwoorden veronderstelt ook dat je niet ten prooi zou vallen aan phishing of andere aanvallen die willekeurig op je gericht zijn, in plaats van specifiek. De LastPass-inbreuk vereiste directe aanvallen op specifieke werknemers maar lukrake aanvallen kunnen worden geautomatiseerd of breed worden verspreid via malware. De aanvallers weten niet wie hun slachtoffers zijn, of het kan hen niet schelen.

Bovendien bieden cloudgebaseerde systemen twee aantrekkelijke functies: synchronisatie tussen verschillende apparaten en platformen en het delen van bepaalde wachtwoorden met andere gebruikers van hetzelfde systeem. Synchroniseren is vrij eenvoudig te repliceren met behulp van iCloud, Dropbox of iets dergelijks, maar voor het delen van wachtwoorden met andere mensen is een gedeeld account vereist.

Zijn andere wachtwoordbeheerders kwetsbaar voor soortgelijke aanvallen?

Ik zou denken van niet. De LastPass-inbreuk was gebaseerd op eerder gestolen informatie die toegang bood tot secundaire back-upopslag dankzij inloggegevens en informatie die was gestolen bij aanvallen gericht op individuele werknemers. Het was een aangepaste aanval en kon niet tegen andere bedrijven worden gebruikt. En de afhankelijkheid van LastPass van één enkel hoofdwachtwoord vormt ook een uniek risico voor de gegevens van zijn gebruikers.

Maar goed, ik moet aannemen dat alle wachtwoordbeheer-diensten vrijwel constant worden aangevallen, want om bankrover Willie Sutton te parafraseren, dat is waar de wachtwoorden zijn. Deze bedrijven beschouwen dergelijke aanvallen misschien als normaal, of gebruiken het incident van LastPass als een excuus om hun beveiligingspraktijken opnieuw door te lichten om er zeker van te zijn dat ze niets hebben gemist. LastPass dacht vermoedelijk ook niets gemist te hebben vóór augustus 2022.

Wanneer zullen passkeys dit soort problemen elimineren?

Zeker weet ik het niet maar de overgang kan niet snel genoeg plaatsvinden. Zie “Waarom passkeys eenvoudiger en veiliger zijn dan wachtwoorden” (27 juni 2022).