Ofte stillede spørgsmål

Hvorfor er dette websted dårligt oversat? ⎃

Undskyld, men de nuværende forfattere taler kun engelsk. Vi har brug for hjælp til at oversætte dette projekt til andre sprog. Som et simpelt og billigt middel til at gøre denne service tilgængelig for folk, der ikke taler engelsk, bruger vi maskinoversættelse. Resultaterne er normalt acceptable, men kan resultere i mærkelig ordlyd eller endda helt unøjagtige oplysninger. Du kan hjælpe os med at forbedre oplevelsen for alle - indsend den korrekte oversættelse .

Hvor sikker er denne tjeneste?

Vi har taget mange skridt for at gøre denne tjeneste sikker til den tilsigtede anvendelse . Før vi går over disse trin, er det vigtigt at forstå følgende:

Vores mål er at tilbyde denne service på en måde, der tilbyder muligheder for at forbedre dit privatliv og din sikkerhed. Her er nogle skridt, vi har taget for at beskytte dine oplysninger:

Hvorfor modtog jeg et link her med mulighed for at dekryptere en besked?

Vi beklager, hvis der er fejl i denne oversættelse . Denne tjeneste sender simpelthen en krypteret meddelelse fra et punkt til et andet, og du er modtageren. Beskeden slettes snart. Operatørerne af denne service har ingen måde at læse meddelelsens indhold på. Normalt bruger nogen denne tjeneste, når de ikke ønsker, at indholdet af en besked skal forblive inde i forskellige databaser / enheder / tjenester / filer / osv. som det er typisk, når du sender en e-mail / øjeblikkelig besked / tekst / osv. Hvis du beslutter at dekryptere, skal du huske følgende:

Sleter du alt, hvad der sendes til dette websted?

I overensstemmelse med vores skraldespandlogo ... alt slettes kort efter modtagelse. Sletning af alt er automatiseret - det skrives ind på serveren. Tænk på det på denne måde - der er to klasser af oplysninger indsendt:

I tilfælde af meddelelser kan du kontrollere, hvornår vi sletter dem ved at angive: Som standard slettes alt om en besked, når den er hentet en gang eller er 1 uge gammel - alt efter hvad der sker først. Når det kommer til at slette alle andre oplysninger, der er forbundet med at indsende noget på nettet (f.eks. Din IP-adresse osv.), Giver vi dig ikke nogen kontrol over hvornår eller hvordan det slettes - vi sletter bare det hele hver 24. time .

Hvorfor bruge denne service?

Denne service er et værktøj til at gøre meddelelser, du sender / modtager, mindre permanente. Det meste af det, du kommunikerer på Internettet (chats, tekster, e-mails osv.), Gemmes og slettes sjældent. Ofte, når du sletter noget, slettes det faktisk ikke, men snarere markeret som slettet og ikke længere vist for dig. Din samlede kommunikation akkumuleres år efter år i databaser og på enheder, du ikke har kontrol over. Uundgåeligt hackes en eller flere af de organisationer / personer / enheder, der gemmer din kommunikation, og dine oplysninger lækkes. Dette problem er så udbredt, at der nu er mange websteder, der sporer de organisationer, der er kompromitteret og lækket brugerdata. End-to-end krypterede midlertidige meddelelser er en enkel løsning, der hjælper med at gøre nogle af din kommunikation mindre permanent. Hver besked, der sendes til dette websted, har en live-periode, der spænder fra 1 minut til 2 uger - når den tid er gået, slettes meddelelsen. Desuden er standardindstillingen at slette enhver besked, når modtageren har hentet den. Derudover er alle meddelelser krypteret fra din enhed hele vejen til modtagerens enhed. Hovedmålet med at bruge end-to-end-kryptering er at fjerne vores evne til at læse eventuelle indsendte beskeder og derved fjerne noget af tillidskravet. Slutresultatet er, at det nu er let at sende en krypteret besked via et simpelt link. Denne meddelelse slettes enten kort efter afsendelse eller ved hentning. Du behøver ikke at installere / konfigurere speciel software. Du behøver ikke oprette en konto eller give nogen personlige oplysninger. Modtageren behøver ikke at være i dine kontakter eller endda vide om denne service - det eneste krav, at de kan klikke på et link.

