Комментарии 35
Прозрачная блокировка рекламы - т.е. рекламные блоки грузятся, добавляются в DOM, обрабатываются скриптами, но не отображаются.
о, nice! Да, совсем забыл, мы что то похожее обсуждали с ребятами, там запрос был на DOM элементы инжектнутые расширением но невидимые для js страницы, это прям рядом. Сейчас добавлю.
Чем-то похожим, вроде бы, занимается https://github.com/dhowe/AdNauseam/.
Так делает любой adblocker, более интересна функциональность как у Stylebot, но чтобы можно было применять стили до загрузки блоков, чтобы не ждать загрузку рекламы и прочего.
Реализацию Containers как в Firefox уже предлагали?
Нет, но идея хорошая. На что то подобное есть запрос, там народ хочет что бы у каждого фрейма было свое окружение - куки, кеш, сторейджи и прочее. Учитывая что таб это частный случай фрейма - программно там особой разницы в реализации не будет. Но это серьезный подход, там с наскока не порешаешь (хотя большая часть работы уже по сути проделана). Однозначно в список.
Возможность скачивать из браузера любое видео с любого сайта (если видео проигрывается на странице значит должна быть и возможность сохранить его локально).
Что то вроде пункта в контекстном меню при клике на video тэг или как?
Как вариант, сейчас во всех(многих) браузерах есть функция показать видео в отдельном окне, вот и добавить туда возможность его ещё и сохранить локально.
+, многие сайты пытаются скрыть свой контент через непонятные соли и cdn, но если на клиенте оно открывается - значит должна быть возможность это сохранить.
Инструменты разработчика -> вкладка сеть
с HLS-стримами это начинает требовать уже нетривиальных телодвижений.
Если есть прямая ссылка на видеофайл - нормально, согласен
У ютуба например видеоряд идет отдельно от звука. Мне кажется имеет смысл подвеситься на тег видео - там уже все ресурсы обозначены и где то недалеко должен лежать ffmpeg, так что смуксить и сконвертировать в нужный пользователю формат должно быть не сложно (ну теоретически конечно, в любом случае надо сначала код смотреть что бы оценить)
Некоторые сайты всеми правдами и неправдами запиещают открывать консоль разработчика. Однажды задался любой ценой заставить сайт открыть её: при запуске хрома из консоли с нужным аргументом, сразу открывающим консоль, сайт моментально редиректился на главную страницу. Всех деталей, к сожалению, не помню
Какой интересный вектор. Признаюсь, как то мимо меня проходило, погуглил, да, там прикольно. Как минимум нужно выносить поведение дебаггера в настройки, с возможностью указывать политики для разных доменов и возможно еще что то вылезет. Результат не обещаю, но как минимум в тему пошел погружаться, я отпишусь так или иначе когда свое мнение по вопросу выработаю.
а еще собирать по кусочкам на любых других сайтах..
развитие web3.0
ваша идея фактически уже существует в виде zeronet. Только пиринг огромного количества ресурсов довольно быстро умирает.
А вот поддержку stun - прямой камень в сторону антитрекинга. Если у вас из JS есть доступ, то доступ есть и у сервисов. Да и спуфинг имеет определённые проблемы, если подразумевалось использование STUN серверов для подобного.
Система торрентов аналогично не скрывает данные о пользователях, именно поэтому качать торренты через какой-нибудь тор - прямой способ рассказать о себе всему миру, что на корню ломает основную идею тора/i2p и иже с ними.
Stun нужны для того чтобы клиенты находили друг друга. У сервисов(а точнее у других клиентов) будет доступ только к тому что пользователь сам открыл, так что тут я не согласен с тем что это пересекается с антидетект вектором, но тем не менее готов обсуждать это.
По поводу масштабирования - тут я даже не претендую на решение проблемы и именно поэтому утверждаю что мое решение более жизнеспособно чем тот же ipsf - я не тащу backend специфичные решения на фронт. На клиенте есть bare minimum что бы работать с cas, а все остальное должен решать бэкенд, и развитие этих протоколов не должно вести к ищменениям на фронте. Но это да, будет подробно в одной из следующих статей
пробросить в api webextensions прямой доступ к сети, tcp и udp модули, сначала клиентов но вполне возможно что потом будет возможность слушать сокеты
Это предположим я еще могу оправдать, но
пробросить в api webextensions прямой доступ к файловой системе (код в хромиуме уже есть для web app, надо по нему просто немного пройтись напильником)
для чего расширению лезть в файловую систему?
Эти две фичи ставят такую сборку на один уровень с электроном, по сути после их реализации электрон теряет аргументы для своего существования
Так зачем козе баян? Для чего браузеру соперничать с электроном? У электрона совершенно иная область применения
webextensions api: возможность триггерить trusted events (нужно при различных автоматизациях, да, в том числе и авторегистрация на сайтах и это далеко не всегда что то плохое)
управление курсором в рамках окна браузера (мотивация та же что и в предыдущем пункте)
генерация событий клавиатуры (имитация ввода) — мотивация та же что в предыдущих двух пунктах)
Я думаю вам стоит ознакомится с Playwright, они это все реализовали
Насчет файловой системы и всего остального - не уверен но выглядит так как будто вы рассматриваете браузер как конечный продукт и сразу у пользователя. Это один из возможных кейсов но не единственный. Я смотрю на это в том числе и как на конструктор, на основании которого различные команды и стартапы смогут пилить свои решения и уже их решения будут тем самым браузером который пользователь себе поставит. А реализовывать различные фичи в крестах и лезть в потроха хромиума гораздо сложнее чем накидать расширеньку и либо заинлайнить ее в сборку либо сделать дефолтную установку.
Собственно стратегически это основная моя идея - снизить порог вхождения. Текущая сложность хромиума ставит крест на любой попытке создать альтернативный браузер - это так и будет пачка энтузиастов каждый сам по себе и слегка не в себе. Для тектонических сдвигов нужна масса и без снижения порога вхождения этой массы не будет.
Прежде всего - портабельность.
Чтобы ты мог на новой машине, или после переустановки системы, ПРОСТО СКОПИРОВАТЬ текущую папочку с браузером, и - НЕ настраивать с нуля под себя все настройки самого браузера, НЕ ставить заново все нужные расширения и НЕ настраивать настройки в каждом из них снова, НЕ настраивать параметры и ключи поисковых систем, НЕ реорганизовывать с нуля иконки на тулбаре, НЕ вбивать заново пароли на куче сайтов (как минимум сайтов для всякой фигни где пароли потерять вообще не страшно - в чем-то типа банковских личных кабинетов пароли в браузере не сохраняю изначально)
Копированием файлов решать вопрос будет тяжко - как минимум на маках и винде используются различные форматы кешей например. Но. По сути то это решено самим гуглем - синхронизация через облако. То есть если зареверсинженирить это дело и выкатить протокол в открытый доступ то по идее:
Могут появиться сторонние сервисы синхронизации, если будет спрос
Можно поверх этого прикруть выгрузку всего хозяйства в один портабельный формат и после установки аплоадить все свое хозяйство указав этот файл
как минимум на маках и винде используются различные форматы кешей например
Кто мешает в своём коде поменять на свой общий формат?
Сопровождение. Я свой код стараюсь положить рядом а не лезть в код гугля. Не всегда это возможно конечно, но там где возможно - надо делать именно так. Впилить свой формат и разбросать его по всему проекту где это используется - сложная задача сама по себе. А потом сопровождать это и при каждом обновлении изучать что там гуглеры наломали и как теперь с этим жить - это постоянная боль. Это не теория, я начинал со 109 версии, сейчас моя сборка на 129, часть коммитов есть под 130. Это не смертельно больно но больно, и чем больше будет добавлено своего кода тем сложнее будет это сопровождать.
Просто что бы понимание масштаба трагедии было - посмотрите на репу хромиума, там, если не ошибаюсь, под сотню коммитов в ДЕНЬ прилетает. Да, основная масса это минорные именения вроде апа версии какой либо зависимости, но общей картины это не меняет - это водопад изменений и в одну рожицу отслеживать их нереально. Можно только снижать свою зависимость от них.
Да, тут или использовать as is c минимальными изменениями и подхватывать гугловые изменения, или отфорковаться в какой то момент и дальше разрабатывать полностью самостоятельно - согласен, что на второе ресурсов надо побольше.
Мой сценарий включает еще третью опцию - потихоньку выкидывать лишнее и тем самым уменьшать объем кода на котором возможны конфликты. А это уже несколько векторов - весь энтерпрайз, та часть логики которую можно подхватить в js и которая сейчас сидит в с++ (например многое из сетевых запросов, не сам сетевой стек а обвязка вокруг него) и различные рудименты - например если убрать favicon cache и положить его в http cache - не думаю что будет какая либо просадка в производительности но при этом часть логики уйдет.
Это очень большие задумки, я понемногу их думаю но пока рановато за них браться - силенки не те, надо наращивать мышечную массу.
Приведу пример - команда электрона, ресурсов у них сильно больше чем у меня и даже они не могут себе позволить апаться на каждую версию хромиума. Можно посмотреть по версиям их релизов какие там пробелы между апами.
Браузер потенциально сочетается с проектом RatBrowser. Как минимум, возможностью качать видео с источников помимо поддерживаемых yt-dlp. Но не только...
Народный браузер — каким он мог бы быть?