Veel Gestelde Vragen

Waarom is deze site slecht vertaald? ⎃

Sorry, maar de huidige auteurs spreken alleen Engels. We hebben hulp nodig bij het vertalen van dit project in andere talen. Als een eenvoudige en goedkope manier om deze service beschikbaar te maken voor mensen die geen Engels spreken, gebruiken we machinevertaling. De resultaten zijn meestal acceptabel, maar kunnen resulteren in vreemde bewoordingen of zelfs totaal onnauwkeurige informatie. U kunt ons helpen de ervaring voor iedereen te verbeteren - gelieve de juiste vertaling in te dienen .

Hoe veilig is deze dienst?

We hebben veel stappen ondernomen om deze service te beveiligen voor het beoogde gebruik . Voordat we deze stappen bespreken, is het belangrijk om het volgende te begrijpen:

Ons doel is om deze service aan te bieden op een manier die opties biedt om uw privacy en veiligheid te verbeteren. Hier zijn enkele stappen die we hebben genomen om uw gegevens te beschermen:

Waarom heb ik hier een link ontvangen met een optie om een bericht te decoderen?

Onze excuses als er fouten in deze vertaling staan . Deze service geeft eenvoudig een gecodeerd bericht door van het ene punt naar het andere en u bent de ontvanger. Het bericht wordt binnenkort verwijderd. De operators van deze service kunnen de inhoud van het bericht niet lezen. Gewoonlijk gebruikt iemand deze service wanneer ze niet willen dat de inhoud van een bericht in verschillende databases/apparaten/services/bestanden/etc blijft. zoals gebruikelijk bij het verzenden van een e-mail/instant-message/sms/etc. Als u besluit te decoderen, houd dan rekening met het volgende:

U verwijdert alles dat naar deze site is verzonden?

Trouw aan ons prullenbaklogo... alles wordt kort na ontvangst verwijderd. Het verwijderen van alles is geautomatiseerd - het wordt in de server geschreven. Zie het op deze manier - er zijn twee soorten informatie ingediend:

In het geval van berichten kunt u bepalen wanneer we ze verwijderen door op te geven: Standaard wordt alles over een bericht verwijderd nadat het eenmaal is opgehaald of 1 week oud is - wat het eerst gebeurt. Als het gaat om het verwijderen van alle andere informatie die inherent is aan het indienen van iets op internet (dwz uw IP-adres, enz.), We geven u geen controle over wanneer of hoe het wordt verwijderd - we verwijderen alles gewoon elke 24 uur .

Waarom deze dienst gebruiken?

