צדדים שלישיים

מהו צד שלישי?

לעיתים נדירות, אתר אינטרנט עומד בפני עצמו. באלמנט Web Almanac של HTTP עולה שרוב האתרים – כ-95% – מכילים תוכן של צד שלישי.

Almanac מגדיר תוכן של צד שלישי כמשהו שמתארח במקור משותף וציבורי, שנמצא בשימוש נרחב במגוון אתרים, ללא השפעה על ידי בעלי אתר ספציפיים. מדובר בתמונות או במדיה אחרת, כמו סרטונים, גופנים או סקריפטים. תמונות וסקריפטים אחראיים יותר מכל פריט אחר שמצורף יחד. תוכן של צד שלישי לא חיוני לפיתוח אתר, אבל לא פחות חשוב מכך; כמעט בטוח שתשתמשו במשהו שנטען משרת משותף ציבורי, בין אם גופני אינטרנט, מסגרות iframe מוטמעות של סרטונים, פרסומות או ספריות JavaScript. לדוגמה, ייתכן שאתם משתמשים בגופני אינטרנט שמוצגים מ-Google Fonts, או שאתם מודדים ניתוח נתונים באמצעות Google Analytics, אולי הוספתם לחצני 'לייק' או 'כניסה באמצעות חשבון' מרשתות חברתיות. יכול להיות שאתם מטמיעים מפות או סרטונים או מטפלים ברכישות דרך שירותי צד שלישי. יכול להיות שאתם עוקבים אחרי שגיאות ומתעדים את נתוני צוותי הפיתוח שלכם באמצעות כלי מעקב של צד שלישי.

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

כשמדברים על 'משאבים של צד שלישי' באופן כללי, ההבחנה בין צד ראשון לצד שלישי היא לא בדיוק ההקשר שבו משתמשים בו. סקריפט שנטען מאתר אחר הוא משאב של צד שלישי, ובקשת ה-HTTP שטוענת את הסקריפט עשויה לכלול קובצי cookie, אבל קובצי ה-cookie האלה לא באמת 'קובצי cookie של צד שלישי'. הם רק קובצי cookie, ואם הם 'צד שלישי' או 'צד ראשון', תלוי אם הסקריפט נטען בדף באתר שלכם או בדף באתר של בעל הסקריפט.

למה אנחנו משתמשים במשאבים של צדדים שלישיים?

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

דוח האינטרנט של ארכיון HTTP מספק תיאור נחמד:

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

מה יכולים לעשות משאבים של צד שלישי?

גישה לחלק מהמידע

כשאתם משתמשים במשאב של צד שלישי באתר, לא משנה מה הוא, חלק מהמידע מועבר לאותו צד שלישי. לדוגמה, אם כוללים תמונה מאתר אחר, בקשת ה-HTTP של הדפדפן של המשתמש תעביר את הכותרת 'גורם מפנה' עם כתובת ה-URL של הדף וגם את כתובת ה-IP של המשתמש.

מעקב באתרים שונים

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

זהו מעקב באתרים שונים: מאפשר לצד שלישי לאסוף יומן של פעילות המשתמש באתרים רבים, כל עוד כל האתרים משתמשים במשאב שמגיע מאותו צד שלישי. הקובץ יכול להיות גופן, תמונה או גיליון סגנונות — כל המשאבים הסטטיים. הוא גם יכול להיות משאב דינמי: קטע סקריפט, לחצן לרשת חברתית, מודעה. הסקריפט הכלול יכול לאסוף מידע רב אף יותר, מפני שהוא דינמי: הוא יכול לבדוק את הדפדפן והסביבה של המשתמש ולהעביר את הנתונים חזרה למקור. כל סקריפט יכול לעשות זאת במידה מסוימת, וכך גם משאבים דינמיים שלא מוצגים כסקריפט, כמו הטמעה של מדיה חברתית, מודעה או לחצן שיתוף. אם מסתכלים על הפרטים של באנר לגבי קובצי cookie באתרים פופולריים, אפשר לראות רשימה של הארגונים שייתכן שמוסיפים קובץ cookie למעקב למשתמשים כדי ליצור תמונה של הפעילויות שלהם וליצור פרופיל של אותו משתמש. יכולים להיות מאות מהם. אם צד שלישי מספק שירות בחינם, אחת הדרכים כדאי מבחינה כלכלית לעשות זאת היא באמצעות איסוף הנתונים האלה לצורך ייצור הכנסות.

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

זוהי הבחנה חשובה: זיהוי לא רצוי בין אתרים הוא בעייתי, גם אם הצד השלישי לא אוסף ממנו מידע רגיש נוסף, מכיוון שהוא מבטל את השליטה של המשתמש על הזהות שלו. גישה לגורם המפנה ולכתובת ה-IP של משתמש וקובצי cookie היא כשלעצמה גילוי נאות לא רצוי. כשמשתמשים במשאבים של צדדים שלישיים, מתכננים גם איך להשתמש בהם באופן ששומר על הפרטיות. חלק מהעבודה שלכם היא באחריותכם כמפתחי האתר, וחלקן מתבצעות על ידי הדפדפן כסוכן המשתמש. כלומר, הסוכן שפועל בשמו של המשתמש כדי להימנע מחשיפת מידע רגיש ומזיהוי לא רצוי בין אתרים, כשאפשר. בהמשך נבחן בפירוט רב יותר את המיטיגציות ואת הגישות ברמת הדפדפן וברמת פיתוח האתר.

קוד של צד שלישי בצד השרת

ההגדרה הקודמת שלנו של צד שלישי שינתה בכוונה את הגישה של HTTP Almanac של צד הלקוח (כפי שמתאים לדיווח שלו!), וכללה בעלות של צד שלישי, מפני שמנקודת מבט של פרטיות, צד שלישי הוא כל מי שיודע משהו על המשתמשים שלך, ולא על המשתמשים שלך.

