Как стать автором
Обновить

Как я вижу идеальный браузер

Время на прочтение37 мин
Количество просмотров37K
В последнее время появилось много статей о недостатках современного софта, при этом никто не пробует предложить свои решения, чтобы поменять ситуацию. Эта статья — ответ на некоторые статьи об этом, равно как и о мечтах о идеальном браузере. Как можно было бы переработать браузер, его UI, методы взаимодействия с сайтами, улучшить протоколы и пользовательский опыт в целом. Если у вас есть какие-то, пусть даже самые смелые мысли по этому поводу, то предлагаюсь обсудить их и быть может заложить основы для создания идеального браузера. В конечном счете, рано или поздно это нужно будет сделать, так как ситуация на рынке браузеров на данный момент совсем не радостная. И не проблема, что другие браузеры очень сложны и их сложно догнать — мы можем пойти по своему пути, реализовывать только необходимые части стандартов, при этом можем вводить свои нестандартные расширения. Не надо бежать за другими, пусть другие бегут за нами. Пусть наш браузер будет создан для людей, а не во имя коммерческих интересов корпораций добра и странных консорциумов, от которых давно нет никакой пользы.



Что же должно быть в идеальном браузере?





Поиск

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

Однажды на одном из форумов я нашел интересную концепцию алгоритма. Обсуждения не было, так что я быстро закрыл вкладку, но сама концепция осела у меня в голове. Поразмышляв над ней в фоновом режиме, я решил поделиться своими идеями… Но где? Быстро посмотрев форумы, где я обычно обитал — я не нашел ничего подобного. В поисковиках тоже ничего, но это и не удивительно — форумы не мгновенно индексируются. Я начал рыться в хистори браузера — ничего не нашел, но это и не удивительно, так как она большая, ей неудобно пользоваться, я мог что-то пропустить. Я заново открывал почти все странички — ничего подобного не нашел. Я начал искать сообщения в почте, в мессенджерах, даже спрашивать людей — без результата. Я уже было начал думать, что мной управляют рептилоиды, внушающие концепты, как решился применить последнее средство: поиск по файлам браузерного кеша. И почти мгновенно нашел то место, которое искал. Оказалось, что поскольку никто не отвечал в тему форума, автор подумал, что он написал глупость, ему стало стыдно и он просто удалил тред. А я эту удаленную тему долго искал и не мог найти, накручивая себя.

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

Сессии

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

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

А может быть сохранять всю сессию целиком, как некий проект? Давать им осмысленные имена вида «Искал модель лодки», «Учусь программировать» и включать/выгружать по мере надобности? Механизм профилей или сессий есть сейчас в каждом браузере, только он зачастую как-то спрятан, что отыскать его сложно, а пользоваться еще сложнее. Пожалуй единственный браузер, где такой механизм хорошо реализован — это браузер Edge в своих последних версиях. При всех недостатках данного браузера, данный механизм сделан в нем максимально удобно и позволяет не накапливать вкладки, а удобно их сортировать. Конечно, нет предела совершенству, но иметь хотя бы такой вариант — обязательно. А еще лучше иметь возможность сохранять такие сессии вместе с кешем/контентом страниц. Только не так, как это делают браузеры сейчас, сохраняя кеш в некотором бинарном виде, а чтобы можно было открыть 100 вкладок по новой теме, сохранить их в какой-то читаемый другими устройствами формат (.html/.pdf) и залить себе на телефон, где спокойно читать, быть может в отдалении от цивилизации.

Приватность

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

Я хочу иметь возможность:

* задавать ширину и высоту экрана (любую, хоть 50000x50000 пикселей)
* глубину цвета, независимо от текущих настроек
* добавить сайт в доверенные, чтобы его куки не прокисали при нажатии «очистить все»
* заменить шрифты на странице, при этом предоставлять сайту тот список шрифтов, который он хочет
* предоставлять произвольный User-Agent, быть может даже рандомный, взятый из большого файла вариантов или привязанный к конкретному сайту
* выбирать язык контента и видеть то, что передается серверу, а не просто «предпочитаемый язык», который еще неизвестно во что развернется
* количество и последовательность заголовков, включая эмуляцию известных багов других браузеров

И вообще, все то, что можно отфингерпринтить, надо иметь возможность изменить. Я хочу иметь такую возможность.

Самое смешное, что древние браузеры имеют кучу настроек для этого. К примеру, такие браузеры как links, w3m и netsurf позволяют не только отключать Referrer/User-Agent, но и предоставляют множество разных интересных опций, где можно достаточно тонко настроить поведение браузера, как он будет заполнять эти поля. В то время как только будущие версии Firefox научатся это делать, причем лишь частично, не давая 100% защиты пользователя, без каких-либо опций, жестко определяя поведение лишь при некоторых условиях (впрочем, о настройках сайтов и условиях мы еще поговорим).

Летающие корабли

Очень долгое время MSIE не поддерживал position:fixed, за что его ругали. И как показывает практика — хорошо, что не поддерживал. Правда людей это не останавливало и они эмулировали его через JS с прыгающими менюшками, которые сохранились и по сей день на миллионах сайтов.

Сегодня перекрытие элементов используется для всякого полезного: окна логина на весь экран, вылезающие во время просмотра страниц и которые нельзя убрать (facebook), всплывающие ассистенты, оказывающиеся чат-ботами, сообщения на весь экран о акциях и подарках, как я что-то выиграл, иногда просто мне показывают рекламу (само собой без рекламы, но и без кнопки закрытия), прозрачные попапы, которые не дают кликать по странице (pornhub), ну и апофеоз: мне рассказывают, что я должен отключить AdBlock, которого у меня нет.

А вы пробовали распечатать любую страницу? А я вот достаточно часто «печатаю» PDF и мне хочется бить тех, кто делают всплывающие растяжки вида «мы используем кукисы» или «вот тут брейкин-ньюз» где-то вверху или снизу экрана. Ну, или просто фиксированное меню сверху и простой футер снизу. Не, ну на экране это выглядит еще ничего, можно страничку поскроллить и как-то прочитать то, что они загораживают. А вы знаете, что эта гадость печатается на каждой странице? И печатается поверх текста? И что бумагу не поскроллить, хотя очень охота, ведь эта гадость загораживает часть контента, который никак не прочитать? Пока что я вынужден через инспектор элементов/ublock отламывать стили или удалять какие-то отдельные менюшки, только после этого я могу «распечатать» страницу. Это несколько напрягает. А вот если бы были простые управляемые элементы, то такого бы даже не случилось!

