Säkerhetsarkitektur
Zero knowledge genom design
Krypteringsnycklarna ligger i URL-fragmentet (#key=...). Enligt HTTP-specifikationen skickas URL-fragment aldrig till servern. Webbläsaren klipper bort fragmentet innan den gör någon förfrågan.
Det innebär att servern aldrig ser krypteringsnycklar. Inte i förfrågningarnas adresser, inte i headers, inte i loggar, ingenstans. Även med full åtkomst till servern (root, databasdump, minnesinspektion) förblir samtalen oläsbara.
"Vi kan inte lämna ut det vi inte har."
Vad vi krypterar
Textmeddelanden
Krypteras i webbläsaren med NaCl secretbox (xsalsa20-poly1305). Varje meddelande använder en unik slumpmässig nonce. Servern lagrar bara ciphertext.
Algoritm: XSalsa20-Poly1305
Nyckellängd: 256 bitar
Bibliotek: TweetNaCl
Nonce: Slumpmässig, unik per meddelande
Röst och video
Krypteras med LiveKit E2EE och PBKDF2-nyckelhärledning. Alla ljud- och videorutor krypteras innan de lämnar din enhet.
Protokoll: LiveKit E2EE (SFrame)
Nyckelhärledning: PBKDF2
Mediaserver: Egen drift, inte moln
Inspelning: Omöjlig (nycklarna finns aldrig på servern)
DÄRFÖR ÄR DET SÄKERT
- ✓ Text: NaCl secretbox (xsalsa20-poly1305), autentiserad kryptering, 256-bitars nyckel, granskad TweetNaCl-implementation
- ✓ Röst och video: varje ruta krypteras innan den lämnar din enhet
- ✓ Egen mediaserver, ingen tredjepartsmoln behandlar era strömmar
Vad vi inte lagrar
DÄRFÖR ÄR DET SÄKERT
- ✓ Ingenting att stjäla, även ett fullständigt dataintrång ger noll användbar data
- ✓ Inga användarkonton betyder inga lösenordsdatabaser att attackera
- ✓ Ingen IP-loggning betyder ingen koppling mellan rum och identiteter
Om vi tvingas av lag
Om Hushroom får en giltig rättslig begäran (domstolsbeslut, föreläggande, begäran från brottsbekämpande myndighet) är detta en transparent redovisning av vad vi kan och inte kan lämna ut:
Vi KAN bekräfta
- ●Att någon begärde en verifieringskod via e-post (vi lagrar inte vilken adress som användes)
- ●Ungefärlig tidpunkt för när rummet skapades
- ●Att ett rum har funnits (inte dess innehåll)
- ●Antal deltagare (inte deras identiteter)
Vi KAN INTE lämna ut
- ●Meddelandeinnehåll (krypterat hela vägen, lagras aldrig i klartext)
- ●Röst- eller videoinspelningar (spelas aldrig in)
- ●Krypteringsnycklar (når aldrig servern)
- ●E-postadressen som användes för att skapa rummet (lagras inte, bara en envägshash)
- ●Deltagares identiteter (anonyma genom design)
- ●IP-adresser (loggas inte)
- ●Historisk data (raderas automatiskt, inga backuper)
DÄRFÖR ÄR DET SÄKERT
- ✓ Tekniska begränsningar, inte löften i en policy. Vi kan inte lämna ut det vi inte har
- ✓ Minimalt med metadata, bara det som krävs för att förhindra missbruk
- ✓ Även metadata raderas när rummets TTL löper ut, inga historiska register
EU:s "Chat Control" (CSA-förordningen) och Hushroom
EU förhandlar om en förordning för att upptäcka material med sexuella övergrepp mot barn, ofta kallad "Chat Control". En tillfällig ordning med frivillig skanning gäller från augusti 2026. Den permanenta förordningen förhandlas fortfarande och väntas, enligt rapporteringen från trilogerna, skydda kryptering hela vägen.
Oavsett slutlig text lämnar Hushrooms konstruktion ingenting att skanna hos oss: det finns inga användarkonton, rummen är tillfälliga, meddelandeinnehåll krypteras i din webbläsare och servern håller bara ciphertext som raderas när rummet stänger. Vi kan inte läsa, spara eller lämna ut innehåll, och vi kommer inte att bygga in en bakdörr i produkten. Om lagstiftning någon gång skulle kräva det säger vi det här, öppet, innan vi ändrar något.
Vi följer förhandlingarna om CSA-förordningen och uppdaterar det här avsnittet när rättsläget ändras (senast granskat 2026-08-23).
Automatisk radering
All krypterad rumsdata ligger i Redis med strikt TTL och finns bara i RAM. Ingenting skrivs till disk (RDB och AOF är avstängda), och när TTL:en löper ut eller processen stoppas är det borta.
Rummen löper ut vid den tid som skaparen valt (15 minuter till 4 timmar). Raderingen är automatisk, inte ett städjobb som någon måste komma ihåg att köra.
Inga backuper. Inga repliker. Ingen återställning.
När data raderats är den borta. Det finns inget sätt att återskapa ett utgånget rum, även om vi ville.
DÄRFÖR ÄR DET SÄKERT
- ✓ Lagring bara i RAM, försvinner strömmen töms minnet omedelbart
- ✓ Ingen persistens på disk (RDB och AOF avstängda), ingenting skrivs till disk någonsin
- ✓ Automatisk TTL, raderingen är garanterad och inte valfri
Hantering av e-post
E-postadresser samlas bara in för den som skapar rum, inte för deltagare. Syftet är att förhindra missbruk genom att begränsa hur många rum en identitet kan skapa.
- Du anger din e-post för att skapa ett rum
- Vi skickar en sexsiffrig verifieringskod (via Lettermint)
- Efter verifiering SHA-256-hashas adressen och originalet kastas
- Bara hashen sparas i JWT-token och används för att begränsa antalet rum
- Vi kan inte återskapa din e-postadress ur hashen, det är en envägsfunktion
Deltagare, alltså de som ansluter via länk, lämnar ingen e-post. Bara ett visningsnamn som finns i minnet så länge sessionen pågår.
Skydd mot missbruk
Frekvensbegränsning: Redis-baserad begränsning på alla endpoints. Inloggning: 5 anrop per 15 minuter och IP. Rumsskapande: 10 per timme och verifierad e-post.
Värdkontroller: Den som skapat rummet kan kicka deltagare och låsa rummet så att ingen ny kan ansluta.
Rapportering: Rapportering av missbruk inne i rummet. Rapporter sparas i 90 dagar (bara rums-id och typ av rapport, inget meddelandeinnehåll).
Avstängning: Permanenta avstängningar med e-posthashar. Avstängda kan inte skapa rum, och eftersom bara hashen sparas innehåller inte ens spärrlistan några e-postadresser.
Infrastruktur
Egen drift i Sverige (EU)
HTTPS och WSS (TLS 1.3)
Egen LiveKit-drift, inte moln
Egen drift (UDP 3478, TLS 5349)
Redis (bara RAM, ingen persistens på disk)
Svensk rätt (EU:s dataskyddsförordning)
Frågor om säkerhetsmodellen?
Läs om hur rummen fungerar, eller skriv till oss. Vi svarar utförligt på säkerhetsfrågor.