Signal-oprichter brengt opensource AI-bot Confer uit met end-to-endencryptie

De oorspronkelijke maker en oprichter van Signal, hacker Moxie Marlinspike, komt met een opensource AI-assistent die net als chatapp Signal gericht is op privacy. De opzet van AI-bot Confer is dat data niet leesbaar is voor de aanbieder zelf en ook niet voor externe partijen.

Ingenieur Moxie Marlinspike belooft met Confer 'echt privé AI', die gebruikers een eigen ruimte geeft waar ze kunnen denken. Net zoals bij chatapp Signal is de communicatie end-to-end versleuteld, waardoor de aanbieder zelf niet kan meelezen. Dat geldt daarmee ook voor verzoeken van derde partijen, zoals autoriteiten en overheden. Opslag van de encryptiesleutel gebeurt op het apparaat van gebruikers.

Verder doet Confer de belofte dat het zijn AI nooit zal trainen op gebruikersdata en dat het die gegevens nooit zal verkopen of delen. "Niemand behalve jij heeft er toegang toe", luidt de verklaring over gebruikersdata. Confer geeft gebruikers de mogelijkheid om chatconversaties met ChatGPT te importeren. Daarvoor moeten die gegevens bij de AI-chatbot van OpenAI eerst geëxporteerd worden, waarna het exportbestand is te uploaden naar Confer.

AI-vergissingen

De onderliggende IT-infrastructuur, inclusief het grote taalmodel en backendsystemen, draaien geheel op opensourcesoftware, meldt Ars Technica. Daardoor kunnen gebruikers deze software controleren via een cryptografische verificatie van de code. Onderaan de webpagina voor deze nieuwe AI-chatbot van Marlinspike staat wel de mededeling dat Confer vergissingen kan maken en dat gebruikers belangrijke informatie moeten controleren.

Reacties (30)

[Mayco]

Hmm, e2e encryption is logisch tussen twee devices, waar elke device een key heeft, maar tussen een device en een LLM is wat vreemd toch? Als het LLM aan een specifieke key kan voor jou e2e communicatie, dan kan een medewerker van Confer daar toch ook aan?

[GertMenkel]

Volgende het blog van Confer gebruiken ze inderdaad plaintext inference.

Wat ze wel aanbieden is remote hardware attestation van de VM/hardware waarop de inference gedaan wordt. Je kunt dus de source code van de hun runners erbij pakken en cryptografisch valideren dat de code die hun runners uitvoeren ook daadwerkelijk de broncode is die gepubliceerd is. Zolang in de broncode geen kwetsbaarheden of backdoors zitten, zitten die er dan ook niet in wanneer het model draait.

Vaak wordt remote attestation andersom gebruikt (verifiëren dat je apparaat wel is welke het claimt te zijn, bijvoorbeeld voor banken en DRM) maar hier werkt het andersom. Leuk om dat ook een keer te zien.

De E2EE zit hem vooral in de data die je heen en weer gooit naar de LLM-server (dat gaat niet over plaintext HTTP, ook niet voorbij de TLS-terminatie) en tussen je apparaten als je op meerdere apparaten inlogt. Er wordt voor zover ik kan vinden geen gebruik gemaakt van technieken als homomorphe versleuteling.

[AgamemnonZ]

De link naar de betreffende blogpost https://confer.to/blog/2026/01/private-inference/

[latka]

Ook mijn eerste gedachte te tenzij er gebruik gemaakt wordt van homomorfe crypto maar dat zie ik niet vliegen met LLMs.

[Pinkys Brain]

Het gebruikt SEV/TDX. Dus jij communiceert met een VM op een server met een zootje GPUs waarvan je weet door verifiable builds en attestation wat erop draait. Als er in die build geen communicatie naar buiten is, maar alleen E2EE communicatie van/naar gebruiker dan is de data in theorie afgesloten van de rest van de wereld. Daar zorgt SEV/TDX voor.

In de praktijk zijn er heel veel impliciete sidechannels door middel van timing of PCIe afluisteren (dat laatste helpt TDISP tegen, maar dat gebruiken ze nog niet, zit alleen op Blackwell). Zelfs expliciete sidechannels om data uit de VM naar de hypervisor te sluizen zullen moeilijk te vinden zijn, heel veel source code om wat in te verstoppen (moet er natuurlijk wel uit zien als een bug als je het goed doet, maar ook dat valt wel te doen).

[Reactie gewijzigd door Pinkys Brain op 13 januari 2026 19:01]

