שאלות נפוצות

מדוע אתר זה מתורגם בצורה גרועה?

מצטער, אבל המחברים הנוכחיים דוברים אנגלית בלבד. אנו זקוקים לעזרה בתרגום פרויקט זה לשפות אחרות. כאמצעי פשוט וזול להנגשת שירות זה לאנשים שאינם דוברי אנגלית, אנו משתמשים בתרגום מכונה. התוצאות בדרך כלל קבילות, אך עלולות לגרום לניסוח מוזר או אפילו למידע לא מדויק לחלוטין. אתה יכול לעזור לנו לשפר את החוויה לכולם - אנא שלח את התרגום הנכון .

עד כמה שירות זה מאובטח?

נקטנו צעדים רבים בכדי להבטיח שירות זה לשימושו המיועד . לפני שנעבור על השלבים האלה, חשוב להבין את הדברים הבאים:

מטרתנו היא להציע שירות זה באופן המציע אפשרויות לשיפור פרטיותך וביטחונך. להלן מספר צעדים שעשינו כדי לשמור על המידע שלך:

מדוע קיבלתי כאן קישור עם אפשרות לפענוח הודעה?

אנו מתנצלים אם ישנן טעויות בתרגום זה . שירות זה פשוט מעביר הודעה מוצפנת מנקודה אחת לאחרת ואתה הנמען. ההודעה תימחק בקרוב. למפעילי שירות זה אין דרך לקרוא את תוכן ההודעה. בדרך כלל מישהו משתמש בשירות זה כאשר הוא לא רוצה שתוכן ההודעה יישאר בתוך מאגרי מידע / מכשירים / שירותים / קבצים / וכו '. כמקובל בשליחת דוא"ל / הודעה מיידית / טקסט / וכו '. אם תחליט לפענח, זכור את הדברים הבאים:

האם למחוק את כל מה שנשלח לאתר זה?

נכון ללוגו של פח האשפה שלנו ... הכל נמחק זמן קצר לאחר קבלתו. מחיקת הכל היא אוטומטית - היא נכתבת לשרת. תחשוב על זה ככה - יש שני סוגים של מידע שהוגש:

במקרה של הודעות, תוכל לשלוט מתי אנו מוחקים אותן על ידי ציון: כברירת מחדל, כל מה שקשור להודעה נמחק לאחר שאוחזר פעם אחת או בן שבוע - מה שקורה הראשון. כשמדובר במחיקת כל המידע האחר הטמון בהגשת כל דבר באינטרנט (כלומר כתובת ה- IP שלך וכו '), איננו נותנים לך שום שליטה על מתי או כיצד הוא נמחק - אנחנו פשוט מוחקים את זה כל 24 שעות. .

מדוע להשתמש בשירות זה?

שירות זה הוא כלי המסייע בהפיכת הודעות שאתה שולח / מקבל פחות קבועות. רוב הדברים שאתה מתקשר באינטרנט (צ'אטים, טקסטים, מיילים וכו ') נשמרים ונמחקים לעיתים נדירות. לעתים קרובות, כאשר אתה מוחק משהו, זה לא באמת נמחק אלא מסומן כמוחק וכבר לא מוצג לך. התקשורת המצטברת שלך מצטברת שנה אחר שנה במאגרי מידע ובמכשירים שאין לך שליטה עליהם. באופן בלתי נמנע, אחד או יותר מהארגונים / אנשים / מכשירים השומרים את התקשורת שלך נפרצים והמידע שלך דולף. בעיה זו כה מקיפה עד כי ישנם כיום אתרי אינטרנט רבים העוקבים אחר הארגונים שנפגעו והדלפו נתוני משתמשים. הודעות זמניות מוצפנות מקצה לקצה הן פיתרון פשוט שיעזור להפוך חלק מהתקשורת שלך לקבועה פחות. לכל הודעה המוגשת לאתר זה יש זמן לחיות שנע בין דקה לשבועיים - לאחר שחלף הזמן ההודעה נמחקת. יתר על כן, הגדרת ברירת המחדל היא מחיקת כל הודעה לאחר שהמקבל אחזר אותה. בנוסף, כל ההודעות מוצפנות מהמכשיר שלך עד למכשיר הנמען. המטרה העיקרית בשימוש בהצפנה מקצה לקצה היא להסיר את היכולת שלנו לקרוא הודעות שהוגשו ובכך להסיר חלק מדרישת האמון. התוצאה הסופית היא שכעת קל לשלוח הודעה מוצפנת באמצעות קישור פשוט. הודעה זו נמחקת זמן קצר לאחר השליחה או עם האחזור. אינך צריך להתקין / להגדיר תוכנה מיוחדת. אינך צריך ליצור חשבון או לספק מידע אישי כלשהו. הנמען לא צריך להיות באנשי הקשר שלך או אפילו לדעת על שירות זה - הדרישה היחידה שהם יכולים ללחוץ על קישור.

האם מדובר בשירות העברת הודעות?

לא. שירות זה נועד להשלים שירותי העברת הודעות קיימים כמו מסרים מיידיים / דוא"ל / טקסט / וכו '. על ידי הוספת היכולת למנוע שמירת הודעות שנשלחו לאורך זמן. איננו מעבירים את הקישור שנוצר למקבל .

מהם מקרי השימוש המיועדים?

אז מהם כמה תרחישים שבהם ראוי להשתמש בשירות זה? בעוד שלכל אחד יש צרכים ודרישות שונות בכל הנוגע לפרטיותם וביטחונם, באופן אישי מצאתי את התרחישים הבאים כמקרי שימוש מתאימים:

לשם מה אסור להשתמש בשירות זה?

אין להשתמש בשירות זה למידע רגיש מאוד מכל הסיבות המובאות בשאלות נפוצות אלו. להלן מספר דוגמאות למה לא לעשות:

מדוע לא להשתמש רק ב- PGP / Signal / OMEMO / Matrix / etc.?

אם אתה מכיר את האדם שאתה רוצה לשלוח הודעות זמניות מאובטחות, שלח אותם לעיתים קרובות, מצפה לממשק דמוי צ'אט ו / או שאתה יכול לצפות שהנמען יהיה בעל התוכנה הנדרשת וידע להשתמש בו, אתר אינטרנט זה הוא כנראה לא הפיתרון הכי טוב. ישנן אפשרויות נהדרות שם בחוץ שהן קוד פתוח, תומכות ב- E2EE, לא מבוססות אינטרנט, ואפילו כמה כמו Signal שתומכות גם בהודעות זמניות. אני אישית משתמש בשרת XMMP פרטי וב- OMEMO כדי לשוחח עם חברים קרובים ומשפחה. השימוש באתר זה עשוי להיות אופטימלי רק אם אינך יודע איזו תוכנה פועל הנמען, אינך יודע את מספר הטלפון / ידית הקשר שלו, אינך יודע את בקיאותו הטכנית (אך נניח שהוא יכול ללחוץ על קישור), או שאתה פשוט מעדיף לשמור את ההודעה שאתה שולח מחוץ לתעבורת התקשורת הבסיסית.

אילו דרישות קיימות?

נדרש דפדפן אינטרנט מודרני ועדכני המיישם כראוי סטנדרטים כולל ה- Web Crypto API. דוגמאות כוללות: Chrome, Firefox, Edge ו- Safari (בערך 2020 ואחרי).

האם הנמען יכול ליצור עותק של ההודעה?

כן. למרות שההודעה עשויה למחוק את עצמה לאחר האחזור, הנמען עדיין יכול להציג את ההודעה. בכל פעם שהמקלט יכול להציג את ההודעה לחלוטין, ניתן ליצור העתק - זה חל על כל התקשורת. יש אפשרות להקשות על המקבל ביצירת עותק. במקרה זה מיושמים שלוש מכשולים להעתקה:

עם זאת, הגנות ההעתקה הללו חלשות מכיוון שניתן לעקוף אותן. כמו כן, הנמען יכול תמיד פשוט לצלם צילום מסך או תמונה של ההודעה.

האם נאסף מידע אישי כלשהו?

איננו תומכים בחשבונות משתמש (כלומר שם משתמש / סיסמה). אנו לא אוספים שום מידע שיוכל לזהות אותך (כלומר שם / כתובת / דוא"ל / טלפון). יתכן ומידע אישי כלשהו יכול להיות בהודעה שאתה שולח, אך הוא מוצפן ואין לנו שום דרך לקרוא אותו. אנא עיין במדיניות הפרטיות שלנו לקבלת פרטים מלאים.

איזה מידע נרשם?

שרת האינטרנט שלנו שומר על עד 24 שעות של פורמט יומן נפוץ בכל פעילות האינטרנט. זה כולל רישום כתובת ה- IP המלאה של לקוחות HTTP. לאחר 24 שעות, מידע רשום זה נמחק באופן אוטומטי. כל הבקשות שנשלחות אל / api מתפרסמות, כלומר שום מידע ספציפי להודעות לא נרשם מעולם על ידי שרת האינטרנט. בנוסף, כל המידע שנשמר במסד הנתונים נרשם למעשה. לכל הערכים במסד הנתונים, כולל כתובות IP אנונימיות ו hashed, יש זמן תפוגה (TTL) שלאחריו הם נמחקים אוטומטית. זמני התפוגה של TTL משתנים בין דקה לשבועיים.

מה אתה עושה כדי לאבטח את השרתים?

אבטחת שרתים היא עניין מובהק. ישנם שני תחומים עיקריים שאנו מתמקדים בהם בכדי לשמור על אבטחתה:

אילו סיכוני אבטחה קיימים בעת השימוש באתר זה?

לפני שהתייחסתי ספציפית לחלק מהסיכונים הללו, אני חושב שאנלוגיה קצרה למחצה עשויה לעזור לסיכום הסיכונים בשימוש בכל תקשורת אינטרנט. דמיין כי כל מערכת מאובטחת רק כמו החוליה החלשה ביותר בשרשרת. כעת דמיין תרחיש בו ישנם שני אנשים בחדר אטום ללא אמצעים לראות, לשמוע או להקליט דבר שהם עושים. האחד יעביר הודעה לאחר אשר עם קריאת ההודעה ישרוף אותו. אם מישהו מחוץ לחדר הזה מעוניין לקבל את המסר שכבר הועבר, זה יהיה קשה. מהו החוליה החלשה ביותר להשגת המסר? אין כל כך הרבה קישורים לבחירה - זה שרשרת די קצרה. עכשיו דמיין שכשאתה שולח הודעה באינטרנט שיש לפחות מיליון קישורים בשרשרת - רבים מהם חלשים - רבים מהם לגמרי מחוץ לשליטתך - וזו המציאות.

שימוש בהצפנה יכול לעזור מאוד לבעיית הקישורים הנ"ל ולקל בפיתוי לחשוב שמערכות E2EE מעוצבות מציעות את הפתרון הסופי. עם זאת, חשיבה זו עלולה לגרום לך לצרות, מכיוון שתוקף בדרך כלל רק ילך אחרי הקישורים החלשים יותר במערכת. לדוגמה, זה כנראה הרבה יותר קל להשתלט על הטלפון או המחשב ולהגדיר לוגר קלט כדי פשוט לקרוא את כל מה שאתה מקליד מאשר לפצח הודעות מוצפנות דרך החוט. השורה התחתונה היא שאם היה מוטל עלי להעביר סוד בעל חשיבות חיונית / קריטית, הייתי משתמש רק בתקשורת אלקטרונית כשיטה אחרונה.

כך שיש סיכוני אבטחה בשימוש בכל תקשורת, אך אתה עדיין משתמש בדפדפן אינטרנט לבנקאות, לקנות דברים, דוא"ל וכו '. זה סיכון מקובל לנוחיות העצומה שהושגה. באמת השאלה היא ... אילו סיכוני אבטחה הם ספציפיים למחצה לאתר זה? כמה עולים בראשם:

מה אתה עושה בקשר להתקפות איש-באמצע (MITM)?

כל המשתמשים באתרי אינטרנט עשויים להיות קורבן להתקפת MITM - אתר זה אינו שונה מכל האחרים באינטרנט בנושא זה. התקפת MITM היא כאשר תוקף מסוגל ליירט ולשנות תקשורת בין דפדפן המשתמש לבין שרת האינטרנט של האתר. זה מאפשר לתוקף לשנות כל אחד מהקודים / תוכן של האתר תוך שהוא נראה למשתמש הקצה כאתר אליו הם רגילים. אנו נוקטים כמה צעדים בכדי להקשות על התקפת MITM:

עם זאת, מתקפת MITM עדיין אפשרית תמיד - במיוחד אם התוקף שולט בתשתית רשת / מפתח ציבורי כפי שהיה קורה בארגונים גדולים או חזקים או ממשלות. אנו מציעים הרחבות דפדפנים אשר יכולות לסייע בהפחתת סיכוני MITM.

אילו יתרונות מציעים הרחבות הדפדפן?

אנו מציעים הרחבות דפדפנים כאמצעי לספק נוחות נוספת ואבטחה נוספת. במילים פשוטות ... התוספים הופכים את שליחת הודעות זמניות למהירה וקלה יותר. אבטחה מסוימת מושגת גם משום שכל הקוד המשמש להצפנת והכנת הודעה מאוחסן באופן מקומי בתוך הסיומת. מכיוון שהקוד מאוחסן באופן מקומי, הדבר מציע לשולח הגנה מסוימת מפני התקפות MITM . עם זאת, ראוי לציין כי בעוד שהתוספים מציעים הגנה רבה יותר מפני התקפת MITM הפוגעת בתוכן ההודעה, התקפת MITM עדיין יכולה להיות יעילה (כלומר לקבוע את כתובת ה- IP של השולח אם אינה משתמשת ב- TOR / VPN / וכו ').

כיצד אוכל לדעת בוודאות כי כל מה שנשלח מוצפן מקצה לקצה?

שלא כמו לקוחות צ'אט פופולריים אחרים המוצפנים מקצה לקצה (E2EE), די פשוט לראות מה בדיוק נשלח אלינו כשאתה מגיש הודעה. מדריך הווידאו שלהלן מדגים כיצד לאשר שאין לנו דרך לפענח הודעות שנשלחו לשרת.

כמו כן, אם אתה חושב על כך, כל עוד איננו סוכנות חשאית כלשהי המנסים לאסוף הודעות רגישות, אין שום תועלת מכך שנוכל לפענח הודעות שכן היכולת הזו רק יוצרת לנו בעיות. אנחנו אפילו לא רוצים לאחסן הודעות - אבל זה רע הכרחי להעביר אותן.

כיצד פועל הצפנה מקצה לקצה באתר זה?

בשלב זה אנו משתמשים בהצפנה סימטרית (AES-GCM 256bit) עם מפתחות שמקורם בסיסמאות (מינימום 150,000 חזרות של PBKDF2 / SHA-256). לא משתמשים בהצפנה א-סימטרית מכיוון שקיימות דרישות ל 1) שולח שיוזם את התקשורת 2) השולח והנמען אינם מקוונים בו זמנית ו- 3) אין מידע על הנמען ו 4) אנו מנסים לשמור על דברים פשוטים וניהול המפתח הוא מורכב. ה- API של Crypto Web רגיל משמש לכל פונקציונליות הצפנה כולל RNG. בעיקרון, הנה מה שקורה:

  1. משתמש הקצה בוחר סיסמה או שזו נוצרת אוטומטית
  2. מתבצעת שיחת API כדי להשיג את מספר האיטרציות הנדרשות של PBKDF2 / SHA-256 ( שלב זה נדרש לבקרת דואר זבל )
  3. נוצר מלח של 32 בתים
  4. מפתח נגזר מהמלח והסיסמה
  5. נוצר וקטור אתחול של 12 בתים (IV)
  6. ההודעה מוצפנת באמצעות המקש + IV
  7. ספירת האיטרציה, המלח, הרביעי וטקסט הצופן נשלחים לשרת (יחד עם מידע אחר כגון TTL, RTL וכו ').
  8. השרת מחזיר מזהה אקראי המתייחס להודעה
  9. לאחר מכן הדפדפן מציג למשתמש הקצה קישור המכיל את המזהה והסיסמה שהוחזרו או קישור ללא הסיסמה (ובמקרה זה על הנמען לדעת ולהזין את הסיסמה)
  10. אם הסיסמה היא חלק מהקישור, היא נמצאת ב- hash של ה- URL , ולכן לעולם לא נשלחת לשרת כאשר הנמען מגיש את בקשת ה- GET
  11. הנמען מתבקש אם ברצונו לפענח ולהציג את ההודעה
  12. הדפדפן מגיש בקשה המציינת את מזהה ההודעה
  13. אם השולח דורש השלמת CAPTCHA, הנמען מופנה לכתובת אתר אחרת כדי להוכיח שהוא אנושי (ברגע שהוא עובר הוא מופנה חזרה)
  14. השרת שולח את ההודעה המוצפנת וכברירת מחדל ימחק את ההודעה בשלב זה אם הקריאה לחיות (RTL) היא אחת
  15. הנמען יפענח את ההודעה באמצעות הסיסמה (ויתבקש להזין את הסיסמה אם לא בכתובת האתר)
התקנה זו פשוטה ביותר, ומציעה הצפנת הודעות ממכשיר השולח למכשיר הנמען, אך כמובן חסרה ההבטחה שההצפנה הא-סימטרית יכולה להציע מבחינת הידיעה שרק מי שנמצא ברשותו המפתח הפרטי של הנמען יכול לפענח את ההודעה. כל מי שיש לו את הקישור יכול לפתוח את ההודעה בתרחיש המוגדר כברירת מחדל לפיה הסיסמה היא חלק מכתובת ה- URL - זה מדגיש את החשיבות של שימוש בתעבורה מתאימה לקישור (כלומר דוא"ל / צ'אט / טקסט / וכו ') - החלטה שהושארה ל שׁוֹלֵחַ. אנו עשויים, אם יש עניין, גם לפרוס תמיכה בתכנית אסימטרית בסיסית מאוד לפיה הנמען יוזם בקשה להודעה ושולח קישור בקשה זה לשולח ההודעה. התקנה זו תמנע את הצורך להכיל את הסיסמה בכתובת האתר, אך גם מבטלת את היכולת של השולח ליזום.

סיסמת הפענוח יכולה להיות בכתובת האתר?

כן. זה כמובן משפיע על האבטחה מכיוון שאם השיטה בה משתמשים לשליחת הקישור אינה בטוחה, ההודעה אינה בטוחה על ידי שיוך. כל הדרכים לעקיפת הבעיה כדי למנוע בעיה זו מציגות שלבים ומורכבויות נוספות המשפיעים על חוויית המשתמש (כלומר יש להגדיר את הדברים בשני הקצוות לפני שליחת ההודעה). תכנית אסימטרית לפיה הנמען יוזם בקשה להודעה ושולח קישור בקשה זה יכול לעבוד עם דרישת המפתח שלנו "הכל ארעית" - ניתן ליישם זאת. בסופו של דבר, אם שני צדדים הולכים לשלוח הודעות זה לזה בתדירות גבוהה, קיימים פתרונות טובים יותר בהנחה ששני הצדדים יוכלו להתמודד עם שימוש בפתרונות אלה.

אבל סיסמת הפענוח לא חייבת להיות בכתובת האתר?

נכון. אם סיסמת הפענוח אינה כלולה בקישור, הנמען יתבקש להזין את הסיסמה. אם הסיסמה מועברת בצורה מאובטחת לנמען (או שהם כבר יודעים זאת), הדבר מספק הגנה מפני יירוט. עם זאת, החיסרון הוא שהנמען חייב לדעת ולהזין את הסיסמה בצורה נכונה. להלן דרך אחת לשלוח את הסיסמה לנמען אשר מציעה הגנה מסוימת מפני יירוט:

  1. הצפן את הסיסמה בהודעה עם הגדרות ברירת המחדל ושלח את הקישור הזה לנמען.
  2. כאשר הנמען לוחץ על הקישור ומפענח את ההודעה, הוא יודע שאף אחד אחר לא השיג לפניו את הסיסמה מכיוון שההודעה המכילה את הסיסמה נמחקת לאחר השליפה. עם זאת, אם יש התקפת MITM פעילה או אם המכשיר שלך או המכשיר של הנמען נפגעו, עדיין ייתכן שצד אחר יוכל להשיג את הסיסמה.
  3. אשר עם הנמען כי הוא השיג בהצלחה את הסיסמה. לדוגמה, אם הנמען מודיע לך שכאשר הם הלכו לאחזר את הסיסמה, כי ההודעה כבר נמחקה, אז אתה יודע שמישהו אחר השיג את הסיסמה לפני הנמען ועל כן הסיסמה נפגעת ואין להשתמש בה.
  4. באמצעות הסיסמה שהנמען אישר שיש ברשותה, כעת תוכל לשלוח הודעה באמצעות אותה סיסמה להצפנה - פשוט שתף את גרסת הקישור שאינה מכילה את הסיסמה.

זה נכון - אנו יוצרים את הקישור ומשאירים לידי השולח כיצד להעבירו למקבל בצורה הטובה ביותר. המטרה של שירות זה היא לספק אפשרות להציע פחות קביעות בהעברת הודעות קיימות כמו דואר אלקטרוני / צ'אט / טקסט / וכו '. לכן, הציפייה היא שהקישור שאנחנו מייצרים שמצביע על ההודעה הזמנית נשלח באמצעות העברת הודעות קיימת. יש לכך השלכות אבטחה שמשתמשים צריכים להבין. בואו ניקח הודעת טקסט SMS כדוגמא מכיוון שזו שיטת תקשורת די לא בטוחה. כאשר אתה משתמש בשירות זה כדי לשלוח קישור הודעה זמני באמצעות הודעת טקסט, אם אתה משתמש במצב ברירת המחדל לפיו הסיסמה כלולה בקישור, כל מי שיש לו את הקישור יכול לקרוא את ההודעה ולא מוצעת הגנה מפני יירוט. שירות זה עדיין מספק תקשורת זמנית יותר שיכולה לשפר את הפרטיות והאבטחה. בנוסף, אתה יכול לבחור לשלוח את הקישור ללא הסיסמה וזה יספק הגנה מפני יירוט.

כיצד אוכל להגן על פרטיותי ככל האפשר בעת השימוש בשירות זה?

כפי שנדון במקומות אחרים בשאלות נפוצות זו, למרות שאנו כבר עושים הרבה כדי להגן על פרטיותך ולמרות שאנו לא אוספים מידע אישי כלשהו, מידע כלשהו הקשור ביומן מוגש ונאסף על ידינו ואחרים מכוחך באמצעות דפדפן אינטרנט. עם זאת, ישנן דרכים רבות להגן על פרטיותך עוד יותר. דרך חופשית לשימוש, המבוססת על תוכנת קוד פתוח, ועובדת די טוב היא להשתמש בדפדפן Tor . דפדפן זה נועד להגן על פרטיותך ברמות מרובות - כולל שימוש ברשת Tor . האתר שלנו כבר נגיש דרך רשת הבצל של Tor, כלומר הגישה לאתר שלנו דרך Tor אינה מחייבת שימוש בצומת יציאה, מה שמבטל מישהו שציתות את התנועה בצומת היציאה . עם זאת, זכור כי גם בתרחיש זה, ספק האינטרנט שלך יכול לראות שאתה משתמש ב- Tor - אם כי לא בשביל מה. אתה יכול אפילו להתחבר ל- VPN ואז להפעיל את דפדפן Tor לשתי שכבות של אנונימיות; עם זאת, זכור כי ספק האינטרנט שלך עדיין יכול לראות שאתה משתמש ב- VPN בתרחיש זה - אם כי לא בשביל מה. אם אינך מעוניין שספק האינטרנט שלך יודע באילו פרוטוקולים אתה משתמש, תוכל להתחבר לרשת WiFi ציבורית ציבורית גדולה כמו ספריה, בית ספר וכו 'ואז להשתמש בדפדפן Tor.

מה אם אני לא סומך על ארצות הברית?

השרתים שלנו ממוקמים בארצות הברית. בנוסף, ספק ה- CDN שלנו, Cloudflare, הוא חברה שבסיסה בארצות הברית. ניסינו להסיר את הצורך לסמוך עלינו או על המדינה בה השרתים שלנו שוהים פשוט מכיוון שאנו לא אוספים מידע אישי, לא יכולים לפענח שום הודעה והכל נמחק זמן קצר לאחר קבלתו. עם זאת, אנו יכולים להבין קצת חוסר אמון מכיוון שהוא מבוסס אינטרנט ובמיוחד אם אתה גר במדינות מסוימות. יש לנו כמה תוכניות להציע אפשרויות באיסלנד ובשוויץ לאנשים שמתקשים לסמוך על ארה"ב. אנא יידע אותנו אם זה חל עליך, מכיוון שלא יהיה לנו מוטיבציה להציע חלופות אלא אם כן יש ביקוש אמיתי.

מה אתה עושה כדי למנוע דואר זבל?

בכל פעם שאתה מאפשר למישהו לפרסם הודעה שניתן להעביר באמצעות קישור, אתה מזמין שולחי דואר זבל. ריסון הבעיה אינו פשוט לחלוטין. איננו רוצים לטעון CAPTCHA של צד שלישי כחלק מתהליך שליחת ההודעות מכמה סיבות:

אנו עשויים לעקוף את בעיית ה- API באמצעות מערכת מפתח API כלשהי, אך אז עלינו לאסוף פרטי משתמש שאיננו רוצים לעשות. כמו כן, מה מונע משלחי דואר זבל לקבל הרבה מפתחות API? איננו יכולים לבחון הודעות כדי להסיק את זבלנותן (שהיא בעייתית מאוד במקרה הטוב) מאחר ומלבד הצפנת ההודעות יש לנו מדיניות מעשית לגבי תוכן ההודעה. בהתחשב בדרישות אלה, אנו משתמשים בשתי שיטות למניעת דואר זבל: אם ידוע לך כי שולחי דואר זבל מנצלים שימוש לרעה בשירות זה, אנא הגש דוח שימוש לרעה .

מדוע יש אפשרות לדרוש מהנמען להשלים CAPTCHA?

אמנם נכון שאנחנו לא אוהבים CAPTCHA, אך אנו מכירים בכך שהם משרתים מטרה ויש להם זמן ומקום (לפחות בינתיים). זוהי דרך פשוטה עבור השולח להשיג ביטחון כלשהו שהנמען הוא אנושי וכי תהליכים אוטומטיים אינם ניגשים להודעה.

מי מפעיל שירות זה ומדוע הוא בחינם?

אנחנו רק זוג חבר'ה שלפעמים נתקלנו בבעיה שאין לנו אפשרויות טובות לעזור בהגנה על פרטיותנו. לעתים קרובות זה נבע מתקשורת עם חברים ובני משפחה שלא התייחסו בזהירות רבה לאופן הטיפול שלהם במכשירים ובמידע שלהם. פעמים אחרות זה קרה בעת שימוש בפורומים מבוססי אינטרנט כמו Reddit או באמצעות מערכות תמיכה מבוססות אינטרנט. מצאנו כמה פתרונות להודעות זמניות מבוססות אינטרנט, אך אף אחד מהם לא הציע E2EE, מה שאומר שלא נוכל לסמוך עליהם. אז פשוט בנינו פיתרון משלנו והחלטנו למסור אותו כדי שאחרים יוכלו ליהנות ממנו.

כיצד אוכל לסמוך על התשובות לשאלות הנ"ל?

באמת שלא צריך לבטוח באף אתר רק בגלל שהוא אומר דברים מסוימים - זה בדרך כלל רעיון טוב לאמת טענות כלשהן. ניסינו להסיר את הדרישה לסמוך עלינו ככל האפשר באמצעות הצפנה מקצה לקצה. לדוגמה, די קל לבקר שאנחנו לא יכולים לקרוא שום הודעה מכיוון שהן מוצפנות . שמרנו גם על קוד javascript שמריץ אתר זה פשוט מאוד, כך שהוא קל לקריאה ולהבנה. הפיכת כל הקוד לקוד פתוח מאפשרת לאנשים לאמת מה פועל; עם זאת, זכור כי אין דרך לאמת באמת מה השרת פועל. אמנם נכון שחלק ניכר מדרישת האמון מוסר עם הצפנה מקצה לקצה, אך זה עדיין גורם שמשקפינו שוקלים מאוד כאשר הם מחליטים להשתמש בשירות זה או לא.