הסרת ממסר push משנה מי משתתף במסירה; היא לא מעלימה את מטא־נתוני הניתוב.
פרטיות ההתראות ב־Android תלויה ביותר מאשר בשאלה אם השיחה עצמה מוצפנת. שירות push יכול לנתב התראה בלי לקבל טקסט שיחה קריא, אך הוא עדיין משתתף במסירה. חיבור ישיר מסיר את המתווך המסוים הזה, אבל לא מוחק מטא־נתונים משרת המסנג׳ר או מהרשת.
לכן ההשוואה המועילה אינה ״FCM מדליף הכול; sockets מסתירים הכול״. השאלות הן: אילו נתונים מגיעים לכל צד, עד כמה התכנון שנבחר פועל באופן אמין ברקע, ומה המשתמש יכול לאמת?
מה FCM מעביר
Firebase Cloud Messaging מבחין בין הודעות התראה, שהפלטפורמה יכולה להציג, לבין הודעות נתונים שקוד היישום מטפל בהן. המטען עשוי להכיל טקסט התראה קריא, נתונים מוצפנים או אות מינימלי שמורה ליישום למשוך עדכונים. לתכנונים האלה השלכות שונות על הפרטיות. סוגי הודעות FCM.
Firebase מתעד הגנת TLS בין השרת השולח, FCM והמכשיר, אבל מציין ש־FCM אינו מספק אוטומטית הצפנה מקצה לקצה ברמת היישום. מטענים רגישים דורשים הגנה מתאימה מעל שכבת התעבורה. במסנג׳ר פרטי, הגנה זו חייבת לשמר את גבול נקודות הקצה המתוכנן; הצפנת נתונים בשרת שכבר מכיר את הטקסט הגלוי היא מודל אמון אחר. הנחיות הצפנה של FCM.
מה מזהי ניתוב מוכיחים — ומה לא
שליחת push ממוקדת זקוקה למזהה של מופע היישום המתאים. זה אינו מזהה קבוע ואוניברסלי של אדם. רישומים יכולים להשתנות או לפוג; הנחיות Firebase הנוכחיות מכסות רישומים מבוססי התקנה וגם אסימונים ותיקים. תיעוד ניהול רישומים.
ספק push משתתף בהכרח בטיפול בבקשות ובמסירה. הדבר יוצר שיקולים הנוגעים למטא־נתונים, אך משך השמירה המדויק, הקישור לחשבונות והנראות דורשים תיעוד או מדידה. אין להסיק שהתראה כללית ״הודעה חדשה״ חושפת אוטומטית את האדם השולח, הנמען וכל הגרף החברתי.
מתאם תזמון עשוי להיות שיקול במודל האיומים, במיוחד כשצופה רואה כמה זרמי תעבורה רלוונטיים. הדיוק שלו תלוי בתצפיות הזמינות, בקיבוץ משלוחים, בפעילות ברקע ובגורמים נוספים. ״יכול לספק אות״ אינו שקול ל״משחזר בקלות כל שיחה״.
השוואת FCM וסנכרון ישיר
| שאלת תכנון | Push דרך FCM | סנכרון ישיר ברקע |
|---|---|---|
| האם משתתף ממסר push של צד שלישי? | כן | לא עבור החיבור הישיר הזה |
| האם ניתן להחריג מהממסר טקסט שיחה קריא? | כן, בתכנון מטען מתאים | המסנג׳ר עדיין צריך E2EE מתאים |
| האם שרת היישום רואה נתוני חיבור או מסירה? | לעיתים קרובות; תלוי בארכיטקטורה | כן, הוא משרת את הלקוח ישירות |
| האם מובטחת מסירה מיידית? | לא | לא |
| מה צריך לבדוק? | תוכן המטען, מחזור חיי האסימון, עיכובים ומנגנון חלופי | מגבלות מערכת ההפעלה, חיבור מחדש, עלות בסוללה ועיכובים |
תשאול ישיר או sockets יכולים לצמצם תלות בספק push. הם אינם יוצרים אנונימיות אוטומטית ואינם מונעים ממערכת ההפעלה, מהרשת או מתשתית היישום עצמו לצפות בכל האירועים הרלוונטיים.
מדוע WorkManager אינו תעבורה להודעות מיידיות
Android מגביל עבודה ברקע כדי לנהל משאבים. WorkManager מתזמן עבודה מתמשכת במסגרת המגבלות האלה; אזכורו בארכיטקטורה אינו אומר שחיבור יישאר פעיל ברציפות או שכל הודעה תגיע מיד. הגדרות היצרן, מגבלות הסוללה ומצב היישום חשובים. מגבלות עבודה ברקע ב־Android.
ביטול מגבלות צריכת חשמל עשוי לשנות את האמינות ואת השימוש בסוללה, אך אין להחיל החרגות גורפות באופן עיוור. בדקו את המצב הנתמך של היישום במכשיר עצמו. הסרת רכיבי Google אינה מלמדת יישומים אוטומטית להשתמש במנגנון מסירה חדש; חלק מהפונקציונליות עלול להפסיק לפעול.
מה Livara אומרת על התראות
תיעוד האבטחה של Livara אומר שהתראות push של הודעות מוצפנות אינן מכילות פרטי הודעה או שמות. הוא גם אומר שהשירות שומר מטא־נתונים תפעוליים ואסימוני push. אלה טענות על המוצר, לא ראיה לכך ש־Livara אינה משתמשת ב־FCM או שמטא־נתוני המסירה מוסתרים מכל מתווך.
יש לקרוא את התיעוד הציבורי לצד מודל האיומים. מאמר זה אינו טוען לקיומה של אפשרות סנכרון ישיר שנבדקה, ליתרון מדוד בצריכת סוללה או למדיניות מסוימת של שמירת יומנים במקום שבו אלה לא הודגמו.
בדיקה מעשית של התראות
השתמשו בהודעת בדיקה תמימה. השוו מה מופיע כשהטלפון פתוח, נעול, לא מקוון ואז מחובר מחדש. בדקו בנפרד תצוגות מקדימות במכשירים מקושרים ויישומים בעלי גישה להתראות. הגדרת מסך נעילה שולטת בתצוגה המקומית; היא לא בהכרח משנה את מטען ה־push בצד השרת.
למפתחים: בדקו מטעני בדיקה ותעדו רק את נתוני האבחון המינימליים. מדדו מסירה בתנאי סוללה וקישוריות מציאותיים, ותעדו מה פירושם בנפרד של ״נשלח״, ״התקבל לעיבוד״, ״נמסר״ ו״הוצג״. גם הפרטיות וגם האמינות משתפרות כשהגבולות האלה מפורשים.
