ofte stilte spørsmål

Hvorfor er dette nettstedet dårlig oversatt? ⎃

Beklager, men de nåværende forfatterne snakker bare engelsk. Vi trenger hjelp til å oversette dette prosjektet til andre språk. Som et enkelt og billig middel for å gjøre denne tjenesten tilgjengelig for folk som ikke snakker engelsk, bruker vi maskinoversettelse. Resultatene er vanligvis akseptable, men kan føre til merkelig ordlyd eller til og med fullstendig unøyaktig informasjon. Du kan hjelpe oss med å forbedre opplevelsen for alle - vennligst send inn riktig oversettelse .

Hvor sikker er denne tjenesten?

Vi har tatt mange skritt for å gjøre denne tjenesten sikker for den tiltenkte bruken . Før vi går over disse trinnene, er det viktig å forstå følgende:

Vårt mål er å tilby denne tjenesten på en måte som tilbyr alternativer for å forbedre personvernet og sikkerheten din. Her er noen skritt vi har tatt for å beskytte informasjonen din:

Hvorfor fikk jeg en lenke her med et alternativ til å dekryptere en melding?

Vi beklager hvis det er feil i denne oversettelsen . Denne tjenesten sender ganske enkelt en kryptert melding fra et punkt til et annet, og du er mottaker. Meldingen blir snart slettet. Operatørene av denne tjenesten har ingen måte å lese meldingsinnholdet. Vanligvis bruker noen denne tjenesten når de ikke vil at innholdet i en melding skal forbli i forskjellige databaser / enheter / tjenester / filer / osv. som er typisk når du sender en e-post / direktemelding / tekst / etc. Hvis du bestemmer deg for å dekryptere, må du huske følgende:

Du sletter alt som sendes inn på dette nettstedet?

I samsvar med papirkurven vår logo ... alt blir slettet kort tid etter mottak. Slette alt blir automatisert - det skrives inn på serveren. Tenk på det slik - det er to klasser av informasjon som sendes inn:

Når det gjelder meldinger, kan du kontrollere når vi sletter dem ved å spesifisere: Som standard slettes alt om en melding etter at den er hentet en gang eller er 1 uke gammel - avhengig av hva som skjer først. Når det gjelder å slette all annen informasjon som ligger i å sende inn noe på nettet (f.eks. IP-adressen din osv.), Gir vi deg ikke noen kontroll over når eller hvordan den slettes - vi sletter bare alt dette hver 24. time .

Hvorfor bruke denne tjenesten?

Denne tjenesten er et verktøy for å gjøre meldinger du sender / mottar mindre permanente. Det meste av det du kommuniserer på Internett (chatter, tekster, e-post osv.) Lagres og blir sjelden slettet. Ofte, når du sletter noe, blir det faktisk ikke slettet, men heller merket som slettet og ikke lenger vist for deg. Den samlede kommunikasjonen din akkumuleres år etter år i databaser og på enheter du ikke har kontroll over. Uunngåelig blir en eller flere av organisasjonene / personene / enhetene som lagrer kommunikasjonen din hacket og informasjonen din lekker. Dette problemet er så gjennomgripende at det nå er mange nettsteder som sporer organisasjonene som har blitt kompromittert og lekket brukerdata. End-to-end krypterte midlertidige meldinger er en enkel løsning for å gjøre noe av kommunikasjonen mindre permanent. Hver melding som sendes til dette nettstedet har en levetid fra 1 minutt til 2 uker - når den tiden har gått, blir meldingen slettet. Videre er standardinnstillingen å slette en melding når mottakeren har hentet den. I tillegg er alle meldingene kryptert fra enheten din helt til mottakerens enhet. Hovedmålet med å bruke end-to-end-kryptering er å fjerne vår evne til å lese eventuelle innsendte meldinger og dermed fjerne noe av tillitskravet. Sluttresultatet er at det nå er enkelt å sende en kryptert melding via en enkel lenke. Denne meldingen blir slettet kort tid etter sending eller etter henting. Du trenger ikke å installere / konfigurere spesiell programvare. Du trenger ikke opprette en konto eller oppgi personlig informasjon. Mottakeren trenger ikke å være i kontaktene dine eller til og med vite om denne tjenesten - det eneste kravet om at de kan klikke på en lenke.

