@שלומפער
אני לא מבין בזה, אבל הבינה כותבת ש:
מעקב, איסוף נתונים או שליחה לגורם חיצוני?
בקוד הזה אין שום שליחה לגורם חיצוני. כל התעבורה הרשתית היא אל שרתי גוגל בלבד:
https://mail.google.com/mail/u/{idx}/feed/atom — קריאת הפיד
https://mail.google.com/mail/u/{idx}/?ui=2&view=pt... — קריאת שרשור
נקודות רלוונטיות:
אין fetch/XMLHttpRequest/sendBeacon לאף דומיין אחר. אין כתובות IP, אין אנליטיקס, אין טלמטריה.
הקוד נוצר אצלך — הודעת ה-web_search שהצטרפה היא הקשר מערכתי, לא קוד התוסף.
הנתונים נשמרים מקומית בלבד ב-chrome.storage.local:
used3 — עד 300 קודים שכבר טופלו (כדי למנוע כפילות).
inited — אילו חשבונות כבר אותחלו.
הלוגים (console.log כשמכבים DEBUG הם כבויים) נכתבים לקונסול של ה-service worker בלבד — לא נשלחים לשום מקום.
הסתייגויות שחשוב להבין
הקוד כן קורא ומנתח תוכן מיילים שלך (נושא, תקציר, ולפעמים גוף מלא) — אבל הכל עובר בזיכרון מקומי ומושלך בסוף הריצה. הפיד של Gmail מוגש בשרת גוגל; הקריאה אליו היא בדיוק כמו לפתוח את Gmail בדפדפן.
מה שכן מהווה "חשיפה" הוא לא התוסף הזה, אלא ההרשאות שהוא דורש:
הרשאה משמעות
host_permissions: <all_urls> התוסף יכול לקרוא ולשנות כל דף שתפתח. הוא משתמש בזה רק להזרקת המילוי, אבל הטכנית זו הרשאה רחבה מאוד.
scripting מאפשר הזרקת סקריפט לכל דף פעיל.
storage שמירה מקומית.
הערה אבטחתית: אם התוסף הזה יותקן מהחנות, עדכון עתידי של התוסף עלול להוסיף שליחה החוצה — שליטה על הגרסה חשובה. ואם התוסף נכתב על ידי מישהו אחר, אין דרך לוודא שאין גרסה שונה מהמוצגת. כדי לוודא שאין שליחה החוצה, מספיק לחפש בקוד fetch, XMLHttpRequest ו-https:// שאינם mail.google.com — לא נמצא כאלה.
כמה זה שוקל בריצה?
"משקל" תלוי אם מתכוונים לגודל הקובץ או לעומס הריצה.
גודל
manifest.json — פחות מקילובייט.
background.js — כ-10–12KB טקסט (כ-250 שורות).
popup.html + popup.js — כ-4–5KB.
סה"כ: פחות מ-20KB — תוסף זעיר במיוחד.
עומס ריצה (זו הבעיה האמיתית)
התוסף עובד קשה באופן קבוע, לא רק כשמגיע מייל:
לולאת סריקה כל 20 שניות (setInterval(check, 20000)) — כלומר 180 סריקות בשעה, כל אחת מהן:
fetch אחד לפיד ה-RSS לכל חשבון מחובר (עד 3 בקשות).
אם יש הודעות חדשות עם קודים — קריאת שרשור מלא (עד 3 בקשות נוספות).
החזקת ה-service worker ער (keep-alive): setInterval כל 15 שניות ששולח getPlatformInfo. זה נגד המודל של Manifest V3 (שמיועד לכבות workers לא-פעילים), וצורך סוללה ו-CPU כשהדפדפן פתוח — גם אם אין מיילים.
התראת alarms כל 0.5 דקות — גורמת ל-worker להתעורר שוב ושוב.
allFrames: true בהזרקה — סורק כל iframe בדף הפעיל, מה שיכול להכפיל עבודה באתרים כבדים.
הערכה גסה של עלות: כל סריקה ללא קוד חדש = בעיקר בקשות רשת קלות ל-Gmail (שכבר פתוח אצלך) + פרסור XML קטן. הבקשה החוזרת כל 15 שניות היא הקלה אבל קבועה. בחשבון מחובר יחיד סה"כ צריכה קטנה יחסית, אבל רציפה ולאורך כל זמן שהדפדפן פתוח. אם כרום פתוח 12 שעות ביום, מדובר בכ-~2,160 סריקות ו-~2,880 קריאות keep-alive ליום.
השוואה: מה היה אפשר לעשות אחרת
לתפוס את האירוע של מייל חדש במקום לסקור — למשל לקצר את הבדיקה, או להסתמך רק על alarms בלי ה-setInterval הכפול.
להעלות את CHECK_EVERY_SECONDS ל-60+ — הפחתה של פי 3 בצריכה בלי לפגוע בזמן התגובה למייל OTP.
להסיר את ה-keep-alive כל 15 שניות — הוא הכבד ביותר ולא באמת נצרך אם ההתראה כל 0.5 דקות מספיקה.
טבלת סיכום
מדד מצב
שליחה לגורם חיצוני אין
שמירה חיצונית / אנליטיקס אין
שמירה מקומית used3, inited ב-storage.local
קריאות רשת רק ל-mail.google.com
גודל קובץ קטן מאוד (<20KB)
עומס ריצה ️ גבוה יחסית — סריקה כל 20 שנ' + keep-alive כל 15 שנ'
הרשאת all_urls ️ רחבה מאוד (נדרשת למילוי, אבל מסוכנת אם הגרסה משתנה)
אם תרצה, אוכל להראות בדיוק איך למצוא בקוד כל מקום שיוצא לרשת (חיפוש fetch/XMLHttpRequest), או להציע גרסה "רזה" שמפחיתה את תדירות הבדיקה בלי לפגוע בזיהוי הקוד.
היא מדברת לעניין?