คำถามที่พบบ่อย

เหตุใดไซต์นี้จึงแปลได้ไม่ดี ⎃

ขออภัย แต่ผู้เขียนปัจจุบันพูดได้เฉพาะภาษาอังกฤษ เราต้องการความช่วยเหลือในการแปลโครงการนี้เป็นภาษาอื่น เนื่องจากเป็นวิธีที่ง่ายและราคาไม่แพงในการทำให้บริการนี้พร้อมใช้งานสำหรับผู้ที่ไม่พูดภาษาอังกฤษ เราใช้การแปลด้วยคอมพิวเตอร์ ผลลัพธ์มักจะยอมรับได้ แต่อาจส่งผลให้ใช้ถ้อยคำแปลก ๆ หรือแม้แต่ข้อมูลที่ไม่ถูกต้องโดยสิ้นเชิง คุณสามารถช่วยเราปรับปรุงประสบการณ์สำหรับทุกคน โปรดส่งคำแปลที่ถูกต้อง

บริการนี้มีความปลอดภัยเพียงใด?

เราได้ดำเนินการหลายขั้นตอนเพื่อทำให้บริการนี้มีความปลอดภัยสำหรับ การใช้งานตามวัตถุประสงค์ ก่อนที่เราจะก้าวข้ามขั้นตอนเหล่านั้น สิ่งสำคัญคือต้องเข้าใจสิ่งต่อไปนี้:

เป้าหมายของเราคือนำเสนอบริการนี้ในลักษณะที่เสนอทางเลือกในการปรับปรุงความเป็นส่วนตัวและความปลอดภัยของคุณ ต่อไปนี้คือขั้นตอนบางส่วนที่เราได้ดำเนินการเพื่อปกป้องข้อมูลของคุณ:

เหตุใดฉันจึงได้รับลิงก์พร้อมตัวเลือกในการถอดรหัสข้อความที่นี่

ขออภัยหากมี ข้อผิดพลาดในการแปล นี้ บริการนี้เพียงแค่ส่งข้อความที่เข้ารหัสจากจุดหนึ่งไปยังอีกจุดหนึ่ง และคุณเป็นผู้รับ ข้อความจะถูกลบในไม่ช้า ผู้ให้บริการนี้ไม่สามารถอ่านเนื้อหาข้อความได้ โดยปกติมีคนใช้บริการนี้เมื่อไม่ต้องการให้เนื้อหาของข้อความยังคงอยู่ในฐานข้อมูล/อุปกรณ์/บริการ/ไฟล์/อื่นๆ ตามปกติเมื่อส่งอีเมล/ข้อความโต้ตอบแบบทันที/ข้อความ/ฯลฯ หากคุณตัดสินใจที่จะถอดรหัส โปรดคำนึงถึงสิ่งต่อไปนี้:

คุณลบทุกอย่างที่ส่งไปยังไซต์นี้หรือไม่

โลโก้ถังขยะของเราเป็นจริง... ทุกอย่างจะถูกลบทันทีที่ได้รับ การลบทุกอย่างเป็นไปโดยอัตโนมัติ - มันถูกเขียนลงในเซิร์ฟเวอร์ ลองคิดแบบนี้ - มีการส่งข้อมูลสองประเภท:

ในกรณีของข้อความ คุณสามารถควบคุมเวลาที่เราลบข้อความโดยระบุ: โดยค่าเริ่มต้น ทุกอย่างเกี่ยวกับข้อความจะถูกลบออกหลังจากที่ดึงข้อมูลมาหนึ่งครั้งหรือเก่า 1 สัปดาห์ แล้วแต่ว่าจะถึงอย่างใดก่อน เมื่อพูดถึงการลบข้อมูลอื่น ๆ ทั้งหมดที่มีอยู่ในการส่งสิ่งใด ๆ บนเว็บ (เช่นที่อยู่ IP ของคุณ ฯลฯ ) เราไม่สามารถควบคุมได้ว่าจะลบเมื่อใดหรืออย่างไร - เราเพียงแค่ลบข้อมูลทั้งหมดทุก 24 ชั่วโมง .

ทำไมต้องใช้บริการนี้?