[IlIlIllII]

Is Confer per direct beschikbaar? Ik krijg met diverse browsers (Chrome, Firefox, Edge - allemaal up-to-date) de volgende melding bij het bezoeken van de pagina:

Advanced Passkey Features Required

This application requires passkey with PRF extension support for secure encryption key storage. Your browser or device doesn't support these advanced features. Please use Chrome 116+, Firefox 139+, or Edge 141+ on a device with platform authentication (Face ID, Touch ID, Windows Hello, etc.).

Edit: voor zover ik opmerk is het passkey gedeelte cruciaal. Op mijn iPhone 13 werkt Confer wel gewoon. Op mijn Windows 11 computer (met wachtwoord, zonder Windows Hello functionaliteit) niet.

[Reactie gewijzigd door IlIlIllII op 13 januari 2026 15:50]

[GertMenkel]

Als ik deze website bekijk, lijkt het erop dat Microsoft het nodige codepath nog niet open heeft gezet om deze functie te gebruiken i.c.m. Windows Hello. Een andere passkey-provider zou wel moeten werken als ik het zo lees (Yubikeys, telefoon-als-passkey via CTAP2, sommige browser-extensies).

Na even spelen heb ik ontdekt dat die melding gedeeltelijk ook veroorzaakt wordt door user agent filtering, als ik mijn user agent aanpas dan kom ik wel voorbij dat scherm maar gaat de website in de volgende stap stuk.

[Reactie gewijzigd door GertMenkel op 13 januari 2026 16:12]

[Orogima]

Confer zelf vermeld 1Password en YubiKey als werkend. Bitwarden werkt niet bij mij. Wordt nochtans toegevoegd, maar Confer ziet deze als mislukt.

[GertMenkel]

Bitwarden geeft op hun website aan dat Chromium-browsers wel PRF-capabel moeten zijn maar Confer geeft aan dat Bitwarden niet werkt vanwege bugs. Ik vermoed dat het daardoor komt.

Nu dat er daadwerkelijk een publieke dienst is die deze API gebruikt, vermoed ik dat de feature de komende tijd beter zal gaan werken. Tot nu toe heb ik er eigenlijk alleen maar theoretische demo's van gezien.

[Orogima]

Ik moet ook wel bekennen dat ik Firefox gebruik en geen Chromium browser. Kan het ook wel aan liggen.

[pli]

Ik heb hier met 1Password prima een passkey kunnen maken en op Windows met Brave ingelogd op Confer.

[nout77]

Ik heb het getest op Firefox voor Android en krijg deze melding:

Your authenticator doesn't support encryption keys. Please try again using Google Password Manager or 1Password — some password managers like Bitwarden don't work yet.

[Gr4mpyC3t]

Interessant, maar ik zie hier wel een paradox:

Hoe kan een AI-model beter worden zonder input te vergaren van gebruikers of het internet? Als Confer end-to-end versleuteld is en geen data verzamelt, hoe komt Signal dan aan het basismodel? En hoe gaan ze dit model in de toekomst verbeteren?

Dat "data niet leesbaar is voor de aanbieder" klinkt goed, maar dit lijkt een catch-22:

1. Of je verzamelt geen data en het model blijft zoals het is (en wordt dus niet beter)
2. Of je verzamelt wel data voor verbetering, maar dan is de privacy-belofte niet volledig waar

Ik lees niet terug waar het model vandaan komt en welke data het daarvoor gebruikt?

[duvekot]

Een LLM kan waarschijnlijk nooit "beter" worden van de input van gebruikers. Die vragen juist zaken aan de LLM waar ze zelf weinig of geen kennis van hebben. Je wil je LLM juiste trainen op authentieke en correcte en unieke data.

Dat is het komende gevaar. Hoe weet je dat de training data die je gebruikt voor je LLM niet door een LLM zelf is aangemaakt 🤔

En ondertussen hebben de meeste grote LLM partijen al bijna alle vrij verkrijgbare publieke data al verzameld in datasets voor de training. Het gaat nu eigenlijk meer om hoe je handig tools kan gebruiken, kan anticiperen op data die je binnen krijgt die nieuw is (bijvoorbeeld uit het aanroepen van een applicatie). Maar ook extra redenatie over wat de gebruiker nu eigenlijk vraagt en welke extra vragen dat oproept. Dat is wat ze nu doen met "thinking" .. en pas daarna gaan ze weer op de statische manier lettergrepen en woorden achterelkaar zetten die de meeste logische zijn op basis van de "context" die ze hebben.

