חיפוש בצ׳אט מוצפן אפשרי משום שהמכשיר המורשה לקרוא הודעות יכול גם לחפש בהן. תכנון נפוץ בונה אינדקס מקומי לאחר הפענוח. אבל הצפנה מקצה לקצה אינה מוכיחה, כשלעצמה, ששאילתות חיפוש לעולם אינן יוצאות מהמכשיר, או שכל יישומי ההודעות משתמשים באותה ארכיטקטורת חיפוש.
ההבחנה הזאת חשובה כאשר החיפוש איטי, תוצאות ישנות נעלמות או טלפון חדש אינו מוצא הודעות שנראות בטלפון הישן. כיסוי החיפוש, זמינות המפתחות וסנכרון הנתונים הם שאלות נפרדות.
איך פועל אינדקס חיפוש מקומי
יישום יכול להפוך הודעות קריאות לאינדקס המתעד אילו מונחים מופיעים באילו הודעות. החיפוש נעזר באינדקס הזה במקום לסרוק כל הודעה מתחילתה ועד סופה. התיעוד של FTS5 ב־SQLite הוא דוגמה לטכנולוגיית אינדוקס טקסט מלא; אזכורה כאן אינו מעיד שלקוח מסוים של Livara משתמש ב־FTS5.
תכנון מקומי טיפוסי כולל ארבעה שלבים:
- הורדה או קבלה של ההודעה המוצפנת.
- פענוחה באמצעות מפתחות המכשיר המורשים.
- הוספת תוכן שניתן לחפש בו לאינדקס המקומי.
- החזרת תוצאות מהנתונים הזמינים כרגע באותו מכשיר.
האינדקס רגיש. גם אם אינו שומר משפטים שלמים, מונחים והפניות יכולים לחשוף תוכן שיחות. האחסון שלו, הגיבויים, התנהגות המחיקה ובקרות הגישה ראויים לאותה תשומת לב כמו מסד נתוני הצ׳אט.
האם חיפוש בצד השרת תמיד אומר שהשרת קורא הכול?
לא. אינדוקס רגיל של טקסט גלוי בשרת מעניק לשירות גישה לתוכן המאונדקס, אך הוא אינו התכנון האפשרי היחיד לחיפוש מרוחק. מחקר קריפטוגרפי על הצפנה סימטרית המאפשרת חיפוש מתאר דרכים לחפש בנתונים מוצפנים המאוחסנים אצל גורם חיצוני במסגרת מודלי אבטחה מוגדרים.
לטכניקות האלה יש הנחות משלהן ואפשרויות לדליפת מידע. בדיקה מועילה שואלת מה השרת לומד על שאילתות חוזרות, רשומות תואמות, דפוסי גישה וגודלי תוצאות. לא ״החיפוש מתבצע בענן״ ולא ״הנתונים מוצפנים״ מכריעים לבדם בשאלות האלה.
| תכנון | יתרון מעשי | שאלה לבדיקה |
|---|---|---|
| אינדקס מקומי | מאפשר לחפש בהיסטוריה הזמינה ללא שאילתה מרוחקת | האם האינדקס מוצפן במנוחה ומוחרג מגיבויים לא בטוחים? |
| אינדקס טקסט גלוי בשרת | אינדוקס מרכזי וחיפוש בנתונים המאוחסנים | למי יש גישה לתוכן, לשאילתות וליומנים? |
| שיטת חיפוש מרוחק מוצפן | עשויה לתמוך בשאילתות מוגדרות על נתונים מוגנים | אילו דליפות מידע והנחות אמון מתירה השיטה? |
| חיפוש משולב בציבורי ובפרטי | טיפול שונה בתוכן ציבורי ובתוכן פרטי | האם תחום החיפוש ברור למשתמש? |
אי אפשר לדרג מהירות לפי הטבלה הזאת. החומרה, איכות האינדקס, נפח ההודעות, השהיית הרשת והמימוש — כולם חשובים. לא נערכה בדיקת השוואת זמנים לצורך המאמר הזה.
למה הודעות עלולות להיעדר מהחיפוש
לפני שמסיקים שההיסטוריה אבדה, בדקו את היקף הבעיה:
- האם ההודעה נראית בשיחה? אם לא, ייתכן שהחיפוש משקף היסטוריה לא זמינה ולא אינדקס פגום.
- האם נבחרו השיחה או החשבון הנכונים? מסננים לפי תאריכים, שולחים ומדיה עלולים להוציא תוצאה שהייתה מתאימה בלעדיהם.
- האם המכשיר החדש קיבל את ההיסטוריה ואת חומר הפענוח? שחזור מפתח זהות אינו זהה אוטומטית לשחזור כל הודעה.
- האם האינדוקס הסתיים? ייבוא גדול וסנכרון שנקטע עלולים להשפיע על הכיסוי.
- האם החיפוש מזהה את צורת המונח? התאמת ביטויים, איות, פיסוק וחלוקת השפה לאסימונים עשויים להשתנות.
השתמשו בביטוי בדיקה תמים וייחודי בשיחה שבשליטתכם. בדקו אם הוא מופיע בחיפוש לפני ניתוק הרשת ואחריו. כך אפשר לבסס עובדה מצומצמת לגבי זמינות מקומית; אין בכך הוכחה שהיישום לעולם אינו שולח טלמטריה או נתוני חיפוש כשהוא מחובר לרשת.
מה אפשר לומר על Livara?
דף האבטחה של Livara מציין שתוכן ההודעות הפרטיות מוצפן, בעוד שהניתוב, החברות, מצב המסירה והטקסט המוצפן תומכים בסנכרון. התיעוד הציבורי שלה אינו ראיה מספקת לטענה בדבר מנוע חיפוש מקומי מסוים, חיפוש אוניברסלי ללא חיבור לרשת, אפס טלמטריה של שאילתות או השפעה מדודה על הסוללה.
לערוצים ציבוריים יש גבול פרטיות שונה מזה של צ׳אטים פרטיים. שירות יכול לאנדקס תוכן ציבורי בלי לטעון אותה טענה לגבי שיחות פרטיות. עיינו במודל האיומים לפני שתתייחסו לתוצאה של חיפוש כלל־מערכתי כאל מידע חסוי.
שאלות שכדאי לשאול ספק
שאלו אילו הודעות מאונדקסות, היכן האינדקס נמצא, האם טקסט השאילתה מועבר או נרשם ביומן, מה מקבל מכשיר מקושר וכיצד מחיקת הודעה משפיעה על אינדקסים וגיבויים. תשובה ברורה צריכה לציין את הלקוח ואת הגרסה, ולא להסתמך על הביטוי ״חיפוש E2EE״.
חיפוש הוא תכונה בעלת זרימת נתונים משלה. העריכו את הזרימה הזאת לצד הצפנת ההודעות, במקום להניח שההצפנה עונה על כל שאלה לגביה.