Deze service is een hulpmiddel om berichten die u verzendt/ontvangt minder permanent te maken. Het meeste van wat u op internet communiceert (chats, sms'jes, e-mails, enz.) wordt opgeslagen en zelden verwijderd. Vaak, wanneer u iets verwijdert, wordt het niet echt verwijderd, maar gemarkeerd als verwijderd en niet langer aan u getoond. Uw totale communicatie stapelt zich jaar na jaar op in databases en op apparaten waar u geen controle over heeft. Het is onvermijdelijk dat een of meer van de organisaties/mensen/apparaten die uw communicatie opslaan, worden gehackt en dat uw informatie wordt gelekt. Dit probleem is zo wijdverbreid dat er nu veel websites zijn die de organisaties volgen die zijn gecompromitteerd en gebruikersgegevens hebben gelekt. End-to-end versleutelde tijdelijke berichten zijn een eenvoudige oplossing om sommige van uw communicatie minder permanent te maken. Elk bericht dat naar deze site wordt verzonden, heeft een levensduur van 1 minuut tot 2 weken - zodra die tijd is verstreken, wordt het bericht verwijderd. Bovendien is de standaardinstelling om elk bericht te verwijderen zodra de ontvanger het heeft opgehaald. Bovendien worden alle berichten gecodeerd vanaf uw apparaat tot aan het apparaat van de ontvanger. Het belangrijkste doel bij het gebruik van end-to-end-codering is om ons vermogen om verzonden berichten te lezen te verwijderen, waardoor een deel van de vertrouwensvereiste wordt weggenomen. Het eindresultaat is dat het nu eenvoudig is om via een simpele link een versleuteld bericht te versturen. Dat bericht wordt ofwel kort na verzending ofwel bij opvraging verwijderd. U hoeft geen speciale software te installeren/configureren. U hoeft geen account aan te maken of persoonlijke informatie op te geven. De ontvanger hoeft niet in uw contacten te staan of zelfs maar iets van deze service af te weten - de enige vereiste dat ze op een link kunnen klikken.

Is dit een berichtenservice?

Nee. Deze service is bedoeld als aanvulling op bestaande berichtenservices zoals instant messaging/e-mail/sms/enz. door de mogelijkheid toe te voegen om te voorkomen dat verzonden berichten voor een lange tijd worden opgeslagen. Wij leveren de gegenereerde link niet aan de ontvanger .

Wat zijn de beoogde use-cases?

Dus wat zijn enkele scenario's waarin het gepast is om deze service te gebruiken? Hoewel iedereen verschillende behoeften en vereisten heeft als het gaat om hun privacy en beveiliging, heb ik persoonlijk de volgende scenario's gevonden als geschikte gebruiksscenario's:

Waar mag deze dienst niet voor worden gebruikt?

Deze service mag niet worden gebruikt voor zeer gevoelige informatie om alle redenen die in deze FAQ worden uitgelegd. Hieronder vindt u enkele voorbeelden van wat u niet moet doen:

Waarom niet gewoon PGP/Signal/OMEMO/Matrix/etc. gebruiken?

Als u de persoon kent die u beveiligde tijdelijke berichten wilt verzenden, deze vaak verzendt, een chat-achtige interface verwacht en/of kunt verwachten dat de ontvanger de vereiste software heeft en weet hoe deze te gebruiken, dan is deze website waarschijnlijk niet de beste oplossing. Er zijn geweldige opties die open source zijn, E2EE ondersteunen, niet webgebaseerd, en zelfs sommige zoals Signal die ook tijdelijke berichten ondersteunen. Ik gebruik persoonlijk een privé XMMP-server en OMEMO om te chatten met goede vrienden en familie. Het gebruik van deze site kan alleen optimaal zijn als u niet weet welke software de ontvanger gebruikt, hun telefoonnummer/contactpersoon niet kent, hun technische vaardigheid niet kent (maar ervan uitgaat dat ze op een link kunnen klikken), of je houdt de boodschap die je verstuurt gewoon liever buiten het onderliggende communicatietransport.

Welke eisen zijn er?

Een moderne en up-to-date webbrowser die standaarden correct implementeert, waaronder de Web Crypto API, is vereist. Voorbeelden zijn: Chrome, Firefox, Edge en Safari (circa 2020 of later).

Kan de ontvanger een kopie van het bericht maken?

Ja. Hoewel het bericht zichzelf kan verwijderen bij het ophalen, kan de ontvanger het bericht nog steeds bekijken. Telkens wanneer de ontvanger het bericht volledig kan zien, kan een kopie worden gemaakt - dit geldt voor alle communicatie. Er is een optie om het voor de ontvanger moeilijker te maken om een kopie te maken. In dit geval worden drie belemmeringen voor het kopiëren geïmplementeerd:

Deze kopieerbeveiligingen zijn echter zwak omdat ze kunnen worden omzeild. Ook kan de ontvanger altijd gewoon een screenshot of een foto van het bericht maken.

Wordt er persoonlijke informatie verzameld?

We ondersteunen geen gebruikersaccounts (dwz gebruikersnaam/wachtwoord). We verzamelen geen informatie die u kan identificeren (dwz naam/adres/e-mail/telefoon). Het is mogelijk dat er persoonlijke informatie in het bericht staat dat u verzendt, maar dat is versleuteld en we kunnen het niet lezen. Raadpleeg ons privacybeleid voor volledige details.

Welke informatie wordt vastgelegd?

Onze webserver houdt tot 24 uur aan gemeenschappelijk logformaat bij voor alle webactiviteiten. Dit omvat het loggen van het volledige IP-adres van HTTP-clients. Na 24 uur wordt deze geregistreerde informatie automatisch verwijderd. Alle verzoeken die naar /api worden verzonden, zijn POSTed, wat betekent dat er nooit berichtspecifieke informatie wordt vastgelegd door de webserver. Bovendien wordt alle informatie die in de database is opgeslagen, effectief geregistreerd. Alle vermeldingen in de database, inclusief geanonimiseerde en gehashte IP-adressen, hebben een vervaltijd (TTL) waarna ze automatisch worden verwijderd. De TTL-verlooptijden variëren van 1 minuut tot 2 weken.

Wat doen jullie om de servers te beveiligen?

Serverbeveiliging is een voor de hand liggend probleem. Er zijn twee hoofdgebieden waarop we ons richten om het veilig te houden:

Welke veiligheidsrisico's zijn aanwezig bij het gebruik van deze site?

Alvorens specifiek in te gaan op enkele van deze risico's, denk ik dat een semi-korte analogie kan helpen om de risico's bij het gebruik van internetcommunicatie samen te vatten. Visualiseer dat elk systeem zo veilig is als de zwakste schakel in een keten. Stel je nu een scenario voor waarin twee mensen in een afgesloten ruimte zijn zonder middelen om iets te zien, te horen of op te nemen wat ze doen. De een zal een bericht doorgeven aan de ander, die het bij het lezen ervan zal verbranden. Als iemand buiten die kamer het bericht wil ontvangen dat al is doorgegeven, wordt dat moeilijk. Wat is de zwakste schakel om de boodschap te krijgen? Er zijn niet zoveel schakels om uit te kiezen - het is een vrij korte ketting. Stel je nu voor dat wanneer je een bericht op internet verzendt dat er minstens een miljoen schakels in de keten zijn - waarvan vele zwak - waarvan vele volledig buiten je controle - en dat is de realiteit.

Het gebruik van encryptie kan enorm helpen bij het bovenstaande miljoenen-linkprobleem en het is gemakkelijk om te denken dat goed ontworpen E2EE-systemen de eindoplossing bieden. Dat denken kan je echter in de problemen brengen, omdat een aanvaller meestal gewoon achter de zwakkere schakels in het systeem aan gaat. Het is bijvoorbeeld waarschijnlijk veel gemakkelijker om uw telefoon of computer over te nemen en een invoerlogboek in te stellen om alles wat u typt te lezen dan versleutelde berichten over de draad te kraken. Waar het op neerkomt, is dat als ik de taak zou krijgen om een geheim van vitaal/kritiek belang te communiceren, ik elektronische communicatie alleen als laatste redmiddel zou gebruiken.

Er zijn dus veiligheidsrisico's bij het gebruik van communicatie, maar je gebruikt nog steeds een webbrowser voor bankieren, dingen kopen, e-mailen, enz. Het is een geaccepteerd risico voor de enorme voordelen die je hebt opgedaan. De vraag is eigenlijk... welke beveiligingsrisico's zijn semi-specifiek voor deze site? Een paar komen in me op:

Wat doet u aan man-in-the-middle-aanvallen (MITM)?

Alle gebruikers van websites kunnen mogelijk het slachtoffer worden van een MITM-aanval - deze site is in dit opzicht niet anders dan alle andere op internet. Een MITM-aanval is wanneer een aanvaller de communicatie tussen de browser van de gebruiker en de webserver van de site kan onderscheppen en wijzigen. Hierdoor kan de aanvaller de code/inhoud van de site wijzigen terwijl de eindgebruiker er nog steeds uitziet als de site die hij gewend is. We nemen enkele maatregelen om een MITM-aanval moeilijker te maken:

Een MITM-aanval is echter nog steeds altijd mogelijk - vooral als de aanvaller de netwerk-/public-key-infrastructuur beheert, zoals het geval zou zijn bij grote/machtige organisaties of overheden. We bieden browserextensies die sommige MITM-risico's kunnen helpen verminderen.

Welke voordelen bieden de browserextensies?

We bieden browserextensies aan als middel om extra gemak en extra veiligheid te bieden. Simpel gezegd... De extensies maken het verzenden van tijdelijke berichten sneller en gemakkelijker. Er wordt ook enige beveiliging verkregen omdat alle code die wordt gebruikt om een bericht te coderen en voor te bereiden, lokaal in de extensie wordt opgeslagen. Doordat de code lokaal wordt opgeslagen, biedt dit de afzender enige bescherming tegen MITM-aanvallen . Het is echter de moeite waard om erop te wijzen dat hoewel de extensies meer bescherming bieden tegen een MITM-aanval die de inhoud van het bericht in gevaar brengt, een MITM-aanval nog steeds effectief kan zijn (dwz om het IP-adres van de afzender te bepalen als TOR/VPN/etc. niet wordt gebruikt).

Hoe weet ik zeker dat alles wat wordt verzonden end-to-end is versleuteld?

In tegenstelling tot veel andere populaire end-to-end gecodeerde (E2EE) chatclients, is het vrij eenvoudig om precies te zien wat er naar ons wordt verzonden wanneer u een bericht verzendt. De onderstaande video-tutorial laat zien hoe u kunt bevestigen dat we berichten die naar de server zijn verzonden, niet kunnen decoderen.

En als je erover nadenkt, zolang we geen geheime instantie zijn die gevoelige berichten probeert te verzamelen, heeft het geen voordeel voor ons om berichten te kunnen ontsleutelen, omdat het hebben van die mogelijkheid alleen maar problemen voor ons veroorzaakt. We willen zelfs geen berichten opslaan - het is echter een noodzakelijk kwaad om ze af te leveren.

Hoe werkt end-to-end encryptie op deze site?

Op dit moment gebruiken we symmetrische codering (AES-GCM 256bit) met sleutels die zijn afgeleid van wachtwoorden (minimaal 150.000 herhalingen van PBKDF2/SHA-256). Asymmetrische encryptie wordt niet gebruikt omdat er vereisten bestaan voor 1) afzender die de communicatie initieert 2) afzender en ontvanger zijn niet tegelijkertijd online en 3) geen informatie over de ontvanger en 4) we proberen de zaken heel eenvoudig te houden en sleutelbeheer is ingewikkeld. De standaard Web Crypto API wordt gebruikt voor alle cryptografische functionaliteit, inclusief RNG. Kortom, hier is wat er gebeurt:

  1. De eindgebruiker kiest een wachtwoord of er wordt automatisch een wachtwoord gegenereerd
  2. Er wordt een API-aanroep gedaan om het aantal vereiste PBKDF2/SHA-256-iteraties te verkrijgen ( deze stap is vereist voor spamcontrole)
  3. Er wordt een zout van 32 bytes gegenereerd
  4. Een sleutel is afgeleid van het zout en het wachtwoord
  5. Er wordt een initialisatievector van 12 bytes (IV) gegenereerd
  6. Het bericht wordt versleuteld met de sleutel + IV
  7. Het aantal herhalingen, salt, IV en cijfertekst worden naar de server verzonden (samen met enkele andere informatie zoals TTL, RTL, enz.)
  8. De server retourneert een willekeurige ID die verwijst naar het bericht
  9. De browser geeft de eindgebruiker vervolgens een link met de geretourneerde ID en wachtwoord of een link zonder het wachtwoord (in welk geval de ontvanger het wachtwoord moet kennen en invoeren)
  10. Als het wachtwoord deel uitmaakt van de link, staat het in de URL-hash en wordt het daarom nooit naar de server verzonden wanneer de ontvanger het GET-verzoek doet
  11. De ontvanger wordt gevraagd of ze het bericht willen decoderen en bekijken
  12. De browser doet een verzoek met vermelding van de bericht-ID
  13. Als de afzender een CAPTCHA moet invullen, wordt de ontvanger doorgestuurd naar een andere URL om te bewijzen dat ze een mens zijn (zodra ze geslaagd zijn, worden ze teruggestuurd)
  14. De server verzendt het versleutelde bericht en verwijdert het bericht standaard op dit punt als de reads-to-live (RTL) één is
  15. De ontvanger decodeert het bericht met het wachtwoord (en wordt gevraagd om het wachtwoord als dit niet in de URL staat)
