Deze pagina legt per onderwerp uit wát we doen, hóe we het gebouwd hebben, en welke wet daar iets over zegt. Steeds op vijf niveaus, zodat je zelf kiest hoe diep je gaat. Alles wat hier staat is waar van de versie die nu draait — niet van wat er op de planning staat.

Hoe je deze pagina leest

  1. 🧸 Alsof je vijf bent — het idee in gewone woorden, zonder jargon.
  2. 📖 Gewone samenvatting — wat het voor jou als gebruiker betekent.
  3. ⚙️ Hoe we het gebouwd hebben — de vorm van de oplossing. Bewust zonder de precieze werking: een beschrijving die uitlegt hoe je een maatregel omzeilt, is geen transparantie maar een handleiding.
  4. ⚖️ Juridische dekking — welke verplichting hier speelt en hoe wij die invullen.
  5. 📐 Juridisch — technisch — de exacte artikelen. Ook hier geen implementatiedetails.
Waarom hier ook oranje staat — en hoe je het moet lezen. Een compliance-overzicht dat uitsluitend groen toont, is geen overzicht maar een reclamefolder. Vier onderwerpen dragen een oranje label. Dat betekent niet dat het onderwerp zelf openstaat: die vier werken en zijn afgedekt, net als de rest. Het betekent dat er bínnen dat onderwerp één afgebakend punt is dat nog niet dicht is. Elk van die punten heeft onderaan het onderwerp een eigen blok — “⚠️ Open punt” — waarin staat wat er precies open is, wat níet, waarom het nog niet dicht is, en wat het zou sluiten. Dezelfde punten staan in onze interne documenten, in dezelfde bewoordingen.
📡

Nabijheid & Bluetooth

✅ Live · ⚠️ 1 open punt

Iemand in de buurt vinden, zonder te weten waar iemand is.

🧸Alsof je vijf bent

Je telefoon fluistert een verzonnen woord, een beetje zoals een geheim wachtwoord op het schoolplein. Alleen telefoons van mensen die óók meedoen herkennen dat woord. Je echte naam fluistert hij nooit. En dat verzonnen woord verandert steeds, zodat niemand je ermee kan volgen.

📖Gewone samenvatting

Ontdekken werkt via Bluetooth, niet via een kaart. Jouw telefoon zendt een anoniem, steeds wisselend kenmerk uit — geen naam, geen account, geen locatie. Beide mensen moeten Beacon-modus zélf aanzetten; heeft één van de twee hem uit, dan gebeurt er niets. De app zegt alleen “hier vlakbij” of “in de buurt”. Nooit een aantal meters, en nooit een pijl die ergens heen wijst.

⚙️Hoe we het gebouwd hebben
  • Het uitgezonden kenmerk is anoniem en ververst zichzelf om de paar minuten, over een radioadres dat het besturingssysteem zelf al willekeurig maakt. Twee sessies zijn daardoor niet aan elkaar te knopen.
  • De scanner ontvangt onvermijdelijk ook koptelefoons, auto’s en laptops. Alles zonder ons kenmerk wordt weggegooid in de ontvangstfunctie zelf — vóórdat er ook maar iets wordt weggeschreven. Dat is in code afgedwongen, niet in een afspraak.
  • Signaalsterkte wordt uitsluitend op jouw toestel omgezet naar een label. Die meting verlaat je telefoon niet, wordt niet bewaard en bereikt de ander nooit.
  • Blokkades worden op de server afgedwongen, vóórdat een kenmerk aan een profiel wordt gekoppeld. Wie jou blokkeert, bestaat voor jou simpelweg niet in de radar.
  • Een sessie loopt af, en verlengen kan tot een harde bovengrens per sessie die de server bewaakt. De radio werkt alleen op de voorgrond — een telefoon in je zak zendt niets uit.
⚖️Juridische dekking

Dit is de verwerking met het hoogste risico in onze eigen beoordeling, en zo schrijven we het ook op. De gegevensbeschermingseffectbeoordeling (DPIA) registreert het als risico R8: iemand kan vaststellen dat een specifiek persoon, met naam en foto, hier en nu aanwezig is. Dat risico is niet weg te nemen — het ís de functie — maar het is ingeperkt met maatregelen die wij verplicht hebben gesteld in plaats van optioneel.

📐Juridisch — technisch
  • AVG art. 35 — DPIA uitgevoerd, versie 2.2 (augustus 2026). BLE-nabijheid valt onder de AP-trigger “innovatieve technologie met grote privacyrisico’s”.
  • AVG art. 5(1)(c) — dataminimalisatie. Meterwaarden zijn gebouwd, gemeten en weer weggegooid: de metingen konden een getal niet dragen (18 dB spreiding op één vaste meter). Twee grove labels is wat de radio wél kan waarmaken.
  • AVG art. 25 — privacy by design: symmetrische opt-in, wisselende kenmerken, alleen voorgrond, server-side blokkades.
  • Restrisico R10, open en zichtbaar: een passieve scanner kan zien dát iemand deze app draait. Zie het open punt hieronder.
⚠️Open punt

De iOS-uitzending draagt nog een leesbare app-naam

Wat er open staat — en wat niet. Nabijheidsontdekking zelf werkt en is afgedekt. Het open punt is smal: een passieve scanner in de buurt kan aan de uitzending zien dát iemand deze app draait. Niet wie, niet waar, geen profiel — maar wel een gevolgtrekking over iemands privéleven die terechtkomt bij een derde die nergens toestemming voor heeft gegeven.

Waarom het nog niet dicht is. De ontvangstkant accepteert de anonieme vorm al en staat live. De laatste stap zit in native code, en die kan niet via een over-the-air-update mee — daar is een volledige app-store-build voor nodig.

Waarom die volgorde met opzet zo is. Als de uitzendkant eerst was aangepast, zou elke al geïnstalleerde telefoon blind zijn geworden voor nieuwe toestellen: ontdekking zou stilletjes stoppen te werken voor mensen die nog niet hadden bijgewerkt. De ontvangstkant moest dus eerst landen en zich verspreiden. Dat is gebeurd, en op een echt toestel gemeten voordat we verdergingen.

En de eerlijke ondergrens. Ook als die build er is, verkleint dit het risico, het sluit het niet. De uitzending draagt nog steeds een vast technisch kenmerk dat ontdekking nodig heeft om te kúnnen werken — je kunt dat niet tegelijk verbergen én gebruiken. Echt sluiten vraagt een kenmerk dat meeroteert, en dat staat niet gepland. Dit geldt voor elke Bluetooth-app; we doen alleen niet alsof het anders is.

📍

Locatie & de Liefdesronde

✅ Live

Eén vage stip, één uur, en daarna echt weg.

🧸Alsof je vijf bent

Als je meedoet zetten we één wazig stipje op een kaart — als een vingertop op een atlas, niet een speld. Na ongeveer een uur veegt de kaart zichzelf schoon. Het stipje is dan echt weg, niet verstopt.

📖Gewone samenvatting

Bij het aanzetten van Beacon-modus leggen we één locatie vast, zodat de kaart kan laten zien waar het ongeveer druk is. Niet doorlopend, nooit op de achtergrond. Wat anderen zien is bewust onnauwkeurig gemaakt, en je stip verschuift pas als je een flink stuk hebt gelopen. Na 60 minuten wordt de coördinaat verwijderd — niet verborgen, verwijderd.

⚙️Hoe we het gebouwd hebben
  • Vastgelegd op het moment dat jij zelf de beacon start. Er is geen achtergrondproces dat je volgt.
  • Wat anderen te zien krijgen is vervaagd tot een tiental meters, en de positie wordt pas herschreven na een ruime verplaatsing — zodat een stip niet zachtjes met je meebeweegt.
  • Andere gebruikers krijgen een grove afstandsband, nooit ruwe coördinaten.
  • Een achtergrondproces ruimt met vaste tussenpozen op wat buiten het uur valt, en maakt álle velden leeg waarin die coördinaat voorkomt — ook de precieze variant die de kaartfunctie zelf nooit uitleest. Een lopende sessie wordt nooit halverwege opgeruimd.
⚖️Juridische dekking

Op onze website stond al dat de locatie na maximaal 60 minuten wordt verwijderd. Bij controle bleek dat die 60 minuten alleen een weergavefilter waren: de kaart toonde de stip niet meer, maar de coördinaat bleef staan. We hebben toen de belofte waargemaakt in plaats van de tekst af te zwakken. Dat is de richting die we aanhouden wanneer gepubliceerde tekst en draaiende code het oneens zijn.

📐Juridisch — technisch
  • AVG art. 5(1)(e) — opslagbeperking. De bewaartermijn wordt nu afgedwongen door een opruimproces, niet slechts beweerd in beleid.
  • AVG art. 5(1)(c) — minimalisatie: één momentopname per activering, vervaagd vóór deling, afstandsband in plaats van coördinaten.
  • DPIA-punt L1 — GESLOTEN vóór publicatie. In de DPIA staat er expliciet bij dat de eerste reparatiepoging zélf onvolledig was: één opslagveld met dezelfde coördinaat op volle precisie werd gemist, en is daarna alsnog meegenomen. Een DPIA die alleen geslaagde pogingen vermeldt is niets waard.
  • DPIA-risico R11 — van “zeker” naar “laag”.
✍️

Toestemming

✅ Live · ⚠️ 1 open punt

Twee aparte vinkjes, want één vinkje voor alles is geen keuze.

🧸Alsof je vijf bent

We vragen twee keer of iets mag, op twee verschillende momenten. Niet één groot vinkje waar stiekem tien dingen in zitten. En als je later “toch maar niet” zegt, mag dat — met één tik, en dan stopt het meteen.

📖Gewone samenvatting

Bij registratie staat een apart vinkje, los van de privacyverklaring en de voorwaarden, voor de gevoelige gegevens die nu eenmaal bij een datingapp horen. Het staat standaard uit. Bij de eerste keer Beacon-modus volgt een tweede, aparte toestemming voor Bluetooth-aanwezigheid en die ene locatie. Die tweede is géén voorwaarde om de app te gebruiken: je account werkt volledig zonder. Intrekken doe je in de instellingen, met één bevestigde tik.