Er dette en messaging-tjeneste?

Nej. Denne service er designet til at supplere eksisterende messaging-tjenester som instant messaging / email / text / etc. ved at tilføje muligheden for at forhindre, at sendte beskeder lagres i lang tid. Vi leverer ikke det genererede link til modtageren .

Hvad er de tilsigtede anvendelsestilfælde?

Så hvad er nogle scenarier, hvor det er hensigtsmæssigt at bruge denne service? Mens alle har forskellige behov og krav, når det kommer til deres privatliv og sikkerhed, har jeg personligt fundet følgende scenarier som passende brugssager:

Hvad skal denne tjeneste ikke bruges til?

Denne service bør ikke bruges til meget følsomme oplysninger af alle de grunde, der er forklaret i denne FAQ. Nedenfor er nogle eksempler på, hvad man ikke skal gøre:

Hvorfor ikke bare bruge PGP / Signal / OMEMO / Matrix / osv.?

Hvis du kender den person, du vil sende sikre midlertidige beskeder, sender dem ofte, forventer en chatlignende grænseflade og / eller kan forvente, at modtageren har den nødvendige software og ved, hvordan den skal bruges, er dette websted sandsynligvis ikke det bedste løsning. Der er gode muligheder derude, der er open source, understøtter E2EE, ikke webbaseret, og endda nogle som Signal, der også understøtter midlertidige meddelelser. Jeg bruger personligt en privat XMMP-server og OMEMO til at chatte med nære venner og familie. Brug af dette websted er muligvis kun optimalt, hvis du ikke ved, hvilken software modtageren kører, ikke kender deres telefonnummer / kontakthåndtag, ikke kender deres tekniske færdigheder (men antager, at de kan klikke på et link), eller du foretrækker bare at opbevare den besked, du sender, uden for den underliggende kommunikationstransport.

Hvilke krav findes der?

Der kræves en moderne og opdateret webbrowser, der korrekt implementerer standarder inklusive Web Crypto API. Eksempler inkluderer: Chrome, Firefox, Edge og Safari (ca. 2020 eller senere).

Kan modtageren lave en kopi af meddelelsen?

Ja. Selvom beskeden muligvis sletter sig selv efter hentning, kan modtageren stadig se beskeden. Hver gang modtageren kan se meddelelsen fuldstændigt, kan der laves en kopi - dette gælder for al kommunikation. Der er en mulighed for at gøre det vanskeligere for modtageren at lave en kopi. I dette tilfælde implementeres tre hindringer for kopiering:

Disse kopibeskyttelser er dog svage, fordi de kan omgåes. Modtageren kan også altid bare tage et skærmbillede eller et billede af beskeden.

Er der indsamlet personlige oplysninger?

Vi understøtter ikke brugerkonti (dvs. brugernavn / adgangskode). Vi indsamler ingen oplysninger, der kan identificere dig (dvs. navn / adresse / e-mail / telefon). Det er muligt, at nogle personlige oplysninger kan være i den meddelelse, du sender, men de er krypteret, og vi har ingen måde at læse dem på. Se vores fortrolighedspolitik for komplette detaljer.

Hvilke oplysninger er logget?

Vores webserver holder op til 24 timers fælles logformat på al webaktivitet. Dette inkluderer logning af den fulde IP-adresse på HTTP-klienter. Efter 24 timer slettes disse loggede oplysninger automatisk. Alle anmodninger sendt til / api POSTes, hvilket betyder, at ingen meddelelsesspecifik information nogensinde er logget af webserveren. Derudover logges alle oplysninger, der er gemt i databasen, effektivt. Alle poster i databasen, inklusive anonymiserede og hashede IP-adresser, har en udløbstid (TTL), hvorefter de automatisk slettes. TTL-udløbstiderne varierer mellem 1 minut og 2 uger.

Hvad laver du for at sikre serverne?

Serversikkerhed er en åbenbar bekymring. Der er to hovedområder, vi fokuserer på for at beskytte det:

Hvilke sikkerhedsrisici er der, når du bruger dette websted?