Зато внутри движка браузера можно детектировать, когда элемент перекрывает собой текстовую информацию и… Ну, к примеру, убирать его куда-то в сторону. Или вообще отламывать стили, объявляя их опасными. Вариантов масса. Можно представить страницу как слои и дать пользователю пару кнопок, чтобы «срезать» верхние слои или возвращать обратно, как это сделано в некоторых игрушках или трехмерных редакторах — я джва года хочу такую функцию!

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

Снапшот страницы

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

А придя к компьютеру через несколько часов замечаешь, что КУРСОР МЫШКИ ЕЛЕ ДВИГАЕТСЯ, ВСЕ В СВОПЕ, РАБОТАТЬ ЗА КОМПЬЮТЕРОМ НЕВОЗМОЖНО, В УЖАСЕ ОТКРЫВАЕШЬ СПИСОК ПРОЦЕССОВ И КИЛЯЕШЬ ГАДА (если сможешь дождаться отрисовки списка процессов). И тут закрывается вкладочка как раз с этим невинным сайтом.

Чтобы такого не было, я в свое время написал для Firefox плагин, который спустя 5 секунд после загрузки страницы (события onload) подменял setInterval/setTimeout/requestAnimationFrame на пустые вызовы, которые ничего не делали, а существующие отключал. В принципе, я радовался. Правда всякие интерактивные элементы, вроде разворачивающихся спойлеров, тоже перестали работать, так как таймеров больше не было, а открытие спойлера запускало таймер для анимации. Большая ли это цена? Мне пришлось отказаться от своего плагина, так как я не мог возвращать обработчики по какому-то событию, но если мы пишем свой браузер — почему нет?

Альтернативная реализация: спустя 10 секунд от события onload, мы останавливаем весь JS, выгружаем DOM и оставляем только те структурки в памяти, которые нужны для рендеринга прямоугольничков с текстом, таблицами и картинками. Все, пусть фоновая вкладка будет чем-то вроде картинки с текстом, не более того. Еще одна альтернатива: весь лейаут мы рендерим в отдельном процессе, а загружаем только координаты текста и картинок после рендеринга, как это было в Opera Mini, таким образом наш браузер будет еще чуток безопаснее.

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

Кеширование контента локально

Рассказываю идею на миллион баксов: загрузка страницы за 0мс. Нет, даже если сайт полностью лежит в нашем кеше, то он не откроется, пока мы не пошлем запрос, не подождем Round Trip Time, не распарсим ответ, а потом не проделаем аналогичное со всеми оставшимися скриптами и стилями. А что мешает открывать его СРАЗУ из кеша и в фоне проводить валидацию контента, посылая сразу запросы ко ВСЕМ ресурсам в фоне, в фоне же, используя двойную буферизацию, обновлять данные в случае изменений, как просто перерисовывая картинки, так и блоки текста? Скажете, что уже было в IE и называлось «Работать автономно»? Да, в IE до сих пор много хороших и интересных функций, но во-первых, данная функция работала не всегда, а во-вторых, мы не сможем обновить страницу, а в моем случае страница будет автоматически перерисована по мере валидации.

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

Само собой, кеширование должно быть в виде инкрементальных diff-ов (иначе места не хватит на всё), с интеллектуальным парсингом неотображаемой информации (незачем хранить изменяющийся код счетчиков), с подсветкой изменений, с выбором старых версий прямо из адресной строки. Хранить можно уже распаршенные странички, как набор прямоугольников и их координат на экране, таким образом можно ускорить рендеринг, а изображения можно даунскейлить и хранить в виде h265, который гораздо лучше jpeg-картинок — мы экономим место. И если уж мы столько сил потратили на принудительный кеш и его облагораживание, то почему бы не поделиться им с кем-то еще? Юзер-интерфейс тут главное. Фича не только должна быть, но ей должно быть удобно пользоваться: открывать разные версии страницы, удалять или сохранять версии страниц, анонсировать их как публичный кеш, делать выборку страниц и выгружать локальные версии сайта (страниц, по которым ходили), делать что-то вроде mht/pdf с рабочими ссылками, чтобы их можно было открывать на других устройствах, а не только они оседали где-то во внутренних хранилищах браузера, как происходит в некоторых мобильных браузерах.

Чтобы ускорить загрузку страниц и застраховать себя от нежданных инъекций кода, различные скрипты, такие как jquery и ему подобные, хранящиеся на разных CDN, можно подгружать прямо с локального диска, как это делает расширение Decentraleyes. Загрузка шрифтов и икон-паков станет мгновенной. Узнать больше о том, что уже есть: addons.mozilla.org/en-US/firefox/addon/decentraleyes. Разумеется, неплохо бы сделать инъекции своего кода, по аналогии с browser.js (только не руками авторов) или Grease Monkey (только без троянов), чтобы можно было изменять/исправлять код сайтов. Нет, не костыли в виде плагина, а нативную поддержку, которая не будет тормозить, как это когда-то было в Опере. Но увы, сейчас удобных средств для патчинга кода сайтов просто нет. Ричард Столлман называет это «тивоизацией» сайтов, но об этом будет написано в разделе о подписях кода.

Добавим сюда некий гипотетический sitemap.xml, определяющий родство статей, страницы для упреждающего кеширования, ссылку на некий трекер для p2p-обмена контентом… И мы получаем самореплицирующийся сайт, который можно сохранить и использовать локально, который будет выдерживать любые нагрузки и контент которого не умрет никогда. Впрочем об этом, равно как и о распределенных сайтах, мы поговорим далее.

Подпись кода

