Samlify
Villkor

Säkerhet

Vad som är krypterat, vad som inte är det, och vad som händer när något går fel. Aldrig snyggare än sanningen.

Senast uppdaterad 21 augusti 2026.

Det här står på sidan

Vad lämnar du ifrån dig om du kopplar in din egen brevlåda?

Ett lösenord som kan läsa och skicka allt i den brevlådan. Vi lagrar det, vi använder det utan att fråga dig varje gång, och det fungerar tills du kopplar ifrån brevlådan eller byter lösenord hos din leverantör. Det är den raka versionen, och den står först på sidan för att den är det största som står här.

Varför dörren finns över huvud taget

Det finns tre sätt att få in posten i Samlify, och de kostar dig olika saker.

  • Google eller Microsoft. Du godkänner oss i deras egen dialog och vi ser aldrig ett lösenord. Du kan återkalla det från din egen kontosida på tio sekunder. Är du på någon av dem: välj den här.
  • Din egen brevlåda. Den här texten handlar om den. Den finns för att ett företag på one.com, Loopia eller ett webbhotells egen mejlserver inte kan gå in genom den första dörren, och utan den här får det ingen historik, ingen Skickat-mapp, och brev som går ut i någon annans namn.
  • En vidarebefordringsadress. Du lämnar inte ifrån dig något. Du får då heller ingen historik och ingen Skickat-kopia, och vi kan inte skicka i ditt namn.

Hur det förvaras

Lösenordet är krypterat med en nyckel som hör till just den brevlådan. Den nyckeln är krypterad med en nyckel som hör till ditt företag. Den nyckeln är krypterad med en huvudnyckel, och huvudnyckeln ligger inte på de servrar som kör Samlify. Den bor i en egen tjänst, i ett eget konto, som ingenting annat når. När Samlify behöver läsa dina uppgifter ber den tjänsten packa upp dem, och den får aldrig själva huvudnyckeln. Varje sådan begäran loggas med ditt företag och tidpunkten, det finns ett tak för hur ofta de får göras, och de kan stängas av för alla kunder på en gång.

Var det här är svagare än det starkaste alternativet, sagt rakt ut. Vissa leverantörer håller en huvudnyckel i manipuleringsskyddad hårdvara som ingen, inte heller de själva, kan läsa ut den ur. Vår ligger inte i sådan hårdvara. Den är en hemlighet i ett andra konto, så skyddet vilar på att de två kontona verkligen är skilda åt, med skilda inloggningar. Det hindrar den som tar sig in i Samlify från att gå därifrån med nyckeln. Det hindrar inte den som kommer in på kontot där den ligger.

Vad ett intrång faktiskt skulle betyda

Det vore allvarligt, och stycket ovan hindrar det inte. Kod som kör som Samlify kan be nyckeltjänsten packa upp dina uppgifter, för det är precis vad produkten gör varje gång den läser din post. Den som tar kontroll över Samlify kan alltså läsa och skicka post i ditt namn, så länge kontrollen varar.

Det upplägget köper är inte att det aldrig händer. Det är att en sådan händelse blir synlig (varje uppackning är en loggrad), begränsad (takten sätter ett tak för hur fort något hinner dekrypteras) och möjlig att döda (en åtgärd stoppar alltihop, också kopior vi inte känner till). Utan det hade en enda läsning av vår konfiguration betytt att varje kund gick att dekryptera för alltid, tyst, utan nät, och utan något att stänga av. Vi beskriver hellre skillnaden ärligt än kallar resultatet säkert.

Vi ber om det svagare lösenordet när det finns ett

Flera leverantörer låter dig skapa ett appspecifikt lösenord: ett som bara fungerar för post, som går att återkalla ensamt, och som inte loggar ut din telefon när du gör det. Har din leverantör ett sådant frågar anslutningsrutan efter det och länkar till sidan där du gör ett. Kontots riktiga lösenord är reserven, aldrig vårt förstahandsval.

Att koppla ifrån förstör nyckeln

