edgeglint: למה בנינו אנליטיקה מודעת לפרטיות על Cloudflare

למסלולי ההתקנה ולרמות המדידה, קראו את עמוד הפרויקט של edgeglint.

edgeglint היא ההבטחה שלנו לאנליטיקה מודעת לפרטיות על Cloudflare: יותר תובנות מ־Cloudflare Web Analytics באמצעות עומק גלילה, ספירת קליקים לפי רכיב, שגיאות JavaScript ו־Core Web Vitals, ללא עוגיות אנליטיקה או מזהי מבקרים. כלל המדינות הנוכחי שלנו מונע מדידה ב־edgeglint עבור האזור הכלכלי האירופי, בריטניה, שווייץ, מדינות לא ידועות ו־Tor. זהו גבול מוצר שמרני במכוון, ולא קביעה שאיסוף במקומות אחרים אינו דורש הסכמה או שהסרת עוגיות הופכת אותו לחוקי.

אני Sam Jacobson מ־Dataxad. בנינו את edgeglint כדי להבין את האתר שלנו בלי לבנות היסטוריה של האנשים שמשתמשים בו. המאגר הציבורי של edgeglint נפתח היום. זהו המחקר, הפשרות והניסיון מפריסות שעליהם הוא מבוסס.

תצוגה של לוח הבקרה עם נתוני הדגמה. המספרים אינם נתוני התעבורה של Dataxad.

למה לבנות עוד כלי אנליטיקה?

Cloudflare Web Analytics היא נקודת מוצא טובה, אבל אינה עונה על שאלות האינטראקציה שלנו. היא חינמית בכל המסלולים, אינה משתמשת בעוגיות או ב־localStorage, וכוללת Core Web Vitals. בהתקנה אוטומטית באתר שעובר דרך הפרוקסי של Cloudflare, דיווחי המדידה נשלחים לדומיין האתר עצמו; הסקריפט עדיין נטען מ־static.cloudflareinsights.com. אין בה עומק גלילה, נתוני קליקים, מפות חום או שגיאות JavaScript. השאלות הנפוצות עדיין אומרות שאירועים מותאמים אישית אינם זמינים.

השאלה של Dataxad הייתה ממוקדת: האם אפשר ללמוד באילו רכיבים משתמשים, עד לאן קוראים גוללים והיכן JavaScript נכשל, בלי לזהות מבקרים? edgeglint שומרת מדידות ברמת העמוד ונתונים מצרפיים גסים, במקום ציר זמן אישי. בגרסה הראשונה אין מדד מבקרים ייחודיים, שחזור סשנים או מעקב סמן. היא גם מוותרת על נתוני תעבורה מאזורים שלמים, במקום להניח שדיווח ללא עוגיות פטור מהסכמה. זו הפשרה שבחרו Sam Jacobson ו־Dataxad: נתוני אינטראקציה שימושיים יותר במקום שבו האיסוף מותר, ופחות כיסוי במקום שבו הבסיס המשפטי עדיין אינו ברור. ״טובה יותר״ פירושו כאן מתאימה יותר למשימה המסוימת הזאת, ולא עשירה יותר בתכונות מכל פלטפורמת אנליטיקה. Cloudflare כבר מספקת Core Web Vitals; התוספת שלנו היא שילוב מדדי הביצועים עם מדידות האינטראקציה והשגיאות שהיינו צריכים, תחת מדיניות איסוף שאפשר לבדוק ולבחון.

גם מוצרי Cloudflare הסמוכים לא סגרו את הפער. חנות Apps הישנה נסגרה; הודעות מעבר מצד שלישי מציינות הפסקת פעילות ב־31 באוגוסט 2024 והפסקת התקנות חדשות עד 15 בינואר 2025. כפתורי פריסה והתבניות של Cloudflare נשארו, אך באוסף התבניות לא הייתה תבנית אנליטיקה בתמונת המצב של המחקר שלנו.

