Vanliga frågor

Varför är den här webbplatsen dåligt översatt? ⎃

Tyvärr, men nuvarande författare talar bara engelska. Vi behöver hjälp med att översätta detta projekt till andra språk. Som ett enkelt och billigt sätt att göra denna tjänst tillgänglig för personer som inte talar engelska använder vi maskinöversättning. Resultaten är vanligtvis acceptabla, men kan leda till konstiga formuleringar eller till och med helt felaktig information. Du kan hjälpa oss att förbättra upplevelsen för alla - skicka in rätt översättning .

Hur säker är den här tjänsten?

Vi har vidtagit många steg för att göra den här tjänsten säker för den avsedda användningen . Innan vi går igenom dessa steg är det viktigt att förstå följande:

Vårt mål är att erbjuda denna tjänst på ett sätt som erbjuder alternativ för att förbättra din integritet och säkerhet. Här är några steg vi har tagit för att skydda din information:

Varför fick jag en länk här med möjlighet att dekryptera ett meddelande?

Vi ber om ursäkt om det finns fel i denna översättning . Denna tjänst skickar helt enkelt ett krypterat meddelande från en punkt till en annan och du är mottagaren. Meddelandet kommer snart att raderas. Operatörerna av denna tjänst har inget sätt att läsa meddelandets innehåll. Vanligtvis använder någon den här tjänsten när de inte vill att innehållet i ett meddelande ska finnas kvar i olika databaser / enheter / tjänster / filer / etc. som är vanligt när du skickar ett e-postmeddelande / snabbmeddelande / text / etc. Om du bestämmer dig för att dekryptera, kom ihåg följande:

Tar du bort allt som skickas till den här webbplatsen?

Sann mot vår papperskorgslogotyp ... allt raderas strax efter att ha fått det. Radering av allt är automatiserat - det skrivs in på servern. Tänk på det här - det finns två klasser av information som skickas in:

När det gäller meddelanden kan du kontrollera när vi tar bort dem genom att ange: Som standard raderas allt om ett meddelande efter att det har hämtats en gång eller är 1 vecka gammalt - beroende på vad som händer först. När det gäller att radera all annan information som ligger i att skicka något på webben (t.ex. din IP-adress etc.), ger vi dig ingen kontroll över när eller hur den raderas - vi tar bara bort den var 24: e timme .

Varför använda den här tjänsten?

Denna tjänst är ett verktyg för att göra meddelanden du skickar / tar emot mindre permanenta. Det mesta av det du kommunicerar på Internet (chattar, texter, e-post, etc.) lagras och raderas sällan. Ofta när du raderar något raderas det faktiskt inte utan markeras som borttaget och visas inte längre för dig. Din sammanlagda kommunikation ackumuleras år efter år i databaser och på enheter som du inte har kontroll över. Oundvikligen hackas en eller flera av de organisationer / personer / enheter som lagrar din kommunikation och din information läcks ut. Detta problem är så genomgripande att det nu finns många webbplatser som spårar de organisationer som har äventyrats och läckt ut användardata. End-to-end krypterade tillfälliga meddelanden är en enkel lösning för att göra vissa av dina kommunikationer mindre permanenta. Varje meddelande som skickas till den här webbplatsen har en livstid som sträcker sig från 1 minut till 2 veckor - när den tiden har gått raderas meddelandet. Standardinställningen är dessutom att radera alla meddelanden när mottagaren har hämtat det. Dessutom krypteras alla meddelanden från din enhet hela vägen till mottagarens enhet. Huvudmålet med att använda end-to-end-kryptering är att ta bort vår förmåga att läsa alla skickade meddelanden och därmed ta bort en del av tillitskravet. Slutresultatet är att det nu är enkelt att skicka ett krypterat meddelande via en enkel länk. Det meddelandet raderas antingen strax efter att det har skickats eller efter hämtningen. Du behöver inte installera / konfigurera speciell programvara. Du behöver inte skapa ett konto eller tillhandahålla någon personlig information. Mottagaren behöver inte vara i dina kontakter eller ens veta om den här tjänsten - det enda kravet att de kan klicka på en länk.

