מה אתרים יכולים לדעת עליך

Facebook Pixel

פיקסל אמיתי, שנוצר במיוחד להדגמה הזאת בחשבון ה-Meta Business של הירוקים הוד השרון (goinfo.co.il, מזהה 37595343516747103). הפעלה שולחת אירוע PageView אמיתי ל-Meta וקובעת עוגיית מעקב _fbp - אם אתם מחוברים לפייסבוק בדפדפן הזה, Meta יכולה לשייך את הביקור הזה לחשבון שלכם.

הפעל Facebook Pixel (חי)

עוגיות שנקבעו: (המתג כבוי)

בקשות רשת שיצאו בפועל

Twitter / X Widgets

טוען את platform.twitter.com/widgets.js האמיתי. גם בלי לצייר טוויט על המסך, עצם טעינת הסקריפט שולחת ל-X את ה-Referrer, כתובת ה-IP וה-User-Agent שלכם, ומנסה לקבוע עוגיית זיהוי (guest_id) - חלק מהדפדפנים חוסמים אותה כברירת מחדל כעוגיית צד-שלישי.

הפעל Twitter/X widgets.js (חי)

עוגיות שנקבעו: (המתג כבוי)

בקשות רשת שיצאו בפועל

לא - זו קריאה חד-כיוונית

הבקשות ל-facebook.com/tr/... ול-platform.twitter.com/widgets.js חוזרות עם קוד 200, אבל בלי גוף תשובה שימושי - בדיוק כמו טעינת פיקסל שקוף בגודל 1×1. שום קוד שרץ בעמוד הזה לא מקבל בחזרה JSON עם הפרופיל, המייל או שם המשתמש שלכם. האתר לא "יודע" יותר אחרי שליחת הבקשה משהוא ידע לפניה - הוא רק שלח החוצה IP, User-Agent, כתובת העמוד ועוגיית מעקב.

אז איפה כן קורה השיוך לחשבון שלכם?

אצל מטא/X עצמן, לא אצל האתר. אם הדפדפן שלכם מחובר במקביל לפייסבוק, עוגיית ה-_fbp שנקבעה כאן יכולה להיות מקושרת בשרתים של מטא לחשבון שלכם. זה קורה מאחורי הקלעים ולעולם לא חוזר לאתר כתשובה - האתר רק רואה בהמשך נתונים מצטברים ואנונימיים ב-Meta Ads/Events Manager ("214 מהמבקרים שלכם התאימו לקהל X"), לא שם או מייל של מבקר בודד.

דרך שבה אתר כן יכול לשלוח מייל או טלפון ישירות היא פיצ'ר בשם Advanced Matching (מטא) או Enhanced Conversions (גוגל) - שם האתר עצמו שולח גיבוב (hash) של המייל/הטלפון כדי לשפר את ההתאמה לחשבון המחובר. בבקשה שנשלחת מהפיקסל של ההדגמה הזאת אין שדות כאלה (em, ph) - זה PageView רגיל, לא זיהוי מתקדם. אתרי קופה והרשמה רבים כן מפעילים את זה.

אז פייסבוק/גוגל "מוכרים" את המידע כשמופיעה מודעה שמתאימה למה שגלשתי?

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

עם זאת, מבחינה משפטית זה כן נחשב "מכירה" או "שיתוף" של מידע אישי - ברגולציות כמו ה-CCPA הקליפורני ההגדרה החוקית של "מכירת מידע" כוללת בדיוק את מנגנון ההתאמה הזה מבוסס פיקסלים ועוגיות, ומשם מגיע הכפתור "Do Not Sell or Share My Personal Info" שרואים באתרים אמריקאיים.

למה ל-Twitter/X זה פחות "נדבק" מאשר לפייסבוק

בבדיקה בפועל בדפדפן: העוגייה _fbp של מטא נקבעה בהצלחה, אבל guest_id של X לא נקבעה. ההבדל טכני, לא כוונה טובה יותר של X: מטא קובעת את _fbp באמצעות קוד שרץ על גבי goinfo.co.il עצמו, כך שלדפדפן זו עוגיית צד ראשון (first-party) שלא נחסמת כברירת מחדל. X מנסה לקבוע את guest_id משורת Set-Cookie שמגיעה ישירות מהשרת של platform.twitter.com - עוגיית צד-שלישי אמיתית, שדפדפנים מודרניים (כולל Chrome כברירת מחדל) חוסמים. הבקשה עצמה עדיין יוצאת ועדיין חושפת IP, Referrer ו-User-Agent - רק ההשתרשות לביקור חוזר היא שנכשלת.

