Google Chrome

[kmscom]

7 часов назад, Umnik сказал:

Прописал DoH на роутере

скриншотом покажите

7 часов назад, Umnik сказал:

Дополнительно прописал DoH на смартфоне

тоже скриншотом покажите

[ska79]

Буду премного благодарен если просветите как настроить doh на tp-link td-w8901n? )

[Friend]

111 Chrome-дополнений, загруженных 32 млн раз, уличены в загрузке конфиденциальных данных

Спойлер

Компания Awake Security сообщила о выявлении 111 дополнений к Google Chrome, отправляющих на внешние серверы конфиденциальные данные пользователя. В том числе дополнения имели доступ к созданию скриншотов, чтению содержимого буфера обмена, анализу наличия токенов доступа в Cookie и перехвату ввода в web-формах. В сумме выявленные вредоносные дополнения насчитывали 32.9 млн загрузок в Chrome Web Store, а самое популярное (Sеarch Manager), a было загружено 10 млн раз и включает 22 тысячи отзывов.

Предполагается, что все рассмотренные дополнения подготовлены одной командой злоумышленников, так как во всех использовалась типовая схема распространения и организации захвата конфиденциальных данных, а также встречаются общие элементы дизайна и повторяющийся код. 79 дополнений с вредоносным кодом были размещены в каталоге Chrome Store и уже удалены после отправки уведомления о вредоносной активности. Многие вредоносные дополнения копировали функциональность различных популярных дополнений, в том числе нацеленных на обеспечение дополнительной защиты браузера, повышение конфиденциальности при поиске, преобразования PDF и конвертации форматов.

Разработчики дополнений вначале размещали в Chrome Store чистую версию без вредоносного кода, проходили рецензирование, а потом в одном из обновлений добавляли изменения, которые подгружали вредоносный код после установки. Для скрытия следов вредоносной активности также применялась техника выборочных ответов - при первом запросе выдавалась вредоносная загрузка, а при последующих не вызывающие подозрения данные.

В качестве основных путей распространения вредоносных дополнений выделяется продвижение профессионально выглядящих сайтов (как на картинке ниже) и размещение в Chrome Web Store, обходя механизмы проверки для последующей загрузки кода с внешних сайтов. Для обхода ограничений по установке дополнений только из Chrome Web Store атакующими распространялись отдельные сборки Chromium с предустановленными дополнениями, а также производилась установка через уже присутствующие в системе рекламные приложения (Adware). Исследователи проанализировали 100 сетей финансовых, медийных, медицинских, фармацевтических, нефтегазовых и торговых компаний, а также образовательных и госучреждений, и почти во всех из них выявили следы наличия рассматриваемых вредоносных дополнений.

В ходе кампании по распространению вредоносных дополнений было зарегистрировано более 15 тысяч доменов, пересекающихся с популярными сайтами (например, gmaille.com, youtubeunblocked.net и т.п.) или зарегистрированными после окончания срока продления ранее существующих доменов. Данные домены также использовались в инфраструктуре управления вредоносной активностью и для загрузки вредоносных JavaScript-вставок, выполняемых в контексте открываемых пользователем страниц.

Исследователи заподозрили сговор с регистратором доменов Galcomm, в котором были зарегистрированы 15 тысяч доменов для вредоносных действий (60% от всех выданных данным регистратором доменов), но представители Galcomm опровергли эти предположения и указали, что 25% из перечисленных доменов уже удалены или выданы не Galcomm, а остальные почти все являются неактивными припаркованными доменами. Представители Galcomm также сообщили, что до публичного раскрытия отчёта к ним никто не обращался, и они получили список доменов, применяемых для вредоносных целей, от третьего лица и теперь проводят по ним свой разбор.

Выявившие проблему исследователи сравнивают вредоносные дополнения с новым руткитом - основная деятельность многих пользователей ведётся через браузер, через который осуществляется доступ к совместным хранилищам документов, корпоративным информационным системам и финансовым сервисам. Злоумышленникам в таких условиях нет смысла искать пути полной компрометации операционной системы для установки полноценного руткита, - гораздо проще добиться установки вредоносного браузерного дополнения и контролировать через него потоки конфиденциальных данных. Кроме контроля за транзитными данными дополнение может запросить полномочия для доступа к локальным данным, web-камере, местоположению. Как показывает практика, большинство пользователей не обращают внимание на запрашиваемые полномочия, а 80% из 1000 популярных дополнений запрашивают доступ к данным всех обрабатываемых страниц.

 

[Umnik]

On 19.06.2020 at 18:33, kmscom said:

скриншотом покажите

 

Spoiler

 

Здесь указаны и обычные DNS, но они игнорируются. Роутер игнорирует не защищённые DNS, если есть DoH или DoT. При наличии обоих вместе (H и T) будет выбираться то, что быстрее. Но т.к. DoT может быть заблокирован, т.к. использует специфичный порт, я деинсталлировал этот модуль из роутера, оставив только DoH, который для провайдера не отличается от любого другого HTTPS запроса.

Выбрать желаемый сервер можно здесь: https://github.com/curl/curl/wiki/DNS-over-HTTPS

У меня добавлено 2 клаудфлаера — один обычный и один для TOR и Гугловый, если клаудфлаер решит прилечь вдруг.

 

On 19.06.2020 at 18:33, kmscom said:

тоже скриншотом покажите

 

Spoiler

 

Здесь у меня гугловый, потому что Гугл в Андроиде решил сломать совместимость с клаудфлаером.

Изменено 21 июня, 2020 пользователем Umnik

[Friend]

 Оценка влияния на производительность популярных дополнений к Chrome

Спойлер

Опубликованы результаты исследования влияния на производительность браузера тысячи наиболее популярных дополнений к Chrome. Показано, что некоторые дополнения могут достаточно сильно влиять на производительность и создавать большую нагрузку на систему, а также в разы увеличивать потребление памяти. При тестировании оценивалось создание нагрузки на CPU в активном и фоновом режимах, потребление памяти и влияние на скорость отображения открываемых страниц. Результаты представлены в двух выборках, охватывающих 100 и 1000 самых популярных дополнений.

Из 100 самых популярных дополнений наиболее сильно нагружающими CPU признаны дополнения "Evernote Web Clipper" (4 млн пользователей) и "Grammarly" (10 млн пользователей), которые приводят к трате дополнительных 500 мс процессорного времени при открытии каждой страницы (для сравнения открытие тестового сайта без дополнений расходует 40 мс). В общем виде 20 дополнений потребляют больше 100 мс, а 80 меньше 100 мс. Из неожиданных открытый стало относительно большое потребление ресурсов дополнением Ghostery, съедающим 120 мс времени CPU. Менеджер паролей LastPass съедал 241 мс, а Skype - 191 мс. Указанные ресурсы не приводят к остановке отрисовки, но блокируют начало взаимодействия со страницей и влияют на потребление энергии устройством.

При выборке из 1000 дополнений встречаются дополнения, создающие существенно более ощутимую нагрузку:

В тесте на задержку отрисовки страницы дополнения Clever, Grammarly, Cash Back for Shoping, LastPass и AVG замедляли открытие на 150-300 мс, в некоторых случаях внося задержки сопоставимые с отрисовкой самой страницы. В целом ситуация нормальная, так как из 100 дополнений только 6 приводят к задержке более 100 мс.

Результаты выборки из 1000 дополнений:

При оценке нагрузки на CPU, создаваемой при выполнении дополнением фоновых операций, проявило себя дополнение Avira Browser Safety, которое потратило почти 3 секунды времени CPU, в то время как затраты других дополнений не превышали 200 мс. Так как фоновый режим обычно используется для обработки сетевых запросов, выполняемых в процессе открытия страницы, тест был повторён на сайте apple.com, который делает 50 запросов вместо одного. Результаты изменились и в лидеры по созданию нагрузки выбился Ghostery, а Avira Browser Safety сместился на 9 место (разбор показал, что нагрузка снизилась из-за присутствия сайта apple.com в белом списке).

Результаты тестов 1000 дополнений:

• В тесте на потребление памяти первое место заняло дополнение Avira Browser Safet, потребление памяти которым составило 218 МБ (из-за обработки более 30 тысяч регулярных выражений, хранимых в памяти). На втором и третьем местах оказались Adblock Plus и Adblock, потребляющие чуть меньше 200 МБ. Замыкает 20 худших по потреблению памяти - uBlock Origin, съедающий менее 100 МБ (при сравнении с другими блокировщиками рекламы, у uBlock Origin одно из самых низких потребления памяти, см. ниже сравнение блокировщиков).

  20 худших показателей при тестовании 1000 дополнений:

  

  Так как часто пользователь списывает низкую производительность и возникающие задержки на браузер, а не на установленные дополнений, компания Google начала эксперименты с информированием о проблемных дополнениях. В стабильном выпуске Chrome 83 появилась настройка "chrome://flags/#extension-checkup", включающая вывод информационных сообщений о возможном влиянии дополнений на конфиденциальность и производительность. При включении опции на странице новой вкладки и в менеджере дополнений начинает показываться предупреждение о том, что дополнения могут привести к потреблению значительных ресурсов или получить доступ к персональным данным и активности пользователя.
  
   

  Отдельно проведено сравнение дополнений для блокировки рекламы и обеспечения конфиденциальности, в контексте экономии ресурсов за счёт блокирования внешних скриптов и рекламных вставок. Все дополнения обеспечили снижение нагрузки как минимум в три раза при обработке тестовой статьи из одного из новостных сайтов. Лидером стало дополнение DuckDuckGo Privacy Essentials, при использовании которого нагрузка при открытии тестовой страницы снизилась с 31 сек до 1.6 сек времени СPU за счёт снижения числа сетевых запросов на 95% и размера загружаемых данных на 80%. Близкий результат показал uBlock Origin.

  

  DuckDuckGo Privacy Essentials и uBlock Origin также оказались лучшими при оценке потребления ресурсов при выполнении фоновых операций.

  

  При тестировании потребления памяти, DuckDuckGo Privacy Essentials и uBlock Origin позволили снизить расход памяти с 536 MB при полной обработке тестовой страницы до ~140 MB.

  

  Аналогичное тестирование проведено для дополнений для web-разработчиков. Нагрузка на CPU:

  

  Нагрузка на CPU при выполнении фоновых операций

  

  Задержки отрисовки:

  

  Потребление памяти:

  

 

[Friend]

@Umnik у меня почему то нет DNS-over-HTTPS в настройках роутера:

Спойлер

 

[Umnik]

http://192.168.1.1/controlPanel/system/components → включить галку и ребутнуться

 

Screenshot_20200625_110240.webp

Изменено 25 июня, 2020 пользователем Umnik

[PitBuLL]

Версия 83.0.4103.116 (Официальная сборка), (64 бит).

Сверху, справа напротив адресной строки теперь "красуется" шлепок (значок) Расширения. Убрать можно это? В настройках не нашел.

[Friend]

В Chrome предложен новый интерфейс PDF-просмотрщика и добавлена поддержка AVIF

Спойлер

В состав Chrome включена новая реализация интерфейса встроенного просмотрщика документов в формате PDF. Интерфейс примечателен выносом в верхнюю панель всех настроек. Если раньше в верхней панели отображались только название файла, информация о страницах, кнопки поворота, печати и сохранения, то теперь в неё перенесено и содержимое боковой панели, включавшей элементы управления масштабированием и размещения документа по размеру страницы. Добавлена возможность сохранения отредактированных PDF-форм, а также режим двухстраничного просмотра. Для включения новых возможностей предложены флаги "chrome://flags#pdf-viewer-update", "chrome://flags/#pdf-form-save" и "chrome://flags/#pdf-two-up-view".

Из изменений в Chrome также можно отметить включение по умолчанию поддержки формата изображений AVIF (AV1 Image Format), в котором задействованы технологии внутрикадрового сжатия из формата кодирования видео AV1. Контейнер для распространения сжатых данных в AVIF полностью аналогичен HEIF. AVIF поддерживает как изображения в HDR (High Dynamic Range) и цветовом пространстве Wide-gamut, так и в стандартном динамическом диапазоне (SDR). В Firefox экспериментальная поддержка AVIF добавлена в выпуске Firefox 77 (включается через image.avif.enabled в about:config).

Ранее в Chrome продвигался формат изображений WebP, который по тестам Google позволяет сократить размер файлов с изображениями на 25%-34% при сохранении качества на уровне формата JPEG. Альтернативные тесты показывают, что WebP не так эффективен как хотелось бы - если сравнивать его не с эталонным кодировщиком cjpeg от JPEG Group, а используя более эффективный кодировщик MozJPEG, то выигрыш WebP ощущается только для низких разрешений (500px), наиболее часто используемых в Web. При разрешении 1000px результат почти одинаков, а при разрешении 1500px WebP даже отстаёт от MozJPEG. AVIF в тех же тестах заметно обгоняет MozJPEG, cjpeg и WebP, поэтому рассматривается производителями браузеров как более перспективный формат.

 

[Mark D. Pearlstone]

25.06.2020 в 13:13, PitBuLL сказал:

Версия 83.0.4103.116 (Официальная сборка), (64 бит).

Сверху, справа напротив адресной строки теперь "красуется" шлепок (значок) Расширения. Убрать можно это? В настройках не нашел.

chrome://flags/#extensions-toolbar-menu

Disabled

Перезапустить браузер.

[Friend]

 Chrome, Firefox и Safari ограничат время жизни TLS-сертификатов 13 месяцами

Спойлер

Разработчики проекта Chromium внесли изменение, прекращающее доверие к TLS-сертификатам, время жизни которых превышает 398 дней (13 месяцев). Компании Apple и Mozilla ранее приняли решение ввести аналогичное ограничение в Safari и Firefox. Ограничение будет действовать только для сертификатов, выписанных начиная с 1 сентября 2020 года. Для полученных до 1 сентября сертификатов с длительным сроком действия доверие будет сохранено, но ограничено 825 днями (2.2 года). Попытка открытия в браузере сайта с сертификатом, не соответствующим упомянутым критериям, будет приводить к отображению ошибки "ERR_CERT_VALIDITY_TOO_LONG".

В прошлом и позапрошлом годах изменение было выставлено на голосование участниками ассоциации CA/Browser Forum, которая используется как площадка для согласования совместных решений производителями браузеров и удостоверяющими центрами. Ранее производителям браузеров удалось отстоять сокращение времени жизни сертификатов вначале до 8, затем до 5, а потом и до 3 лет. В 2018 году была предпринята попытка сокращения действия до года, но, в конечном счёте, было утверждено компромиссное решение и срок был ограничен двумя годами. В прошлом году попытка повторилась, но решение по ограничению срока действия сертификатов до одного года не было утверждено из-за несогласия большинства удостоверяющих центров. В феврале 2020 года компания Apple решила ввести ограничения без согласования в CA/Browser Forum, в марте к инициативе присоединилась компания Mozilla, а теперь и Google.

Изменение может негативно отразиться на бизнесе удостоверяющих центров, продающих дешёвые сертификаты с длительным сроком действия, доходящим до 5 лет. По мнению производителей браузеров генерация подобных сертификатов создаёт дополнительные угрозы безопасности, мешает оперативному внедрению новых криптостандартов и позволяет злоумышленникам длительное время контролировать трафик жертвы или использовать для фишинга в случае незаметной утечки сертификата в результате взлома.

 

[Friend]

Релиз Chrome 84

Спойлер

Компания Google представила релиз web-браузера Chrome 84. Одновременно доступен стабильный выпуск свободного проекта Chromium, выступающего основой Chrome. Браузер Chrome отличается использованием логотипов Google, наличием системы отправки уведомлений в случае краха, возможностью загрузки модуля Flash по запросу, модулями для воспроизведения защищённого видеоконтента (DRM), системой автоматической установки обновлений и передачей при поиске RLZ-параметров. Следующий выпуск Chrome 85 запланирован на 25 августа.

 

Основные изменения в Chrome 84:

• Отключена поддержка протоколов TLS 1.0 и TLS 1.1. Для обращения к сайтам по защищённому каналу связи сервер должен предоставить поддержку как минимум TLS 1.2, иначе браузер теперь будет выводить ошибку. По данным Google в настоящее время около 0.5% загрузок web-страниц продолжает осуществляться с использованием устаревших версий TLS. Отключение произведено в соответствии с рекомендациями IETF (Internet Engineering Task Force). Причиной отказа от TLS 1.0/1.1 является отсутствие поддержки современных шифров (например ECDHE и AEAD) и требование поддержки старых шифров, надёжность которых на современном этапе развития вычислительной техники поставлена под сомнение (например, требуется поддержка TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, для проверки целостности и аутентификации используется MD5 и SHA-1). Настройка, дающая возможность вернуть TLS 1.0/1.1 будет сохранена до января 2021 года.
• Обеспечено блокирование небезопасной загрузки (без шифрования) исполняемых файлов и добавлен вывод предупреждений при небезопасной загрузке архивов. В дальнейшем постепенно планируется полностью прекратить поддержку загрузки файлов без применения шифрования. Блокировка реализована, так как загрузка файлов без шифрования может использоваться для совершения вредоносных действий путём подмены содержимого в процессе MITM-атак.
• Добавлена начальная поддержка идентификатора Client Hints, развиваемого в качестве альтернативы заголовка User-Agent. Механизм Client Hints предлагает в качестве замены User-Agent серию заголовков "Sec-CH-UA-*", позволяющих организовать выборочную отдачу данных о конкретных параметрах браузера и системы (версия, платформа и т.д.) только после запроса сервером. Пользователь получает возможность определить какие параметры допустимы для отдачи и выборочно предоставлять подобную информацию владельцам сайтов. При использовании Client Hints идентификатор не передаётся по умолчанию без явного запроса, что делает невозможным проведение пассивной идентификации (по умолчанию указывается только название браузера). Работа по унификации User-Agent отложена до следующего года.
• Продолжена активация более жёсткого ограничения передачи Cookie между сайтами, которая была отменена из-за COVID-19. Для не-HTTPS запросов запрещена обработка сторонних Cookie, выставляемых при обращении к сайтам, отличным от домена текущей страницы. Подобные Cookie применяются для отслеживания перемещений пользователя между сайтами в коде рекламных сетей, виджетов социальных сетей и систем web-аналитики.

  Напомним, что для управления передачей Cookie применяется указываемый в заголовке Set-Cookie атрибут SameSite, который по умолчанию будет выставлен в значение "SameSite=Lax", ограничивающее отправку Cookie для межсайтовых субзапросов, таких как запрос изображения или загрузка контента через iframe с другого сайта. Сайты могут переопределить применяемый по умолчанию режим SameSite, явно выставляя при установке Cookie значение SameSite=None. Притом значение SameSite=None для Cookie может выставляться только в режиме Secure (действует для соединений через HTTPS). Изменение будет применяться поэтапно, вначале для небольшого процента пользователей, а потом постепенно расширяя охват.

• Добавлена экспериментальная реализация блокировщика ресурсоёмкой рекламы, которую можно активировать при помощи настройки "chrome://flags/#enable-heavy-ad-intervention". Блокировщик позволяет автоматически отключать рекламные iframe-блоки после превышения пороговых значений трафика и нагрузки на CPU. Блокировка будет срабатывать если в основном потоке израсходовано более 60 секунд процессорного времени в сумме или 15 секунд в 30-секундном интервале (потребляет 50% ресурсов более 30 секунд), а также когда загружено более 4 Мб данных по сети.

  Блокировка будет срабатывать только если до момента превышения лимитов пользователь не взаимодействовал с рекламным блоком (например, не кликал на него), что с учётом ограничения на трафик позволит блокировать автовоспроизведение объёмных видеороликов в рекламе без явной активации воспроизведения пользователем. Предлагаемые меры избавят пользователей от рекламы с неэффективной реализацией кода или преднамеренной паразитной активностью (например, выполняющими майнинг). По статистике Google, подпадающая под критерии блокировки реклама составляет всего 0.30% от всех рекламных блоков, но при этом подобные рекламные вставки потребляют 28% ресурсов CPU и 27% трафика от всего объёма рекламы.

• Проведена работа по снижению потребления ресурсов CPU когда окно браузера не находится в поле видимости пользователя. Chrome теперь проверяет не перекрывается ли окно браузера другими окнами и исключает отрисовку пикселей в областях перекрытия. Включение новой функции будет производиться постепенно: выборочно для некоторых пользователей оптимизация будет включена в Chrome 84, а для остальных в Chrome 85.
• Включена по умолчанию защита от назойливых уведомлений, например, спама запросами на получение push-уведомлений. Так как подобные запросы прерывают работу пользователя и отвлекают внимание на действия в диалогах подтверждения, вместо отдельного диалога в адресной строке будет отображаться не требующая действий от пользователя информационная подсказка с предупреждением о блокировке запроса полномочий, которая автоматически сворачивается в индикатор с изображением зачёркнутого колокола. При клике на индикатор можно активировать или отклонить запрошенное полномочие в любой удобный момент.

   

  
• Обеспечено запоминание выбора пользователя при открытии обработчиков внешних протоколов - пользователь может выбрать "всегда разрешать для этого сайта" для определённого обработчика и браузер запомнит это решение в привязке к текущему сайту.
• Добавлена защита от изменения настроек пользователя без явного согласия. Если дополнение изменит предлагаемую по умолчанию поисковую систему или страницу, отображаемую для новой вкладки, браузер теперь выведет диалог с предложением подтвердить указанную операцию или отменить изменение.
• Продолжено внедрение защиты от загрузки смешанного мультимедийного контента (когда на HTTPS-странице загружаются ресурсы по протоколу http://). На страницах, открытых по HTTPS, теперь автоматически будут заменяться ссылки "http://" на "https://" в блоках, связанных с загрузкой изображений (ранее заменились скрипты и iframe, автозамена звуковых и видео ресурсов ожидается в следующем выпуске). Если изображение недоступно по https, то его загрузка блокируется (вручную можно отметить блокировку через меню, доступное через символ замка в адресной строке).
  
   
• Добавлена поддержка API Web OTP (развивался как SMS Receiver API), позволяющий организовать ввод на web-странице одноразового пароля, после получения SMS-сообщения с кодом подтверждения, доставленного на Android-смартфон пользователя, на котором запущен браузер. Подтверждение по SMS, например, может использоваться для проверки номера телефона, указанного пользователем при регистрации. Если раньше пользователь должен был открыть приложение для работы SMS, скопировать из него код в буфер обмена, вернуться в браузер и вставить этот код, то новый API даёт возможность автоматизировать данный процесс и свести его к одному касанию.
• Расширено API Web Animations для управления воспроизведением web-анимации. В новом выпуске добавлена поддержка операций композитинга, позволяющих контролировать как комбинируются эффекты и предоставляющих новые обработчики, вызываемые при наступлении событий замены содержимого. API Web Animations также теперь поддерживает Promise для определения последовательности показа анимации и лучшего управления тем, как анимация взаимодействует с другими возможностями приложения.
• В режиме Origin Trials (экспериментальные возможности, требующие отдельной активации) добавлено несколько новых API. Origin Trial подразумевает возможность работы с указанным API из приложений, загруженных с localhost или 127.0.0.1, или после прохождения регистрации и получения специального токена, который действует ограниченное время для конкретного сайта.
  • API Cookie Store для доступа Service worker к HTTP Cookies, выступающий асинхронной альтернативой применения document.cookie.
  • API Idle Detection для определения неактивности пользователя, позволяющий определять время, когда пользователь не взаимодействует с клавиатурой/мышью, запущен хранитель экрана, экран заблокирован или работа выполняется на другом мониторе. Информирование приложения об неактивности осуществляется через отправку уведомления после достижения заданного порога неактивности.
  • Режим Origin Isolation, позволяет разработчику использовать более полную изоляцию обработки контента в отдельном процессе в привязке к источнику (origin - домен+порт+протокол), а не сайту, ценой прекращения поддержки некоторых устаревших возможностей, таких как синхронное выполнение скриптов, использующих document.domain, и вызов postMessage() для отправки сообщений экземплярам WebAssembly.Module. Иными словами, Origin Isolation позволяет организовать разделение по разным процессам на основе домена ресурса, а не сайта со всеми посторонними включениями на страницах.
  • API WebAssembly SIMD для использования векторных SIMD-инструкций в приложениях в формате WebAssembly. Для обеспечения платформонезависимости предлагаются новый 128-разрядный тип, который может представлять разные типы упакованных данных, и несколько базовых векторных операций для обработки упакованных данных. SIMD позволяет повысить производительность за счёт распараллеливания обработки данных и будет полезным при компиляции нативного кода в WebAssembly.
• Стабилизирован и теперь распространяется вне Origin Trials API Content Indexing, предоставляющий метаданные о контенте, который ранее был прокэширован web-приложениями, работающими в режиме Progressive Web Apps (PWS). Приложение может сохранять на стороне браузера различные данные, включая изображения, видео и статьи, а при пропадании сетевого соединения использовать их при помощи API Cache Storage и IndexedDB. Content Indexing API даёт возможность добавлять, находить и удалять подобные ресурсы. В браузере данный API уже используется для перечисления списка страниц и мультимедийных данных, доступных для просмотра в offline.
• Стабилизирован вариант API Wake Lock на основе механизма Promise, предоставляющий более безопасный способ управления отключением автоблокировки экрана и перевода устройств в энергосберегающие режимы.
• В версии для платформы Android добавлена поддержка ярлыков приложений, позволяющих предоставить быстрый доступ к востребованным типовым действиям в приложении. Для создания ярлыков достаточно добавить элементы в манифест web-приложения в формате PWA (Progressive Web Apps).
• Для Web Worker разрешено использование API ReportingObserver, позволяющего определить обработчик для генерации отчёта, вызываемый при обращении к устаревшим возможностям. Сгенерированный отчёт по выбору пользователя может быть сохранён, отправлен на сервер или обработан скриптом на JavaScript.
• Обновлён API Resize Observer, позволяющий подключить обработчик, которому будут направляться уведомления об изменении размера указанных элементов на странице. В ResizeObserverEntry добавлено три новых свойства: contentBoxSize, borderBoxSize и devicePixelContentBoxSize для получения более детальной информации, выдаваемой в форме массива из объектов ResizeObserverSize.
• Добавлно ключевое слово "revert" для сброса стиля элемента в значение по умолчанию.
• Избавлены от префикса CSS-свойства "-webkit-appearance" и "-webkit-ruby-position", которые теперь доступны как "appearance" и "ruby-position".
• В JavaScript реализована поддержка пометки методов и свойств класса приватными, после чего доступ к ним будет открыт только внутри класса (ранее приватными могли быть только поля). Для пометки методов и свойств приватным следует указать перед именем поля знак "#".
• В JavaScript добавлена поддержка слабых ссылок (weak reference) на объекты JavaScript, позволяющих сохранить ссылку на объект, но не блокирующих удаление связанного объекта сборщиком мусора. Также добавлена поддержка финализаторов, дающих возможность определения обработчика, вызываемого после выполнения сборки мусора указанного обекта.

Кроме нововведений и исправления ошибок в новой версии устранено 38 уязвимостей. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Одна проблема (CVE-2020-6510, переполнение буфера в обработчике фоновых операций fetch) помечена как критическая, т.е. позволяет обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения. В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google выплатила 26 премий на сумму 21500 долларов США (две премии $5000, две премии $3000, одна премия $2000, две премии $1000 и три премии $500). Размер 16 вознаграждений пока не определён.

 

Изменено 15 июля, 2020 пользователем Friend

[Friend]

В Chrome экспериментируют с прекращением автозаполнения форм, отправляемых без шифрования

Спойлер

В кодовую базу, используемую для формирования выпуска Chrome 86, добавлена настройка "chrome://flags#mixed-forms-disable-autofill", отключающая автозаполнение форм ввода на страницах, загруженных по HTTPS, но отправляющих данные по HTTP. Автозаполнение форм аутентификации на страницах, открываемых по HTTP, отключено в Chrome и Firefox уже достаточно давно, но до сих пор признаком для отключения служило открытие страницы с формой по HTTPS или HTTP, теперь также будет учитываться применение шифрования при отправке данных обработчику формы. Кроме того, в Chrome добавлено новое предупреждение, информирующее пользователя об отправке заполненных данных через незашифрованный канал связи.

 

[Peter15]

Можно ли раз и навсегда запретить принимать уведомления от сайтов при нахождении в сессии своего аккаунта? После переустановки хрома приходят снова. 

[Mark D. Pearlstone]

20 часов назад, Peter15 сказал:

После переустановки хрома приходят снова. 

Настройки уведомлений хранятся в профиле на устройстве. Поэтому после переустановки нужно заново настраивать.