Är detta en meddelandetjänst?

Nej. Den här tjänsten är utformad för att komplettera befintliga meddelandetjänster som snabbmeddelanden / e-post / text / etc. genom att lägga till möjligheten att förhindra att skickade meddelanden lagras under lång tid. Vi levererar inte den genererade länken till mottagaren .

Vilka är avsedda användningsfall?

Så vad är några scenarier där det är lämpligt att använda den här tjänsten? Medan alla har olika behov och krav när det gäller deras integritet och säkerhet, har jag personligen hittat följande scenarier som lämpliga användningsfall:

Vad ska denna tjänst inte användas till?

Den här tjänsten ska inte användas för mycket känslig information av alla skäl som förklaras i denna FAQ. Nedan följer några exempel på vad man inte ska göra:

Varför inte bara använda PGP / Signal / OMEMO / Matrix / etc.?

Om du känner till personen du vill skicka säkra tillfälliga meddelanden, skickar dem ofta, förväntar dig ett chattliknande gränssnitt och / eller kan förvänta dig att mottagaren har den nödvändiga programvaran och vet hur man använder den, är den här webbplatsen förmodligen bästa lösningen. Det finns bra alternativ där ute som är öppen källkod, stöder E2EE, inte webbaserade, och till och med några som Signal som också stöder tillfälliga meddelanden. Jag personligen använder en privat XMMP-server och OMEMO för att chatta med nära vänner och familj. Att använda den här webbplatsen kan bara vara optimalt om du inte vet vilken programvara mottagaren kör, inte känner till deras telefonnummer / kontakthandtag, inte vet deras tekniska kunskaper (men antar att de kan klicka på en länk), eller föredrar du bara att hålla meddelandet du skickar utanför den underliggande kommunikationstransporten.

Vilka krav finns?

En modern och uppdaterad webbläsare som korrekt implementerar standarder inklusive Web Crypto API krävs. Exempel är: Chrome, Firefox, Edge och Safari (cirka 2020 eller senare).

Kan mottagaren göra en kopia av meddelandet?

Ja. Även om meddelandet kan ta bort sig själv efter hämtning kan mottagaren fortfarande se meddelandet. När som helst mottagaren kan se meddelandet helt kan en kopia göras - detta gäller all kommunikation. Det finns ett alternativ för att göra det svårare för mottagaren att göra en kopia. I detta fall implementeras tre hinder för kopiering:

Dessa kopieringsskydd är dock svaga eftersom de kan kringgås. Mottagaren kan också alltid bara ta en skärmdump eller ett foto av meddelandet.

Samlas någon personlig information in?

Vi stöder inte användarkonton (dvs. användarnamn / lösenord). Vi samlar inte in någon information som kan identifiera dig (dvs. namn / adress / e-post / telefon). Det är möjligt att viss personlig information kan finnas i meddelandet du skickar, men det är krypterat och vi har inget sätt att läsa det. Läs vår integritetspolicy för fullständig information.

Vilken information loggas?

Vår webbserver håller upp till 24 timmar vanligt loggformat för all webbaktivitet. Detta inkluderar loggning av hela IP-adressen för HTTP-klienter. Efter 24 timmar raderas den loggade informationen automatiskt. Alla förfrågningar som skickas till / api är POSTade, vilket innebär att ingen meddelandespecifik information någonsin loggas av webbservern. Dessutom loggas all information som sparas i databasen effektivt. Alla poster i databasen, inklusive anonymiserade och hashade IP-adresser, har en utgångstid (TTL) varefter de raderas automatiskt. TTL-utgångstiderna varierar mellan 1 minut och 2 veckor.

Vad gör du för att säkra servrarna?

Serversäkerhet är ett uppenbart problem. Det finns två huvudområden vi fokuserar på för att hålla det säkert:

Vilka säkerhetsrisker finns när du använder den här webbplatsen?

