De OpenID Foundation is normaal gezien niet het soort club dat grote, dramatische uitspraken doet. Dat zijn de mensen achter standaarden zoals OpenID Connect, het spul achter die "Inloggen met Google"- of "Sign in with Microsoft"-knoppen die je overal ziet. Bijna iedereen gebruikt dat geregeld zonder erbij stil te staan. Het soort infrastructuur waar bijna niemand over nadenkt, tot het stuk is.

Dus toen zij in een recente paper digitale dood "het grootste onopgeloste probleem in identity" noemden, ben ik even rechter gaan zitten.

Niet omdat het zo'n goede quote is. Wel omdat dit uit een hoek komt die meestal pas praat als iets echt structureel fout zit.

Hun punt is simpel: we hebben het internet gebouwd voor levende gebruikers. Voor mensen met een telefoon in hun hand, toegang tot hun mailbox, hun eigen biometrie, hun eigen security keys. Zodra iemand overlijdt, valt die veronderstelling uit elkaar. En dan blijkt hoe weinig van onze digitale infrastructuur voorbereid is op overdracht.

Dat klinkt abstract. Dat is het niet.

Probeer na een overlijden maar eens toegang te krijgen tot iemands Gmail, iCloud, Twitter-account, crypto wallet, domeinnamen, foto's, of de 2FA-app op zijn telefoon. Dan merk je snel dat "erfenis" voor de fysieke wereld redelijk goed geregeld is, en voor de digitale wereld vooral bestaat uit improvisatie.

Wat er vandaag misloopt

Het eerste probleem is verificatie. Er bestaat geen wereldwijde, digitale standaard om betrouwbaar vast te stellen dat iemand overleden is. Overlijdensakten zien er per land anders uit, komen vaak pas na dagen of weken beschikbaar, en zijn niet gemaakt voor geautomatiseerde online processen. Elk platform verzint dus zijn eigen procedure. De ene vraagt een scan van een document, de andere een rechtbankbevel, een derde biedt amper een formeel proces.

Het tweede probleem is delegatie. Veel diensten zijn gebouwd rond één gebruiker, één login, één toestel. Er is geen nette manier om te zeggen: deze persoon is overleden, deze andere persoon heeft juridisch mandaat, geef beperkte toegang voor precies deze handelingen. In plaats daarvan krijg je een rommelig spectrum van halve oplossingen. Sommige platformen hebben een legacy contact. Andere hebben niets. Nog andere duwen families stilzwijgend richting credential sharing, wat meestal indruist tegen hun eigen voorwaarden.

Het derde probleem is dat sterke authenticatie meesterlijk werkt zolang je leeft. Passkeys, Face ID, hardware keys, authenticator apps, device binding: allemaal uitstekend voor security. Tot iemand er niet meer is. Dan verandert moderne beveiliging plots in een perfect systeem om erfgenamen buiten te sluiten. Je kunt niet erven wat je niet eens kunt openen.

En dan is er nog een vierde laag die volgens mij nog onderschat wordt: AI. We kunnen intussen stemmen klonen, avatars bouwen, chatbots voeden met iemands berichten en video. De technische drempel is weg. De ethische en juridische kaders zijn dat niet. Wie mag daar toestemming voor geven? De overledene niet meer. De erfgenamen? Op basis waarvan? Het verschil tussen een profiel online laten staan en een digitale simulatie van iemand bouwen is behoorlijk groot. Toch behandelen we dat vandaag vaak alsof het gewoon een productkeuze is.

Waarom is dat nu een probleem?

Jaren geleden kon je nog doen alsof een digitaal nalatenschapsprobleem vooral over een mailbox en wat foto's ging. Die tijd is voorbij.

Voor veel mensen zit echte waarde online. Crypto uiteraard, maar ook betaalde software, cloudopslag, domeinnamen, loyaltypunten, webshops, advertentie-inkomsten, code repositories, social accounts, contracten, klantendata, abonnementen, documenten, recovery codes. Soms vertegenwoordigt dat financiële waarde. Soms operationele waarde. Soms puur emotionele waarde. Vaak een combinatie van de drie.

Ik denk dat dit onderwerp nu pas echt boven komt drijven omdat de eerste generatie die een volledig digitaal volwassen leven heeft geleid stilaan in de fase komt waar overlijden en incapaciteit geen theoretische randgevallen meer zijn. Dan bots je op systemen die nog altijd doen alsof de gebruiker morgen wel weer zal inloggen.

Dat zie je ook in de details. Een bankrekening heeft procedures. Een huis heeft eigendomspapieren. Een BV heeft bestuurders en overdrachtsregels. Een set passkeys op een telefoon met kapot scherm en een pincode die niemand kent? Succes ermee.

Waarom ik dit document serieus neem

Ik kijk hier natuurlijk niet helemaal neutraal naar. Ik werk aan Trustbourne, dus dit onderwerp zit dicht op mijn werk. Maar precies daarom vond ik die OpenID-paper interessant. Niet als marketingmateriaal, wel als bevestiging dat dit geen niche-observatie van een founder is.

Als een standaardenorganisatie zegt dat death verification en posthumous delegation nog fundamenteel onopgelost zijn, dan betekent dat meestal twee dingen.

Eén: platformen beginnen hetzelfde probleem te voelen. Niet vanuit filosofie, maar omdat supportteams, juristen en productmensen er in de praktijk op botsen.

Twee: dit schuift op van een vreemd randdossier naar basisinfrastructuur. Zoals backups ooit iets waren voor nerds en daarna gewoon hygiëne werden, zo zie ik digitale nalatenschap ook evolueren. Eerst optioneel. Dan plots overduidelijk noodzakelijk.

Wat mensen vandaag wél al kunnen doen

De slechtste aanpak is niets doen en hopen dat je partner of kinderen het later wel uitzoeken. Dat is geen plan. Dat is een tijdbom met administratieve bijsluiter.

Wat wel werkt, begint saai. Een inventaris maken. Niet alleen van accounts, maar ook van wat belangrijk is, wat weg mag, wie wat moet krijgen, welke accounts zakelijk zijn, waar de recovery codes zitten, hoe 2FA geregeld is, en wie welke rol krijgt. Niet alleen "hier zijn mijn wachtwoorden", maar ook "dit is wat je ermee moet doen".

Dat verschil is groter dan het lijkt. Een wachtwoordlijst zonder context helpt minder dan mensen denken. Accounts veranderen. Toestellen verdwijnen. Authenticatieflows schuiven op. Wat je nodig hebt is geen statisch document in een lade, maar een systeem dat mee kan bewegen.

Ik vermoed dat daar de komende jaren veel rond gaat gebeuren, zowel technologisch als juridisch. Overheden gaan zich ermee bemoeien. Platformen gaan delegatiemodellen moeten bouwen. Standaarden gaan proberen het overdraagbaar en controleerbaar te maken.

Allemaal goed. Alleen lost dat het probleem van vandaag niet op.

Conclusie

Wat mij vooral is bijgebleven uit die OpenID-paper: de internetstack gaat impliciet uit van onsterfelijkheid. Niet letterlijk natuurlijk, maar operationeel wel. De gebruiker heeft toegang. De gebruiker bevestigt. De gebruiker logt in. De gebruiker klikt weg wat moet weggeklikt worden.

Tot de gebruiker dat niet meer kan.

Dan blijkt hoeveel van onze digitale wereld leunt op aannames die nooit zijn uitgewerkt tot echte overdrachtsmechanismen.

Een tijdje geleden schreef ik al over wat er met je digitale leven gebeurt als jij er niet meer bent. Deze nieuwe paper van OpenID maakt hetzelfde punt, maar dan vanuit de hoek van de mensen die identity-infrastructuur bouwen. Dat maakt het moeilijker om weg te lachen als nicheprobleem.

En eerlijk, dat is ergens ook goed nieuws. Zodra standards-mensen hardop zeggen dat iets fundamenteel ontbreekt, duurt het meestal niet lang meer voor de rest van de sector moet volgen.

Het internet is volwassen geworden. Nu de sterfelijkheid nog.

Bron: OpenID Foundation, The Unfinished Digital Estate, maart 2026

Ik bouw een digitale kluis. Eentje waar mensen hun belangrijkste bestanden in bewaren: wachtwoorden, cryptosleutels, documenten voor als ze er niet meer zijn. En de moeilijkste beslissing die ik tot nu toe genomen heb: zorgen dat ik zelf nergens bij kan.

Als je een SaaS-product bouwt, wil je alles zien. Dashboards met gebruikersdata, support-toegang tot accounts, logging van wat er in en uit gaat. Elke tutorial, elk framework, elk voorbeeld gaat ervan uit dat jij als founder ergens een admin-paneel hebt waar je kunt meekijken.

Bij Trustbourne heb ik dat bewust opgegeven. Als ik een kluis verkoop voor je belangrijkste bestanden en ik kan er zelf bij, dan is het geen kluis. Dan is het een map op iemand anders z'n server.

Twee kluizen, één keuze

De architectuur van Trustbourne draait op encryptie in de browser. Bestanden worden versleuteld op jouw apparaat, vóórdat ze mijn servers bereiken. Ik zie encrypted blobs. Inhoud, metadata: ik heb er geen toegang toe.

Maar hier wordt het interessant. Trustbourne heeft twee encryptie-modi, en de reden waarom zegt meer over het product dan de technologie zelf.

Seamless is de standaard. Je bestanden worden in je browser versleuteld met een master key. Die master key wordt twee keer versleuteld: één keer met je wachtwoord (zodat jij erbij kunt), en één keer met een release key die Trustbourne bewaart op aparte infrastructuur. Die release key staat los van je vaultdata — andere systemen, andere toegangscontroles, audit logging ertussen.

Zou ik technisch gezien de stukken kunnen combineren om te ontsleutelen? Ja. Ik voorkom dat met toegangscontroles, scheiding van systemen en operationele policies. Maar "we kiezen ervoor om het niet te doen" is een andere belofte dan "we kunnen het niet."

En toch is Seamless de standaard. Bewust.