Многие из нас не задумываются, но в браузере может исполняться код разных людей, написанный под различными, в том числе и несвободными лицензиями. И не факт, что пользователь согласен с этими лицензиями. Это как вступать в сексуальные отношения без предварительного согласия. В принципе, в большинстве случаев ничего плохого не произойдет, но могут быть нюансы. Ричард Столлман написал отличную статью «Ловушка Javascript», по мотивам которой было написано расширение LibreJS: en.wikipedia.org/wiki/GNU_LibreJS — это то, что должно стать отправной точкой в деле интерпретации Javascript в нашем браузере!

Если бы указание лицензии было частью стандарта, жизнь была бы чуточку легче, но этого нет. Если бы авторы кода его подписывали своим публичным ключем, то я мог бы хотя бы доверять различным авторам, но нет и этого. Остается только хешировать скрипты, включая самые мелкие, вшитые в страницу и спрашивать пользователя «разрешить ли это?» для запуска каждого из них, ведя базу разрешенных или запрещенных скриптов. Что-то уровня антивируса. Тоже поиск «вирусни» по сигнатурам, но вместо эвристического анализатора — указание лицензии и вопросы к пользователю. На основе таких хешей можно не только обезопасить себя от вредоносного кода, но и построить систему версионирования. Создать инфраструктуру, где будет запускаться только тот код, которому вы доверяете! Вам ведь надоело бороться со скриптами, которые переворачивают текст и просят отключить Адблок? Я бы отключил, но у меня нету Адблока, равно как и уверенности в том, что завтра меня не попросят сделать донейт или подписаться на какую-то аферу.

Если вы еще не знакомы с замечательным трудом Ричарда Столлмана, то рекомендую почитать: www.gnu.org/philosophy/javascript-trap.ru.html (на русском языке).

Оценка сайтов / антирейтинг

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

Но можно было пойти другим путем: вместо того, чтобы что-то патчить, писать кому-то на емейл, использовать личные связи и все такое, можно было бы выводить текст патча прямо поверх страницы со словами «автор этого сайта не придерживается стандарта, следующий код мог бы починить этот сайт». Дернул вызов IE-only? Никакой эмуляции, вместо неё большой красный попап о профпригодности автора (конечно же, не перекрывая контента). Многие пользователи конечно проигнорируют это, но кто-то может задать авторам сайта вопрос: «А что это тут так много красненького?». И владельцы сайта будут рассказывать, как они экономили деньги на программистах. Или рассказывать клиенту о том, что надо бы поставить «нормальный Гуугле Кхроме», из-за чего клиент скорее уйдет от них. Если же такой сайт будет выводить что-то вроде «location.href = 'http://google.com/', приходите к нам еще» — так это еще лучше, не надо связываться с такими людьми.

Можно пойти дальше: картинка на странице отображается как 100х100, а на самом деле 500х500? Красный попап с сообщением о том, что автор не умеет ресайзить картинки. Картинка с фотореалистичной графикой пожата в PNG? Красный попап о том, что автор не разбирается в форматах файлов. На странице нету ссылки на главную страницу? Красный попап с сообщением о том, что автор сайта не сделал нормальную навигацию.

Конечно, красный попап выводить можно не всегда. К примеру, если PNG изображение можно лучше оптимизировать через optipng, то можно выводить просто красненький варнинг, как выводят их блокировщики рекламы. Нечто подобное уже делают различные CDN-оптимизаторы, которые и картинки пережимают, и код минифицируют, а на входе даже SQL-инъекции пытаются фильтровать. Но вся эта радость будет только в том случае, если автор заплатил денег и подключил соответствующие услуги, а что делать простому пользователю? А простой пользователь может просто отказаться от использования некачественного сайта, и его браузер должен ему в этом помочь.

Уже сейчас отчет блокировщиков рекламы, который выводит цифирки, можно считать неким антирейтингом сайта. Чем больше антирейтинг — тем хуже сайт и автору надо бы что-то с этим сделать. При некоторых значениях можно просто выводить варнинги о том, что посещение этого сайта может быть нежелательным. Причем я считаю, что браузер должен делиться своими находками с сообществом. Можно создать глобальный рейтинг каждого сайта, цепляя заветные цифирки к каждой ссылке, чтобы случайно не перейти куда-то туда, где пользователя ждет «плохой опыт». Конечно, автоматизировать все нельзя. Поэтому можно создать несколько рейтингов, часть из которых будут вести живые люди, вручную проверяя код, проверяя их лицензии и качество кода, качество сайта в целом. Конечно же, механизм должен быть децентрализованным и неподконтрольным конкретным лицам. Пусть пользователь сам решит, на какие подписки будет подписан.

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

Каждый сайт или группа сайтов должны иметь свои индивидуальные настройки, подобно тому, как это можно было настроить в старой Опере (до 12-х версий включительно). Только данный механизм можно улучшить.

Во-первых, идентифицировать сайты не только по домену или поддомену, но и по регулярному выражению в домене. Или по полученному IP-адресу этого домена. К примеру, я не хочу выполнять скрипты на сайтах/ресурсах от Яндекса (о причинах см. далее), я бы мог найти списки блоков IP-адресов, пренадлежащих Яндексу и нежно перебанить выполнение неблагонадежного кода. Это просто и легко. Но на данный момент я вынужден ограничиться лишь баном отдельных доменов (а их всех я не знаю!), занесением всех диапазонов адресов в фаерволл, что крайне неудобно, или же поднятием своего DNS-сервера с указанием адресов для маски *yandex*, что я делаю на данный момент.

Во-вторых, чтобы не плодить сущности, можно создать базовые профили, такие как «доверенный сайт», «обычный сайт», «плохой сайт», «для сайтов от Васяна», «для Алиэкспресса» и присваивать свои настройки тому или иному сайту. И в зависимости от профиля, будет отправляться свой User-Agent, последовательность и содержимое заголовков, поддерживаться или неподдерживаться загрузка стилей, шрифтов, скриптов и всего остального, что только можно настроить. Даже определить, можно ли перехватывать правый клик мыши, с какой точностью запускать таймеры или воспроизводить ли анимации и звуки (с непонятной целью на AliExpress зачем-то появляется запрос на MIDI). Можно предусмотреть и настройки, меняющиеся рандомно, такие как случайные значения User-Agent из большого списка или произвольный прокси для конкретного сайта (об этом позднее).