Er dette en meldingstjeneste?

Nei. Denne tjenesten er designet for å utfylle eksisterende meldingstjenester som direktemeldinger / e-post / tekst / etc. ved å legge til muligheten for å forhindre at sendte meldinger lagres i lang tid. Vi leverer ikke den genererte lenken til mottakeren .

Hva er de tiltenkte brukssakene?

Så hva er noen scenarier der det er hensiktsmessig å bruke denne tjenesten? Mens alle har forskjellige behov og krav når det gjelder deres personvern og sikkerhet, har jeg personlig funnet følgende scenarier som hensiktsmessige bruksområder:

Hva skal denne tjenesten ikke brukes til?

Denne tjenesten skal ikke brukes til veldig sensitiv informasjon av alle grunnene som er forklart i denne vanlige FAQ. Nedenfor er noen eksempler på hva du ikke skal gjøre:

Hvorfor ikke bare bruke PGP / Signal / OMEMO / Matrix / etc.?

Hvis du kjenner personen du vil sende sikre midlertidige meldinger, sender dem ofte, forventer et chattelignende grensesnitt og / eller kan forvente at mottakeren har den nødvendige programvaren og vet hvordan du bruker den, er dette nettstedet sannsynligvis ikke beste løsningen. Det er gode alternativer der ute som er åpen kildekode, støtter E2EE, ikke nettbasert, og til og med noen som Signal som også støtter midlertidige meldinger. Jeg personlig bruker en privat XMMP-server og OMEMO for å chatte med nære venner og familie. Å bruke dette nettstedet kan bare være optimalt hvis du ikke vet hvilken programvare mottakeren kjører, ikke kjenner telefonnummeret / kontakthåndtaket, ikke kjenner deres tekniske ferdigheter (men antar at de kan klikke på en lenke), eller du foretrekker bare å holde meldingen du sender utenfor den underliggende kommunikasjonstransporten.

Hvilke krav eksisterer?

Det kreves en moderne og oppdatert nettleser som implementerer standarder inkludert Web Crypto API. Eksempler inkluderer: Chrome, Firefox, Edge og Safari (ca. 2020 eller senere).

Kan mottakeren lage en kopi av meldingen?

Ja. Selv om meldingen kan slette seg selv etter henting, kan mottakeren fortsatt se meldingen. Hver gang mottakeren kan se meldingen helt, kan det lages en kopi - dette gjelder all kommunikasjon. Det er et alternativ for å gjøre det vanskeligere for mottakeren å lage en kopi. I dette tilfellet implementeres tre hindringer for kopiering:

Disse kopibeskyttelsene er imidlertid svake fordi de kan omgåes. Dessuten kan mottakeren alltid bare ta et skjermbilde eller et bilde av meldingen.

Samles det inn personlig informasjon?

Vi støtter ikke brukerkontoer (dvs. brukernavn / passord). Vi samler ikke inn noen informasjon som kan identifisere deg (dvs. navn / adresse / e-post / telefon). Det er mulig at noen personlige opplysninger kan være i meldingen du sender, men den er kryptert, og vi har ingen måte å lese den på. Les personvernreglene for fullstendige detaljer.

Hvilken informasjon logges?

Vår webserver holder opptil 24 timer med vanlig loggformat på all webaktivitet. Dette inkluderer å logge hele IP-adressen til HTTP-klienter. Etter 24 timer slettes denne loggede informasjonen automatisk. Alle forespørsler sendt til / api er POSTED, noe som betyr at ingen meldingsspesifikk informasjon blir logget av webserveren. I tillegg logges all informasjon som er lagret i databasen effektivt. Alle oppføringer i databasen, inkludert anonymiserte og hashede IP-adresser, har en utløpstid (TTL), hvoretter de automatisk slettes. TTL-utløpstidene varierer mellom 1 minutt og 2 uker.

Hva gjør du for å sikre serverne?

Serversikkerhet er en åpenbar bekymring. Det er to hovedområder vi fokuserer på for å sikre det:

Hvilke sikkerhetsrisikoer er det når du bruker dette nettstedet?