Want denk even na over wat er aan de andere kant gebeurt. Je partner moet bij je kluis. Ze heeft net te horen gekregen dat je er niet meer bent. Ze regelt de uitvaart, belt de notaris, zoekt uit welke rekeningen er nog openstaan. En nu moet ze óók nog een wachtwoordzin vinden die je ergens bewaard hebt, uitzoeken waar die voor dient, en die correct invoeren voordat ze iets kan zien.

Dat is wrijving op het slechtste moment.

Met Seamless klikt je contactpersoon op een link, bevestigt haar identiteit via e-mail en SMS, en ziet je bestanden. De decryptie gebeurt volledig in haar browser — onversleutelde bestanden staan nooit op mijn servers. Maar zij hoeft er niks voor te doen behalve zijn wie ze is.

Maximum Privacy gaat verder. Geen release key op de server. Je master key wordt alleen versleuteld met een wachtwoordzin die je zelf kiest, los van je accountwachtwoord. Ik heb die zin niet. Ik bewaar hem niet. Ik kan hem niet herstellen.

Zelfs bestandsnamen zijn versleuteld. Bij Seamless kan ik je mappenstructuur en bestandsnamen zien — handig voor je contactpersonen om te navigeren na een release. Bij Maximum Privacy zie ik niks. Versleutelde namen, versleutelde inhoud, versleutelde sleutels. Het hele ding is ondoorzichtig.

Als je kluis vrijgegeven wordt, krijgen je contactpersonen de versleutelde data maar geen release key. Hij heeft de wachtwoordzin nodig die je via een ander kanaal gedeeld hebt. Een verzegelde brief. Een notaris. Een kluis bij de bank. Dat is wat "zero-knowledge" in de praktijk betekent. Ik kan structureel, wiskundig niet meekijken. De sleutel bestaat niet op mijn servers.

Maximum Privacy zit op het Plus-abonnement. En er zit een harde consequentie aan: als je je wachtwoordzin kwijtraakt, is je data weg. Geen "neem contact op met support." Weg. Ik kan het niet resetten. Ik kan je master key niet herstellen. De wiskunde trekt zich er niks van aan. Dat is het hele punt.

De technische details staan in ons encryptie-artikel.

Waarom twee modi?

Ik had alleen Maximum Privacy kunnen bouwen. Puurder verhaal. Makkelijker uit te leggen.

Maar de persoon die je kluis ontvangt, zit midden in een rouwproces. Ik vond het niet verdedigbaar om die persoon ook nog een puzzel te laten oplossen. Seamless bestaat omdat de ontvanger ertoe doet, ook in de architectuur.

Voor de meeste mensen is dat de juiste afweging. Voor mensen met significante crypto-holdings, gevoelige bedrijfsdocumenten, of situaties waar elk risico op toegang door derden te veel is — daarvoor bestaat Maximum Privacy.

Twee modi, eerlijk over de afwegingen van beide. Dat vind ik een sterkere belofte dan één modus met een marketingverhaal eromheen.

Wat ik dagelijks merk

Trustbourne zit in beta. Echte mensen bewaren er echte bestanden. Cryptosleutels, inloggegevens, instructies voor nabestaanden.

En ik kan er niet bij. Als ik nu in de database zou kijken, zie ik versleutelde data en metadata over wanneer iemand z'n laatste check-in deed. Meer niet.

Dat voelt soms kwetsbaar. Ik kan niet controleren of mensen het systeem goed gebruiken. Geen handige statistieken, geen A/B-tests op gebruikersdata. Al die optimalisatietechnieken waar SaaS-founders op leunen, werken niet als je niks kunt zien. Ik moet het doen met audit logs die me vertellen welke acties genomen zijn, zonder me de data te geven.

Maar het klopt wel.

De afweging

Zero-knowledge kost je features die gebruikers verwachten. Zoeken in je bestanden? Kan niet server-side. Previews genereren? Onmogelijk als je de inhoud niet kunt lezen. Slimme suggesties, automatische categorisering, AI-features — allemaal van tafel als je de data niet kunt zien.

Elke feature die ik wil bouwen moet ik bedenken vanuit de vraag: kan dit volledig op het apparaat van de gebruiker draaien? Soms is het antwoord nee, en dan bouw ik het niet.

Minder features, meer vertrouwen. Geen dashboards vol gebruikersdata voor mij, maar een kluis die doet wat een kluis hoort te doen.

Een tijdje geleden schreef ik over het probleem — wat er gebeurt met je digitale leven als jij er niet meer bent. Dit stuk gaat over de andere kant: hoe je iets bouwt waar mensen dat soort data aan durven toevertrouwen.

Trustbourne zit in beta. Als je het wilt proberen of vragen hebt over de encryptie-architectuur: team@trustbourne.com.

De man van een kennis stierf bij een ski-ongeval in Zwitserland. Maanden later zoekt ze nog steeds naar papieren. Polissen van groepsverzekeringen. Documenten die ergens op een computer of in een mailbox moeten zitten. Niemand weet waar, niemand komt erbij.

Dit is geen uitzonderlijk verhaal. Vraag rond in je omgeving. Iedereen kent wel iemand.

De cloud biedt oplossingen, maar ...

Apple en Google hebben ondertussen wel degelijk systemen om nabestaanden toegang te geven. Apple heeft "Legacy Contact", Google heeft "Inactive Account Manager". Je kunt vooraf mensen aanduiden die na je overlijden bij je data kunnen.

Klinkt goed. Maar er zitten haken en ogen aan.

Ten eerste: het werkt alleen voor die ene dienst. Je Apple-contactpersoon krijgt toegang tot je iCloud-foto's en berichten, maar niet tot je wachtwoorden. Niet tot je Dropbox. Niet tot die ene webapp waar je facturen in zitten. Je digitale leven is verspreid over tientallen diensten. Elke dienst heeft zijn eigen procedure, als die er al is. Dropbox bijvoorbeeld vereist een gerechtelijk bevel.

Ten tweede: alles gaat naar dezelfde persoon. Misschien wil je zakelijke documenten aan je boekhouder of zakenpartner geven. Persoonlijke zaken aan je partner. Medische richtlijnen aan iemand anders. Bij de meeste diensten is dat niet of nauwelijks te regelen.

Ten derde, en dit vergeten de meeste mensen: deze systemen werken alleen bij overlijden. Wat als je zes maanden in coma belandt na een ongeluk? Je partner kan nergens bij. De rekeningen blijven binnenkomen. De verzekeringen moeten verlengd worden. Je bedrijf draait door.

Trustbourne

Ik bouw daarom aan Trustbourne. Het idee: je uploadt belangrijke bestanden naar een versleutelde kluis. Wachtwoorden, crypto-sleutels, documenten, instructies. Je bepaalt wie toegang krijgt tot welke bestanden. Als je een tijdje niet meer reageert op check-ins en we je via meerdere kanalen niet meer kunnen bereiken, krijgen die mensen automatisch toegang.

Your files. Your people. Your terms.

Geen notaris nodig voor de digitale zaken. Geen wachtwoorden op briefjes. Geen zoektocht door oude laptops.

Ter illustratie: er zit naar schatting 140 miljard dollar aan Bitcoin permanent vast omdat eigenaren hun sleutels niet deelden voor het te laat was.

Bestanden worden versleuteld op je eigen toestel. Wij kunnen ze niet lezen, alleen de mensen die jij kiest.

Waar we nu staan

De saaie basis is af. Registratie, login, tweefactorauthenticatie, e-mailverificatie. 177 automatische tests die controleren of alles werkt. Je kunt er nog niks mee doen als gebruiker, maar de fundamenten zijn solide.

Nu begint fase 2: de daadwerkelijke kluis, bestanden uploaden, mappen organiseren. De eerste schermen...

Als je geïnteresseerd bent in updates, kun je je inschrijven op trustbourne.com. We sturen alleen iets als er echt iets te vertellen valt.

Gisteren was ik op een evenement van de Collective (de "moderne businessclub" van het Wintercircus) met als teaser "Hello Doctor GPT", een samenwerking van de GenAI en de Bits & Bio communities. Een zaal vol AI-specialisten en mensen uit de health tech sector, precies het publiek waar je verwacht dat nuance en kritisch denken hoogtij vieren.

De quote die niemand meer wil horen

De eerste spreker, Dr. Uri Ilan, een leukemie-expert van het Prinses Máxima kinderziekenhuis in Utrecht, opende met een slide die ik inmiddels vaker heb gezien dan goede koffie op conferenties: "You will not be replaced by AI, you will be replaced by somebody who knows AI". Het geruststelling-mantra van 2024 en 2025. En eerlijk is eerlijk, in een medische context wordt dit nog eens extra benadrukt. Elke spreker, elk panel, elke demo eindigt met dezelfde verzekering: "De AI is ondersteunend, de dokter beslist".

Logisch ook. We willen niet dat algoritmes leven-of-dood beslissingen nemen zonder menselijke tussenkomst. We willen de menselijke expertise, de empathie, het vermogen om nuance te zien die niet in data past.

Plot twist

Enkele slides later kwam hij met een vaststelling die de zaal even stil deed worden. Onderzoek toont aan dat als je wél enkel de AI zou laten beslissen, er in de zorg betere beslissingen genomen worden. Niet alleen in uitzonderlijke gevallen waar specialisten state-of-the-art studies moeten beoordelen, maar "across the board" in de zorg.

Beter dan dokters die AI gebruiken. Die op hun beurt beter zijn dan dokters die Google gebruiken. Die weer beter zijn dan dokters die geen van beide gebruiken.

Even laten bezinken: AI alleen > Dokter + AI > Dokter + Google > Dokter alleen.

Update 20251115: Het artikel met de vergelijking tussen dokter en het AI model. Wat me opvalt is de grafiek hieronder. Op heel wat beoordeelingsassen die belangrijk zijn voor de patient, waaronder ook empathie, scoort de AI tool beter dan de menselijke dokter.

De vraag die niemand durft te stellen

