סביר להניח שהנחיתה של SharedArrayBuffer באינטרנט לא טובה, אבל הכול מסתדר. דברים שעליך לדעת:
בקצרה
- בשלב זה,
SharedArrayBufferנתמך ב-Firefox 79 ואילך, והוא יגיע ב-Android Chrome 88. עם זאת, הוא זמין רק לדפים שמבודדים ממקורות שונים. - בשלב הזה,
SharedArrayBufferזמין ב-Chrome למחשב, אבל החל מ-Chrome 92 הוא יוגבל לדפים מבודדים ממקורות שונים. אם לדעתכם אי אפשר לבצע את השינוי הזה בזמן, אפשר להירשם לגרסת מקור לניסיון כדי לשמור על ההתנהגות הנוכחית עד Chrome 113 לפחות. - אם אתם מתכוונים לאפשר בידוד בין מקורות כדי להמשיך להשתמש ב-
SharedArrayBuffer, כדאי להעריך את ההשפעה שתהיה לכך על רכיבים אחרים באתר, כמו מיקומי מודעות. בדקו אם אחד ממשאבי הצד השלישי משתמש ב-SharedArrayBufferכדי להבין את ההשפעה וההנחיות.
סקירה כללית בנושא בידוד בין מקורות
אפשר להפוך דף למבודד ממקורות שונים על ידי הצגת הדף עם הכותרות הבאות:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
לאחר מכן, הדף לא יוכל לטעון תוכן ממקורות שונים, אלא אם המשאב יאפשר זאת באופן מפורש באמצעות כותרת Cross-Origin-Resource-Policy או כותרות CORS (Access-Control-Allow-* וכן הלאה).
יש גם Reporting API שמאפשר לאסוף נתונים על בקשות שנכשלו כתוצאה מ-Cross-Origin-Embedder-Policy ומ-Cross-Origin-Opener-Policy.
אם אתם לא חושבים שתוכלו לבצע את השינויים האלה בזמן ל-Chrome 92, תוכלו להירשם לגרסת מקור לניסיון כדי לשמור על ההתנהגות הנוכחית של Chrome במחשב עד גרסה 113 של Chrome לפחות.
לקבלת הנחיות ומידע נוספים על בידוד בין מקורות, קראו את הקטע קריאה נוספת שבתחתית הדף הזה.
איך הגענו לכאן?
SharedArrayBuffer הגיע ל-Chrome 60 (כלומר יולי 2017, לאלה מכם שחושבים על זמן בתאריכים במקום גרסאות של Chrome), והכול היה נהדר.
למשך 6 חודשים.
בינואר 2018 נחשפה נקודת חולשה בכמה מעבדים (CPU) פופולריים. כדאי לקרוא את ההודעה עם כל הפרטים, אבל למעשה הקוד הזה יכול להשתמש בטיימרים ברזולוציה גבוהה כדי לקרוא זיכרון שהוא לא אמור לקבל גישה אליו.
ספקי הדפדפנים היו צריכים לעשות זאת, כי אנחנו רוצים לאפשר לאתרים להפעיל קוד בצורת JavaScript ו-WASM, אבל לשלוט אך ורק בזיכרון שלקוד יש גישה אליהם. אם אתם מגיעים לאתר שלי, לא אמורה להיות לי אפשרות לקרוא שום דבר באתר הבנקאות שגם פתחתם. למעשה, אני לא אמור לדעת שאתר הבנקאות שלכם באינטרנט פתוח. אלו הם היסודות של אבטחת אינטרנט.
כדי לצמצם את התופעה הזו, צמצמנו את הרזולוציה של הטיימרים ברזולוציה הגבוהה, כמו performance.now(). עם זאת, אפשר ליצור טיימר ברזולוציה גבוהה באמצעות SharedArrayBuffer על ידי שינוי הזיכרון בלולאה צפופה ב-worker, וקריאתו בשרשור אחר. אי אפשר היה לצמצם את הבעיה בצורה יעילה בלי להשפיע בצורה משמעותית על הקוד בכוונה טובה, ולכן SharedArrayBuffer הושבת לגמרי.
כדי להקל באופן כללי, צריך לוודא שתהליך המערכת של דף אינטרנט לא מכיל מידע אישי רגיש ממקום אחר. Chrome השקיע מלכתחילה בארכיטקטורה מרובת תהליכים (זוכרים את הקומיקס?), אבל עדיין היו מקרים שבהם נתונים מאתרים מרובים יכלו להגיע באותו תהליך:
<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->
לממשקי ה-API האלה יש התנהגות 'מדור קודם', שמאפשרת להשתמש בתוכן ממקורות אחרים בלי להפעיל הסכמה מהמקור האחר. הבקשות האלה נשלחות באמצעות קובצי ה-cookie של המקור האחר, כך שזו בקשה מלאה ש'מחוברת'. כיום, כדי להשתמש בממשקי API חדשים, המקור השני צריך להביע הסכמה באמצעות CORS.
כדי לעבוד על ממשקי ה-API האלה מדור קודם, מנענו מתוכן להיכנס לתהליך של דף האינטרנט אם הוא נראה 'שגוי', וקראו לו חסימת קריאה ממקורות שונים. במקרים שלמעלה, לא נאפשר ל-JSON להיכנס לתהליך כי הוא לא פורמט חוקי לאף אחד מממשקי ה-API האלה. זאת, מלבד מסגרות iframe. למסגרות iframe, אנחנו מעבירים את התוכן בתהליך אחר.
לאחר ההקלות האלה, הצגנו מחדש את SharedArrayBuffer ב-Chrome 68 (יולי 2018), אבל רק במחשב. כתוצאה מדרישות התהליך הנוספות, לא יכולנו לעשות את אותו הדבר במכשירים ניידים. בנוסף, צוין שהפתרון של Chrome לא היה מלא, כי חסמנו רק פורמטים 'שגויים' של נתונים, אבל ייתכן (אף על פי יוצא דופן) ש-CSS/JS/תמונות חוקיים בכתובות URL שניתן לנחש יוכלו להכיל נתונים פרטיים.
חברים בסטנדרטים של אתרים התאחדו כדי לחשוב על פתרון מקיף יותר
לדפדפנים שונים. הפתרון היה לאפשר לדפים לומר "אני מוותר בזאת על היכולת שלי להביא תוכן ממקור אחר לתהליך זה ללא הסכמתם".
ההצהרה הזו מתבצעת באמצעות כותרות COOP ו-COEP שמוצגות בדף. הדפדפן אוכף את זה, ובתמורה הדף מקבל גישה ל-SharedArrayBuffer ולממשקי API אחרים בעלי כוחות דומים. מקורות אחרים יכולים להביע הסכמה להטמעת תוכן דרך Cross-Origin-Resource-Policy או CORS.
Firefox היה הראשון ששלח את SharedArrayBuffer עם ההגבלה הזו, בגרסה 79 (יולי 2020).
ואז, בינואר 2021, כתבתי את המאמר הזה ואתם קראת אותו. שלום,
זה המקום שבו אנחנו נמצאים עכשיו. בגרסה 88 של Chrome, SharedArrayBuffer בחזרה ל-Android בדפים שמבודדים ממקורות שונים, ו-Chrome 92 מחזיר את אותן הדרישות למחשב, גם כדי לשמור על עקביות וגם כדי להשיג בידוד מוחלט בין מקורות.
השהיית שינוי Chrome במחשב
זהו חריג זמני בצורת 'גרסת מקור לניסיון' שנותן לאנשים יותר זמן להטמיע דפים מבודדים ממקורות שונים. היא מפעילה את SharedArrayBuffer בלי שיהיה צורך לבודד את הדף בין מקורות. החריג פג בגרסה 113 של Chrome, והחריג חל רק על Chrome במחשב.
- בקשו אסימון למקור.
- מוסיפים את האסימון לדפים. אפשר לעשות את זה בשתי דרכים:
- צריך להוסיף תג
origin-trial<meta>לראש כל דף. לדוגמה, זה עשוי להיראות כך:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - אם אפשר להגדיר את השרת, אפשר גם להוסיף את האסימון באמצעות כותרת HTTP מסוג
Origin-Trial. כותרת התגובה שתתקבל אמורה להיראות כך:
Origin-Trial: TOKEN_GOES_HERE
- צריך להוסיף תג
קריאה נוספת
תמונת הבאנר של דניאל גרגואר ב-UnFlood