האם החלפת שרת VPN מנתקת אתכם מחנות?
כתובת יציאה חדשה אינה מרוקנת את צנצנת העוגיות. תחילה החליטו אם אתם בודקים את נתיב הרשת, את ההפעלה המחוברת או את נתוני האתר המאוחסנים.
החליפו את יציאת ה-VPN כשחנות פתוחה בכרטיסייה אחרת, והסל בדרך כלל עדיין שם. זו אינה תקלת VPN; זה הדפדפן עושה בדיוק את מה שנאמר לו. העוגייה נשלחת על ידי הדפדפן, ונתיב רשת חדש אינו משנה את מה שהדפדפן מאחסן. שלוש שאלות שונות מסתתרות מאחורי «האתר עוד מכיר אותי», והתשובה תלויה בשאלה שאתם באמת שואלים.
שלוש שאלות, סימפטום אחד
ראשית: האם האתר מזהה עוגייה מאוחסנת? שנית: האם הוא מזהה חשבון מחובר, שמתקיים ללא תלות בכל עוגייה בודדת? שלישית: האם הוא מזהה משהו בדפדפן או במכשיר ולא מצב מאוחסן? לכל אחת יש הבדיקה והתרופה שלה.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
רוב הבלבול נובע משינוי הראשון וציפייה שהשני יבוא בעקבותיו. כתובת רשת ומאגר דפדפן הם שני מערכות נפרדות שבמקרה אותו עמוד משתמש בהן.
מה עוגייה באמת נושאת
ניהול מצב HTTP, כפי שמפורט ב-RFC 6265, פשוט בכוונה: השרת קובע שם וערך עם היקף, והדפדפן מחזיר אותם עבור בקשות שמתאימות להיקף הזה. הערך יכול להיות מזהה הפעלה, העדפה או אסימון אטום שהשרת ממפה לרשומת סל. שום דבר במנגנון אינו מזכיר את כתובת הלקוח.
התכנון הזה הוא הסיבה לכך שהתחברויות וסלים רגילים שורדים שינוי ברשת, והוא גם הסיבה שהם שורדים אותו אצל עוקבים. אותו מנגנון משרת את שתי המטרות ואינו מבחין ביניהן. אין שדה בפרוטוקול לכתובת הלקוח, ולכן אין דבר שיציאה חדשה יכולה לבטל. אתר שרוצה לקשור עוגייה למקור רשת היה צריך להוסיף את ההיגיון הזה בעצמו.
כשאתר מחזיר עוגייה, השרת מחפש את הרשומה שהערך הזה מצביע עליה. שינוי המסלול שהבקשה עברה בו אינו משנה את החיפוש, וזו כל ההסבר לתצפית בסל הקניות.
החליטו מה הבדיקה שלכם מודדת
לפני שאתם משנים משהו, רשמו את המצב שממנו אתם מתחילים: איזה פרופיל דפדפן, איזה חשבון, איזה נתוני אתר, איזה נתיב רשת. אחר כך שנו בדיוק אחד מהם וצפו. בדיקה שמשנה בו-זמנית את כתובת היציאה ואת פרופיל הדפדפן אינה מוכיחה דבר על אף אחד מהם.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartשתי הפקודות עושות שימוש חוזר באותו קובץ עוגיות, והשנייה כופה כתובת מקור מקומית אחרת היכן שהמארח מאפשר זאת. תגובת הסל זהה בשני המקרים כי השרת מעולם לא ראה זהות לקוח אחרת, רק נתיב אחר. זה המנגנון בזוג בקשות אחד שניתן לשחזר.
אם המטרה היא לראות אם האתר מזהה אתכם בלי מצב מאוחסן, מחקו את נתוני האתר הזה וחזרו על הבדיקה. אם הוא עדיין מזהה אתכם, החשודים הבאים הם החשבון המחובר, קישור שעקבתם אחריו או מאפייני דפדפן ולא עוגייה.
מחקו את המצב הנכון, לא את הרשת
הסרת האחסון של אתר אחד שייכת לפקדים של הדפדפן עצמו, ולעיתים קרובות היא תנתק אתכם או תאפס העדפות כתופעת לוואי. היא אינה מוחקת את החשבון או את הרשומות שהשירות כבר מחזיק; לאלה נדרש התהליך של השירות עצמו.
הגבלות בין אתרים מטפלות בחלק אחר של הבעיה. דפדפנים יכולים לחסום או לחלק אחסון ששירותים מוטמעים היו חולקים אחרת בין אתרים, בעוד התחברות מצד ראשון ממשיכה לעבוד. לכן התחברות מוצלחת אינה הוכחה שמעקב בין אתרים פועל.
חלונות פרטיים הם כלי נוסף בהיקף צר ממה שאנשים מצפים. אתרים עדיין יכולים לקבוע עוגיות במהלך ההפעלה, והתחברות עדיין מזהה את החשבון. סיום ההפעלה הפרטית הוא מה שמשליך את המצב הזמני, כלומר לסגור כל חלון פרטי ולא כרטיסייה אחת.
לבסוף, התייחסו לזיהוי לפי טביעת אצבע כאפשרות ולא כהסבר הראשון. מאפייני מכשיר ודפדפן יכולים לקשר ביקורים בלי שום עוגייה מאוחסנת, ומחיקת האחסון לא תיגע בהם. בדקו קודם את הסיבות הפשוטות, אחר כך הרחיבו את החקירה, ורשמו איזה מצב שיניתם כדי שההשוואה הבאה תהיה משמעותית.