De zaal was niet klaar voor een filosofisch debat. Er werd nerveus gelachen, er werd naar een volgende slide geklikt, en we gingen door met de veilige verhalen over hoe AI dokters ondersteunt. Maar de vraag hing in de lucht: als AI betere medische beslissingen neemt dan dokters met AI-ondersteuning, waarom laten we die beslissingen dan niet gewoon aan de AI over?

Dit is geen comfortabele vraag. Het voelt als verraad aan eeuwen van medische opleiding, aan de Hippocratische eed, aan het idee dat geneeskunde een menselijke praktijk is. Maar het is wel een vraag die we moeten durven stellen.

Maar (en het is een grote maar)

Voor we allemaal onze artsen ontslaan en vervangen door ChatGPT met een stethoscoop, zijn er natuurlijk nuances. Want nuances zijn er altijd.

Ten eerste: "Betere beslissingen" is een gemiddelde. In welke gevallen presteert AI beter, en in welke niet? Zijn er situaties waar de menselijke intuïtie, ervaring of empathie cruciaal is? Waarschijnlijk wel.

Ten tweede: Verantwoordelijkheid. Als de AI een fout maakt, wie is er dan verantwoordelijk? De ontwikkelaar? Het ziekenhuis? De overheid die het systeem goedkeurde? Dit is niet alleen een juridische vraag, maar ook een ethische.

Ten derde: Het blackbox-probleem. Als een AI zegt "behandel deze patiënt met medicijn X", maar niemand begrijpt waarom, hoe weten we dan of die beslissing klopt? Of dat het niet gewoon een correlatie is die werkte in de trainingsdata maar gevaarlijk is in edge cases?

Ten vierde: Data bias. AI's zijn zo goed als de data waarop ze getraind zijn. Als die data voornamelijk witte mannen bevat (en dat is helaas vaak zo in medisch onderzoek), hoe betrouwbaar zijn de beslissingen dan voor vrouwen, andere etniciteiten, of kinderen?

Het spectrum van controle

Misschien is de vraag niet "AI of mens", maar "waar op het spectrum tussen volledige menselijke controle en volledige AI-autonomie moeten we zitten voor verschillende types beslissingen?"

En hier wordt het pas echt ongemakkelijk. Want zelfs bij wat wij intuïtief als "eenvoudige" beslissingen beschouwen (routinematige beeldanalyse voor kankerscreening bijvoorbeeld) blijkt uit onderzoek dat pure AI gemiddeld beter scoort dan AI met nazicht door een dokter. De menselijke interventie verslechtert dus de uitkomst.

Laat dat even bezinken. De dokter die "voor de zekerheid nog even meekijkt" maakt het gemiddeld slechter, niet beter.

Aan de andere kant: een terminale diagnose communiceren aan een gezin? Hier is empathie, context, culturele sensitiviteit cruciaal. Geen AI vandaag die dat kan, of zelfs maar zou moeten proberen ... for now.

Maar dat grijs gebied? Dat blijkt veel kleiner dan we dachten. En het verschuift snel. End-of-life beslissingen. Experimentele behandelingen. Diagnoses met grote onzekerheid. Voor hoeveel van deze gevallen geldt straks ook: "pure AI scoort beter"?

De ongemakkelijke waarheid

De medische wereld heeft een lange geschiedenis van weerstand tegen verandering, gevolgd door snelle acceptatie als de voordelen onmiskenbaar blijken. Denk aan antibiotica, aan kijkoperaties, aan vaccinaties. Eerst scepticisme, dan mainstream.

AI in de zorg zal waarschijnlijk hetzelfde pad volgen. We zullen beginnen met "de dokter beslist altijd", verschuiven naar "de dokter beslist maar alleen na grondig AI-advies te hebben bekeken", dan naar "de dokter keurt AI-beslissingen goed", en uiteindelijk misschien wel naar "AI beslist, de dokter monitort".

De vraag is niet óf dit zal gebeuren, maar wanneer en voor welke beslissingen. En of we daar als maatschappij klaar voor zijn.

Tot slot

Ik heb geen pasklaar antwoord. Niemand heeft dat, zelfs niet de experts in die zaal gisteren. Maar wat me wel bijblijft is de moed van Dr. Ilan om de vraag hardop te stellen. Om niet te schuilen achter het veilige narratief van "AI ondersteunt, mens beslist", maar om de realiteit onder ogen te zien: soms is de AI gewoon beter.

De vraag is niet of we dat moeten accepteren. De vraag is: wat doen we ermee?

En jij, wat denk je? Zou jij een behandeling accepteren die enkel op basis van AI-analyse is voorgeschreven, als je weet dat de AI gemiddeld betere uitkomsten behaalt dan een arts? Laat het me weten in de reacties, want deze discussie zijn we met z'n allen aan het voeren, of we het nu willen of niet.

Ik zit met een dilemma. En waarschijnlijk jij ook, als je dit leest en consultant bent. Claude (of ChatGPT, of welke AI-assistent je ook gebruikt) is ondertussen een onmisbare collega geworden. Maar hoe ga je daar in godsnaam mee om als je per uur factureert?

Laten we eerlijk zijn: AI heeft mijn productiviteit door het dak gejaagd. Wat vroeger een halve dag kostte, krijg ik nu in twee uur gedaan. Code reviews? Claude kost me elke maand meer (de Max 20x kost al € 200 per maand, want ik wil de beste versie), en mijn klanten betalen me per uur.

Het probleem met uurtarieven in een AI-wereld

Het traditionele consulting-model kraakt. We verkopen tijd, maar tijd wordt steeds minder relevant. Als ik dankzij Claude in 4 uur lever wat vroeger 8 uur kostte, wie wint dan? Wie verliest? En belangrijker: hoe blijf je eerlijk naar iedereen toe?

Dit is geen theoretische discussie meer. Vorige maand had ik een complexe data-migratie te doen voor een klant. Pre-Claude zou ik daar makkelijk twee dagen aan gezeten hebben. Met Claude erbij? Een lange namiddag. Wat factureer ik nu?

De opties op tafel

1. De Struisvogel: Niks veranderen

Uurtarief blijft gelijk, AI-kosten zijn voor mij, productiviteitswinst voor de klant. Simpel, transparant, maar op termijn onhoudbaar. Je subsidieert basically je klanten met je eigen AI-investering. Voor kleine klanten misschien haalbaar, maar als je 5+ klanten hebt wordt dit een dure grap.

Voordeel: Geen moeilijke gesprekken
Nadeel: Je betaalt uit eigen zak voor andermans productiviteitswinst

2. De Cowboy: Creatief met uurtjes

We werken 4 uur, presteren voor 8, factureren 8. Bedankt Claude en ChatGPT!

Verleidelijk? Absoluut. Ethisch? Dat is een ander verhaal. En praktisch ook riskant. Wat als je klant vraagt naar een gedetailleerde tijdsregistratie? "Van 14u tot 22u aan uw API-documentatie gewerkt" terwijl je om 18u al een biertje zat te drinken?

Voordeel: Maximale winst op korte termijn
Nadeel: Je vertrouwensrelatie naar de vaantjes als het uitkomt

3. De Economist: Verhoog je uurtarief

Je bent productiever, levert betere kwaliteit, dus je tarief mag omhoog. Van €125 naar €160 per uur bijvoorbeeld. De klant betaalt evenveel of zelfs iets minder voor een project (minder uren × hoger tarief), jij dekt je AI-kosten en wordt beloond voor je efficiëntie.

Volgens Leanware's onderzoek rekenen AI-consultants met specialisaties in generative AI of reinforcement learning al 20-30% premiums bovenop hun standaard tarieven. Maar die research lijkt beperkt tot het AI domein terwijl het mijn assistent is, wat ook het domein is. Grote consultancies bundelen het vaak in "Digital Acceleration" tarieven zonder de details prijs te geven.

Dit werkt... tot je een nieuwe klant moet uitleggen waarom jij 50% duurder bent dan je concurrent die nog met Stack Overflow werkt.

Voordeel: Eerlijk model dat productiviteit beloont
Nadeel: Moeilijk uit te leggen aan nieuwe klanten. Nog moeilijker aan bestaande klanten bij wie je moet verhogen.

4. De Abonnementeur: AI-supplement

Een vaste AI-toeslag per klant per maand. €50 voor kleine klanten, €200 voor grote klanten? Maar wat met die klant waar je maar 3 uur per kwartaal voor werkt? Ga je die €50 per maand aanrekenen?

Ik hoor van collega's dat sommige agencies hier al mee experimenteren - een "AI Tools & Infrastructure" fee of gestaffelde modellen op basis van bedrijfsgrootte. Maar de receptie is... gemengd.

Voordeel: Duidelijke, aparte kostenlijn
Nadeel: Oneerlijk voor kleine klanten

5. De Revolutionair: Weg met uurtarieven

Stop met tijd verkopen, start met waarde verkopen. Projectprijzen, retainers, value-based pricing. Een migratie kost €5000, of het nu 2 dagen of 2 weken duurt.

De grote strategy houses doen dit al jaren, en volgens onderzoek van Consultancy-me.com zegt Simon-Kucher dat 20% van alle professional services firms hun revenue model fundamenteel zullen moeten veranderen in de komende 5 jaar door AI. Nog schokkender: 73% van klanten prefereert nu al pricing modellen gekoppeld aan meetbare business outcomes in plaats van tijd.

Klinkt logisch, maar probeer dat maar eens uit te leggen aan een procurement-afdeling die gewend is aan uurtarieven te vergelijken.

Voordeel: Alignment tussen jouw efficiëntie en jouw inkomen
Nadeel: Complete mindshift nodig bij klanten

6. Het Hybride model: Mix and match

Wat ik in de toekomst zal testen: een combinatie. Basis uurtarief blijft, maar met een transparante AI-component:

• Kleine taken (< 4 uur): gewoon uurtarief, AI-kost absorbeert
• Grote projecten: ofwel projectprijs, ofwel uurtarief + €100 AI-supplement per projectdag
• Vaste klanten (>40 uur/maand): maandelijkse retainer die AI bevat