Custom Dashboards אינם מונים את Analytics Engine בין מקורות הנתונים הנתמכים. Zaraz מנהלת כלים מצד שלישי והסכמה; היא אינה מנגנון האיסוף הישיר שחיפשנו. רכיב מנוהל מותאם אינו יכול לחשוף נקודת קצה ציבורית.

מה מצאנו בשוק?

מצאנו אבני בניין שימושיות, אך אף אחת לא תאמה בדיוק את בחירות האחסון והאיסוף שלנו. הטבלה משקפת תמונת מצב מ־21 באוקטובר 2026, ולא ספירת כוכבים חיה. ל״א פירושו לא אומת בתקציר המחקר שלנו, גם בתאי התכונות: ל״א אינו ראיה שתכונה אינה קיימת. ארבע התכונות מופיעות בסדר: עומק גלילה / קליקים לפי רכיב / שגיאות JavaScript / שחזור סשנים.

כמה הבדלים חשובים יותר ממספר הכוכבים. Plausible מוחקת את ה־salt היומי מדי 24 שעות וכוללת עומק גלילה מובנה. Umami מגבבת אתר, IP, ‏User-Agent, ‏salt וסוד שרת. InsightFlare תומכת באירועים מותאמים וב־Web Vitals. Rybbit מציעה משפכים, שגיאות, שחזור סשנים ו־Web Vitals בענן. אלה בחירות מוצר שונות, ולא הגדרות זהות של פרטיות. לפי התקציר שלנו אין מפות חום ב־Plausible, ‏Umami או Rybbit.

השאלות הנפוצות של Clarity קובעות שנדרשת הסכמה מפורשת לפני הצבת עוגיות באזור הכלכלי האירופי, בריטניה ושווייץ. PostHog מסבירה שמזהה ייחודי מתמשך הוא מידע אישי לפי GDPR. אפילו עמוד ה־GDPR של Mouseflow, לצד הצהרות התאימות שלו, אומר שלקוחות עשויים להזדקק להסכמה פעילה ומפורשת. תוויות שיווקיות אינן קובעות את הבסיס המשפטי של התקנה מסוימת.

למה לא לפצל את Counterscale?

Counterscale הייתה הקרובה ביותר מבחינת ארכיטקטורה: Workers, ‏Analytics Engine, אינדקס אתר וארכיון R2. אבל ספירת הביקורים שלה משתמשת במטמון: קוראת If-Modified-Since ומגדירה Last-Modified; מנגנון האיסוף גם שומר User-Agent גולמי. הבחירות האלה מתנגשות עם הגבול שלנו, שמוציא מזהים מהתמונה.

זו גם אפליקציה משמעותית: כ־8,500 שורות שאינן בדיקות ו־11,100 שורות בדיקה, כולל לוח בקרה ב־React Router ומתקין. הנחיות התרומה מתארות פרויקט מתנדבים; בתמונת המצב שלנו בקשות משיכה חיצוניות מוזגו בתוך ארבעה ימים עד ארבעה חודשים, ובקשת אבטחה מ־16 באוקטובר עדיין הייתה פתוחה. רצינו חוזה קטן ושונה, ולא פיצול שנצטרך לבטל את הנחות היסוד שלו. גם dytsou/site הדגים תאי מפת חום של קליקים ב־Analytics Engine; אנחנו בחרנו בספירת רכיבים ללא קואורדינטות.

האם בלי עוגיות פירושו בלי הסכמה?

לא. הסרת עוגיות אינה מסירה כשלעצמה את כללי ePrivacy. הנחיות EDPB ‏2/2023, שגרסתן המתוקנת אומצה ב־7 באוקטובר 2024, מתייחסות למידע שנוצר מקומית ונשלח לשרת כגישה למידע בציוד הקצה. תחולתן כוללת מנגנוני מטמון ובנסיבות מסוימות גם מעקב לפי IP בלבד. תחולת הכלל אינה אומרת אוטומטית שנדרשת הסכמה; עדיין צריך לבחון פטור מתאים.

