image


Добрый день! Меня зовут Тимур и я программист.


В прошлой статье я сделал анонс сборки Хромиума — Ultimatum, и несмотря на то что обсуждения на хабре слегка потеряли градус (по сравнению с обсуждениями 5-10 летней давности) — пара неплохих идей все таки всплыла. Собственно этой статьей я рассчитываю поднять интерес к теме и попытаться понять на какие фичи у людей есть реальный запрос.


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


Для начала расскажу какие планы развития уже есть (без приоритетов — это просто список того что я рассчитываю сделать):


  • пробросить в api webextensions прямой доступ к сети, tcp и udp модули, сначала клиентов но вполне возможно что потом будет возможность слушать сокеты
  • пробросить в api webextensions прямой доступ к файловой системе (код в хромиуме уже есть для web app, надо по нему просто немного пройтись напильником)

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


  • развитие антидетект браузера


    • webextensions api: доступ ко всем indexedDB со всеми origins (аналогичо localStorages api)
    • webextensions api: доступ ко всем CacheStorage со всеми origins (оно построено поверх disk_cache который мы уже умеем, но там еще нужно уметь сохранять информацию о bucket-ах, то есть проброс к этим кешам в api diskCache проблему не решит, нужно отдельное api)

  • развитие web3.0


    • интегрировать hashNet с атрибутом integrity, этот атрибут является сам по себе uri. Для начала для тех тегов где этот аттрибут уже предусмотрен стандартом, в дальнейшем возможно добавить его к другим тегам. Интреграция подразумевает под собой запрос ресурса с таким тегом из хэшнет (в случае если оригинальный источник недоступен или лагает а имеющиеся hashNet агенты имеют меньший пинг)
    • дать возможность пользователям раздавать закешированный контент полученный как из обычного web-а так и из hashNet другим пользователям hashNet — то есть при желании каждый браузер может выполнять роль наподобие торрент-трекера и раздачи
    • интеграция с торрентами — что то вроде webTorrent-ов только через hashNet, с возможностью использования этих ресурсов в html
    • добавить в chromium поддержку STUN серверов (причем код в хромиум уже есть, надо только до него дотянуться и пробросить в js)


Из обсуждения в предыдущей статье:


  • пробросить в webextensions api возможность скрывать/возвращать обратно любой таб (без выгрузки из памяти) — дает возможность писать расширения реализующие логику группировки табов любой сложности
  • в настройки браузера? (или в webextensions) добавить возможность работать с сертификатами, в частности указывать домены на которых сертификат может/не может участвовать в цепочке доверия (спасибо iassasin за идею)
  • возможность управлять выгрузкой/кешированием открытых страниц (кому-то хочется иметь возможность выгружать их из памяти, кто-то наоборот хочет что бы они всегда были под рукой seraz, V1RuS) — тут будет сложновато но попробовать стоит. Управление кешированием по сути уже покрыто имеющимися возможностями — доступ к http кешу у нас есть + urlRequest api позволяет перехватывать запросы и подменять ответы, этого уже достаточно что бы писать интересные вещи

Из моего опыта практического применения этой сборки:


  • webextensions api: возможность триггерить trusted events (нужно при различных автоматизациях, да, в том числе и авторегистрация на сайтах и это далеко не всегда что то плохое)
  • управление курсором в рамках окна браузера (мотивация та же что и в предыдущем пункте)
  • генерация событий клавиатуры (имитация ввода) — мотивация та же что в предыдущих двух пунктах)

Эти три фичи являются базисом для инструментов автоматизации процессов, что то вроде PyAutoGUI в браузере.


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

Из обсуждения этой статьи:


  • DOM манипуляции — делать DOM элемент инжектнутый расширением невидимым для js страницы И управлять видимостью DOM из расширения (скрывать рекламные блоки, unreal_undead2
    ) — вроде бы такая возможность есть и сейчас, но пусть пока полежит тут.

  • Реализация Containers как в Firefox: возможность программно (с webextensions) задать окружение для каждого таба/фрейма — куки, кеш, storages. Revertis

Вроде бы ничего не забыл.


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


Собственно все из планов, давайте обсудим что еще из полезного могло бы быть в браузере. Любые фантазии, любые хотелки — это мозгошторм, и есть ненулевые шансы что эти фантазии будут реализованы.

