SharedArrayBuffer sasa inafanya kazi tena kwenye kivinjari, lakini inafanya kazi tu wakati ukurasa ukiwa umetengwa kwa cross-origin – hali inayohitaji vichwa viwili vya majibu (response headers). Kuongeza vichwa hivyo ilinilazimu kuacha kila skripti ya upande wa tatu kwenye tovuti yangu, hatua iliyobadilisha jinsi front end nzima inavyojengwa na data inayovuja.

Kwa nini vichwa hivyo ni muhimu

SharedArrayBuffer inawezesha multithreading ya kweli katika JavaScript, sharti la awali la kuendesha ffmpeg ndani ya tab. Vivinjari vya kisasa vimeanzisha tena kipengele hiki baada ya hatua za kuzuia za aina ya Spectre, lakini vimekiunganisha na cross-origin isolation. Ili kufikia utengaji huo, seva lazima itume:

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

Kichwa cha pili, require-corp, kinaiambia kivinjari kwamba rasilimali yoyote ya nje lazima iwe na kichwa cha Cross-Origin-Resource-Policy au ipatikane kwa kutumia CORS (Cross-Origin Resource Sharing). Huduma nyingi za upande wa tatu haziset vichwa hivyo, hivyo skripti, fonti, na iframes zao zinazuiliwa moja kwa moja.

Nini kilipotea wakati utengaji ulipowashwa

Mara tu vichwa hivyo vilipoanza kufanya kazi, mfululizo wa hitilafu ulitokea:

  • Analytics – watoa huduma wengi hupakia kodi yao ya ufuatiliaji kwa kutumia <script> rahisi inayofanya ombi la no-CORS. Bila kichwa cha CORP, ombi linakataliwa, hivyo kifuatiliaji hakifanyi kazi kamwe.
  • Google Fonts – mtindo wa maandishi (stylesheet) hupatikana kutoka fonts.googleapis.com bila CORS. Kivinjari hukitupa, na kuacha ukurasa bila aina maalum ya maandishi (typography).
  • Embedded media – iframes za YouTube na skripti za widget hazina CORP, hivyo zinaacha kuonyeshwa.
  • OAuth pop-ups – uhusiano wa window.opener unavunjwa na sera kali ya same-origin, hivyo kuvuruga mtiririko wa kawaida wa kuingia (login) unaotumia pop-up.

Kwa kifupi, rasilimali yoyote iliyotegemea domain ya upande wa tatu ilipotea isipokuwa domain hiyo ilipokubali mfumo mpya wa vichwa hivyo.

Kujenga upya bila wasaidizi wa kati

Nikikabiliwa na tovuti iliyoharibika, niliandika upya mfumo wa front-end kwa kutumia rasilimali zinazojihost (self-hosted):

  • Fonti na picha sasa zinatolewa kutoka kwenye domain yangu mwenyewe, hivyo kuondoa hitaji la stylesheet za nje.
  • Data APIs zimejengwa kwenye backend ya faragha ninayodhibiti, ili kila ombi libaki ndani ya domain yangu.
  • Analytics ikageuzwa kuwa Cloudflare Worker ndogo inayokubali matukio ya POST na kuyahifadhi kwenye bucket ya faragha. Upande wa mteja (client side) ni mistari michache tu ya kodi ya fetch.
  • Zana za kuripoti makosa na kucheza upya vikao (session replay) kama Sentry ziliachwa kabisa; hitilafu yoyote sasa inarekodiwa kwenye endpoint yangu mwenyewe.

Ikiwa rasilimali ya nje bado inahitajika, njia pekee inayowezekana ni kuipitisha kupitia proxy ya seva unayomiliki, ukiongeza kichwa cha CORP kinachohitajika kabla kivinjari hakijaiona.

Faida za faragha dhidi ya gharama za uendeshaji

Faida ya haraka iko wazi: tovuti haivuji tena data ya matumizi kwa mitandao ya matangazo, watoa fonti, au majukwaa ya video. Telemetry yote inabaki chini ya udhibiti wangu, na ninaweza kuifuta wakati wowote ninapotaka. Kiwango hicho cha faragha ni vigumu kufikia kwa mfumo wa kawaida wa upande wa tatu.

Mabadiliko (trade-off) ni mzigo wa ziada wa matengenezo. Ku-host fonti, kushughulikia uhifadhi wa analytics, na kuweka proxy ikiwa up-to-date ni kazi ambazo watengenezaji wengi huwakabidhi kwa huduma maalum. Njia hii pia inamaanisha kupoteza vipengele ambavyo huduma hizo hutoa – kwa mfano, muunganisho wa makosa wa wakati halisi (real-time error aggregation) au michoro ya kina ya mchakato wa mtumiaji (detailed funnel visualisations).

Hoja kinyume: je, mfumo utabadilika?

Baadhi wanahoji kuwa watoa huduma wa upande wa tatu hatimaye wataongeza vichwa vinavyohitajika, na kufanya utengaji wa cross-origin uwe rahisi kuukubali. Wachache tayari wanafanya hivyo, lakini wengi wa huduma zinazotumiwa sana bado hawafanyi hivyo. Mpaka mfumo utakapofikia kiwango hicho, watengenezaji lazima waamue ikiwa faida ya faragha inazidi juhudi za kihandisi zinazohitajika kujihost.

Jinsi ya kuhakikisha kuwa umetengwa kweli

Kabla ya kuanza kuandika upya, hakikisha kivinjari kinaona ukurasa wako kama umetengwa:

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

Ikiwa angalau moja ya ukaguzi huo itafeli, vichwa hivyo havijatumika kwa usahihi, na SharedArrayBuffer itaendelea kutopatikana.

Nini kinafuata kwa watengenezaji?

Wakati programu nyingi za wavuti zinatafuta ongezeko la utendaji la JavaScript ya multithreaded, shinikizo kwa watoa huduma wa upande wa tatu la kuanza kutumia CORP litaongezeka. Wakati huo huo, mradi wowote unaohitaji SharedArrayBuffer unapaswa kupanga mkakati wa rasilimali zinazojihost au tabaka nyepesi la proxy. Kufuatilia maelezo ya toleo za kivinjari (browser release notes) kwa mabadiliko ya mahitaji ya utengaji pia kutakuwa muhimu.

Muhtasari: Kuwezesha cross-origin isolation ili kufungua SharedArrayBuffer kunaleta chaguo gumu – kuendelea na urahisi wa skripti za upande wa tatu au kuubadili kwa ajili ya mfumo wa faragha ulioimarishwa na unaodhibitiwa wenyewe. Uamuzi huo unabadilisha usanifu wa kiufundi na athari za mtiririko wa data katika tovuti za kisasa.