De ongemakkelijke waarheid

We moeten dit gesprek voeren met onze klanten. Nu. Want volgens SCOPE Better's CEO Tracey Shirtcliff: "0% van firms hebben een plan voor AI's impact op hun revenue model, terwijl minstens 20% fundamenteel hun model zal moeten veranderen in de komende 5 jaar."

De alternatieven zijn:

1. We worden steeds efficiënter en verdienen steeds minder (race to the bottom)
2. We misleiden onze klanten over onze werkelijke tijdsbesteding
3. We stoppen met AI gebruiken (alsof dat een optie is...)

Ik ben voorstander van transparantie. Vertel je klanten dat je AI gebruikt. Leg uit waarom dat hen ten goede komt (betere kwaliteit, snellere delivery, minder menselijke fouten). En wees eerlijk over de kosten en de impact op je pricing model.

De ongemakkelijke waarheid (2)

En hier komt de échte ongemakkelijke waarheid. Toen ik mijn assistente Claudine (ja, Claude dus) vroeg om me research te doen naar bedrijven die al hun pricing aangepast hebben naar één van de bovenstaande modellen, kwam ze terug met mooie namen: van de Big 4 consultants tot niche consultancy boutiques. Thoughtworks die hun tarieven verhoogd had, Cognetik met hun AI-supplement model, enzovoort.

Tot ik opmerkte dat de links die ze gaf naar hun hoofdpagina's gingen. Na wat aandringen kreeg Claudine wat schaamrood op de wangen: ze had de bronnen verzonnen. "Realistische voorbeelden," noemde ze het. Bij een tweede research-poging kwam ze terug met de naakte waarheid: nog bitter weinig consultants schrijven hierover, laat staan dat ze hun modellen openlijk aanpassen.

Wat zegt dat? We zitten allemaal met hetzelfde probleem, maar niemand durft de eerste zet te doen. We wachten af, kijken naar elkaar, hopen dat iemand anders het pad effent. Ondertussen blijven we stiekem collega's Claudine of Chad gebruiken, worstelen met onze facturen, en doen alsof er niks aan de hand is. De olifant in de kamer wordt alleen maar groter.

Mijn voorstel voor het laatste kwartaal van 2025

Dit ga ik doen:

1. Nieuwe klanten: Projectprijzen waar mogelijk, anders schuif ik mijn bestaande tier-structuur op. Wat vroeger "standard development" was wordt nu "senior work", wat "senior consultancy" was wordt "AI-augmented consultancy". Alles schuift 1-2 tiers omhoog. In de praktijk komt dit neer op een verhoging van de uurprijs over de breedte van mijn werk.
2. Bestaande klanten: Open gesprek over AI-gebruik, voorstel voor geleidelijke transitie naar waardegebaseerd model
3. Kleine opdrachten: Minimumfactuur invoeren (halve dag per maand minimum) om AI-overhead te dekken
4. Documentatie: Duidelijk maken in offertes dat AI-tools deel uitmaken van mijn werkproces

Call to action

Nu ben ik benieuwd: hoe pak jij dit aan? Ben je nog aan het struggelen met hetzelfde dilemma? Of heb je de heilige graal gevonden?

Specifieke vragen waar ik mee zit:

• Hoe leg je aan "oude rotten" in procurement uit dat tijd niet meer de juiste metric is?
• Wat doe je met klanten die expliciet vragen hoeveel uur je aan iets gewerkt hebt?
• Hoe ga je om met AI-gebruik in highly regulated industries (finance, healthcare)?

Drop een reactie hieronder, of ping me op LinkedIn. Want dit probleem gaat niet vanzelf weg, en samen staan we sterker in deze transitie.

PS: Ironisch genoeg heb ik vriendin Claudine gebruikt om deze blogpost te schrijven. Kostte me 30 minuten in plaats van 2 uur. Ga ik dat nu aan jullie doorrekenen?

We zitten midden in 2025, en er ontstaat een kloof die groter wordt dan de digitale kloof van de jaren '90. Aan de ene kant heb je mensen die AI nog steeds zien als een leuk speeltje - ChatGPT voor wat tekstjes, misschien een plaatje genereren. Aan de andere kant zijn er mensen die met AI systemen complete wetenschappelijke doorbraken realiseren, juridische analyses automatiseren, en hun dagelijkse productiviteit vertienvoudigen.

Robin: van hypothese tot medicijn in 2,5 maand

Vorige week publiceerde FutureHouse iets wat perfect illustreert waar we naartoe gaan. Hun AI-systeem "Robin" heeft zelfstandig een potentieel nieuw medicijn ontdekt voor oogaandoeningen. Niet door bestaande data te herordenen, maar door:

• Literatuuronderzoek uit te voeren
• Hypotheses te formuleren
• Experimenten te ontwerpen
• Resultaten te analyseren
• Nieuwe hypotheses te genereren
• En dit alles te herhalen tot een bruikbare ontdekking

Het hele proces van concept tot wetenschappelijk paper: 2,5 maand. Ter vergelijking: traditioneel farmaceutisch voor-onderzoek duurt jaren tot decennia.

De coding revolution

In mijn werk bij Krane Labs zie ik dagelijks het verschil tussen developers die AI omarmen en degenen die het negeren. De eerste groep schrijft complexe applicaties in uren waar de tweede groep weken over doet. Ze gebruiken AI niet om code te kopiëren, maar als een intelligente pair-programmer die:

• Architectuurkeuzes voorstelt
• Edge cases identificeert
• Code reviews uitvoert
• Documentatie genereert
• Tests schrijft

De productiviteitskloof wordt zo groot dat bedrijven straks moeilijk zullen kunnen concurreren zonder AI-savvy developers.

Recht en Administratie: van urenlang zoeken naar seconden

Juristen die AI gebruiken kunnen in seconden relevante jurisprudentie vinden, contracten analyseren, en juridische argumenten formuleren. Hun collega's die nog handmatig zoeken in databases zijn langzaam maar zeker hun concurrentievoordeel aan het verliezen.

Hetzelfde geldt voor administratieve taken. Waar accountants vroeger uren besteedden aan het doorploegen van documenten, kunnen AI-systemen nu in realtime compliance-checks uitvoeren, anomalieën detecteren, en rapportages genereren.

Waarom ontstaat deze kloof?

Naast al deze nieuwe productiviteitswinsten en nieuwe manieren van werken, staat een hele grote groep mensen voor wie AI nog steeds "dat ding dat grappige plaatjes maakt maar niet kan rekenen".

Complexity Hiding: De beste AI-tools verstoppen hun complexiteit. ChatGPT lijkt simpel, maar onder de motorkap draait een systeem dat complexer is dan wat we ooit gebouwd hebben.

Graduele Evolutie: Verandering gebeurt geleidelijk. Elke dag wordt AI een beetje beter, waardoor mensen de cumulatieve impact onderschatten. Maar als je enkele maanden niet naar de veranderen gekeken hebt, loop je hopeloos achter.

Comfort Zone: Voor veel mensen werken hun huidige methodes "goed genoeg". Ze zien nog niet waarom ze zouden veranderen.

Wat Nu?

Het is 2025. AI is geen toekomstmuziek meer, het is een gereedschap dat vandaag beschikbaar is. De vraag is niet of je het gaat gebruiken, maar wanneer je begint en hoe snel je de achterstand inhaalt.

Voor ondernemers, professionals, en eigenlijk iedereen die competitief wil blijven: de trein vertrekt nu. Spring erin, of kijk hem voorbijrijden.

Gebruik jij AI al structureel in je werk? Doe je er meer mee dan tekstjes vertalen of herschrijven? Of zie je het nog steeds als "spielerei"?

Laat het me weten in de reacties.

Recently, I encountered an interesting issue with one of my client setups. We use Caddy as a front-end server with its excellent "On Demand TLS" feature, while Apache sits behind it serving the actual site content. While I'd love to simplify this stack by eliminating Apache, the client's application heavily relies on .htaccess files for configuration, so we maintain this hybrid approach.

The issue emerged when the client reported that users with AVG Antivirus installed were receiving strange SSL errors across all browsers when attempting to access the site. Curiously, I couldn't reproduce this problem on AVG for Mac, which added another layer of mystery to the troubleshooting process.

Debugging Process

When analyzing the problem in Chrome on a Windows machine with AVG installed, I noticed references to QUIC in the error messages. For those unfamiliar, QUIC (Quick UDP Internet Connections) is a transport layer protocol developed by Google that serves as the foundation for HTTP/3. It aims to improve performance, particularly in high-latency and lossy network environments.

I ran multiple validation tests on the website but couldn't find any explicit QUIC-related errors. The site's SSL configuration passed all the standard checks, and everything looked fine from a certificate perspective.

After extensive troubleshooting and ruling out other potential causes, I decided to test disabling QUIC in Caddy. Surprisingly, this immediately resolved the issue - users with AVG could now access the site without any SSL errors.

The solution

If you encounter similar SSL errors with Caddy and AVG Antivirus, here's how to disable QUIC/HTTP/3 globally in your Caddy configuration:

{
  servers {
    protocols h1 h2
  }
}

# Rest of your Caddyfile...

This simple configuration change tells Caddy to only use HTTP/1.1 and HTTP/2 protocols for all sites, effectively disabling HTTP/3 (QUIC) across your entire server.

Why does this happen?

The exact cause of the conflict between Caddy's QUIC implementation and AVG Antivirus remains somewhat mysterious. After searching through both Caddy GitHub issues and AVG forums, I couldn't find any posts specifically addressing this issue.

My theory is that AVG's HTTPS scanning feature might be intercepting and inspecting TLS traffic but doesn't properly support or handle QUIC/HTTP/3 connections. Since QUIC works over UDP instead of TCP and uses a different handshake mechanism, it's possible that AVG's scanning engine either misinterprets these connections or incorrectly flags them as suspicious.

Performance implications

