A Chrome 91 kiadása

A Google bejelentette a Chrome 91 webböngésző kiadását. Ezzel egyidejűleg elérhető a Chromium nyílt forráskódú projekt stabil verziója, amely a Chrome alapja. A Chrome böngésző a Google logóinak használatával, a rendszeres értesítésekkel a leállásról, a védett videótartalom (DRM) lejátszásához szükséges modulokkal, az automatikus frissítések telepítési rendszerével és a keresések során RLZ-paraméterek átadásával tűnik ki. A következő Chrome 92 kiadásának időpontja július 20. tervezett.

A Chrome 91 főbb változásai:

• Lehetőséget kapunk a JavaScript végrehajtásának leállítására a minimalizált fülcsoportokban. A Chrome 85 bevezetésével lehetőség nyílt a fülek csoportosítására, amelyeket egy adott színnel és címkével lehet összekapcsolni. A csoport címkéjére kattintva a kapcsolódó fülek minimalizálódnak, és helyettük csak egy címke marad (a címkére kattintva a csoport újra megnyílik). Az új kiadás célja a CPU-terhelés csökkentése és az energiahatékonyság, így a minimalizált fülek aktivitása felfüggesztésre kerül. Kivételt képeznek azok a fülek, amelyekben hangot játszanak le, a Web Locks API-t vagy az IndexedDB-t használják, USB-eszközre csatlakoznak, vagy videót, hangot vagy ablakok tartalmát rögzítik. A módosítást fokozatosan vezetik be, kezdve a felhasználók kis százalékával.
• Bekapcsolták a kvantumszámítógépekkel szemben ellenálló kulcsegyesítési módszer támogatását. A kvantumszámítógépek lényegesen gyorsabban oldják meg az egész számok prímtényezőkre bontásának feladatát, amely a modern aszimmetrikus titkosítási algoritmusok alapja, és klasszikus processzorokon hatékonyan megoldhatatlan. A TLSv1.3-hoz a CECPQ2 (Combined Elliptic-Curve and Post-Quantum 2) plugint biztosítják, amely a klasszikus X25519 kulcscsere mechanizmust egy NTRU Prime algoritmusra épülő HRSS sémával ötvözi, amelyet posztkvantum kriptográfiai rendszerekhez fejlesztettek ki.
• Teljesen megszűnt a TLS 1.0 és TLS 1.1 protokollok támogatása, amelyeket az IETF (Internet Engineering Task Force) elavultnak minősített. Ezen kívül eltávolították a TLS 1.0/1.1 verziók visszaállításának lehetőségét az SSLVersionMin politika módosításával.
• A Linux platform blueprint includes the use of the "DNS over HTTPS" (DoH) mode, which was previously made available to users of Windows, macOS, ChromeOS, and Android. DNS-over-HTTPS will be automatically activated for users whose DNS provider settings support this technology (the same provider used for DNS is applied for DNS-over-HTTPS). For example, if a user has DNS 8.8.8.8 set in system settings, the Google DNS-over-HTTPS service ("https://dns.google.com/dns-query") will be activated in Chrome, while if DNS is 1.1.1.1, the Cloudflare DNS-over-HTTPS service ("https://cloudflare-dns.com/dns-query") will be used, and so on.
• Port 10080, used in Amanda backup and VMWare vCenter, has been added to the list of blocked network ports. Ports 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, and 6566 were already blocked earlier. Blocking for blacklisted ports prevents the sending of HTTP, HTTPS, and FTP requests to protect against NAT slipstreaming attacks, which allow an attacker to establish a network connection from their server to any UDP or TCP port on the user's system when opening a specially crafted web page in the browser, regardless of the use of internal address ranges (192.168.x.x, 10.x.x.x).
• The ability to configure the automatic launch of standalone web applications (PWA — Progressive Web Apps) upon user login (Windows and macOS) has been provided. Auto-launch can be configured on the chrome://apps page. Functionality is currently being tested on a small percentage of users, and for others, it requires enabling the setting "chrome://flags/#enable-desktop-pwas-run-on-os-login".
• As part of the transition to inclusive terminology in the browser, the file "master_preferences" has been renamed to "initial_preferences". To maintain compatibility, support for "master_preferences" will still be retained in the browser for some time. The browser has already removed the use of the terms "whitelist," "blacklist," and "native".
• A kibővített védelem a veszélyes webhelyek ellen (Enhanced Safe Browsing) üzemmódban további ellenőrzések aktiválódnak a phishing, rosszindulatú tevékenységek és egyéb webes fenyegetések ellen. Lehetővé vált a feltöltött fájlok Google általi ellenőrzésének küldése. Továbbá a kibővített védelem figyelembe veszi a Google fiókhoz kapcsolt tokeneket phishing kísérletek észlelésénél, valamint a Referrer fejléc értékeinek Google szerverekre való küldését a rosszindulatú webhelyekkel való átjárás ellenőrzésére.
• Az Android platformra készült kiadásban javultak a web-formák elemeinek megjelenítése, amelyek optimalizálva lettek érintőképernyők és mozgáskorlátozottak számára (az asztali rendszerekre a dizájnt a Chrome 83-ban alakították át). A redo célja az űrlapelemek megjelenésének egységesítése és a stílusbeli eltérések megszüntetése volt — korábban az űrlapelemek egy része az operációs rendszerek felhasználói felületének elemei szerint, míg más része a legnépszerűbb stílusok szerint lett tervezve. Emiatt a különböző elemek eltérően teljesítettek érintőképernyőkön és mozgáskorlátozottak számára.
• Felhasználói véleménykérdőív került bevezetésre, amely a Privacy Sandbox beállításainak megnyitásakor jelenik meg (chrome://settings/privacySandbox).
• Az Android verziójú Chrome indításakor a nagy képernyős táblagépeken a desktop verzió kérése, nem pedig a mobil változaté biztosított. A viselkedés megváltoztatható a ‘chrome://flags/#request-desktop-site-for-tablets’ beállítással.
• A táblázatok megjelenítési kódja átdolgozásra került, ami lehetővé tette a Chrome és a Firefox/Safari közötti táblázatok megjelenítési viselkedésének eltéréseinek megoldását.
• A spanyol Camerfirma hitelesítő központ szerveroldali tanúsítványainak feldolgozása leállításra került, a tanúsítványkibocsátás során 2017 óta tartó incidensek miatt. Az ügyfél tanúsítványok támogatása megmaradt, a blokkolás csak a HTTPS webhelyeken használt tanúsítványokra vonatkozik.
• A folytatásban megvalósítjuk a hálózati szegmentálás támogatását a felhasználók webhelyek közötti mozgásának nyomon követésének olyan módszereivel szemben, amelyek a nem állandó tárolásra szánt területeken ("Supercookies") tárolt azonosítókra alapoznak. Mivel a cache-ben tárolt források egy közös névtérben találhatók, függetlenül az eredeti domaintől, az egyik webhely meg tudja határozni, hogy egy másik webhely forrásait betöltötték-e a cache ellenőrzésével. A védelem a hálózati szegmentálás alkalmazásán alapul, amelynek lényege, hogy a közösen használt cache-ekhez további kötelező bejegyzéseket adunk hozzá. domain, ahonnan a főoldal meg van nyitva, ami korlátozza a cache terjedelmét a mozgáskövető szkriptek számára csak a jelenlegi webhelyre (az iframe-ből érkező szkript nem tudja ellenőrizni, hogy a forrást egy másik webhely töltötte-e be).

  A szegmentálás ára a cache-elés hatékonyságának csökkenése, ami a betöltési idő minimális növekedését eredményezi (maximálisan 1,32%, de a webhelyek 80%-ának esetében 0,09-0,75%-ot). A szegmentálási mód teszteléséhez indítsa el a böngészőt a következő kapcsolóval: "--enable-features=PartitionConnectionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, SplitHostCacheByNetworkIsolationKey".

• Hozzáadva egy külső REST API VersionHistory (https://versionhistory.googleapis.com/v1/chrome), amelyen keresztül megtudhatja a Chrome verziókra vonatkozó információkat platformok és ágak szerint, valamint a böngésző frissítési történetét.
• Az iframe-ekben, amelyeket a főoldaltól eltérő domainekről töltenek be, megtiltják a JavaScript-dialógusok, mint az alert(), confirm() és prompt() megjelenítését, amely megvédi a felhasználókat a külső szkriptek próbálkozásaitól, hogy az üzeneteket a fő webhely értesítéseként jelenítsék meg.
• Stabilizálták és alapértelmezettként javasolták a WebAssembly SIMD API-t a vektoros SIMD utasítások alkalmazásához WebAssembly formátumú alkalmazásokban. A platformfüggetlenség biztosítása érdekében egy új 128-bites típust javasolnak, amely különböző típusú csomagolt adatokat képviselhet, valamint több alapvető vektorműveletet a csomagolt adatok feldolgozásához. A SIMD lehetővé teszi a teljesítmény növelését az adatok párhuzamos feldolgozásával, és hasznos lesz a natív kód WebAssembly-re történő fordításakor.
• Az Origin Trials módban (kísérleti lehetőségek, amelyek külön aktiválást igényelnek) számos új API került hozzáadásra. Az Origin Trial lehetőséget ad az adott API használatára olyan alkalmazásokból, amelyeket a localhost vagy a 127.0.0.1-től töltöttek be, vagy a regisztráció és a különleges token megszerzése után, amely korlátozott ideig érvényes egy adott webhelyre.
  • A WebTransport — egy protokoll és a hozzá tartozó JavaScript API az adatok böngésző általi küldésére és fogadására. szerverrelA kommunikációs csatornát az HTTP/3 tetején alakítják ki, a QUIC protokoll használatával, amely lényegében egy UDP protokollra épül, lehetővé téve több kapcsolat egyidejű multiplexelését, és biztosítva a TLS/SSL-nek megfelelő titkosítási módszereket.

    A WebTransport a WebSockets és az RTCDataChannel mechanizmusok helyett használható, olyan kiegészítő lehetőségeket kínálva, mint a több szálú adatátvitel, egyirányú áramlások, csomagok sorrendjét nem figyelembe vevő szállítás (out-of-order), megbízható és megbízhatatlan szállítási módok. Ezen kívül a WebTransport használható a Server Push mechanizmus helyett is, amelyről a Google lemondott a Chrome-ban.

  • Deklaratív interfész a független webalkalmazások (PWA) hivatkozásainak meghatározására, amelyet a webalkalmazás manifestjében található capture_links paraméterrel vonnak be, lehetővé téve, hogy a webhelyek automatikusan új PWA ablakot nyissanak meg, amikor egy alkalmazás linkjére kattintanak, vagy egy ablakos üzemmódba lépjenek, hasonlóan a mobilalkalmazásokhoz.
  • Új API WebXR Plane Detection lett bevezetve, amely tájékoztatást nyújt a sík felületekről a virtuális 3D környezetben. Ez az API lehetővé teszi az erőforrásigényes adatok feldolgozásának elkerülését a MediaDevices.getUserMedia() hívásával, saját gépi látási algoritmusok alkalmazásával. Emlékeztetünk rá, hogy a WebXR API lehetővé teszi a különböző virtuális valóság eszközökkel való munka egységesítését, a klasszikus 3D sisakoktól kezdve a mobil megoldásokig.
• A WebSockets támogatása az HTTP/2 tetején (RFC 8441) került megvalósításra, amely csak a WebSockets-re irányuló védett kérések esetén működik és akkor, ha már van létrehozott HTTP/2 kapcsolat a szerverrel, amelyben bejelentették a „WebSockets over HTTP/2” bővítmény támogatását.
• A performance.now() hívásával kibocsátott időmérő értékek pontosságának korlátozása egységesítve lett minden támogatott platform esetében, figyelembe véve a feldolgozók esetleges külön folyamatokba való elszigetelését. Például asztali rendszerek esetében a pontosság nem elszigetelt kontextusokban 5 mikroszekundumról 100 mikroszekundumra csökkent.
• Az asztali rendszerekhez készült összesítésekben megvalósították a fájlok vágólapból való olvasásának lehetőségét (a fájlok vágólapra írása továbbra is tilos). async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); }
• A CSS-ben megvalósították a @counter-style szabályt, amely lehetővé teszi saját számlálók és címkék stílusának definiálását számozott listákban.
• A CSS álnév-osztályaiba „:host()” és „:host-context()” lehetőséget kaptak az egyes értékek átadására összetett szelektorok (<compound-selector>) mellett, az összetett szelektorlisták (<compound-selector-list>) mellett.
• A GravitySensor interfészt hozzáadták a tömeges (három dimenzióban) adatokat mérő gravitációs érzékelővel kapcsolatban.
• A File System Access API-ban megvalósították a fájl- és mappanevek ajánlásainak meghatározásának lehetőségét a fájl létrehozására vagy megnyitására szolgáló párbeszédablakban.
• A más domainekből betöltött iframe-ek számára engedélyezték a WebOTP API-hoz való hozzáférést, ha a felhasználó megfelelő engedélyeket biztosít. A WebOTP lehetővé teszi az SMS-ben küldött egyszeri megerősítő kódok olvasását.
• Engedélyezett a hitelesítő adatok megosztása olyan webhelyek között, amelyeket a DAL (Digital Asset Links) mechanizmusa társít, lehetővé téve az Android-alkalmazások és webhelyek összekapcsolását a bejelentkezés egyszerűsítése érdekében.
• A Service worker-ben lehetővé vált a JavaScript modulok használata. A 'module' típus megadása a konstruktor hívása során lehetővé teszi, hogy a megadott szkriptek modulok formájában betöltődjenek, és importálhatók legyenek a worker kontextusában. A modulok támogatása megkönnyíti a kód közös használatát weboldalakon és Service worker-ekben.
• A JavaScript-ben lehetőség nyílt a zárt mezők létezésének ellenőrzésére egy objektumban a „#foo in obj” szintaxissal. class A { static test(obj) { console.log(#foo in obj); } #foo = 0; } A.test(new A()); // true A.test({}); // false
• A JavaScript-ben alapértelmezetten megengedett az await kulcsszó használata a modulok legfelső szintjén, ami lehetővé teszi az aszinkron hívások lágyabb integrálását a modulok betöltési folyamatába, és elkerülhető a «async function» csomagolása. Például, a (async function() { await Promise.resolve(console.log(‘test’)); }()); helyett most már írhatsz await Promise.resolve(console.log(‘test’));
• A V8 JavaScript motorban javították a sablonok gyorsítótárazásának hatékonyságát, ami 4,5%-kal növelte a Speedometer2-FlightJS teszt áthaladási sebességét.
• Jelentős fejlesztéseket hajtottak végre a webfejlesztők számára készült eszközökben. Új memóriainspektáló módot (Memory inspector) vezettek be, amely eszközöket biztosít az ArrayBuffer és a Wasm memória adatainak tanulmányozására.

  A Teljesítmény panelen egy összefoglaló teljesítménymérő mutatót adtak hozzá, amely lehetővé teszi a webhely optimalizálásának szükségességének megítélését.

  

  A képek előnézeténél az Elemen belüli és a hálózati kérdések elemző paneljén megjelenik az image képarány, a megjelenítési jellemzők és a fájlméret információja.

  

  A hálózati ellenőrző panelen lehetőség nyílt a Content-Encoding fejléc által fogadott értékek módosítására.

  

  A stílusokkal kapcsolatos panelen lehetőség nyílik a kiszámított érték gyors megtekintésére, ha a CSS paraméterek között navigálunk, és a helyi menüben a „View computed value” lehetőséget választjuk.

  

Az új verzióban új funkciókat vezettek be és hibákat javítottak, összesen 32 sebezhetőséget szüntettek meg. Számos sebezhetőséget az AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer és AFL automatizált tesztelő eszközökkel azonosítottak. Kritikus problémák, amelyek lehetővé tennék a böngésző összes védelmi szintjének megkerülését és a kód végrehajtását a rendszerben a sandbox környezeten kívül, nem kerültek azonosításra. A sebezhetőségek felfedezésére irányuló díjazási program keretében a Google a jelenlegi kiadásért 21 jutalmat összesen 92,000 USD értékben adott (egy díj 20,000 USD, egy díj 15,000 USD, négy díj 7,500 USD, három díj 5,000 USD, három díj 3,000 USD, két díj 1,000 USD és két díj 500 USD). Az 5 jutalom mértéke még nem került meghatározásra.

Forrás: opennet.ru