⚙️Hoe we het gebouwd hebben
  • De twee toestemmingen worden los van elkaar vastgelegd, met tijdstip én met de versie van de tekst waarmee je akkoord ging — een ja/nee-vinkje kan niet laten zien wáár je ja tegen zei.
  • De weigering wordt afgedwongen op de server, niet in de app. Zonder geldige tweede toestemming wordt het starten van een beacon geweigerd, ook als iemand de app omzeilt en rechtstreeks met onze servers praat.
  • Intrekken beëindigt een lopende beacon onmiddellijk en wist meteen de bijbehorende kaartgegevens — niet pas wanneer de sessie vanzelf afloopt.
  • Dit staat volledig los van de Bluetooth-toestemming van je telefoon. Dat is een toegangsrecht van je besturingssysteem, geen AVG-toestemming, en we behandelen het ook niet zo.
⚖️Juridische dekking

Wat vaststaat: toestemming die verstopt zit in “ik ga akkoord met de voorwaarden” is geen uitdrukkelijke toestemming. Dat was de situatie hier, en die is opgeruimd — vandaar twee losse vinkjes op twee momenten. Wat niet vaststaat is of die opzet juridisch volstaat; dat is ons belangrijkste open punt en het staat voluit onderaan dit onderwerp.

📐Juridisch — technisch
  • AVG art. 9(2)(a) — uitdrukkelijke toestemming voor bijzondere categorieën. Zie het open punt hieronder (C1).
  • AVG art. 7(2) — een toestemmingsverzoek dat samen met andere zaken wordt gedaan, moet duidelijk te onderscheiden zijn. Vandaar een eigen vinkje in een eigen kader, standaard uit.
  • AVG art. 7(1) — aantoonbaarheid. Daarom leggen we de versie van de tekst vast, en niet alleen een vinkje.
  • AVG art. 7(3) — intrekken moet net zo eenvoudig zijn als geven. Eén tik, met onmiddellijk effect.
  • AVG art. 7(4) / overweging 43 — “vrijelijk gegeven”. Dat is exact de vraag die openstaat voor het eerste vinkje. Door de tweede toestemming los te houden, geldt die vraag alleen voor verwerking die onlosmakelijk bij een datingdienst hoort, en niet voor locatie.
  • Bestaande accounts en twee oude registratieroutes staan op niet vastgelegd. Bewust niet met terugwerkende kracht ingevuld: een achteraf ingevulde toestemming is bewijs dat instort zodra iemand vraagt waar het vandaan komt.
⚠️Open punt

Of deze toestemmingsopzet juridisch voldoende is, is nog niet getoetst

Wat er open staat — en wat niet. Het mechanisme is gebouwd en staat live: twee losse toestemmingen, standaard uit, met tijdstip en tekstversie vastgelegd, en de weigering wordt op de server afgedwongen. Wat níet vaststaat is of dat juridisch genoeg is. Dat is een ander soort vraag, en het is niet de onze om te beantwoorden.

Waarom het open blijft staan. Iets bouwen is niet hetzelfde als dat het volstaat. We hadden dit punt kunnen sluiten op het moment dat de code werkte — dat zou het comfortabel hebben gemaakt en onwaar. Twee dingen zijn concreet onbeslist: (1) is de toestemming bij registratie “vrijelijk gegeven” als je zonder die toestemming geen account krijgt? Ons argument is dat een datingdienst zonder die verwerking simpelweg niet bestaat, dus dat het geen voorwaarde is die op onnodige verwerking wordt gelegd. Dat argument is verdedigbaar en het is niet beslecht. En (2) is de formulering specifiek en begrijpelijk genoeg om uitdrukkelijke toestemming te zijn, en niet alleen goed geïnformeerde instemming?

Wat het bouwen wél veranderd heeft. Niet het antwoord — de vráág. Die is verschoven van “ontwerp een toestemmingsmechanisme voor ons” naar “is deze tweedeling voldoende?”. Dat is smaller, goedkoper en beantwoordbaar. Bewust is de tweede toestemming (Bluetooth en locatie) buiten de registratie gehouden, zodat de vrijelijk-gegeven-vraag alleen speelt bij verwerking die onlosmakelijk bij de dienst hoort, en nooit bij locatie.

Wat het sluit. Een oordeel van een jurist. Niet meer engineering — dat deel is af.

💪

Jouw rechten over je gegevens

✅ Live

Inzien, meenemen, weggooien — vanuit de app, zonder e-mail te hoeven sturen.

🧸Alsof je vijf bent

Alles wat wij van jou hebben, is eigenlijk van jou. Je mag het bekijken. Je mag er een kopie van meenemen naar een andere plek. En je mag zeggen: gooi maar weg. Dan gooien we het echt weg.

📖Gewone samenvatting

Je kunt in de app een kopie van je gegevens downloaden in een formaat dat andere software kan lezen, en je kunt je account zelf verwijderen — zonder tussenkomst van een medewerker en zonder wachttijd bij een helpdesk. Verwijderen betekent verwijderen: je profiel, je berichten, je crush-geschiedenis. Wat overblijft is een klein, opzettelijk kaal spoor waar de wet ons dat verplicht — zie het onderdeel over meldingen hieronder.

⚙️Hoe we het gebouwd hebben
  • Export en verwijdering zijn zelfbedieningsfuncties in de app. Een recht dat alleen via een formulier bestaat, is in de praktijk een recht met drempel.
  • Verwijderen loopt door alle gekoppelde gegevens heen in één handeling, zodat er geen wees-records achterblijven die niemand meer opruimt.
  • Beheerdershandelingen op een account worden zonder uitzondering in een auditlog vastgelegd — wie, wat, wanneer, en de toestand vóór en ná.
  • Toegang tot de beheeromgeving vereist tweestapsverificatie. Geen uitzonderingen, ook niet voor de oprichter.
⚖️Juridische dekking

De AVG geeft je een reeks rechten. De vraag is nooit of ze op papier staan, maar of je ze kunt uitoefenen zonder eerst iemand te moeten overtuigen. Daarom zitten inzage, overdraagbaarheid en verwijdering in de app zelf, en niet achter een e-mailadres.

📐Juridisch — technisch
  • AVG art. 15 — inzage. Art. 20 — overdraagbaarheid, in een gestructureerd, machineleesbaar formaat.
  • AVG art. 17 — vergetelheid, uitgevoerd als zelfbediening met cascade over gekoppelde gegevens.
  • AVG art. 16 / 18 / 21 — rectificatie, beperking en bezwaar via de profielinstellingen respectievelijk het contactadres.
  • AVG art. 17(3)(b) en (e) — de enige uitzondering: veiligheidsmeldingen blijven bewaard in gepseudonimiseerde vorm. Het recht op verwijdering zelf wordt daarmee niet geblokkeerd; het account en alle overige gegevens gaan wél weg.
  • AVG art. 5(2) — verantwoordingsplicht: beheerdershandelingen zijn herleidbaar via een auditlog.
🛟

Melden, blokkeren & moderatie

✅ Live

Een melding die nergens heen gaat, is geen melding.

🧸Alsof je vijf bent

Als iemand vervelend doet, kun je dat zeggen. Er kijkt dan echt iemand naar — het verdwijnt niet in een la. En je hoort ook wat ermee is gebeurd. Wil je die persoon gewoon nooit meer zien? Dan kan dat ook, meteen.

📖Gewone samenvatting

Melden en blokkeren zitten daar waar je ze nodig hebt: direct op de kaart in de radar, niet drie schermen verderop. Elke melding komt in een wachtrij die op volgorde van urgentie wordt behandeld. Je krijgt bericht over de uitkomst. Iemand blokkeren werkt onmiddellijk en werkt beide kanten op.

⚙️Hoe we het gebouwd hebben
  • Meldingen komen in een moderatiewachtrij, gesorteerd op het aantal meldingen tegen dezelfde persoon; vanaf drie meldingen wordt er automatisch geëscaleerd.
  • Een account kan omkeerbaar geschorst worden. Die schorsing geldt overal tegelijk: bij het inloggen, bij gewone verzoeken én bij de live verbinding. Er is geen ingang die de schorsing niet kent.
  • Een geschorste gebruiker krijgt een scherm met uitleg in plaats van een app die stilletjes kapot lijkt — en kan daar nog steeds zijn gegevens exporteren en zijn account verwijderen.
  • De melder wordt geïnformeerd via e-mail én een pushbericht. E-mail is het kanaal van vastlegging, omdat dat het enige kanaal is waarvan wij de aflevering daadwerkelijk kunnen waarnemen. Een push die we niet kunnen bevestigen, wordt niet als “geïnformeerd” geboekt.
  • Wat een melder te zien krijgt over de afloop is een categorie, nooit de interne notitie van de moderator — die zou de melder kunnen verraden.
⚖️Juridische dekking

De Digital Services Act verplicht platforms niet alleen om meldingen aan te nemen, maar om er iets mee te doen en de melder over de uitkomst te informeren. Vóór augustus 2026 kwamen meldingen bij ons in een tabel terecht die door niets werd uitgelezen. Dat stond als risico R9 in onze DPIA en is nu opgelost.

📐Juridisch — technisch
  • DSA art. 16 — notice-and-action: ontvangst, triage, besluit. Art. 16(5) — de melder wordt over de uitkomst geïnformeerd. Art. 16(6) — niet-willekeurige, zorgvuldige behandeling.
  • DSA art. 17 — motivering richting de betrokkene bij een maatregel.
  • AVG art. 6(1)(c) — wettelijke verplichting (DSA-verwerkingsplicht) en art. 6(1)(f) — gerechtvaardigd belang (platformveiligheid, verdediging tegen rechtsvorderingen).
  • Bewaartermijn vastgesteld en afgedwongen: 2 jaar voor afgewezen meldingen, 5 jaar wanneer er is opgetreden, opgeruimd door een dagelijks proces. Daarna blijft er bewust alleen een turfje over — welke persoon, en dát er ooit een melding was. Alle inhoud gaat weg: de vrije tekst, de identiteit van de melder, de beschuldiging en de notitie van de moderator.
  • Wat dat turfje kost, eerlijk gezegd: het is een permanent spoor dat aan een persoon hangt. We houden het omdat anders het patroon “één melding per jaar, jarenlang” nooit zou opvallen — precies het geduldige gedrag dat je wilt zien. Die afweging staat zo opgeschreven in ons verwerkingsregister, mét de prijs erbij.