Deze opzet is uiterst eenvoudig en biedt berichtversleuteling van het apparaat van de afzender naar het apparaat van de ontvanger, maar mist natuurlijk de garantie die asymmetrische versleuteling kan bieden in termen van weten dat alleen iemand die in het bezit is van de privésleutel van de ontvanger het bericht kan ontsleutelen. Iedereen met de link kan het bericht openen in het standaardscenario waarbij het wachtwoord deel uitmaakt van de URL - dit onderstreept het belang van het gebruik van een geschikt transport voor de link (dwz e-mail/chat/tekst/etc.) - een beslissing overgelaten aan de afzender. We kunnen, als er interesse is, ook ondersteuning uitrollen voor een zeer basaal asymmetrisch schema waarbij de ontvanger een verzoek om een bericht initieert en die verzoeklink naar de afzender van het bericht stuurt. Deze instelling zou de noodzaak elimineren om het wachtwoord in de URL te hebben, maar elimineert ook de mogelijkheid voor de afzender om te starten.

Het decoderingswachtwoord kan in de URL staan?

Ja. Dit heeft uiteraard gevolgen voor de beveiliging, want als de methode die wordt gebruikt om de link te verzenden, onveilig is, is het bericht onveilig door associatie. Alle tijdelijke oplossingen om dit probleem op te lossen, introduceren extra stappen en complexiteiten die van invloed zijn op de gebruikerservaring (dwz dingen moeten aan beide kanten worden ingesteld voordat het bericht wordt verzonden). Een asymmetrisch schema waarbij de ontvanger een verzoek om een bericht initieert en die verzoeklink verzendt, zou kunnen werken met onze "alles is kortstondig"-sleutelvereiste - dit kan worden geïmplementeerd. Als twee partijen elkaar regelmatig berichten gaan sturen, zijn er uiteindelijk betere oplossingen, ervan uitgaande dat beide partijen deze oplossingen aankunnen.