บริการนี้เป็นเครื่องมือที่ช่วยทำให้ข้อความที่คุณส่ง/รับไม่ถาวร สิ่งที่คุณสื่อสารบนอินเทอร์เน็ตส่วนใหญ่ (แชท ข้อความ อีเมล ฯลฯ) จะถูกจัดเก็บและแทบจะไม่ถูกลบทิ้ง บ่อยครั้ง เมื่อคุณลบบางสิ่ง สิ่งนั้นจะไม่ถูกลบจริงๆ แต่จะถูกทำเครื่องหมายว่าถูกลบแล้ว และไม่แสดงให้คุณเห็นอีกต่อไป การสื่อสารโดยรวมของคุณสะสมปีแล้วปีเล่าในฐานข้อมูลและบนอุปกรณ์ที่คุณควบคุมไม่ได้ องค์กร/บุคคล/อุปกรณ์อย่างน้อยหนึ่งองค์กรที่จัดเก็บการสื่อสารของคุณถูกแฮ็กและข้อมูลของคุณรั่วไหลอย่างหลีกเลี่ยงไม่ได้ ปัญหานี้แพร่หลายมากจนขณะนี้มีเว็บไซต์จำนวนมากที่ติดตามองค์กรที่ถูกบุกรุกและรั่วไหลข้อมูลผู้ใช้ ข้อความชั่วคราวที่เข้ารหัสแบบ end-to-end เป็นวิธีแก้ปัญหาง่ายๆ ที่จะช่วยให้การสื่อสารบางส่วนของคุณไม่ถาวร ทุกข้อความที่ส่งมายังไซต์นี้มีระยะเวลาในการแสดงสดตั้งแต่ 1 นาทีถึง 2 สัปดาห์ - เมื่อพ้นเวลาดังกล่าวแล้ว ข้อความจะถูกลบ นอกจากนี้ การตั้งค่าเริ่มต้นคือการลบข้อความใดๆ เมื่อผู้รับได้รับข้อความแล้ว นอกจากนี้ ข้อความทั้งหมดจะถูกเข้ารหัสจากอุปกรณ์ของคุณไปจนถึงอุปกรณ์ของผู้รับ เป้าหมายหลักในการใช้การเข้ารหัสแบบ end-to-end คือการลบความสามารถของเราในการอ่านข้อความที่ส่งเข้ามา ซึ่งจะทำให้ข้อกำหนดความน่าเชื่อถือบางส่วนหายไป ผลลัพธ์ที่ได้คือขณะนี้ง่ายต่อการส่งข้อความที่เข้ารหัสผ่านลิงก์ง่ายๆ ข้อความนั้นจะถูกลบออกไม่นานหลังจากส่งหรือเมื่อมีการดึงข้อมูล คุณไม่จำเป็นต้องติดตั้ง/กำหนดค่าซอฟต์แวร์พิเศษ คุณไม่จำเป็นต้องสร้างบัญชีหรือให้ข้อมูลส่วนบุคคลใดๆ ผู้รับไม่จำเป็นต้องอยู่ในรายชื่อติดต่อของคุณหรือแม้กระทั่งรู้เกี่ยวกับบริการนี้ - ข้อกำหนดเพียงอย่างเดียวที่พวกเขาสามารถคลิกลิงก์ได้

นี่คือบริการส่งข้อความใช่หรือไม่

ไม่ บริการนี้ออกแบบมาเพื่อเสริมบริการส่งข้อความที่มีอยู่ เช่น การส่งข้อความโต้ตอบแบบทันที/อีเมล/ข้อความ/ฯลฯ โดยเพิ่มความสามารถในการป้องกันไม่ให้ข้อความที่ส่งถูกเก็บไว้เป็นเวลานาน เราไม่ส่งลิงค์ที่สร้างขึ้นไปยังผู้รับ

กรณีการใช้งานที่ตั้งใจไว้คืออะไร?

แล้วสถานการณ์ใดที่เหมาะสมที่จะใช้บริการนี้ แม้ว่าทุกคนจะมีความต้องการและข้อกำหนดที่แตกต่างกันในเรื่องความเป็นส่วนตัวและความปลอดภัย แต่โดยส่วนตัวแล้วฉันพบว่าสถานการณ์ต่อไปนี้เป็นกรณีการใช้งานที่เหมาะสม:

ไม่ควรใช้บริการนี้เพื่ออะไร?

ไม่ควรใช้บริการนี้สำหรับข้อมูลที่ละเอียดอ่อนมาก ด้วยเหตุผลทั้งหมดที่อธิบายไว้ในคำถามที่พบบ่อยนี้ ด้านล่างนี้คือตัวอย่างบางส่วนของสิ่งที่ไม่ควรทำ:

ทำไมไม่ใช้ PGP/Signal/OMEMO/Matrix/etc.?

หากคุณรู้จักคนที่คุณต้องการส่งข้อความชั่วคราวที่ปลอดภัย ส่งบ่อยๆ คาดว่าจะมีอินเทอร์เฟซเหมือนแชท และ/หรือคาดหวังให้ผู้รับมีซอฟต์แวร์ที่จำเป็นและรู้วิธีใช้งาน เว็บไซต์นี้อาจไม่ใช่ ทางออกที่ดีที่สุด มีตัวเลือกที่ดีมากมายที่เป็นโอเพ่นซอร์ส รองรับ E2EE ไม่ใช่บนเว็บ และแม้กระทั่งบางตัวเช่น Signal ที่รองรับข้อความชั่วคราวด้วย ฉันใช้ เซิร์ฟเวอร์ XMMP ส่วนตัวและ OMEMO เพื่อแชทกับเพื่อนสนิทและครอบครัว การใช้ไซต์นี้อาจเหมาะสมที่สุดก็ต่อเมื่อคุณไม่ทราบว่าผู้รับใช้ซอฟต์แวร์ใด ไม่ทราบหมายเลขโทรศัพท์/ที่ติดต่อ ไม่ทราบความสามารถทางเทคนิค (แต่ถือว่าสามารถคลิกลิงก์ได้) หรือคุณเพียงต้องการเก็บข้อความที่คุณส่งไปนอกระบบสื่อสารพื้นฐาน

มีข้อกำหนดอะไรบ้าง?