🔞

Leeftijd & minderjarigen

✅ Live · ⚠️ 1 open punt

Een 18+-platform, met nultolerantie en een eerlijk verhaal over wat we wél en niet kunnen controleren.

🧸Alsof je vijf bent

Deze app is alleen voor volwassenen. Bij het aanmelden moet je zeggen dat je 18 of ouder bent, en dat schrijven we op. Als iemand liegt kunnen we dat niet altijd zien — dat vertellen we er eerlijk bij in plaats van te doen alsof.

📖Gewone samenvatting

MySecretCrush is uitsluitend voor volwassenen. Bij registratie bevestig je dat je 18 of ouder bent; die bevestiging wordt nu vastgelegd bij je account. De app hanteert nultolerantie voor materiaal of gedrag met betrekking tot minderjarigen, met een apart kindveiligheidsbeleid en een meldkanaal.

⚙️Hoe we het gebouwd hebben
  • De bevestiging wordt vastgelegd met tijdstip. Een expliciete weigering wordt door de server geweigerd — de controle zit niet alleen in de knop op je scherm.
  • Accounts van vóór deze wijziging, en twee oude registratieroutes, staan op niet vastgelegd. Bewust niet met terugwerkende kracht ingevuld: een verklaring die achteraf is ingevuld, is geen verklaring.
  • Een technische leeftijdscontrole (dus meer dan een eigen verklaring) staat op de roadmap en is nog niet gebouwd. Dat staat er zo in plaats van “leeftijdsverificatie” te noemen wat een vinkje is.
⚖️Juridische dekking

Dit onderdeel bevat een correctie die we niet wegpoetsen. Onze kindveiligheidspagina presenteerde “18+-bevestiging bij aanmelding” als maatregel. Het vinkje bestond wél, maar werd daarna weggegooid: geen enkel account droeg er bewijs van. Een maatregel die je niet kunt aantonen, is geen maatregel. Nu wordt hij vastgelegd.

📐Juridisch — technisch
  • DSA art. 28 — bescherming van minderjarigen op onlineplatforms. Bevestiging in de app plus een controle aan de serverkant.
  • AVG art. 8 — niet van toepassing bij een uitsluitend volwassen dienst, maar wél de reden dat leeftijd als eerste drempel geldt.
  • AVG art. 5(2) — verantwoordingsplicht: hier zat het echte gat. De maatregel werkte in de interface en liet geen enkel spoor na.
  • Restrisico: in de DPIA gewaardeerd als LAAG-MIDDEL. Zie het open punt hieronder.
  • Apart beleid: zie de kindveiligheidsnormen en de veiligheidspagina voor volwassenen.
⚠️Open punt

Leeftijd berust op een eigen verklaring — we leggen hem vast, we controleren hem niet

Wat er open staat — en wat niet. Het vastleggen is opgelost: de bevestiging wordt met tijdstip bewaard, en een expliciete weigering wordt op de server geweigerd. Wat open blijft is de aard van de maatregel zelf. Een verklaring is geen verificatie, en iemand die liegt komt er in de meeste gevallen doorheen.

Waarom dit hier als open punt staat en niet stilzwijgend als “gedaan”. Precies dit ging eerder mis: onze eigen kindveiligheidspagina presenteerde “18+-bevestiging bij aanmelding” als maatregel, terwijl het vinkje daarna werd weggegooid — geen enkel account droeg er bewijs van. Dat is nu hersteld. Maar de verleiding om een vinkje “leeftijdsverificatie” te noemen is precies hoe zoiets ontstaat, en we noemen het daarom wat het is.

Waarom het nog niet dicht is. Elke echte technische controle — identiteitsdocument, creditcard, schatting door een derde partij — vraagt dat we van iedereen véél meer identificerende gegevens verzamelen dan de rest van deze app doet, en levert nog steeds geen zekerheid. Dat is een reële afweging tussen twee dingen die we allebei belangrijk vinden, en hij is nog niet gemaakt. Zolang dat zo is, beschrijven we de maatregel als een verklaring in plaats van hem groter te maken dan hij is.

🔐

Beveiliging van de verwerking

✅ Live

Sloten op de deuren, en een logboek van wie er naar binnen is geweest.

🧸Alsof je vijf bent

Je wachtwoord bewaren we niet als woord, maar als een soort geheimschrift waar je niet meer op terug kunt rekenen. Alles wat heen en weer gaat, zit in een gesloten envelop. En wie bij de knoppen mag, moet twee keer bewijzen dat hij het echt is.

📖Gewone samenvatting

Alles tussen je telefoon en onze servers gaat versleuteld over de lijn. Wachtwoorden worden nooit als leesbare tekst bewaard. Toegang tot beheerfuncties vereist tweestapsverificatie, en elke handeling daar wordt gelogd. Onze eigen servers en onze database staan bewust in dezelfde regio — dat is een beschikbaarheidsmaatregel, geen detail.

⚙️Hoe we het gebouwd hebben
  • Transport uitsluitend over actueel TLS. Opslag versleuteld door het databaseplatform.
  • Wachtwoorden gaan door een bewust trage hashfunctie met salt; ze zijn niet terug te rekenen, ook niet door ons.
  • Rechten zijn gescheiden per rol: een gewone app-gebruiker kan met zijn sleutel eenvoudigweg niet bij andermans gegevens, en de beheeromgeving zit achter een eigen, afgeschermde ingang.
  • Productiegeheimen staan alleen in de omgevingsconfiguratie van de hosting — nooit in de app, nooit in de broncode-repository.
  • Schema-wijzigingen aan de database lopen uitsluitend via een geautomatiseerde procedure die eerst een momentopname maakt. Handmatig sleutelen aan productie is geen toegestane werkwijze.
  • Alle code wordt vóór samenvoegen beoordeeld, inclusief een controle op de bekende OWASP-categorieën.
⚖️Juridische dekking

De AVG schrijft geen specifieke techniek voor, maar wél een beveiligingsniveau dat past bij het risico — en het vermogen om dat aan te tonen. Wij documenteren daarom niet alleen de maatregelen, maar ook de risico’s die we bewust hebben geaccepteerd, met de reden erbij.

📐Juridisch — technisch
  • AVG art. 32 — beveiliging van de verwerking: versleuteling in transport en in rust, toegangsscheiding, tweestapsverificatie voor beheer, auditlog.
  • AVG art. 33 / 34 — meldplicht datalekken: procedure vastgelegd, melding aan de toezichthouder binnen 72 uur, betrokkenen geïnformeerd bij hoog risico.
  • AVG art. 5(2) & art. 24 — verantwoordingsplicht: informatiebeveiligingsbeleid met jaarlijkse herziening en een expliciete lijst van aanvaarde restrisico’s.
  • Aanvaarde restrisico’s, open opgeschreven: geen aparte web application firewall (de hosting levert basisbescherming) en nog geen jaarlijkse externe pentest — die volgt zodra de omzet dat draagt. Kwetsbaarhedenbeheer gebeurt nu via periodieke dependency-audits en handmatige review.
💬

Berichten & versleuteling

✅ Live

Wij kunnen je gesprekken niet lezen. Dat is geen belofte maar een gevolg van waar de sleutel ligt.

🧸Alsof je vijf bent

Als je iets typt, doet je telefoon het in een kluisje op slot vóórdat het weggaat. Wij bewaren alleen het kluisje — en wij hebben geen sleutel. Van jouw sleuteltje ligt er wel een reservekopie bij ons, maar die zit zélf ook in een kluisje dat alleen jij open krijgt. Daardoor ben je je oude berichten niet meer kwijt als je een nieuwe telefoon krijgt.

📖Gewone samenvatting

Berichten worden op je eigen toestel versleuteld en pas op het toestel van de ander weer geopend. Wat op onze servers staat is versleutelde inhoud waar wij niets mee kunnen. Sinds september 2026 bewaren wij daarnaast een versleutelde reservekopie van je sleutel. Die wordt op jouw toestel dichtgezet met een herstelcode die je zelf bewaart, en — zodra de app je wachtwoord voorhanden heeft — daarnaast ook met dat wachtwoord. Wij ontvangen alleen het dichtgezette resultaat. Daarmee overleeft je gespreksgeschiedenis een nieuw toestel of opnieuw inloggen; vóór die datum was ze in dat geval definitief weg. Eén eerlijke uitzondering blijft: als je pushberichten aan hebt staan, ziet de voorvertoning onderweg langs Apple of Google — dat hoort bij hoe pushmeldingen werken en dat vertellen we erbij.

⚙️Hoe we het gebouwd hebben
  • Elk toestel maakt een eigen sleutelpaar. Het geheime deel staat in de beveiligde opslag van het besturingssysteem en verlaat het toestel uitsluitend als versleutelde reservekopie — nooit in een vorm die wij kunnen lezen.
  • Een bericht wordt versleuteld met een sleutel die per bericht wordt gemaakt; die sleutel wordt daarna zó ingepakt dat alleen jullie twee hem kunnen uitpakken.
  • De koppeling tussen bericht en gesprek wordt op de server opnieuw berekend in plaats van van de app overgenomen — zo kan een gemanipuleerde app een bericht niet aan een ander gesprek hangen.
  • Die reservekopie kan twee keer los dichtgezet worden voor dezelfde sleutel: onder een herstelcode die op je eigen toestel wordt gegenereerd en die wij nooit ontvangen, en onder je wachtwoord. De herstelcode-envelop wordt altijd geschreven; de wachtwoord-envelop alleen wanneer de app je wachtwoord voorhanden heeft — na een tweestapsverificatie bijvoorbeeld niet, en dan blijft de herstelcode de weg terug. Het afleiden gebeurt op het toestel met een bewust trage sleutelafleidingsfunctie, op de sterkte die OWASP aanbeveelt. Twee envelopes, omdat een vergeten wachtwoord anders het einde van je geschiedenis zou zijn.
  • Wisselt de ontvanger van sleutel terwijl de afzender nog de vorige kende, dan weigert de server het bericht op te slaan in plaats van iets te bewaren dat niemand ooit nog kan openen. De app versleutelt opnieuw naar de actuele sleutel en verstuurt één keer opnieuw.
  • Heeft de ontvanger nog geen sleutel gepubliceerd (bijvoorbeeld direct na installatie), dan valt het bericht terug op versleuteling aan de serverkant. Onversleuteld opslaan gebeurt in geen van beide gevallen, en als de eigen sleutel niet beschikbaar is, wordt het versturen afgebroken in plaats van uitgeweken.
