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

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

אפשר לומר שההשקה של SharedArrayBuffer באינטרנט הייתה קצת קשה, אבל המצב מתייצב. דברים שעליך לדעת:

בקצרה

  • בשלב הזה, יש תמיכה ב-SharedArrayBuffer ב-Firefox מגרסה 79 ומעלה, והיא תגיע ל-Android Chrome מגרסה 88. עם זאת, היא זמינה רק לדפים שחסומים לגישה מדומיינים אחרים.
  • SharedArrayBuffer זמין כרגע ב-Chrome למחשב, אבל החל מגרסה 92 של Chrome הוא יהיה מוגבל לדפים מבודדים ממקורות שונים. אם אתם לא מצליחים לבצע את השינוי הזה בזמן, תוכלו להירשם לתקופת ניסיון למקור כדי לשמור על ההתנהגות הנוכחית לפחות עד גרסה 113 של Chrome.
  • אם אתם מתכוונים להפעיל בידוד בין מקורות כדי להמשיך להשתמש ב-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 למחשב עד ל-Chrome 113 לפחות.

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

איך הגענו לכאן?

SharedArrayBuffer הגיע ל-Chrome 60 (זהו יולי 2017, למי שמחשב את הזמן לפי תאריכים ולא לפי גרסאות של Chrome), והכול היה נהדר. למשך 6 חודשים.

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

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

כדי לצמצם את הבעיה הזו, הפחתנו את הרזולוציה של הטיימרים ברזולוציה גבוהה, כמו performance.now(). עם זאת, אפשר create טיימר ברזולוציה גבוהה באמצעות 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, כתבתי את המאמר הזה ואתם קוראים אותו. שלום,

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

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

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

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

קריאה נוספת

תמונת הבאנר של Daniel Gregoire ב-Unsplash