När du kopplar ifrån en brevlåda letar vi inte reda på rader att radera. Vi förstör den brevlådans nyckel, och i samma sekund är det sparade lösenordet chiffer som ingen kan läsa, inte vi heller. En skrivning, ingen kaskad, ingenting kvar att glömma. Att avsluta kontot gör samma sak ett steg upp, för varje uppgift ditt företag någonsin lämnat ifrån sig.

Det ärliga förbehållet. Vår databas säkerhetskopieras, och en kopia som togs innan du kopplade ifrån bär fortfarande den gamla krypterade nyckeln. Strimlingen är alltså klar först när de kopiorna är för gamla och raderas, vilket tar 30 dagar. Fram till dess är det sanna beskedet att nyckeln är borta ur det som är i drift och finns kvar i en säkerhetskopia ingen läser rutinmässigt. Vi tänker inte säga att raderingen är omedelbar och total, för det är den inte.

Vad vi kan se

Allt i den brevlåda vi synkar: avsändare, ämnen, brödtexter och namnen på bilagor. Det är ingen bieffekt av att vi håller lösenordet, det är produkten. Att läsa posten är hur Samlify sorterar den, och det som läses lagras i vår databas på det sätt som beskrivs under Vad är inte krypterat? nedan.

Varje gång vi ansluter, synkar, skickar eller kopplar ifrån skrivs en rad med tidsstämpel i din egen granskningskedja. Du kan läsa den. Det kan vi också, och ingen annan.

En synk markerar aldrig din olästa post som läst. Breven hämtas med det IMAP-kommando som låter oläst-flaggan vara, och mappen öppnas skrivskyddad så att servern inte heller får ändra den.

Vad är krypterat?

Nycklarna till dina system

Åtkomst- och förnyelsetoken till Gmail, kalendern, Fortnox och resten ligger i två lager. En huvudnyckel krypterar din egen datanyckel, och din datanyckel krypterar dina tokens. En läckt datanyckel exponerar en kund, inte alla.

Sedan 21 augusti 2026 finns huvudnyckeln inte i Samlifys egen konfiguration alls: den bor i en egen tjänst i ett eget konto, som beskrivs i avsnittet om brevlådan ovan, och samma skydd gäller varje uppgift i valvet och inte bara lösenord till brevlådor.

Klartexten lämnar aldrig valvfunktionerna och skrivs aldrig till en logg.

Sessioner och inloggningslänkar

Vi lagrar aldrig värdet, bara ett hashvärde av det. En kopia av sessionslagret ger alltså ingen en giltig inloggning, och en kopia av länktabellen ger ingen en giltig länk.

På väg in och ut

All trafik går över TLS. Sessionskakan är HttpOnly och Secure, och den är bunden till värdnamnet: en session på adminvyn följer aldrig med till kundsidan.

Vad är inte krypterat?

Allt annat ligger i klartext i databasen. Mejlrubriker och brödtexter, kalenderposter, namn, adresser, fakturor, abonnemangsstatus och samtalet med assistenten.

Skyddet där är Cloudflares kryptering i vila plus åtkomstkontrollen på vårt Cloudflare-konto, alltså inget Samlify gör utöver det. Konsekvensen rakt ut: den som kommer in på det kontot kan läsa varje kunds mejl i databaskonsolen. Försvaret är tvåfaktor på kontot och så få personer med åtkomst som möjligt, inte kryptografi.

Det är normalt för en produkt i det här skedet, och det ska sägas som det är när någon frågar. Vill du ha ett annat svar i ett upphandlingsformulär får du det inte av oss.

Kan en annan kund se mitt hus?

Nej. Varje fråga mot databasen binder ditt kundnummer i villkoret, och det är inte en vana utan något som provas mekaniskt.

Två prov håller det. Det ena skapar två kunder, skriver data som den ena och går sedan genom varje adress i gränssnittet som den andra: ingenting ska synas och ingenting ska gå att ändra. Det andra läser alla adresser i koden och faller om en ny adress saknas i tabellen, så att provet inte kan glömmas bort när något läggs till.

Samma sak gäller vårt eget förslag när någon ny ska bjudas in: en adress visas aldrig i klartext utom när det är samma brevlåda. Alla andra maskeras.