Innan jag specifikt tar upp några av dessa risker tror jag att en kortfattad analogi kan hjälpa till att sammanfatta riskerna med användning av internetkommunikation. Visualisera att alla system bara är lika säkra som den svagaste länken i en kedja. Föreställ dig nu ett scenario där det finns två personer i ett tillslutet rum utan möjlighet att se, höra eller spela in något de gör. Man kommer att skicka ett meddelande till den andra som vid läsning av meddelandet kommer att bränna det. Om någon utanför rummet vill få det meddelande som redan skickats kommer det att bli tufft. Vad är den svagaste länken för att få meddelandet? Det finns inte så många länkar att välja mellan - det är en ganska kort kedja. Tänk dig nu att när du skickar ett meddelande på Internet om att det finns minst en miljon länkar i kedjan - många av dem svaga - många av dem helt utanför din kontroll - och det är verkligheten.

Att använda kryptering kan i hög grad hjälpa till med ovanstående miljoner länkproblem och det är lätt att locka sig till att väl utformade E2EE-system erbjuder den slutliga lösningen. Men det här tänkandet kan få dig i trubbel, eftersom en angripare brukar bara följa de svagare länkarna i systemet. Till exempel är det förmodligen mycket lättare att ta över din telefon eller dator och ställa in en ingångsloggare för att bara läsa allt du skriver än att knäcka krypterade meddelanden över kabeln. Slutsatsen är att om jag fick i uppgift att kommunicera en hemlighet av vital / kritisk betydelse, skulle jag bara använda elektronisk kommunikation som en sista utväg.

Så det finns säkerhetsrisker med all kommunikation, men du använder fortfarande en webbläsare för bank, köp av saker, e-post etc. Det är en accepterad risk för de enorma bekvämligheter som erhållits. Frågan är verkligen ... vilka säkerhetsrisker är semi-specifika för den här webbplatsen? Några kommer att tänka på:

Vad gör du åt man-i-mitten-attacker (MITM)?

Alla användare av webbplatser kan potentiellt bli offer för en MITM-attack - den här webbplatsen är inte annorlunda än alla andra på nätet i detta avseende. En MITM-attack är när en angripare kan fånga upp och ändra kommunikation mellan användarens webbläsare och webbplatsens webbserver. Detta gör det möjligt för angriparen att ändra någon av webbplatsens kod / innehåll medan den fortfarande visas för slutanvändaren som den webbplats som de är vana vid. Vi vidtar några åtgärder för att försvåra en MITM-attack:

Men en MITM-attack är fortfarande alltid möjlig - speciellt om angriparen kontrollerar nätverks- / public key-infrastruktur som skulle vara fallet för stora / kraftfulla organisationer eller regeringar. Vi erbjuder webbläsartillägg som kan hjälpa till att mildra vissa MITM-risker.

Vilka fördelar erbjuder webbläsartilläggen?

Vi erbjuder webbläsartillägg för att ge extra bekvämlighet och extra säkerhet. Enkelt uttryckt ... Tilläggen gör att det går snabbare och enklare att skicka tillfälliga meddelanden. Viss säkerhet uppnås också eftersom all kod som används för att kryptera och förbereda ett meddelande lagras lokalt i tillägget. Eftersom koden lagras lokalt erbjuder detta avsändaren ett visst skydd mot MITM-attacker . Det är dock värt att påpeka att även om tilläggen erbjuder mer skydd mot en MITM-attack som äventyrar meddelandets innehåll, kan en MITM-attack fortfarande vara effektiv (dvs. att avgöra avsändarens IP-adress om den inte använder TOR / VPN / etc.).

Hur kan jag med säkerhet veta att allt som skickas är krypterat från slut till slut?

Till skillnad från många andra populära end-to-end-krypterade (E2EE) chattklienter är det ganska enkelt att se exakt vad som skickas till oss när du skickar ett meddelande. Nedanstående videohandledning visar hur du kan bekräfta att vi inte har något sätt att dekryptera meddelanden som skickas till servern.