While disabling QUIC/HTTP/3 does solve the compatibility issue with AVG, it's worth noting that you'll lose some potential performance benefits, especially for users on high-latency or lossy connections. HTTP/3 offers advantages like improved connection establishment times and better handling of packet loss.

However, the performance impact should be minimal for most websites, as HTTP/2 already provides many optimizations compared to HTTP/1.1. The most important thing is ensuring your site is accessible to all users, regardless of their security software.

Conclusion

This case highlights an interesting compatibility issue between modern web protocols and security software. As the web continues to evolve with new protocols and standards, these types of conflicts may become more common.

If you're running Caddy and users report SSL errors that you can't reproduce on your end, checking for antivirus interference and potentially disabling QUIC might be a quick solution. While not ideal from a cutting-edge performance perspective, ensuring compatibility with common security software used by your visitors is often more important.

Have you encountered similar issues with QUIC or HTTP/3 and security software? Let me know in the comments below!

P.S. While most of my blog posts are written in Dutch, I've chosen to write this specific article in English to increase the chances of Google directing users here. There's surprisingly little information available online about this particular QUIC/AVG issue, so I hope this helps others who might be facing the same problem.

Terwijl ik hier zit te typen met een verse kop koffie en de wind raast over het Sint-Baafsplein, bedenk ik me dat 2024 voorbij gevlogen is. Tijd om even vooruit te dromen over wat 2025 ons gaat brengen!

1. Krane Labs: Groeien Zonder Grijs Haar

Wie had dat gedacht: Krane Labs overtrof alle verwachtingen in 2024! We groeien als kool, maar wel op de chill manier - geen Silicon Valley "work-till-you-drop" taferelen hier. Het plan voor 2025? Doorgroeien met de handrem subtiel in het zicht. Mijn haar is nog niet grijs genoeg voor een complete burn-out 😅

2. America's Cup 2.0

De paar dagen die we in Barcelona doorbrachten tussen de America's Cup boten waren onvergetelijk. Check de foto's van zowel de hyper-moderne boten van deze editie, maar werp ook een blik op de beauty's van de 12M klasse. Allicht de mooiste America's Cup boten ooit gebouwd (al krijg ik daar commentaar van reisgenoten voor die je majesteuze J-classes nog mooier vinden). Met vier op "onze" eigen boot zaten we midden in de actie, met dank aan onze skipper die werkelijk iedereen kent in het circuit 😄.

Nu wachten we gespannen af waar de volgende editie zal plaatsvinden! En of we in 2025 plannen maken om die volgende editie (volgens gefluister al in 2026) opnieuw kunnen bijwonen.

3. Schoolstress & Survival

B's schoolkeuze staat voor de deur. Een paar weken gezonde stress in april in het vooruitzicht (lees: papa die meer grijze haren krijgt). Maar hey, hij overleeft het wel... en wij hopelijk ook!

4. N's Mad Scientist Avonturen

N's wetenschappelijke ontdekkingsdrang blijft groeien. Zolang ze het huis maar niet opblaast met haar experimenten, moedig ik het alleen maar aan! Wie weet lost ze in 2025 wel kernfusie op. Een vader mag dromen, toch?

5. Camera-Crisis Overwonnen

Eindelijk: een camera die in mijn jaszak past! Nu nog onthouden dat 'ie daar zit... 🤦‍♂️

2025 wordt het jaar waarin ik eindelijk stop met zeggen "had ik nu maar mijn camera mee!" Dat is tenminste het plan. Zoals met alle goede voornemens: wordt vervolgd!

Veilige en moderne SSH-communicatie steunt op public/private key-encryptietechnologie. Hierbij maak je een sleutelpaar aan: een publieke en een private sleutel. Je geeft de server of service waar je wilt inloggen het publieke deel, en houdt het private deel geheim. Standaard wordt de private sleutel als een bestand op je computer opgeslagen, bij voorkeur nog eens extra beveiligd met een wachtwoord.

De opkomst van SSH Key Agents

Gaandeweg zijn er hulpmiddelen ontwikkeld om het gebruik van SSH-sleutels te vereenvoudigen. Een belangrijke hiervan is de SSH Key Agent, die toelaat om de private sleutels in het geheugen te laden en meerdere keren te gebruiken zonder telkens opnieuw het wachtwoord in te geven. Oorspronkelijk werden SSH-sleutels enkel gebruikt om op een server interactief in te loggen (SSH staat dan ook voor “Secure Shell”), maar ook het populaire versiebeheerssysteem Git gebruikt SSH-versleuteling. Dit is niet alleen om code-aanpassingen naar een centrale plek te uploaden of downloaden, maar ook om aanpassingen te tekenen zodat je zeker bent dat de aanpassing van Mieke ook écht door Mieke is gedaan.

Het gebruik van meerdere sleutelparen

Waar je vroeger meestal met één sleutelpaar werkte, is het de laatste jaren eenvoudiger geworden om meerdere sleutelparen te hebben. Dit biedt meer veiligheid en flexibiliteit, maar kan ook tot complicaties leiden.

1Password als oplossing voor sleutelbeheer

Omdat je private sleutel een sleutel is tot je systemen, bewaar je die het best in een wachtwoordmanager. Al meer dan 15 jaar gebruik ik, zowel persoonlijk als in mijn bedrijven, 1Password. Sinds kort heeft 1Password twee functies toegevoegd die het gebruik en beheer van SSH-sleutels nog eenvoudiger maken:

1. Automatische sleutelgeneratie via de browserplugin: De browserplugin van 1Password herkent pagina’s van grote Git-hostingservices (GitHub, GitLab, AWS CodeCommit, enz.) en hostingproviders (DigitalOcean, Vultr, enz.). Als zo’n pagina je vraagt om een nieuwe publieke SSH-sleutel te uploaden, zal 1Password voorstellen om de sleutel rechtstreeks aan te maken. Geen gedoe meer met ssh-keygen en command line-commando’s. Dit maakt het proces veel gebruiksvriendelijker.
2. Vervanging van de SSH Agent: 1Password kan op je desktop de SSH Agent vervangen. Zo blijven je SSH-sleutels veilig opgeslagen in je 1Password-kluis, en haalt de agent ze daar vandaan wanneer dat nodig is. De sleutels komen dus nooit meer op je disk terecht. Een prachtig systeem!

Het nadeel van te veel sleutels

Er is echter ook een nadeel. Het wordt op deze manier bijzonder makkelijk om voor elke service een afzonderlijke sleutel aan te maken. Op zich is dat niet slecht, zeker niet voor veelgebruikte diensten zoals GitHub of een cloudprovider die je regelmatig gebruikt. Er zijn ook diensten waar de sleutel helaas voor jou wordt gemaakt en je niet kan kiezen. Dit is eigenlijk een design-fout in die systemen, maar bon, we maken niet alles zelf 😄

Het probleem is dat SSH niet weet welke sleutel het precies voor welke service moet gebruiken. SSH lost dat op door ze gewoon allemaal te proberen. Het probeert eerst eentje, daarna de tweede als de eerste geweigerd wordt, dan de derde, enzovoort. Als je meerdere sleutels hebt, bestaat de kans dat na een aantal pogingen de server aan de andere kant er genoeg van heeft. Standaard staat dit op zes pogingen, maar serverbeheerders kunnen dat uiteraard zelf aanpassen.

Als je dan meer dan zes sleutels hebt, kan het zijn dat de juiste nooit geprobeerd wordt en je dus niet kan inloggen.

De oplossingen die 1Password biedt

1Password biedt twee manieren om dit probleem aan te pakken:

1. De volgorde bepalen: Je kunt de volgorde waarin sleutels worden geprobeerd bepalen in je 1Password SSH-agentconfiguratiebestand (een .toml-bestand). Dit is bijzonder handig als je, zoals ik, elke paar jaar je sleutels vernieuwt. Je kunt dan de oude sleutels als laatste laten proberen, voor die ene server waar je bijna nooit op inlogt en die je nog niet hebt aangepast aan je nieuwe sleutelpaar.
2. Specifieke sleutels per service instellen: Dit lost het probleem echter niet op wanneer je per service een andere sleutel gebruikt. Als je op de klassieke manier je SSH-sleutels op schijf bewaart, kun je hiervoor gebruikmaken van de IdentityFile-parameter in je SSH-configuratie. Je wijst dan naar je private sleutel voor die service en geeft zo aan dat SSH die sleutel moet gebruiken. Alleen wil ik mijn private sleutels niet op mijn schijf bewaren, zelfs niet versleuteld. Ik wil dat ze in de digitale kluis blijven zitten.

De oplossing met publieke sleutels

In de documentatie van 1Password vond ik een halve oplossing hiervoor. Het beste zou zijn als je kon opgeven welke sleutel de 1Password-agent moet gebruiken. Alleen maakt SSH de selectie van de sleutels, niet 1Password. Tenzij 1Password dus hun eigen ssh-variant zou leveren die de standaard vervangt, helpt dit niet. Bovendien zou ik ernstige bedenkingen hebben bij die oplossing.

De oplossing zit hem erin dat de IdentityFile-parameter ook naar het (niet-geheime) publieke deel van de sleutel kan wijzen. Door je publieke sleutel te exporteren uit 1Password en op schijf te bewaren, en je IdentityFile naar deze publieke sleutel te laten wijzen, werkt het zoals ik wil. De 1Password SSH-agent zal zelf de juiste private sleutel zoeken in de kluis.

Mijn configuratie voor GitHub en Azure DevOps

Mijn configuratie voor GitHub en Azure DevOps ziet er dan bijvoorbeeld als volgt uit:

Host ssh.dev.azure.com
  IdentitiesOnly yes
  IdentityFile ~/.ssh/1pkeys/azure.pub

Host github.com
  IdentitiesOnly yes
  IdentityFile ~/.ssh/1pkeys/github.pub

# Standaardinstellingen
Host *
  ServerAliveInterval 60
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

  # Versnelde herverbindingen
  ControlPath ~/.ssh/control_%C
  ControlMaster auto
  ControlPersist 1h