Är det farligt att öppna ett brev?

Inkommande brev ritas som avsändaren formgav dem. Det är den enda plats i produkten där någon annans markup hamnar i vårt dokument, och den tvättas på servern innan brevet ens skrivs till databasen.

Fyra regler bär tvätten:

  • En tillåtelselista över element och attribut, aldrig en förbudslista.
  • Skript, stilblock, ramar och formulär tas bort med innehåll.
  • Länkar bara till http, https, mailto och tel, och alltid i ny flik utan att bära med sig sidan.
  • Bilder laddas inte av sig själva. En läsnotis till avsändaren blir därför alltid ett aktivt val från dig.

Under tvätten ligger en innehållssäkerhetspolicy som andra försvarslinje. Båda ska hålla på egen hand.

Vad loggas aldrig?

  • Inloggningslänkar i produktion.
  • Tokens i klartext, någonstans.
  • Lösenord till brevlådor, någonstans, inte heller deras längd. IMAP-bibliotekets egen felsökningslogg skulle skriva ut hela inloggningen, så den är avstängd i stället för filtrerad.
  • Innehållet i en inloggningskod när ett fel uppstår. Felmeddelandet från leverantören klipps till 300 tecken och koden följer aldrig med.

Det som loggas är driftinformation: vilken koppling som gick fel, när, och hur. Det räcker för att laga och det är meningen.

Finns det säkerhetskopior?

Ja, och de är prövade. En säkerhetskopia ingen läst tillbaka är ett antagande, inte en kopia, så vi har ett skript som exporterar databasen, läser tillbaka den och jämför antalet rader i tio tabeller.

Senaste provet kördes 16 augusti 2026: 121 MB export, 83 sekunder, åtta av tio tabeller exakt lika. Två avvek med 1 respektive 4 rader, och orsaken var att minutsynken skrev nya poster medan exporten pågick. Vi skriver ut det talet i stället för att avrunda till tio av tio.

Säkerhetskopior sparas i 30 dagar. Det fönstret är också vad som avgör när en förstörd nyckel till slut är borta överallt, som beskrivs i avsnittet om brevlådan ovan.

Vad händer vid en incident?

Vi stoppar först och utreder sedan. Är en nyckel eller ett token inblandat roteras det innan städningen börjar, för fram till dess är det läckt oavsett vad historiken säger.

Drabbar en personuppgiftsincident dig hör vi av oss utan onödigt dröjsmål och senast inom 72 timmar från att vi upptäckt den, med vad som hänt, vilka uppgifter det gäller och vad vi gjort. Det är kravet i dataskyddsförordningen och det är också vad vi tänker göra.

Det finns ingen jour dygnet runt i dag. Vi är få, vi bevakar tjänsten, och du ska veta vilken storlek på bolag du köper av. Hittar du något som ser fel ut: hello@samlify.com, och du får svar från en människa.

Vad är inte löst än?

Fem saker, och de står här för att listan är mer värd än tystnaden.

  • Databasens jurisdiktion. Den svarar från Stockholm, men den är inte bunden till EU. Se Var ligger datan?
  • Innehållssäkerhetspolicyn. Den tillåter fortfarande inline-skript, så mot ett skript som tagit sig förbi tvätten ger den inget extra skydd än. Tvätten är alltså ensam försvarslinje just där tills det är åtgärdat.
  • Klartext i databasen. Se avsnittet ovan. Kryptering per kund på fältnivå är inte byggd.
  • Ett lösenord till en brevlåda går inte att återkalla från vår sida. Att förstöra vår nyckel hindrar oss från att använda det, och det är vad vi råder över. Bara du kan ogiltigförklara själva lösenordet, hos din mejlleverantör, och efter varje incident som rör valvet är det steget vi kommer att be dig ta.
  • Huvudnyckeln ligger inte i manipuleringsskyddad hårdvara. Se avsnittet om brevlådan ovan. Den är skild åt av konto i stället för av hårdvara, vilket är en verklig skillnad och en vi hellre skriver här än låter dig upptäcka själv.

Listan ändras när sakerna är gjorda, inte innan.