Кампанія Google апублікавала рэліз web-браўзэра Chrome 119. Адначасова даступны стабільны выпуск вольнага праекта Chromium, які выступае асновай Chrome. Браўзэр Chrome адрозніваецца ад Chromium выкарыстаннем лагатыпаў Google, наяўнасцю сістэмы адпраўкі апавяшчэнняў у выпадку краху, модулямі для прайгравання абароненага ад капіявання відэакантэнту (DRM), сістэмай аўтаматычнай усталёўкі абнаўленняў, сталым уключэннем Sandbox-ізаляцыі, пастаўкай ключоў да Google API і перадачай пры пошуку RL параметраў. Для тых, каму неабходна больш часу на абнаўленне, асобна падтрымліваецца галінка Extended Stable, якая суправаджаецца 8 тыдняў. Наступны выпуск Chrome 120 запланаваны на 5 снежня.
Асноўныя змены ў Chrome 119:
- Скарочаны цыкл фарміравання рэлізаў, у якім паменшаны час паміж стварэннем новай галінкі і пачаткам бэта-тэставанні - бэта-версія зараз фармуецца праз два дні пасля стварэння галінкі, а не праз 8 дзён. Стабілізацыя бэта-версіі па-ранейшаму ажыццяўляецца на працягу 4 тыдняў. Такім чынам, цыкл падрыхтоўкі новых выпускаў стаў на тыдзень меншы.
- Дадзена магчымасць захавання груп укладак. Карыстальнік зараз можа захаваць групу і зачыніць якія ўваходзяць у яе ўкладкі, каб яны не займалі рэсурсы. Пазней, калі ўзнікне неабходнасць укладкі з захаванай групы можна вярнуць, а таксама адкрыць на іншых прыладах, якія ўдзельнічаюць у сінхранізацыі ўкладак. Магчымасць уключана для часткі карыстальнікаў, для прымусовага ўключэння прадугледжана настройка "chrome://flags/#tab-groups-save".
- У інтэрфейсе зменены фармулёўкі аперацый і налад, злучаных з выдаленнем і стратай дадзеных. Замест тэрміна "ачыстка" (Clear) у падобных аперацыях зараз ужываецца слова "выдаленне" (Delete), бо слова "ачыстка" не ўспрымалася асобнымі карыстачамі як прыкмета беззваротнай страты дадзеных.
- Пры аўтадапаўненні URL зараз улічваецца любое ключавое слова, раней выкарыстанае для пошуку сайта, а не толькі словы супадаючыя з пачаткам адрасу. Напрыклад, аўтададатак адраса "https://www.google.com/travel/flights" спрацуе не толькі пры ўводзе слова "google", але і пры ўводзе "flights".

- Рэалізавана аўтаматычнае выпраўленне памылак друку пры ўводзе адрасу сайта і забяспечаны выснова рэлевантных падказак, пры фармаванні якіх улічваюцца сайты, раней адчыненыя бягучым карыстачом. Напрыклад, пры ўводзе "youutube" будзе прапанавана адкрыць YouTube.com.

- Прадастаўлена магчымасць пошуку ў раздзелах закладак праз адрасны радок. Напрыклад, можна дадаць пры ўводзе імя часткі закладак і Chrome прапануе спасылкі з дадзенай часткі, якія адпавядаюць уведзенаму ключавому слову. Напрыклад, пры ўводзе "паездкі 2023 Нью" будуць прапанаваны спасылкі з падзелу закладак "паездкі 2023", звязаныя з Нью-Ёркам.

- Рэалізаваны вывад рэкамендацый папулярных сайтаў, нават калі карыстач раней не наведваў іх ці дапусціў памылку пры ўводзе URL. Напрыклад, калі прытрымліваючыся чыёйсьці рэкамендацыі адкрыць Google Earth карыстач пачаў набіраць «googleear» не ведаючы дакладнага адраса, браўзэр прапануе перайсці на сайт earth.google.com.

