SharedArrayBuffer עובד שוב בדפדפן, אך רק כאשר הדף נמצא במצב של cross-origin isolated – מצב הדורש שתי כותרות תגובה (response headers). הוספת הכותרות הללו אילצה אותי לוותר על כל סקריפט צד-שלישי באתר שלי, מהלך שעיצב מחדש את כל מבנה ה-front end ואת סוג הנתונים שהוא מדליף.

למה הכותרות הללו חשובות

SharedArrayBuffer מאפשר ריבוי תהליכונים (multithreading) אמיתי ב-JavaScript, תנאי מוקדם להרצת ffmpeg בתוך לשונית. דפדפנים מודרניים הפעילו מחדש את התכונה לאחר הפעלת הגנות מסוג Spectre, אך הם קשרו אותה ל-cross-origin isolation. כדי להשיג בידוד זה, השרת חייב לשלוח:

  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp

הכותרת השנייה, require-corp, אומרת לדפדפן שכל משאב חיצוני חייב לשאת כותרת Cross-Origin-Resource-Policy או להישלף באמצעות CORS (Cross-Origin Resource Sharing). רוב שירותי הצד-שלישי אינם מגדירים את הכותרות הללו, ולכן הסקריפטים, הגופנים וה-iframes שלהם נחסמים לחלוטין.

מה נעלם כשבידוד הופעל

ברגע שהכותרות נכנסו לתוקף, שרשרת של כשלים הופיעה:

  • Analytics – רוב הספקים טוענים את קוד המעקב שלהם באמצעות <script> פשוט שמבצע בקשת no-CORS. ללא כותרת CORP, הבקשה נדחית, ולכן המעקב לעולם לא פועל.
  • Google Fonts – גיליון העיצוב (stylesheet) נשלף מ-fonts.googleapis.com ללא CORS. הדפדפן מבטל אותו, מה שמותיר את הדף ללא הטיפוגרפיה המותאמת שלו.
  • Embedded media – iframes של YouTube וסקריפטים של ווידג'טים חסרים CORP, ולכן הם מפסיקים להופיע.
  • OAuth pop-ups – הקשר window.opener נשבר בשל מדיניות ה-same-origin המחמירה, מה ששובר את תהליך ההתחברות הרגיל המבוסס על חלונות קופצים (popups).

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

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

מול אתר שבור, כתבתי מחדש את ה-front-end stack סביב נכסים המאוחסנים באופן עצמאי (self-hosted):

  • Fonts and images מוגשים כעת מה-origin שלי, מה שמבטל את הצורך בגיליונות עיצוב חיצוניים.
  • Data APIs בנויים על backend פרטי שאני שולט בו, כך שכל בקשה נשארת בתוך הדומיין שלי.
  • Analytics הפכו ל-Cloudflare Worker קטן שמקבל אירועי POST ושומר אותם ב-bucket פרטי. צד הלקוח הוא רק תריסר שורות של קוד fetch.
  • Error reporting and session replay – כלים כמו Sentry הוסרו לחלוטין; כל קריסה נרשמת כעת ב-endpoint שלי.

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

רווחים בפרטיות מול עלות תפעולית

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

המחיר הוא נטל תחזוקה נוסף. אירוח גופנים, ניהול אחסון ה-analytics ושמירה על proxy מעודכן הם משימות שרוב המפתחים מעבירים לשירותים מתמחים (outsource). הגישה הזו פירושה גם ויתור על תכונות שהשירותים הללו מספקים – למשל, ריכוז שגיאות בזמן אמת או ויזואליזציות מפורטות של משפכי המרה (funnels).

נקודת מבט נגדית: האם האקוסיסטם יסתגל?

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

איך לוודא שאתם באמת מבודדים

לפני שאתם מתחילים לכתוב מחדש, ודאו שהדפדפן רואה את הדף שלכם כמבודד:

crossOriginIsolated   // should be true
typeof SharedArrayBuffer   // should be "function"

אם אחת הבדיקות נכשלת, הכותרות אינן מוחלות כראוי, ו-SharedArrayBuffer יישאר לא זמין.

מה הלאה עבור מפתחים?

ככל שיותר אפליקציות ווב יחפשו את שיפור הביצועים של JavaScript מרובה תהליכונים, הלחץ על ספקי צד-שלישי לאמץ CORP יגדל. בינתיים, כל פרויקט שזקוק ל-SharedArrayBuffer צריך לתכנן אסטרטגיית נכסים ב-self-hosted או שכבת proxy קלה. מעקב אחר הערות השחרור (release notes) של הדפדפנים לגבי שינויים בדרישות הבידוד יהיה גם הוא חיוני.

שורה תחתונה: הפעלת cross-origin isolation כדי לפתוח את האפשרות להשתמש ב-SharedArrayBuffer מציבה בחירה קשה – לשמור על הנוחות של סקריפטים מצד שלישי או להחליף אותה במודל פרטיות הדוק ומבוקר עצמית. ההחלטה מעצבת מחדש הן את הארכיטקטורה הטכנית והן את טביעת הרגל של זרימת הנתונים באתרים מודרניים.