Met deze configuratie wijs ik per host naar de specifieke publieke sleutel. SSH gebruikt deze informatie om de juiste sleutel te selecteren, en de 1Password SSH-agent zorgt ervoor dat de bijbehorende private sleutel uit de kluis wordt gehaald wanneer dat nodig is. Zo combineer je de veiligheid van het opslaan van je sleutels in 1Password met de flexibiliteit van het gebruik van meerdere sleutels voor verschillende services, zonder dat je private sleutels op je schijf hoeft te bewaren.

Conclusie

De integratie van SSH in 1Password maakt het beheer van SSH-sleutels eenvoudiger en veiliger. Door gebruik te maken van deze nieuwe functies kun je efficiënter werken en tegelijkertijd de beveiliging van je systemen verhogen. Hoewel het even kan duren om je configuratie aan te passen, wegen de voordelen hier ruimschoots tegenop.

Heb je vragen of wil je je eigen ervaringen delen? Laat het me weten in de reacties!

Elektrisch rijden wordt steeds populairder, en dat betekent dat je niet om laadkaarten heen kunt. Aangezien mijn blogposts over tankkaarten nog steeds bij de meest gelezen artikels van deze blog horen, wou ik een moderne update geven over laadkaarten.

Laten we eens kijken hoe dit ecosysteem in elkaar zit, wie er wat verdient, en hoeveel kaarten je eigenlijk nodig hebt.

Het Laadkaart-Ecosysteem: Hoe Werkt het?

Laadpaaluitbaters (CPO’s): Dit zijn bedrijven zoals Ionity, Allego, Shell, Tesla en Fastned die laadpalen langs snelwegen en in steden plaatsen. Ze hebben vaak verschillende tarieven:

• Publiek Tarief: De standaardprijs voor iedereen zonder speciale laadkaart of met hun eigen kaart of app.
• Wholesale Tarief: Een lager tarief voor laadkaartuitgevers.
• Abonnementen & Loyaliteit: Kortingen via eigen abonnementen of loyaliteitsprogramma's.

Aan de andere kant heb je Laadkaartuitgevers. (MSP) Dit zijn bedrijven als Shell, FreshMile en Maingau. Ze geven laadkaarten uit die werken bij diverse laadnetwerken. Sommige CPOs zijn ook MSPs.

De Verschillende Modellen van Laadkaartuitgevers

1. Kost+ Model:

Dit model was vroeger populair en werkt simpel. De Mobility Service Provider (MSP) rekent een kleine marge bovenop het standaard tarief dat de Charge Point Operator (CPO) vraagt. Dit kan een vast bedrag zijn of een percentage.

Voordelen:

• Transparant: De kosten zijn relatief duidelijk en voorspelbaar, zeker als de CPO de prijs duidelijk afficheert aan de paal.
• Redelijk Geprijsd: Je betaalt een kleine extra marge bovenop de standaardprijs, maar niet buitensporig veel.

Nadelen:

• Onvoorspelbaarheid: De exacte prijzen kunnen variëren omdat ze gebaseerd zijn op wat de CPO op dat moment rekent.
• Beperkte Besparing: Mogelijk mis je speciale deals of kortingen van andere aanbieders.

2. Uniform Tarief:

Dit model hanteert een vast tarief per type paal (AC of DC) en per regio, ongeacht de kosten die de CPO aan de kaartuitgever rekent.

Voordelen:

• Consistentie: Altijd dezelfde prijs, of je nu bij een Allego AC-paal in Antwerpen of een Total Energies AC-paal in Namen laadt.
• Eenvoudig: Je hoeft de tarieven niet op te zoeken omdat ze consistent zijn.

Nadelen:

• Overbetalen: Soms betaal je te veel voor goedkope palen of mis je tijdelijke kortingen.
• Hoge Prijzen: Om verliezen te dekken, kunnen de uniforme tarieven relatief hoog zijn.
  

3. Stuntprijzen:

Sommige kaartuitgevers bieden tijdelijk zeer lage prijzen om snel klanten te trekken, zelfs als ze er verlies op maken.

Voordelen:

• Extreem Lage Kosten: Onverslaanbare tarieven, zelfs onder marktprijzen.
• Snelle Bekendheid: Dit helpt nieuwe merken snel een sterke klantenbasis te krijgen.
  

Nadelen:

• Korte Duur: Stuntprijzen blijven meestal niet lang bestaan en kunnen na een tijd abrupt veranderen.
• Beperkte Betrouwbaarheid: Na de stuntperiode stijgen de tarieven vaak fors of verandert het businessmodel.

Hoeveel Kaarten Moet Je Hebben?

Optimaliseer Kosten en Gemak: Kies één of twee kaarten die bij je laadpatroon passen en bespaar zonder het overzicht te verliezen.

• Vermijd Overkill: Te veel kaarten zijn onhandig en leveren vaak weinig voordeel op. Wil je elke cent korting, moet je bovendien elke stuntprijs operator najagen. Wil je hier elke maand een uur tijd aan spenderen om 15 euro goedkoper te laden op een jaar?
• Jaarlijkse Evaluatie: Tarieven veranderen, dus controleer jaarlijks of je kaarten nog optimaal zijn.

Welke Kaarten Zijn Geschikt?

Focus op Besparing: Heb je geen eigen laadpaal en ben je afhankelijk van publieke AC-laders in je buurt? Kies dan kaarten die je daar de meeste voordelen bieden. Als je veel reist, kies dan ook een kaart met goede tarieven bij snelladers op jouw route.

Pas op voor Overcomplicatie: Een kaart die je een superkorting geeft bij een specifieke lader is zinloos als je daar nooit laadt.

Tesla: Een Apart Geval

Tesla’s Superchargers zijn uitgebreid en handig geplaatst, maar werken alleen via de Tesla-app. Hun tarieven variëren per locatie en tijdstip, maar zijn vaak goedkoper dan andere merken. Koppel je betaalkaart vooraf aan je Tesla-account voor een soepel proces.

Heb je wel een Kaart Nodig?

Ja, absoluut! Ondanks de nieuwe EU-regels die DC-palen verplichten bankkaarten te accepteren, blijven veel oudere palen en AC-laders uitsluitend via laadkaarten werken. Bovendien bieden kaarten een extra betaaloptie als de lezer defect is.

Kaart of App?

Hoewel veel kaarten ook via een app werken, biedt de fysieke kaart meestal het beste gebruiksgemak. Een goede internetverbinding is niet altijd gegarandeerd, en de juite paal selecteren via een app kan lastig zijn.

Laadkosten voor Bedrijven

Voor bedrijven en zelfstandigen is het belangrijk om facturen te kunnen indienen. Laadkaarten bieden doorgaans gedetailleerde facturen voor je boekhouder, in tegenstelling tot directe betalingen via bankkaarten.

Mijn Favoriete Laadkaarten

Dit zijn enkele kaarten die ik momenteel nuttig vind:

• Shell Recharge: Een allround kaart met redelijke tarieven en brede acceptatie.
• FreshMile: Interessant voor snelladers (behalve Ionity) met goede tarieven.
• ElectroVerse: Een goede keuze voor bv. Ionity-laders in Frankrijk.
• Tesla App: Onmisbaar voor Tesla Superchargers.
• Renault Mobilize: [Toegevoegd januari 2025 aan deze blog, gebruik deze sinds juli 2024]. De kaart van Renault kan je ook als niet-Renault klant gebruiken. Ik had deze oorspronkelijk in de categorie "stuntprijzen" die niet lang blijven duren, maar de "promo" blijft geldig. De standaard tarieven zijn niet veel soeps, maar als je het abonnement van 5 euro per maand neemt, laad je aan 29 cent bij Ionity. Nergens anders vind je Ionity palen aan die prijs voor zo'n laag abonnement. Voorlopig een aanrader voor wie vaak bij Ionity zal laden.

Tot Slot

• Houd het Simpel: Je hebt geen 10 kaarten nodig.
• Focus op Gebruik: Kies kaarten die voordelig zijn waar jij vaak laadt.
• Tesla App voor SuCs: Noodzakelijk voor Tesla-laders.
• Gebruik Kaarten: Moderniseren is belangrijk, maar ga nog niet zonder laadkaart op pad in 2024.
• Koop Geen Hybride :) (of als je eentje hebt om puur fiscale redenen, bezet nooit een laadpaal)

De Belgische bankensector en tech start-ups lijken in twee verschillende universa te opereren. Enerzijds hebben we de dynamische, snel evoluerende wereld van tech start-ups, die gekenmerkt wordt door innovatie, flexibiliteit en snelheid. Anderzijds staan de banken, ogenschijnlijk vastgeroest in oude gewoonten, traag en onaangepast aan de behoeften van deze moderne ondernemingen.

Start-Up Ongastvrij: Waarom Banken Falen

De vraag dringt zich op: waarom falen onze banken in het ondersteunen van de unieke behoeften van start-ups? Start-ups vereisen een vlotte en efficiënte dienstverlening, flexibiliteit en een begrip van hun snel veranderende eisen. Maar in plaats daarvan worden ze geconfronteerd met een traag, bureaucratisch systeem dat hen hindert in plaats van helpt.

Geen enkele bank in België kan momenteel met trots de titel "start-up vriendelijk" dragen. Dit is een gemiste kans, want start-ups zijn de drijvende kracht achter innovatie en economische groei. Ze hebben banken nodig die hun tempo kunnen bijhouden, die begrijpen dat tijd geld is, en die processen hebben gestroomlijnd om aan hun specifieke behoeften te voldoen. Ze kopen alles online, hebben klanten in het buitenland, betalen een aanzienlijk deel van hun diensten direct, via Visa of Mastercard en in US Dollar.

Het Falen van 'Innovatieve' Diensten

Banken lijken hun focus te hebben verloren. In plaats van het stroomlijnen van hun diensten om echt nuttig te zijn voor start-ups, worden klanten overstelpt met gimmicks en irrelevante 'innovaties'. Het sturen van pop-upberichten over voetbalgoals of het aanbieden van eigen virtuele munten is niet wat start-ups nodig hebben. Deze zogenaamde innovaties zijn niet meer dan afleidende foefjes die geen echte waarde toevoegen aan de kernactiviteiten van bankieren.

