עדכונים של SharedArrayBuffer ב-Android Chrome 88 וב-Chrome למחשב 92

Jake Archibald
Jake Archibald
X דף הבית
Eiji Kitamura

אפשר לומר שרמת הנחיתה של 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 על ידי שינוי הזיכרון בלולאה הדוקה בעובד, וקריאה אותו שוב בשרשור אחר. לא ניתן היה לצמצם את הבעיה ללא קוד בעל כוונות טובות, ולכן 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. בשביל iframes: להעביר את התוכן לתהליך אחר.

אחרי יישום המיטיגציות האלה, הוספנו את SharedArrayBuffer ל-Chrome 68 (יולי 2018), אבל רק במחשב. בעקבות הדרישות הנוספות, לא הצלחנו לעשות את אותו הדבר במכשירים ניידים. כמו כן, מצוין שהפתרון של Chrome לא הושלם, מכיוון שחסמנו רק את האפשרות 'שגוי' ואילו פורמטים של נתונים אפשרית (אבל חריגה) ש-CSS/JS/תמונות חוקיים בכתובות URL שניתן לנחש אותן מכילים מידע פרטי.

אנשים נפגשים עם תקן אינטרנט כדי ליצור גרסה מלאה יותר של דפדפנים שונים לפתרון הבעיה. הפתרון היה לתת לדפים דרך לומר "אני מוותר על יכולת לייבא תוכן ממקור אחר לתהליך הזה ללא הבעת הסכמה שלו". ההצהרה הזו מתבצעת באמצעות כותרות COOP ו-COEP מוצגת עם הדף. הדפדפן אוכף את הפעולה, ובתמורה הדף מרוויח גישה ל-SharedArrayBuffer ולממשקי API אחרים עם יכולות דומות. מקורות אחרים יכולים להצטרף להטמעת תוכן דרך Cross-Origin-Resource-Policy או CORS.

Firefox היה הראשון ששלח את SharedArrayBuffer עם ההגבלה הזו, גרסה 79 (יולי 2020).

ואז, בינואר 2021, כתבתי את המאמר הזה וקראתם אותו. שלום,

זה המקום שבו אנחנו נמצאים עכשיו. Chrome 88 מחזיר את SharedArrayBuffer אל Android לדפים שמבודדים ממקורות שונים, ו-Chrome 92 מספק את אותה פעולה למחשבים, גם לשמירה על עקביות וגם להשגת השגת היעדים של טרנספורמר.

השהיית השינוי ב-Chrome למחשב

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

  1. מבקשים אסימון למקור.
  2. מוסיפים את האסימון לדפים שלכם. אפשר לעשות זאת בשתי דרכים:
    • מוסיפים תג origin-trial <meta> בחלק העליון של כל דף. לדוגמה, זה יכול להיראות בערך כך:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • אם יש לכם אפשרות להגדיר את השרת, אתם יכולים גם להוסיף את האסימון באמצעות כותרת HTTP Origin-Trial. כותרת התגובה שתתקבל ייראה בערך כך:
      Origin-Trial: TOKEN_GOES_HERE

קריאה נוספת

תמונת הבאנר מאת דניאל Gregoire ב-Unbounce