Før jeg specifikt tager fat på nogle af disse risici, tror jeg, at en semi-kort analogi kan hjælpe med at opsummere risiciene ved brug af internetkommunikation. Visualiser, at ethvert system kun er så sikkert som det svageste led i en kæde. Forestil dig nu et scenario, hvor der er to personer i et lukket rum uden mulighed for at se, høre eller optage noget, de laver. Den ene vil sende en besked til den anden, som ved læsning af beskeden vil brænde den. Hvis nogen uden for dette rum ønsker at få den besked, der allerede var videregivet, bliver det svært. Hvad er det svageste led for at få beskeden? Der er ikke så mange links at vælge imellem - det er en smuk kort kæde. Forestil dig nu, at når du sender en besked på Internettet, at der er mindst en million led i kæden - mange af dem svage - mange af dem helt uden for din kontrol - og det er virkeligheden.

Brug af kryptering kan i høj grad hjælpe med ovenstående millionlinkproblem og det er let at lokke til at tro, at veldesignede E2EE-systemer tilbyder den endelige løsning. Imidlertid kan denne tænkning få dig i problemer, fordi en angriber normalt kun følger de svagere links i systemet. For eksempel er det sandsynligvis langt nemmere at overtage din telefon eller computer og konfigurere en indgangslogger til bare at læse alt, hvad du skriver, end at knække krypterede meddelelser over ledningen. Pointen er, at hvis jeg fik til opgave at kommunikere en hemmelighed af vital / kritisk betydning, ville jeg kun bruge elektronisk kommunikation som en metode til sidste udvej.

Så der er sikkerhedsrisici ved enhver kommunikation, men du bruger stadig en webbrowser til bank, køb af ting, e-mail osv. Det er en accepteret risiko for de enorme opnåede bekvemmeligheder. Spørgsmålet er virkelig ... hvilke sikkerhedsrisici er semi-specifikke for dette websted? Et par kommer til at tænke på:

Hvad laver du ved menneske-i-midten-angreb (MITM)?

Alle brugere af websteder kan potentielt blive offer for et MITM-angreb - dette websted er ikke anderledes end alle de andre på nettet i denne henseende. Et MITM-angreb er, når en angriber er i stand til at opfange og ændre kommunikation mellem brugerens browser og webstedets webserver. Dette gør det muligt for angriberen at ændre en hvilken som helst af websteds kode / indhold, mens den stadig vises for slutbrugeren som det sted, de er vant til. Vi tager nogle forholdsregler for at gøre et MITM-angreb vanskeligere:

Imidlertid er et MITM-angreb stadig altid muligt - især hvis angriberen kontrollerer netværk / offentlig nøgleinfrastruktur, som det ville være tilfældet for store / magtfulde organisationer eller regeringer. Vi tilbyder browserudvidelser, som kan hjælpe med at afbøde nogle MITM-risici.

Hvilke fordele tilbyder browserudvidelserne?

Vi tilbyder browserudvidelser som et middel til at give ekstra bekvemmelighed og ekstra sikkerhed. Kort sagt ... Udvidelserne gør det hurtigere og lettere at sende midlertidige meddelelser. Noget sikkerhed opnås også, fordi al kode, der bruges til at kryptere og forberede en besked, er gemt lokalt i udvidelsen. Da koden er gemt lokalt, giver dette afsenderen en vis beskyttelse mod MITM-angreb . Det er dog værd at påpege, at mens udvidelserne giver mere beskyttelse mod et MITM-angreb, der kompromitterer meddelelsesindholdet, kan et MITM-angreb stadig være effektivt (dvs. at bestemme afsenderens IP-adresse, hvis den ikke bruger TOR / VPN / osv.).

Hvordan kan jeg med sikkerhed vide, at alt indsendt er krypteret ende-til-ende?

I modsætning til mange andre populære end-to-end krypterede (E2EE) chatklienter er det ret simpelt at se nøjagtigt, hvad der sendes til os, når du sender en besked. Nedenstående videotutorial viser, hvordan vi kan bekræfte, at vi ikke har nogen måde at dekryptere beskeder sendt til serveren.