Копирование и вставка

Казалось бы, что может быть самой основной фунцией в программах, которые отображают текст? Работа с выделением/копированием/вставкой текста конечно же!

Увы, но даже с простым выделением уже начинаются проблемы. Вы пробовали выделить ссылку? В браузере, в почте, в IM? И как оно? Где-то ссылка начинает перетаскиваться, где-то осуществляется переход по ней, даже если вы не отпускали кнопку, а где-то надо целиться в миллиметровый зазор, чтобы иметь возможность выделить ее. Выделение картинок — отдельная лотерея, порой этого вообще нельзя сделать, кроме как нажав секретную хакерскую комбинацию CTRL+A. Шаг вправо-влево — и у нас выделена вся страница, а не тот абзац, в который мы целились.

Или текст может не выделяться вообще, создавая иллюзию сломанной кнопки мышки. Если даже мы прицелились и смогли выделить текст, то не факт, что при нажатии правой кнопки мыши у нас не появится крутое предупреждение вида «Текст этой страницы круто защищен». Или вообще ничего не появится, благо браузеры научились отламывать такие скрипты автоматически. Или не вылезет просьба отправить отчет о найденной на странице опечатке. Я во время чтения текста часто его выделяю мышкой для удобства восприятия, а подобная гадость неимоверно бесит.

Со вставкой еще хуже. Будет ли сохранено форматирование или нет? Иногда это зависит от того, используете ли вы хоткей, или пользуетесь «колесиком» — разное поведение, для вроде бы одного действия. Будут ли пробелы в том, что вставляется в сторонние приложения, если между блоками не было пробелов? А иногда от форматирования не избавишься: вставляешь скопированный текст в пределах страницы, к примеру, в пределах набираемого письма, а набираемый абзац вдруг становится жирным и/или превращается в цитату.

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

Распределенное хранилище

Локальное кеширование контента, о котором мы говорили ранее — это только часть потребностей пользователя современного веба. Вторая важная часть проблемы — кеширование контента на сервере, по пути к клиенту на разных CDN и тому подобном. Фактически, небольшие сайты могут столкнуться с тем, что нужно слишком много трафика чтобы доставить, по сути, практически статические файлы. Всё снова и снова. И у них практически нет никакого выхода, кроме как кормить зажравшуюся CloudFlare, чтобы она предоставляла свой распределенный кеш.

У самой же CloudFlare есть интересная технология RailGun: www.cloudflare.com/website-optimization/railgun — это крутой костыль, который позволяет кешировать не кешируемое, при помощи которого они не просто кешируют старые версии страниц, а еще делают diff-ы с ними и отсылают уже пересобранную разницу со своих серверов. Таким образом получается, что можно обновлять страничку всего 1 пакетом данных в 400 байт (число взято из описания), а оригинальный сервер может хоститься хоть на телефоне (на самом деле это не так). Но за такую штуку надо платить, от $200 в месяц, что очень существенные деньги для небольших сайтов.

Эх, а если бы можно было разделить контент на небольшие управляемые элементы… Но да, об этом позже. Пока есть костыли вроде diff и cloudflare с его Railgun.

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

Впрочем, ничего нового тут нет. Лет 15 назад у популярных вебсайтов был свой десктопный клиент (и порой не один) и что-то вроде торрент-раздач в комплекте к нему. Да и сегодня это существует в том или ином виде, например, приложение WikiTaxi, которое позволяет держать Википедию в своем кармане. А еще я вспоминаю о такой штуке как AportExpress, внутри которой был полноценный шаблонизатор и родные шаблоны Апорта с сервера, собиравший странички на клиенте.

Улучшенная работа с сетью

Вы можете себе представить, что иногда люди выходят в сеть через разные GSM-модемы, где и без того невысокая скорость дорезается плохими условиями приема сигнала / плохими условиями договора? И существуют сайты вроде imgur.com/a/XJmb7, где лежат ну очень красивые вещи, но и вес самой странички, включая всю графику, превышает десятки мегабайт. Вот только проблема — такие странички невозможно посмотреть при таком соединении.

Сегодня браузер пытается грузить все картинки одновременно, замедляя загрузку каждой из них (для этого еще делают кучу суб-доменов, чтобы обойти лимиты на количество соединений). Через какое-то время наступает таймаут и сервер просто закрывает соединение, оставляя нас с битыми картинками, которые хорошо если вообще как-то откроются. Если нажать F5, то на мгновение произойдет отрисовка (отмена загрузки и отображение того, что успело прогрузится), а потом загрузка пойдет с самого начала, без докачки индивидуальных изображений. А еще вы ведь часто замечали, что браузер «загружает» страничку или файл сначала со скоростью в 50кб/сек, потом в 20кб/сек, а потом 3кб/сек? Это значит, что реальная скорость загрузки по какой-то причине стала равна 0 байт/сек, а оборвать соединение и начать заново черевато большими сложностями, даже если технически докачать файл возможно.

А ведь вебсервер может генерировать torrent-файлы для статики и раздавать их в автоматическом режиме, что позволит как докачивать файлы, так и снимать нагрузку с сетевого канала! По своей сути, torrent-файл есть всего лишь список контрольных сумм, которые позволяют скачивать файл с произвольного места и проверять корректность скачанного. Таким образом даже недокачанные картинки можно будет легко выкачать, пусть с 5-й попытки, точно решить вопрос с версионностью и валидациями кеша.

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

К сожалению, современные разработчики пытаются бороться с этими проблемами по-своему, не предоставляя настроек и реализуя все это собственными руками, т.е. «как получится». К примеру, подгрузка картинок/видео через кучу JS, множество доменов и обработку скроллинга страницы, из-за чего быстро промотать страницу до «десятой страницы» уже нельзя, что меня очень сильно бесит. К счастью, некоторые крупные вендоры, такие как Сяоми начали с этим бороться, спрашивая каждый раз «Вы хотите воспроизвести видео? За это может сниматься дополнительная плата!», но пока нельзя настроить автоматический запрет на подобные безобразия, да и способов обхода со стороны разработчика все еще много.

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