ההבחנה הזאת עיצבה את edgeglint יותר מכל השוואת תכונות. צבירת נתונים חשובה, אך אינה מוציאה אוטומטית דיווח JavaScript מתחולת סעיף 5(3). חוות דעת WP29 ‏04/2012 אומרת שעוגיות אנליטיקה של האתר אינן הכרחיות לחלוטין, ובמקביל מכירה בסיכון מוגבל עם צבירה, אפשרות סירוב ואנונימיזציה. פסק הדין Planet49 של בית הדין האירופי קובע שכלל ההסכמה חל גם כשהמידע אינו אישי. Breyer קובע שכתובות IP דינמיות יכולות להיות מידע אישי. עבור Sam Jacobson ו־Dataxad, המקורות האלה תומכים בזהירות ביחס למנגנון האיסוף עצמו, ולא רק בהבטחות לגבי מסד הנתונים הסופי. הם אינם מוכיחים ש־edgeglint עומדת בתנאי פטור. בחרנו בכלל החרגה לפי קוד מדינה באזורים שבהם שאלת ההסכמה רגישה במיוחד; כל מפעיל עדיין צריך לבדוק את הדין בכל מקום שבו המדידה פועלת.

הכללים הלאומיים מוסיפים מורכבות:

• גרמניה: המחקר שלנו מצא שסעיף 25 ל־TDDDG דורש הסכמה לשמירה או לקריאה של מידע מהמכשיר, ללא פטור כללי של DSK למדידת תפוצה.
• בריטניה: החריג למטרות סטטיסטיות בנספח A1 של PECR, שבתוקף מ־5 בפברואר 2026, כולל דרישה לאפשר התנגדות. סעיף 5(2) מוציא מהחריג מידע שנפלט אוטומטית. השאלה אם כותרות HTTP נכללות בניסוח הזה עדיין פתוחה; ראו גם את הנחיות ICO לגבי החריגים וכן החקיקה המתקנת.
• צרפת: ההנחיות העדכניות של CNIL מאפשרות פטור מהסכמה רק כאשר מדידת הקהל עומדת בתנאים מוגדרים. הן דורשות סטטיסטיקה אנונימית עבור האתר או האפליקציה של המפעיל בלבד, ללא מעקב בין אתרים או שילוב המידע עם עיבודים אחרים. על מפעיל האתר לבחון את הכלי כפי שהוגדר ולתעד את הבסיס לכל פטור; תווית שיווקית של פרטיות אינה מספיקה.

ההחלטה שלנו תפעולית: קוד המדינה של הבקשה לפי Cloudflare קובע אם הקצה מחזיר סקריפט מעקב ריק ומשליך דיווחים מהאזור הכלכלי האירופי, בריטניה, שווייץ, מדינות לא ידועות ו־Tor. מיקומו הפיזי של המבקר עשוי להיות שונה מקוד המדינה. Cloudflare עצמה מציעה הגדרה להחרגת האיחוד האירופי, אך הכלל שלנו כולל יותר קודי מדינה. כך נמנעת מדידה של edgeglint עבור בקשות אלה; Cloudflare עדיין מטפלת בבקשת הדף ועשויה לשמור יומני תפעול. איננו מתארים את edgeglint כ״תואמת רגולציה״ או כ״ללא צורך בבאנר״.

מה edgeglint שומרת בפועל?

רק מערך המדידות הנוכחי, Tier 1, פעיל. שמות של רמות מדידה אינם יוצרים פטור משפטי. שדות הנתונים מוגבלים במכוון:

• נתיבים מנורמלים: מקטעים מרשימת היתר, החלפת מקטעים שנראים כמזהים ב־:x, ורשימת נתיבים שנוצרת מבניית האתר וממפה נתיבים לא ידועים ל־/other.
• דומיין רשום של האתר המפנה או other; מדינה; קבוצת רוחב חלון הדפדפן s/m/l; גרסאות ראשיות מוגבלות של הדפדפן ומערכת ההפעלה.
• גלילה במדרגות של 10 אחוזים; זמן שהייה בחזית במדרגות של חמש שניות; יציאה מהירה בתוך פחות מחמש שניות, שנקבעת ב־pagehide.
• LCP במדרגות של 100 מילישניות ו־CLS במדרגות של 0.01: מדידות גסות של טעינה ויציבות פריסה.
• סוג שגיאת JavaScript מתוך רשימה קבועה ונתיב סקריפט מנורמל, ולעולם לא הודעת השגיאה.
• ספירת קליקים לפי נתיב רכיב, עם רשימת היתר של 63 תגיות ו־nth-child בלבד; דומיין רשום של יעד קישור יוצא או סיומת הורדה.

איננו שומרים כתובות IP, ‏User-Agent גולמי, פרמטרים של שאילתה, טקסט עמוד, תוכן טפסים, מזהי רכיבים או מחלקות CSS, מסלולי סמן, קואורדינטות x/y, שחזור סשנים או מזהי מבקרים מכל משך חיים. IP ו־User-Agent עדיין מגיעים לקצה לצורך מדינה, בדיקות בוטים, הגבלת קצב וחילוץ גרסאות, ואז נזרקים. ״לא נשמר״ אינו אומר ״לא מעובד״.

אין עוגיות אנליטיקה או localStorage. שתי פעולות נפרדות של המשתמש יכולות להשתמש בעוגיות: סירוב לאיסוף מגדיר עוגיית העדפה ל־13 חודשים שהמבקר בחר בה; כניסה ללוח הבקרה מגדירה עוגיית אימות. אף אחת אינה מנגנון לספירת מבקרים. Global Privacy Control ו־Do Not Track עוצרים גם את הסקריפט וגם את מנגנון האיסוף.

ביקורים משתמשים בהגדרה של Cloudflare: צפייה בעמוד שהדומיין המפנה שלה שונה מדומיין האתר. אין מזהה מבקר ייחודי ב־v0.1. מודל דיווח ההפרשים שולח את הצפייה פעם אחת; דיווחים מאוחרים יותר, בעת הסתרת לשונית או יציאה מהעמוד, כוללים קליקים, שגיאות, קישורים יוצאים וזמן שהייה בחזית שנוספו, ומעדכנים את לוח הבקרה כאשר הגלילה, LCP או CLS מגיעים לערך גבוה יותר. התיקון משויך לזמן הדיווח המאוחר. חזרה ממטמון אחורה/קדימה ממשיכה את אותה טעינת עמוד.

בדיקות קנרית מחדירות מחרוזות סימון למזהים, מחלקות, טקסט, מאפיינים, הודעות שגיאה, מפנים וכתובות URL. סימון שמגיע לדיווח או לשורה שמורה מכשיל את הבדיקה. הפרויקט גם מפעיל בדיקת קנרית ב־Playwright באתר האמיתי. הבדיקות בוחנות גבול דליפה מסוים, ולא אנונימיות מוחלטת.

מיקוד באמצעות מקלדת או ריחוף עם המצביע מציגים את הערכים המדויקים בגרף. נתוני ההדגמה אינם מייצגים ביקורים באתר dataxad.com.

איך היא פועלת על Cloudflare?

Workers מטפלים באיסוף; Analytics Engine שומרת את המדידות המוגבלות; לוח בקרה בעמוד HTML אחד מתשאל אותן דרך קישור Analytics SQL ל־Workers. הקישור אינו דורש אסימון API וזמין מ־Wrangler ‏4.145.0 ואילך.

הזרימה פשוטה:

1. הקצה בוחן אזור והעדפות לפני שהוא מגיש סקריפט מעקב פעיל.
2. הסקריפט שולח מדידות מותרות; מנגנון האיסוף בודק ומנרמל אותן.
3. Analytics Engine מקבלת שורות; לוח הבקרה קורא תשובות מצרפיות.
4. בדיקת בריאות ציבורית משתמשת באסימונים מגובבים; נתיב אבחון לבעלים בלבד מסייע בחקירה.