Før jeg spesifikt tar for meg noen av disse risikoene, tror jeg en semi-kort analogi kan bidra til å oppsummere risikoen ved bruk av internettkommunikasjon. Visualiser at ethvert system bare er like sikkert som det svakeste leddet i en kjede. Tenk deg nå et scenario der det er to personer i et lukket rom uten midler til å se, høre eller registrere noe de gjør. Den ene vil sende en melding til den andre som ved å lese meldingen vil brenne den. Hvis noen utenfor det rommet ønsker å få beskjeden som allerede ble sendt, blir det vanskelig. Hva er den svakeste lenken for å få tak i meldingen? Det er ikke så mange lenker å velge mellom - det er en ganske kort kjede. Tenk deg nå at når du sender en melding på Internett om at det er minst en million lenker i kjeden - mange av dem svake - mange av dem helt utenfor din kontroll - og det er virkeligheten.

Bruk av kryptering kan i stor grad hjelpe med de ovennevnte millionkoblingsproblemet, og det er lett å lokke til å tro at veldesignede E2EE-systemer tilbyr den endelige løsningen. Imidlertid kan denne tankegangen få deg i trøbbel, fordi en angriper vanligvis bare følger de svakere koblingene i systemet. For eksempel er det sannsynligvis langt lettere å ta over telefonen eller datamaskinen og sette opp en inngangslogger for å bare lese alt du skriver enn å knekke krypterte meldinger over ledningen. Poenget er at hvis jeg fikk i oppgave å kommunisere en hemmelighet av vital / kritisk betydning, ville jeg bare bruke elektronisk kommunikasjon som en siste utvei.

Så det er sikkerhetsrisiko ved bruk av kommunikasjon, men du bruker fortsatt en nettleser til bank, kjøp av ting, e-post osv. Det er en akseptert risiko for de enorme bekvemmelighetene du har fått. Egentlig spørsmålet er ... hvilke sikkerhetsrisikoer er semi-spesifikke for dette nettstedet? Noen få kommer til å tenke:

Hva gjør du med mann-i-midten-angrep (MITM)?

Alle brukere av nettsteder kan potensielt bli utsatt for et MITM-angrep - dette nettstedet er ikke annerledes enn alle de andre på nettet i denne forbindelse. Et MITM-angrep er når en angriper er i stand til å fange opp og modifisere kommunikasjon mellom brukerens nettleser og nettstedets webserver. Dette gjør det mulig for angriperen å endre hvilken som helst av nettstedets kode / innhold mens den fremdeles ser ut til sluttbrukeren å være nettstedet de er vant til. Vi tar noen tiltak for å gjøre et MITM-angrep vanskeligere:

Imidlertid er et MITM-angrep fremdeles alltid mulig - spesielt hvis angriperen kontrollerer nettverks- / offentlig nøkkelinfrastruktur slik det ville være tilfelle for store / mektige organisasjoner eller regjeringer. Vi tilbyr nettleserutvidelser som kan bidra til å redusere noen MITM-risikoer.

Hvilke fordeler tilbyr nettleserutvidelsene?

Vi tilbyr nettleserutvidelser som et middel for å gi ekstra bekvemmelighet og ekstra sikkerhet. Enkelt sagt ... Utvidelsene gjør det enklere å sende midlertidige meldinger. Noe sikkerhet oppnås også fordi all kode som brukes til å kryptere og forberede en melding, er lagret lokalt i utvidelsen. Fordi koden er lagret lokalt, gir dette avsenderen en viss beskyttelse mot MITM-angrep . Det er imidlertid verdt å påpeke at mens utvidelsene gir mer beskyttelse mot et MITM-angrep som kompromitterer innholdet i meldingen, kan et MITM-angrep fremdeles være effektivt (dvs. å bestemme avsenderens IP-adresse hvis den ikke bruker TOR / VPN / osv.).

Hvordan kan jeg vite med sikkerhet at alt som sendes er kryptert fra ende til annen?

I motsetning til mange andre populære end-to-end-krypterte (E2EE) chat-klienter, er det ganske enkelt å se nøyaktig hva som blir sendt til oss når du sender en melding. Videoveiledningen nedenfor viser hvordan du kan bekrefte at vi ikke har noen måte å dekryptere meldinger sendt til serveren.

