QR-menu’s: wijzig de menupagina, niet de code

QR-codes voor menu’s werden in 2020 overal gebruikt en zijn nooit verdwenen. Bij de meeste restaurants werd de code één keer gemaakt door degene die de website beheerde, en daarna nooit meer bekeken — wat belangrijk is omdat deze situatie juist in de horeca voorkomt: veel codes, veel scans, lang meegaand drukwerk en krappe marges.

Waarom worden restaurants per tafel gefactureerd?

Omdat een prijs per code samenkomt met een bedrijf dat veel codes nodig heeft. Een restaurant met twaalf tafelkaartjes, een raamsticker en een sticker op een afhaaltas heeft veertien codes. Bij een dynamisch abonnement met prijs per code zijn dat veertien maandelijkse posten, voor een menu dat vroeger alleen de prijs van papier kostte.

Het abonnement blijft hier ook ongewoon lang lopen. Tafelkaartjes zijn gelamineerd, stickers kleven vast en menu’s worden hooguit per seizoen opnieuw gedrukt. Opnieuw drukken is een echt project, dus het maandbedrag blijft er comfortabel onder — en precies zo is de prijs gekozen. De echte kosten van een "gratis" QR-code legt die rekensom uit.

Wat leert de aanbieder over je gasten?

Elke scan is een HTTP-verzoek aan de aanbieder voordat het menu wordt geladen. Zonder cookies of toestemming ontvangen zij het IP-adres, tijdstip, apparaat en besturingssysteem van de gast, plus de voorkeurstaal — en omdat elk tafelkaartje een eigen korte link heeft, ook om welke tafel het ging.

Bij elkaar opgeteld geeft dat een gedetailleerd beeld van je service: het aantal gasten per uur, de omloopsnelheid van tafels, welke tafels populair zijn, patronen op werkdagen tegenover het weekend en de talenmix van je klanten. Het is echt bruikbare operationele informatie over je restaurant, maar die wordt door je meubilair gegenereerd en door iemand anders verzameld.

Over het hele klantenbestand van de aanbieder gaat het om meer. Dezelfde apparaatvingerafdruk die terugkomt bij restaurants, winkels en locaties in een stad beschrijft iemands verplaatsingen. Het Hof van Justitie oordeelde in *Breyer* (C-582/14) dat een dynamisch IP-adres dat door een websitebeheerder wordt geregistreerd, een persoonsgegeven kan zijn. Daarom gaat dit om naleving en niet om nieuwsgierigheid — en volgens de AVG komt de verantwoordelijkheid doorgaans te liggen bij het bedrijf dat de code heeft ingezet. Wat een QR-proxy logt gaat hier dieper op in.

Wat gaat er in de praktijk mis?

De eerste drie zijn hetzelfde probleem in een andere gedaante: het menu hangt af van een bedrijf dat niet van jou is. Het vierde staat los van de facturering, maar wordt er wel door verergerd, omdat een gast die gewend is aan een onbekend kort domein niet kan zien dat een kwaadaardig domein anders is.

Volgens de beoordeling van het NCSC zijn QR-codes in cafés en restaurants meestal veilig, terwijl veel meer voorzichtigheid nodig is bij codes die per e-mail binnenkomen. Het resterende fysieke risico is de sticker die over de code heen is geplakt. De oplossing is eenvoudig: controleer de kaartjes.

Hoe ziet de vaste versie eruit?

Hoe zit het met bestel- en betaalcodes?

Die moet je los zien van menucodes, omdat het risicoprofiel echt anders is en het advies niet hetzelfde is.

Een bestel-en-betaalcode stuurt een gast naar een pagina waar die kaartgegevens invoert. Daardoor worden alle problemen in dit artikel ernstiger: een sticker over een betaalcode leidt rechtstreeks naar kaartfraude in plaats van alleen naar ergernis, en een gast die jouw domein niet kan herkennen in het voorbeeld, kan je betaalpagina niet onderscheiden van een overtuigende kopie. De waarschuwing van de FTC over stickers die over legitieme codes worden geplakt gaat in andere situaties precies over dit patroon; parkeermeters zijn het bekendste voorbeeld.

Daaruit volgen twee regels. Ten eerste moet een betaalcode altijd je eigen domein of het echte domein van je bestelplatform bevatten — nooit een algemene verkorter, omdat je daarmee het enige controlesignaal van de gast wegneemt. Ten tweede moet je het domein in leesbare tekst naast de code afdrukken en de fysieke kaartjes volgens een schema controleren; beide maatregelen zijn goedkoop en samen de enige verdediging die aan tafel werkt.

Als je bestelplatform de codes uitgeeft, decodeer er dan één en kijk welk domein in de inhoud staat. Sommige platforms zetten hun eigen domein er rechtstreeks in, en dat is prima. Andere sturen eerst via een externe verkorter, waardoor er een extra, niet-gecontracteerde partij tussen je gast en het kaartformulier komt.

Hoe stap je over?

1. Decodeer een huidig tafelkaartje met onze lezer en kijk welk domein in de inhoud staat. Als het niet van jou is, gebruik je een gehuurde omleiding.
2. Kies een stabiele URL — yourrestaurant.com/menu — en zorg dat die niet verandert. Als je de mogelijkheid wilt houden om die later te verplaatsen, laat je de code naar yourrestaurant.com/m verwijzen en stuur je vanaf daar door.
3. Genereer een statische [URL-QR-code](Url) die dat adres bevat.
4. Voeg tracking per plaatsing toe als je dat wilt: ?src=table, ?src=window, ?src=takeaway. Je eigen analysetools geven je dan dezelfde aantallen per plaatsing die het dashboard je verkocht.
5. Druk de URL in leesbare tekst naast de code af, zodat gasten het menu zonder scannen kunnen bereiken en kunnen zien dat de code van jou is.
6. Druk opnieuw af tijdens je volgende geplande drukronde, en zeg het abonnement op zodra de oude kaartjes niet meer worden gebruikt.

Als de codes al dood zijn en gasten vandaag op een upgradepagina terechtkomen, behandelt de gids voor herstel na gijzeling de noodprocedure voordat je opnieuw laat drukken.

Vervang de codes nu, zodat alles klaar is voor de volgende drukronde: URL-QR-code. Achtergrond: de waarheid over QR-codescams.