⚖️Juridische dekking

Versleuteling is hier geen marketingterm maar een gegevensbeschermingsmaatregel: wat wij technisch niet kunnen lezen, kunnen wij ook niet verstrekken, verliezen of misbruiken. Dat verkleint de gevolgen van vrijwel elk denkbaar incident met berichten. De reservekopie van de sleutel verandert daar niets aan: hij komt versleuteld binnen, wordt versleuteld bewaard, en verdwijnt mee wanneer je je account verwijdert.

📐Juridisch — technisch
  • AVG art. 32(1)(a) — versleuteling expliciet genoemd als passende maatregel. Hier toegepast als end-to-end-versleuteling met de bruikbare private sleutel op het toestel.
  • AVG art. 25 — gegevensbescherming door ontwerp: de bruikbare sleutel ligt buiten ons bereik, dus het risico is bij het ontwerp weggenomen in plaats van met beleid afgedekt.
  • AVG art. 34(3)(a) — bij een lek hoeven betrokkenen niet te worden geïnformeerd wanneer de gegevens onbegrijpelijk zijn voor onbevoegden. Dat is precies waar deze maatregel voor zorgt.
  • AVG art. 17 — verwijder je je account, dan verdwijnt ook de versleutelde reservekopie van je sleutel. Dat is op de productiedatabase getest en aangetoond, niet alleen als beleid opgeschreven.
  • Bewust vermeld: een reservekopie die met een wachtwoord te openen is, is nooit sterker dan dat wachtwoord. Daarom bestaat de herstelcode: die wordt willekeurig gegenereerd en is de sterkste van de twee. Raak je je wachtwoord, je herstelcode én elk toestel met de sleutel kwijt, dan is je geschiedenis onleesbaar — ook voor ons. En berichten die al verloren waren voordat deze reservekopie bestond, blijven verloren.
  • Bewust vermeld: de voorvertoning in een pushmelding passeert de push-dienst van Apple of Google. Dat is inherent aan pushmeldingen; wie dat niet wil, kan voorvertoningen uitzetten.
🛡️

Weerbaarheid & continuïteit (NIS2)

✅ Live

We vallen niet onder NIS2. We werken wel volgens NIS2 — en we zeggen precies welk van de twee.

🧸Alsof je vijf bent

Stel dat er iets kapotgaat: dan hebben we van tevoren opgeschreven wat we dan doen, in welke volgorde, en hoe snel het weer moet werken. Een beetje zoals een brandoefening — je wilt niet pas gaan nadenken als het al brandt.

📖Gewone samenvatting

NIS2 is de Europese cyberbeveiligingswet voor bedrijven in kritieke sectoren. Wij vallen daar op grond van onze omvang niet verplicht onder, en we noemen ons dus niet “NIS2-compliant”. Wat we wél doen: de maatregelen die NIS2 vraagt zijn uitgewerkt en vastgelegd — beveiligingsbeleid, incidentafhandeling, herstelplan met concrete hersteltijden, en een risicobeoordeling van elke leverancier.

⚙️Hoe we het gebouwd hebben
  • Hersteldoelen zijn getallen, geen intenties: de app moet binnen 4 uur weer werken, met maximaal 24 uur dataverlies in het slechtste geval, en gebruikers worden binnen 2 uur geïnformeerd bij een bevestigde langere storing.
  • Per storingsscenario ligt een draaiboek klaar: wat je ziet, hoe je het vaststelt, wat je in welke volgorde doet.
  • Elke wijziging aan de database maakt automatisch een momentopname vooraf — herstellen is daardoor een terugrol-actie, geen reconstructie.
  • Rekencapaciteit en gegevensopslag staan in dezelfde regio. Dat is niet alleen snelheid: een eerdere splitsing over twee werelddelen heeft de app een keer volledig platgelegd. Sindsdien is co-locatie een harde regel en zijn alle aanroepen naar de cache voorzien van een tijdslimiet, zodat één trage afhankelijkheid nooit meer de hele app kan meeslepen.
⚖️Juridische dekking

Er is een verschil tussen “de wet geldt niet voor ons” en “we doen er niets aan”. Wij zitten onder de drempel van NIS2, maar de onderliggende maatregelen zijn hoe dan ook goed beleid — en als de drempel ooit verschuift, hoeven we niet vanaf nul te beginnen.

📐Juridisch — technisch
  • NIS2 / Cyberbeveiligingswet — buiten verplicht bereik op grond van omvang (minder dan 50 medewerkers, minder dan €10 mln omzet). Bewust vastgelegd als beoordeling, niet als stilzwijgen.
  • NIS2 art. 21(2)(a) — risicoanalyse en informatiebeveiligingsbeleid: aanwezig, jaarlijkse herziening.
  • NIS2 art. 21(2)(b) — incidentafhandeling: gedocumenteerde procedure, aansluitend op de AVG-meldplicht.
  • NIS2 art. 21(2)(c) — bedrijfscontinuïteit en back-upbeheer: herstelplan met hersteltijd- en herstelpuntdoelstelling.
  • NIS2 art. 21(2)(d) — ketenbeveiliging: leveranciersrisicoregister met een scoremethodiek, zie het volgende onderwerp.
  • AVG art. 32(1)(b) en (c) — doorlopende beschikbaarheid en het vermogen gegevens tijdig te herstellen. Hetzelfde plan dient beide kaders.
🏢

Leveranciers & doorgifte

✅ Live · ⚠️ 1 open punt

Wie raakt jouw gegevens nog meer aan, en op welke grondslag staat dat.

🧸Alsof je vijf bent

Wij bouwen niet alles zelf. Voor opslag, e-mail en betalen huren we hulp in. Van elke helper hebben we opgeschreven wat ze mogen zien, hoe erg het is als zij omvallen, en wat we dan doen.

📖Gewone samenvatting

De app draait op diensten van derden: databasehosting, servers, e-mailbezorging, pushmeldingen, betalingen, abonnementsbeheer en GIF-zoeken. Elke leverancier is beoordeeld op vier punten — hoe gevoelig de gegevens zijn, wat er stukgaat als zij uitvallen, hoe moeilijk vervangen is, en welke certificeringen zij hebben. Er is geen advertentie- of trackingdienst in de app. Dat is geverifieerd, niet aangenomen.

⚙️Hoe we het gebouwd hebben
  • Elke leverancier krijgt een risicoscore uit vier factoren; boven een drempel is het een hoog risico en volgt er een expliciete beheersmaatregel.
  • Voor de kritieke diensten ligt vast wát er precies stukgaat bij uitval, en welk draaiboek er dan geldt.
  • Het ontbreken van tracking is gecontroleerd op de afhankelijkheden van de app zelf, niet afgeleid uit een beleidsstuk. Onze eigen advertenties zijn rotatiegebaseerd en worden niet gericht op geslacht, voorkeur, leeftijd of locatie.
⚖️Juridische dekking

Wanneer een ander bedrijf gegevens namens ons verwerkt, moet daar een verwerkersovereenkomst onder liggen, en bij verwerking buiten de EU een geldig doorgiftemechanisme. Wij houden daar een register van bij, per leverancier, inclusief hun eigen sub-verwerkers. Eén punt daarvan is nog niet af — zie het open punt onderaan dit onderwerp.

📐Juridisch — technisch
  • AVG art. 28 — verwerkersovereenkomsten, bijgehouden in een register per leverancier, inclusief hun certificeringen en hun eigen sub-verwerkers.
  • AVG art. 30 — verwerkingsregister: welke gegevens, welke grondslag, welke ontvangers, welke bewaartermijn, per verwerkingsactiviteit.
  • AVG art. 44–49 — doorgifte naar derde landen op basis van standaardcontractbepalingen voor de Amerikaanse diensten die wij gebruiken.
  • NIS2 art. 21(2)(d) — ketenbeveiliging: hetzelfde register dient hier als onderbouwing.
⚠️Open punt

Niet elke verwerkersovereenkomst is als kopie gearchiveerd

Wat er open staat — en wat niet. Dit gaat niet over de leveranciers zelf. Die zijn beoordeeld, de verwerkersovereenkomsten gelden (ze worden geaccepteerd bij het aangaan van de dienst), en de doorgifte buiten de EU rust op standaardcontractbepalingen. Het open punt is smaller en saaier: van een deel van die overeenkomsten hebben we de getekende of geaccepteerde versie nog niet als kopie in ons eigen dossier liggen.

Waarom dat toch iets is. De verantwoordingsplicht in de AVG gaat niet alleen over het regelen van iets, maar over het kunnen tonen dat het geregeld is. Een overeenkomst die geldt maar die je bij navraag niet kunt overleggen, doet in dat gesprek precies niets voor je.

Waarom het nog niet dicht is, eerlijk gezegd. Het is administratief werk zonder zichtbaar resultaat, en het valt daarmee makkelijk achter functionaliteit. Het is opgeschreven als actiepunt in het register in plaats van weggelaten, juist omdat dit het type taak is dat anders onzichtbaar blijft liggen tot het moment waarop iemand erom vraagt — en dat is precies het slechtste moment om erachter te komen.

💳

Betalen & consumentenrecht

✅ Live

Wij zien je kaartnummer nooit — en je mag binnen 14 dagen van gedachten veranderen.

🧸Alsof je vijf bent

Als je iets koopt, gaat het geld via de winkel van je telefoon. Wij krijgen alleen te horen “betaald”. Je bankpasnummer komt nooit bij ons langs. En als je er spijt van hebt, mag je het binnen twee weken terugdraaien.

📖Gewone samenvatting