Også, hvis du tenker på det, så lenge vi ikke er noe hemmelig byrå som prøver å samle inn sensitive meldinger, er det ingen fordel for oss å kunne dekryptere meldinger, siden å ha den muligheten bare skaper problemer for oss. Vi ønsker ikke engang å lagre meldinger - det er imidlertid et nødvendig onde å levere dem.

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

På dette tidspunktet bruker vi symmetrisk kryptering (AES-GCM 256bit) med nøkler hentet fra passord (minimum 150 000 gjentakelser av PBKDF2 / SHA-256). Asymmetrisk kryptering brukes ikke fordi det foreligger krav til 1) avsender som initierer kommunikasjonen 2) avsender og mottaker ikke er online samtidig og 3) ingen informasjon om mottakeren og 4) vi prøver å holde ting virkelig enkle og nøkkeladministrasjon er komplisert. Standard Web Crypto API brukes til all kryptografisk funksjonalitet inkludert RNG. I utgangspunktet er det som skjer:

  1. Sluttbrukeren velger et passord, eller et er automatisk generert
  2. Det blir foretatt et API-anrop for å oppnå antallet nødvendige PBKDF2 / SHA-256-iterasjoner ( dette trinnet er nødvendig for spam-kontroll )
  3. Det genereres et 32 byte salt
  4. En nøkkel er hentet fra salt og passord
  5. En 12 byte initialiseringsvektor (IV) genereres
  6. Meldingen krypteres ved hjelp av nøkkelen + IV
  7. Iterasjonstall, salt, IV og krypteringstekst blir sendt til serveren (sammen med litt annen informasjon som TTL, RTL, etc.)
  8. Serveren returnerer en tilfeldig ID som refererer til meldingen
  9. Nettleseren presenterer deretter sluttbrukeren med en lenke som inneholder den returnerte ID-en og passordet eller en lenke uten passordet (i så fall må mottakeren vite og oppgi passordet)
  10. Hvis passordet er en del av lenken, er det i URL-hash , og blir derfor aldri sendt til serveren når mottakeren gjør GET-forespørselen
  11. Mottakeren blir bedt om de ønsker å dekryptere og vise meldingen
  12. Nettleseren sender en forespørsel om spesifisering av meldings-ID
  13. Hvis avsenderen krever at CAPTCHA er fullført, blir mottakeren sendt til en annen URL for å bevise at de er menneskelige (når de har bestått, blir de sendt tilbake)
  14. Serveren sender den krypterte meldingen og vil som standard slette meldingen på dette punktet hvis read-to-live (RTL) er en
  15. Mottakeren vil dekryptere meldingen med passordet (og blir bedt om passordet hvis det ikke er i URL-en)
Dette oppsettet er ekstremt enkelt, og tilbyr meldingskryptering fra avsenderens enhet til mottakerens enhet, men mangler selvfølgelig garantien som asymmetrisk kryptering kan tilby når det gjelder å vite bare noen som har mottakerens private nøkkel, kan dekryptere meldingen. Alle med lenken kan åpne meldingen i standardscenariet der passordet er en del av URL-en - dette understreker viktigheten av å bruke en passende transport for lenken (dvs. e-post / chat / tekst / osv.) - en avgjørelse overlatt til avsender. Vi kan, hvis det er interesse, også rulle ut støtte for en veldig grunnleggende asymmetrisk ordning hvor mottakeren initierer en forespørsel om en melding og sender den forespørselskoblingen til avsenderen av meldingen. Dette oppsettet vil eliminere behovet for å ha passordet i URL-en, men eliminerer også muligheten for avsenderen til å starte.

Krypteringspassordet kan være i URL-en?

