Het is eerlijk om te zeggen SharedArrayBuffer een wat moeilijke landing op het internet heeft gehad, maar de zaken zijn aan het kalmeren. Dit is wat u moet weten:
In het kort
-
SharedArrayBufferwordt momenteel ondersteund in Firefox 79+ en zal verschijnen in Android Chrome 88. Het is echter alleen beschikbaar voor pagina's die cross-origin geïsoleerd zijn. -
SharedArrayBufferis momenteel beschikbaar in Desktop Chrome, maar vanaf Chrome 92 is dit beperkt tot geïsoleerde cross-origin-pagina's. Als u denkt dat u deze wijziging niet op tijd kunt doorvoeren, kunt u zich aanmelden voor een origin-proefperiode om het huidige gedrag te behouden tot minimaal Chrome 113. - Als u van plan bent cross-origin-isolatie in te schakelen om
SharedArrayBufferte blijven gebruiken, evalueer dan de impact die dit zal hebben op andere cross-origin-elementen op uw website, zoals advertentieplaatsingen. Controleer ofSharedArrayBufferwordt gebruikt door bronnen van derden om de impact en begeleiding te begrijpen.
Overzicht van isolatie van verschillende oorsprong
U kunt een pagina cross-origineel isoleren door de pagina met deze headers weer te geven:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Zodra u dit doet, kan uw pagina geen cross-origin-inhoud laden, tenzij de bron dit expliciet toestaat via een Cross-Origin-Resource-Policy header of CORS- headers ( Access-Control-Allow-* enzovoort).
Er is ook een rapportage-API , zodat u gegevens kunt verzamelen over verzoeken die zijn mislukt als gevolg van Cross-Origin-Embedder-Policy en Cross-Origin-Opener-Policy .
Als u denkt dat u deze wijzigingen niet op tijd kunt doorvoeren voor Chrome 92, kunt u zich registreren voor een origin-proefperiode om het huidige gedrag van Desktop Chrome te behouden tot ten minste Chrome 113.
Bekijk het gedeelte Verder lezen onderaan deze pagina voor meer richtlijnen en informatie over cross-origin isolatie.
Hoe zijn we hier terechtgekomen?
SharedArrayBuffer arriveerde in Chrome 60 (dat is juli 2017, voor degenen onder u die tijd in datums zien in plaats van in Chrome-versies), en alles was geweldig. Voor 6 maanden.
In januari 2018 werd een kwetsbaarheid onthuld in enkele populaire CPU's. Zie de aankondiging voor alle details, maar het betekende in wezen dat code timers met hoge resolutie kon gebruiken om geheugen te lezen waartoe het geen toegang zou moeten hebben.
Dit was een probleem voor ons, browserleveranciers, omdat we sites code willen laten uitvoeren in de vorm van JavaScript en WASM, maar strikt willen controleren tot welk geheugen deze code toegang heeft. Als u op mijn website terechtkomt, zou ik niets kunnen lezen van de internetbankiersite die u ook geopend heeft. Sterker nog, ik zou niet eens moeten weten dat u uw site voor internetbankieren open heeft. Dit zijn de basisprincipes van webbeveiliging.
Om dit te verhelpen, hebben we de resolutie van onze timers met hoge resolutie, zoals performance.now() , verlaagd. U kunt echter een timer met hoge resolutie maken met behulp van SharedArrayBuffer door het geheugen in een strakke lus in een werker aan te passen en het terug te lezen in een andere thread. Dit kon niet effectief worden verholpen zonder een grote impact te hebben op goedbedoelde code, dus werd SharedArrayBuffer helemaal uitgeschakeld.
Een algemene oplossing is om ervoor te zorgen dat het systeemproces van een webpagina geen gevoelige gegevens van elders bevat. Chrome had vanaf het begin geïnvesteerd in een architectuur met meerdere processen ( herinner je de strip nog? ), maar er waren nog steeds gevallen waarin gegevens van meerdere sites in hetzelfde proces terecht konden komen:
<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… -->
Deze API's hebben een 'verouderd' gedrag waardoor inhoud van andere oorsprong kan worden gebruikt zonder aanmelding van de andere oorsprong. Deze verzoeken worden gedaan met de cookies van de andere oorsprong, het is dus een volledig 'ingelogd' verzoek. Tegenwoordig vereisen nieuwe API's dat de andere oorsprong zich aanmeldt met behulp van CORS .
We hebben deze verouderde API's omzeild door te voorkomen dat inhoud het proces van de webpagina binnendringt als deze er 'onjuist' uitziet, en noemden dit cross-origin leesblokkering . In de bovenstaande gevallen staan we dus niet toe dat JSON deelneemt aan het proces, omdat het voor geen van deze API's een geldig formaat is. Dat wil zeggen, behalve iframes. Voor iframes plaatsen we de inhoud in een ander proces.
Nu deze maatregelen van kracht zijn, hebben we SharedArrayBuffer opnieuw geïntroduceerd in Chrome 68 (juli 2018), maar alleen op desktops. Door de extra procesvereisten konden we niet hetzelfde doen op mobiele apparaten. Er werd ook opgemerkt dat de oplossing van Chrome onvolledig was, omdat we alleen 'onjuiste' gegevensformaten blokkeerden, terwijl het mogelijk is (hoewel ongebruikelijk) dat geldige CSS/JS/afbeeldingen op raadbare URL's privégegevens kunnen bevatten.
Mensen op het gebied van webstandaarden kwamen samen om met een completere cross-browser oplossing te komen. De oplossing was om pagina's een manier te geven om te zeggen: "Ik doe hierbij afstand van mijn vermogen om inhoud van andere oorsprong in dit proces te betrekken zonder hun toestemming". Deze aangifte wordt gedaan via COOP- en COEP-headers die bij de pagina worden geleverd. De browser dwingt dat af, en in ruil daarvoor krijgt de pagina toegang tot SharedArrayBuffer en andere API's met vergelijkbare bevoegdheden. Andere oorsprongen kunnen zich aanmelden voor het insluiten van inhoud via Cross-Origin-Resource-Policy of CORS .
Firefox was de eerste die SharedArrayBuffer met deze beperking uitbracht, in versie 79 (juli 2020).
Vervolgens schreef ik in januari 2021 dit artikel, en jij leest het. Hallo.
En dat is waar we nu zijn. Chrome 88 brengt SharedArrayBuffer terug naar Android voor pagina's die cross-origin geïsoleerd zijn, en Chrome 92 brengt dezelfde vereisten naar de desktop, zowel voor consistentie als om totale cross-origin isolatie te bereiken.
De wijziging van Desktop Chrome uitstellen
Dit is een tijdelijke uitzondering in de vorm van een 'origin-proef' die mensen meer tijd geeft om geïsoleerde cross-origin-pagina's te implementeren. Het maakt SharedArrayBuffer mogelijk zonder dat de pagina cross-origin geïsoleerd hoeft te zijn. De uitzondering vervalt in Chrome 113 en de uitzondering is alleen van toepassing op Desktop Chrome.
- Vraag een token aan voor uw herkomst.
- Voeg het token toe aan uw pagina's. Er zijn twee manieren om dat te doen:
- Voeg een
origin-trial<meta>-tag toe aan de kop van elke pagina. Dit kan er bijvoorbeeld ongeveer zo uitzien:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - Als u uw server kunt configureren, kunt u het token ook toevoegen met behulp van een
Origin-TrialHTTP-header. De resulterende antwoordheader zou er ongeveer zo uit moeten zien:
Origin-Trial: TOKEN_GOES_HERE
- Voeg een
Verder lezen
- Een gids om cross-origin-isolatie mogelijk te maken
- Hoe u uw pagina's cross-origineel kunt isoleren
- Waarom cross-origin isolatie nodig is
Bannerfoto door Daniel Gregoire op Unsplash