จำเป็นต้องมีเว็บเบราว์เซอร์ที่ทันสมัยและทันสมัยซึ่งนำมาตรฐานไปใช้อย่างเหมาะสมรวมถึง Web Crypto API ตัวอย่าง ได้แก่ Chrome, Firefox, Edge และ Safari (ประมาณปี 2020 หรือหลังจากนั้น)

ผู้รับสามารถทำสำเนาข้อความได้หรือไม่

ใช่. แม้ว่าข้อความอาจลบตัวเองเมื่อดึงข้อมูล ผู้รับยังสามารถดูข้อความได้ ทุกครั้งที่ผู้รับสามารถดูข้อความได้อย่างสมบูรณ์ สามารถทำสำเนาได้ ซึ่งมีผลกับการสื่อสารทั้งหมด มีตัวเลือกในการทำให้ผู้รับทำสำเนาได้ยากขึ้น ในกรณีนี้มีการดำเนินการอุปสรรคสามประการในการคัดลอก:

อย่างไรก็ตาม การป้องกันการคัดลอกเหล่านี้ไม่มีประสิทธิภาพ เนื่องจากสามารถข้ามได้ นอกจากนี้ ผู้รับยังสามารถถ่ายภาพหน้าจอหรือภาพถ่ายของข้อความได้ตลอดเวลา

มีการเก็บรวบรวมข้อมูลส่วนบุคคลใด ๆ หรือไม่?

เราไม่สนับสนุนบัญชีผู้ใช้ (เช่น ชื่อผู้ใช้/รหัสผ่าน) เราไม่รวบรวมข้อมูลใดๆ ที่สามารถระบุตัวคุณได้ (เช่น ชื่อ/ที่อยู่/อีเมล/โทรศัพท์) เป็นไปได้ว่าข้อมูลส่วนบุคคลบางอย่างอาจอยู่ในข้อความที่คุณกำลังส่ง แต่ข้อมูลนั้นถูกเข้ารหัสและเราไม่มีทางอ่านมันได้ โปรดตรวจสอบ นโยบายความเป็นส่วนตัว ของเราสำหรับรายละเอียดทั้งหมด

ข้อมูลอะไรถูกบันทึกไว้?

เว็บเซิร์ฟเวอร์ของเรามี รูปแบบบันทึกทั่วไป สูงสุด 24 ชั่วโมงสำหรับกิจกรรมบนเว็บทั้งหมด ซึ่งรวมถึงการบันทึกที่อยู่ IP แบบเต็มของไคลเอ็นต์ HTTP หลังจาก 24 ชั่วโมง ข้อมูลที่บันทึกไว้นี้จะถูกลบโดยอัตโนมัติ คำขอทั้งหมดที่ส่งไปยัง /api นั้นถูกโพสต์แล้ว หมายความว่าเว็บเซิร์ฟเวอร์ไม่เคยบันทึกข้อมูลเฉพาะของข้อความ นอกจากนี้ ข้อมูลใดๆ ที่บันทึกไว้ในฐานข้อมูลจะถูกบันทึกอย่างมีประสิทธิภาพ รายการทั้งหมดในฐานข้อมูล รวมถึงที่อยู่ IP ที่ไม่ระบุชื่อและแฮช มีเวลาหมดอายุ (TTL) หลังจากนั้นจะถูกลบออกโดยอัตโนมัติ เวลาหมดอายุ TTL จะแตกต่างกันไประหว่าง 1 นาทีถึง 2 สัปดาห์

คุณกำลังทำอะไรเพื่อรักษาความปลอดภัยเซิร์ฟเวอร์?

ความปลอดภัยของเซิร์ฟเวอร์เป็นปัญหาที่ชัดเจน มีสองประเด็นหลักที่เรามุ่งเน้นในการรักษาความปลอดภัย:

มีความเสี่ยงด้านความปลอดภัยอะไรบ้างเมื่อใช้ไซต์นี้

ก่อนที่จะระบุความเสี่ยงเหล่านี้โดยเฉพาะ ฉันคิดว่าการเปรียบเทียบแบบสั้นอาจช่วยสรุปความเสี่ยงในการใช้การสื่อสารทางอินเทอร์เน็ตได้ นึกภาพว่าระบบใดๆ ก็ตามปลอดภัยพอๆ กับจุดอ่อนที่สุดในห่วงโซ่ ตอนนี้ลองนึกภาพสถานการณ์ที่มีคนสองคนอยู่ในห้องที่ปิดสนิทโดยที่ไม่มีทางมองเห็น ได้ยิน หรือบันทึกสิ่งที่พวกเขาทำ หนึ่งจะส่งข้อความไปยังอีกคนหนึ่งซึ่งเมื่ออ่านข้อความจะเขียนมัน ถ้ามีคนนอกห้องนั้นต้องการได้รับข้อความที่ผ่านไปแล้ว มันคงเป็นเรื่องยาก ลิงก์ที่อ่อนแอที่สุดในการรับข้อความคืออะไร มีลิงค์ให้เลือกไม่มากนัก - เป็นสายสั้นสวย ลองนึกภาพว่าเมื่อคุณส่งข้อความบนอินเทอร์เน็ตว่ามีลิงก์อย่างน้อยหนึ่งล้านลิงก์ในสายโซ่ - หลายลิงก์อ่อนแอ - หลายลิงก์อยู่นอกเหนือการควบคุมของคุณ - และนั่นคือความเป็นจริง