Abonnementen lopen via de App Store en Google Play. Je opzeggen doe je daar ook — wij kunnen dat niet voor je vasthouden. Kaartgegevens komen nooit op onze servers: die worden afgehandeld door partijen die daar specifiek voor gecertificeerd zijn. Advertentiebetalingen lopen via een gecertificeerde betaaldienst. De prijs die je ziet is inclusief btw.

⚙️Hoe we het gebouwd hebben
  • Er is geen enkel betaalveld op onze eigen pagina’s. De betaalpagina’s zijn van de betaaldienst zelf.
  • Meldingen van betaalstatus worden op echtheid gecontroleerd voordat er iets mee gebeurt — een vervalst bericht kan geen abonnement activeren.
  • Abonnementsstatus wordt afgeleid uit de winkel, zodat opzeggen in de winkel meteen doorwerkt in de app.
⚖️Juridische dekking

Twee kaders komen hier samen: de beveiligingsstandaard voor kaartbetalingen, en het Nederlandse en Europese consumentenrecht waar de ACM op toeziet. Het tweede is voor jou het belangrijkst: heldere prijzen, geen verborgen verlenging, en een herroepingsrecht.

📐Juridisch — technisch
  • PCI-DSS — SAQ-A, de lichtste categorie, en wij komen daarvoor in aanmerking juist omdat kaartgegevens volledig zijn uitbesteed. In de app loopt betalen via de App Store en Google Play, die zelf gecertificeerd zijn.
  • Richtlijn consumentenrechten 2011/83/EU, art. 9 — 14 dagen herroepingsrecht, ook zichtbaar in onze voorwaarden.
  • Prijstransparantie — de weergegeven prijs is inclusief btw; bij een jaarabonnement wordt zowel het jaarbedrag als het maandequivalent getoond, zodat de vergelijking eerlijk is.
  • AVG art. 6(1)(b) en 6(1)(c) — uitvoering van de overeenkomst, plus de wettelijke bewaarplicht voor de administratie (7 jaar, art. 52 AWR).

Toegankelijkheid

✅ Live

Bruikbaar met een schermlezer, en leesbaar als je slecht ziet.

🧸Alsof je vijf bent

Sommige mensen laten hun telefoon voorlezen wat er op het scherm staat. Daarom heeft bij ons elke knop een naam die hardop voorgelezen kan worden. En we zorgen dat letters genoeg opvallen tegen de achtergrond.

📖Gewone samenvatting

De app is te bedienen met de voorleesfuncties van iOS en Android. Alle knoppen en velden hebben een uitgesproken naam, niet alleen een plaatje. Het kleurcontrast is doorgemeten en waar het te laag was, is het aangepast — dat betrof echte tekst op echte schermen, geen theoretische controle.

⚙️Hoe we het gebouwd hebben
  • Bedieningselementen hebben expliciete labels voor de voorleesfunctie; een icoon zonder tekst is anders letterlijk onbenoembaar.
  • Contrastverhoudingen zijn berekend, niet op het oog beoordeeld — inclusief halftransparante tekst, die eerst tegen de werkelijke achtergrond is doorgerekend.
  • Aanraakvlakken zijn groot genoeg om te raken zonder te mikken, en een raakvlak mag nooit buiten het element vallen waar het bij hoort.
⚖️Juridische dekking

De European Accessibility Act geldt sinds juni 2025 voor digitale consumentendiensten. De praktische invulling daarvan is de WCAG-norm. Wij hebben een auditverslag; dat is intern beschikbaar en op verzoek op te vragen.

📐Juridisch — technisch
  • EAA — richtlijn (EU) 2019/882, van toepassing op digitale consumentendiensten sinds juni 2025.
  • WCAG 2.1 niveau AA — contrastdrempels 4,5:1 voor normale tekst, 3:1 voor grote tekst en voor bedieningselementen.
  • Auditverslag — contrastaudit over de primaire schermen, met de gebruikte rekenmethode erbij, zodat de uitkomst herhaalbaar is.
🤖

AI-verordening — beoordeeld en uitgesloten

➖ Niet van toepassing

Er zit geen AI in deze app. Dat hebben we nagekeken en opgeschreven, in plaats van er niets over te zeggen.

🧸Alsof je vijf bent

Er zit geen slimme robot in de app die iets over jou raadt. Matchen gebeurt omdat jullie het allebei zelf aanklikken — niet omdat een computer denkt dat het wel bij elkaar past.

📖Gewone samenvatting

MySecretCrush gebruikt geen kunstmatige intelligentie. Matchen is een wederzijdse handeling van twee mensen, geen aanbeveling van een systeem. Er is geen ranglijst, geen score en geen profilering. Het nabijheidslabel komt uit een vaste vergelijking die door mensen is opgeschreven.

⚙️Hoe we het gebouwd hebben
  • Vastgesteld door de afhankelijkheden van de app en de server na te lopen: geen taalmodel, geen gezichtsherkenning, geen aanbevelings- of sentimentbibliotheek.
  • Er zijn geen geautomatiseerde besluiten met rechtsgevolg of vergelijkbaar effect. Wat de app doet is vergelijken en tonen, niet beslissen.
⚖️Juridische dekking

Een “niet van toepassing” met onderbouwing is meer waard dan stilzwijgen, zeker als iemand er ooit naar vraagt. Daarom staat de beoordeling opgeschreven, inclusief twee rode lijnen voor het geval de app ooit een andere kant op gaat.

📐Juridisch — technisch
  • AI-verordening (EU) 2024/1689, art. 3(1) en overweging 12 — vaste, door mensen geschreven regels vallen buiten de definitie van een AI-systeem. Geen aanbieder- of gebruiksverantwoordelijke-verplichtingen, geen transparantieplicht uit art. 50, en de kennisplicht uit art. 4 bijt niet.
  • AVG art. 22 — niet van toepassing: geen geautomatiseerde besluitvorming met rechtsgevolgen.
  • Rode lijn 1 — art. 5(1)(g): biometrische categorisering om seksuele gerichtheid af te leiden is verboden, en dat is geen risicoklasse maar een verbod. Elke toekomstige fotoanalyse moet hieraan getoetst worden vóór de eerste regel code.
  • Rode lijn 2 — art. 50: een AI-chatassistent, AI-gegenereerde profielteksten of algoritmische rangschikking van matches zouden onmiddellijk transparantieverplichtingen activeren.
🌍

Wat níet op ons van toepassing is

➖ Niet van toepassing

En waarom we dat toch hebben uitgezocht.

🧸Alsof je vijf bent

Sommige regels gelden alleen in andere landen, of alleen voor hele grote bedrijven. Die gelden nu niet voor ons. Maar we hebben wel opgeschreven wanneer ze dat wél zouden gaan doen, zodat we niet verrast worden.

📖Gewone samenvatting

Niet elke wet die je op een compliancepagina ziet staan, geldt voor elk bedrijf. Wij zetten de kaders die niet op ons van toepassing zijn er toch bij, met de reden en met de gebeurtenis die dat zou veranderen. Een lijst die alleen groene vinkjes toont is minder bruikbaar dan een lijst die laat zien waar de grenzen liggen.

⚙️Hoe we het gebouwd hebben
  • Per kader is één concrete trigger vastgelegd — een gebeurtenis, geen datum — waarop de beoordeling opnieuw moet worden gedaan.
  • De onderliggende analyses liggen klaar, zodat een eventuele uitbreiding een uitvoerklus is en geen onderzoek vanaf nul.
⚖️Juridische dekking

Voor elk van deze kaders geldt: nu niet van toepassing, met een vastgelegde herbeoordeling. Dat is een bewuste keuze, geen omissie.

📐Juridisch — technisch
  • UK GDPR — niet van toepassing: de app wordt niet in het Verenigd Koninkrijk aangeboden. Trigger: een Britse app-storevermelding. Dan volgen ICO-registratie en mogelijk een vertegenwoordiger onder art. 27.
  • CCPA / CPRA (Californië) — niet van toepassing: geen Amerikaanse vermelding, geen Californische gebruikers, en geen van de drie drempels wordt gehaald. Trigger: een Amerikaanse app-storevermelding.
  • SOX — niet van toepassing: dat is Amerikaanse wetgeving voor beursgenoteerde ondernemingen. Wij zijn een Nederlandse besloten vennootschap. Trigger: een gesprek over institutionele investering — dan gaat het om de controles die investeerders vragen, niet om de wet.
  • Functionaris voor gegevensbescherming (AVG art. 37) — nu niet verplicht, op grond van de schaal. Maar heropend: nabijheidsbepaling plus locatie schuiven de app richting “stelselmatige observatie op grote schaal”. De beoordeling wordt opnieuw gedaan bij de volgende herziening of bij 10.000 gebruikers, wat eerder komt.

This page explains, per topic, what we do, how we built it, and which law has something to say about it. Always at five levels, so you choose how deep you go. Everything here is true of the version running right now — not of what is on the roadmap.

How to read this page

  1. 🧸 Like you’re five — the idea in plain words, no jargon.
  2. 📖 Plain summary — what it means for you as a user.
  3. ⚙️ How we built it — the shape of the solution. Deliberately not the exact workings: a description detailed enough to explain how to bypass a control is not transparency, it is a manual.
  4. ⚖️ Legal coverage — which obligation applies here and how we meet it.
  5. 📐 Legal coverage — technical — the specific articles. No implementation details here either.
Why there is amber here — and how to read it. A compliance overview showing only green is not an overview, it is a brochure. Four topics carry an amber label. That does not mean the topic itself is unresolved: those four work and are covered, like the rest. It means there is one bounded point inside that topic which is not yet closed. Each of those has its own block at the foot of the topic — “⚠️ Open item” — setting out exactly what is open, what is not, why it is not closed, and what would close it. The same items appear in our internal documents, in the same words.
📡

Proximity & Bluetooth

✅ Live · ⚠️ 1 open item

Finding someone nearby without knowing where anyone is.

🧸Like you're five

Your phone whispers a made-up word, a bit like a secret password in a playground. Only phones belonging to people who are also playing recognise that word. It never whispers your real name. And the made-up word keeps changing, so nobody can follow you around with it.

📖Plain summary

Discovery runs on Bluetooth, not on a map. Your phone broadcasts an anonymous, constantly changing marker — no name, no account, no location. Both people have to switch Beacon Mode on themselves; if one of you has it off, nothing happens at all. The app only ever says “right here” or “nearby”. Never a number of metres, and never an arrow pointing anywhere.

