Google Chrome

[Friend]

Для Chrome предложен режим автоматической блокировки ресурсоёмкой рекламы :

 

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

Отмечается, что некоторые виды рекламы, из-за неэффективной реализации кода или преднамеренной паразитной активности, создают большую нагрузку на системы пользователя, замедляют загрузку основного контента, сокращают время автономной работы от аккумулятора и расходуют трафик на небезлимитных мобильных тарифах. Из типичных примеров рекламных блоков, подлежащих блокировке, упоминаются рекламные вставки с кодом для майнинга криптовалют, обработчиками больших несжатых изображений, декодировщиками видео на JavaScript или скриптами, интенсивно обрабатывающим события таймера (например для атак по сторонним каналам).

Код предлагается блокировать, если он израсходовал в основном потоке более 60 секунд процессорного времени в сумме или 15 секунд в 30-секундном интервале (потребляет 50% ресурсов более 30 секунд). Блокировка также будет срабатывать при загрузке рекламным блоком более 4 Мб данных по сети. Для исключения использования блокировки как признака для осуществления атак по сторонним каналам, по которым можно судить о мощности CPU, предлагается добавлять небольшие случайные флуктуации в пороговые значения и срабатывание блокировки.

Выгружаться и заменяться на предупреждение о блокировке будет только реклама, с которой не взаимодействовал пользователь. Определение связи iframe с рекламой производится эвристическим путём при помощи уже имеющегося механизма AdTagging. Пороговые значения подобраны для пропускания активности 99.9% проанализированных рекламных блоков. При этом прогнозируется, что предложенный механизм блокировки позволит уменьшить трафик от рекламных блоков на 12.8% и снизить нагрузку на CPU на 16.1%.

 

 

[Friend]

План прекращения поддержки TLS 1.0 и 1.1 в Chrome :

 

Как и в Firefox в Chrome планируют скоро прекратить поддержку протоколов TLS 1.0 и TLS 1.1, которые находятся в процессе перевода в разряд устаревших и не рекомендованных организацией IETF (Internet Engineering Task Force) для использования. Поддержка TLS 1.0 и 1.1 будет отключена в Chrome 81, намеченном на 17 марта 2020 года.

По данным Google в настоящее время около 0.5% загрузок web-страниц продолжается осуществляться с использованием устаревших версий TLS. До фактического прекращения поддержки начиная с выпуска Chrome 79, намеченного на 13 января, для соединений с использованием TLS 1.0 и 1.1 начнёт выводиться индикатор небезопасного соединения.

После блокировки в Chrome 81 для сеансов на базе TLS 1.0 и 1.1 начнёт выводиться ошибка.

 

 

[Friend]

Chrome начнёт блокировать HTTP-ресурсы на HTTPS-страницах и проверять надёжность паролей :

 

Компания Google предупредила об изменении подхода к обработке смешанного контента на страницах, открытых по HTTPS. Ранее при наличии на открытых по HTTPS страницах компонентов, загружаемых с без шифрования (по протоколу http://), выводился специальный индикатор. В будущем решено блокировать загрузку подобных ресурсов по умолчанию. Таким образом, страницы, открытые по "https://", будут гарантированно содержать только ресурсы, загруженные по защищённому каналу связи.

Отмечается, что в настоящее время более 90% сайтов, открываются пользователями Chrome с использованием HTTPS. Наличие вставок, загружаемых без шифрования, создаёт угрозы нарушения безопасности через модификацию незащищённого контента при наличии контроля за каналом связи (например, при подключении через открытые Wi-Fi). Индикатор смешанного контента признан неэффективным и вводящим пользователя в заблуждение, так как он не даёт однозначной оценки безопасности страницы.

В настоящее время наиболее опасные виды смешанного контента, такие как скрипты и iframe, уже блокируются по умолчанию, но изображения, звуковые файлы и видео по-прежнему могут быть загружены по http://. Через подмену изображений атакующий может подставить отслеживающие действия пользователя Cookie, попытаться эксплуатировать уязвимости в обработчиках изображений или совершить подлог, заменив представленную на изображении информацию.

Введение блокировки разделено на несколько этапов. В Chrome 79, намеченном на 10 декабря, появится новая настройка, которая позволит отключить блокировку для конкретных сайтов. Указанная настройка будет применяться для уже блокируемого смешанного контента, такого как скрипты и iframe, и вызываться через меню, выпадающее при клике на символ замка, заменив собой ранее предлагавшийся индикатор для отключения блокировки.

В Chrome 80, который ожидается 4 февраля, будет применена мягкая схема блокировки звуковых и видео файлов, подразумевающая автоматическую замену в ссылках http:// на https://, что позволит сохранить работоспособность, если проблемный ресурс также доступен по HTTPS. Изображения продолжат загружаться без изменений, но в случае загрузки по http:// на станицах https:// для всей страницы начнёт выводится индикатор незащищённого соединения. Для автозамены на https или блокировки изображений разработчики сайтов смогут использовать CSP-свойства upgrade-insecure-requests и block-all-mixed-content. В выпуске Chrome 81, запланированном на 17 марта, при смешанной загрузке изображений будет применена автозамена на http:// на https://.

Кроме того, компания Google объявила об интеграции в один из следующих выпусков браузера Chome нового компонента Password Checkup, ранее развивавшегося в виде внешнего дополнения. Интеграция приведёт к появлению в штатном менеджере паролей Chrome средств для анализа надёжности используемых пользователем паролей. При попытке входа на любой сайт будет выполняться проверка логина и пароля по базе скомпрометированных учётных записей с выводом предупреждения в случае выявления проблем. Проверка осуществляется по базе, охватывающей более 4 миллиардов скомпрометированных аккаунтов, фигурировавших в утечках пользовательских баз. Предупреждение также будет выводиться при попытке использования тривиальных паролей, таких как "abc123" (по статистике Google 23% американцев используют подобные пароли), или при использовании одного и того же пароля на нескольких сайтах.

Для сохранения конфиденциальности при обращении к внешнему API передаётся лишь первые два байта хэша от связки из логина и пароля (для хэширования используется алгоритм Argon2). Полный хэш шифруется ключом, генерируемым на стороне пользователя. Исходные хэши в базе Google также дополнительно шифруются и оставляются для индексации только первые два байта хэша. Конечная сверка хэшей, подпадающих под переданный двухбайтовый префикс, производится на стороне пользователя с использованием криптографической техники "ослепления", при которой ни одна из сторон не знает содержимое проверяемых данных. Для защиты от определения содержимого базы скомпрометированных учётных записей путем перебора с запросом произвольных префиксов, отдаваемые данные шифруются в привязке к ключу, сгенерированному на основе проверяемой связки логина и пароля.

 

 

[znamenka]

uBlock Origin для Google Chrome пришёл конец?

:

 

Раймонд Хилл, известный как Gorhill, разработчик блокировщика рекламы uBlock Origin, недавно сообщил, что Google отказала в размещении новой версии расширения для разработчиков в Интернет-магазине Chrome.C начала 2019 года достаточно много говорилось о том, что разработка расширений uBlock Origin и uMatrix может прекратиться из-за нового манифеста Chrome, и о том, как эти изменения повлияют на все блокировщики контента и другие подобные расширения.

Летом Google все же объявила о намерении внести изменения в Web Request API, реализуя инициативу Manifest V3, «с целью минимизации сбора данных в Chrome сторонними расширениями для блокировки контента и рекламы». Однако, компания, смягчила ограничение на количество правил фильтрации – до 150 тысяч правил, после того, как столкнулась с серьезной критикой со стороны пользователей и разработчиков.Но, похоже, Google снова вернулась к курсу на ограничение блокировщиков рекламы в Chrome.

Google отказала в публикации uBlock Origin для разработчиков

Раймонд Хилл на своей странице GitHub сообщает, что Google отказала ему в размещении новой версии расширения uBlock Origin для разработчиков в Интернет-магазине Chrome.

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

После размещения новой версии "uBlock Origin development build" разработчик получил от Google сообщение по электронной почте, что расширение нарушает одну из политик Интернет-магазина Chrome, которая запрещает «объединение несвязанных функций в расширениях».

Как сообщает Раймонд Хилл, в электронном письме не содержится никакой другой информации о фактическом нарушении. За подобную практику компанию Google часто критикуют, но она продолжает придерживаться ей во всех сферах своего бизнеса.

Хилл, как уже достаточно опытный разработчик, не питает иллюзий, что Google предоставит информацию об отказе:

Нет смысла так или иначе спекулировать на этой теме, мой опыт работы с Chrome Web Store в прошлом научил тому, что мы никогда не узнаем, почему расширение получило отказ в публикации, Google никогда не раскрывает точную причину "почему".

Версия расширения uBlock Origin для разработчика используется меньшим количеством пользователей, чем стабильная версия, что означает, что отказ пока не затрагивает большинство пользователей расширения. Основная проблема с отказом заключается в том, что следующая стабильная версия расширения будет более или менее идентична отклонённой версии для разработчика.

 

Хотя все еще существует вероятность того, что новая версия uBlock Origin будет опубликована в Интернет-магазине Chrome, более вероятно, что Google снова откажет в размещении, и это может положить конец uBlock Origin для Google Chrome.

Раймонд Хилл рекомендует пользователям найти другой браузер, который продолжает поддерживать uBlock Origin, если они хотят продолжать использовать данный блокировщик рекламы.

Последняя версия расширения доступна для многих основных браузеров, и помимо браузеров на базе Chromium, которые используют Интернет-магазин Chrome, поддерживает Mozilla Firefox, Opera, старый и новый Microsoft Edge: uBlock Origin для Firefox / uBlock Origin для Opera / uBlock Origin для Edge / uBlock Origin для Edge на Chromium.

 

 

 

 

Изменено 12 октября, 2019 пользователем znamenka

[kmscom]

@znamenka, что то подобное происходило и для AdGuard. Они свое мобильное приложение распространяют на своем сайте
https://adguard.com/ru/blog/google-udalil-adguard-dlya-android-iz-play-store.html

[Friend]

@znamenka, Дополнения::

 

Дополнение 1: Несколько минут назад в каталоге Chrome Web Store появился новый тестовый выпуск 1.22.5.102 (rc2), но подтверждения урегулирования проблемы пока нет и не ясно не возникнет ли проблем при попытке обновления стабильной ветки, будущий выпуск (1.22.5) которой идентичен последним тестовым обновлениям, попытка публикации которых привела к проблемам.

Дополнение 2: Симеон Винцент (Simeon Vincent), отвечающий в команде Chrome за взаимодействие с разработчиками дополнений (занимает должность Extensions Developer Advocate), подтвердил, что команда рецензирования уже пересмотрела решение и сборка пропущена в каталог. Отклонение публикации признано ошибкой автоматизированной системы рецензирования. Также утверждается, что ответы службы поддержки генерировались автоматически и в то время не нашлось людей для оценки ситуации (блокировка была выполнена 6 дней назад).

В комментариях подняли важную для каталога Chrome Web Store проблему - uBlock Origin популярное дополнение, имеющее более 10 млн установок, но даже для него потребовалось несколько дней и привлечение общественного внимания, чтобы добиться хоть какой-то реакции от Google. Для менее популярных дополнений ошибки системы рецензирования могут оказаться приговором, а также нет гарантии, что и для uBlock Origin подобные блокировки не повторятся вновь. При этом окончательно всё запутывает то, что сообщения о блокировке не содержат конкретной информации о причине, а только общее упоминание нарушения правил каталога. Все попытки доказать несостоятельность блокировки приводят лишь к безрезультатной переписке с ботом.

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

 

 

[Friend]

Усиление изоляции между сайтами в Chrome :

 

Компания Google объявила об усилении в Chrome режима межсайтовой изоляции, обеспечивающего обработку страниц с разных сайтов в отдельных изолированных процессах. Режим изоляции на уровне сайтов позволяет обезопасить пользователя от атак, которые могут быть совершены через используемые на сайте сторонние блоки, такие как iframe-вставки, или для блокирования утечки данных через встраивание легитимных блоков (например, с запросами к банковским сервисам, на которых может быть аутентифицирован пользователь) на вредоносных сайтах.

При разделении обработчиков в привязке к домену, в каждом процессе находятся данные только одного сайта, что затрудняет совершение атак, направленных на межсайтовый захват данных. В настольных версиях Chrome разделение обработчиков в привязке к домену, а не вкладке, реализовано начиная с Chrome 67. В Chrome 77 подобный режим был активирован и для платформы Android.

Для снижения накладных расходов режим изоляции сайтов в Android включается только если на странице зафиксирован вход при помощи пароля. Chrome запоминает факт использования пароля и включает защиту и для всех дальнейших обращений к сайту. Защита также применяется сразу для избранного списка предопределённых сайтов, популярных среди пользователей мобильных устройств. Выборочный метод активации и добавленные оптимизации позволили удержать рост потребления памяти из-за увеличения числа работающих процессов в среднем на уровне 3-5%, вместо 10-13%, наблюдаемых при активации изоляции для всех сайтов.

Новый режим изоляции активирован для 99% пользователей Chrome 77 на Android-устройствах, снабжённых как минимум 2 Гб ОЗУ (для 1% пользователей режим остался отключённым для мониторинга за производительностью). Включить или отключить режим изоляции сайтов вручную можно через настройку "chrome://flags/#enable-site-per-process".

В настольной редакции Chrome вышеотмеченный режим изоляции сайтов теперь усилен для противостояния атакам, нацеленным на полную компрометацию процесса с обработчиком контента. Улучшенный режим изоляции позволит защитить данные сайтов от двух дополнительных видов угроз: утечек данных в результате атак по сторонним каналам, таких как Spectre, и утечек после полной компрометации процесса-обработчика при успешной эксплуатации уязвимостей, позволяющих получить контроль над процессом, но не достаточных для обхода sandbox-изоляции. В Chrome для Android подобная защита будет добавлена позднее.

Суть метода в том, что управляющий процесс запоминает к какому сайту рабочий процесс имеет доступ и запрещает обращение к другим сайтам, даже если атакующий получит контроль над процессом и попытается получить доступ к ресурсам другого сайта. Ограничения охватывают ресурсы, связанные с аутентификацией (сохранённые пароли и Cookie), загружаемыми напрямую по сети данными (фильтруются и привязываются в текущему сайту HTML, XML, JSON, PDF и прочие типы файлов), данными во внутренних хранилищах (localStorage), полномочиями (выданные сайту разрешения доступа к микрофону и т.п.) и сообщениями, передаваемыми через API postMessage и BroadcastChannel. Все подобные ресурсы связываются меткой с исходным сайтом и проверяются на стороне управляющего процесса на предмет возможности передачи по запросу из рабочего процесса.

Из связанных с Chrome событий также можно отметить начало утверждения включения в Chrome поддержки функции Scroll-To-Text, дающей возможность формировать ссылки на отдельные слова или фразы, без явного указания в документе меток при помощи тега "a name" или свойства "id". Синтаксис подобных ссылок планируется утвердить в качестве web-стандарта, который пока находится на стадии черновика. Маска для перехода (по сути выполняется поиск с прокруткой) отделяется от обычного якоря признаком ":~:". Например, при открытии ссылки "https://opennet.ru/51702/#:~:text=Chromе"страница сдвинется на позицию с первым упоминанием слова "Chromе" и данное слово будет подсвечено. Возможность добавлена в ветку Canary, но для включения требует запуска с флагом "--enable-blink-features=TextFragmentIdentifiers".

Другим интересным предстоящим изменением в Chrome является возможность заморозки неактивных вкладок, позволяющая автоматически выгрузить из памяти вкладки, которые находятся в фоновом состоянии более 5 минут и не выполняют имеющих значение действий. Решение о пригодности той или иной вкладки для заморозки принимаются на основе эвристики. Изменение добавлено в ветку Canary, на базе которой будет сформирован выпуск Chrome 79, и включается через флаг "chrome://flags/#proactive-tab-freeze".

 

 

[znamenka]

Chrome 78: новые API и улучшения темного режима для Android и iOS:

Chrome получил поддержку новых CSS свойств и API: Values API, Native File System API. Также представлены новые экспериментальные функции Origin Trials и улучшена поддержка темного режима в мобильных версиях для Android и iOS.

Аудитория Chrome превышает 1 миллиард пользователей. Это главная платформа, на которую должны обращать внимание разработчики. Изменения в Chrome, а также удаленные функции, часто влияют на вектор развития веба в целом. Например, в Chrome 78 из-за потенциальных проблем приватности был исключен компонент XSS Auditor.

Chrome 78  получил поддержку CSS свойств и Values API: теперь разработчики могут регистрировать переменные как полноценные пользовательские свойства. Они всегда имеют определенный тип, могут принимать значения по умолчанию и даже использоваться для анимации. Изображение ниже демонстрирует анимацию, созданную с помощью пользовательского свойства CSS. Этот переход был невозможен без нового API.

Native File System API позволяет разработчикам создавать веб-приложения, которые могут взаимодействовать с файлами на локальном устройстве. К данному типу приложений относятся различные IDE, фото и видео редакторы, текстовые редакторы др. После того, как пользователь предоставит доступ к файловой системе, новый API позволит веб-приложениям читать содержимое и вносить изменения в файлах и папках. При этом будут открываться собственные диалоговое окна открытия и сохранения.

В Chrome 77 были представлены экспериментальные функции Origin Trials. Они позволяют опробовать новые возможности и предоставить отзывы об удобстве использования и эффективности сообществу веб-стандартов. В Chrome 78 добавлено еще несколько функций, в том числе Signed Exchange и SMS Receiver API. Signed Exchange позволяет дистрибьютору работать с контентом, подписанным издателем. SMS Receiver API позволяет сайтам получать доступ к SMS-сообщениям, которые доставляются на телефон пользователя.

Chrome 78 поставляется с несколькими новыми функциями, которые будут развертываться поэтапно. Например, пользователи Chrome скоро смогут выделять номер телефона на сайте и отправлять его на устройство Android с помощью пункта контекстного меню. Некоторые пользователи получат возможность использовать облачный буфер, который будет синхронизироваться между компьютерами и мобильными устройствами. Для этого нужно будет войти в один и тот же аккаунт Google на обоих устройствах и включить синхронизацию. Google сообщает, что скопированный текст будет защищаться сквозным шифрованием.

 

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

Chrome для Android

Chrome 78 для Android доступен для скачивания в Google Play. С списке изменений всего один пункт:

• Темная тема для меню, настроек и элементов интерфейса Chrome. Доступна на странице Настройки > Темы.

Chrome для iOS

Chrome 78 для IOS доступен в App Store. Google представила три основных улучшения:

• Добавлена возможность переключиться на темный режим, если устройство обновлено до iOS 13.
• Закладки, История, Недавние вкладки и Список для чтения представлены в виде карточек на iOS 13.
• Поддержка добавления кредитной карты на странице настроек Chrome.

Обновления безопасности

Chrome 78 поставляется с 37 исправлениями безопасности. Более двух десятков из исправленных проблем были обнаружены независимыми исследователями.

Google выпускает новую версию браузера каждые шесть недель. релиз Chrome 79 запланирован на начало декабря.

 

Изменено 23 октября, 2019 пользователем znamenka

[znamenka]

Как перевести сайты на темный режим в Google Chrome

:

Введите следующую команду в адресную строку:

 

chrome://flags/#enable-force-dark

 

Напротив "Force Dark Mode for Web Contents" выберите одно из нескольких значений и перезагрузите браузер нажав по кнопке "Relaunch".

 

Выбор у нас сейчас такой:

• Режим по умолчанию;
• Включен;
• Простая инверсия на основе HSL;
• Простая инверсия на основе CIELAB;
• Избирательная инверсия изображений;
• Избирательная инверсия элементов, не являющихся изображениями;
• Избирательная инверсия всего;
• Отключен.
• Напомним что помимо этого переводить сайты на темный режим в Google Chrome можно используя расширение под названием Dark Reader или ему подобные. 

 

 

[Friend]

В Chrome началось тестирование третьей редакции манифеста, несовместимой с uBlock Origin :

 

Компания Google начала тестирование третьей редакции манифеста Chrome, нарушающей работу многих дополнений для блокирования нежелательного контента и обеспечения безопасности. Поддержка нового манифеста, который определяет возможности и ресурсы, предоставляемые дополнениям, добавлена в экспериментальные сборки Chrome Canary. Новый манифест разработан в рамках инициативы по усилению безопасности, конфиденциальности и производительности дополнений (основной целью является упрощение создания безопасных и высокопроизводительных дополнений, и усложнение возможности создания небезопасных и медленных дополнений).

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

Напомним, что основное недовольство новым манифестом связано с прекращением поддержки блокирующего режима работы API webRequest, который будет ограничен режимом только для чтения. Исключение будет сделано лишь для редакции Chrome для предприятий (Chrome for Enterprise), в которых поддержка API webRequest будет сохранена. Компания Mozilla решила не следовать за новым манифестом и сохранить в Firefox возможность полного использования API webRequest.

Вместо API webRequest для фильтрации контента в новом манифесте предложен декларативный API declarativeNetRequest. Если API webRequest позволял подключать собственные обработчики, имеющие полный доступ к сетевым запросам и способные на лету модифицировать трафик, новый API declarativeNetRequest предоставляет доступ к готовому универсальному встроенному движку для фильтрации, самостоятельно обрабатывающему правила блокировки, не разрешающему использовать собственные алгоритмы фильтрации и не позволяющему задавать сложные правила, перекрывающие друг друга в зависимости от условий.

В новом манифесте также представлены и другие изменения, влияющие на совместимость с дополнениями. Среди них:

• Переход к выполнению Service workers в форме фоновых процессов, что потребует от разработчиков изменения кода некоторых дополнений.
• Новая гранулированная модель запроса полномочий - дополнение не сможет активироваться сразу для всех страниц (убрано полномочие "all_urls"), а будет работать только в контексте активной вкладки, т.е. пользователю потребуется подтверждать работу дополнения для каждого сайта.
• Изменение обработки Cross-origin запросов - в соответствии с новым манифестом на скрипты обработки контента будут распространяться те же ограничения полномочий, что и для основной страницы, в которую эти скрипты внедряются (например, если страница не имеет доступа к API определению местоположения, то и скрипт дополнения также не получит этот доступ).
• Запрет выполнения кода, загруженного с внешних серверов (речь про ситуации, когда дополнение подгружает и выполняет внешний код).

 

 

[Friend]

Chrome начнёт помечать быстрые и медленные сайты :

 

Google выступил с инициативой по стимулированию повышения скорости загрузки сайтов в Web, для чего планирует включить в Chrome специальные индикаторы, выделяющие очень медленно или, наоборот, очень быстро загружаемые сайты. Окончательно способы индикации быстрых и медленных сайтов пока не определены, а оптимальный для пользователей вариант будет подобран в ходе нескольких экспериментов.

Например, если сайт обычно загружается медленно из-за применения неэффективных настроек или проблем с организацией загрузки, то в процессе открытия или во время ожидания появления контента может выводиться метка о том, что данный сайт обычно загружается медленно. Уведомление позволит пользователю понять, что задержка для открываемого сайта в порядке вещей, а не обусловлена каким-то единичным сбоем. Для хорошо оптимизированных и обычно очень быстро открываемых сайтов предлагается выделять зелёным цветом полоску, отображающую прогресс загрузки. Также рассматривается возможность предоставления сведений о скорости загрузки ещё не открытых страниц, например, через вывод индикатора в контекстом меню для ссылок.

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

Разработчикам сайтов рекомендуется использовать имеющиеся инструменты для оптимизации скорости загрузки, такие как PageSpeed Insights и Lighthouse. Данные инструменты позволяют проанализировать различные аспекты загрузки web-страницы, оценить потребление ресурсов и определить ресурсоёмкие операции на JavaScript, блокирующие формирование вывода, после чего выработать рекомендации по ускорению и оптимизации.

 

 

[Sandynist]

Доэкспериментировались   https://www.ixbt.com/news/2019/11/16/neozhidannyj-jeksperiment-google-porushil-tysjachi-brauzerov-chrome-i-privjol-k-ogromnym-ubytkam.html

 

Традиционно пострадал корпоративный сектор.

[Friend]

@Sandynist, СМИ раздули проблему, альтернатив браузера много. В самой системе есть Internet Explorer.

[Sandynist]

 

 

СМИ раздули проблему

 

Достаточно прочитать хотя-бы перевод вот этой статьи для того, чтобы убедиться что в Гугле налажали по-крупному. Терминалку к серверу у нескольких тысяч сотрудников не перенастроишь за 5 секунд на другой браузер.

[Friend]

Обновление Chrome 78.0.3904.108 с устранением уязвимостей :

 

Опубликован корректирующий выпуск Chrome 78.0.3904.108, в котором устранены 0-day уязвимости, использованные для организации двух успешных взломов, продемонстрированных на соревновании Tianfu Cup. Проблемы (CVE-2019-13723, CVE-2019-13724) присутствовали в коде для взаимодействия с устройствами Bluetooth и позволяли обратиться к уже освобождённой области памяти (use-after-free) или к данным за границей выделенного буфера.

В новой версии в контекстное меню также была возвращена функция закрытия всех вкладок, кроме текущей ("Close other Tabs"). Напомним, что, проанализировав полученную в результате сбора телеметрии статистику о методах работы пользователей, разработчики пришли к выводу, что функцию "Close other Tabs" можно удалить, так как она востребована лишь 2% пользователей. После того как Google столкнулся с недовольством пользователей подобным решением, было решено вернуть удалённую возможность. Недовольство также вызвал перенос функций восстановления закрытой вкладки и добавления всех вкладок в закладки из контекстного меню вкладок в контекстное меню, показываемое при клике на свободную область справа от кнопок вкладок.