Ja. Dette påvirker åpenbart sikkerheten, for hvis metoden som brukes til å sende lenken er usikker, er meldingen usikker av tilknytning. Alle løsninger for å eliminere dette problemet introduserer flere trinn og kompleksiteter som påvirker brukeropplevelsen (dvs. at ting må konfigureres i begge ender før du sender meldingen). En asymmetrisk ordning der mottakeren starter en forespørsel om en melding og sender den forespørselskoblingen, kan fungere med vårt "alt er kortvarig" nøkkelkrav - dette kan implementeres. Til slutt, hvis to parter skal sende meldinger til hverandre ofte, eksisterer det bedre løsninger forutsatt at begge parter kan håndtere bruk av disse løsningene.

Men dekrypteringspassordet trenger ikke å være i URL -adressen?

Riktig. Hvis dekrypteringspassordet ikke er inkludert i lenken, blir mottakeren bedt om å angi passordet. Hvis passordet er sikkert kommunisert til mottakeren (eller de allerede vet det), gir dette beskyttelse mot avskjæring. Imidlertid er ulempen at mottakeren må vite og skrive inn passordet riktig. Her er en måte å sende passordet til mottakeren som gir en viss beskyttelse mot avlytting:

  1. Krypter passordet i en melding med standardinnstillingene og send denne lenken til mottakeren.
  2. Når mottakeren klikker på lenken og dekrypterer meldingen, vet de at ingen andre har fått passordet før dem fordi meldingen som inneholder passordet blir slettet ved hentning. Men hvis det er et aktivt MITM -angrep eller hvis enheten eller mottakerens enhet er blitt kompromittert, er det fortsatt mulig at en annen part kan få passordet.
  3. Bekreft med mottakeren at de har fått passordet. For eksempel, hvis mottakeren informerer deg om at når de gikk for å hente passordet, at meldingen allerede var slettet, vet du at noen andre fikk passordet før mottakeren, og at passordet derfor er kompromittert og ikke bør brukes.
  4. Ved å bruke passordet mottakeren bekreftet at de har, kan du nå sende en melding med det samme passordet for kryptering - bare del versjonen av lenken som ikke inneholder passordet.

Det er riktig - vi genererer lenken og overlater det til avsenderen hvordan man best kan levere den til mottakeren. Målet med denne tjenesten er å tilby et alternativ som gir mindre varighet i eksisterende meldingstransporter som e-post / chat / tekst / etc. Derfor er forventningen at lenken vi genererer som peker på den midlertidige meldingen, sendes via en eksisterende meldingstransport. Dette har sikkerhetsmessige implikasjoner som brukerne bør forstå. La oss ta en SMS-tekstmelding som et eksempel, siden dette er en ganske usikker kommunikasjonsmetode. Når du bruker denne tjenesten til å sende en midlertidig meldingskobling via en tekstmelding, hvis du bruker standardmodus der passordet er inkludert i lenken, kan alle med lenken lese meldingen og ingen beskyttelse mot avlytting tilbys. Denne tjenesten gir fortsatt en mer midlertidig kommunikasjon som kan forbedre personvernet og sikkerheten. I tillegg kan du velge å sende lenken uten passordet, og dette vil gi beskyttelse mot avskjæring.

Hvordan kan jeg beskytte personvernet mitt så mye som mulig når jeg bruker denne tjenesten?

Som diskutert andre steder i denne FAQ, selv om vi allerede gjør mye for å beskytte personvernet ditt, og selv om vi ikke samler inn personlig informasjon, blir noen loggrelatert informasjon sendt inn og samlet inn av oss og andre i kraft av deg ved hjelp av en nettleser. Det er imidlertid flere måter å beskytte personvernet ditt enda mer på. En måte som er gratis å bruke, basert på programvare med åpen kildekode, og som fungerer ganske bra, er å bruke Tor Browser . Denne nettleseren er designet for å beskytte personvernet ditt på flere nivåer - inkludert bruk av Tor-nettverket . Nettstedet vårt er allerede tilgjengelig via Tor-løkenettverket, noe som betyr at tilgang til nettstedet vårt via Tor ikke krever bruk av en utgangsnode, noe som tilsier at noen avlytter trafikk på utgangsnoden . Husk imidlertid at selv i dette scenariet kan Internett-leverandøren din se at du bruker Tor - men ikke til hva. Du kan til og med koble til et VPN og deretter starte Tor Browser for to lag med anonymitet; Vær imidlertid oppmerksom på at Internett-leverandøren din fremdeles kan se at du bruker en VPN i dette scenariet - men ikke til hva. Hvis du ikke vil at Internett-leverandøren din skal vite hvilke protokoller du bruker, kan du koble til et stort offentlig WiFi-nettverk som et bibliotek, skole osv. Og deretter bruke Tor-nettleseren.