การใช้การเข้ารหัสสามารถช่วยแก้ไขปัญหาลิงก์กว่าล้านลิงก์ได้อย่างมาก และง่ายต่อการถูกหลอกให้คิดว่าระบบ E2EE ที่ออกแบบมาอย่างดีนำเสนอโซลูชันแบบครบวงจร อย่างไรก็ตาม ความคิดนั้นสามารถทำให้คุณมีปัญหาได้ เนื่องจากผู้โจมตีมักจะไล่ตามลิงก์ที่อ่อนแอกว่าในระบบ ตัวอย่างเช่น อาจง่ายกว่ามากที่จะยึดโทรศัพท์หรือคอมพิวเตอร์ของคุณและตั้งค่าตัวบันทึกอินพุตเพื่ออ่านทุกสิ่งที่คุณพิมพ์มากกว่าการถอดรหัสข้อความที่เข้ารหัสผ่านสาย สิ่งสำคัญที่สุดคือถ้าฉันได้รับมอบหมายให้สื่อสารความลับที่มีความสำคัญ/สำคัญยิ่ง ฉันจะใช้การสื่อสารทางอิเล็กทรอนิกส์เป็นวิธีสุดท้ายเท่านั้น

ดังนั้นการใช้การสื่อสารจึงมีความเสี่ยงด้านความปลอดภัย แต่คุณยังคงใช้เว็บเบราว์เซอร์สำหรับการธนาคาร การซื้อของ อีเมล ฯลฯ ถือเป็นความเสี่ยงที่ยอมรับได้สำหรับความสะดวกมากมายที่ได้รับ จริงๆ แล้วคำถามคือ... ความเสี่ยงด้านความปลอดภัยใดที่มีลักษณะกึ่งเฉพาะสำหรับไซต์นี้ นึกถึงสองสาม:

คุณกำลังทำอะไรเกี่ยวกับการโจมตีแบบ man-in-the-middle (MITM)

ผู้ใช้เว็บไซต์ทั้งหมดอาจตกเป็นเหยื่อของการโจมตี MITM ได้ - ไซต์นี้ไม่แตกต่างจากเว็บไซต์อื่นๆ ในเรื่องนี้ การ โจมตีแบบ MITM คือเมื่อผู้โจมตีสามารถสกัดกั้นและแก้ไขการสื่อสารระหว่างเบราว์เซอร์ของผู้ใช้และเว็บเซิร์ฟเวอร์ของไซต์ ซึ่งช่วยให้ผู้โจมตีสามารถแก้ไขโค้ด/เนื้อหาของไซต์ได้ในขณะที่ยังคงปรากฏต่อผู้ใช้ปลายทางว่าเป็นไซต์ที่พวกเขาคุ้นเคย เราใช้มาตรการบางอย่างเพื่อทำให้การโจมตี MITM ยากขึ้น:

อย่างไรก็ตาม การโจมตีแบบ MITM ยังคงเป็นไปได้เสมอ โดยเฉพาะอย่างยิ่งหากผู้โจมตีควบคุมโครงสร้างพื้นฐานของเครือข่าย/คีย์สาธารณะ เช่นเดียวกับองค์กรขนาดใหญ่/ทรงพลังหรือรัฐบาล เราเสนอ ส่วนขยายเบราว์เซอร์ ซึ่งสามารถช่วยลดความเสี่ยงของ MITM บางอย่างได้

ส่วนขยายเบราว์เซอร์มีข้อดีอะไรบ้าง?

เราเสนอส่วนขยายเบราว์เซอร์ เพื่อเพิ่มความสะดวกและความปลอดภัยเพิ่มเติม พูดง่ายๆ... ส่วนขยายทำให้การส่งข้อความชั่วคราวทำได้เร็วและง่ายขึ้น การรักษาความปลอดภัยบางอย่างยังได้รับเนื่องจากรหัสทั้งหมดที่ใช้ในการเข้ารหัสและเตรียมข้อความจะถูกจัดเก็บไว้ในส่วนขยาย เนื่องจากรหัสถูกเก็บไว้ในเครื่อง จึงให้การป้องกัน การโจมตี MITM แก่ผู้ส่ง อย่างไรก็ตาม ควรสังเกตว่าในขณะที่ส่วนขยายให้การป้องกันการโจมตี MITM ที่กระทบต่อเนื้อหาข้อความมากขึ้น การโจมตี MITM ก็อาจยังมีประสิทธิภาพ (เช่น เพื่อระบุที่อยู่ IP ของผู้ส่ง หากไม่ได้ใช้ TOR/VPN/อื่นๆ)

ฉันจะทราบได้อย่างไรว่าสิ่งที่ส่งมานั้นได้รับการเข้ารหัสตั้งแต่ต้นทางถึงปลายทาง