Maar het decoderingswachtwoord hoeft niet in de URL te staan?

Juist. Als het decoderingswachtwoord niet in de link is opgenomen, wordt de ontvanger om het wachtwoord gevraagd. Als het wachtwoord veilig aan de ontvanger wordt gecommuniceerd (of die het al weet), biedt dit bescherming tegen onderscheppen. Het nadeel is echter dat de ontvanger het wachtwoord moet kennen en correct moet invoeren. Hier is een manier om het wachtwoord naar de ontvanger te sturen die enige bescherming biedt tegen onderschepping:

  1. Versleutel het wachtwoord in een bericht met de standaardinstellingen en stuur deze link naar de ontvanger.
  2. Wanneer de ontvanger op de link klikt en het bericht decodeert, weten ze dat niemand anders het wachtwoord voor hen heeft gekregen, omdat het bericht met het wachtwoord bij het ophalen wordt verwijderd. Als er echter een actieve MITM-aanval is of als uw apparaat of het apparaat van de ontvanger is gecompromitteerd, is het nog steeds mogelijk dat een andere partij het wachtwoord kan verkrijgen.
  3. Bevestig met de ontvanger dat ze het wachtwoord met succes hebben verkregen. Als de ontvanger u bijvoorbeeld laat weten dat toen hij het wachtwoord ging ophalen, het bericht al was verwijderd, dan weet u dat iemand anders het wachtwoord eerder dan de ontvanger heeft gekregen en dat het wachtwoord daarom is gecompromitteerd en niet mag worden gebruikt.
  4. Met behulp van het wachtwoord waarvan de ontvanger heeft bevestigd dat hij het bezit, kunt u nu een bericht verzenden met hetzelfde wachtwoord voor codering - deel gewoon de versie van de link die het wachtwoord niet bevat.