הזיהוי החזק באמת: התחברות עם Google/Facebook

כל מה שתואר למעלה הוא מעקב פסיבי - האתר לא באמת מקבל בחזרה מי אתם, רק שולח סימנים החוצה. יש דרך אחת שבה אתר כן מקבל את הזהות שלכם ישירות ובבירור: כפתור "התחבר עם Google" או "התחבר עם Facebook" - למשל בדף דיווח על גומה ריקה בפרויקט אחר של אותו מפתח, שמשתמש ב-accounts.google.com/gsi/client (Google Identity Services).

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

הסולם המלא, מהחלש לחזק: טביעת אצבע אנונימית (IP/User-Agent הבסיסיים למעלה) ← עוגיית מעקב פסאודונימית חוצת-אתרים (_fbp, _ga) ← מסירת זהות מפורשת בהתחברות (OAuth). בכל שלב האתר מבקש יותר, ורק בשלב האחרון הוא באמת מקבל את השם והמייל שלכם - לא רק חברת פרסום שיודעת עליכם משהו בלי לשתף אותו הלאה.

אז אם מתקינים Ghostery ו-uBlock, מוגנים הרבה יותר?

כן, וזו לא רק תיאוריה - בדיקה בפועל של שני המתגים למעלה, פעם בפיירפוקס עם Ghostery ו-uBlock Origin מותקנים ופעם בכרום עם חסימה מדומה ברמת הדומיין, נתנה תוצאה חדה: ל-Twitter/X הסקריפט (widgets.js) לא נטען בכלל - הכפתור נשאר תקוע לצמיתות על "טוען…" כי אף בקשה לא יצאה. לפייסבוק, קובץ הבסיס (fbevents.js) כן נטען בפיירפוקס, אבל הבקשה האמיתית שמכילה את הנתונים - קריאת ה-PageView ל-facebook.com/tr וקריאת ה-signals/config - נחסמו, ועוגיית _fbp מעולם לא נקבעה. בלי העוגייה הזו אין למטא שום דבר לקשר בין הביקור הזה לביקורים אחרים או לחשבון שלכם.

ההבדל בין השניים מסביר איך רשימות חסימה אמיתיות (EasyPrivacy, Disconnect - הרשימות שעליהן מבוססים גם Ghostery וגם uBlock) עובדות בפועל: הן פוגעות בנקודתיות בכתובות המעקב הידועות (למשל facebook.com/tr) ולא בהכרח בקובץ ה-SDK הבסיסי עצמו, כדי לא לשבור אתרים שבודקים אם fbq קיים. חסימה גורפת של דומיין שלם (מה שסימלנו בכרום) עובדת טוב יותר אבל יכולה לשבור עמודים שתלויים בקובץ שנחסם.

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

Chrome מול Firefox - אותו שם תוסף, הגנה שונה

גם Ghostery וגם uBlock זמינים בחנות התוספים של Chrome, אבל כרום נמצא באמצע מעבר כפוי ל-Manifest V3 שמצמצם בדיוק את היכולת החזקה ביותר של חוסמי תוכן - חסימת בקשות רשת ברמה נמוכה לפני שהן יוצאות (webRequest חוסם). הגרסה התואמת ל-Manifest V3, "uBlock Origin Lite", נשענת על מנגנון מוגבל יותר (declarativeNetRequest) עם סט חוקים דליל בהרבה מהגרסה המלאה. פיירפוקס לא עבר את המעבר הזה ועדיין מריץ את uBlock Origin המלא, עם כל עוצמת החסימה שלו. כלומר: התקנת אותם שני שמות תוספים בכרום ובפיירפוקס לא נותנת בהכרח את אותה רמת הגנה - זה בדיוק ההבדל שבא לידי ביטוי בבדיקה למעלה.