De Oproep tot Echte Verandering

Het is hoog tijd dat de bankensector zich heroriënteert en zich focust op wat echt belangrijk is voor start-ups: efficiëntie, snelheid en relevante dienstverlening. Echte innovatie is niet het toevoegen van meer functies, maar het verbeteren en versnellen van de bestaande diensten. Banken moeten hun klanten niet zien als passieve ontvangers van hun diensten, maar als actieve partners die behoefte hebben aan snelle, efficiënte en toegespitste ondersteuning.

Conclusie: Tijd voor Actie

Het is tijd voor actie. Banken moeten hun oude manieren van doen afwerpen en zich richten op het ondersteunen van de groeiende gemeenschap van tech start-ups in België. Dit betekent afscheid nemen van yesterwork en het omarmen van echte innovatie die waarde en efficiëntie toevoegt. Start-ups hebben banken nodig die niet alleen hun geld bewaren, maar ook hun ambities en groei ondersteunen. De toekomst van de Belgische economie kan hiervan afhangen. Laten we hopen dat onze banken deze boodschap ter harte nemen en de uitdaging aangaan om echte, start-up vriendelijke diensten te leveren.

Waarschijnlijk komt het door ouder te worden. Misschien komt het omdat een tweede januari toch maar wat raar aanvoelt. Maar vandaag sta ik even stil, kijk achter me, om dan snel terug vooruit te kijken.

Tweeduizenddrienentwintig was een bewogen jaar. Het was een verademing dat het jaar niet gedomineerd werd door Corona. Helaas waren er genoeg andere gruwels om ons met de voetjes op de grond te brengen.

Voor mij was het het jaar waarin ik de prijs begin te betalen van de eerste grote EV van een Europese autofabrikant te willen. De I-Pace is nu vijf jaar, en de pionierstaks begint binnen te rollen. Het is ongelooflijk hoeveel sneller en efficienter de batterijen geworden zijn. Onze snellaadstops zouden met een moderne EV ongeveer dubbel zo snel gaan. Gelukkig is dit enkel op vakantie een probleem. Maar daarnaast is de auto de laatste maanden ook in de garage langsgeweest voor lege 12V batterijen, voor een lekkende luchtvering, een lekkende voorruit, een nood-update aan de batterijen, en (als gevolg van die laatste update) al twee maal voor defecte batterij-cellen te vervangen.

Daarnaast was 2023 het jaar waarin Bernard en ik eindelijk besloten iets te gaan doen met het idee waar we al een paar jaar op broeiden en wat een logisch volgende hoofdstuk is van het boek waarvan Openminds het eerste hoofdstuk was. Al snel bleek dat Bram op dezelfde golflengte zat, en bouwen we met drie aan Krane Labs.

Maar ik wil in deze post niet te lang blijven stilstaan bij het verleden en vooruit kijken

Zoals je merkte, ben ik regelmatiger op deze blog beginnen schrijven, en zal ik dat in 2024 blijven doen. EVs, ondernemerschap en bij uitbreiding de wereldeconomie, maar ook hard-core tech blijven de rode draad. De blog zit trouwens sinds even in een nieuw jasje, overzichtelijker, eenvoudiger. Ook de analytics (cookie-free, dus geen cookie banner meer!), comments en bijhorende nieuwsbrief zijn beter geïntegreerd.

Heel veel energie zal dit jaar naar Krane Labs gaan. We zijn begonnen, maar nog lang niet waar we willen zijn. We hebben ambitieuze groeiplannen voor 2024, willen onze klanten nog meer toegevoegde waarde bieden en stilaan onze naam bekend maken. Avanti! Daarnaast blijft DNS mijn nerdy-uitlaatklep, en ben ik met DNSGuru ook nog leuke dingetjes van plan. Daarnaast blijf ik andere start-ups en scale-ups mentoren, iets wat ik bijzonder graag doe.

Auto-gewijs hoop ik de ID Buzz met 7 plaatsen te kunnen bestellen binnenkort. Ik zal waarschijnlijk nooit meer zo'n fantastische "drivers-car" als de Jag hebben, maar de technologie evolueert. Zodra VW de order boeken opent, zal je dat hier wel lezen 😄

Een persoonlijk hoogtepunt voor me moet Oktober worden. Ik ga immers live naar de America's Cup. Mijn tickets voor Barcelona zijn al geboekt.

Tot slot

Terwijl ik terugblik op de hoogtepunten en uitdagingen van 2023, voel ik een hernieuwde energie en vastberadenheid voor het jaar dat voor ons ligt. Met de lessen van het verleden als mijn gids, kijk ik uit naar de groei en kansen die 2024 belooft te brengen. Of het nu gaat om de verdere ontwikkeling van Krane Labs of het beleven van de opwinding van de America's Cup in Barcelona, elk aspect van dit nieuwe hoofdstuk belooft zijn eigen avontuur te zijn.

Het leven is een constante beweging voorwaarts, een eindeloze rit van leren, groeien, en jezelf opnieuw uitvinden. Ik nodig jullie uit om mij te vergezellen op deze reis, om samen de uitdagingen aan te gaan en de successen te vieren. Hier is naar een jaar van vooruitgang, ontdekking, en duurzame technologische innovatie. Avanti!

PS: wil je elk nieuw artikel automatisch in je mailbox? Dat kan!

Wie mij volgt op Linked In las de aankondiging als dat Bernard, Bram en ik een nieuw bedrijf gestart zijn. Heb je alles op mijn Linked In gevolgd, heb je onze website helemaal uitgeplozen? Skip dan gerust de volgende vier paragrafen 😄.

Bernard was mijn mede-vennoot bij Openminds, Bram was er onze tweede medewerker. Bij Openminds wouden we de beste Belgische hoster zijn voor bedrijven die met de laatste technologieën aan de slag, bedrijven die voorliepen op hun sector-genoten.

Eén van de uitdagingen waar we de laatste jaren bij Openminds vaak over dachten, was de impact van de Public Cloud op de hostingmarkt. Langs de ene kant kan je onmogelijk tegen de schaal van Amazon, Google en Microsoft op en biedt het daardoor een hoop diensten die onze doelgroep direct en efficient kunnen helpen. Langs de andere kant kunnen die grote drie onmogelijk een super-gepersonaliseerde en white-glove support geven.

Als je nadenkt over hoe je daar een oplossing op moet bieden, kom je al snel bij Public Cloud specifieke consulting uit. Dat is zeker een nuttig en soms nodig model, maar Bernard, Bram en ik wouden iets meer doen dan dat. De eerste 16 jaar van deze eeuw zagen we dat je een succesvol bedrijf kan bouwen rond high-end diensten aan een vaste maandelijkse fee aanbieden. Konden we dit vertalen naar high-end oplossingen voor bedrijven die de stap naar de Public Cloud voor hun gemiddelde sectorgenoot zetten?

Krane Labs is geboren om die vragen te beantwoorden. De public cloud, met support, zonder uitgebreide consulting.

Security, ISO27001 en SOC2

Bij Krane Labs hebben we heel lang nagedacht over het model waarin we onze diensten aanbieden. Vrij snel lag vast dat we een antwoord willen bieden op ongeveer elke security eis van onze klanten willen kunnen volgen. Dat heeft een grote invloed gehad op keuzes als hoe we in de Public Cloud werken. Maar ook hoe we zelf werken, is daardoor bepaald.

Zo kwamen we heel snel tot de conclusie dat een ISO 27001 of SOC2 veiligheidscertificaat of -rapport niet op de roadmap voor de eerste zes maanden staat, we er toch helemaal "klaar" willen zijn. Concreet wil dat zeggen dat we van bij de start zoveel mogelijk keuzes maken die we voor ISO 27001 op dezelfde manier zouden moeten maken.

Zo'n traject is me natuurlijk niet vreemd, en wie me volgt weet dat ik grote voorstander ben om "te vroeg" eerder dan "te laat" kwaliteits- of veiligheids-standaarden te implementeren.

Daarom blog ik de komende weken en maanden op de Krane Labs blog heel transparant over wat en hoe we zelf dit traject doormaken.

De cruciale rol van ISO27001 en SOC2 voor techbedrijven behandel ik in de eerste blogpost. Waarom zou je een ISMS bouwen volgens een van beide standaarden, welke voordelen brengt het mee en waarom begin je er beter vroeg aan. Wanneer kies je voor ISO27001 of SOC2 en hoeveel verschil zit er nu echt tussen beide?

De tweede blogpost uit de reeks neemt de eerste concrete stappen. Over welke norm je waar moet kopen, hoe je de eerste structuur brengt in je ISO-gerelateerde documenten, en hoe je door de bomen het pad door het bos kan vinden. Het geeft een voorzet voor het cruciaalste stuk van elk veiligheidsbeleid: de risico analyse.

In verdere posts ga ik verder in op de risico analyse, de vertaling naar controls, waarom ik de beruchte "Annex A" maar lees enkele weken na de eerste risico analyse, en waarom dat perfect OK is. Daarna komt het harde werk: teksten en policies schrijven (dank je ChatGPT!), verfijnen en blijver verfijnen.

Ik zal deze blogpost aanvullen als ik nieuwe artikels schrijf, maar als je van dichter volgen, raad ik aan om je in te schrijven op de Krane Labs nieuwsbrief door je adres na te laten onderaan de pagina's op de Krane Labs website.

Veel volgers vragen me of ik de ID.Buzz, waarover ik zo enthousiast schreef, nu heb besteld. Na een proefrit was ik onder de indruk: ondanks de afwerking met veel hard plastic (ik ben verwend door de Jaguar I-Pace!) rijdt de Buzz verrassend aangenaam. Je mist het "camionette" gevoel volledig, wat een pluspunt is.

Het interieur? Ruimtelijk en comfortabel, zelfs op de middelste achterbank zit je gemakkelijk urenlang.