Комментарии (32)


  1. unreal_undead2
    10.12.2024 09:14

    Прозрачная блокировка рекламы - т.е. рекламные блоки грузятся, добавляются в DOM, обрабатываются скриптами, но не отображаются.


    1. gonzazoid Автор
      10.12.2024 09:14

      о, nice! Да, совсем забыл, мы что то похожее обсуждали с ребятами, там запрос был на DOM элементы инжектнутые расширением но невидимые для js страницы, это прям рядом. Сейчас добавлю.


    1. V1tol
      10.12.2024 09:14

      Чем-то похожим, вроде бы, занимается https://github.com/dhowe/AdNauseam/.


    1. novoselov
      10.12.2024 09:14

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


      1. unreal_undead2
        10.12.2024 09:14

        Почему то любой adblocker легко детектится скриптами на сайтах - видимо, какие то следы в DOM оставляет.


  1. Revertis
    10.12.2024 09:14

    Реализацию Containers как в Firefox уже предлагали?


    1. gonzazoid Автор
      10.12.2024 09:14

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


  1. RoasterToaster
    10.12.2024 09:14


  1. Demanih
    10.12.2024 09:14

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


    1. gonzazoid Автор
      10.12.2024 09:14

      Что то вроде пункта в контекстном меню при клике на video тэг или как?


      1. Demanih
        10.12.2024 09:14

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


      1. easky
        10.12.2024 09:14

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


        1. OldVitus
          10.12.2024 09:14

          Инструменты разработчика -> вкладка сеть


          1. S-trace
            10.12.2024 09:14

            с HLS-стримами это начинает требовать уже нетривиальных телодвижений.

            Если есть прямая ссылка на видеофайл - нормально, согласен


          1. gonzazoid Автор
            10.12.2024 09:14

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


    1. Burtanshy
      10.12.2024 09:14

      а еще собирать по кусочкам на любых других сайтах..


    1. anonym0use
      10.12.2024 09:14

      1. Demanih
        10.12.2024 09:14

        Требуется установить дополнение-спутник

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


  1. domix32
    10.12.2024 09:14

    развитие web3.0

    ваша идея фактически уже существует в виде zeronet. Только пиринг огромного количества ресурсов довольно быстро умирает.

    А вот поддержку stun - прямой камень в сторону антитрекинга. Если у вас из JS есть доступ, то доступ есть и у сервисов. Да и спуфинг имеет определённые проблемы, если подразумевалось использование STUN серверов для подобного.

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


    1. gonzazoid Автор
      10.12.2024 09:14

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


    1. gonzazoid Автор
      10.12.2024 09:14

      По поводу масштабирования - тут я даже не претендую на решение проблемы и именно поэтому утверждаю что мое решение более жизнеспособно чем тот же ipsf - я не тащу backend специфичные решения на фронт. На клиенте есть bare minimum что бы работать с cas, а все остальное должен решать бэкенд, и развитие этих протоколов не должно вести к ищменениям на фронте. Но это да, будет подробно в одной из следующих статей


  1. TheCoolKuid
    10.12.2024 09:14

    • пробросить в api webextensions прямой доступ к сети, tcp и udp модули, сначала клиентов но вполне возможно что потом будет возможность слушать сокеты

    Это предположим я еще могу оправдать, но

    • пробросить в api webextensions прямой доступ к файловой системе (код в хромиуме уже есть для web app, надо по нему просто немного пройтись напильником)

    для чего расширению лезть в файловую систему?

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

    Так зачем козе баян? Для чего браузеру соперничать с электроном? У электрона совершенно иная область применения

    • webextensions api: возможность триггерить trusted events (нужно при различных автоматизациях, да, в том числе и авторегистрация на сайтах и это далеко не всегда что то плохое)

    • управление курсором в рамках окна браузера (мотивация та же что и в предыдущем пункте)

    • генерация событий клавиатуры (имитация ввода) — мотивация та же что в предыдущих двух пунктах)

    Я думаю вам стоит ознакомится с Playwright, они это все реализовали


    1. gonzazoid Автор
      10.12.2024 09:14

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

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


  1. LiquidBlasted
    10.12.2024 09:14

    Прежде всего - портабельность.
    Чтобы ты мог на новой машине, или после переустановки системы, ПРОСТО СКОПИРОВАТЬ текущую папочку с браузером, и - НЕ настраивать с нуля под себя все настройки самого браузера, НЕ ставить заново все нужные расширения и НЕ настраивать настройки в каждом из них снова, НЕ настраивать параметры и ключи поисковых систем, НЕ реорганизовывать с нуля иконки на тулбаре, НЕ вбивать заново пароли на куче сайтов (как минимум сайтов для всякой фигни где пароли потерять вообще не страшно - в чем-то типа банковских личных кабинетов пароли в браузере не сохраняю изначально)


    1. gonzazoid Автор
      10.12.2024 09:14

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

      • Могут появиться сторонние сервисы синхронизации, если будет спрос

      • Можно поверх этого прикруть выгрузку всего хозяйства в один портабельный формат и после установки аплоадить все свое хозяйство указав этот файл


      1. unreal_undead2
        10.12.2024 09:14

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

        Кто мешает в своём коде поменять на свой общий формат?


        1. gonzazoid Автор
          10.12.2024 09:14

          Сопровождение. Я свой код стараюсь положить рядом а не лезть в код гугля. Не всегда это возможно конечно, но там где возможно - надо делать именно так. Впилить свой формат и разбросать его по всему проекту где это используется - сложная задача сама по себе. А потом сопровождать это и при каждом обновлении изучать что там гуглеры наломали и как теперь с этим жить - это постоянная боль. Это не теория, я начинал со 109 версии, сейчас моя сборка на 129, часть коммитов есть под 130. Это не смертельно больно но больно, и чем больше будет добавлено своего кода тем сложнее будет это сопровождать.


        1. gonzazoid Автор
          10.12.2024 09:14

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


          1. unreal_undead2
            10.12.2024 09:14

            Да, тут или использовать as is c минимальными изменениями и подхватывать гугловые изменения, или отфорковаться в какой то момент и дальше разрабатывать полностью самостоятельно - согласен, что на второе ресурсов надо побольше.


            1. gonzazoid Автор
              10.12.2024 09:14

              Мой сценарий включает еще третью опцию - потихоньку выкидывать лишнее и тем самым уменьшать объем кода на котором возможны конфликты. А это уже несколько векторов - весь энтерпрайз, та часть логики которую можно подхватить в js и которая сейчас сидит в с++ (например многое из сетевых запросов, не сам сетевой стек а обвязка вокруг него) и различные рудименты - например если убрать favicon cache и положить его в http cache - не думаю что будет какая либо просадка в производительности но при этом часть логики уйдет.

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


        1. gonzazoid Автор
          10.12.2024 09:14

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


  1. MagisterAlexandr
    10.12.2024 09:14

    Браузер потенциально сочетается с проектом RatBrowser. Как минимум, возможностью качать видео с источников помимо поддерживаемых yt-dlp. Но не только...