⚙️How we built it
  • The broadcast marker is anonymous and rotates every few minutes, over a radio address the operating system already randomises. Two sessions cannot be tied together.
  • The scanner unavoidably also receives headphones, cars and laptops. Anything without our marker is discarded inside the receive callback — before a single byte is written anywhere. Enforced in code, not by convention.
  • Signal strength is converted to a label on your handset only. That measurement never leaves your phone, is never stored, and never reaches the other person.
  • Blocks are enforced on the server, before a marker is ever resolved to a profile. Someone who blocked you simply does not exist in your radar.
  • A session expires, and extending it is capped by a hard per-session ceiling the server enforces. The radio is foreground-only — a phone in your pocket broadcasts nothing.
⚖️Legal coverage

This is the highest-rated risk in our own assessment, and we write it down that way. The Data Protection Impact Assessment records it as risk R8: someone can determine that a specific, named, photographed person is here right now. That risk cannot be eliminated — it is the feature — but it is bounded by controls we classified as required rather than optional.

📐Legal coverage — technical
  • GDPR Art. 35 — DPIA completed, version 2.2 (August 2026). BLE proximity falls under the Dutch DPA trigger “innovative technology with significant privacy risks”.
  • GDPR Art. 5(1)(c) — minimisation. Metre-level readouts were built, measured, and thrown away: the measurements could not support a number (18 dB of spread at a fixed one metre). Two coarse labels is what the radio can actually defend.
  • GDPR Art. 25 — data protection by design: symmetric opt-in, rotating markers, foreground-only, server-side blocks.
  • Residual risk R10, open and visible: a passive scanner can tell that someone is running this app. See the open item below.
⚠️Open item

The iOS advertisement still carries a readable app name

What is open — and what is not. Proximity discovery itself works and is covered. The open item is narrow: a passive scanner nearby can tell from the advertisement that someone is running this app. Not who, not where, no profile — but still an inference about someone’s private life reaching a third party who consented to nothing.

Why it is not closed yet. The receiving side already accepts the anonymous form and is live. The last step is in native code, which cannot travel in an over-the-air update — it needs a full app-store build.

Why that order is deliberate. Had the broadcasting side changed first, every already-installed phone would have gone blind to new devices: discovery would quietly stop working for anyone who had not yet updated. So the receiving side had to land and propagate first. That has happened, and was measured on a real handset before we went further.

And the honest floor. Even once that build ships, this reduces the risk, it does not close it. The advertisement still carries a fixed technical marker that discovery needs in order to work at all — you cannot both hide it and use it. Genuinely closing this needs a marker that rotates, and that is not planned. This is true of every Bluetooth app; we simply do not pretend otherwise.

📍

Location & the Circle of Love

✅ Live

One blurred dot, one hour, and then genuinely gone.

🧸Like you're five

When you join in, we put one fuzzy dot on a map — like a fingertip on an atlas, not a pin. After about an hour the map wipes itself clean. The dot is then actually gone, not hidden.

📖Plain summary

When you switch Beacon Mode on we capture one location, so the map can show roughly where things are happening. Not continuously, never in the background. What other people see is deliberately imprecise, and your dot only moves once you have walked a fair distance. After 60 minutes the coordinate is deleted — not hidden, deleted.

⚙️How we built it
  • Captured at the moment you start the beacon yourself. There is no background process tracking you.
  • What others see is blurred to roughly a dozen metres, and the position is only rewritten after substantial movement — so a dot does not quietly drift along with you.
  • Other users receive a coarse distance band, never raw coordinates.
  • A background process clears anything outside the hour on a fixed cadence, and empties every field the coordinate lives in — including the precise variant the map feature itself never reads. A live session is never purged mid-way.
⚖️Legal coverage

Our website already said the location is deleted after a maximum of 60 minutes. On review, those 60 minutes turned out to be a display filter only: the map stopped showing the dot, but the coordinate stayed. We made the promise true rather than softening the text. That is the direction we take whenever published copy and running code disagree.

📐Legal coverage — technical
  • GDPR Art. 5(1)(e) — storage limitation. The retention period is now enforced by a purge process, not merely asserted in policy.
  • GDPR Art. 5(1)(c) — minimisation: one snapshot per activation, blurred before sharing, distance band instead of coordinates.
  • DPIA item L1 — CLOSED before publication. The DPIA states explicitly that the first attempt at the fix was itself incomplete: one storage field holding the same coordinate at full precision was missed, and was then included. A DPIA that records only successful attempts is worth nothing.
  • DPIA risk R11 — moved from “certain” to “low”.
✍️

Consent

✅ Live · ⚠️ 1 open item

Two separate ticks, because one tick for everything is not a choice.

🧸Like you're five

We ask permission twice, at two different moments. Not one big tick with ten things hiding inside it. And if you later say “actually, no” — that is allowed, with one tap, and it stops straight away.

📖Plain summary

At registration there is a separate tick, distinct from the privacy policy and the terms, for the sensitive data a dating app inherently involves. It is off by default. The first time you use Beacon Mode there is a second, separate consent for Bluetooth presence and that one location. The second is not a condition of using the app: your account works fully without it. You withdraw it in Settings, with one confirmed tap.

⚙️How we built it
  • The two consents are recorded independently, each with a timestamp and with the version of the wording you agreed to — a yes/no flag cannot show what you actually said yes to.
  • The refusal is enforced on the server, not in the app. Without valid second consent, starting a beacon is refused even if someone bypasses the app and talks to our servers directly.
  • Withdrawing ends a live beacon immediately and clears the associated map data at once — not when the session happens to expire.
  • This is entirely separate from your phone’s Bluetooth permission. That is an operating-system access grant, not a GDPR consent, and we do not treat it as one.
⚖️Legal coverage

What is settled: consent buried inside “I accept the terms” is not explicit consent. That was the situation here, and it has been cleared up — hence two separate ticks at two separate moments. What is not settled is whether that design is legally sufficient; that is our most significant open item and it is set out in full at the foot of this topic.

📐Legal coverage — technical
  • GDPR Art. 9(2)(a) — explicit consent for special categories. See the open item below (C1).
  • GDPR Art. 7(2) — a consent request presented with other matters must be clearly distinguishable. Hence its own tick in its own box, off by default.
  • GDPR Art. 7(1) — demonstrability. This is why we record the version of the wording, not just a flag.
  • GDPR Art. 7(3) — withdrawal must be as easy as giving. One tap, effective immediately.
  • GDPR Art. 7(4) / Recital 43 — “freely given”. That is precisely the open question for the first tick. Keeping the second consent separate means the question applies only to processing inseparable from a dating service, and not to location.
  • Existing accounts and two legacy registration routes read not recorded. Deliberately not back-filled: a retrofitted consent is evidence that collapses the moment anyone asks where it came from.
⚠️Open item

Whether this consent design is legally sufficient has not been reviewed

What is open — and what is not. The mechanism is built and live: two separate consents, off by default, each recorded with a timestamp and the version of the wording, and the refusal enforced on the server. What is not settled is whether that is legally enough. That is a different kind of question, and not ours to answer.

Why it stays open. Building something is not the same as it being sufficient. We could have closed this item the moment the code worked — that would have been comfortable and untrue. Two things are concretely undecided: (1) is the consent taken at registration “freely given” when you cannot have an account without it? Our argument is that a dating service does not exist without that processing, so it is not a condition imposed on unnecessary processing. That argument is defensible and it is not settled. And (2) is the wording specific and intelligible enough to be explicit consent, rather than merely well-informed agreement?

What building it did change. Not the answer — the question. It moved from “design us a consent mechanism” to “is this two-tier split sufficient?”, which is narrower, cheaper and answerable. The second consent (Bluetooth and location) was deliberately kept out of registration so that the freely-given question applies only to processing inseparable from the service, and never to location.

What closes it. A lawyer’s opinion. Not more engineering — that part is done.

💪

Your rights over your data

✅ Live

See it, take it with you, delete it — from the app, without having to email anyone.

🧸Like you're five

Everything we have about you is really yours. You may look at it. You may take a copy of it somewhere else. And you may say: throw it away. Then we actually throw it away.

📖Plain summary

You can download a copy of your data from inside the app, in a format other software can read, and you can delete your own account — with no member of staff involved and no helpdesk queue. Deleting means deleting: your profile, your messages, your crush history. What remains is a small, deliberately bare trace where the law requires it — see the reporting section below.

⚙️How we built it
  • Export and deletion are self-service in the app. A right that only exists via a form is, in practice, a right with a barrier in front of it.
  • Deletion runs through all linked data in a single operation, so no orphaned records are left behind that nothing ever cleans up.
  • Administrator actions on an account are logged to an audit trail without exception — who, what, when, and the state before and after.
  • Access to the admin environment requires two-factor authentication. No exceptions, including for the founder.
⚖️Legal coverage

The GDPR gives you a set of rights. The question is never whether they exist on paper, but whether you can exercise them without first having to convince somebody. That is why access, portability and erasure live inside the app rather than behind an email address.

📐Legal coverage — technical
  • GDPR Art. 15 — access. Art. 20 — portability, in a structured, machine-readable format.
  • GDPR Art. 17 — erasure, implemented as self-service with a cascade across linked data.
  • GDPR Art. 16 / 18 / 21 — rectification, restriction and objection, via profile settings and the contact address respectively.
  • GDPR Art. 17(3)(b) and (e) — the single exception: safety reports are retained in pseudonymised form. The erasure right itself is not blocked; the account and all other data do go.
  • GDPR Art. 5(2) — accountability: administrator actions are traceable through an audit log.
🛟

Reporting, blocking & moderation

✅ Live

A report that goes nowhere is not a report.

🧸Like you're five

If somebody is being nasty, you can say so. A real person then looks at it — it does not vanish into a drawer. And you get told what happened. Just never want to see that person again? You can do that too, straight away.

📖Plain summary

Reporting and blocking sit where you need them: right on the card in the radar, not three screens away. Every report enters a queue worked in order of urgency. You are told the outcome. Blocking someone takes effect immediately and works in both directions.