Скачивание сайтов

Допустим, я нашел сайт с мануалами по выращиванию клубники. Восхитился, загорелся идеей, поехал на дачу и… И столкнувшись с проблемами понял, что надо было каждую страничку сконвертить в PDF, а только потом ехать на дачу. Почему в PDF? Да потому, что современные странички даже поштучно не хотят сохраняться корректно, а что будет отображено при открытии локального HTML и куда оно напихает Cookie остается только гадать.

А ведь в былые времена я мог взять Teleport Pro и выкачать весь сайт с клубникой, залить это себе на телефон и спокойно поехать на дачу! Все картинки будут выкачаны, все ссылки будут перелинкованы, практически все будет работать. Были даже сайты с уже выкачанными сайтами — незаменимая штука для обучения в те годы, равно как и поисковые системы на JS, работающие прямо в браузере!

Но что будет сегодня, если я попытаюсь сделать так? Меня ждет открытие, что в современных сайтах странички динамические, у каждой страницы есть тысяча URL-ов и я легко выкачаю три странички 10000 раз, тщательно их перелинкую, а при просмотре до нужной странички так и не дойду, даже если она будет скачана (по пути из 50 ссылок, который я должен буду пройти точно так же, как это сделала качалка).

А если очень хочется? В таком случае мы сегодня берем и пишем парсер сайта, выковыриваем контент (регулярками или xpath), как-то это перелинковываем при помощи самодельных скриптов, приделываем индекс из говна и палок, может быть даже простейший поисковик. Все это занимает от 1 дня, до тех пор, пока не надоест. Можно просто накопипастить текст в Word и материться от того, что все вставляется красным Импактом и разметка едет до такой степени, что на это невозможно смотреть. Можно включить записывалку видео и листать странички — менее затратный вариант по времени, хоть и весить такая запись будет много, но в наши времена это мало кого волнует.

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

И не надо думать, что современные сайты в принципе невозможно выкачать. Наоборот, в моду снова входит статика, есть даже интересные и популярные проекты вроде github.com/jekyll/jekyll для генерации статики. Так почему бы не раздавать «исходники» сайта?

Дисклеймер: Teleport Pro тут используется лишь как наиболее известная софтина для выкачивания сайтов, это ни разу не реклама или ностальгия, лично я его недолюбливал из-за кучи временных файлов и неумение корректно парсить javascript. Моим выбором были другие качалки, не так широко известные, вроде webzip, которые хоть и требовали кучу ресурсов, вставляли рекламу в странички, но выкачивали контент корректно и полностью.

Медиаконтент

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

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

1. Как бы покрутить яркость/контрастность в этом? А динамическую нормализацию?
2. Как бы переключиться в фулскрин? А если кнопки нет, так как ее забыли нарисовать?
3. Как бы ускорить скучную лекцию на 3 часа?
4. Как бы покрутить эквалайзер? Лектора еле слышно, даже если выкрутить колонки
5. Как бы вырезать вооон тот кусочек и отправить его другу?
6. Как бы быстро вернуться назад, на пару секунд, не прицеливаясь мышкой в маленькую полосочку?
7. Как бы сделать так, чтобы оно выдавало более 15 fps?

Некоторые вендоры уже пытаются решить эту проблему. Проблему в виде примитивных самоделок с базовыми фичами. К примеру, в Опере можно «отслоить» плеер от странички и управлять им отдельно. Есть youtube-dl, который позволяет не только выкачать видео из кучи сервисов, но и получить ссылку, чтобы ее можно было засунуть в нормальный плеер, хотя бы в VLC. Еще есть StreamLink и MPV, попробуйте, наверняка вам понравится это больше, чем штатные плееры.

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

Для того, чтобы коннект к источнику видео не РВАЛСЯ и видео заново не скачивалось, мы можем открыть локальный прокси-сервер, как это делают торрент-клиенты, с перепаковкой видеопотока на лету, который используем для раздачи видео во внешнее приложение, а когда запрос придет — часть отсервим из кеша, а часть будем в реальном времени скармливать, согласно запросам приложения и возможностям сайта. Аналогично, любое видео/аудио можно будет легко сохранить в виде файла, даже если изначально оно представляло собой живую трансляцию или динамически генерируемый скриптами медиасорс и файлов как таковых даже не существовало. И не надо где-то в кишках страниц искать прямые ссылки, воевать с редиректами или включать тяжелую артилерию в виде записи видео с экрана — браузер должен быть для пользователя, а уж пользователь своего добьется, тут ему никто не помешает. Самое сложное тут, это пожалуй, инъекция в процесс Флеша. Но его жизненный цикл заканчивается, потому слишком часто он обновляться не должен.

Фильтрация нежелательного контента

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

К примеру, на сайте с работой/фрилансом вы можете часто видеть, что нужно кому-то написать реферат, но при этом вы рефератами не занимаетесь, равно как не пишите на JS или PHP, но взять и выкинуть все такие проекты из поисковой выдачи зачастую просто нельзя, равно как и полагаться на категории — их никто нормально не указывает. Или вы просматриваете ленту новостей, а после падения очередного самолета уже не знаете куда деваться от новостей про самолет, особенно если там были родственники и это вас ранит? Некоторых людей достали какие-то выражения модных и знаменитых, а то и просто тренды вроде спиннеров или покемонов, в результате чего появились даже специальные плагины к браузерам, чтобы этого просто не видеть. А кто не хотел бы добавить некоторых «друзей» в блеклист так, чтобы больше никогда не видеть их посты? А еще бы не видеть новостей про блюющего носорога с их наглой рекламой, прикрываемой тестированием опенсорс-программ и бесплатной помощью сообществу…