זה כולל גורמי צד שלישי שמספקים את השירותים שבהם אתם משתמשים בשרת, וגם את הלקוח. מבחינת הפרטיות, חשוב להבין גם ספרייה של צד שלישי (כמו תוכן שכלול ב-NPM, ב-Composer או ב-NPM). האם יחסי התלות מעבירים נתונים מחוץ לגבולות שלכם? אם אתם מעבירים נתונים לשירות רישום ביומן או למסד נתונים באירוח מרוחק, אם ספריות כוללות גם את "דף הבית של הטלפון" לכותבים שלהן, הן עלולות להפר את פרטיות המשתמשים שלכם ולכן צריך לעבור בדיקה. בדרך כלל, צד שלישי שמבוסס על שרת צריך לקבל את נתוני המשתמש על ידכם, כך שהנתונים שאליהם הוא חשוף נתונים יותר בשליטתכם. לעומת זאת, צד שלישי מבוסס-לקוח – סקריפט או משאב HTTP שכלול באתר שלכם ומאוחזר על ידי הדפדפן של המשתמש – יכול לאסוף נתונים מסוימים ישירות מהמשתמש בלי שאתם תפקחו על התהליך הזה של איסוף נתונים. רוב המודול הזה יתמקד בזיהוי הצדדים השלישיים מצד הלקוח שבחרתם לכלול ולחשוף את המשתמשים שלכם, בדיוק מפני שאתם יכולים לצמצם את אפשרויות הגישור. עם זאת, כדאי לשקול לאבטח את הקוד בצד השרת כדי שתבינו את התקשורת היוצאת ממנו ותוכלו לתעד או לחסום כל קוד שאינו צפוי. פרטים על הדרך בדיוק לעשות זאת אינם בטווח שלנו כאן (ותלויים מאוד בהגדרת השרת שלכם), אבל זה חלק נוסף ממעמד האבטחה והפרטיות שלכם.

למה אתם צריכים לנהוג בזהירות ביחס לצדדים שלישיים?

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

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

דוגמה לבעיית אבטחה היא מצב שבו "מרפרפים באינטרנט" גונבים פרטי כרטיס אשראי – משאב של צד שלישי שכלול בדף שבו המשתמש מזין פרטי כרטיס אשראי עלול, באופן פוטנציאלי, לגנוב את פרטי כרטיס האשראי האלה ולשלוח אותם לצד השלישי הזדוני. אלה שיוצרים את הסקריפטים המצלמים האלה, יצירתיים מאוד בחיפוש מקומות כדי להסתיר אותם. בסיכום אחד מוסבר איך סקריפטים של רפרוף הוסתרו בתוכן של צד שלישי כמו התמונות שמשמשות לסמלי לוגו של אתר, לסמל אתר ולרשתות מדיה חברתית, ספריות פופולריות כמו jquery, Modernizr ו-Google Tag Manager, ווידג'טים של אתרים כמו חלונות צ'אט בשידור חי וקובצי CSS.

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

ריכזנו כמה דוגמאות לצדדים שלישיים?

נדון ב"צדדים שלישיים" באופן כללי, אבל למעשה יש סוגים שונים של צדדים שלישיים ויש להם גישה לכמויות שונות של נתוני משתמשים. לדוגמה, הוספה של רכיב <img> ל-HTML, שנטען משרת אחר, תיתן לשרת מידע שונה על המשתמשים שלכם מאשר הוספה של רכיב <iframe> או רכיב <script>. אלה דוגמאות ולא רשימה מקיפה, אבל כדאי להבין את ההבדלים בין סוגי הפריטים השונים של צד שלישי שבהם האתר יכול להשתמש.

בקשת משאב מאתרים שונים

משאב חוצה-אתרים הוא כל דבר באתר שלך שנטען מאתר אחר ואינו <iframe> או <script>. לדוגמה, <img>, <audio>, <video>, גופני אינטרנט שנטענים על ידי CSS ומרקמים של WebGL. כל הכתובות האלה נטענות באמצעות בקשת HTTP. כפי שתואר קודם לכן, בקשות ה-HTTP יכללו קובצי cookie שהוגדרו בעבר על ידי האתר האחר, את כתובת ה-IP של המשתמש המבקש ואת כתובת ה-URL של הדף הנוכחי בתור הגורם המפנה. בעבר, כל הבקשות של צד שלישי כללו את הנתונים האלה כברירת מחדל. עם זאת, נעשו מאמצים לצמצם או לבודד את הנתונים שמועברים לצדדים שלישיים מדפדפנים שונים, כפי שמתואר בהמשך במאמר 'הסבר על הגנות הדפדפן של צד שלישי'.

הטמעה של iframe חוצה-אתרים

באמצעות מסמך מלא שמוטמע בדפים שלך באמצעות <iframe>, ניתן לבקש גישה נוספת לממשקי API של הדפדפן, בנוסף לשלל קובצי ה-cookie, כתובת ה-IP והגורם המפנה. פירוט של ממשקי ה-API שזמינים לדפי <iframe>, והדרך שבה הם מבקשים גישה הם ספציפיים לדפדפן, ותהליך זה נמצא כרגע בתהליך שינויים. בהמשך מוסבר בהרחבה על "מדיניות ההרשאות" שבהמשך מוסבר איך להגביל את הגישה ל-API במסמכים מוטמעים או לעקוב אחריה.

הפעלת JavaScript באתרים שונים

הכללת רכיב <script> טוענת ומריצים JavaScript באתרים שונים בהקשר ברמה העליונה של הדף שלך. כלומר, לסקריפט שרץ יש גישה מלאה לכל מה שיש לסקריפטים של הדומיין שלכם. הרשאות הדפדפן עדיין מנהלות את הנתונים האלה, כך שעדיין תידרש הסכמה של המשתמש לגבי בקשת מיקום המשתמש (לדוגמה). עם זאת, סקריפט כזה יכול לקרוא את כל המידע שנמצא בדף או זמין כמשתני JavaScript. הוא כולל לא רק קובצי cookie שמועברים לצד השלישי במסגרת הבקשה, אלא גם קובצי cookie שמיועדים לאתר שלכם בלבד. באותה מידה, סקריפט של צד שלישי שנטען לדף שלכם יכול לבצע את כל אותן בקשות HTTP כמו הקוד שלכם, כלומר הוא יכול לשלוח בקשות fetch() לממשקי ה-API העורפיים שלכם כדי לקבל נתונים.

הכללת ספריות של צד שלישי ביחסי התלות שלך