Hva om jeg ikke stoler på USA?

Serverne våre er lokalisert i USA. I tillegg er vår CDN-leverandør, Cloudflare, et selskap basert i USA. Vi har forsøkt å fjerne behovet for å stole på oss eller landet der serverne våre bor, bare fordi vi ikke samler inn personlig informasjon, ikke kan dekryptere noen meldinger, og alt blir slettet kort tid etter at det er mottatt. Vi kan imidlertid forstå noe mistillit siden det er nettbasert, og spesielt hvis du bor i visse land. Vi har noen planer om å tilby opsjoner på Island og Sveits for folk som har vanskelig for å stole på USA. Gi oss beskjed hvis dette gjelder deg, siden vi ikke vil være motivert til å tilby alternativer med mindre det er reell etterspørsel.

Hva gjør du for å forhindre spam?

Når du tillater noen å legge ut en melding som kan videreformidles via en lenke, inviterer du spammere. Å dempe dette problemet er ikke helt greit. Vi ønsker ikke å laste inn en tredjepart CAPTCHA som en del av prosessen for sending av meldinger av noen grunner:

Vi kan muligens komme oss rundt API-problemet ved å bruke et API-nøkkelsystem, men da må vi samle brukerinformasjon som vi ikke vil gjøre. Hva er også for å hindre at spammere får mange API-nøkler? Vi kan ikke undersøke meldinger for å utlede deres spam (som i beste fall er veldig problematisk), bortsett fra å kryptere meldingene, har vi en hands-off-policy for meldingsinnhold. Gitt disse kravene bruker vi to metoder for å forhindre spam: Hvis du er klar over at spammere misbruker denne tjenesten, kan du sende inn en misbruksrapport .

Hvorfor er det et alternativ å kreve at mottakeren fullfører en CAPTCHA?

Selv om det er sant at vi ikke liker CAPTCHA, anerkjenner vi at de tjener et formål og har en tid og et sted (i hvert fall foreløpig). Dette er en enkel måte for avsenderen å få viss forsikring om at mottakeren er menneskelig og at automatiserte prosesser ikke får tilgang til meldingen.

Hvem kjører denne tjenesten, og hvorfor er den gratis?

Vi er bare et par gutter som noen ganger sto overfor vanskeligheter med å ikke ha gode muligheter for å beskytte personvernet vårt. Ofte skyldes dette kommunikasjon med venner og familiemedlemmer som ikke er veldig forsiktige med hvordan de håndterte enhetene og informasjonen deres. Andre ganger kom dette til når du bruker nettbaserte fora som Reddit eller bruker nettbaserte støttesystemer. Vi fant noen nettbaserte midlertidige meldingsløsninger, men ingen tilbød E2EE, noe som betydde at vi ikke kunne stole på dem. Så vi bygde bare vår egen løsning og bestemte oss for å gi den bort slik at andre kan dra nytte av den.

Hvordan kan jeg stole på svarene på spørsmålene ovenfor?

Du burde egentlig ikke stole på noe nettsted bare fordi det sier visse ting - det er vanligvis en god ide å verifisere eventuelle krav. Vi har prøvd å fjerne kravet om å stole på oss så mye som mulig via å bruke end-to-end-kryptering. For eksempel er det ganske enkelt å revidere at vi ikke kan lese noen meldinger siden de er kryptert . Vi har også holdt javascript-koden som kjører dette nettstedet veldig enkel, slik at den er lett å lese og forstå. Å gjøre all koden åpen kildekode lar folk kontrollere hva som kjører; Vær imidlertid oppmerksom på at det ikke er noen måte å virkelig kontrollere hva serveren kjører. Selv om det er sant at mye av tillitskravet fjernes med end-to-end-kryptering, er det fortsatt en faktor som brukerne våre veier mye når de bestemmer seg for å bruke denne tjenesten eller ikke.