Dat klopt - we genereren de link en laten het aan de afzender over hoe deze het beste bij de ontvanger kan worden afgeleverd. Het doel van deze service is om een optie te bieden die minder permanentie biedt in bestaande berichtentransporten zoals e-mail/chat/tekst/etc. De verwachting is dan ook dat de door ons gegenereerde link die verwijst naar het tijdelijke bericht via een bestaand berichtentransport wordt verzonden. Dit heeft beveiligingsimplicaties die gebruikers moeten begrijpen. Laten we als voorbeeld een sms-bericht nemen, want dit is een behoorlijk onveilige manier van communiceren. Wanneer u deze dienst gebruikt om een tijdelijke berichtlink via een SMS-bericht te verzenden, als u de standaardmodus gebruikt waarbij het wachtwoord in de link is opgenomen, kan iedereen met de link het bericht lezen en wordt er geen bescherming tegen onderschepping geboden. Deze service biedt nog steeds een meer tijdelijke communicatie die de privacy en veiligheid kan verbeteren. Bovendien kunt u ervoor kiezen om de link zonder wachtwoord te verzenden en dit biedt bescherming tegen onderschepping.

Hoe kan ik mijn privacy zo goed mogelijk beschermen tijdens het gebruik van deze dienst?

Zoals elders in deze FAQ besproken, wordt, hoewel we al veel doen om uw privacy te beschermen en hoewel we geen persoonlijke informatie verzamelen, sommige log-gerelateerde informatie door ons en anderen ingediend en verzameld op grond van het feit dat u een webbrowser gebruikt. Er zijn echter meerdere manieren om uw privacy nog beter te beschermen. Een manier die gratis te gebruiken is, gebaseerd op open source software, en vrij goed werkt, is door de Tor Browser te gebruiken . Deze browser is ontworpen om uw privacy op meerdere niveaus te beschermen, inclusief het gebruik van het Tor-netwerk . Onze site is al toegankelijk via het Tor-uiennetwerk, wat betekent dat voor toegang tot onze site via Tor geen exit-node nodig is, waardoor iemand het exit-node-verkeer niet kan afluisteren . Houd er echter rekening mee dat zelfs in dit scenario uw ISP kan zien dat u Tor gebruikt, maar niet waarvoor. U kunt zelfs verbinding maken met een VPN en vervolgens de Tor-browser starten voor twee lagen anonimiteit; Houd er echter rekening mee dat uw ISP in dit scenario nog steeds kan zien dat u een VPN gebruikt, maar niet waarvoor. Als u niet wilt dat uw ISP weet welke protocollen u gebruikt, kunt u verbinding maken met een groot openbaar WiFi-netwerk zoals een bibliotheek, school, enz. en vervolgens de Tor-browser gebruiken.