[Gr4mpyC3t]

Gebruikersdata wordt juist wel gebruikt om taalmodellen beter te maken. Dat is precies waar Reinforcement learning from human feedback voor bedoeld is.

Moderne LLMs zoals ChatGPT doorlopen meerdere trainingsfases:

1. Op publieke datasets (waar jij naar verwijst)
2. Op specifiekere, vaak ook bewezen datasets
3. En dan RLHF.

Bij die laatste fase worden chats, prompts en beoordelingen juist gebruikt om een 'reward model' te trainen dat aangeeft wat mensen als goede/slechte antwoorden ervaren. Het model leert dan om gewenste antwoorden te genereren.

OpenAI, Anthropic, Google en anderen gebruiken standaard je data voor RHLF, tenzij je dit zelf uitzet in je instellingen.

Dus de vraag blijft: hoe gaat Confer dit doen als alle data end-to-end versleuteld is? Je kunt geen RLHF doen als je de chats niet kunt lezen.

[Quacko]

Zoals de poster hierboven al vernoemde. Maar de reinforced learning fase zal zijn op basis van de gesprekken van de medewerkers. Niet die van de 'klanten'.
Dus het ene sluit het andere niet uit.
Al lijkt mij het toch opportuun om te leren uit gesprekken waar een gebruiker de llm wijst op een contradictie of fout. Dus ik ben dan meer fan om te zeggen dat je default niet gebruikt wordt maar dat je manueel kan aanduiden een bepaalde chat wel te gebruiken voor training. Zo krijg je een beetje commmunity based verbetering en mits screening zelfs redelijk kwalitatieve training want buiten de trolls die je met de screening er uit haalt gaan mensen degelijk materiaal aanduiden om uit te leren.
Ik heb al vaak gedachr dat een knopje bij een respons waar de llm zich tegenspreekt od iets dergelijks eenteressant zou zijn om te kunne melden...

[AgamemnonZ]

Lees vooral Moxie's zeer interessante blogs over dit project https://confer.to/blog.

Moxie probeert o.a. het probleem dat end-to-end encrypted data moeilijk te syncen is tussen devices (zie Signal) op te lossen met vernuftig gebruik van passkeys: https://confer.to/blog/2025/12/passkey-encryption/

[Reactie gewijzigd door AgamemnonZ op 13 januari 2026 15:38]

[litebyte]

Hacker? Klinkt natuurlijk wel spannender...maar hij is officieel ontwikkelaar en beveiligingsonderzoeker...heel mooi dat het open source is en de mogelijkheid biedt tot het importeren van data van ChatGPT

[Frij5fd]

Venice, Kagi en Proton bieden al producten aan die hier sterk op lijken. Goed dat er meer aanbod komt, maar of de vijver groot genoeg is om veel partijen naast elkaar te hebben vraag ik me af

[Mifuki]

Weet iemand hoe Lumo van Proton vergelijkt qua privacy en security vs wat Signal uitbrengt?

edit:
typo

[Reactie gewijzigd door Mifuki op 13 januari 2026 21:34]

[djwice]

Waar kan ik het model vinden?
Zou een gguf bestand moeten zijn, vindt het niet 1-2-3 op huggingface?

[Wout_2007]

Ik hoop dat je dit model binnenkort ook lokaal kan draaien via een ollama ofzo

[djwice]

Als je de url hebt moet je hem kunnen downloaden en dan draait ie ook in ollama.

[Wout_2007]

ohh vet! ik zal eens kijken of ik het aan de gang krijg THX voor de comment!

[djwice]

https://docs.ollama.com/import

Het kan zijn dat op jouw hardware vLLM nóg efficiënter de modellen kan draaien die je wilt gebruiken:
https://github.com/vllm-project/vllm

[Reactie gewijzigd door djwice op 16 januari 2026 22:19]

[Gr4mpyC3t]

Oeps, dubbel.

[Reactie gewijzigd door Gr4mpyC3t op 13 januari 2026 17:24]

[Bas van Pelt]

Ik heb weinig behoefte aan gehallucineerde reacties op mijn vragen, maar soms gebruik ik Lumo van Proton vanwege de privacy, dus omdat ik dossiervorming wil vermijden als dat makkelijk kan.
Is Confer dan beter of wat anders?

[Paul1202]

Bij mij is het wel gelukt met Microsoft-Edge. Hij vroeg me direct om een passkey aan te maken in mijn 1Paswword. Werkte prima