⚙️How we built it
  • Reports enter a moderation queue ordered by how many reports exist against the same person; from three onwards it escalates automatically.
  • An account can be reversibly suspended. The suspension applies everywhere at once: at login, on ordinary requests, and on the live connection. There is no entrance that does not know about it.
  • A suspended user gets a screen that explains it rather than an app that quietly appears broken — and can still export their data and delete their account from there.
  • The reporter is notified by email and by push. Email is the channel of record, because it is the only one whose delivery we can actually observe. A push we cannot confirm is not booked as “notified”.
  • What a reporter sees about the outcome is a category, never the moderator’s internal note — that note could identify the reporter.
⚖️Legal coverage

The Digital Services Act obliges platforms not merely to accept reports, but to act on them and tell the reporter what happened. Before August 2026, reports landed in a table nothing read. That was risk R9 in our DPIA, and it is now closed.

📐Legal coverage — technical
  • DSA Art. 16 — notice-and-action: receipt, triage, decision. Art. 16(5) — the reporter is notified of the outcome. Art. 16(6) — timely, diligent, non-arbitrary handling.
  • DSA Art. 17 — statement of reasons to the affected person when a measure is applied.
  • GDPR Art. 6(1)(c) — legal obligation (DSA handling duty) and Art. 6(1)(f) — legitimate interests (platform safety, defence of legal claims).
  • Retention set and enforced: 2 years for dismissed reports, 5 years where action was taken, swept daily. After that, deliberately, only a tally mark survives — which person, and that a report once existed. Everything else goes: the free text, the reporter’s identity, the allegation, and the moderator’s note.
  • What that tally mark costs, stated plainly: it is a permanent trace attached to a person. We keep it because otherwise the pattern “one report a year, for years” would never surface — precisely the patient behaviour you want to catch. That trade-off is written into our processing register with its price attached.
🔞

Age & minors

✅ Live · ⚠️ 1 open item

An 18+ platform, with zero tolerance and an honest account of what we can and cannot verify.

🧸Like you're five

This app is for grown-ups only. When you sign up you have to say you are 18 or older, and we write that down. If someone lies we cannot always tell — and we say so, instead of pretending otherwise.

📖Plain summary

MySecretCrush is for adults only. At registration you confirm you are 18 or over, and that confirmation is now recorded against your account. The app operates zero tolerance for material or conduct involving minors, with a separate child-safety policy and a reporting channel.

⚙️How we built it
  • The confirmation is recorded with a timestamp. An explicit refusal is rejected by the server — the check does not live only in the button on your screen.
  • Accounts predating this change, and two legacy registration routes, read not recorded. Deliberately not back-filled: a declaration filled in after the fact is not a declaration.
  • A technical age check (i.e. more than a self-declaration) is on the roadmap and is not built. We say that, rather than calling a checkbox “age verification”.
⚖️Legal coverage

This section contains a correction we are not papering over. Our child-safety page presented “age confirmation (18+) at sign-up” as a mitigation. The tick did exist, but it was then discarded: no account carried any evidence of it. A mitigation you cannot demonstrate is not a mitigation. It is now recorded.

📐Legal coverage — technical
  • DSA Art. 28 — protection of minors on online platforms. In-app confirmation plus a server-side check.
  • GDPR Art. 8 — not applicable to an adults-only service, but it is why age is the first gate.
  • GDPR Art. 5(2) — accountability: this is where the real gap was. The control worked in the interface and left no trace whatsoever.
  • Residual risk: rated LOW-MEDIUM in the DPIA. See the open item below.
  • Separate policies: see the child safety standards and the adult safety page.
⚠️Open item

Age rests on self-declaration — we record it, we do not verify it

What is open — and what is not. The recording is fixed: the confirmation is stored with a timestamp, and an explicit refusal is rejected by the server. What remains open is the nature of the control itself. A declaration is not verification, and someone who lies will in most cases get through.

Why this is listed as open rather than quietly counted as done. This is precisely what went wrong before: our own child-safety page presented “age confirmation (18+) at sign-up” as a mitigation while the tick was being discarded — no account carried any evidence of it. That is now fixed. But the temptation to call a checkbox “age verification” is exactly how that happens, so we call it what it is.

Why it is not closed. Every real technical check — identity document, credit card, third-party estimation — requires collecting far more identifying data from everyone than the rest of this app collects, and still returns no certainty. That is a genuine trade between two things we both care about, and it has not been decided. Until it is, we describe the control as a declaration rather than inflating it.

🔐

Security of processing

✅ Live

Locks on the doors, and a logbook of who went through them.

🧸Like you're five

We do not keep your password as a word, but as a kind of secret code you cannot work backwards from. Everything travelling back and forth goes in a sealed envelope. And anyone allowed near the controls has to prove twice that they really are who they say.

📖Plain summary

Everything between your phone and our servers travels encrypted. Passwords are never stored as readable text. Access to admin functions requires two-factor authentication, and every action there is logged. Our servers and our database sit deliberately in the same region — that is an availability control, not a detail.

⚙️How we built it
  • Transport over current TLS only. Storage encrypted by the database platform.
  • Passwords go through a deliberately slow, salted hash; they cannot be worked backwards, including by us.
  • Privileges are separated by role: an ordinary app user simply cannot reach anyone else’s data with their credential, and the admin environment sits behind its own, separately guarded entrance.
  • Production secrets live only in the hosting platform’s environment configuration — never in the app, never in the source repository.
  • Database schema changes run exclusively through an automated procedure that takes a snapshot first. Hand-editing production is not a permitted way of working.
  • All code is reviewed before merge, including a pass over the known OWASP categories.
⚖️Legal coverage

The GDPR does not prescribe a specific technology, but it does require a level of security appropriate to the risk — and the ability to demonstrate it. So we document not only the controls, but also the risks we have knowingly accepted, with the reasoning attached.

📐Legal coverage — technical
  • GDPR Art. 32 — security of processing: encryption in transit and at rest, privilege separation, two-factor authentication for admin, audit logging.
  • GDPR Art. 33 / 34 — breach notification: procedure documented, supervisory authority within 72 hours, data subjects informed where risk is high.
  • GDPR Art. 5(2) & Art. 24 — accountability: an information security policy with annual review and an explicit list of accepted residual risks.
  • Accepted residual risks, written down openly: no separate web application firewall (the hosting platform provides baseline protection) and no annual external penetration test yet — that follows once revenue supports it. Vulnerability management currently runs on periodic dependency audits and manual review.
💬

Messages & encryption

✅ Live

We cannot read your conversations. That is not a promise; it is a consequence of where the key lives.

🧸Like you're five

When you type something, your phone locks it in a little box before it leaves. We only ever keep the box — and we do not have a key. There is a spare copy of your key with us, but it sits in a locked box of its own that only you can open. That is why your old messages no longer disappear when you get a new phone.

📖Plain summary

Messages are encrypted on your own device and only opened again on the other person’s device. What sits on our servers is encrypted content we can do nothing with. Since September 2026 we also keep an encrypted backup of your key. It is sealed on your device under a recovery code you keep yourself and, once the app has your password to hand, under that password as well. All we ever receive is the sealed result. That is what lets your conversation history survive a new phone or a fresh login; before that date it was gone for good in those cases. One honest exception remains: if you have push notifications on, the preview passes Apple or Google in transit — that is how push works, and we say so.

⚙️How we built it
  • Each device generates its own key pair. The secret half lives in the operating system’s secure storage and leaves the device only as an encrypted backup — never in a form we can read.
  • A message is encrypted with a key created for that message; that key is then wrapped so that only the two of you can unwrap it.
  • The binding between message and conversation is recomputed on the server rather than taken from the app — so a tampered client cannot attach a message to a different conversation.
  • That backup can be sealed twice, separately, for the same key: under a recovery code generated on your own device that we never receive, and under your password. The recovery-code envelope is always written; the password one only when the app has your password to hand — not after a two-factor login, say, where the recovery code stays the way back. The derivation runs on the device using a deliberately slow key-derivation function at the strength OWASP recommends. Two envelopes, because otherwise a forgotten password would be the end of your history.
  • If the recipient changes key while the sender still knows the previous one, the server refuses to store the message rather than keeping something nobody could ever open. The app re-encrypts to the current key and sends once more.
  • If the recipient has not published a key yet (right after install, say), the message falls back to server-side encryption. Storing it unencrypted happens in neither case, and if your own key is unavailable the send is aborted rather than downgraded.
⚖️Legal coverage

Encryption here is not a marketing term but a data-protection control: what we cannot technically read, we also cannot disclose, lose or misuse. That shrinks the consequences of almost any conceivable incident involving messages. The key backup does not change that: it arrives encrypted, is stored encrypted, and is deleted when you delete your account.

📐Legal coverage — technical
  • GDPR Art. 32(1)(a) — encryption named explicitly as an appropriate measure. Applied here as end-to-end encryption with the usable private key held on the device.
  • GDPR Art. 25 — data protection by design: the usable key sits outside our reach, so the risk is designed out rather than papered over with policy.
  • GDPR Art. 34(3)(a) — data subjects need not be notified of a breach where the data is unintelligible to unauthorised parties. That is precisely what this control achieves.
  • GDPR Art. 17 — deleting your account also deletes the encrypted backup of your key. That was tested and demonstrated against the production database, not merely written down as policy.
  • Stated deliberately: a backup a password can open is never stronger than that password. That is why the recovery code exists: it is randomly generated, and it is the stronger of the two. Lose your password, your recovery code and every device holding the key, and your history is unreadable — to us as well. And messages already lost before this backup existed stay lost.
  • Stated deliberately: the preview in a push notification passes through Apple’s or Google’s push service. That is inherent to push notifications; anyone who prefers otherwise can switch previews off.
🛡️

Resilience & continuity (NIS2)

✅ Live

We are not in scope for NIS2. We do work to NIS2 — and we say which of the two.

🧸Like you're five

Suppose something breaks: we have already written down what we do, in what order, and how quickly it has to work again. A bit like a fire drill — you do not want to start thinking once it is already burning.

📖Plain summary