Wat als ik de Verenigde Staten niet vertrouw?

Onze servers bevinden zich in de Verenigde Staten. Bovendien is onze CDN-provider, Cloudflare, een bedrijf gevestigd in de Verenigde Staten. We hebben geprobeerd om de noodzaak om ons of het land waarin onze servers zich bevinden weg te nemen, simpelweg omdat we geen persoonlijke informatie verzamelen, geen berichten kunnen decoderen en alles wordt verwijderd kort nadat het is ontvangen. We kunnen echter enig wantrouwen begrijpen, omdat het webgebaseerd is en vooral als u in bepaalde landen woont. We hebben enkele plannen om opties aan te bieden in IJsland en Zwitserland voor mensen die de VS moeilijk kunnen vertrouwen. Laat het ons weten als dit op u van toepassing is, aangezien we niet gemotiveerd zullen zijn om alternatieven aan te bieden, tenzij er echte vraag is.

Wat doet u om spam te voorkomen?

Telkens wanneer u iemand toestaat een bericht te plaatsen dat via een link kan worden doorgegeven, nodigt u spammers uit. Dit probleem oplossen is niet helemaal eenvoudig. We willen om een aantal redenen geen CAPTCHA van derden laden als onderdeel van het proces voor het verzenden van berichten:

We zouden het API-probleem mogelijk kunnen omzeilen door een of ander API-sleutelsysteem te gebruiken, maar dan moeten we gebruikersinformatie verzamelen, wat we niet willen. En wat is om te voorkomen dat spammers veel API-sleutels krijgen? We kunnen berichten niet onderzoeken om hun spaminess af te leiden (wat op zijn best zeer problematisch is), aangezien we, behalve het versleutelen van de berichten, een hands-off beleid hebben voor de inhoud van berichten. Gezien deze vereisten gebruiken we twee methoden om spam te voorkomen: Als je weet dat spammers deze service misbruiken, dien dan een misbruikrapport in .