Maar waarom staat er dan nog geen Buzz op mijn oprit? Simpel: ik wacht op het model dat ik écht wil - de langere ID.Buzz LWB.

Prestaties en Batterij

De langere wielbasis van de ID.Buzz LWB maakt ruimte voor een krachtigere elektromotor en een 85 kWh batterij – een upgrade van de standaard 77 kWh. Dit betekent niet alleen een verbeterde rijervaring, maar ook een snellere oplaadtijd. Je kunt de batterij in slechts 25 minuten tot 80% opladen met een snelheid van 200 kW. Deze upgrades beloven een spannendere rijervaring en mogelijk een groter bereik, hoewel de exacte cijfers nog moeten worden onthuld.

Innovatie in het Interieur

Binnenin is de ID.Buzz LWB een toonbeeld van innovatie en comfort. Het model introduceert een panoramisch zonnedak en een ruitje achteraan dat open kan. Er zijn ook extra AC vents geplaatst, wat het comfort achteraan moet verhogen. Verlichte touchsliders en stembediening voegen een extra laag van gemak en moderniteit toe. Het is eigenlijk ongelooflijk dat de originele ID.Buzz en de ID.4 deze functie niet hadden.

Ik hoop stiekem dat de ergoActive stoelen uit de nieuwe ID.7 ook in de ID.Buzz leverbaar zullen zijn (of in het slechtste geval achteraf in te bouwen zijn).

Wachten...

Tenzij er de komende paar maand nog snel iets anders zou uitkomen (nieuwe Mercedes EQV, de grote Volvo met een meer Europese styling), of als VW de ID.Buzz LWB nog zou uitstellen, is de kans heel groot dat ik de langere Buzz zal bestellen.

Wanneer dat zal zijn is nog koffiedikkijken: volgens "wel ingelichte bronnen" ziet het er voorlopig nog steeds naar uit dat dit rond begin april zal zijn (hoewel de officiële PR van Dieteren nog spreekt van januari), maar gezien het recente slechte nieuws dat uit Wolfsburg komt, is niks meer zeker...

Ha, het paste zo goed in het hele "Vlaamse overheid spendeert miljardenjoenen aan consultants" verhaaltje dat de pers al enkele weken bezighoudt: HLN.be (I know) kwam met een verhaal waarom een "ethische hacker" aan het woord komt over wat een prutsers de Vlaamse Overheid is als het op mails aankomt in artikel met als titel "Hackers sturen valse 'fiscale fiches' vanuit vlaanderen.be: “Mailen als minister-president van Vlaanderen is fluitje van een cent”.

Een goedgeschreven artikel, dat niet. Het is wel duidelijk komkommertijd en dan worden uitspraken van "ethische hackers" niet meer gefactcheckt. Daarnaast is de insteek van het artikel niet helemaal correct, maar daar kom ik op het einde toe.

SPF

Het artikel raakt enkele heel juiste zaken aan. Er worden heel veel spam of phishing mails gestuurd die doen alsof ze van de Vlaamse overheid komen, ook ik erger me eraan, want hoewel de meeste worden tegengehouden door spamfilters, belanden er toch in mijn inbox.

De belangrijkste reden die het artikel aanhaalt, is de chaos in de SPF records, die wijzen op het feit dat niemand bij de overheid echt overzicht heeft over de gebruikte maildiensten, en er geen kritisch proces is bij het reviewen van de entries.

SPF-records zijn een stukje DNS informatie (de vaste lezers weten dat DNS een van mijn dada's is), die aan andere mailservers aangeven welke mailservers namens een domein verondersteld zijn mail te sturen. De records die op de vlaanderen.be domeinnaam staan, zijn syntactisch correct, maar bevatten bij nader inzicht een hoop rommel, zoals het artikel aanhaalt.

Het artikel is helemaal correct als het aanhaalt dat het grootste probleem bij deze SPF records zit.

Te veel SPF

Alleen maakt het artikel wat shortcuts en is het niet helemaal volledig op een paar andere punten. En mist het de essentie, maar daar kom ik straks op terug.

Zo vallen mij drie zaken op als ik het voor het eerst naar de SPF records kijk. Vooreerst zijn de SPF records enorm uitgebreid. Als ik snel tel, gaat het om 145 netwerk-blokjes, goed voor een klein miljoen (!) afzonderlijke ip-adressen.

Verder zijn er de talloze "RFC 1918" ip-adressen die erin voorkomen. Dit zijn adressen die enkel kunnen voorkomen in "private" netwerken zoals je thuis-net of bedrijfsnetwerken, maar op het internet onbruikbaar zijn. Er is geen enkele geldige reden om deze adressen op te nemen in een SPF record, toch niet in een organisatie die de basis netwerk hygiëne op orde heeft...

Als derde valt op dat de SPF records enkel individuele ip-blokken bevatten, en geen includes naar andere domeinen gebruiken. Let me explain ... Als je nieuwsbrieven verstuurt via een bepaald platform, of een extern-gehoste inschrijf-module gebruikt, sturen die externe diensten mail uit jouw naam. De ip-adressen van de servers die door die derde partij gebruikt worden om mail te sturen, moeten dus opgenomen worden in de SPF records van al hun klanten.

Dit zou willen zeggen dat elke keer zo'n uitbater iets aan hun infrastructuur verandert, ze alle klanten op voorhand zouden moeten melden welke nieuwe ip-adressen in gebruik genomen zullen worden. Omdat dit praktisch niet haalbaar is, kan je "doorverwijzingen" gebruiken bij SPF records. Zo kan je bv zeggen "dit ip hier is mijn bedrijfs-mailserver, maar ik gebruik MailChimp om mails te sturen, dus ga daar even kijken welke servers zij gebruiken om te mailen, en heb een webshop bij Shopify, die ook wel mailtjes in mijn naam mag sturen".

De Vlaamse overheid gebruikt die mogelijkheid compleet niet. Enkel individuele ip-adressen of ip-blokken zijn opgenomen. Er kunnen meerdere redenen zijn om dit te doen, maar tenzij de VO dit 100% geautomatiseerd heeft, werkt dit systeem niet. De gigantische hoeveelheid adressen die in de SPF lijst voorkomen, wijzen voor mij dat aan dit proces heel wat schort.

Oei, geen SPF?

Helaas gaat het artikel op een paar plekken in de mist. Vooreerst haalt het aan dat er Microsoft adressen op de lijst staan, en het de spammers daardoor wel heel makkelijk maakt.

Hoewel de SPF records van de VO inderdaad een gigantische adresblok van Microsoft opneemt en het als spammer allicht niet zo heel moeilijk is een ip-tje daaruit te bemachtigen op een Azure account, is enkel het opnemen van Microsoft adressen op zich niet zo'n probleem. Meer nog: als je organisatie Office365 gebruikt als mailplatform, moet je de SPF records van MS Office365 opnemen. Het is natuurlijk wel een probleem als je meer dan enkel de adressen van de Microsoft mailservers opneemt, maar dat onderscheid maakt het artikel niet.

Daarnaast zou de ethische hacker moeten zien dat de SPF records bij de Vlaamse overheid nog maar recent toegevoegd zijn. Ik heb in elk geval spam-samples van 30 mei 2023 of 5 juni 2023 die aangeven dat er op dat moment gewoon geen SPF record was. Update: een vriendelijke ziel bezorgde me een mail van 10 juni waaruit ik afleid dat er zelfs op 10 juni nog geen SPF records waren.

Update: Wouter Goderis toonde net aan dat de records er maar sinds 8 juni staan.

Het feit dat vlaanderen.be sindsdien SPF records heeft, is dus een reactie, geen oorzaak van de recente spam-golf. De VO zou dus aangemoedigd en gefeliciteerd moeten worden in het artikel. De SPF records zelf is nog gigantisch veel werk aan, maar de stappen zijn wel gezet! Het artikel slaat hier dus volgens mij de bal mis.

Dat neemt uiteraard niet weg dat de journalist ook niet kritisch moet zijn voor de uitspraken voor de uitspraken van de woordvoerder van Vlaanderen Digitaal die in de laatste paragraaf aan het woord komt. Het is op vandaag niet mogelijk om DKIM signing (waarbij aan elke mail een onzichtbare handtekening wordt toegevoegd die gecontroleerd wordt door de ontvangende mailserver) af te dwingen. Hetgeen het dichts in de buurt komt en waar de woordvoerder op alludeert is het DMARC record. Die geeft aan dat de mail waarschijnlijk spam is als of de DKIM header ontbreekt of de zendende mailserver niet in de SPF adressen zit (en daarnaarst is er nog iets technisch over alignment maar dat zou ons te ver brengen).

Met andere woorden: als een mail niet digitaal via DKIM getekend is, maar de mail is wel verzonden door een server in de (veel te) uitgebreide set ip-adressen in het SPF record, dan zal de mail niet noodzakelijk als spam aanzien worden.

In t kort ...

... had het artikel beter de titel "Hackers sturen valse 'fiscale fiches' vanuit vlaanderen.be: Vlaamse Overheid pakt het aan (maar heeft nog een weg te gaan)".

Daarnaast is goed dat SPF records plaatsen en een strikte DMARC policy implementeren helpt. Bijna alle grote mailservers (GMail en Microsoft voorop) hechten een groot belang aan deze systemen. Waar ze vroeger eerder "optioneel" waren, zijn ze vandaag essentieel. Zowel in het reduceren van de hoeveelheid spam in onze mailboxen, maar ook in het omgekeerde. Het is cruciaal dat je deze records correct en juist geïmplementeerd hebt om zeker te zijn dat je mail toekomt in de mailbox van je ontvangers. Daarover schrijf ik later nog wel eens iets ... (insert mysterieus muziekje hier)

Update 21/06/2023: Er blijft spam toekomen met vlaanderen.be afzenders. Het lijkt erop dat mijn suggestie hieronder dat ook de Nameserver setup niet optimaal was, correct blijkt: de nameservers geven heel vaak een SERVFAIL foutbootschap als je de SPF records opvraagt. Overbelast? Rate-limiting ergens? Te weinig redundantie zowiezo.