הסקריפט שנמדד היה בגודל 2,471 בתים ב־gzip, מול תקציב של 3,072 בתים. מנגנון האיסוף מחזיר 204 בכל מצב, משתמש בקישורי הגבלת קצב וכותב לכל היותר 171 שורות בכל משלוח. היעדר DASH_KEY סוגר את לוח הבקרה עם 404; תשובות נשמרות במטמון ל־60 שניות.

המגבלות של Analytics Engine כוללות 20 שדות blob, ‏20 שדות double, אינדקס אחד, 250 כתיבות להפעלה, 16 KB של שדות blob לבקשה ושמירה לשלושה חודשים. עמוד התמחור במחקר שלנו מנה 100,000 כתיבות ו־10,000 קריאות חינמיות ביום, וציין שבאותה עת לא הופעל חיוב. אלה תנאי פלטפורמה מתוארכים, ולא הבטחה לאירוח חינמי לתמיד.

שישה לקחים משישה סבבי פריסה חיים

הארכיטקטורה הייתה קטנה. הבאת הגבולות שלה למצב הנכון לא הייתה פשוטה.

1. צריך להפעיל תחילה את Analytics Engine בלוח הבקרה של החשבון. שום אסימון API אינו מבצע את הצעד הראשוני. הפריסות הראשונות נעצרו עם “You need to enable Analytics Engine”.
2. מדיניות Referrer השפיעה על הכניסה. Astro דחתה את בקשת ה־POST של הטופס כש־no-referrer יצר Origin: null. עמוד הכניסה משתמש כעת ב־same-origin.
3. אריזת הקוד שינתה קוד בר־הרצה. המרת פונקציה לטקסט עם toString() נשברה עם keepNames של esbuild: ‏__name is not defined. קוד הלקוח הפך למחרוזת תבנית, עם בדיקה שמבצעת אריזה.
4. קישור SQL לא השתמש בניב שהנחנו. משקלי הדגימה כבר מיושמים; אין _sample_interval. אין date_trunc, ואילו toStartOfInterval, ‏toStartOfDay ו־toDate פועלים. גם מיון עמודה מקובצת עם כינויים נכשל. נתיב אבחון לבעלים בלבד בדק 18 צורות שאילתה בסביבה החיה.
5. סוקרים עצמאיים המשיכו למצוא פגמים אמיתיים. במשך חמישה סבבים: תבניות במקום רשימות היתר, משלוח חד־פעמי, כשל גאוגרפי שמאפשר איסוף, שקלול דגימה כפול, SELECT DISTINCT, מפתחות מטמון, מטמון אחורה/קדימה ותוויות דומיין שנראות כמזהים. קוד קצר לא הפך סקירה למיותרת.
6. התראת המכסה הייתה שייכת לעומס אחר. מנגנון האיסוף השתמש בכ־180 בקשות Worker ביום; אות חיים ממארח משחקים אחר בחשבון השתמש ב־100,000. התראות ברמת חשבון דורשות אבחון לפי עומס עבודה.

איך משתמשים בה, ומה הלאה?

התחילו במדריך ההתקנה במאגר. הוא מכסה שלוש צורות פריסה: Worker עצמאי, שילוב ב־Worker קיים או באפליקציית Astro, ו־Pages Functions. השתמשו בהנחיות התצורה העדכניות במקום להעתיק קטע מבלוג. קראו את docs/research.md להשוואות, למקורות ולהחלטות שבבסיס המערכת.

השלבים הבאים הם מצב מכוון־CNIL וספירת מבקרים ייחודיים רק אחרי ייעוץ משפטי, וכן חיבור למנהל הסכמה. אלה פריטים שטרם הושלמו, ולא יכולות שלוח הבקרה הנוכחי מבטיח.

עבור Dataxad, המטרה היא תובנות שימושיות על האתר עם גבול איסוף שאפשר להסביר, לבדוק ולאתגר. למאגר עדיין אין רישיון; נבחר אחד. זמינות ציבורית של הקוד אינה מעניקה רישיון קוד פתוח.