Самое смешное, что практически в любом email-клиенте есть богатые фильтры по сортировке/автоудалению нежелательной почты, но почти ни на одном вебсайте нету такой функциональности. Если же наш контент был бы нарезан на маленькие управляемые элементы, то мы могли бы осуществлять фильтрацию / подсветку, чтобы не тратить свое время на то, что нам явно не интересно. И мне бы не пришлось писать парсеры для некоторых сайтов, которые удаляли 90% контента и предоставляли мне выжимку в виде оставшихся 10% в нужном мне формате. И не по 10 элементов на странице. Хотя бы по 1000 штук. Можно было бы использовать RSS-читалки, но RSS/Atom есть далеко не везде, особенно его нехватает в результатах поиска.

Маленькие управляемые элементы

Так что же это за такие маленькие и управляемые элементы сайта, упоминавшиеся ранее? Чтобы было проще понять, давайте представим статичный json-файл с какой-либо информацией. Или XML, или базу SQLite, или XLS-файл, или CSV-текстовик, или что-то такое, что даже еще не появилось на свет, но обязательно бинарное, сжатое и нанотехнологичное… А внутри маленькие кусочки информации. Маленькие потому, что представляют собой неделимые логические единицы. Это может быть ссылка в панели навигации, сниппет на описание товара, сам товар со всеми свойствами, комментарий пользователя, а то и целая статья. Это могут быть и какие-то отдельные виджеты сайта: поле поиска, корзина заказов, поле логина/разлогина.

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

К примеру, я пытаюсь найти новые крутые работы в области демосцены. Я иду на pouet.net, тыкаю Prods, а дальше… С одной стороны, я хочу только крутые работы, потому сортирую работы по количеству лойсов. На первом месте я вижу мой любимый fr-041: debris, равно как и другие работы, которые видел уже не раз. Но я хочу чего-то свежего! Тыкаю я значит на release date, тут только свежак. Но кто из них лучший? Как бы мне совместить 2 сортировки? Или хотя бы сделать выборку по временному отрезку вида «за последние полгода» и только потом сортировать? Увы, но мне не дали инструментов для этого. А ведь каждая из работ могла бы быть представлена в нашем JSON-файле как элемент из массива работ, на основании схемы данных, наш браузер мог бы нарисовать элементы управления, не зависящие от авторов сайта, где мы бы осуществляли выборки в свое удовольствие.

Другой пример: мы все знаем, что лучше поиска чем у Google просто не существует. Но иногда он считает себя настолько умным, что выбрасывает из поискового запроса целые фразы, переводит их на разные языки и показывает то, что считает более полезным. Мне этого не надо. Где галочка «перестань умничать, я тут главный»? Раньше она заключалась в правильной расстановке кавычек и плюсиков, а теперь находится она по адресу bing.com — сразу включается более примитивный поиск, зато ищет ровно то, что мне надо и не умничает, не игнорирует мои ключевые слова, не игнорирует условия запроса. Если вообще найдет что-то, а если не найдет — честно об этом скажет, не пытаясь придумать что-то от себя. В том случае, если бы нам выдавали маленькие управляемые элементы, то мы легко бы смогли соединить результаты поиска от обоих поисковиков в единую поисковую ленту, для этого нужно было бы лишь соединить 2 однотипных массива.

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

Опять вернемся к сортировкам. Как и при поиске красивых демосцен, при поиске товара в онлайн-магазинах зачастую интересуют несколько параметров, но отсортировать результаты выборки можно только по какому-то одному. Если вообще можно. Этим страдают даже крупнейшие торговые площадки. Если бы они возвращали сырые данные, то ими было бы очень легко манипулировать. На практике, надо открывать по 50 страниц и вручную сравнивать описания товара, подбрасывать монетки и надеяться, что покупка будет успешной. Никаких мошеннических схем, когда к лоту добавляется расческа за 1 доллар как аксессуар, а на деле минимальная стоимость от 10 долларов. Есть и более интересные методы. Когда я покупал свой первый планшет, я выкачал описания 15000 товаров и парсил их регулярками в поисках нужных мне ключевых слов — было очень медленно, но я нашел свою любовь (это был U9GT2).

Но давайте вернемся к нашей клубнике. А точнее, к сайту с мануалами о выращивании клубники.

Представим себе, что инструкция по выращиванию клубники — это ресурс (пока еще в виде json-файла, для простоты), который можно запросить отдельно, внутри которого есть семантическая разметка (она расскажет нам на какие страницы оно ссылается и о типе связей). Никакой навигации, топов лучших советов или комментов других пользователей — только чистый контент. Ну, топы, комменты и советы там где-то рядом конечно тоже могут быть, но главное, что это не в виде монолита, можно точно идентифицировать нужные типы данных. Конечно, сюда наверняка добавят рекламу и скрипты, но об этом позднее. Пока считаем, что у нас есть чистый контент, прямиком из базы данных (или даже из редактора контента). Такое легко выкачать, сложить, проиндексировать, не говоря уже о легкости кеширования и доставки контента. Такие элементы можно использовать для пре-кеширования как на CDN, так и в браузере, создания bulk-пакетов с контентом для эффективного сжатия и загрузки (чтобы не дергать отдельно каждую кнопку по 50 байт), для версионирования и архивации. Такие данные можно долго крутить-вертеть в браузере без какой-либо нагрузки на сервер, долго играться с сортировками и разными выборками. Самое смешное, что это все уже именно так и хранится в базах данных, внутри управляющих CMS. Но наружу все это подается через «монолитизатор», который впечатывает данные в монолитный HTML, с которым потом очень сложно работать.

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

Где такие маленькие элементы? Что уже есть?

В это сложно поверить, но попытки отделить контент от его представления были уже достаточно давно. Первой ласточкой был RSS, который отлично справляется с ролью доставки сниппетов. Яндекс.маркет требует от магазинов выгрузки в специальном XML-формате, который содержит цены, картинки, данные о производителе и даже доставке. У других площадок свои форматы выгрузки, к примеру, Google Merchant использует немного модифицированный RSS2.0, но в целом эти форматы можно читать и делать рендерер уже сегодня.

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

Можно было бы обмениваться чистым XML или JSON с кучей именованых и полустандартизированных полей. Можно обмениваться даже самими базами данных в формате SQLite или генерировать небольшие выборки в нем. Главное, чтобы тут были чистые данные, без какого-либо кода (о этом чуть позже).