Også, hvis du tænker over det, så længe vi ikke er et hemmeligt agentur, der prøver at indsamle følsomme meddelelser, er der ingen fordel for os at være i stand til at dekryptere meddelelser, da at have denne evne kun skaber problemer for os. Vi ønsker ikke engang at gemme meddelelser - det er dog et nødvendigt onde at levere dem.

Hvordan fungerer end-to-end-kryptering på dette websted?

På dette tidspunkt bruger vi symmetrisk kryptering (AES-GCM 256bit) med nøgler afledt af adgangskoder (minimum 150.000 iterationer af PBKDF2 / SHA-256). Asymmetrisk kryptering bruges ikke, fordi der findes krav til, at 1) afsender initierer kommunikationen 2) afsender og modtager ikke er online på samme tid og 3) ingen oplysninger om modtageren og 4) vi prøver at holde tingene rigtige enkle, og nøglehåndtering er kompliceret. Standard Web Crypto API bruges til al kryptografisk funktionalitet inklusive RNG. Grundlæggende er her hvad der sker:

  1. Slutbrugeren vælger en adgangskode, eller den ene genereres automatisk
  2. Der foretages et API-opkald for at opnå antallet af krævede PBKDF2 / SHA-256-iterationer ( dette trin er nødvendigt for spamkontrol )
  3. Der genereres et 32 byte salt
  4. En nøgle stammer fra saltet og adgangskoden
  5. En 12 byte initialiseringsvektor (IV) genereres
  6. Meddelelsen krypteres ved hjælp af nøglen + IV
  7. Iterationstal, salt, IV og krypteringstekst sendes til serveren (sammen med nogle andre oplysninger såsom TTL, RTL osv.)
  8. Serveren returnerer et tilfældigt ID, der henviser til meddelelsen
  9. Browseren præsenterer derefter slutbrugeren med et link, der indeholder det returnerede ID og adgangskode eller et link uden adgangskoden (i hvilket tilfælde modtageren skal kende og indtaste adgangskoden)
  10. Hvis adgangskoden er en del af linket, er den i URL-hash og sendes derfor aldrig til serveren, når modtageren foretager GET-anmodningen
  11. Modtageren bliver bedt om, hvis de ønsker at dekryptere og se meddelelsen
  12. Browseren fremsætter en anmodning, der angiver besked-id'et
  13. Hvis afsenderen kræver, at en CAPTCHA udfyldes, dirigeres modtageren til en anden URL for at bevise, at de er menneskelige (når de har bestået, føres de tilbage)
  14. Serveren sender den krypterede besked og vil som standard slette beskeden på dette tidspunkt, hvis read-to-live (RTL) er en
  15. Modtageren dekrypterer meddelelsen med adgangskoden (og bliver bedt om adgangskoden, hvis den ikke findes i URL-adressen)
Denne opsætning er ekstremt enkel og tilbyder meddelelseskryptering fra afsenderens enhed til modtagerens enhed, men mangler naturligvis garantien, som asymmetrisk kryptering kan tilbyde med hensyn til kun at kende nogen, der har modtagerens private nøgle, kan dekryptere beskeden. Enhver med linket kan åbne beskeden i standardscenariet, hvorved adgangskoden er en del af URL'en - dette understreger vigtigheden af at bruge en passende transport til linket (dvs. e-mail / chat / tekst / osv.) - en beslutning overlades til afsender. Vi kan, hvis der er interesse, også udrulle support til en meget grundlæggende asymmetrisk ordning, hvor modtageren initierer en anmodning om en besked og sender anmodningslinket til afsenderen af meddelelsen. Denne opsætning eliminerer behovet for at have adgangskoden i URL'en, men eliminerer også afsenderens mulighed for at starte.

Krypteringsadgangskoden kan være i URL'en?

Ja. Dette påvirker naturligvis sikkerheden, fordi hvis metoden, der bruges til at sende linket, er usikker, er meddelelsen usikker af tilknytning. Alle løsninger til eliminering af dette problem indfører yderligere trin og kompleksiteter, der påvirker brugeroplevelsen (dvs. ting skal konfigureres i begge ender, inden meddelelsen sendes). En asymmetrisk ordning, hvor modtageren initierer en anmodning om en besked og sender anmodningslinket, kan arbejde med vores "alt er kortvarigt" nøglekrav - dette kan implementeres. I sidste ende, hvis to parter ofte sender meddelelser til hinanden, findes der bedre løsninger, forudsat at begge parter kan håndtere disse løsninger.