Om du tänker på det, så länge vi inte är någon hemlig byrå som försöker samla in känsliga meddelanden, finns det ingen fördel för oss att kunna dekryptera meddelanden eftersom att ha den förmågan bara skapar problem för oss. Vi vill inte ens lagra meddelanden - det är dock ett nödvändigt ont att leverera dem.

Hur fungerar end-to-end-kryptering på den här webbplatsen?

För närvarande använder vi symmetrisk kryptering (AES-GCM 256bit) med nycklar härledda från lösenord (minst 150 000 iterationer av PBKDF2 / SHA-256). Asymmetrisk kryptering används inte eftersom det finns krav på att 1) avsändaren initierar kommunikationen 2) avsändaren och mottagaren inte är online samtidigt och 3) ingen information om mottagaren och 4) vi försöker hålla sakerna enkla och nyckelhantering är komplicerad. Standard Crypto API används för alla kryptografiska funktioner inklusive RNG. I grund och botten är det här som händer:

  1. Slutanvändaren väljer ett lösenord eller ett genereras automatiskt
  2. Ett API-samtal görs för att erhålla antalet obligatoriska PBKDF2 / SHA-256-iterationer ( detta steg krävs för skräppostkontroll )
  3. Ett 32 byte salt genereras
  4. En nyckel kommer från saltet och lösenordet
  5. En initialiseringsvektor (IV) med 12 byte genereras
  6. Meddelandet krypteras med nyckeln + IV
  7. Iterationsantalet, salt, IV och ciphertext skickas till servern (tillsammans med annan information som TTL, RTL, etc.)
  8. Servern returnerar ett slumpmässigt ID som hänvisar till meddelandet
  9. Webbläsaren presenterar sedan slutanvändaren med en länk som innehåller returnerat ID och lösenord eller en länk utan lösenordet (i vilket fall mottagaren måste känna till och ange lösenordet)
  10. Om lösenordet är en del av länken finns det i URL-hash och skickas därför aldrig till servern när mottagaren gör GET-begäran
  11. Mottagaren uppmanas om de vill dekryptera och visa meddelandet
  12. Webbläsaren gör en begäran som anger meddelandets ID
  13. Om avsändaren kräver att en CAPTCHA är klar, riktas mottagaren till en annan URL för att bevisa att de är mänskliga (när de passerar riktas de tillbaka)
  14. Servern skickar det krypterade meddelandet och raderar som standard meddelandet vid denna tidpunkt om läsuppsättningen (RTL) är en
  15. Mottagaren dekrypterar meddelandet med lösenordet (och uppmanas att ange lösenordet om det inte finns i webbadressen)
Denna inställning är extremt enkel och erbjuder meddelandekryptering från avsändarens enhet till mottagarens enhet, men saknar naturligtvis garantin som asymmetrisk kryptering kan erbjuda när det gäller att bara känna någon som har mottagarens privata nyckel kan dekryptera meddelandet. Alla med länken kan öppna meddelandet i standardscenariot där lösenordet är en del av URL: en - detta understryker vikten av att använda en lämplig transport för länken (t.ex. e-post / chatt / text / etc.) - ett beslut som lämnas till avsändare. Vi kan, om det finns intresse, också rulla ut stöd för ett mycket grundläggande asymmetriskt system, varigenom mottagaren initierar en begäran om ett meddelande och skickar den begärande länken till avsändaren av meddelandet. Denna inställning skulle eliminera behovet av att ha lösenordet i webbadressen, men eliminerar också avsändarens möjlighet att initiera.

Krypteringslösenordet kan finnas i URL: en?