Где брать счастье?

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

На сегодняшний день существуют несколько проектов, которые специализируются на парсинге сайтов. Некоторые, такие как Octoparse, не требуют практически никаких знаний, нужные блоки выбираются мышкой. Равно как и план «обхода» сайта тоже заполняется мышкой. Это значит, что порог вхождения для «программирования» будет крайне низким, даже домохозяйка при желании сможет сделать свой парсер, если захочет. Если парсер будет некачественным или перестанет работать, то браузер просто отобразит страницу как есть, пока кто-то другой не напишет новый парсер.

Есть и более близкие проекты, которые работают уже сегодня. К примеру, это фича Instant View в Телеграмме. Люди уже написали множество парсеров, которые обходят известные сайты и парсят только чистый контент. И когда кто-то постит ссылку на такой сайт в Телеграме, то появляется заветная кнопочка Instant View. Если ее нажать, то прилетит только чистый контент, без рекламы и прочего мусора. На загрузку которого будет потрачего всего несколько килобайт трафика и памяти, а не мегабайты трафика и гигабайты памяти, как это было бы в случае браузера. Загрузка такого незначительного объема данных происходит мгновенно, отсюда и название фичи — Instant View. Если какой-то парсер ломается, то есть багтрекер и сообщество, готовое написать новый парсер, в чем поможет удобный редактор. Так что если кто-то не может поверить в возможность такой задумки, пока сам не увидит своими глазами — добро пожаловать.

Правда наша задача будет немного сложнее, так как кроме отображения текста статей, нам надо отображать и ленты со статьями, осуществлять навигацию по разделам сайта (статьи, форум и магазин — это все нельзя мешать в единую ленту). Надо не просто выцепить из страницы нужное, но и решить, по каким таблицам это разложить. К примеру, я очень люблю читать комментарии, а если будет вытащена только основная новость или статья — ценность ресурса для меня станет меньше. К примеру, раньше я смотрел Youtube через SkyTube и находил много нового и интересного в комментариях, но переключившись на NewPipe я остался без них. Этим же страдает такой набор парсеров как youtube-dl. И вот как разложить полученный контент по полочкам — это большой вопрос, не каждая домохозяйка сможет спроектировать структуру базы данных. Еще больший вопрос в том, как осуществлять навигацию по такому контенту. Что является основным, а что дочерним? Как-то много лет назад я уже написал универсальный парсер с эвристиками, так он вырезал основной контент, оставляя только комментарии, так как считал, что комментарии — это основное.

Еще сложнее понять, что же делать с полученными данными, как их отображать. В голову тут приходят только существующие методы: HTML-темплейтеры, PHP и SQL. И если уже делают браузеры на NodeJS, почему бы для одной из фич не добавить в браузер еще и PHP? Я не являюсь фанатом этого языка, но порог вхождения в него минимальный, а где нельзя будет обойтись какими-то простыми шаблонами, люди смогут программировать на нем (или любом другом языке, см.ниже). Чем-то такая генерация страниц мне напоминает древний Aport Express — маленькую программу от поисковика Апорт, которая занималась тем, что темплейтила поисковую выдачу прямо на клиенте, снижая трафик на используемом тогда диалапе. Если кто-то хочет погрузиться в историю, то почитать можно на web.archive.org/web/20010124043000/http://www2.aport.ru:80/aexpress/, а скачать на web.archive.org/web/20040627182348/http://www.romangranovsky.narod.ru:80/aexpress.exe

Баннеры и трекеры

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

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

Решение очень простое: возможность указания «дружеских доменов» для сайта и отключение запросов ко всему остальному. Так можно резать рекламу при помощи Request Policy или аналога, что в отличии от AdBlock-образных резалок будет работать на практически каждом сайте, не потребует подписок и поможет даже в том случае, если сайт был взломан и на нем размещена связка с вредоносным кодом.

Я там слышу вопли о том, что резка рекламы снижает доход авторов? Не забывайте, что за показ баннеров давно никто не платит. Показывать _мне_ рекламу бессмысленно, это лишь тратит мой трафик и трафик сервера, но не принесет авторам ни копейки. Зато может лишь разозлить меня. В свое время я писал набор утилит для особо-отличившихся сайтов.

Если же смириться со сбором/утечкой персональных данных, а пользователь при этом достаточно зол, то я бы порекомендовал поставить что-то вроде замечательного расширения AdNauseam. Наверное единственное расширение для блокировки рекламы, которое было забанено гуглем. Суть работы этого расширения очень проста: оно кликает на каждый блокируемый элемент в скрытом режиме, т.е. не отображая пользователю ничего. Рекламщики же получают свои долгожданные клики, все как они хотели. И если кликать на каждый баннер, то утекаемые персональные данные будут перемешаны с кучей мусора, так как не будут соответствовать реальным предпочтениям пользователя. Таргетинг и слежка становятся бесполезными. Очень хорошее расширение. И гениальная задумка.

Реклама (таргет-профиль)

Осуждаешь? Предлагай! Да, я осуждаю практику сбора таргетированных данных, особенно при помощи слежки и тому подобных нехороших (для меня) приемов. Почему бы не указать таргетинговые данные прямо в браузере? Я сам все о себе расскажу, не надо никакой слежки и вирусов:

Пол: мужской
Возраст: 55 лет
Образование: среднее-специальное
Увлечения: fisting, bdsm, shemale, chastity devices, gasmask breath control
Место жительства: Klyuchi (a settlement) in Ust-Kamchatsky District of Kamchatka Krai
Последний чек в магазине: 28 рублей (батон хлеба)
Финансовое состояние: денег нет, живу на пособие и личным огородом
Отношение к фримиум-продуктам: пишу негативные отзывы о них, ставлю колы
Профиль в социальных сетях: нет и не будет
Кредитная карта: нет и не будет

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

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

Еще бы я хотел механизм пользовательских оценок для просочившейся рекламы. К примеру, открываю я ролик на Youtube, канал моего любимого Креосана, а в какой-то момент сам Креосан начинает рассказывать о каких-то там казино. Я бы с радостью выделил область с рекламой и отпостил данные об этой области как «рекламные», чтобы потом, другие пользователи могли легко пропустить такую рекламу. Иногда реклама встречается в тексте самих статей, да и статьи в целом бывают замаскированной рекламой. Мне очень неприятно читать такие статьи, потому я их с радостью бы пометил как «реклама».

