Berichtprivacy
Kan Collogue mijn privéberichten lezen?
Waar de huidige browsercode wel en niet bij kan wanneer die een Collogue-bericht versleutelt.
Gepubliceerd: 14 januari 2026
Grenzen van de huidige implementatie
Huidige Collogue-links bevatten de versleutelde inhoud in de URL. De browser gebruikt de Web Crypto API: PBKDF2-SHA-256 met 310.000 iteraties leidt uit het afzonderlijk ingevoerde wachtwoord een 256-bits AES-GCM-sleutel af, met een willekeurige salt van 16 bytes en een IV van 12 bytes. De huidige client doet geen verzoek naar een applicatie-API om berichten te maken, op te halen of op te slaan.
Het wachtwoord is niet in de link opgenomen. De implementatie biedt geen eenmalige weergave, verwijdering aan de serverkant of vervaltimer. Behandel de volledige link als gevoelig en deel het wachtwoord via een apart kanaal.
Verdere context
“Kan de dienst mijn bericht lezen?” klinkt als een ja-of-neevraag. Technisch zijn het meerdere vragen die één jas dragen.
Een goed antwoord maakt die vragen afzonderlijk zichtbaar in plaats van ze achter één bijvoeglijk naamwoord te verbergen.
De leesbare tekst heet platte tekst. Het versleutelde resultaat heet cijfertekst. Goede versleuteling hoort cijfertekst onbruikbaar te maken zonder de vereiste sleutel.
De volgende vraag is waar de sleutel vandaan komt en wie die kan verkrijgen.
Als Collogue een ander mechanisme gebruikt, moet de openbare uitleg dat mechanisme beschrijven en niet het verhaal over een URL-fragment van een ander product overnemen.
Stel dat een website berichten in de browser versleutelt. U controleert vandaag het netwerkverzoek en bevestigt dat er geen platte tekst wordt verstuurd. Goed.
Dat maakt versleuteling in de browser niet zinloos. Het laat zien wat deze bescherming wel betekent.
Een openbaar controleerbare repository kan de transparantie vergroten. Ze bewijst niet dat de uitgerolde build exact overeenkomt met de repository als er geen controleerbaar releaseproces is. Een onafhankelijke audit kan het vertrouwen vergroten. Ze maakt een veranderende webapplicatie echter niet tot een wiskundig bewijs.
Beveiliging blijft een technische bewering die door bewijs wordt ondersteund.
Deze beschermingen zijn juist betekenisvol omdat ze beperkt zijn.
- het apparaat van de afzender is gecompromitteerd;
- het apparaat van de ontvanger is gecompromitteerd;
- een kwaadaardige browserextensie leest de pagina;
- de afzender geeft de link aan de verkeerde persoon;
- iemand stuurt de volledige link door voordat die wordt geopend;
- de ontvanger kopieert of neemt het bericht op;
- de webapplicatie die aan de browser wordt geleverd is kwaadaardig;
- het geheim zelf is zwak, hergebruikt of heeft te veel rechten.
Versleuteling beperkt de toegang tot informatie onder de genoemde aannames. Ze heft menselijk gedrag niet op.
Gebruik die term alleen als de architectuur, sleutelverwerking, uitgerolde code en het operationele model de claim rechtvaardigen. Alleen een in de browser versleutelde payload is niet genoeg om elke betekenis van “zero knowledge” vast te leggen.
Het antwoord hangt ervan af of records platte tekst, cijfertekst, sleutels of genoeg gegevens om sleutels af te leiden bevatten. Publiceer het gecontroleerde schema en sleutelpad in plaats van een slogan.
Ja. Een ontvanger moet uiteindelijk platte tekst reconstrueren om die te zien. Op dat moment maken de browseromgeving en het apparaat deel uit van het vertrouwensmodel.
Maak een privélink van Collogue wanneer u een wachtwoord, token, herstelcode of andere korte gevoelige waarde moet versturen.