Ja. Detta påverkar uppenbarligen säkerheten, för om metoden som används för att skicka länken är osäker är meddelandet osäkert av koppling. Alla lösningar för att eliminera denna fråga introducerar ytterligare steg och komplexitet som påverkar användarupplevelsen (dvs. saker måste ställas in i båda ändar innan meddelandet skickas). Ett asymmetriskt schema där mottagaren initierar en begäran om ett meddelande och skickar den förfrågningslänken kan fungera med vårt "allt är kortare" nyckelkrav - detta kan implementeras. I slutändan, om två parter kommer att skicka meddelanden till varandra ofta, finns det bättre lösningar förutsatt att båda parter kan hantera dessa lösningar.

Men dekrypteringslösenordet behöver inte finnas i webbadressen?

Korrekt. Om dekrypteringslösenordet inte ingår i länken uppmanas mottagaren att ange lösenordet. Om lösenordet kommuniceras säkert till mottagaren (eller de redan vet det), ger detta skydd mot avlyssning. Nackdelen är dock att mottagaren måste känna till och ange lösenordet korrekt. Här är ett sätt att skicka lösenordet till mottagaren som erbjuder ett visst skydd mot avlyssning:

  1. Kryptera lösenordet i ett meddelande med standardinställningarna och skicka den här länken till mottagaren.
  2. När mottagaren klickar på länken och dekrypterar meddelandet vet de att ingen annan har fått lösenordet före dem eftersom meddelandet som innehåller lösenordet raderas vid hämtning. Men om det finns en aktiv MITM -attack eller om din enhet eller mottagarens enhet har äventyrats är det fortfarande möjligt att en annan part kan få lösenordet.
  3. Bekräfta med mottagaren att de har fått lösenordet. Till exempel, om mottagaren informerar dig om att när de gick för att hämta lösenordet, att meddelandet redan hade raderats, vet du att någon annan fick lösenordet före mottagaren och att lösenordet därför äventyras och inte bör användas.
  4. Med hjälp av lösenordet som mottagaren bekräftade att de har kan du nu skicka ett meddelande med samma lösenord för kryptering - dela bara versionen av länken som inte innehåller lösenordet.

Det är korrekt - vi genererar länken och lämnar den till avsändaren hur man bäst levererar den till mottagaren. Målet med den här tjänsten är att erbjuda ett alternativ som erbjuder mindre beständighet i befintliga meddelandetransporter som e-post / chatt / text / etc. Därför är förväntningen att länken vi genererar som pekar på det tillfälliga meddelandet skickas via en befintlig meddelandetransport. Detta har säkerhetsmässiga konsekvenser som användarna bör förstå. Låt oss ta ett SMS-meddelande som ett exempel eftersom det här är en ganska osäker kommunikationsmetod. När du använder den här tjänsten för att skicka en tillfällig meddelandelänk via ett textmeddelande, om du använder standardläget där lösenordet ingår i länken, kan alla med länken läsa meddelandet och inget skydd mot avlyssning erbjuds. Denna tjänst tillhandahåller fortfarande en mer tillfällig kommunikation som kan förbättra integriteten och säkerheten. Dessutom kan du välja att skicka länken utan lösenordet och detta ger skydd mot avlyssning.

Hur kan jag skydda min integritet så mycket som möjligt när jag använder den här tjänsten?

Som diskuteras någon annanstans i denna FAQ, även om vi redan gör mycket för att skydda din integritet och även om vi inte samlar in någon personlig information, skickas och samlas in viss logginformation av oss och andra genom att du använder en webbläsare. Det finns dock flera sätt att skydda din integritet ännu mer. Ett sätt som är gratis att använda, baserat på programvara med öppen källkod, och som fungerar ganska bra är att använda Tor Browser . Denna webbläsare är utformad för att skydda din integritet på flera nivåer - inklusive att använda Tor-nätverket . Vår webbplats är redan tillgänglig via Tor-löknätverket, vilket innebär att åtkomst till vår webbplats via Tor inte kräver användning av en utgångsnod, vilket innebär att någon avlyssnar på utgångstrafik . Men kom ihåg att även i detta scenario kan din Internetleverantör se att du använder Tor - men inte vad för. Du kan även ansluta till en VPN och sedan starta Tor Browser för två lager av anonymitet; kom dock ihåg att din Internetleverantör fortfarande kan se att du använder en VPN i det här scenariot - men inte vad du ska använda. Om du inte vill att din ISP ska veta vilka protokoll du använder kan du ansluta till ett stort offentligt WiFi-nätverk som ett bibliotek, skola etc. och sedan använda webbläsaren Tor.

