שאלות נפוצות
- מדוע אתר זה מתורגם בצורה גרועה? ⎃
- עד כמה שירות זה מאובטח?
- מדוע קיבלתי כאן קישור עם אפשרות לפענוח הודעה?
- האם למחוק את כל מה שנשלח לאתר זה?
- מדוע להשתמש בשירות זה?
- האם מדובר בשירות העברת הודעות?
- מהם מקרי השימוש המיועדים?
- לשם מה אסור להשתמש בשירות זה?
- מדוע לא להשתמש רק ב- PGP / Signal / OMEMO / Matrix / etc.?
- אילו דרישות קיימות?
- האם הנמען יכול ליצור עותק של ההודעה?
- האם נאסף מידע אישי כלשהו?
- איזה מידע נרשם?
- מה אתה עושה כדי לאבטח את השרתים?
- אילו סיכוני אבטחה קיימים בעת השימוש באתר זה?
- מה אתה עושה בקשר להתקפות איש-באמצע (MITM)?
- אילו יתרונות מציעים הרחבות הדפדפן?
- כיצד אוכל לדעת בוודאות כי כל מה שנשלח מוצפן מקצה לקצה?
- כיצד פועל הצפנה מקצה לקצה באתר זה?
- סיסמת הפענוח יכולה להיות בכתובת האתר?
- אבל סיסמת הפענוח לא חייבת להיות בכתובת האתר?
- שירות זה אינו מספק את הקישור למקבל?
- כיצד אוכל להגן על פרטיותי ככל האפשר בעת השימוש בשירות זה?
- מה אם אני לא סומך על ארצות הברית?
- מה אתה עושה כדי למנוע דואר זבל?
- מדוע יש אפשרות לדרוש מהנמען להשלים CAPTCHA?
- מי מפעיל שירות זה ומדוע הוא בחינם?
- כיצד אוכל לסמוך על התשובות לשאלות הנ"ל?
מדוע אתר זה מתורגם בצורה גרועה? ⎃
מצטער, אבל המחברים הנוכחיים דוברים אנגלית בלבד. אנו זקוקים לעזרה בתרגום פרויקט זה לשפות אחרות. כאמצעי פשוט וזול להנגשת שירות זה לאנשים שאינם דוברי אנגלית, אנו משתמשים בתרגום מכונה. התוצאות בדרך כלל קבילות, אך עלולות לגרום לניסוח מוזר או אפילו למידע לא מדויק לחלוטין. אתה יכול לעזור לנו לשפר את החוויה לכולם - אנא שלח את התרגום הנכון .
עד כמה שירות זה מאובטח?
נקטנו צעדים רבים בכדי להבטיח שירות זה לשימושו המיועד . לפני שנעבור על השלבים האלה, חשוב להבין את הדברים הבאים:
- למרות שאיננו יכולים לקרוא את ההודעה שלך בגלל הצפנה מקצה לקצה , קישור ברירת המחדל שנוצר מכיל את סיסמת / מפתח הפענוח ; ולכן כל מי שיש לו את הקישור יכול לקרוא את ההודעה שלך - כולל כל מי שמסוגל ליירט אותה.
- שירות זה הוא רק כלי המאפשר שליחה של תקשורת פחות קבועה (כלומר הודעות מוצפנות שנמחקות בעת אחזורם) באמצעות הובלות מסורתיות קבועות יותר (כלומר דוא"ל / טקסט / מסרים מיידיים / אתר אינטרנט וכו '). המשמעות היא שכל בעיות אבטחה / פרטיות הטמונות בתעבורה שנבחרה (כלומר דוא"ל) עוברות בירושה כאשר אתה משתמש בכלי זה .
- ישנם פתרונות אחרים המציעים אבטחה טובה יותר בהתאם לצרכים ולסביבה שלך. היתרון העיקרי שמציע שירות זה בהשוואה לאחרים, הוא דרישות נמוכות בהרבה למקבל (כלומר, הם רק צריכים דפדפן אינטרנט ויכולת ללחוץ על קישור).
- הגדרת ברירת המחדל היא אמנם מחיקת הודעות לאחר אחזורם, אך אין מה שמונע מהנמען ליצור עותק . זכור כי הדבר חל על כל פתרונות ההודעות הזמניות - אם המקלט יכול לראות את ההודעה, ניתן להעתיק אותה.
- כל תקשורת באינטרנט יכולה לפגוע בפרטיות שלך - אתה סוחר אבטחה מסוימת לנוחיותך.
- האינטרנט הוא סביבה מאתגרת בכל הנוגע לאבטחה בגלל כמה נושאים מהותיים - זה חל על כל אתרי האינטרנט. עם זאת, היותנו מבוססי רשת מקלה על אימות טענתנו כי איננו יכולים לקרוא את הודעתך .
- אתר אינטרנט זה ומסד הנתונים שלו מתארחים בארצות הברית. אנו משתמשים ב- Cloudflare, חברה שבסיסה בארצות הברית, כרשת למסירת התוכן שלנו (כל תעבורת הרשת עוברת ברשת זו).
- השימוש בשירות אינו מצריך מידע אישי (כלומר שם / דוא"ל / טלפון / וכו '). אין מערכת חשבונות (כלומר כניסה / סיסמה / וכו '); לכן כל הפרת נתונים אינה יכולה לדלוף מידע זה.
- כל תוכן ההודעה מוצפן מקצה לקצה . במילים אחרות, מפתח / סיסמת הפענוח לעולם לא נשלחים אלינו. לפיכך, אין לנו או לכל אדם אחר המחזיק בבסיס הנתונים שום אמצעי לפענח ולהציג את תוכן ההודעה.
- לכל ערך במסד הנתונים שלנו יש זמן לחיות שנע בין דקה לשבועיים (ברירת מחדל לשבוע אחד). לאחר שחלף הזמן הזה, הרשומה נמחקת אוטומטית. לכן, כל מידע במאגר המידע שלנו יימחק זמן קצר לאחר יצירתו .
- אנו מקיימים רק את 24 השעות האחרונות של יומני שרת האינטרנט . כל מידע IP המאוחסן במסד הנתונים נחשל באופן מאובטח, מה שלא מאפשר לחלץ את ה- IP המקורי.
- כל הקוד שמפעיל שירות זה הוא קוד פתוח וזמין לבדיקה. אתה יכול לראות בקלות את הקוד שמריץ את ההצפנה - שהוא קצר בכוונה, תמציתי ותגובה.
- ננקטים מספר אמצעי זהירות טכניים המסייעים לחיזוק הביטחון - חלקם כוללים:
- כל אתר זה שאינו / api הוא סטטי ואינו תומך בקוד שרת בדפים (כלומר PHP / JSP / ASP / וכו ').
- ה- Web Crypto API , המהווה חלק מהדפדפן, משמש להצפנת כל תוכן ההודעה.
- TLS משמש להצפנת תקשורת בין הדפדפן שלך לשרתים שלנו. זה עוזר להבטיח שלא ניתן ליירט קוד או לשנות אותו במעבר. TLS 1.3 נתמך, אך אנו תומכים גם ב- TLS 1.2 למכשירים ישנים יותר. גרסאות ישנות יותר של TLS מושבתות מכיוון שהן אינן מאובטחות באותה מידה.
- יומני שקיפות האישורים מנוטרים על מנת להפריש אישור. בנוסף אנו מפרסמים מדיניות רשות אישורים (CAA) להפחתת הסיכון להנפקת אישור לא מכוונת או זדונית.
- אנו משתמשים ב- HTTP Strict Transport Security (HSTS) על מנת להבטיח כי דפדפנים תמיד מתקשרים עם השרתים שלנו באמצעות פרוטוקול TLS. בנוסף, אנו כוללים את הדומיינים שלנו ברשימות הטעינה המוקדמת .
- אוכפת מדיניות קפדנית לאבטחת תוכן כדי למנוע התקפות CrossScript (XSS) .
- על ידי שימוש במדיניות משאבים בין -מקורית, במדיניות הטמעה בין-מקורית ובמדיניות פותח-מקור , אנו אוסרים על קוד מוצא על מנת לסייע במיתון נגד התקפות צד-ערוציות ספקולטיביות כמו ספקטר ומיתוך. זה גם מציע הגנה מפני בקשות שעלולות להיות זדוניות ממקורות אחרים על ידי בידוד הקשר הגלישה אך ורק למסמכים מאותו מקור.
- אנו משתמשים במדיניות הרשאות כדי למנוע מהדפדפן לטעון משאבים שעלולים לפגוע בפרטיותך כגון המיקום שלך, מצלמת רשת, מיקרופון וכו '.
- DNSSEC משמש בכל התחומים שלנו כדי לסייע במיתון התקפות MITM מבוססות DNS.
- אנו נוקטים מספר אמצעי זהירות לאבטחת השרת.
- לא נטען קוד של צד שלישי (כלומר jQuery) ומעט מאוד משאבים נטענים (קדימה ופתח את כרטיסיית הרשת בכלי Dev כדי לבדוק) - זה ממזער את המאמץ הדרוש לביקורת. היוצא מן הכלל היחיד הוא אם נדרש CAPTCHA - הטוען קוד צד 3 מ- hCaptcha. עם זאת, קוד hCaptcha נטען בכתובת האתר שלו בתוך כללי ה- CSP שלו ובשום עת אין לו גישה לכל מה שקשור להודעה.
- כאמצעי לסייע בשמירה מפני התקפות MITM , הרחבות דפדפן זמינות .
מדוע קיבלתי כאן קישור עם אפשרות לפענוח הודעה?
אנו מתנצלים אם ישנן טעויות בתרגום זה . שירות זה פשוט מעביר הודעה מוצפנת מנקודה אחת לאחרת ואתה הנמען. ההודעה תימחק בקרוב. למפעילי שירות זה אין דרך לקרוא את תוכן ההודעה. בדרך כלל מישהו משתמש בשירות זה כאשר הוא לא רוצה שתוכן ההודעה יישאר בתוך מאגרי מידע / מכשירים / שירותים / קבצים / וכו '. כמקובל בשליחת דוא"ל / הודעה מיידית / טקסט / וכו '. אם תחליט לפענח, זכור את הדברים הבאים:
- סביר להניח שההודעה תימחק מיד לאחר שנשלחה למכשיר שלך לצורך פענוח. המשמעות היא שלאחר שלוחצים על הכפתור לפענוח ההודעה, אין לנו עוד עותק שישלח אליכם מאוחר יותר.
- אנו מוחקים באופן שיטתי את כל המידע שהתקבל. ההודעות יימחקו בכל מקום בין דקה לשבועיים לאחר שנוצרה - ללא קשר אם ההודעה תפענח אי פעם. במילים אחרות, אם אתה צריך לקרוא את ההודעה, אל תחכה יותר מדי זמן כדי לפענח אותה.
- השולח סבור כי יש לטפל בזהירות בתוכן ההודעה. יתכן שהם אפילו ציינו שהם רוצים שלא יוצרו עותקים. אנא כבד את משאלותיהם.
- אם תתבקש להזין סיסמה לפענוח הודעה, אל תסגור את חלון / כרטיסיית הדפדפן. לפי נקודת התבליט הראשונה ברשימה זו, סביר להניח שלא נוכל לשלוח עותק נוסף מאוחר יותר. פשוט השאר את חלון / כרטיסיית הדפדפן פתוחים עד שתוכל להזין את הסיסמה. אם תזין סיסמה שגויה, תתבקש שוב. יש להזין את הסיסמה באופן מדויק. זכור שכדי להתאים לשפות שונות ולדרישות סיסמא שונות, אנו מקבלים תווים רבים ושונים בסיסמאות.
האם למחוק את כל מה שנשלח לאתר זה?
נכון ללוגו של פח האשפה שלנו ... הכל נמחק זמן קצר לאחר קבלתו. מחיקת הכל היא אוטומטית - היא נכתבת לשרת. תחשוב על זה ככה - יש שני סוגים של מידע שהוגש:
- הודעות מוצפנות שאין לנו שום אמצעי לפענח את התוכן
- מידע אחר הטמון בהגשת דבר באינטרנט (למשל כתובת ה- IP שלך וכו ')
- כמה זמן עלינו לשמור את ההודעה אם אף אחד לא משחזר אותה (נע בין דקה לשבועיים - ברירת מחדל לשבוע אחד).
- כמה פעמים ההודעה משוחזרת (נע בין 1 ל 100 פעמים - ברירת המחדל היא פעם אחת)
מדוע להשתמש בשירות זה?
שירות זה הוא כלי המסייע בהפיכת הודעות שאתה שולח / מקבל פחות קבועות. רוב הדברים שאתה מתקשר באינטרנט (צ'אטים, טקסטים, מיילים וכו ') נשמרים ונמחקים לעיתים נדירות. לעתים קרובות, כאשר אתה מוחק משהו, זה לא באמת נמחק אלא מסומן כמוחק וכבר לא מוצג לך. התקשורת המצטברת שלך מצטברת שנה אחר שנה במאגרי מידע ובמכשירים שאין לך שליטה עליהם. באופן בלתי נמנע, אחד או יותר מהארגונים / אנשים / מכשירים השומרים את התקשורת שלך נפרצים והמידע שלך דולף. בעיה זו כה מקיפה עד כי ישנם כיום אתרי אינטרנט רבים העוקבים אחר הארגונים שנפגעו והדלפו נתוני משתמשים. הודעות זמניות מוצפנות מקצה לקצה הן פיתרון פשוט שיעזור להפוך חלק מהתקשורת שלך לקבועה פחות. לכל הודעה המוגשת לאתר זה יש זמן לחיות שנע בין דקה לשבועיים - לאחר שחלף הזמן ההודעה נמחקת. יתר על כן, הגדרת ברירת המחדל היא מחיקת כל הודעה לאחר שהמקבל אחזר אותה. בנוסף, כל ההודעות מוצפנות מהמכשיר שלך עד למכשיר הנמען. המטרה העיקרית בשימוש בהצפנה מקצה לקצה היא להסיר את היכולת שלנו לקרוא הודעות שהוגשו ובכך להסיר חלק מדרישת האמון. התוצאה הסופית היא שכעת קל לשלוח הודעה מוצפנת באמצעות קישור פשוט. הודעה זו נמחקת זמן קצר לאחר השליחה או עם האחזור. אינך צריך להתקין / להגדיר תוכנה מיוחדת. אינך צריך ליצור חשבון או לספק מידע אישי כלשהו. הנמען לא צריך להיות באנשי הקשר שלך או אפילו לדעת על שירות זה - הדרישה היחידה שהם יכולים ללחוץ על קישור.
האם מדובר בשירות העברת הודעות?
לא. שירות זה נועד להשלים שירותי העברת הודעות קיימים כמו מסרים מיידיים / דוא"ל / טקסט / וכו '. על ידי הוספת היכולת למנוע שמירת הודעות שנשלחו לאורך זמן. איננו מעבירים את הקישור שנוצר למקבל .
מהם מקרי השימוש המיועדים?
אז מהם כמה תרחישים שבהם ראוי להשתמש בשירות זה? בעוד שלכל אחד יש צרכים ודרישות שונות בכל הנוגע לפרטיותם וביטחונם, באופן אישי מצאתי את התרחישים הבאים כמקרי שימוש מתאימים:
- התקשרת באמצעות פורום אינטרנט מקומי על שבילי אופני הרים באזור ולפעמים נפגשים עם אנשים בפורום כדי לבדוק יחד שבילים חדשים. מישהו מהפורום רוצה לאסוף אותך אצלך כדי לנסוע לשביל בסוף השבוע. אינך רוצה שכתובת הבית שלך תשוב לנצח במאגר הפורומים של אתרי אינטרנט אלה. כל שעליך לעשות הוא לשלוח את הכתובת באמצעות שירות זה - הקישור הוא מה שנמצא במאגר הפורומים של האתר, אך לאחר קריאתו על ידי הנמען, ההודעה / כתובת נמחקת.
- אתה צריך לשלוח לאחיך את הכניסה שלך לנטפליקס מכיוון שאחייניתך משגעת אותו בגלל נעילת COVID והוא עדיין לא מחזיק חשבון משלו. לא אכפת לך יותר מדי מההתחברות הזו, אבל לאח שלך רע במיוחד במה שאני פשוט אקרא "היגיינה דיגיטלית" והיו לו ניסויים רבים עם כניסות ותוכנות זדוניות שנפגעו. הניסיונות הבאים לגרום לו לנקות את פעולתו ואף להתקין עבורו מסרים מאובטחים לא הצליחו להישאר. פשוט לשלוח אותו באמצעות הודעת טקסט היא כנראה האפשרות הטובה ביותר (לצערנו), אבל לא נעים לך שההתחברות הזו תשמש בהיסטוריית ההודעות שלו בגלל ניסיון העבר. השימוש בשירות זה כדי לשלוח את הכניסה דרך קישור בהודעת טקסט מספק שאינו נותן לכניסה לבלות לנצח בהיסטוריית הצ'אט שלו.
- לפעמים אתה עובד במשרד שיש בו דיירים משותפים רבים שבאים והולכים בכל שעה. יש WiFi זמין לשימוש, אך הסיסמה מסתובבת מדי שבוע מכיוון שהיו בעיות בהתעללות. דיירים רבים שולחים אימייל / טקסט המבקשים את סיסמת ה- WiFi למרות שהיא נמצאת בדלפק הקבלה מכיוון שרובם אינם נכנסים דרך הכניסה הראשית הקדמית. באמצעות שירות זה, מנהל המשרד יכול לשלוח את סיסמת ה- WiFi דרך קישור במייל / תשובת טקסט מספק שאינו נותן לסיסמה להתעכב, וגם מאפשר לנמען להעתיק מיד את הסיסמה באמצעות כפתור העתקה שהוא פחות מגושם במכשירים ניידים.
- אחד מספקי האירוח שלך מבקש ממך פרטים אודות שרת שדיווחת עליו מראה סימנים של כונן קשיח שנראה רע. חלק מהמידע שהם זקוקים לו הוא מעט רגיש - אתה לא רוצה שהוא יושב לנצח במערכת הכרטיסים של הצד השלישי שהם משתמשים בו. באמצעות שירות זה תוכלו לשלוח את המידע לטכנאי התמיכה מבלי שיימצא במערכת הכרטיסים. מכיוון שמספר טכנאים עשויים להזדקק להתייחס למידע מספר רב של פעמים, הגדר את הקריאה לחיות גדולה מ -1 (כלומר אולי 20) כך שההודעה לא תימחק בעת האחזור הראשון.
- עליך לשלוח הודעה פרטית למשתמש אחר ב- Reddit כדי להודיע לו על מספר הטלפון שלך כדי שיוכל להתקשר אליך. Reddit, כמו ספקים רבים אחרים, הדליפו מידע על משתמשים בעבר ואתם לא רוצים שמספר הטלפון שלכם יושב רק במסד הנתונים של Reddit במשך שנים עד לדליפה הבאה. כל שעליך לעשות הוא לשלוח את מספר הטלפון שלך באמצעות שירות זה.
- בן הזוג שלך שולח לך הודעה בזמן שאתה בעבודה ורוצה להתחבר לשירותים מכיוון שחברתה בדיוק ניסתה תוכנית חדשה שחסכה לה כסף בחשבון החשמלי שלה והיא רוצה לבדוק את זה. יש מנהל סיסמאות משפחתי משותף שאתה מזכיר לה עליו, אבל היא רק רוצה שתשלח את הכניסה. OMEMO מועסקת להעברת הודעות מיידיות עם בן / בת הזוג שלך ולכן אתה מרגיש בטוח מאוד שהעברת המסרים מאובטחת; עם זאת, היסטוריית הצ'אט עצמה נשמרת ללא הצפנה. בן הזוג שלך לא תמיד נזהר מהורדות, מיילים וכו 'וחשבונות השירות הם מעט רגישים מכיוון שהם יכולים לשמש לגניבת זהות להוכחת מגורים. אתה יכול לשלוח לה את פרטי הכניסה באמצעות שירות זה כדי למנוע עותק המאוחסן במחשב שלה.
לשם מה אסור להשתמש בשירות זה?
אין להשתמש בשירות זה למידע רגיש מאוד מכל הסיבות המובאות בשאלות נפוצות אלו. להלן מספר דוגמאות למה לא לעשות:
- אל תשתמש בשירות זה כדי להפוך העברת הודעות בלתי הולמת ל"מאובטחת יותר ". מכיוון שהגדרת ברירת המחדל היא לכלול את הסיסמה בכתובת האתר שיכולה לקרוא את ההודעה, כל מי שיש לו את הקישור יכול לקרוא את ההודעה. כאמור לעיל, כל נושא אבטחה / פרטיות הטמון בתעבורה שנבחרה (כלומר טקסט) עובר בירושה כאשר אתה משתמש בכלי זה. כך, למשל, אם לעולם לא היית שוקל להשתמש בדוא"ל כדי לשלוח מידע ספציפי בשל אופיו החמור, אז אתה לא צריך להשתמש בשירות זה כדי "לאבטח" את החלק של הדוא"ל.
- אל תשתמש בשירות זה כדי להבטיח שלא יוצר עותק מההודעה. רק בגלל שאנחנו מוחקים את העותק שלנו של ההודעה המוצפנת מיד עם השליפה ואנחנו מקשים על ההעתקה, זה לא אומר שלא ניתן להעתיק את ההודעה. מה אם הנמען מצלם את המסך שלו? מה אם הם פשוט יכתבו את ההודעה? בסופו של דבר, אם הנמען יכול לקרוא את ההודעה - ניתן ליצור העתק.
- אל תשתמש בשירות זה כדי להבטיח שלא ניתן יהיה לאתר הודעה אליך. שירות זה תלוי בספק העברת הודעות אחר (כלומר דוא"ל, צ'אט וכו ') כדי לקבל את ההודעה מנקודה אחת לאחרת. העברת המסרים המועסקת יכולה בהחלט לאתר את המסר אליך.
- אל תשתמש בשירות זה כדי לשלוח כל דבר שתרצה לשלול. רק בגלל שההודעה עצמה נמחקת, זה לא אומר שהקישור שמפנה להודעה שנמחקה נמחק. אם אתה שולח דוא"ל לחבר שלך ולחלק מאותו דוא"ל יש קישור להודעה משירות זה, קורא מזדמן יידע שיש משהו אחר בהודעה. גם אם ההודעה אליה התייחס הקישור חלפה מזמן - ברור שמשהו אחר נשלח ושנשלח על ידך לחברך.
מדוע לא להשתמש רק ב- 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 משתנים בין דקה לשבועיים.
מה אתה עושה כדי לאבטח את השרתים?
אבטחת שרתים היא עניין מובהק. ישנם שני תחומים עיקריים שאנו מתמקדים בהם בכדי לשמור על אבטחתה:
- ראשית, אנו מאחסנים כמה שפחות בפרק הזמן המינימלי האפשרי, כך שאם השרת נפגע אי פעם, כל דליפת מידע לא תזיק למשתמשים שלנו. כל ההודעות המאוחסנות במסד הנתונים מוצפנות ללא אמצעי לפענוחן. אין שום דבר המאוחסן המקשר הודעה לאף אחד מהמשתמשים שלנו מכיוון שאנו לא אוספים מידע אישי מהמשתמשים שלנו. לכל הרשומות במאגר זמן תפוגה (TTL) שנע בין דקה לשבועיים - לאחר שחלף הזמן הזה הרשומה נמחקת אוטומטית. לכן, הרוב המכריע של המידע שהיה אי פעם במאגר כבר נמחק מזמן.
- אנו נוקטים מספר צעדים למניעת פשרות ומכילים כל פשרה שתתרחש:
- שרת האינטרנט, nginx , מנוהל במיכל מבודד כמשתמש חסר זכות ללא גישה לכתיבה למעט יומנים. המכולה פועלת בהקשר SELinux משלה, ומונעת כל שינוי במערכת הקבצים או בריחה קלה מהמיכל. אין תמיכה ב- PHP / ASP / JSP / וכו '. - רק משרת משאבים סטטיים.
- הקוד הפועל / api כתוב ב- Go, מה שאמור להפוך אותו לעמיד למדי לפגיעות של הצפת יתר (וקטור התקפה נפוץ). תהליך ה- Go פועל גם במיכל מבודד כמשתמש לא-רגלי ללא גישה לכתיבה למעט מסד הנתונים. המכולה פועלת בהקשר SELinux משלה, ומונעת כל שינוי במערכת הקבצים או בריחה קלה מהמיכל. מסד הנתונים, badgerdb , הוא חלק מתהליך ה- Go (ללא תלות / תהליך חיצוני במסד נתונים).
- הסכנה העיקרית של פשרה בשרת היא שהתוקף יכול לשנות קבצים באופן שיפגע בפרטיות / באבטחה של המשתמשים שלנו. תהליך ייעודי עוקב אחר כל קבצי אתרי האינטרנט על כל שינוי ומתריע בפנינו באופן מיידי במקרה שיש שינוי כלשהו.
- כל הגישה הניהולית מוגנת ומוגבלת לרשתות מורשות.
אילו סיכוני אבטחה קיימים בעת השימוש באתר זה?
לפני שהתייחסתי ספציפית לחלק מהסיכונים הללו, אני חושב שאנלוגיה קצרה למחצה עשויה לעזור לסיכום הסיכונים בשימוש בכל תקשורת אינטרנט. דמיין כי כל מערכת מאובטחת רק כמו החוליה החלשה ביותר בשרשרת. כעת דמיין תרחיש בו ישנם שני אנשים בחדר אטום ללא אמצעים לראות, לשמוע או להקליט דבר שהם עושים. האחד יעביר הודעה לאחר אשר עם קריאת ההודעה ישרוף אותו. אם מישהו מחוץ לחדר הזה מעוניין לקבל את המסר שכבר הועבר, זה יהיה קשה. מהו החוליה החלשה ביותר להשגת המסר? אין כל כך הרבה קישורים לבחירה - זה שרשרת די קצרה. עכשיו דמיין שכשאתה שולח הודעה באינטרנט שיש לפחות מיליון קישורים בשרשרת - רבים מהם חלשים - רבים מהם לגמרי מחוץ לשליטתך - וזו המציאות.
שימוש בהצפנה יכול לעזור מאוד לבעיית הקישורים הנ"ל ולקל בפיתוי לחשוב שמערכות E2EE מעוצבות מציעות את הפתרון הסופי. עם זאת, חשיבה זו עלולה לגרום לך לצרות, מכיוון שתוקף בדרך כלל רק ילך אחרי הקישורים החלשים יותר במערכת. לדוגמה, זה כנראה הרבה יותר קל להשתלט על הטלפון או המחשב ולהגדיר לוגר קלט כדי פשוט לקרוא את כל מה שאתה מקליד מאשר לפצח הודעות מוצפנות דרך החוט. השורה התחתונה היא שאם היה מוטל עלי להעביר סוד בעל חשיבות חיונית / קריטית, הייתי משתמש רק בתקשורת אלקטרונית כשיטה אחרונה.
כך שיש סיכוני אבטחה בשימוש בכל תקשורת, אך אתה עדיין משתמש בדפדפן אינטרנט לבנקאות, לקנות דברים, דוא"ל וכו '. זה סיכון מקובל לנוחיות העצומה שהושגה. באמת השאלה היא ... אילו סיכוני אבטחה הם ספציפיים למחצה לאתר זה? כמה עולים בראשם:
- אולי הסיכון הגדול ביותר והייחודי ביותר לשירות זה הוא שהמשתמשים שלנו לא ישתמשו בשיקול דעת טוב כאשר הם מבחינים בין מה מתאים לשלוח לבין מה שלא מתאים לשלוח . לפעמים ההבחנה בין "נוח לי לשלוח מידע זה בדוא"ל - אני רק רוצה שהדואר האלקטרוני יימחק לאחר הקריאה" לבין "לא נעים לי לשלוח מידע זה בדוא"ל - דוא"ל זה הובלה בלתי הולמת" יכולה להיות די עדינה.
- תמיד קיים האיום שמפעילי האתר הזה הם למעשה שחקנים גרועים המפתים אנשים להשתמש בשירות כדי להשיג איזו מטרה סופית חשוכה. אנו נתקלים באמין באופן סביר - הופכים את הכל לקל ובחינם - מקבלים המון אנשים המשתמשים בשירות - כל הזמן תוך כוונה מרושעת. בווההההההה! איך יכולת לבטוח בנו?
- יש סיכוי שלקוד שלנו יש באגים שמשפיעים על האבטחה או שפשוט לא חשבנו טוב על הדברים והחסרונות שלנו חושפים כעת את המשתמשים שלנו לסכנה מיותרת. אנו בהחלט מקווים שלא - אך איננו יכולים לשלול זאת.
- שלא כמו הטק-טיטאנים (כלומר גוגל / פייסבוק / וואטסאפ) שיש בהם טריטים של נתונים מוצפנים הזורמים כל הזמן פנימה והחוצה של הרשת העצומה שלהם, שם קל להתקשר עם תקשורת פרטית עם תעבורה אחרת, שירותים מרכזיים עצמאיים (כלומר, Signal, מברק, ואנחנו) בולטים. קל למפעיל רשת או אפילו לארגון / ממשלה גדולים לראות שכתובת ה- IP xxxx משתמשת בשירות XYZ.
- אמנם הם לא ממש ספציפיים לאתר זה, מכיוון שהוא יכול לשמש כנגד כל אתר אינטרנט, התקפות איש-אמצע (MITM) מהוות דאגה נכונה .
מה אתה עושה בקשר להתקפות איש-באמצע (MITM)?
כל המשתמשים באתרי אינטרנט עשויים להיות קורבן להתקפת MITM - אתר זה אינו שונה מכל האחרים באינטרנט בנושא זה. התקפת MITM היא כאשר תוקף מסוגל ליירט ולשנות תקשורת בין דפדפן המשתמש לבין שרת האינטרנט של האתר. זה מאפשר לתוקף לשנות כל אחד מהקודים / תוכן של האתר תוך שהוא נראה למשתמש הקצה כאתר אליו הם רגילים. אנו נוקטים כמה צעדים בכדי להקשות על התקפת MITM:
- HSTS משמש לאילוץ דפדפנים להתחבר רק דרך TLS. השרת שלנו מוגדר להתעלם מתקשורת שאינה TLS מלבד הפניה מחדש. רק TLS 1.2 ומעלה נתמכים.
- DNSSEC משמש לחתימת אזור התחום שלנו. זה יכול לעצור זיוף DNS המיושם התקפות MITM אם המשתמש מפעיל פותר רקורסיבי רלוונטי ל- DNSSEC.
- אנו משתמשים בשירות כדי לפקח על רשויות אישורים המנפיקות אישורי TLS לא מורשים המתייחסים לתחום שלנו.
- פרסמנו הרחבות דפדפן לתמיכה בהצפנת הודעות באמצעות קוד המאוחסן במכשיר של משתמש הקצה.
אילו יתרונות מציעים הרחבות הדפדפן?
אנו מציעים הרחבות דפדפנים כאמצעי לספק נוחות נוספת ואבטחה נוספת. במילים פשוטות ... התוספים הופכים את שליחת הודעות זמניות למהירה וקלה יותר. אבטחה מסוימת מושגת גם משום שכל הקוד המשמש להצפנת והכנת הודעה מאוחסן באופן מקומי בתוך הסיומת. מכיוון שהקוד מאוחסן באופן מקומי, הדבר מציע לשולח הגנה מסוימת מפני התקפות MITM . עם זאת, ראוי לציין כי בעוד שהתוספים מציעים הגנה רבה יותר מפני התקפת MITM הפוגעת בתוכן ההודעה, התקפת MITM עדיין יכולה להיות יעילה (כלומר לקבוע את כתובת ה- IP של השולח אם אינה משתמשת ב- TOR / VPN / וכו ').
כיצד אוכל לדעת בוודאות כי כל מה שנשלח מוצפן מקצה לקצה?
שלא כמו לקוחות צ'אט פופולריים אחרים המוצפנים מקצה לקצה (E2EE), די פשוט לראות מה בדיוק נשלח אלינו כשאתה מגיש הודעה. מדריך הווידאו שלהלן מדגים כיצד לאשר שאין לנו דרך לפענח הודעות שנשלחו לשרת.
כמו כן, אם אתה חושב על כך, כל עוד איננו סוכנות חשאית כלשהי המנסים לאסוף הודעות רגישות, אין שום תועלת מכך שנוכל לפענח הודעות שכן היכולת הזו רק יוצרת לנו בעיות. אנחנו אפילו לא רוצים לאחסן הודעות - אבל זה רע הכרחי להעביר אותן.כיצד פועל הצפנה מקצה לקצה באתר זה?
בשלב זה אנו משתמשים בהצפנה סימטרית (AES-GCM 256bit) עם מפתחות שמקורם בסיסמאות (מינימום 150,000 חזרות של PBKDF2 / SHA-256). לא משתמשים בהצפנה א-סימטרית מכיוון שקיימות דרישות ל 1) שולח שיוזם את התקשורת 2) השולח והנמען אינם מקוונים בו זמנית ו- 3) אין מידע על הנמען ו 4) אנו מנסים לשמור על דברים פשוטים וניהול המפתח הוא מורכב. ה- API של Crypto Web רגיל משמש לכל פונקציונליות הצפנה כולל RNG. בעיקרון, הנה מה שקורה:
- משתמש הקצה בוחר סיסמה או שזו נוצרת אוטומטית
- מתבצעת שיחת API כדי להשיג את מספר האיטרציות הנדרשות של PBKDF2 / SHA-256 ( שלב זה נדרש לבקרת דואר זבל )
- נוצר מלח של 32 בתים
- מפתח נגזר מהמלח והסיסמה
- נוצר וקטור אתחול של 12 בתים (IV)
- ההודעה מוצפנת באמצעות המקש + IV
- ספירת האיטרציה, המלח, הרביעי וטקסט הצופן נשלחים לשרת (יחד עם מידע אחר כגון TTL, RTL וכו ').
- השרת מחזיר מזהה אקראי המתייחס להודעה
- לאחר מכן הדפדפן מציג למשתמש הקצה קישור המכיל את המזהה והסיסמה שהוחזרו או קישור ללא הסיסמה (ובמקרה זה על הנמען לדעת ולהזין את הסיסמה)
- אם הסיסמה היא חלק מהקישור, היא נמצאת ב- hash של ה- URL , ולכן לעולם לא נשלחת לשרת כאשר הנמען מגיש את בקשת ה- GET
- הנמען מתבקש אם ברצונו לפענח ולהציג את ההודעה
- הדפדפן מגיש בקשה המציינת את מזהה ההודעה
- אם השולח דורש השלמת CAPTCHA, הנמען מופנה לכתובת אתר אחרת כדי להוכיח שהוא אנושי (ברגע שהוא עובר הוא מופנה חזרה)
- השרת שולח את ההודעה המוצפנת וכברירת מחדל ימחק את ההודעה בשלב זה אם הקריאה לחיות (RTL) היא אחת
- הנמען יפענח את ההודעה באמצעות הסיסמה (ויתבקש להזין את הסיסמה אם לא בכתובת האתר)
סיסמת הפענוח יכולה להיות בכתובת האתר?
כן. זה כמובן משפיע על האבטחה מכיוון שאם השיטה בה משתמשים לשליחת הקישור אינה בטוחה, ההודעה אינה בטוחה על ידי שיוך. כל הדרכים לעקיפת הבעיה כדי למנוע בעיה זו מציגות שלבים ומורכבויות נוספות המשפיעים על חוויית המשתמש (כלומר יש להגדיר את הדברים בשני הקצוות לפני שליחת ההודעה). תכנית אסימטרית לפיה הנמען יוזם בקשה להודעה ושולח קישור בקשה זה יכול לעבוד עם דרישת המפתח שלנו "הכל ארעית" - ניתן ליישם זאת. בסופו של דבר, אם שני צדדים הולכים לשלוח הודעות זה לזה בתדירות גבוהה, קיימים פתרונות טובים יותר בהנחה ששני הצדדים יוכלו להתמודד עם שימוש בפתרונות אלה.
אבל סיסמת הפענוח לא חייבת להיות בכתובת האתר?
נכון. אם סיסמת הפענוח אינה כלולה בקישור, הנמען יתבקש להזין את הסיסמה. אם הסיסמה מועברת בצורה מאובטחת לנמען (או שהם כבר יודעים זאת), הדבר מספק הגנה מפני יירוט. עם זאת, החיסרון הוא שהנמען חייב לדעת ולהזין את הסיסמה בצורה נכונה. להלן דרך אחת לשלוח את הסיסמה לנמען אשר מציעה הגנה מסוימת מפני יירוט:
- הצפן את הסיסמה בהודעה עם הגדרות ברירת המחדל ושלח את הקישור הזה לנמען.
- כאשר הנמען לוחץ על הקישור ומפענח את ההודעה, הוא יודע שאף אחד אחר לא השיג לפניו את הסיסמה מכיוון שההודעה המכילה את הסיסמה נמחקת לאחר השליפה. עם זאת, אם יש התקפת MITM פעילה או אם המכשיר שלך או המכשיר של הנמען נפגעו, עדיין ייתכן שצד אחר יוכל להשיג את הסיסמה.
- אשר עם הנמען כי הוא השיג בהצלחה את הסיסמה. לדוגמה, אם הנמען מודיע לך שכאשר הם הלכו לאחזר את הסיסמה, כי ההודעה כבר נמחקה, אז אתה יודע שמישהו אחר השיג את הסיסמה לפני הנמען ועל כן הסיסמה נפגעת ואין להשתמש בה.
- באמצעות הסיסמה שהנמען אישר שיש ברשותה, כעת תוכל לשלוח הודעה באמצעות אותה סיסמה להצפנה - פשוט שתף את גרסת הקישור שאינה מכילה את הסיסמה.
שירות זה אינו מספק את הקישור למקבל?
זה נכון - אנו יוצרים את הקישור ומשאירים לידי השולח כיצד להעבירו למקבל בצורה הטובה ביותר. המטרה של שירות זה היא לספק אפשרות להציע פחות קביעות בהעברת הודעות קיימות כמו דואר אלקטרוני / צ'אט / טקסט / וכו '. לכן, הציפייה היא שהקישור שאנחנו מייצרים שמצביע על ההודעה הזמנית נשלח באמצעות העברת הודעות קיימת. יש לכך השלכות אבטחה שמשתמשים צריכים להבין. בואו ניקח הודעת טקסט SMS כדוגמא מכיוון שזו שיטת תקשורת די לא בטוחה. כאשר אתה משתמש בשירות זה כדי לשלוח קישור הודעה זמני באמצעות הודעת טקסט, אם אתה משתמש במצב ברירת המחדל לפיו הסיסמה כלולה בקישור, כל מי שיש לו את הקישור יכול לקרוא את ההודעה ולא מוצעת הגנה מפני יירוט. שירות זה עדיין מספק תקשורת זמנית יותר שיכולה לשפר את הפרטיות והאבטחה. בנוסף, אתה יכול לבחור לשלוח את הקישור ללא הסיסמה וזה יספק הגנה מפני יירוט.
כיצד אוכל להגן על פרטיותי ככל האפשר בעת השימוש בשירות זה?
כפי שנדון במקומות אחרים בשאלות נפוצות זו, למרות שאנו כבר עושים הרבה כדי להגן על פרטיותך ולמרות שאנו לא אוספים מידע אישי כלשהו, מידע כלשהו הקשור ביומן מוגש ונאסף על ידינו ואחרים מכוחך באמצעות דפדפן אינטרנט. עם זאת, ישנן דרכים רבות להגן על פרטיותך עוד יותר. דרך חופשית לשימוש, המבוססת על תוכנת קוד פתוח, ועובדת די טוב היא להשתמש בדפדפן Tor . דפדפן זה נועד להגן על פרטיותך ברמות מרובות - כולל שימוש ברשת Tor . האתר שלנו כבר נגיש דרך רשת הבצל של Tor, כלומר הגישה לאתר שלנו דרך Tor אינה מחייבת שימוש בצומת יציאה, מה שמבטל מישהו שציתות את התנועה בצומת היציאה . עם זאת, זכור כי גם בתרחיש זה, ספק האינטרנט שלך יכול לראות שאתה משתמש ב- Tor - אם כי לא בשביל מה. אתה יכול אפילו להתחבר ל- VPN ואז להפעיל את דפדפן Tor לשתי שכבות של אנונימיות; עם זאת, זכור כי ספק האינטרנט שלך עדיין יכול לראות שאתה משתמש ב- VPN בתרחיש זה - אם כי לא בשביל מה. אם אינך מעוניין שספק האינטרנט שלך יודע באילו פרוטוקולים אתה משתמש, תוכל להתחבר לרשת WiFi ציבורית ציבורית גדולה כמו ספריה, בית ספר וכו 'ואז להשתמש בדפדפן Tor.
מה אם אני לא סומך על ארצות הברית?
השרתים שלנו ממוקמים בארצות הברית. בנוסף, ספק ה- CDN שלנו, Cloudflare, הוא חברה שבסיסה בארצות הברית. ניסינו להסיר את הצורך לסמוך עלינו או על המדינה בה השרתים שלנו שוהים פשוט מכיוון שאנו לא אוספים מידע אישי, לא יכולים לפענח שום הודעה והכל נמחק זמן קצר לאחר קבלתו. עם זאת, אנו יכולים להבין קצת חוסר אמון מכיוון שהוא מבוסס אינטרנט ובמיוחד אם אתה גר במדינות מסוימות. יש לנו כמה תוכניות להציע אפשרויות באיסלנד ובשוויץ לאנשים שמתקשים לסמוך על ארה"ב. אנא יידע אותנו אם זה חל עליך, מכיוון שלא יהיה לנו מוטיבציה להציע חלופות אלא אם כן יש ביקוש אמיתי.
מה אתה עושה כדי למנוע דואר זבל?
בכל פעם שאתה מאפשר למישהו לפרסם הודעה שניתן להעביר באמצעות קישור, אתה מזמין שולחי דואר זבל. ריסון הבעיה אינו פשוט לחלוטין. איננו רוצים לטעון CAPTCHA של צד שלישי כחלק מתהליך שליחת ההודעות מכמה סיבות:
- אנו שונאים CAPTCHAs - הם לוקחים זמן ומעצבנים
- טעינת JavaScript של צד שלישי יכולה להיות פולשנית לפרטיות וביטחון
- הפעלת CAPTCHA משלנו פירושה שאנחנו נרשמים למשחק אינסופי של ואק-שומה
- בסופו של דבר אנשים עשויים לרצות להיות מסוגלים לתקשר עם שירות זה דרך ה- API
- הגדלת מספר האיטרציות הנדרשות של PBKDF2 / SHA-256
ניתן לאחזר את כל ההודעות מספר מועט של פעמים - מאפיין לא מושך עבור שולחי דואר זבל מכיוון שהם מסתמכים על שליחת הודעות רבות. מכיוון שדורש דואר זבל יצטרך ליצור הרבה הודעות עבור כל קמפיין ספאם נתון - בחרנו להפוך את המשימה הזו ליקרה כל כך חישובית כדי להפוך את השימוש לרעה בשירות זה לספאם למאמץ לא מושך. זה נעשה על ידי מעקב אחר הרשתות שמפרסמות הודעות - נמדדות במונחים של סך כל ההחלפות האפשריות. מידע הרשת עצמו מגובש בצורה מאובטחת כך שלא נוכל להסיק את הרשת האמיתית מהאש. מכיוון שרשת נתונה מפרסמת הודעות נוספות, אנו מגדילים את מספר האיטרציות PBKDF2 / SHA-256 הדרושות לפרסום ההודעה הבאה. זה מהר מאוד מביא לכך שנדרש זמן רב של המעבד רק כדי לפרסם הודעה אחת. אני מקווה ששיטה זו תהיה מספקת בכדי לרסן את השימוש לרעה בספאם ובאותה עת, לא להשפיע על משתמשים אמיתיים. - אסוף דוחות זבל ממשתמשים כאשר הם מאחזרים הודעה
יש לחצן "דווח על דואר זבל" ממש מתחת להודעה כאשר משתמש מאחזר הודעה. אם הודעה היא דואר זבל, נקווה שחלק יקח את 3 השניות הנדרשות ללחיצה על כפתור זה. כאשר אנו מקבלים דוח דואר זבל, הוא מתריע בפנינו והוא גם גורם להשפעה על איטרציות ה- PBKDF2 / SHA-256 הנדרשות עבור רשת נתונה.
מדוע יש אפשרות לדרוש מהנמען להשלים CAPTCHA?
אמנם נכון שאנחנו לא אוהבים CAPTCHA, אך אנו מכירים בכך שהם משרתים מטרה ויש להם זמן ומקום (לפחות בינתיים). זוהי דרך פשוטה עבור השולח להשיג ביטחון כלשהו שהנמען הוא אנושי וכי תהליכים אוטומטיים אינם ניגשים להודעה.
מי מפעיל שירות זה ומדוע הוא בחינם?
אנחנו רק זוג חבר'ה שלפעמים נתקלנו בבעיה שאין לנו אפשרויות טובות לעזור בהגנה על פרטיותנו. לעתים קרובות זה נבע מתקשורת עם חברים ובני משפחה שלא התייחסו בזהירות רבה לאופן הטיפול שלהם במכשירים ובמידע שלהם. פעמים אחרות זה קרה בעת שימוש בפורומים מבוססי אינטרנט כמו Reddit או באמצעות מערכות תמיכה מבוססות אינטרנט. מצאנו כמה פתרונות להודעות זמניות מבוססות אינטרנט, אך אף אחד מהם לא הציע E2EE, מה שאומר שלא נוכל לסמוך עליהם. אז פשוט בנינו פיתרון משלנו והחלטנו למסור אותו כדי שאחרים יוכלו ליהנות ממנו.
כיצד אוכל לסמוך על התשובות לשאלות הנ"ל?
באמת שלא צריך לבטוח באף אתר רק בגלל שהוא אומר דברים מסוימים - זה בדרך כלל רעיון טוב לאמת טענות כלשהן. ניסינו להסיר את הדרישה לסמוך עלינו ככל האפשר באמצעות הצפנה מקצה לקצה. לדוגמה, די קל לבקר שאנחנו לא יכולים לקרוא שום הודעה מכיוון שהן מוצפנות . שמרנו גם על קוד javascript שמריץ אתר זה פשוט מאוד, כך שהוא קל לקריאה ולהבנה. הפיכת כל הקוד לקוד פתוח מאפשרת לאנשים לאמת מה פועל; עם זאת, זכור כי אין דרך לאמת באמת מה השרת פועל. אמנם נכון שחלק ניכר מדרישת האמון מוסר עם הצפנה מקצה לקצה, אך זה עדיין גורם שמשקפינו שוקלים מאוד כאשר הם מחליטים להשתמש בשירות זה או לא.