Chrome 79. kiadás

Google bemutatott webböngésző kiadás Chrome 79... Egyidejűleg elérhető ingyenes projekt stabil kiadása Króm, amely a Chrome alapja. Chrome böngésző különböző a Google logók használata, az összeomlás esetén értesítést küldő rendszer megléte, a Flash modul igény szerinti letöltése, a védett videotartalom (DRM) lejátszására szolgáló modulok, az automatikus frissítési rendszer és a keresési átvitel RLZ paraméterek. A Chrome 80 következő kiadása február 4-én jelenik meg.

A főbb változások в króm 79:

• aktív Jelszóellenőrző komponens, amely a felhasználó által használt jelszavak erősségének elemzésére szolgál. Amikor megpróbál bejelentkezni bármely webhelyre Jelszóellenőrzés teljesíti a bejelentkezési név és a jelszó ellenőrzése a feltört fiókok adatbázisában, figyelmeztetéssel, ha problémákat észlel (az ellenőrzés a felhasználó oldalán található hash előtag alapján történik). Az ellenőrzést egy több mint 4 milliárd feltört fiókot lefedő adatbázison hajtják végre, amelyek kiszivárgott felhasználói adatbázisokban jelentek meg. Figyelmeztetés akkor is megjelenik, ha triviális jelszavakat próbál használni, például "abc123". A Jelszóellenőrzés felvételének szabályozására egy speciális beállítást alkalmaztunk a „Szinkronizálás és Google szolgáltatások” részben.
• Bemutatnak egy új technológiát az adathalászat valós idejű észlelésére. Korábban az ellenőrzést a Biztonságos Böngészés helyileg letöltött feketelistáihoz való hozzáféréssel végezték, amelyek körülbelül 30 percenként frissültek, ami például a támadók gyakori tartományváltása esetén nem bizonyult elegendőnek. Az új módszer lehetővé teszi az URL-ek menet közbeni ellenőrzését az engedélyezési listákon való előzetes ellenőrzéssel, amelyek több ezer megbízható webhely hash-ét tartalmazzák. Ha a megnyitott webhely nem szerepel a fehér listán, a böngésző ellenőrzi az URL-t a Google szerverén, továbbítva a link SHA-32 hash-jének első 256 bitjét, amelyből az esetleges személyes adatokat kivágják. A Google szerint az új megközelítés 30%-kal javíthatja az új adathalász oldalak figyelmeztetésének hatékonyságát.
• Hozzáadott proaktív védelem a Google hitelesítő adatok és a jelszókezelőben tárolt jelszavak adathalász oldalakon keresztüli átvitele ellen. Ha olyan webhelyen próbál meg mentett jelszót megadni, ahol ezt a jelszót általában nem használják, a felhasználó figyelmeztetést kap egy potenciálisan veszélyes műveletre.
• A TLS 1.0-t és 1.1-et használó kapcsolatok most a nem biztonságos kapcsolat jelzőjét mutatják. Teljes mértékben támogatja a TLS 1.0-t és 1.1-et letiltásra kerül Chrome 81-ben, 17. március 2020-én.
• Hozzáadtuk az inaktív lapok lefagyasztásának lehetőségét, lehetővé téve az olyan memórialapok automatikus eltávolítását, amelyek több mint 5 perce a háttérben vannak, és nem hajtanak végre jelentős műveleteket. Egy adott lap fagyasztásra való alkalmasságáról a heurisztika alapján kell dönteni. A funkció engedélyezését a „chrome://flags/#proactive-tab-freeze” jelző vezérli.
• biztosított Vegyes tartalom blokkolása a HTTPS-en keresztül megnyitott oldalakon annak biztosítása érdekében, hogy a https:// felett megnyitott oldalak csak biztonságos kommunikációs csatornán keresztül betöltött erőforrásokat tartalmazzanak. Annak ellenére, hogy a vegyes tartalmak legveszélyesebb típusai, például a szkriptek és az iframe-ek már alapértelmezés szerint le vannak tiltva, a képek, hangfájlok és videók továbbra is letölthetők a http:// oldalról. Az ilyen betétekhez korábban használt vegyes tartalom jelző hatástalannak és a felhasználó számára félrevezetőnek bizonyult, mivel nem ad egyértelmű értékelést az oldal biztonságáról. Például a képhamisítás révén a támadó helyettesítheti a felhasználókövető cookie-kat, megpróbálhatja kihasználni a képfeldolgozók biztonsági réseit, vagy hamisítást követhet el a képen található információk cseréjével. A kevert komponensek zárolásának letiltására egy speciális beállítás került be, amely a lakat szimbólumra kattintva megjelenő menün keresztül hívható elő.
• Kísérleti lehetőség hozzáadva a vágólap tartalmának megosztásához a Chrome asztali és mobil verziói között. Ha a Chrome egy fiókhoz van kapcsolva, mostantól hozzáférhet egy másik eszköz vágólapjának tartalmához, beleértve a vágólap megosztását a mobil és az asztali rendszerek között. A vágólap tartalma végpontok közötti titkosítással van titkosítva, amely megakadályozza a szöveghez való hozzáférést a Google szerverein. A funkció a chrome://flags#shared-clipboard-receiver, chrome://flags#shared-clipboard-ui és chrome://flags#sync-clipboard-service opciókkal engedélyezhető.
• A címsorban bizonyos pillanatokban (például jelszó mentésekor), amikor a profilszinkronizálás ki van kapcsolva, az avatar mellett az aktuális Google-fiók neve is megjelenik, így a felhasználó pontosan tudja azonosítani az aktuális aktív fiókot.
• A felhasználók 1%-ánál aktiválva támogatás „DNS HTTPS-en keresztül” (DoH, DNS HTTPS-en keresztül). A kísérletben csak olyan felhasználók vesznek részt, akiknek a rendszerbeállításai már megadták a DoH-t támogató DNS-szolgáltatókat. Például, ha a felhasználó DNS 8.8.8.8-val rendelkezik a rendszerbeállításokban, akkor a Google DoH szolgáltatása („https://dns.google.com/dns-query”) aktiválódik a Chrome-ban; ha a DNS 1.1.1.1. XNUMX, majd a DoH Cloudflare szolgáltatás („https://cloudflare-dns.com/dns-query”) stb. A „chrome://flags/#dns-over-https” beállítással szabályozható, hogy a DoH engedélyezve van-e. Három üzemmód támogatott: biztonságos, automatikus és kikapcsolt. „Biztonságos” módban a gazdagépek meghatározása csak a korábban gyorsítótárazott (biztonságos kapcsolaton keresztül kapott) biztonságos értékek és a DoH-n keresztüli kérések alapján történik; a rendszer nem alkalmazza a normál DNS-re való visszaállást. „Automatikus” módban, ha a DoH és a biztonságos gyorsítótár nem érhető el, az adatok lekérhetők a nem biztonságos gyorsítótárból, és a hagyományos DNS-en keresztül érhetők el. Kikapcsolt módban először a megosztott gyorsítótárat ellenőrzik, és ha nincs adat, akkor a rendszer DNS-en keresztül küldi el a kérést.
• Kísérleti hozzáadva támogatás a megjelenített tartalom gyorsítótárazása oldalváltáskor az előre és vissza gombok használatával, ami jelentősen csökkentheti az ilyen típusú navigáció során jelentkező késéseket a teljes oldal teljes gyorsítótárazása miatt, ami nem igényli az erőforrások újramegjelenítését és betöltését. Az optimalizálás különösen észrevehető a mobileszközökre szánt verzióban, ahol a teljesítménynövekedés navigáció közben eléri a 19%-ot. A mód a „chrome://flags#back-forward-cache” opcióval engedélyezhető.
• Törölve a „chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains” beállítás, amely lehetővé tette a protokoll megjelenítését a címsorban (most minden hivatkozás mindig látható https:// és http:/ / nélkül, valamint „www.” nélkül is).
• A Windowshoz készült buildek tartalmazzák a hanglejátszási szolgáltatás sandbox-kezelését. Az elkülönítés engedélyezésének szabályozásához az AudioSandboxEnabled tulajdonság javasolt.
• A központi adminisztrációs eszközök a vállalatok számára tartalmazzák a szabályok meghatározásának lehetőségét, amelyek szabályozzák, hogy egy böngészőpéldány mennyi memóriát fogyaszthat a háttérben lévő lapok eltávolítása előtt. A lap kirakodása után felszabaduló memória használhatóvá válik, és a lap tartalma a ráváltáskor újra betöltődik.
• A Linux beépített tanúsítvány-ellenőrző processzort használ, amely felváltja a korábban használt NSS rendszert. Ebben az esetben a beépített processzor továbbra is az NSS tárolót használja az ellenőrzés során, de szigorúbb követelményeket támaszt a hibásan kódolt és külön hitelesített tanúsítványok feldolgozásakor (minden tanúsítványt hitelesítő hatóságnak kell hitelesítenie).
• Az Android platformra készült verzióban tette hozzá adaptív ikonok hozzárendelésének képessége a progresszív webalkalmazások (PWA) módban futó telepített webalkalmazásokhoz. Az adaptív ikonok alkalmazkodhatnak az eszköz gyártója által használt felülethez, például kerekek, szögletesek vagy sima sarkúak.
• Hozzáadva API WebXR eszköz, amely hozzáférést biztosít a virtuális és kiterjesztett valóság létrehozásához szükséges komponensekhez. Az API lehetővé teszi a különböző típusú eszközökkel végzett munka egységesítését, az olyan helyhez kötött virtuális valóság fejhallgatóktól, mint az Oculus Rift, a HTC Vive és a Windows Mixed Reality, a mobileszközökön alapuló megoldásokig, mint például a Google Daydream View és a Samsung Gear VR. Azok az alkalmazások, amelyekben az új API alkalmazható, többek között 360°-os videómegtekintési programok, háromdimenziós tér megjelenítésére szolgáló rendszerek, videobemutatókhoz virtuális mozik létrehozása, üzletek és galériák 3D-s interfészek létrehozásával kapcsolatos kísérletek elvégzése;
  

• Eredeti próbaverzió módban (kísérleti funkciók, amelyekhez külön szükséges aktiválás) számos új API-t javasoltak. Az Origin Trial magában foglalja a megadott API-val való együttműködés lehetőségét a localhostról vagy a 127.0.0.1-ről letöltött alkalmazásokból, vagy a regisztráció és egy speciális token fogadása után, amely korlátozott ideig érvényes egy adott webhelyen.
  • Minden HTML-elemhez a „rendersubtree” attribútum javasolt, amely biztosítja, hogy a DOM-elem megjelenítése rögzített legyen. Ha az attribútumot "láthatatlan" értékre állítja, akkor az elem tartalmát nem lehet renderelni vagy ellenőrizni, ami lehetővé teszi az optimalizált megjelenítést. "Aktiválható" beállítás esetén a böngésző eltávolítja a láthatatlan attribútumot, megjeleníti és láthatóvá teszi a tartalmat.
  • API opció hozzáadva Ébresztő zár a Promise mechanizmuson alapul, amely biztonságosabb módot nyújt az automatikus zárolási képernyők letiltásának és az eszközök energiatakarékos módba kapcsolásának szabályozására.
• Megvalósította az attribútum használatának képességét autofókuszos minden HTML és SVG elemhez, amely bemeneti fókuszt tartalmazhat.
• Képekhez és videókhoz biztosított Számítsa ki a képarányt a Width vagy Height attribútumok alapján, amelyek segítségével meghatározhatja a kép méretét CSS segítségével abban a szakaszban, amikor a kép még nincs betöltve (megoldja az oldal újraépítésének problémáját a képek betöltése után).
• CSS tulajdonság hozzáadva betűtípus-optikai méretezés, amely automatikusan beállítja a változó betűméretet optikai koordinátákban "opsz", ha a betűtípus támogatja őket. A mód lehetővé teszi az optimális karakterjel-alak kiválasztását egy adott mérethez, például kontrasztosabb karakterjeleket használjon a címsorokhoz.
• CSS tulajdonság hozzáadva lista-stílusú, amely lehetővé teszi a pontok helyett tetszőleges szimbólumok használatát a listákban, például „-”, „+”, „★” és „▸”.
• Ha a Worklet.addModule() végrehajtása nem lehetséges, akkor a hiba természetére vonatkozó részletes információkkal egy objektum jelenik meg, amely lehetővé teszi a hiba okának pontosabb felmérését (hálózati kapcsolati problémák, helytelen szintaxis stb. .).
• A elemek feldolgozása leállt, amikor áthelyezi őket a dokumentumok között. A dokumentumok közötti átvitel során a szkripthez kapcsolódó „hiba” és „betöltés” ​​események végrehajtása is le van tiltva.
• JavaScript motorban V8 végrehajtani Az objektumok mezőinek megjelenítésében bekövetkezett változások kezelésének optimalizálása, ami az AngularJS kód végrehajtását eredményezi a Speedometer tesztcsomagban 4%-kal gyorsabban.
  

• A V8 optimalizálja a beépített API-kban, például a Node.nodeType-ban és a Node.nodeName-ben definiált getterek feldolgozását is IC-kezelő hiányában (inline cache). A változás körülbelül 12%-kal csökkentette az IC-futási idő alatt a Backbone és a jQuery tesztek Speedometer csomagból történő futtatásakor.
  

• Az OSR (az úgynevezett on-stack csere) mechanizmus eredményeit gyorsítótárban tárolják, amely lecseréli az optimalizált kódot a függvény végrehajtása során (lehetővé teszi, hogy elkezdje használni az optimalizált kódot a hosszan futó függvényekhez anélkül, hogy megvárná azok újrafutását). Az OSR gyorsítótárazás lehetővé teszi az optimalizálási eredmények felhasználását a funkció újrafuttatása során, anélkül, hogy újraoptimalizálni kellene.
  Egyes teszteknél a változás 5-18%-kal növelte a csúcsteljesítményt.
  

• Változások a webfejlesztők eszközeiben:
  Megjelent hibakeresési mód a kérés blokkolásának vagy a cookie küldésének okainak meghatározásához.
  
  • A Cookie-listát tartalmazó blokkban egy adott sorra kattintva gyorsan megtekinthető a kiválasztott Cookie érték.
    

  • A prefers-color-séma és a prefers-reduced-motion médialekérdezések különböző beállításainak szimulálása hozzáadva (például az oldal viselkedésének tesztelése sötét rendszertémával vagy letiltott animációs effektusokkal).
    

  • A Lefedettség lap kialakítása korszerűsítésre került, lehetővé téve a használt és a nem használt kód értékelését. Hozzáadtuk az információk típus szerinti szűrésének lehetőségét (JavaScript, CSS). A kódhasználati információk a forrásszöveg megjelenítésekor is hozzáadódnak.
    

  • A hálózati tevékenység rögzítése után hozzáadtuk az adott hálózati erőforrás igénylésének okainak hibakeresését (megtekintheti az erőforrás betöltéséhez vezető JavaScript kódhívás nyomát).
    

  • A „Beállítások > Beállítások > Források > Alapértelmezett behúzás” beállítás hozzáadva a behúzás típusának meghatározásához (2/4/8 szóköz vagy tabulátor) a Konzol és a Források panelen megjelenő kódban.

Az új verzió az újítások és hibajavítások mellett 51 sebezhetőséget szünteti meg. A sebezhetőségek nagy részét az AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer és AFL eszközökkel végzett automatizált tesztelés eredményeként azonosították. Két probléma (CVE-2019-13725, a Bluetooth-támogatás kódjában már felszabadult memória elérése, valamint a CVE-2019-13726, kupac túlcsordulás a jelszókezelőben) kritikusként van megjelölve, pl. lehetővé teszi a böngészővédelem minden szintjének megkerülését és kód futtatását a rendszeren a sandbox környezeten kívül. Ez az első alkalom, hogy két kritikus problémát azonosítottak a Chrome ugyanazon fejlesztési ciklusán belül. Az első sérülékenységet a Tencent Keen Security Lab kutatói és igazolták a Tianfu Cup versenyen, a másodikat pedig Szergej Glazunov találta meg a Google Project Zero-tól.

A jelenlegi kiadás sebezhetőségeinek feltárásáért folyó pénzjutalom program részeként a Google 37 díjat fizetett ki 80000 20000 dollár értékben (egy 10000 7500 dolláros, egy 5000 3000 dolláros, két 2000 1000 dolláros, négy 500 15 dolláros, egy XNUMX XNUMX dolláros, XNUMX nyolc, XNUMX XNUMX dolláros díjat XNUMX dolláros díjak). A XNUMX jutalom nagyságát még nem határozták meg.

Forrás: opennet.ru