NIS2 is the EU cybersecurity law for organisations in critical sectors. By size we are not in its mandatory scope, so we do not call ourselves “NIS2 compliant”. What we do is implement and document the measures it asks for — security policy, incident handling, a recovery plan with concrete recovery times, and a risk assessment of every supplier.

⚙️How we built it
  • Recovery targets are numbers, not intentions: the app must be working again within 4 hours, with at most 24 hours of data loss in the worst case, and users informed within 2 hours of a confirmed extended outage.
  • Each failure scenario has a runbook: what you see, how to confirm it, what you do and in what order.
  • Every database change automatically takes a snapshot beforehand — so recovery is a rollback, not a reconstruction.
  • Compute and data sit in the same region. That is not only speed: a past split across two continents once took the app down entirely. Co-location has been a hard rule since, and every cache call carries a timeout so a single slow dependency can never drag the whole app down again.
⚖️Legal coverage

There is a difference between “the law does not apply to us” and “we do nothing about it”. We sit below the NIS2 threshold, but the underlying measures are good practice regardless — and if the threshold ever moves, we are not starting from zero.

📐Legal coverage — technical
  • NIS2 / Dutch Cybersecurity Act — outside mandatory scope on size grounds (fewer than 50 staff, under €10M turnover). Recorded deliberately as a determination rather than left as silence.
  • NIS2 Art. 21(2)(a) — risk analysis and information security policy: in place, reviewed annually.
  • NIS2 Art. 21(2)(b) — incident handling: documented procedure, dovetailed with the GDPR notification duty.
  • NIS2 Art. 21(2)(c) — business continuity and backup management: recovery plan with recovery-time and recovery-point objectives.
  • NIS2 Art. 21(2)(d) — supply chain security: supplier risk register with a scoring method, see the next topic.
  • GDPR Art. 32(1)(b) and (c) — ongoing availability and the ability to restore data in a timely manner. The same plan serves both frameworks.
🏢

Suppliers & international transfers

✅ Live · ⚠️ 1 open item

Who else touches your data, and on what basis.

🧸Like you're five

We do not build everything ourselves. For storage, email and payments we hire help. For every helper we have written down what they are allowed to see, how bad it is if they fall over, and what we do then.

📖Plain summary

The app runs on third-party services: database hosting, servers, email delivery, push notifications, payments, subscription management and GIF search. Every supplier is assessed on four points — how sensitive the data is, what breaks if they go down, how hard they are to replace, and what certifications they hold. There is no advertising or tracking service in the app. That is verified, not assumed.

⚙️How we built it
  • Every supplier gets a risk score from four factors; above a threshold it counts as high risk and an explicit control follows.
  • For the critical services it is recorded exactly what breaks on an outage, and which runbook then applies.
  • The absence of tracking was checked against the app’s own dependencies, not inferred from a policy document. Our own ads are rotation-based and are not targeted on gender, preference, age or location.
⚖️Legal coverage

Where another company processes data on our behalf there must be a processor agreement underneath it, and for processing outside the EU a valid transfer mechanism. We keep a register of these, per supplier, including their own sub-processors. One part of that is not finished — see the open item at the foot of this topic.

📐Legal coverage — technical
  • GDPR Art. 28 — processor agreements, tracked in a per-supplier register including their certifications and their own sub-processors.
  • GDPR Art. 30 — records of processing: which data, which basis, which recipients, which retention, per processing activity.
  • GDPR Art. 44–49 — third-country transfers on the basis of Standard Contractual Clauses for the US services we use.
  • NIS2 Art. 21(2)(d) — supply chain security: the same register serves as the evidence here.
⚠️Open item

Not every processor agreement is archived as a copy

What is open — and what is not. This is not about the suppliers themselves. They are assessed, the processor agreements are in force (accepted on taking the service), and transfers outside the EU rest on Standard Contractual Clauses. The open item is narrower and duller: for some of those agreements we do not yet hold the signed or accepted version as a copy in our own file.

Why that still matters. Accountability under the GDPR is not only about having arranged something, but about being able to show that you did. An agreement that is in force but cannot be produced on request does nothing for you in that conversation.

Why it is not closed, stated plainly. It is administrative work with no visible output, which makes it easy to let slip behind features. It is written into the register as an action point rather than left out precisely because this is the kind of task that otherwise sits invisible until the moment somebody asks for it — which is the worst possible moment to discover it.

💳

Payments & consumer rights

✅ Live

We never see your card number — and you have 14 days to change your mind.

🧸Like you're five

When you buy something, the money goes through your phone’s shop. We only ever get told “paid”. Your card number never comes anywhere near us. And if you regret it, you can undo it within two weeks.

📖Plain summary

Subscriptions run through the App Store and Google Play. You cancel there too — we cannot hold on to you. Card details never reach our servers: they are handled by parties certified specifically for that. Advertising payments run through a certified payment provider. The price you see includes VAT.

⚙️How we built it
  • There is no payment field at all on our own pages. The payment pages belong to the payment provider.
  • Payment status notifications are verified as authentic before anything acts on them — a forged message cannot activate a subscription.
  • Subscription state is derived from the store, so cancelling in the store takes effect in the app immediately.
⚖️Legal coverage

Two frameworks meet here: the security standard for card payments, and Dutch and European consumer law supervised by the ACM. The second matters most to you: clear pricing, no hidden renewal, and a right of withdrawal.

📐Legal coverage — technical
  • PCI-DSS — SAQ-A, the lightest category, and we qualify for it precisely because card data is fully outsourced. In-app purchases run through the App Store and Google Play, which are themselves certified.
  • Consumer Rights Directive 2011/83/EU, Art. 9 — 14-day right of withdrawal, also stated in our terms.
  • Price transparency — the displayed price includes VAT; on an annual plan both the yearly amount and the monthly equivalent are shown, so the comparison is honest.
  • GDPR Art. 6(1)(b) and 6(1)(c) — performance of the contract, plus the statutory retention duty for financial records (7 years, Art. 52 Dutch AWR).

Accessibility

✅ Live

Usable with a screen reader, and readable if your eyesight is poor.

🧸Like you're five

Some people have their phone read out what is on the screen. So every button here has a name that can be read aloud. And we make sure letters stand out enough against the background.

📖Plain summary

The app can be operated with the screen readers built into iOS and Android. Every button and field has a spoken name, not just a picture. Colour contrast has been measured and adjusted where it was too low — on real text on real screens, not as a theoretical check.

⚙️How we built it
  • Controls carry explicit labels for the screen reader; an icon without text is otherwise literally unnameable.
  • Contrast ratios are calculated, not eyeballed — including semi-transparent text, computed against its actual background first.
  • Touch targets are large enough to hit without aiming, and a touch target never extends beyond the element it belongs to.
⚖️Legal coverage

The European Accessibility Act has applied to digital consumer services since June 2025. Its practical expression is the WCAG standard. We hold an audit report; it is available internally and on request.

📐Legal coverage — technical
  • EAA — Directive (EU) 2019/882, applicable to digital consumer services since June 2025.
  • WCAG 2.1 Level AA — contrast thresholds of 4.5:1 for normal text, 3:1 for large text and for user interface components.
  • Audit report — contrast audit across the primary screens, with the calculation method included so the result is reproducible.
🤖

AI Act — assessed and excluded

➖ Not applicable

There is no AI in this app. We checked and wrote it down, rather than saying nothing about it.

🧸Like you're five

There is no clever robot inside the app guessing things about you. Matching happens because you both tapped it yourselves — not because a computer thought you would go well together.

📖Plain summary

MySecretCrush uses no artificial intelligence. Matching is a mutual act by two people, not a system recommendation. There is no ranking, no scoring and no profiling. The proximity label comes from a fixed comparison written by people.

⚙️How we built it
  • Established by auditing the app’s and the server’s dependencies: no language model, no face recognition, no recommendation or sentiment library.
  • There are no automated decisions with legal or similarly significant effect. What the app does is compare and display, not decide.
⚖️Legal coverage

A reasoned “not applicable” is worth more than silence, particularly if anyone ever asks. So the determination is written down, including two red lines in case the product ever moves.

📐Legal coverage — technical
  • AI Act (EU) 2024/1689, Art. 3(1) and Recital 12 — fixed, human-written rules fall outside the definition of an AI system. No provider or deployer obligations, no Art. 50 transparency duty, and the Art. 4 AI-literacy duty does not bite.
  • GDPR Art. 22 — not applicable: no automated decision-making with legal effects.
  • Red line 1 — Art. 5(1)(g): biometric categorisation to infer sexual orientation is prohibited — a prohibition, not a risk tier. Any future photo-analysis feature must be checked against this before a line of code is written.
  • Red line 2 — Art. 50: an AI chat assistant, AI-generated profile content, or algorithmic match ranking would trigger transparency duties immediately.
🌍

What does not apply to us

➖ Not applicable

And why we worked it out anyway.

🧸Like you're five

Some rules only apply in other countries, or only to very big companies. Those do not apply to us right now. But we have written down when they would start to, so we do not get caught out.

📖Plain summary

Not every law you see on a compliance page applies to every company. We list the frameworks that do not apply to us anyway, with the reason and with the event that would change it. A list showing only green ticks is less useful than one that shows where the boundaries are.

⚙️How we built it
  • For each framework, one concrete trigger is recorded — an event, not a date — on which the assessment must be redone.
  • The underlying analyses are already written, so an expansion becomes an execution task rather than research from scratch.
⚖️Legal coverage

For each of these: not applicable now, with a recorded re-assessment. That is a deliberate determination, not an omission.

📐Legal coverage — technical
  • UK GDPR — not applicable: the app is not offered in the United Kingdom. Trigger: a UK app-store listing. ICO registration and possibly an Art. 27 representative would follow.
  • CCPA / CPRA (California) — not applicable: no US listing, no California users, and none of the three thresholds is met. Trigger: a US app-store listing.
  • SOX — not applicable: that is US law for listed companies. We are a Dutch private limited company. Trigger: an institutional investment discussion — at which point it is about the controls investors ask for, not about the statute.
  • Data Protection Officer (GDPR Art. 37) — not mandatory at present, on scale grounds. But reopened: proximity ranging plus location move the app toward “regular and systematic monitoring on a large scale”. The determination is revisited at the next review or at 10,000 users, whichever comes first.