แตกต่างจากไคลเอนต์แชทเข้ารหัสแบบ end-to-end (E2EE) ยอดนิยมอื่น ๆ ค่อนข้างง่ายที่จะดูว่าอะไรที่ส่งถึงเราเมื่อคุณส่งข้อความ วิดีโอกวดวิชาด้านล่างสาธิตวิธีการยืนยันว่าเราไม่มีวิธีถอดรหัสข้อความที่ส่งไปยังเซิร์ฟเวอร์

นอกจากนี้ หากคุณคิดเกี่ยวกับมัน ตราบใดที่เราไม่ใช่หน่วยงานลับที่พยายามรวบรวมข้อความที่ละเอียดอ่อน ก็ไม่มีประโยชน์ที่เราจะสามารถถอดรหัสข้อความได้ เนื่องจากความสามารถนั้นสร้างปัญหาให้กับเราเท่านั้น เราไม่ต้องการเก็บข้อความไว้ด้วยซ้ำ อย่างไรก็ตาม การส่งมันเป็นสิ่งที่ชั่วร้าย

การเข้ารหัสแบบ end-to-end ทำงานอย่างไรบนไซต์นี้

ในขณะนี้ เราใช้การเข้ารหัสแบบสมมาตร (AES-GCM 256 บิต) กับคีย์ที่ได้มาจากรหัสผ่าน (อย่างน้อย 150,000 ครั้งของ PBKDF2/SHA-256) การเข้ารหัสแบบอสมมาตรไม่ได้ใช้เนื่องจากมีข้อกำหนดสำหรับ 1) ผู้ส่งที่เริ่มต้นการสื่อสาร 2) ผู้ส่งและผู้รับไม่ได้ออนไลน์ในเวลาเดียวกัน และ 3) ไม่มีข้อมูลเกี่ยวกับผู้รับ และ 4) เรากำลังพยายามทำให้สิ่งต่าง ๆ เรียบง่ายและการจัดการคีย์นั้นเรียบง่าย ซับซ้อน. Web Crypto API มาตรฐานใช้สำหรับฟังก์ชันการเข้ารหัสทั้งหมดรวมถึง RNG โดยทั่วไปนี่คือสิ่งที่เกิดขึ้น:

  1. ผู้ใช้ปลายทางเลือกรหัสผ่านหรือรหัสผ่านถูกสร้างขึ้นโดยอัตโนมัติ
  2. มีการเรียก API เพื่อรับจำนวนการทำซ้ำ PBKDF2/SHA-256 ที่จำเป็น ( ขั้นตอนนี้จำเป็นสำหรับการควบคุมสแปม )
  3. สร้าง เกลือ ขนาด 32 ไบต์
  4. กุญแจได้มาจากเกลือและรหัสผ่าน
  5. สร้างเวคเตอร์การเริ่มต้น (IV) ขนาด 12 ไบต์
  6. ข้อความถูกเข้ารหัสโดยใช้คีย์ + IV
  7. จำนวนการวนซ้ำ, เกลือ, IV และข้อความเข้ารหัสจะถูกส่งไปยังเซิร์ฟเวอร์ (พร้อมกับข้อมูลอื่นๆ เช่น TTL, RTL เป็นต้น)
  8. เซิร์ฟเวอร์ส่งคืน ID แบบสุ่มที่อ้างถึงข้อความ
  9. จากนั้นเบราว์เซอร์จะแสดงลิงก์ที่ มี ID และรหัสผ่านที่ส่งคืนให้ กับผู้ใช้ปลายทางหรือ ลิงก์ที่ไม่มีรหัสผ่าน (ซึ่งในกรณีนี้ผู้รับจะต้องรู้และป้อนรหัสผ่าน)
  10. หากรหัสผ่านเป็นส่วนหนึ่งของลิงก์ แสดงว่าอยู่ใน URL hash ดังนั้นจะไม่ส่งไปยังเซิร์ฟเวอร์เมื่อผู้รับส่งคำขอ GET
  11. ผู้รับจะได้รับแจ้งหากต้องการถอดรหัสและดูข้อความ
  12. เบราว์เซอร์ส่งคำขอโดยระบุ ID ข้อความ
  13. หากผู้ส่งกำหนดให้กรอก CAPTCHA ผู้รับจะถูกนำไปยัง URL อื่นเพื่อพิสูจน์ว่าพวกเขาเป็นมนุษย์ (เมื่อส่งแล้วจะถูกส่งกลับ)
  14. เซิร์ฟเวอร์ส่งข้อความที่เข้ารหัสและโดยค่าเริ่มต้นจะลบข้อความ ณ จุดนี้หากการอ่านเพื่อถ่ายทอดสด (RTL) เป็นหนึ่ง
  15. ผู้รับจะถอดรหัสข้อความด้วยรหัสผ่าน (และจะได้รับแจ้งให้ใส่รหัสผ่านหากไม่ได้อยู่ใน URL)