- У Chrome для настольных сістэм палепшаная чытальнасць інфармацыі ў адрасным радку і падвышаная спагадлівасць інтэрфейсу — вынікі зараз выводзяцца адразу пасля пачатку набору ў адрасным радку.
- У адпаведнасці са зменай спецыфікацыі API Fetch, забяспечана выдаленне HTTP-загалоўка Authorization пры перанакіраванні на іншы дамен (cross origin).
- У наладах апавяшчэнняў і азначэнні месцазнаходжанні дададзеная опцыя для ўключэння сэрвісу аўтапрыгнечання запытаў на пацверджанне паўнамоцтваў (Permission Suggestions Service). На выбар прапанаваны рэжымы:
- заўсёды паказваць запыты на атрыманне паўнамоцтваў для вываду апавяшчэнняў і доступу да месцазнаходжання;
- аўтаматычна ігнараваць спамерскія запыты паўнамоцтваў, выкарыстоўваючы механізм Permission Suggestions Service;
- заўсёды ігнараваць усе запыты на вывад апавяшчэнняў;
- заўсёды блакаваць усе запыты на атрыманне паўнамоцтваў для вываду апавяшчэнняў і доступу да месцазнаходжання.
- У зборках для платформы Android пры ўключэнні стандартнай абароны браўзэра (Safe Browsing > Standard protection) у рэжыме рэальнага часу рэалізаваная праверка бяспекі адчыненых URL, выкананая на падставе перадачы на серверы Google частковых хэшаў ад адчыняных карыстачом URL. Для выключэння супастаўлення IP-адрасы карыстальніка і хэша, дадзеныя перадаюцца праз прамежкавы проксі. Раней праверка выконвалася праз загрузку на сістэму карыстальніка лакальнай копіі спіса небяспечных URL. Новая схема дазваляе больш аператыўнай блакаваць шкоднасныя URL. Для настольных сістэм такі рэжым быў уключаны ў мінулым выпуску.
- Экранаванне нелітарных знакаў у імя хаста пры выкліку функцыі URL прыведзена да адпаведнасці з абноўленай спецыфікацыяй. Напрыклад, выклік функцыі 'URL(«http://exa(mple.com;»)' раней вяртаў 'http://exa%28mple.com/', а зараз будзе прыводзіць да высновы памылкі » Invalid URL».

- Да ўсіх раней захаваных Cookie ужыта абмежаванне часу жыцця, аналагічнае таму, што ўжываецца пачынальна з выпуску Chrome 104 для новых і абноўленых Cookie. Для наяўных Cookie час жыцця будзе зрэзана да 400 дзён адносна публікацыі выпуску Chrome 119.
- У CSS прапанаваны новыя псеўда-класы ":user-valid" і ":user-invalid", якія прадстаўляюць элементы формаў, значэнні якіх прайшлі ці не прайшлі праверку. У адрозненне ад ":valid" і ":invalid" новыя псеўдакласы спрацоўваюць толькі пасля ўзаемадзеяння карыстальніка з элементам формай.
- Пры выстаўленні кветак у CSS дазволена вызначэнне значэнняў, вылічаных адносна іншых параметраў колеру. Напрыклад, пры ўказанні "oklab(from magenta calc(l * 0.8) ab)" будзе атрыманы колер на 80% святлей пурпурнога.
- У CSS-уласцівасць clip-path, якое дазваляе абмежаваць бачнасць элемента вызначанай вобласцю, дададзена падтрымка значэння для задання адвольнай вобласці для абразання. Таксама прадстаўлена магчымасць выкарыстання функцый xywh() і rect() для спрашчэння задання прастакутных або скругленых абласцей.
- Адключаная падтрымка API WebSQL, замест якога рэкамендуецца выкарыстоўваць API Web Storage і Indexed Database. Апрацоўшчык WebSQL заснаваны на кодзе бібліятэкі SQLite. API WebSQL не падтрымліваўся ў іншых браўзэрах, прывязваўся да API вонкавай бібліятэкі і падвышаў рызыкі праблем з бяспекай (WebSQL мог выкарыстоўвацца зламыснікамі для эксплуатацыі ўразлівасцяў у SQLite). Для вяртання падтрымкі WebSQL для карпаратыўных карыстачоў пакінутая палітыка WebSQLAccess, якая будзе выдалена ў Chrome 123.
- Часова выдалены API HTML Sanitizer, які дазваляе выразаць з змесціва элементы, якія ўплываюць на адлюстраванне і выкананне пры выснове праз метад setHTML(). API быў распрацаваны для выразання HTML-тэгаў, якія могуць выкарыстоўвацца для здзяйснення XSS-нападаў. У якасці прычыны выдалення называецца незавершанасць спецыфікацыі, якая з часу дадання Sanitizer у Сhrome значна змянілася. Пасля гатоўнасці спецыфікацыі API будзе вернуты.
- Выдалены нестандартны атрыбут shadowRoot, які дазваляе з уласных элементаў звяртацца да свайго асобнага кораня ў Shadow DOM, незалежна ад стану. Замест shadowRoot у Chrome 111 быў прапанаваны атрыбут shadowRootMode, які ўвайшоў у web-стандарт.
- Палепшана рэалізацыя HTML-элемента « », які нагадвае «iframe» і таксама дазваляе ўбудоўваць іншае змесціва на старонку. Адрозненні зводзяцца да абмежавання ўзаемадзеяння ўбудаванага змесціва са змесцівам старонкі на ўзроўні DOM і атрыбутаў. Напрыклад, старонка news.example, у якую пры дапамозе fencedframe убудаваны блок з рэкламай, які загружаецца з сайта shoes.example, не можа атрымаць доступ да дадзеных shoes.example, а ў сваю чаргу код з сайта shoes.example не можа атрымаць дадзеныя, звязаныя з news.example. У новай версіі дададзеная падтрымка якія з'явіліся ў API Protected Audience макрападстановак памеру рэкламнага блока, напрыклад, "https://ad.com?width={/%AD_WIDTH%}&height={/%AD_HEIGHT%}".
- У метад getDisplayMedia() дададзены параметр monitorTypeSurfaces, які можна выкарыстоўваць для забароны падавання сумеснага доступу да ўсяго экрана.
- У метад window.open() дададзены эксперыментальны (origin trial) параметр fullscreen, які дазваляе адкрыць акно адразу ў поўнаэкранным рэжыме.
- У API AudioEncoderConfig дададзены сцяг bitrateMode для выбару паміж сталым (constant) і зменным (variable) бітрэйтам.
- У TLS уключана рэалізацыя механізму інкапсуляцыі ключоў (KEM, Key Encapsulation Mechanism), якая выкарыстоўвае гібрыдны алгарытм X25519Kyber768, устойлівы да падбору на квантавых кампутарах. Для стварэння сесійных ключоў, якія ўжываюцца для шыфравання дадзеных усярэдзіне TLS-злучэнняў, зараз можа выкарыстоўвацца камбінацыя з механізму абмену ключамі X25519, заснаванага на эліптычных крывых і цяпер ужывальнага ў TLS, c алгарытмам Kyber-768, выкарыстоўвалым метады крыптаграфіі, заснаваныя на рашэнні задач тэорыі. , час рашэння якіх не адрозніваецца на звычайных і квантавых кампутарах.
- Уключаная па змаўчанні падтрымка пашырэння WasmGC, які спрашчае партаванне ў WebAssembly праграм, напісаных на мовах праграмавання, выкарыстоўвалых зборшчык смецця (Kotlin, PHP, Java і т.п.). WasmGC дадае новыя тыпы структур і масіваў, для якіх можа прымяняцца нелінейнае вылучэнне памяці.
- Унесены паляпшэнні ў інструменты для web-распрацоўшчыкаў. Дададзена магчымасць рэдагавання CSS-правілаў @property і высновы папярэджанняў пры іх некарэктным вызначэнні. Абноўлены спіс эмуляваных прылад (напрыклад, дададзеныя iPhone 14 і Pixel 7). У web-кансолі рэалізавана аўтадапаўненне прыватных палёў. Забяспечана фарматаванне дадзеных JSON, размешчаных усярэдзіне блокаў

Акрамя новаўвядзенняў і выпраўленні памылак у новай версіі ўхілена 15 уразлівасцяў. Многія з уразлівасцяў выяўлены ў выніку аўтаматызаванага тэсціравання інструментамі AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer і AFL. Крытычных праблем, якія дазваляюць абыйсці ўсе ўзроўні абароны браўзэра і выканаць код у сістэме за межамі sandbox-акружэнні, не выяўлена. У рамках праграмы па выплаце грашовай узнагароды за выяўленне ўразлівасцяў для бягучага рэлізу кампанія Google выплаціла 13 прэмій на суму 40.5 тысяч даляраў ЗША (па адной прэміі ў $16000, $11000, $2000 і $500, тры прэміі $3000 і дзве прэміі $1000). Памер 4 узнагароджанняў пакуль не вызначаны.
Крыніца: opennet.ru