Встроенная поддержка прокси-листов/VPN

К сожалению, некоторые глупые люди решают за меня, могу ли я пользоваться тем или иным сервисом, причем делают это на основе того, в какой стране я родился/живу. Да и не только сайты (грустный взгляд в сторону Google Play). К примеру, использовать Spotify я могу только в том случае, если живу в USA, а вот сервис Advcash я могу использовать в том случает, если я НЕ живу в USA. Конечно, если тебе не повезло при рождении, то не обязятельно прозябать в отсталой стране, в теории можно уехать в нужную страну, а вот как жить в 2-х странах одновременно — я пока не знаю.

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

Почему бы не купить нормальный VPN и не пользоваться им, зачем тащить это все в браузер? Затем, что только браузер может отделить один сайт от другого, разделяя каждую вкладку. Если же мы роутим весь трафик через системный VPN, то нам нужно будет постоянно переключаться, а то порой ловить дисконнекты и баны, если мы забудем это сделать.

Плагины

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

А еще я не хочу придумывать и вводить логины/пароли на каждом сайте, вместо этого я бы хотел указать какой-то случайный Seed, от которого бы генерились как логины, так и пароли для конкретного сайта. К примеру, я указываю строчку «soMeRanDOooo0MStr11nng» и при заходе на сайт example.com эти 2 строчки конкатенируются и создают UID, на основе которого можно сгенерить что угодно, в том числе логины/пароли (а еще лучше, всю оставшуюся анкетную информацию, чтобы можно было регистрироваться в один клик и не думать, какие еще есть имена кроме Сергея без использования fakenamegenerator). И возможность шарить эти пароли на bugmenot. Кстати, такой генератор уже есть в Safari!

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

Браузерные части как сервисы

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

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

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

Браузер по частям

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

Работу с сетью тоже можно вынести в отдельный демон. Рядом можно вынести днс-ресолвер со встроенным блеклистом доменов и автообновлением списков блеклистов, подсистему кеширования контента и кучу всего еще. Даже рендеринг можно вынести в отдельный процесс, как это было в Opera Mini (и что можно провернуть, использовав слитые исходники, так как напрямую этот код в проект даже не попадет, а будет сторонним «плагином», то и лицензионная чистота тоже сохраняется). github.com/browsh-org/browsh — тут движком фурефокса рендерят где-нибудь на впске, а уже отрендеренное отправляется тебе в виде текста и текстовой псевдографики — выглядит очень классно, даже видео можно смотреть

На первых порах все это можно реализовать как независимые микросервисы, причем один разработчик может писать на java, другой на python, а третий на Ruby и им не надо ссориться, выбирая стек технологий. Ведь всем знакома ситуация, что кто-то не может представить браузер на Java из-за тормозов, кто-то боиться Сишку из-за боязни уязвимостей, а кто-то хочет попробовать модный Go и агитирует за него? Здесь каждый сможет выбрать для себя небольшую часть и отвечать строго за нее, договариваться надо будет только о коммуникационном протоколе. И если какие-то части будут плохо работать, то их в конечном итоге можно будет просто заменить. Или взять и адаптировать уже существующие решения для более тесной интеграции, как это было сделано в браузере Arachne.

Даже рендерер можно выполнять в отдельном процессе и передавать лишь информацию для отображения. На первых порах можно просто взять существующий код из w3m/links/netsurf, потом желающие могут приделать переключаемые режимы из Gecko/Servo/Blink.

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

И конечно же, здесь можно следовать старому принципу: пусть каждая программа делает 1 своё дело, но делает его хорошо. Браузер — это очень сложный комплекс программ, работающих с сетью, а отсюда и сложность всей системы в целом. Так может быть просто разделить наш браузер на максимальное количество частей, обеспечивая качество и надежность каждой из них?

Плагины как гарантированные функции

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

К примеру, вы помните в IE6 такую непонятнкую кнопочку как Discuss? Она появлялась после установки MS-офиса, практически никогда не работала, так как для ее работы был нужен серверный SharePoint. А ведь штука была отличная: при ее нажатии открывался тулбарчик, через который можно было добавлять комментарии к странице, был еще какой-то древовидный чатик (хотя я уже плохо помню все это, а нагуглить не смог), причем работало это с любой страницей. Только представте: комментарии на любом сайте, без модерации авторов, где смело и прямо в лицо можно высказать о любом сайте все то, что ты думаешь. Я считаю, что такой плагин просто обязан был в комплекте нашего браузера.

Другой пример: многие сайты открывают на страничке «схема проезда» карты гугла или яндекса, причем это считается хорошей практикой, никто даже не задается вопросами приватности и уж тем более не спрашивает пользователя о том, хочу ли я, чтобы сторонняя организация знала, какие объекты в городе меня интересуют? Такие элементы можно вырезать и заменять на карты OSM или даже карты локального репозитория. Никто не мешает скачать полный дамп OSM и сделать локальные карты, один-два гигабайта на диске сегодня почти ничего не значат.

Итоги

Здесь представлено мое видение идеального браузера. Конечно, написано далеко не про все: не затронуты темы репликации, многоуровневых форм и защиты пользовательских данных, нету ничего о бизнес-модели или путях привлечения спонсоров для реализации проекта. А спонсоры нужны, ведь бесплатно делать такой объем работ мало кто доведет до чего-то юзабельного. Не описано и о том, как защититься от интересов спонсора, ведь на выходе мы можем получить очередной Firefox с плагинами телеметрии, сообщающими о отключении телеметрии.

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

Этот текст доступен под лицензией Public Domain и вы можете свободно его распространять где угодно. Быть может, таким образом мы (люди в целом) сможем получить браузер, которым хоть немного удобнее пользоваться.
Теги:
Хабы:
Всего голосов 78: ↑54 и ↓24+30
Комментарии154

Публикации

Истории

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань