Google Chrome

[Friend]

Релиз Chrome 79 :

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

 

[Friend]

Обновление Chrome 79 для Android привело к исчезновению данных приложений на базе WebView :

 

Разработчики приложений для Android обратили внимание на серьёзную недоработку в Chrome 79, приводящую к потере пользовательских данных в сторонних приложениях, использующих браузерный движок WebView. В Chrome 79 было изменено местоположение каталога с профилем пользователя, в котором в том числе хранятся и данные, сохраняемые web-приложениями при помощи API localStorage или WebSQL. При обновлении с прошлых выпусков Chrome предусмотрен автоматический перенос данных Chrome, но не учтены данные, которые сохранялись в старом каталоге с профилем мобильными приложениями на базе компонента WebView, например, созданными с использованием фреймворка Apache Cordova.

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

Дополнительно можно отметить жалобы о блокировке входа в сервисы Google с использованием некоторых применяемых в Linux браузеров, таких как Konqueror, Falkon и Qutebrowser. В качестве причины указываются возможные проблемы с безопасностью в данных программах. Судя по обсуждению на Reddit блокировка применяется выборочно к пользователям без двухфакторной аутентификации и с браузером на базе устаревших версий движка (старые QtWebEngine, WebKit и KHTML), содержащих неисправленные уязвимости.

Дополнение: Google опубликовал обновление Chrome 79.0.3945.93 для Android, в котором устранена проблема с пропаданием данных (после установки обновления доступ к данным восстановится).

 

 

[sputnikk]

какой разрядности ставится браузер на ос х64 при использовании онлайн-установщика?

[Mark D. Pearlstone]

@sputnikk, x64.

[sputnikk]

@sputnikk, x64.

Опера по прежнему х86.

[Friend]

Chrome, следом за Firefox, добавит защиту от назойливых уведомлений :

 

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

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

В Chrome 80, как в настольной, так и в мобильной редакциях, новый режим будет применяться только при определённых условиях, но в настройках будет предусмотрен пункт для его применения для всех запросов полномочий (chrome://flags/#quiet-notification-prompts). Автоматически новый режим будет выборочно включаться для пользователей, которые до этого обычно блокировали подобные запросы, а также для сайтов, на которых фиксируется большой процент отклонения запросов.

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

 

 

[Friend]

Google намерен до 2022 года прекратить поддержку сторонних Cookie в Chrome:

 

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

Как и заявленное вчера намерение унифицировать заголовок User-Agent, отказ от сторонних Cookie продвигается в рамках инициативы Privacy Sandbox, нацеленной на достижение компромисса между потребностью пользователей сохранить конфиденциальность и желанием рекламных сетей и сайтов отслеживать предпочтения посетителей. До конца этого года в режиме origin trial ожидается включение в браузер дополнительных API для измерения конверсии и персонализации рекламы без применения сторонних Cookie.

Для определения категории интересов пользователя без проведения индивидуальной идентификации и без привязки к истории посещения конкретных сайтов, рекламным сетям предлагается использовать API Floc, для оценки активности пользователя после перехода на рекламу - API Conversion Measurement, а для разделения пользователей без использования межсайтовых идентификаторов - API Trust Token. Развитие спецификаций, связанных с показом таргетированной рекламы без нарушения конфиденциальности, ведётся отдельной рабочей группой, созданной при организации W3C.

В настоящее время в контексте защиты от передачи Cookie в ходе CSRF-атак применяется указываемый в заголовке Set-Cookie атрибут SameSite, который начиная с Chrome 76 по умолчанию выставлен в значение "SameSite=Lax", ограничивающее отправку Cookie для вставок со сторонних сайтов, но сайты могут отменить ограничение, явно выставляя при установке Cookie значение SameSite=None. Атрибут SameSite может принимать два значения ‘strict’ или ‘lax’. В режиме 'strict' Cookie удерживаются от отправки для любых видов межсайтовых запросов. В режиме 'lax' применяются более мягкие ограничения, и передача Cookie блокируется только для межсайтовых субзапросов, таких как запрос изображения или загрузка контента через iframe.

В Chrome 80, намеченном на 4 февраля, будет применено более жёсткое ограничение, запрещающее обработку сторонних Cookie для запросов без HTTPS (с атрибутом SameSite=None Cookie смогут выставляться только в режиме Secure). Кроме того, продолжается работа по реализации средств для определения и защиты от применения обходных методов отслеживания и скрытой идентификации ("browser fingerprinting").

Напомним, что в Firefox, начиная с выпуска 69, по умолчанию обеспечено игнорирование Cookie всех сторонних систем отслеживания перемещений. Google считает подобную блокировку оправданной, но требующей предварительной подготовки Web-экосистемы и предоставления альтернативных API для решения задач, для которых ранее использовались сторонние Cookie, без нарушения конфиденциальности и не подрывая модели монетизации сайтов, финансируемых за счёт показа рекламы. В ответ на блокировку Cookie без предоставления альтернативы рекламные сети не прекратили отслеживание, а лишь перешли к применению более изощрённых методов на основе скрытой идентификации пользователей (fingerprinting) или через создание для трекера отдельных поддоменов в домене сайта, на котором показывается реклама.

 

 

Google опубликовал план прекращения поддержки Chrome Apps, NaCl, PNaCl и PPAPI:

 

Компания Google опубликовала график прекращения поддержки специализированных web-приложений Chrome Apps в браузере Chrome. В марте 2020 года в Chrome Web Store будет прекращён приём новых приложений Chrome Apps (возможность обновления существующих программ продлится до июня 2022 года). В июне 2020 года поддержка Chrome Apps будет прекращена в версиях браузера Chrome для Windows, Linux и macOS, но до декабря будет оставлена опция, позволяющая вернуть Chrome Apps для пользователей Chrome Enterprise и Chrome Education.

В июне 2021 будет полностью прекращена поддержка API NaCl (Native Client), PNaCl (Portable Native Client, вытеснен WebAssembly) и PPAPI (Pepper API для разработки плагинов, пришедший на смену NPAPI), а также возможность использования Chrome Apps в Chrome OS (для пользователей Chrome Enterprise и Chrome Education до июня 2022 года будет оставлена опция для возвращения поддержки Chrome Apps). Решение затрагивает только Chrome Apps и не касается браузерных дополнений (Chrome Extensions), поддержка который остаётся без изменений. Примечательно, что изначально Google объявил о намерении отказаться от Chrome Apps ещё 2016 году и намеревался прекратить их поддержку до 2018 года, но потом отложил данный план.

В качестве причины прекращения поддержки специализированных Chrome Apps называется движение в сторону универсальных web-приложений и технологии Progressive Web Apps (PWA). Если во время появления Chrome Apps многие расширенные возможности, такие как средства для работы в offline, отправки уведомлений и взаимодействия с оборудованием, не были определены в штатных Web API, то теперь они стандартизированы и доступны для любых web-приложений. Кроме того, технология Chrome Apps не получила должного распространения на настольных системах - только около 1% пользователей Chrome для Linux, Windows и macOS используют данные приложения. Для большинства пакетов Chrome Apps уже имеются аналоги, реализованные в форме обычных web-приложений иди браузерных дополений. Для разработчиков Chrome Apps подготовлено руководство по миграции на штатные web-технологии.

 

 

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

 

Доступно обновление браузера Chrome 79.0.3945.130 в котором устранены четыре уязвимости, одной из которых присвоен статус критической проблемы, позволяющей обойти все уровни защиты браузера и выполнить код в системе, за пределами sandbox-окружения. Детали о критической уязвимости (CVE-2020-6378) пока не раскрываются, известно только, что она вызвана обращением к уже освобождённому блоку памяти в компоненте для распознавания речи.

Остальные три уязвимости помечены как опасные. Уязвимость CVE-2020-6379 также связана с обращением к уже освобождённому блоку памяти (Use-after-free) в коде распознавания речи. Проблема CVE-2020-6380 вызвана ошибкой верификации сообщений от дополнений. Ещё одно изменение связано с добавлением защиты от уязвимости CVE-2020-0601 в Crypto API платформы Windows, допускающей создание поддельных TLS-сертификатов и фиктивных цифровых подписей (уже доступны прототипы кода для генерации фиктивных сертификатов, которые верифицируются в Windows как заслуживающие доверия).

 

 

[Friend]

Релиз Chrome 80 :

 

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

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

• Для небольшого процента пользователей предложена функция группировки вкладок, позволяющая объединять несколько сходных по назначению вкладок в визуально разделённые группы. Каждой группе можно привязать свой цвет и имя. Пользователи, не попавшие в первую волну активации, могут включить поддержку группировки чрез опцию "chrome://flags/#tab-groups".
• Добавлена поддержка функции Scroll-To-Text, позволяющей создавать ссылки на отдельные слова или фразы, без явного указания в документе меток при помощи тега "a name" или свойства "id". Синтаксис подобных ссылок планируется утвердить в качестве web-стандарта, который пока находится на стадии черновика. Маска для перехода (по сути выполняется поиск с прокруткой) отделяется от обычного якоря признаком ":~:". Например, при открытии ссылки "https://opennet.ru/52312/#:~:text=Chromе"страница сдвинется на позицию с первым упоминанием слова "Chromе" и данное слово будет подсвечено.
• Применено более жёсткое ограничение передачи Cookie между сайтами, для не-HTTPS запросов запрещающее обработку сторонних Cookie, выставляемых при обращении к сайтам, отличным от домена текущей страницы. Подобные Cookie применяются для отслеживания перемещений пользователя между сайтами в коде рекламных сетей, виджетов социальных сетей и систем web-аналитики. Напомним, что для управления передачей Cookie применяется указываемый в заголовке Set-Cookie атрибут SameSite, который по умолчанию теперь выставлен в значение "SameSite=Lax", ограничивающее отправку Cookie для межсайтовых субзапросов, таких как запрос изображения или загрузка контента через iframe с другого сайта. Сайты могут переопределить применяемый по умолчанию режим SameSite, явно выставляя при установке Cookie значение SameSite=None. При том значение SameSite=None для Cookie может выставляться только в режиме Secure (действует для соединений через HTTPS). Изменение начнёт поэтапно применяться 17 февраля, вначале для небольшого процента пользователей, а потом постепенно расширяя охват.
• Добавлена защита от назойливых уведомлений, связанных с подтверждением полномочий. Так как подобная активность, например, спам запросами на получение push-уведомлений, прерывает работу пользователя и отвлекает внимание на действия в диалогах подтверждения, в Chrome 80 вместо отдельного диалога, в адресной строке теперь может отображаться информационная подсказка с предупреждением о блокировке запроса полномочий, которая затем сворачивается в индикатор с изображением зачёркнутого колокола. При клике на индикатор можно активировать или отклонить запрошенное полномочие в любой удобный момент. Автоматически новый режим будет выборочно включаться для пользователей, которые до этого обычно блокировали подобные запросы, а также для сайтов, на которых фиксируется большой процент отклонения запросов. Для включения нового режима для всех запросов в настройки добавлена специальная опция (chrome://flags/#quiet-notification-prompts).
• Запрещён вывод всплывающих окон (вызов метода window.open()) и отправка синхронных запросов XMLHttpRequest в обработчиках событий закрытия или скрытия страницы (unload, beforeunload, pagehide и visibilitychange);
• Предложена начальная защита от загрузки смешанного мультимедийного контента (когда на HTTPS-странице загружаются ресурсы по протоколу http://). На страницах, открытых по HTTPS, теперь автоматически будут заменяться ссылки "http://" на "https://" в блоках, связанных с воспроизведением звуковых и видео файлов. Если звуковой или видео ресурс недоступен по https, то его загрузка блокируется (вручную можно отметить блокировку через меню, доступное через символ замка в адресной строке). Изображения продолжат загружаться без изменений (автозамена будет применена в Chrome 81), но для замены на https или блокировки изображений разработчикам сайтов предоставлены CSP-свойства upgrade-insecure-requests и block-all-mixed-content. Для скриптов и iframe блокировка смешанного контента уже была реализована ранее.
• Началось постепенное отключение поддержки FTP. По умолчанию поддержка FTP пока сохраняется, но будет проведён эксперимент, в рамках которого для определённого процента пользователей поддержка FTP будет отключена (для возвращения потребуется запустить браузер с опцией "--enable-ftp"). Напомним, что в прошлых выпусках уже было отключено отображение в окне браузера содержимого ресурсов, загружаемых по протоколу "ftp://" (например, прекращён показ HTML-документов и файлов README), запрещено использование FTP при загрузке субресурсов из документов и прекращена поддержка прокси для FTP. Тем не менее, до сих пор оставалась возможность загрузки файлов по прямым ссылкам и отображение содержимого каталогов.
• Добавлена возможность использования векторных SVG-изображений в качестве пиктограммы сайта (favicon).
• В настройки добавлена возможность выборочного отключения отдельных типов данных, передаваемых при синхронизации между браузерами.
• Для централизованно администрируемых корпоративных пользователей добавлено правило BlockExternalExtensions, позволяющее запретить установку внешних дополнений на устройство.
  
   
• Реализована возможность единовременной проверки всей цепочки свойств или вызовов в JavaScript. Например, при обращении к "db.user.name.length" ранее требовалось поэтапно проверить определение всех составных частей, например, через "if (db && db.user && db.user.name)". Теперь при помощи операции "?." можно обратиться к значению "db?.user?.name?.length" без предварительных проверок и такое обращение не приведёт к выводу ошибки. В случае проблем (если какой-то элемент обработан как null или undefined)) на выходе будет выдано значение "undefined".
• В JavaScript предложен новый логический оператор объединения "??", который возвращает правый операнд, если левый операнд имеет значение NULL или undefined, и наоборот. Например, "const foo = bar ?? 'default string'" если bar равен null, вернёт стоку или значение bar в противном случае, в том числе, когда bar равен 0 и ' ', в отличие от оператора "||".
• В режиме Origin Trials (экспериментальные возможности, требующие отдельной активации) предложен API Content Indexing. Origin Trial подразумевает возможность работы с указанным API из приложений, загруженных с localhost или 127.0.0.1, или после прохождения регистрации и получения специального токена, который действует ограниченное время для конкретного сайта. API Content Indexing, предоставляет метаданные о контенте, который ранее был прокэширован web-приложениями, работающими в режиме Progressive Web Apps (PWS). Приложение может сохранять на стороне браузера различные данные, включая изображения, видео и статьи, а при пропадании сетевого соединения использовать их при помощи API Cache Storage и IndexedDB. Content Indexing API даёт возможность добавлять, находить и удалять подобные ресурсы. В браузере данный API уже используется для перечисления списка страниц и мультимедийных данных, доступных для просмотра в offline.
• Стабилизирован и теперь распространяется вне Origin Trials программный интерфейс Contact Picker, позволяющий пользователю выбрать записи из адресной книги и передать определённые детали о них на сайт. При запросе определяется список свойств, которые необходимо получить. Данные свойства явно отображаются пользователю, который принимает решение передавать эти свойства или нет. API может быть использован, например, в почтовом web-клиенте для выбора получателей для отправляемого письма, в web-приложении с функцией VoIP для инициирования звонка по определённому номеру или в социальной сети для поиска уже зарегистрированных друзей. При этом в рамках Origin Trials предложены некоторые новые свойства Contact Picker: помимо ранее доступных ФИО, email и номер телефона, добавлена возможность передачи почтового адреса и изображения.
• В Web Workers предложен новый способ загрузки модулей ECMAScript, позволяющий обойтись без применения функции importScripts(), которая блокирует работу worker-а во время обработки импортируемого скрипта и выполняет его в глобальном контексте. Новый способ подразумевает создание специальных модулей для Web Workers, которые поддерживают стандартные механизмы импорта JavaScript и могут загружаться динамически, не блокируя выполнение worker-а. Для загрузки модулей в конструкторе Worker предусмотрен новый тип ресурса - 'module':
  const worker = new Worker('worker.js', {
  type: 'module'
  });
• Реализована встроенная возможность обработки в JavaScript сжатых потоков, не требующая использования внешних библиотек. Для сжатия и распаковки добавлены API CompressionStream и DecompressionStream. Поддерживается сжатие с использованием алгоритмов gzip и deflate.
  const compressionReadableStream
  = inputReadableStream.pipeThrough(new CompressionStream('gzip'));
• Добавлено CSS-свойство "line-break: anywhere", разрешающее разрывы на уровне любого типографического символа, в том числе разрывы рядом с символами пунктуации, предопределёнными пробелами (<pre>) и в середине слов. Также добавлено CSS-свойство "overflow-wrap: anywhere" разрешающее разрывать неразрывные последовательности символов в любом месте, если в строке не удалось найти пригодную для разрыва позицию.
• Для медиаконтекта, обрабатываемого в шифрованном виде, реализована поддержка метода MediaCapabilities.decodingInfo(), предоставляющего сведения о возможностях браузера, связанных с декодированием защищённого контента (например, указанный метод можно использовать для выбора сценариев высококачественного или экономящего потребление энергии способов декодирования с учётом доступной пропускной способности и размера экрана).
• Добавлен метод HTMLVideoElement.getVideoPlaybackQuality(), через который можно получить сведения о производительности воспроизведения видео для корректировки битрейта, разрешения и других параметров видео.
• В API Payment Handler, который упрощает интеграцию с существующими платёжными системами, добавлена возможность делегирования обработки адреса и контактной информации внешнему обработчику платёжной системы (приложение платёжной системы может обладать более точными сведениями, чем браузер).
• Добавлена поддержка HTTP-заголовка Sec-Fetch-Dest, позволяющего отправить дополнительные метаданные о типе связанного с запросом контента (например, для запроса через тег img указывается тип "image", для шрифтов - "font", для скриптов - "script", для стилей - "style" и т.п.). На основе указанного типа сервер может принять меры для защиты от некоторых типов атак (например, маловероятно, что ссылка на обработчик для перевода денег будет задана через тег img, поэтому такие запросы не нужно обрабатывать).
• В JavaScript-движке V8 проведена оптимизация хранения указателей в куче. Вместо полного 64-разрядного значения обеспечено хранение только уникальных нижних битов указателя. Подобная оптимизация позволила сократить потребление памяти в куче на 40%, ценой снижения производительности на 3-8%.
• Изменения в инструментах для web-разработчиков:
  • В web-консоли появилась возможность переопределения выражений let и class.
  • Улучшены средства отладки WebAssembly. Добавлена поддержка DWARF для пошаговой отладки, указания точек останова и анализа трассировок стека в исходном коде, на котором написано приложение WebAssembly.
  • Улучшена панель для анализа сетевой активности. Добавлена возможность просмотра цепочки вызова скриптов, связанных с инициированием запроса.

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

    
  • Во вкладке Network Conditions добавлена опция для изменения параметра User-Agent.
  • Предложен новый интерфейс для настройки панели аудита.
  • Во вкладке Coverage предоставлен выбор сбора coverage-данных для каждой функции или для каждого блока кода (более детальная статистика, но требует больше ресурсов).
• Действие манифеста AppCache (технология для организации работы web-приложения в offline-режиме) ограничено текущим каталогом сайта (если манифест был загружен с www.example.com/foo/bar/, то возможность переопределения URL будет действовать только внутри /foo/bar/). В Chrome 82 поддержку AppCache планируется удалить полностью. В качестве причины называется желание избавиться от одного из векторов для совершения атак, связанных с межсайтовым скриптингом. Вместо AppCache рекомендуется использовать API Cache.
• Прекращена поддержка устаревшего API WebVR 1.1, вместо которого можно использовать API WebXR Device, позволяющий получить доступ к компонентам для создания виртуальной и дополненной реальности и унифицировать работу с различными классами устройств, от стационарных шлемов виртуальной реальности до решений на базе мобильных устройств.
• Обработчики протоколов, подключаемые через методы registerProtocolHandler() и unregisterProtocolHandler(), теперь могут работать только в безопасном контексте (при доступе через HTTPS).

Кроме нововведений и исправления ошибок в новой версии устранено 56 уязвимостей. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Критических проблем, которые позволяют обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения, не выявлено. В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google выплатила 37 премий на сумму 48 тысяч долларов США (одна премия $10000, три премии $5000, три премии $3000, четыре премии $2000, три премии $1000 и шесть премий $500). Размер 17 вознаграждений пока не определён.

 

 

[Friend]

В Chrome намечено включение блокировки навязчивой видеорекламы:

 

Компания Google опубликовала план реализации в Chrome блокировки неприемлемых видов видеорекламы, предложенных Коалицией по улучшению рекламы (Better Ads Standard) в новом варианте рекомендаций по блокированию неприемлемой рекламы, отображаемой при просмотре видео.

Рекомендации учитывают основные причины недовольства пользователей, вынуждающие устанавливать блокировщики. Для определения раздражающих видов рекламы использован опрос около 45 тысяч пользователей из 8 стран, охватывающих около 60% рынка интернет-рекламы. В итоге были выделены три основных вида раздражающей пользователей рекламы, показываемой до начала показа, в процессе просмотра или после завершения просмотра видеоконтента длительностью не более 8 минут:

• Рекламные вставки любой продолжительности, прерывающие показ видео в середине просмотра;
• Длительные рекламные вставки (дольше 31 сек.), отображаемые перед началом показа видео, без возможности их пропустить спустя 5 секунд после начала рекламы;
• Отображение больших текстовых объявлений или рекламных изображений поверх видео, если они перекрывают больше 20% видео или выводятся в середине окна (в центральной трети окна).

В соответствии с выработанными рекомендациями компания Google намерена 5 августа включить в Chrome блокировку рекламных блоков, подпадающих под вышеприведённые критерии. Блокировка будет распространяться на всю рекламу на сайте (без отсеивания конкретных проблемных блоков), если владелец оперативно не устранит выявленные проблемы. Статус проверки рекламных вставок на сайте можно посмотреть в специальном разделе инструментов для web-разработчиков.

Что касается сайта YouTube.com и принадлежащих Google рекламных платформ, то компания намерена провести рецензирование показываемых в своих сервисах видов рекламы на предмет соответствия новым требованиям.

 

 

Chrome начнёт блокировать загрузку файлов по HTTP :

 

Компания Google опубликовала план добавления в Chrome новых механизмов защиты от небезопасной загрузки файлов. В Chrome 86, релиз которого намечен на 26 октября, загрузка всех видов файлов по ссылкам со страниц, открытых по HTTPS, будет возможна только при отдаче файлов с использованием протокола HTTPS. Отмечается, что загрузка файлов без шифрования может использоваться для совершения вредоносной активности через подмену содержимого в процессе MITM-атак (например, поражающее домашние маршрутизаторы вредоносное ПО может подменять загружаемые приложения или перехватывать конфиденциальные документы).

Блокировка будет внедряться постепенно, начиная с выпуска Chrome 82, в котором при попытке небезопасной загрузки исполняемых файлов по ссылкам со страниц HTTPS начнёт выдаваться предупреждение. В Chrome 83 для исполняемых файлов будет включена блокировка, а предупреждение начнёт выдаваться для архивов. В Chrome 84 будет активирована блокировка архивов и вывод предупреждения для документов. В Chrome 85 документы будут блокироваться, а предупреждение начнёт выводиться при небезопасной загрузке изображений, видео, звука и текста, которые начнут блокироваться в Chrome 86.

В более отдалённом будущем планируется полностью прекратить поддержку загрузки файлов без применения шифрования. В выпусках для Android и iOS блокировка будет внедряться с отставанием на один выпуск (вместо Сhrome 82 - в 83 и т.п.). В Chrome 81 в настройках появится опция "chrome://flags/#treat-unsafe-downloads-as-active-content", которая позволит включить вывод предупреждений, не дожидаясь выхода Сhrome 82.

   

 

 

[Friend]

Из Chrome Web Store удалено более 500 вредоносных дополнений:

 

Подведены итоги блокирования серии вредоносных дополнений к браузеру Chrome, жертвами которых стало несколько миллионов пользователей. На первом этапе независимый исследователь Джамиля Кайя (Jamila Kaya) и компания Duo Security выявили в каталоге Chrome Web Store 71 вредоносное дополнение. В сумме указанные дополнения насчитывали более 1.7 млн установок. После информирования Google о проблеме, в каталоге было обнаружено ещё более 430 подобных дополнений, число установок которых не сообщается.

Примечательно, что несмотря на внушительное число установок, ни у одного из проблемных дополнений нет отзывов пользователей, что наводит на вопросы о том, каким образом были установлены дополнения и как вредоносная активность оставалась незамеченной. В настоящее время все проблемные дополнения удалены из Chrome Web Store. По мнению исследователей, связанная с заблокированными дополнениями вредоносная деятельность ведётся с января 2019 года, но отдельные домены, применявшиеся для выполнения вредоносных действий, были зарегистрированы ещё в 2017 году.

В основной массе вредоносные дополнения преподносились как инструменты для продвижения продуктов и участия в рекламных сервисах (пользователь просматривает рекламу и получает отчисления). В дополнениях применялась техника перенаправления на рекламируемые сайты при открытии станиц, которые по цепочке показывались перед отображением запрошенного сайта.

Во всех дополнениях использовалась однотипная техника для скрытия вредоносной активности и обхода механизмов верификации дополнений в Chrome Web Store. Код всех дополнений был практически идентичен на уровне исходных текстов, за исключением имён функций, которые в каждом дополнении были уникальны. Передача вредоносной логики осуществлялась с централизованных управляющих серверов. Вначале дополнение подключалось к домену, имеющему такое же имя как и название дополнения (например, Mapstrek.com), после чего перенаправлялось на один из управляющих серверов, отдававших сценарий дальнейших действий.

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

 

 

[Friend]

0-day уязвимость в Chrome, выявленная через анализ изменений в движке V8 :

 

Исследователи из компании Exodus Intelligence продемонстрировали слабое место в процессе исправлений уязвимостей в кодовой базе Chrome/Chromium. Проблема связана с тем, что Google раскрывает сведения, что внесённые исправления имеют отношение к проблемам с безопасностью только после релиза, но добавляет в репозиторий код для устранения уязвимости в движке V8 до публикации релиза. Какое-то время исправления проходят тестирование и возникает окно, в течение которого уязвимость становится исправленной в кодовой базе и доступной для анализа, но уязвимость остаётся неисправленной на системах пользователей.

Изучая вносимые в репозиторий изменения исследователи обратили внимание на добавленное 19 февраля исправление и в течение трёх дней смогли подготовить эксплоит, поражающий актуальные выпуски Chrome (опубликованный эксплоит не включал компоненты для обхода sandbox-изоляции). Компания Google оперативно выпустила обновление Chrome 80.0.3987.122, устранив связанную с предложенным эксплоитом уязвимость (CVE-2020-6418). Уязвимость была изначально выявлена инженерами Google и вызвана проблемой с обработкой типов в операции JSCreate, которая может быть эксплуатирована через метод Array.pop или Array.prototype.pop. Примечательно, что похожая проблема была исправлена в Firefox летом прошлого года.

Исследователи также обратили внимание на упрощение создания эксплоитов из-за включения в Chrome 80 механизма упаковки указателей (вместо полного 64-разрядного значения хранятся только уникальные нижние биты указателя, что позволяет значительно сократить потребление памяти в куче). Например, некоторые находящиеся в начале кучи структуры данных, такие как таблица встроенных функций, объекты "native context" и корневые объекты сборщика мусора, теперь размещаются по предсказуемым и доступным на запись упакованным адресам.

Интересно, что почти год назад компанией Exodus Intelligence была сделана аналогичная демонстрация возможности создания эксплоита на основе изучения публичного лога исправлений в V8, но, судя по всему, должных выводов не последовало. На месте исследователей Exodus Intelligence могли оказаться злоумышленники или спецслужбы, которые при создании эксплоита имели бы возможность дни или даже недели скрыто эксплуатировать уязвимость до формирования очередного релиза Chrome.

 

 

[Friend]

Выпуск Chrome 81 отложен из-за перехода сотрудников Google к работе на дому :

 

Из-за изменения рабочего графика сотрудников компания Google приостановила публикацию выпусков Chrome 81 и Chrome OS 81, намеченных на 17 и 24 марта. Отмечается, что главными целями является обеспечения стабильности, безопасности и надёжности работы Chrome. Обновления с устранением уязвимостей продолжат формироваться в приоритетном порядке и при необходимости будут доставлены в форме обновления для Chrome 80.

Из-за пандемии коронавируса COVID-19 на этой неделе большая часть сотрудников Google была переведена на работу на дому, что также привело к задержкам в рецензировании обновлений приложений в каталоге Google Play.

 

 

[animelubitel]

По моему мнению первая по разработкам технологий Гугл Хром, 2 Мозила Файрфокс, а опера вообще раньше на собственном движке может чето и делала, а сейчас просто в основном собственный интерфейс. Или я не прав? Лично мне нравится опера

[Friend]

Google пропустит выпуск Chrome 82 :

 

Компания Google опубликовала новую информацию о приостановке разработки новых релизов Chrome в связи со временным переводом части сотрудников на работу на дому из-за пандемии коронавируса SARS-CoV-2. Решено полностью пропустить выпуск Chrome 82 и приступить сразу к формированию ветки Chrome 83. Разработка новых возможностей будет перемещена в ветку Chrome 83. Ветку trunk/master планируется поддерживать в более-менее стабильном состоянии, избегая рискованных изменений, которые могут привести к снижению стабильности.

Ветка Chrome 81 продолжит находится на стадии бета-тестирования до готовности Chrome 83 к началу бета-тестирования, после чего будет опубликован релиз Chrome 81. В соответствии с ранее имевшимся планом выпуск был Chrome 82 был намечен на 28 апреля, а Chrome 83 на 9 июня, но компания Google намерена скорректировать график в зависимости от хода разработки ветки Chrome 83.

 

 

[Friend]

В Chrome 83 появится настройка для показа полного URL в адресной строке :

 

Компания Google намерена вернуть настройку, отключающую искажение URL в адресной строке. В кодовую базу, на основе которой будет сформирован релиз Chrome 83, принято изменение с поддержкой настройки "chrome://flags/#omnibox-context-menu-show-full-urls", при установке которой в контекстом меню адресной строки появится флаг "Always show full URLs" для возвращения отображения полного URL.

Напомним, что в Chrome 76 адресная строка была переведена по умолчанию на показ ссылок без "https://", "http://" и "www."). Для отключения данного поведения была предусмотрена настройка "chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains". В Chrome 79 данная настройка была удалена и пользователи потеряли возможность отображения полного URL в адресной строке. Изменение вызвало недовольство пользователей и разработчики Chrome согласились добавить опцию для показа неизменного URL.