Men dekrypteringsadgangskoden behøver ikke at være i URL'en?

Korrekt. Hvis dekrypteringsadgangskoden ikke er inkluderet i linket, bliver modtageren bedt om adgangskoden. Hvis adgangskoden kommunikeres sikkert til modtageren (eller ved den allerede), giver dette beskyttelse mod aflytning. Ulempen er imidlertid, at modtageren skal kende og indtaste adgangskoden korrekt. Her er en måde at sende adgangskoden til modtageren, som giver en vis beskyttelse mod aflytning:

  1. Krypter adgangskoden i en meddelelse med standardindstillingerne, og send dette link til modtageren.
  2. Når modtageren klikker på linket og dekrypterer meddelelsen, ved de, at ingen andre har fået adgangskoden før dem, fordi meddelelsen, der indeholder adgangskoden, slettes ved hentning. Men hvis der er et aktivt MITM -angreb, eller hvis din enhed eller modtagerens enhed er blevet kompromitteret, er det stadig muligt, at en anden part kan få adgangskoden.
  3. Bekræft med modtageren, at de har opnået adgangskoden. For eksempel, hvis modtageren informerer dig om, at da de gik for at hente adgangskoden, at meddelelsen allerede var blevet slettet, ved du, at en anden fik adgangskoden før modtageren, og at adgangskoden derfor er kompromitteret og ikke bør bruges.
  4. Ved hjælp af den adgangskode, modtageren bekræftede, at de besidder, kan du nu sende en besked med den samme adgangskode til kryptering - bare del den version af linket, der ikke indeholder adgangskoden.

Det er korrekt - vi genererer linket og overlader det til afsenderen, hvordan det bedst kan leveres til modtageren. Målet med denne service er at give en mulighed, der tilbyder mindre varighed i eksisterende meddelelsestransporter som e-mail / chat / tekst / osv. Derfor forventes det, at det link, vi genererer, der peger på den midlertidige besked, sendes via en eksisterende meddelelsestransport. Dette har sikkerhedsimplikationer, som brugerne skal forstå. Lad os tage en SMS-besked som et eksempel, da dette er en temmelig usikker kommunikationsmetode. Når du bruger denne tjeneste til at sende et midlertidigt meddelelseslink via en tekstbesked, og hvis du bruger standardtilstand, hvor adgangskoden er inkluderet i linket, kan alle med linket læse beskeden, og der tilbydes ingen beskyttelse mod aflytning. Denne tjeneste giver stadig en mere midlertidig kommunikation, som kan forbedre privatlivets fred og sikkerhed. Derudover kan du vælge at sende linket uden adgangskoden, og dette giver beskyttelse mod aflytning.

Hvordan kan jeg beskytte mit privatliv så meget som muligt, når jeg bruger denne tjeneste?

Som diskuteret andetsteds i denne FAQ, selvom vi allerede gør meget for at beskytte dit privatliv, og selvom vi ikke indsamler nogen personlige oplysninger, indsendes og indsamles nogle logrelaterede oplysninger af os og andre i kraft af dig ved hjælp af en webbrowser. Der er dog flere måder at beskytte dit privatliv endnu mere på. En måde, der er gratis at bruge, baseret på open source-software, og som fungerer ret godt, er at bruge Tor Browser . Denne browser er designet til at beskytte dit privatliv på flere niveauer - inklusive brug af Tor-netværket . Vores websted er allerede tilgængeligt via Tor-løgnetværket, hvilket betyder at adgang til vores websted via Tor ikke kræver brug af en udgangsknude, hvilket nægter nogen, der aflytter afkørselstrafik . Husk dog, at selv i dette scenario kan din internetudbyder se, at du bruger Tor - dog ikke hvad til. Du kan endda oprette forbindelse til en VPN og derefter starte Tor Browser for to lag med anonymitet; husk dog, at din internetudbyder stadig kan se, at du bruger en VPN i dette scenarie - dog ikke hvad til. Hvis du ikke vil have din internetudbyder at vide, hvilke protokoller du bruger, kan du oprette forbindelse til et stort offentligt WiFi-netværk såsom et bibliotek, skole osv. Og derefter bruge Tor-browseren.