Vad händer om jag inte litar på USA?

Våra servrar finns i USA. Dessutom är vår CDN-leverantör, Cloudflare, ett företag baserat i USA. Vi har försökt ta bort behovet av att lita på oss eller det land där våra servrar finns helt enkelt för att vi inte samlar in personlig information, inte kan dekryptera några meddelanden och allt raderas strax efter det att det mottagits. Vi kan dock förstå en del misstro eftersom det är webbaserat och särskilt om du bor i vissa länder. Vi har några planer på att erbjuda alternativ på Island och Schweiz för människor som har svårt att lita på USA. Vänligen meddela oss om detta gäller dig, eftersom vi inte kommer att motiveras att erbjuda alternativ om det inte finns någon verklig efterfrågan.

Vad gör du för att förhindra skräppost?

När du tillåter någon att skicka ett meddelande som kan vidarebefordras via en länk bjuder du in spammare. Att begränsa detta problem är inte helt enkelt. Vi vill inte ladda en tredje part CAPTCHA som en del av meddelandesändningsprocessen av några anledningar:

Vi kan eventuellt komma runt API-problemet genom att använda något API-nyckelsystem, men då måste vi samla in användarinformation som vi inte vill göra. Vad ska också hindra spammare från att få massor av API-nycklar? Vi kan inte undersöka meddelanden för att dra slutsatsen att de är skräppost (vilket i bästa fall är mycket problematiskt), förutom att kryptera meddelandena har vi en hands-off-policy för meddelandens innehåll. Med tanke på dessa krav använder vi två metoder för att förhindra skräppost: Om du är medveten om att spammare missbrukar den här tjänsten, skicka in en missbruksrapport .

Varför finns det ett alternativ att kräva att mottagaren slutför en CAPTCHA?

Det är sant att vi ogillar CAPTCHA, men vi inser att de tjänar ett syfte och har en tid och plats (åtminstone för tillfället). Detta är ett enkelt sätt för avsändaren att få viss försäkran om att mottagaren är mänsklig och att automatiserade processer inte kommer åt meddelandet.

Vem driver den här tjänsten och varför är den gratis?

Vi är bara ett par killar som ibland möttes av svårigheterna att inte ha bra alternativ för att skydda vår integritet. Ofta berodde detta på att kommunicera med vänner och familjemedlemmar som inte var särskilt försiktiga med hur de hanterade sina enheter och information. Ottid detta inträffade när man använder webbaserade forum som Reddit eller använder webbaserade supportsystem. Vi hittade några webbaserade temporära meddelandelösningar, men ingen erbjöd E2EE vilket innebar att vi inte kunde lita på dem. Så vi byggde bara vår egen lösning och bestämde oss för att ge bort den så att andra kan dra nytta av den.

Hur kan jag lita på svaren på ovanstående frågor?

Egentligen borde du inte lita på någon webbplats bara för att den säger vissa saker - det är vanligtvis en bra idé att verifiera eventuella anspråk. Vi har försökt ta bort kravet på att lita på oss så mycket som möjligt genom att använda end-to-end-kryptering. Det är till exempel ganska lätt att granska att vi inte kan läsa några meddelanden eftersom de är krypterade . Vi har också hållit javaskriptkoden på den här webbplatsen mycket enkel så att den är lätt att läsa och förstå. Genom att göra all kod öppen källkod kan människor verifiera vad som körs; kom dock ihåg att det inte finns något sätt att verkligen verifiera vad servern kör. Även om det är sant att mycket av förtroendekravet tas bort med end-to-end-kryptering, är det fortfarande en faktor som våra användare väger mycket när de bestämmer sig för att använda den här tjänsten eller inte.