การตั้งค่านี้ง่ายมากและมีการเข้ารหัสข้อความจากอุปกรณ์ของผู้ส่งไปยังอุปกรณ์ของผู้รับ แต่แน่นอนว่าไม่มีการรับประกันว่าการเข้ารหัสแบบอสมมาตรสามารถเสนอได้ในแง่ของการรู้ว่ามีเพียงผู้ที่มีคีย์ส่วนตัวของผู้รับเท่านั้นที่สามารถถอดรหัสข้อความได้ ทุกคนที่มีลิงก์สามารถเปิดข้อความในสถานการณ์เริ่มต้นโดยที่รหัสผ่านเป็นส่วนหนึ่งของ URL ซึ่งเน้นย้ำถึงความสำคัญของการใช้การขนส่งที่เหมาะสมสำหรับลิงก์ (เช่น อีเมล/แชท/ข้อความ/อื่นๆ) - การตัดสินใจที่เหลือ ผู้ส่ง. หากมีความสนใจ เราอาจเปิดตัวการสนับสนุนสำหรับรูปแบบที่ไม่สมมาตรพื้นฐาน โดยที่ผู้รับเริ่มต้นคำขอข้อความและส่งลิงก์คำขอนั้นไปยังผู้ส่งข้อความ การตั้งค่านี้จะขจัดความจำเป็นในการมีรหัสผ่านใน URL แต่ยังขจัดความสามารถสำหรับผู้ส่งในการเริ่มต้น

รหัสผ่านถอดรหัสสามารถอยู่ใน URL?

ใช่. สิ่งนี้ส่งผลกระทบต่อความปลอดภัยอย่างเห็นได้ชัด เพราะหากวิธีการที่ใช้ส่งลิงก์นั้นไม่ปลอดภัย แสดงว่าข้อความนั้นไม่ปลอดภัยโดยการเชื่อมโยง วิธีแก้ไขปัญหาชั่วคราวทั้งหมดเพื่อขจัดปัญหานี้จะแนะนำขั้นตอนและความซับซ้อนเพิ่มเติมซึ่งส่งผลต่อประสบการณ์ของผู้ใช้ (เช่น สิ่งต่างๆ จะต้องได้รับการตั้งค่าที่ปลายทั้งสองด้านก่อนที่จะส่งข้อความ) รูปแบบที่ไม่สมมาตรซึ่งผู้รับเริ่มต้นคำขอข้อความและส่งลิงก์คำขอนั้นสามารถทำงานกับข้อกำหนดคีย์ "ทุกอย่างเป็นข้อมูลชั่วคราว" ของเรา - อาจถูกนำไปใช้ ในท้ายที่สุด หากทั้งสองฝ่ายจะส่งข้อความถึงกันบ่อยๆ วิธีแก้ปัญหาที่ดีกว่ามีอยู่ โดยสมมติว่าทั้งสองฝ่ายสามารถจัดการโดยใช้โซลูชันเหล่านั้นได้

แต่รหัสผ่านถอดรหัสไม่จำเป็นต้องอยู่ใน URL?

ถูกต้อง. ถ้ารหัสผ่านถอดรหัสไม่รวมอยู่ในลิงค์ ผู้รับจะได้รับพร้อมท์ให้ใส่รหัสผ่าน หากรหัสผ่านได้รับการสื่อสารอย่างปลอดภัยไปยังผู้รับ (หรือพวกเขารู้อยู่แล้ว) จะเป็นการป้องกันการสกัดกั้น อย่างไรก็ตาม ข้อเสียคือ ผู้รับต้องรู้และป้อนรหัสผ่านให้ถูกต้อง นี่เป็นวิธีหนึ่งในการส่งรหัสผ่านไปยังผู้รับซึ่งมีการป้องกันการสกัดกั้น:

  1. เข้ารหัสรหัสผ่านในข้อความด้วยการตั้งค่าเริ่มต้นและส่งลิงก์นี้ไปยังผู้รับ
  2. เมื่อผู้รับคลิกลิงก์และถอดรหัสข้อความ พวกเขารู้ว่าไม่มีใครได้รับรหัสผ่านมาก่อนเพราะข้อความที่มีรหัสผ่านจะถูกลบออกเมื่อดึงข้อมูล อย่างไรก็ตาม หากมีการ โจมตี MITM ที่ ใช้งานอยู่ หรือหากอุปกรณ์ของคุณหรืออุปกรณ์ของผู้รับถูกบุกรุก ก็มีความเป็นไปได้ที่บุคคลอื่นสามารถรับรหัสผ่านได้
  3. ยืนยันกับผู้รับว่าพวกเขาได้รับรหัสผ่านสำเร็จแล้ว ตัวอย่างเช่น ถ้าผู้รับแจ้งคุณว่าเมื่อพวกเขาไปดึงรหัสผ่าน ข้อความนั้นถูกลบไปแล้ว คุณก็รู้ว่ามีคนอื่นได้รับรหัสผ่านก่อนผู้รับ และรหัสผ่านจึงถูกบุกรุกและไม่ควรใช้
  4. เมื่อใช้รหัสผ่านที่ผู้รับยืนยันว่ามี คุณสามารถส่งข้อความโดยใช้รหัสผ่านเดียวกันสำหรับการเข้ารหัสได้ เพียงแชร์เวอร์ชันของลิงก์ที่ไม่มีรหัสผ่าน