Hvad hvis jeg ikke stoler på USA?

Vores servere er placeret i USA. Derudover er vores CDN-udbyder, Cloudflare, en virksomhed med base i USA. Vi har forsøgt at fjerne behovet for at stole på os eller det land, hvor vores servere befinder sig, simpelthen fordi vi ikke indsamler personlige oplysninger, ikke kan dekryptere nogen meddelelser, og alt slettes kort efter det er modtaget. Vi kan dog forstå en vis mistillid, da den er webbaseret og især hvis du bor i visse lande. Vi har nogle planer om at tilbyde muligheder i Island og Schweiz for folk, der har svært ved at stole på USA. Lad os vide, hvis dette gælder for dig, da vi ikke vil være motiverede til at tilbyde alternativer, medmindre der er reel efterspørgsel.

Hvad laver du for at forhindre spam?

Når du tillader nogen at sende en besked, der kan videresendes via et link, inviterer du spammere. At begrænse dette problem er ikke helt ligetil. Vi ønsker ikke at indlæse en tredjepart CAPTCHA som en del af afsendelsesprocessen af nogle få grunde:

Vi kan muligvis komme omkring API-problemet via et API-nøglesystem, men så er vi nødt til at indsamle brugeroplysninger, som vi ikke vil gøre. Hvad skal også forhindre spammere i at få masser af API-nøgler? Vi kan ikke undersøge meddelelser for at udlede deres spaminess (hvilket i bedste fald er meget problematisk), bortset fra at kryptere meddelelserne, har vi en håndfri politik for beskedindhold. I betragtning af disse krav anvender vi to metoder til at forhindre spam: Hvis du er opmærksom på, at spammere misbruger denne service, bedes du indsende en misbrugsrapport .

Hvorfor er der en mulighed for at kræve, at modtageren udfylder en CAPTCHA?

Selvom det er sandt, at vi ikke kan lide CAPTCHA'er, erkender vi, at de tjener et formål og har en tid og et sted (i det mindste for nu). Dette er en enkel måde for afsenderen at få en vis sikkerhed for, at modtageren er menneskelig, og at automatiserede processer ikke får adgang til meddelelsen.

Hvem kører denne service, og hvorfor er den gratis?

Vi er bare et par fyre, som nogle gange stod over for vanskelighederne med ikke at have gode muligheder for at beskytte vores privatliv. Ofte skyldtes dette kommunikation med venner og familiemedlemmer, som ikke var meget forsigtige med, hvordan de håndterede deres enheder og information. Otte gange kom dette til, når du bruger webbaserede fora som Reddit eller bruger webbaserede supportsystemer. Vi fandt nogle webbaserede midlertidige meddelelsesløsninger, men ingen tilbød E2EE, hvilket betød, at vi ikke kunne stole på dem. Så vi byggede bare vores egen løsning og besluttede at give den væk, så andre kan få gavn af den.

Hvordan kan jeg stole på svarene på ovenstående spørgsmål?

Virkelig skal du ikke stole på noget websted bare fordi det siger visse ting - det er typisk en god ide at kontrollere eventuelle krav. Vi har forsøgt at fjerne kravet om at stole på os så meget som muligt ved at bruge end-to-end-kryptering. For eksempel er det ret nemt at kontrollere, at vi ikke kan læse nogen meddelelser, da de er krypterede . Vi har også holdt javascript-koden, der kører dette websted, meget enkel, så den er let at læse og forstå. At gøre al koden til open source giver folk mulighed for at kontrollere, hvad der kører; Husk dog, at der ikke er nogen måde at virkelig kontrollere, hvad serveren kører. Selv om det er rigtigt, at meget af tillidskravet fjernes med ende-til-ende-kryptering, er det stadig en faktor, som vores brugere meget vejer, når de beslutter at bruge denne tjeneste eller ej.