כפי שתואר קודם, סביר להניח שהקוד בצד השרת יכלול גם יחסי תלות של צד שלישי, ולא ניתן להבחין בינם לבין הקוד שלכם בכוחם. קוד שאתם כוללים ממאגר GitHub או מהספרייה של שפת התכנות שלכם (npm, PyPI, מלחין וכו') יכול לקרוא את אותם נתונים שגם הקוד האחר שלכם יכול לקרוא.

היכרות עם הצדדים השלישיים

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

כדי להבין את ההבנה הזו, אנחנו עוברים תהליך של ביקורת.

עריכת ביקורת על צדדים שלישיים

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

הרצת ביקורת שאינה טכנית

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

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

ביצוע בדיקה טכנית

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

אם אתם מספקים חשבונות משתמשים, עליכם להירשם באתר שלכם לחשבון חדש. צוות העיצוב שלכם ינהל את התהליך החדש לצירוף משתמשים מנקודת מבט של חוויית המשתמש, אבל אפשר לראות זאת כהמחשה של נקודת המבט של הפרטיות. אל תלחצו פשוט על "מסכים" בתנאים ובהגבלות, באזהרה לגבי קובצי ה-cookie או במדיניות הפרטיות. אל תסתפקו במשימה של שימוש בשירות שלכם בלי לחשוף מידע אישי או להשתמש בקובצי cookie למעקב, ובדקו אם אתם יכולים לעשות זאת וכמה קשה לעשות זאת. כדאי גם לעיין בכלים למפתחים בדפדפן כדי לראות לאילו אתרים מתבצעת גישה ואילו נתונים מועברים לאתרים האלה. הכלים למפתחים מספקים רשימה של בקשות HTTP נפרדות (בדרך כלל בקטע שנקרא 'רשת'), ומכאן תוכלו לראות בקשות לפי סוג (HTML, CSS, תמונות, גופנים, JavaScript, בקשות שהופעלו על ידי JavaScript). אפשר גם להוסיף עמודה חדשה להצגת הדומיין בכל בקשה, שתציג לכמה מקומות שונים יוצרים קשר. בנוסף, יכול להיות שתיבת הסימון 'בקשות של צד שלישי' תציג רק צדדים שלישיים. (כדאי גם להשתמש בדיווח של Content-Security-Policy כדי לבצע ביקורת מתמשכת, ולאחר מכן להמשיך לקרוא).

הכלי 'Request Map Generator' של Simon Hearne יכול גם לספק סקירה כללית מועילה של כל בקשות המשנה שנשלחות מדף שגלוי לכולם.

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

לאחר שתצמצם את רשימת הבקשות לצדדים שלישיים שברצונך לקחת חלק בבדיקה, לחיצה על בקשה מסוימת תציג את כל הפרטים שלה, ובמיוחד את הנתונים שהועברו לבקשה זו. לעיתים קרובות מאוד בקשה של צד שלישי שהקוד שלכם יוזם ולאחר מכן נשלחת בקשות רבות אחרות מצד שלישי. גם צדדים שלישיים נוספים אלה "מיובאים" למדיניות הפרטיות שלך. זו משימה מאומצת אבל חשובה, ולרוב אפשר להוסיף אותה לניתוחים קיימים. צוות הפיתוח שלכם צריך כבר לבדוק בקשות מסיבות שקשורות לביצועים (אולי בעזרת כלים קיימים כמו WebPageTest או Lighthouse), ולשלב בתהליך הזה ביקורת על נתונים ופרטיות, כדי שיהיה קל יותר לעשות זאת.

מה מותר לעשות

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

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

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

קובצי HAR ותיעוד

קובץ HAR הוא פורמט JSON סטנדרטי לכל הבקשות לרשת שנשלחות על ידי דף. כדי לקבל קובץ HAR של דף מסוים:

Chrome

פותחים את כלי הפיתוח בדפדפן (תפריט > כלים נוספים > כלים למפתחים), נכנסים לחלונית 'רשת', טוענים (או מרעננים) את הדף ובוחרים בסמל השמירה של החץ למטה בפינה השמאלית העליונה, ליד התפריט הנפתח 'ללא הגבלת רוחב פס'.

Firefox

פותחים את הכלים למפתחים בדפדפן (תפריט > כלים נוספים > כלים למפתחי אתרים), נכנסים לחלונית 'רשת', טוענים (או מרעננים) את הדף ובוחרים בסמל גלגל השיניים בפינה השמאלית העליונה, ליד התפריט הנפתח של ויסות הנתונים. בתפריט, בוחרים באפשרות שמירת כל ההודעות בפורמט HAR**.

Safari

פותחים את הכלים למפתחים בדפדפן (תפריט > פיתוח > הצגת מפקח אינטרנט; אם אין תפריט פיתוח, מפעילים אותו דרך תפריט > Safari > העדפות > מתקדם > הצגת תפריט פיתוח בסרגל התפריטים), עוברים לחלונית 'רשת', טוענים (או מרעננים) את הדף ובוחרים באפשרות ייצוא בפינה השמאלית העליונה (מימין ל'שמירת יומן', ייתכן שיהיה צורך להגדיל את החלון).

לפרטים נוספים, תוכלו גם לתעד מה מועבר לצדדים שלישיים (בקטע Request), למרות שהנתונים האלה לעיתים קרובות מעורפלים ולא ניתנים לפירוש.

שיטות מומלצות לשילוב צדדים שלישיים

תוכל לקבוע מדיניות משלך לגבי הצדדים השלישיים שהאתר שלך משתמש בהם: לשנות את ספק המודעות שבו אתה משתמש בהתאם לשיטות שלהם, או עד כמה החלון הקופץ לקבלת הסכמה לשימוש בקובצי cookie מעצבן או מטריד, או אם ברצונך להשתמש בלחצנים של רשתות חברתיות באתר או בקישורים למעקב בהודעות אימייל או בקישורי utm_campaign למעקב ב-Google Analytics בציוצים שלך. אחד ההיבטים שחשוב להביא בחשבון במהלך פיתוח האתר הוא מצב הפרטיות והאבטחה של שירות הניתוח. בשירותים מסוימים של ניתוח נתונים סוחרים באופן מפורש בהגנה על הפרטיות. לעיתים קרובות יש גם דרכים להשתמש בסקריפט של צד שלישי שמוסיף הגנה על פרטיות בפני עצמו: אתם לא הצוות הראשון שמעוניין לשפר את פרטיות המשתמשים ולהגן עליהם מפני איסוף נתונים על ידי צד שלישי, וייתכן שכבר יש פתרונות. לבסוף, ספקי צד שלישי רבים רגישים יותר לבעיות באיסוף נתונים כיום מבעבר, ולכן יש הרבה תכונות או פרמטרים שאפשר להוסיף כדי להפעיל מצב הגנה על המשתמש בצורה טובה יותר. הנה מספר דוגמאות.

כשמוסיפים לחצן לשיתוף ברשתות חברתיות

אפשר להטמיע לחצני HTML באופן ישיר: באתר https://sharingbuttons.io/ יש כמה דוגמאות מעוצבות היטב. לחלופין, אפשר להוסיף קישורי HTML פשוטים. היתרון כאן הוא שתאבד את הנתונים הסטטיסטיים של "ספירת המניות" ואת היכולת לסווג את הלקוחות בניתוח הנתונים ב-Facebook. זאת דוגמה לפשרה בין שימוש בספק צד שלישי לקבלת פחות נתונים אנליטיים.

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

לדוגמה, תוכל להוסיף קישורים עבור Twitter ו-Facebook כדי לשתף את השירות שלך בכתובת mysite.example.com באופן הבא:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

חשוב לשים לב ש-Facebook מאפשר לציין כתובת אתר לשיתוף, ו-Twitter מאפשר לציין כתובת אתר וטקסט מסוים.

במהלך הטמעת סרטון

כשמטמיעים סרטונים מאתרים שמארחים סרטונים, בקוד ההטמעה יש אפשרויות לשמירה על הפרטיות. לדוגמה, ב-YouTube, מחליפים את youtube.com בכתובת ה-URL המוטמעת ב-www.youtube-nocookie.com כדי למנוע הצבה של קובצי cookie במשתמשים שצופים בדף ההטמעה. תוכל גם לסמן את האפשרות 'הפעל מצב פרטיות משופרת' בעת יצירת הקישור 'שיתוף/הטמעה' מ-YouTube עצמו. זו דוגמה טובה לשימוש במצב הגנה על המשתמש יותר שהצד השלישי מספק. (בכתובת https://support.google.com/youtube/answer/171780 מתואר בפירוט רב יותר, ועל אפשרויות הטמעה נוספות ב-YouTube ספציפית).

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

בדומה לווידג'טים אינטראקטיביים שתיארנו קודם, לרוב ניתן להחליף סרטון מוטמע בקישור לאתר שמספק את התוכן. האפשרות הזו פחות אינטראקטיבית כי לא ניתן להפעיל את הסרטון ברצף, אבל למשתמשים יש את האפשרות לצפות בו יחד עם אחרים. ניתן להשתמש בו כדוגמה ל "דפוס facade", השם להחלפה דינמית של תוכן אינטראקטיבי בתוכן שמחייב פעולה מצד המשתמש כדי להפעיל אותו. אפשר להחליף סרטון TikTok מוטמע בקישור פשוט לדף של סרטון TikTok, אבל עם קצת עבודה נוספת אפשר לאחזר ולהציג תמונה ממוזערת של הסרטון ולהפוך אותו לקישור. גם אם ספק הווידאו שנבחר לא תומך בדרך קלה להטמיע סרטונים ללא מעקב, מארחי סרטונים רבים תומכים ב-oEmbed, ממשק API שכאשר מספקים לו קישור לסרטון או לתוכן מוטמע, הוא מחזיר מהם פרטים פרוגרמטיים, כולל תמונה ממוזערת ושם. ב-TikTok יש תמיכה ב-oEmbed (פרטים נוספים זמינים בכתובת https://developers.tiktok.com/doc/embed-videos), כלומר אפשר (באופן ידני או פרוגרמטי) להפוך קישור לסרטון TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 למטא-נתונים של JSON לגבי אותו סרטון באמצעות https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, וכך לאחזר תמונה ממוזערת כדי להציג אותו. לדוגמה, WordPress משתמש באפשרות הזו כדי לבקש נתוני oEmbed עבור תוכן מוטמע. ניתן להשתמש בשיטה פרוגרמטית כדי להציג "facade" שנראה אינטראקטיבי ולעבור ישירות להטמעה או לקישור של סרטון אינטראקטיבי כשהמשתמש בוחר ללחוץ עליו.

בהטמעה של סקריפטים של Analytics

מערכת Analytics נועדה לאסוף מידע על המשתמשים שלכם כדי שאפשר יהיה לנתח אותו: לשם כך היא מיועדת. מערכות Analytics הן למעשה שירותים לאיסוף ולהצגה של נתונים על גישה ומשתמשים. הפעולה הזו מתבצעת בשרת של צד שלישי כמו Google Analytics, כדי להקל על ההטמעה. יש גם מערכות ניתוח באירוח עצמי, כמו https://matomo.org/, אבל זו יותר עבודה מאשר שימוש בפתרון של צד שלישי. עם זאת, הפעלת מערכת כזו בתשתית שלכם עוזרת לצמצם את איסוף הנתונים, כי היא לא עוזבת את המערכת האקולוגית שלכם. לעומת זאת, באחריותכם לנהל את הנתונים האלה, להסיר אותם ולקבוע מדיניות. חלק גדול מהחשש במעקב באתרים שונים מתרחש כשהפעולה מתבצעת בחשאי ובחשאי, או כתוצאה מתופעת השימוש בשירות שכלל לא נדרש איסוף נתונים. התוכנות של Analytics תוכננו באופן גלוי כדי לאסוף נתונים כדי ליידע את בעלי האתרים לגבי המשתמשים שלהם.

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

אם שירות של צד שלישי מסוים נמצא בשימוש באתר שלכם ובאתרים אחרים, והשירות כולל את ה-JavaScript שלו באתר שלכם, והוא מגדיר קובצי Cookie לכל משתמש, חשוב לקחת בחשבון שיכול להיות שהוא יבצע זיהוי לא רצוי בין אתרים. כלומר, מעקב אחר המשתמשים באתרים שונים. יכול להיות שלחלקם לא. אבל עמדת ההגנה על הפרטיות כאן היא להניח ששירות צד שלישי כזה למעשה מבצע מעקב באתרים שונים, אלא אם יש לכם סיבה טובה לחשוב או לדעת אחרת. כשלעצמה, זו לא סיבה להימנע משירותים כאלה, אבל כדאי להביא בחשבון את השיקולים האלה כשעושים שימוש בהם.

בעבר הוותק לניתוח נתונים היה כדי לבחור אם להשתמש בו או לא: לאסוף את כל הנתונים ולפגוע בפרטיות בתמורה לקבלת תובנות ותכנון, או לוותר על תובנות לגמרי. עם זאת, זה כבר לא המקרה, ועכשיו ניתן למצוא דרך ביניים בין שתי האפשרויות הקיצוניות האלה. כדאי לפנות לספק שירותי הניתוח כדי לקבל אפשרויות הגדרה כדי להגביל את הנתונים שנאספים ולצמצם את הכמות ומשך האחסון שלהם. מאחר שיש לכם את הרשומות מהביקורת הטכנית שתיארנו קודם, תוכלו להריץ מחדש את הקטעים הרלוונטיים באותה ביקורת כדי לוודא ששינוי ההגדרות האלה אכן מצמצם את כמות הנתונים שנאספים. אם תבצעו את המעבר באתר קיים, תוכלו להשתמש בכלי ניתן לכימות שאותו תוכלו לכתוב עבור המשתמשים. לדוגמה, ב-Google Analytics יש כמה תכונות פרטיות להצטרפות (ולכן מופעלות כברירת מחדל), ורבות מהן יכולות לעזור לציית לחוקים המקומיים להגנה על נתונים. כשאתם מגדירים את Google Analytics, כדאי לשקול להגדיר את תקופת השמירה של הנתונים שנאספים (ניהול > פרטי מעקב > שמירת נתונים) כך שהיא תהיה קצרה יותר מברירת המחדל של 26 חודשים, ולהפעיל כמה מהפתרונות הטכניים יותר, כמו אנונימיזציה חלקית של כתובות IP (פרטים נוספים זמינים בכתובת https://support.google.com/analytics/answer/9019185).

שימוש בצדדים שלישיים באופן ששומר על הפרטיות

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

מדיניות של גורמים מפנים

מה מותר לעשות

אפשר להגדיר מדיניות של strict-origin-when-cross-origin או noreferrer כדי למנוע מאתרים אחרים לקבל כותרת של גורם מפנה כאשר מקשרים אליהם או כשהם נטענים כמשאבי משנה על ידי דף:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

או בצד השרת, למשל ב-Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

במקרה הצורך, אפשר להגדיר מדיניות מצומצמת יותר לבקשות או לרכיבים ספציפיים.

למה זה מגן על פרטיות המשתמשים

כברירת מחדל, כל בקשת HTTP שהדפדפן שולח מעבירה כותרת Referer שמכילה את כתובת ה-URL של הדף שמפעיל את הבקשה, בין אם מדובר בקישור, בתמונה מוטמעת או בסקריפט. זו יכולה להיות בעיית פרטיות כי כתובות URL עשויות להכיל מידע פרטי, וכתובות ה-URL האלה שזמינות לצדדים שלישיים מעבירות אליהם את המידע הפרטי. ב-Web.dev יש כמה דוגמאות לכתובות URL שמכילות מידע פרטי – הידיעה שמשתמש הגיע לאתר שלכם מ-https://social.example.com/user/me@example.com מאפשרת לכם לדעת מיהו המשתמש, וזו דליפה ברורה. אבל גם כתובת URL שאינה חושפת מידע פרטי אכן חושפת את העובדה שהמשתמש המסוים הזה (שאולי ידוע לך, אם הוא מחובר) הגיע לכאן מאתר אחר, ולכן מגלה שהמשתמש ביקר באתר האחר. חשיפת מידע כזה כשלעצמה היא חשיפת מידע שייתכן שלא הייתם יודעים על היסטוריית הגלישה של המשתמשים.

ציון כותרת Referrer-Policy (עם איות נכון!) מאפשר לכם לשנות זאת, כך שחלק מכתובת ה-URL המפנה, או אף אחת מהן, לא יועברו. ב-MDN מופיעים הפרטים המלאים, אבל רוב הדפדפנים אימצו את הערך strict-origin-when-cross-origin כברירת מחדל. כלומר, כתובת ה-URL המפנה מועברת עכשיו לצדדים שלישיים כמקור בלבד (https://web.dev ולא https://web.dev/learn/privacy). זוהי הגנה שימושית על הפרטיות בלי שתצטרכו לעשות משהו. עם זאת, אפשר לצמצם את העניין עוד יותר על ידי ציון Referrer-Policy: same-origin, כדי למנוע העברה של פרטים של גורמים מפנים לצדדים שלישיים (או Referrer-Policy: no-referrer כדי להימנע מהעברה לאף גורם, כולל המקור שלך). (זאת דוגמה נחמדה לאיזון בין פרטיות לבין שירות. ברירת המחדל החדשה מאפשרת שמירה על פרטיות הרבה יותר מבעבר, אבל היא עדיין מספקת מידע ברמה גבוהה לצדדים שלישיים לבחירתכם, כמו ספק ניתוח הנתונים שלכם).

מומלץ גם לציין את הכותרת הזו באופן מפורש כי כך אפשר לדעת בדיוק מהי המדיניות במקום להסתמך על ברירות המחדל של הדפדפן. אם אין אפשרות להגדיר כותרות, אפשר להגדיר מדיניות של גורם מפנה עבור דף HTML שלם באמצעות מטא-רכיב בקטע <head>: <meta name="referrer" content="same-origin">. אם הבעיה היא לגבי צדדים שלישיים ספציפיים, אפשר גם להגדיר את המאפיין referrerpolicy ברכיבים ספציפיים כמו <script>, <a> או <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

מדיניות-אבטחת תוכן

הכותרת Content-Security-Policy, שמכונה בדרך כלל CSP, קובעת מאיפה אפשר לטעון משאבים חיצוניים. הוא משמש בעיקר למטרות אבטחה כי הוא מונע מתקפות של סקריפטים חוצי-אתרים והחדרת סקריפטים, אבל כשמשתמשים בו יחד עם הביקורות הרגילות, הוא יכול להגביל את המקומות שאליהם גורמי הצד השלישי שבחרתם יוכלו להעביר נתונים.

יכול להיות שחוויית המשתמש במצב הזה לא טובה בכלל. אם אחד מהסקריפטים של צד שלישי מתחיל לטעון תלות ממקור שלא מופיע ברשימה שלך, הבקשה תיחסם, הסקריפט ייכשל והאפליקציה שלך עלולה להיכשל בגללו (או לפחות להיות בגרסת החלופה שלו, שנכשלה ב-JavaScript). כדאי להשתמש באפשרות הזו כשמטמיעים CSP לצורכי אבטחה, וזו המטרה הרגילה של הארגון: הגנה מפני בעיות של סקריפטים חוצי-אתרים (וכדי לעשות זאת, צריך להשתמש במדיניות CSP מחמירה). לאחר שזיהיתם את כל הסקריפטים המובְנים שבהם הדף שלכם משתמש, תוכלו להכין רשימה שלהם, לחשב ערך גיבוב (hash) או להוסיף ערך אקראי (שנקרא "nonce") לכל אחד מהם, ולאחר מכן להוסיף את רשימת הגיבובים ל-Content Security Policy. כך תוכלו למנוע טעינה של כל סקריפט שלא מופיע ברשימה. צריך לשלב את התהליך הזה בתהליך הייצור של האתר: הסקריפטים בדפים צריכים לכלול את הצופן החד-פעמי, או שיחושב כחלק מה-build. לפרטים נוספים, אפשר לעיין במאמר על strict-csp.

למרבה המזל, הדפדפנים תומכים בכותרת קשורה, Content-Security-Policy-Report-Only. אם נקבל את הכותרת הזו, בקשות שמפרות את המדיניות שסופקה לא ייחסמו, אבל דוח JSON יישלח לכתובת ה-URL שסופקה. כותרת כזו עשויה להיראות כך: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, ואם הדפדפן טוען סקריפט מכל מקום שאינו 3p.example.com, הבקשה תבוצע בהצלחה אבל הדוח יישלח לכתובת report-uri שצוינה. בדרך כלל, משתמשים בה כדי להתנסות במדיניות לפני ההטמעה שלה, אבל כדאי להשתמש בה כדי לבצע "בדיקה מתמשכת". בנוסף לביקורת הרגילה שתוארה למעלה, תוכלו להפעיל את הדיווח של CSP כדי לראות אם מופיעים דומיינים לא צפויים. המשמעות יכולה להיות שהמשאבים שלכם מצד שלישי טוענים משאבים של צד שלישי משלהם ועליכם לשקול ולהעריך אותם. (כמובן שזה יכול להיות סימן לניצול לרעה של סקריפטים חוצי-אתרים, כמובן, שגם חשוב לדעת עליהם!)

Content-Security-Policy הוא API מורכב וקל לשימוש. אנחנו מודעים לכך, ואנחנו ממשיכים לפתח את "הדור הבא" של ה-CSP .הדור הבא יכול לעמוד באותם יעדים, אבל לא יהיה מורכב במיוחד. זה עדיין לא מוכן, אבל אם אתם רוצים לדעת מה הכיוון הזה (או כדי לגלות מה המטרה שלהם ולעזור לנו בעיצוב,), כדאי להיכנס לכתובת https://github.com/WICG/csp-next לפרטים נוספים.

מה מותר לעשות

צריך להוסיף את כותרת ה-HTTP הזו לדפים שמוצגים: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. כשה-JSON מפורסם בכתובת ה-URL הזו, מאחסנים אותו. בודקים את הנתונים המאוחסנים כדי לקבל אוסף של דומיינים של צד שלישי שהאתר שלכם מבקש ממשתמשים אחרים. כדי לראות מתי הרשימה משתנה, צריך לעדכן את הכותרת Content-Security-Policy-Report-Only כך שתפרט את הדומיינים הרצויים:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

סיבה

תהליך זה מהווה חלק מהביקורת הטכנית שלך, באופן מתמשך. בבדיקה הטכנית הראשונית תוכלו לראות רשימה של צדדים שלישיים שהאתר משתף איתם נתוני משתמשים או מעביר אליהם נתוני משתמשים. לאחר מכן, הכותרת הזו תגרום לבקשות בדפים לדווח לאילו צדדים שלישיים פנו אליכם עכשיו, ותוכלו לעקוב אחר שינויים לאורך זמן. בנוסף להתראה על שינויים שבוצעו על ידי צדדים שלישיים קיימים, אתם גם תסמנו צדדים שלישיים חדשים שנוספו ושלא נוספו לביקורת הטכנית. חשוב לעדכן את הכותרת כדי להפסיק לדווח על הדומיינים הצפויים, אבל חשוב גם לחזור מדי פעם על הבדיקה הטכנית הידנית (כי הגישה Content-Security-Policy לא מסמנת אילו נתונים מועברים, אלא רק שבוצעה בקשה).

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

מדיניות ההרשאות

הקונספט של הכותרת Permissions-Policy (שנקרא בשם Feature-Policy) דומה ל-Content-Security-Policy, אבל היא מגבילה את הגישה לתכונות דפדפן מתקדמות. לדוגמה, אפשר להגביל את השימוש בחומרה של המכשיר כמו מד התאוצה, המצלמה או התקני USB, או להגביל תכונות שאינן חומרה, כמו הרשאה לעבור למסך מלא או להשתמש ב-XMLHTTPRequest סינכרוני. אפשר להחיל את ההגבלות האלה על דף ברמה העליונה (כדי למנוע מהסקריפטים שנטענו לנסות להשתמש בתכונות האלה) או על דפים במסגרות משנה שנטענים דרך iframe. ההגבלה הזו על השימוש ב-API לא קשורה ליצירת טביעת אצבע דיגיטלית (fingerprinting) של הדפדפן. היא רק מאפשרת למנוע מצד שלישי לבצע פעולות מפריעות (כמו שימוש בממשקי API חזקים, חלון קופץ של הרשאות וכו'). הערך הזה מוגדר על ידי מודל האיומים על פרטיות יעד בתור "פריצה".

כותרת Permissions-Policy מוגדרת כרשימה של זוגות (צמדים של מאפיין, מקורות מותרים), באופן הזה:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

הדוגמה הזו מאפשרת לדף הזה ('עצמי') ול-<iframe> מהמקור example.com להשתמש בממשקי ה-API של navigator.geolocation מ-JavaScript. היא מאפשרת לדף הזה ולכל מסגרות המשנה להשתמש ב-API של מסך מלא, והיא אוסרת על כל דף, כולל הדף הזה, להשתמש במצלמה כדי לקרוא מידע על סרטונים. תוכלו למצוא כאן הרבה יותר פרטים ורשימת דוגמאות אפשריות.

רשימת התכונות שמטופלות על ידי הכותרת Permissions-Policy גדולה, ויכול להיות שתהיה להן השפעה שוטפת. נכון לעכשיו, הרשימה מתוחזקת בכתובת https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

מה מותר לעשות

כברירת מחדל, דפדפנים שתומכים ב-Permissions-Policy לא מאפשרים שימוש בתכונות מתקדמות בתת-מסגרות, ועליכם לפעול כדי להפעיל אותן! הגישה הזו פרטית כברירת מחדל. אם תתי-מסגרות באתר שלכם מחייבות את ההרשאות האלה, תוכלו להוסיף אותן באופן סלקטיבי. עם זאת, לא חלה מדיניות הרשאות על הדף הראשי כברירת מחדל, ולכן סקריפטים (כולל סקריפטים של צד שלישי) שנטענים על ידי הדף הראשי לא מוגבלים לניסיון להשתמש בתכונות האלה. לכן מומלץ להחיל מדיניות Permissions-Policy מגבילה על כל הדפים כברירת מחדל, ולאחר מכן להוסיף בהדרגה תכונות שנדרשות בדפים שלכם.

דוגמאות לתכונות חזקות ש-Permissions-Policy מושפעות כוללות בקשה למיקום המשתמש, גישה לחיישנים (כולל מד תאוצה, ג'ירוסקופ ומגנטומטר), הרשאת הצגה במסך מלא ובקשת גישה למצלמה ולמיקרופון של המשתמש. רשימה מלאה של התכונות (המשתנה) מופיעה למעלה.

לצערנו, חסימה של כל התכונות כברירת מחדל והתרה סלקטיבית שלהן מחדש דורשת רישום של כל התכונות בכותרת, דבר שעלול להיראות לא אלגנטי. עם זאת, כותרת Permissions-Policy כזו היא נקודת התחלה טובה. ל-permissionspolicy.com/ יש מחולל שניתן ללחוץ עליו כדי ליצור כותרת כזו: שימוש בה ליצירת כותרת שמשבית את כל התכונות, מביא לתוצאות הבאות:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

הסבר על תכונות הפרטיות המובנות בדפדפני אינטרנט

בנוסף להגנות 'זמן build' ו'זמן תכנון', קיימות גם הגנות על פרטיות שמופעלות בזמן ריצה: כלומר, תכונות פרטיות שמוטמעות בדפדפנים עצמם כדי להגן על המשתמשים. אלו לא תכונות שאתם יכולים לשלוט בהן ישירות או להשתמש בהן כמפתחי אתרים – אלה תכונות של המוצר – אבל הן תכונות שכדאי להיות מודעים להן, כי האתרים שלכם עשויים להיות מושפעים מההחלטות האלה לגבי המוצרים בדפדפנים. הדוגמה הבאה ממחישה את האופן שבו הגנות הדפדפן עשויות להשפיע על האתר שלך: כאשר משתמשים ב-JavaScript בצד הלקוח שממתין לטעינה של תלות של צד שלישי לפני שממשיכים בהגדרת הדף, והתלות של צד שלישי לא תיטען בכלל, יכול להיות שהגדרת הדף אף פעם לא תסתיים ולכן יוצג למשתמש דף שנטענו למחצה.

השירותים האלה כוללים את התכונה Intelligent Tracking Prevention (מניעת מעקב חכמה) ב-Safari (ובמנוע ה-WebKit הבסיסי), ו-Enhanced Tracking Protection (הגנת מעקב משופרת) ב-Firefox (ובמנוע Gecko שלו). כל הגורמים האלה מקשה על צדדים שלישיים ליצור פרופילים מפורטים של המשתמשים שלכם.

גישות הדפדפן בנושא תכונות פרטיות משתנות לעיתים קרובות, וחשוב להתעדכן באופן קבוע. רשימת ההגנות שבהמשך נכונה בזמן הכתיבה. דפדפנים יכולים גם ליישם הגנות אחרות. רשימות אלה הן חלקיות. עיינו במודול השיטות המומלצות כדי להתעדכן בשינויים שביצענו. הקפידו לבדוק בגרסאות הבאות של הדפדפן שינויים שעשויים להשפיע על הפרויקטים שלכם. חשוב לזכור שמצבי גלישה פרטית/פרטית מיישמים לפעמים הגדרות שונות מברירת המחדל של הדפדפן (לדוגמה, קובצי cookie של צד שלישי עשויים להיחסם כברירת מחדל במצבים כאלה). לכן, בדיקות במצב פרטי לא תמיד משקפות את חוויית הגלישה הטיפוסית של רוב המשתמשים אם הם לא משתמשים בגלישה פרטית. חשוב גם לזכור שחסימה של קובצי cookie במצבים שונים עלולה לגרום גם לחסימת פתרונות אחסון אחרים, כמו window.localStorage, ולא רק קובצי cookie.

Chrome

• קובצי cookie של צד שלישי אמורים להיחסם בעתיד. נכון לרגע זה, הם לא חסומים כברירת מחדל (אבל משתמש יכול להפעיל זאת): https://support.google.com/chrome/answer/95647 הסבר על הפרטים.
• תכונות הפרטיות של Chrome, ובמיוחד התכונות ב-Chrome שמתקשרות עם שירותי Google ועם שירותי צד שלישי, מתוארות בכתובת privacysandbox.com/.

Edge

• קובצי cookie של צד שלישי אינם חסומים כברירת מחדל (אבל משתמש יכול להפעיל אותם).
• התכונה מניעת מעקב של Edge חוסמת כברירת מחדל כלי מעקב מאתרים שלא נכנסו אליהם, וכלי מעקב מזיקים ידועים.

Firefox

• קובצי cookie של צד שלישי אינם חסומים כברירת מחדל (אבל משתמש יכול להפעיל אותם).
• התכונה הגנת מעקב משופרת של Firefox חוסמת כברירת מחדל קובצי cookie למעקב, סקריפטים של טביעת אצבע דיגיטלית, סקריפטים של קריפטומיינר וכלי מעקב ידועים. (בכתובת https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track מופיעים פרטים נוספים).
• קובצי cookie של צד שלישי הם מוגבלים לאתרים, כך שלכל אתר יש למעשה מאגר נפרד של קובצי cookie ולא ניתן לקשר אותו בין האתרים (ב-Mozilla השם הזה נקרא "Total cookie Protection".

כדי לקבל תובנות לגבי הבעיות שעלולות להיות חסומים וכדי לנפות באגים, אפשר ללחוץ על סמל המגן בסרגל הכתובות או לעבור אל about:protections ב-Firefox (במחשב).

Safari

• קובצי cookie של צד שלישי חסומים כברירת מחדל.
• כחלק מהתכונה מניעת מעקב חכמה, Safari מצמצם את הגורם המפנה שמעבירים לדפים אחרים לאתר ברמה עליונה, במקום לדף ספציפי: (https://something.example.com, במקום https://something.example.com/this/specific/page).
• נתוני הדפדפן localStorage נמחקים אחרי שבעה ימים.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ מסכם את התכונות האלה).

כדי לקבל תובנות לגבי הפרטים שעשויים להיות חסומים וכדי לנפות באגים, כדאי להפעיל את האפשרות 'מצב ניפוי באגים של מניעת מעקב חכמה' בתפריט הפיתוח של Safari (במחשב). (פרטים נוספים זמינים במאמר https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/).

הצעות API

למה אנחנו צריכים ממשקי API חדשים?

תכונות וכללי מדיניות חדשים לשמירה על הפרטיות במוצרי הדפדפן עוזרים לשמור על פרטיות המשתמשים, אבל גם בהם יש אתגרים. טכנולוגיות אינטרנט רבות ניתנות לשימוש לצורך מעקב באתרים שונים, למרות שהן מיועדות ומשמשות למטרות אחרות. לדוגמה, מערכות רבות של איחוד שירותי אימות הזהות שמשמשות אותנו מדי יום מסתמכות על קובצי cookie של צד שלישי. פתרונות פרסום רבים שבעלי אתרים מסתמכים עליהם כיום לצורך הכנסות, מבוססים על קובצי cookie של צד שלישי. פתרונות רבים לזיהוי הונאות מסתמכים על יצירה של טביעת אצבע דיגיטלית (fingerprinting). מה קורה לתרחישים לדוגמה האלה אחרי שקובצי ה-cookie של צד שלישי והיצירה של טביעת אצבע נעלמים?

לדפדפנים יהיה קשה מאוד להבדיל בין תרחישים שונים לדוגמה לבין שימושים אחרים, ולהבדיל באופן מהימן בין שימושים שמפרים את הפרטיות לבין שימושים אחרים. זו הסיבה שרוב הדפדפנים הגדולים חסמו קובצי cookie של צד שלישי ויצירה של טביעת אצבע דיגיטלית (fingerprinting), או מתכוונים לעשות זאת כדי להגן על פרטיות המשתמשים.

נדרשת גישה חדשה: אנחנו מוציאים משימוש קובצי cookie של צד שלישי ומצמצמים את האפשרות ליצור טביעת אצבע דיגיטלית (fingerprinting), והמפתחים זקוקים לממשקי API ייעודיים שפועלים בתרחישים לדוגמה (שעוד לא נעלמו), אבל תוכננו באופן ששומר על הפרטיות. המטרה היא לתכנן ולבנות ממשקי API שלא ניתן להשתמש בהם למעקב בין אתרים. בשונה מתכונות הדפדפן שמתוארות בקטע הקודם, הטכנולוגיות האלה שואפות להפוך לממשקי API שמתאימים לדפדפנים שונים.

דוגמאות להצעות API

הרשימה הבאה אינה מקיפה - זו גרסה של חלק ממה שמדברים עליה.

דוגמאות להצעות API להחלפת טכנולוגיות שמבוססות על קובצי cookie של צד שלישי:

• תרחישים לדוגמה של זהות: FedCM
• תרחישים לדוגמה במודעות: Private Click Measurement (מדידת קליקים פרטיים), Interactive Private Attribution, דוחות השיוך (Attribution), נושאים, FLEDGE, PARAKEET.

דוגמאות להצעות API להחלפת טכנולוגיות שמבוססות על מעקב פסיבי:

• תרחישים לדוגמה לזיהוי הונאות: Trust Tokens.

דוגמאות להצעות נוספות שממשקי API אחרים יוכלו להסתמך עליהן בעתיד ללא קובצי cookie של צד שלישי:

• Storage Access API

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

Global-Privacy-Control היא כותרת שמטרתה להעביר לאתר הודעה שהמשתמש מעוניין שנתונים אישיים שנאספו לא ישותפו עם אתרים אחרים. הכוונה שלה דומה לפעולה 'אל תעקוב', שהוצאה משימוש.

סטטוס הצעות ה-API

רוב ההצעות האלה ל-API עדיין לא נפרסו, או שהן פרוסות רק מאחורי סימונים או בסביבות מוגבלות לצורך עריכת ניסויים.

שלב הדגירה הציבורי הזה חשוב: ספקי דפדפנים ומפתחים אוספים דיון וניסיון בשאלה אם ממשקי ה-API האלה שימושיים ואם הם באמת עושים את מה שהם נועדו. מפתחים, ספקי דפדפנים וגורמים אחרים בסביבה העסקית משתמשים בשלב הזה כדי לבצע איטרציה לעיצוב ה-API.

המקום הכי טוב להתעדכן בהצעות לממשקי API חדשים הוא כרגע רשימת ההצעות של קבוצת הפרטיות ב-GitHub.

האם אתם צריכים להשתמש בממשקי ה-API האלה?

אם המוצר שלכם מבוסס ישירות על קובצי cookie או טכניקות כמו יצירה של טביעת אצבע דיגיטלית (fingerprinting), אתם צריכים להיות מעורבים בממשקי ה-API החדשים, להתנסות בהם ולתרום את החוויות שלכם לדיונים ולעיצוב ה-API. בכל שאר המקרים, לא תצטרכו לדעת את כל הפרטים על ממשקי ה-API החדשים האלה בזמן הכתיבה, אבל כדאי להיות מודעים לעתיד.