ถูกต้อง - เราสร้างลิงก์และปล่อยให้ผู้ส่งส่งถึงผู้รับได้ดีที่สุด เป้าหมายของบริการนี้คือเพื่อให้ตัวเลือกที่มีความคงทนน้อยลงในการส่งข้อความที่มีอยู่ เช่น อีเมล/แชท/ข้อความ/ฯลฯ ดังนั้น ความคาดหวังก็คือลิงก์ที่เราสร้างซึ่งชี้ไปยังข้อความชั่วคราวจะถูกส่งผ่านการส่งข้อความที่มีอยู่ สิ่งนี้มีนัยด้านความปลอดภัยที่ผู้ใช้ควรเข้าใจ ลองใช้ข้อความ SMS เป็นตัวอย่าง เนื่องจากเป็นวิธีการสื่อสารที่ค่อนข้างไม่ปลอดภัย เมื่อคุณใช้บริการนี้เพื่อส่งลิงก์ข้อความชั่วคราวผ่านข้อความ หากคุณใช้โหมดเริ่มต้นซึ่งรวมรหัสผ่านไว้ในลิงก์ ทุกคนที่มีลิงก์จะสามารถอ่านข้อความได้และไม่มีการป้องกันการสกัดกั้น บริการนี้ยังคงมีการสื่อสารชั่วคราวซึ่งสามารถปรับปรุงความเป็นส่วนตัวและความปลอดภัยได้ นอกจากนี้ คุณอาจเลือกที่จะส่งลิงก์โดยไม่มีรหัสผ่าน ซึ่งจะช่วยป้องกันการสกัดกั้น

ฉันจะปกป้องความเป็นส่วนตัวให้มากที่สุดในขณะที่ใช้บริการนี้ได้อย่างไร

ดังที่ได้กล่าวไว้ในที่อื่นในคำถามที่พบบ่อยนี้ แม้ว่าเราจะทำ สิ่งต่างๆ มากมายเพื่อปกป้องความเป็นส่วนตัวของคุณ และแม้ว่าเราจะไม่ได้รวบรวมข้อมูลส่วนบุคคลใด ๆ แต่ข้อมูล ที่เกี่ยวข้องกับบันทึก บางอย่างก็ส่งและรวบรวมโดยเราและผู้อื่นโดยอาศัยคุณจากการใช้เว็บเบราว์เซอร์ อย่างไรก็ตาม มีหลายวิธีในการปกป้องความเป็นส่วนตัวของคุณมากยิ่งขึ้น วิธีหนึ่งที่ใช้งานได้ฟรี โดยอิงจากซอฟต์แวร์โอเพ่นซอร์ส และใช้งานได้ค่อนข้างดีคือการใช้ Tor Browser เบราว์เซอร์นี้ออกแบบมาเพื่อปกป้องความเป็นส่วนตัวของคุณในหลายระดับ รวมถึงการใช้ เครือข่าย Tor ไซต์ของเราสามารถเข้าถึงได้ผ่านเครือข่าย Tor onion ซึ่งหมายความว่าการเข้าถึงไซต์ของเราผ่าน Tor ไม่จำเป็นต้องใช้โหนดทางออก ซึ่งขัดขวางไม่ให้ผู้อื่น แอบฟังการเข้าชมโหนดทางออก อย่างไรก็ตาม โปรดทราบว่าแม้ในสถานการณ์นี้ ISP ของคุณสามารถเห็นได้ว่าคุณกำลังใช้ Tor แม้ว่าจะไม่ใช่เพื่ออะไรก็ตาม คุณยังสามารถเชื่อมต่อกับ VPN แล้วเปิดใช้ Tor Browser สำหรับการปกปิดตัวตนสองชั้น; อย่างไรก็ตาม โปรดทราบว่า ISP ของคุณยังคงเห็นว่าคุณกำลังใช้ VPN ในสถานการณ์นี้ แม้ว่าจะไม่ใช่เพื่ออะไรก็ตาม หากคุณไม่ต้องการให้ ISP รู้ว่าคุณใช้โปรโตคอลใดอยู่ คุณสามารถเชื่อมต่อกับเครือข่าย WiFi สาธารณะขนาดใหญ่ เช่น ห้องสมุด โรงเรียน ฯลฯ แล้วใช้เบราว์เซอร์ของ Tor

จะเกิดอะไรขึ้นหากฉันไม่ไว้วางใจสหรัฐอเมริกา

เซิร์ฟเวอร์ของเราตั้งอยู่ในสหรัฐอเมริกา นอกจากนี้ Cloudflare ผู้ให้บริการ CDN ของเราเป็นบริษัทที่ตั้งอยู่ในสหรัฐอเมริกา เราได้พยายามขจัดความจำเป็นในการไว้วางใจเราหรือประเทศที่เซิร์ฟเวอร์ของเราอาศัยอยู่ เพียงเพราะเราไม่ได้รวบรวมข้อมูลส่วนบุคคล ไม่สามารถถอดรหัสข้อความใด ๆ และทุกอย่างจะถูกลบทันทีที่ได้รับ อย่างไรก็ตาม เราสามารถเข้าใจความไม่ไว้วางใจบางอย่างได้ เนื่องจากเป็นเว็บและโดยเฉพาะอย่างยิ่งหากคุณอาศัยอยู่ในบางประเทศ เรามีแผนที่จะเสนอทางเลือกในไอซ์แลนด์และสวิตเซอร์แลนด์สำหรับผู้ที่มีปัญหาในการไว้วางใจสหรัฐฯ โปรดแจ้งให้เราทราบ หากสิ่งนี้ตรงกับคุณ เนื่องจากเราจะไม่มีแรงจูงใจที่จะเสนอทางเลือกอื่นเว้นแต่จะมีความต้องการจริง