Waarom is er een optie om de ontvanger te verplichten een CAPTCHA in te vullen?

Hoewel het waar is dat we een hekel hebben aan CAPTCHA's, erkennen we dat ze een doel dienen en een tijd en plaats hebben (althans voorlopig). Dit is een eenvoudige manier voor de afzender om enige zekerheid te krijgen dat de ontvanger een mens is en dat geautomatiseerde processen geen toegang hebben tot het bericht.

Wie beheert deze service en waarom is deze gratis?

We zijn slechts een paar jongens die soms werden geconfronteerd met de hachelijke situatie dat ze geen goede opties hadden om onze privacy te beschermen. Vaak was dit het gevolg van communicatie met vrienden en familieleden die niet erg voorzichtig waren met hoe ze met hun apparaten en informatie omgingen. Soms gebeurde dit bij het gebruik van webgebaseerde forums zoals Reddit of het gebruik van webgebaseerde ondersteuningssystemen. We hebben enkele webgebaseerde tijdelijke berichtenoplossingen gevonden, maar geen enkele bood E2EE aan, wat betekende dat we ze niet konden vertrouwen. Dus hebben we onze eigen oplossing gebouwd en besloten deze weg te geven, zodat anderen ervan kunnen profiteren.

Hoe kan ik de antwoorden op bovenstaande vragen vertrouwen?

Eigenlijk zou u geen enkele website moeten vertrouwen alleen omdat deze bepaalde dingen zegt - het is meestal een goed idee om eventuele claims te verifiëren. We hebben geprobeerd de vereiste om ons zoveel mogelijk te vertrouwen te verwijderen door gebruik te maken van end-to-end encryptie. Het is bijvoorbeeld vrij eenvoudig te controleren dat we geen berichten kunnen lezen omdat ze versleuteld zijn . We hebben ook de javascript-code op deze site heel eenvoudig gehouden, zodat deze gemakkelijk te lezen en te begrijpen is. Door alle code open source te maken, kunnen mensen verifiëren wat er draait; Houd er echter rekening mee dat er geen manier is om echt te verifiëren wat de server draait. Hoewel het waar is dat een groot deel van de vertrouwensvereiste wordt verwijderd met end-to-end-codering, is het nog steeds een factor die onze gebruikers zwaar wegen bij de beslissing om deze service al dan niet te gebruiken.