คุณกำลังทำอะไรเพื่อป้องกันสแปม?

ทุกครั้งที่คุณอนุญาตให้ผู้อื่นโพสต์ข้อความที่สามารถส่งต่อผ่านลิงก์ได้ เท่ากับว่าคุณเชิญผู้ส่งอีเมลขยะ การจัดการปัญหานี้ไม่ได้ตรงไปตรงมาโดยสิ้นเชิง เราไม่ต้องการโหลด CAPTCHA บุคคลที่สามซึ่งเป็นส่วนหนึ่งของกระบวนการส่งข้อความด้วยเหตุผลบางประการ:

เราอาจแก้ปัญหา API ได้โดยใช้ระบบคีย์ API แต่เราต้องรวบรวมข้อมูลผู้ใช้ที่เราไม่ต้องการทำ นอกจากนี้ อะไรจะหยุดนักส่งสแปมไม่ให้ได้รับคีย์ API จำนวนมาก เราไม่สามารถตรวจสอบข้อความเพื่อสรุปว่าเป็นสแปมได้ (ซึ่งเป็นปัญหามากที่สุด) เนื่องจากนอกจากการเข้ารหัสข้อความแล้ว เรามีนโยบายเฉพาะสำหรับเนื้อหาข้อความ จากข้อกำหนดเหล่านี้ เราใช้สองวิธีในการป้องกันสแปม: หากคุณทราบว่านักส่งสแปมกำลังใช้บริการนี้ในทางที่ผิด โปรดยื่นรายงานการละเมิด

เหตุใดจึงมีตัวเลือกให้ผู้รับต้องกรอก CAPTCHA

แม้ว่าจะเป็นความจริงที่เราไม่ชอบ CAPTCHA แต่เราตระหนักดีว่าสิ่งเหล่านี้มีจุดมุ่งหมายและมีเวลาและสถานที่ (อย่างน้อยก็ในตอนนี้) นี่เป็นวิธีง่ายๆ สำหรับผู้ส่งเพื่อให้ได้รับความมั่นใจว่าผู้รับเป็นมนุษย์ และกระบวนการอัตโนมัติไม่สามารถเข้าถึงข้อความได้

ใครเป็นผู้ใช้บริการนี้และเหตุใดจึงให้บริการฟรี

เราเป็นแค่ผู้ชายสองสามคนที่ต้องเผชิญกับสถานการณ์ที่ไม่มีทางเลือกที่ดีในบางครั้งเพื่อช่วยปกป้องความเป็นส่วนตัวของเรา บ่อยครั้งสิ่งนี้เกิดจากการสื่อสารกับเพื่อนและสมาชิกในครอบครัวที่ไม่ระมัดระวังในการจัดการอุปกรณ์และข้อมูลของพวกเขา บางครั้งสิ่งนี้เกิดขึ้นเมื่อใช้ฟอรัมบนเว็บเช่น Reddit หรือใช้ระบบสนับสนุนบนเว็บ เราพบวิธีแก้ปัญหาข้อความชั่วคราวบนเว็บ แต่ไม่มี E2EE เสนอ ซึ่งหมายความว่าเราไม่สามารถเชื่อถือพวกเขาได้ ดังนั้นเราจึงสร้างโซลูชันของเราเองและตัดสินใจแจกให้ผู้อื่นได้ประโยชน์จากมัน

ฉันจะเชื่อถือคำตอบของคำถามข้างต้นได้อย่างไร

จริงๆ แล้ว คุณไม่ควรเชื่อถือเว็บไซต์ใด ๆ เพียงเพราะมันพูดบางอย่าง โดยทั่วไปแล้ว คุณควรตรวจสอบการอ้างสิทธิ์ เราได้พยายามลบข้อกำหนดในการไว้วางใจเราให้มากที่สุดโดยใช้การเข้ารหัสแบบ end-to-end ตัวอย่างเช่น การ ตรวจสอบค่อนข้างง่ายว่าเราไม่สามารถอ่านข้อความใด ๆ ได้เนื่องจากมีการเข้ารหัส เรายังได้เก็บ โค้ดจาวาสคริปต์ที่ใช้งานไซต์นี้ไว้ อย่างเรียบง่ายเพื่อให้อ่านและเข้าใจได้ง่าย การทำให้โค้ดทั้งหมดเป็นโอเพนซอร์สช่วยให้ผู้คนตรวจสอบสิ่งที่กำลังทำงานอยู่ได้ อย่างไรก็ตาม โปรดทราบว่าไม่มีทางที่จะตรวจสอบสิ่งที่เซิร์ฟเวอร์กำลังทำงานอยู่ได้อย่างแท้จริง แม้ว่าความต้องการความน่าเชื่อถือส่วนใหญ่จะถูกลบออกด้วยการเข้ารหัสแบบ end-to-end แต่ก็ยังเป็นปัจจัยที่ผู้ใช้ของเรามีน้ำหนักมากเมื่อตัดสินใจใช้บริการนี้หรือไม่