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

Как Web Bundles навредят блокировщикам контента, инструментам для безопасности и открытому вебу

Время на прочтение 8 мин
Количество просмотров 5.8K
Всего голосов 15: ↑13 и ↓2 +11
Комментарии 39

Комментарии 39

Блин, придётся создавать ещё один Интернет, без Web Bundles.
Похоже, с этой технологией Интернет превратится в аналог телевидения. Для мартышек.

Когда ОНИ уже нажрутся?

Хотя для банков, например, или для государственных порталов такое решение было бы к месту.
Но и только.

А чем банки лучше, чем другие сайты? Вот, например, крупный кипрский банк. Зачем мне ютуб и гугланалитикс при работе с банком?


Ну так и пусть вводят этот стандарт для подобных организаций, интернет это не только банки.

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

Придём так к тому, что для банков и прочих «важных» игроков придётся отдельный девайс заводить-таскать-заряжать. Обслуживаемый по подписке…
Зачем мне ютуб и гугланалитикс при работе с банком?

Эм, так аналитика и не для вас (пользователя), а для разработчиков сайта. Претензии к fonts.googleapis.com у вас нет? Банк же тоже может сам шрифты хостать, а не использовать сторонние сервисы.

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

Ваш браузер на ваши деньги? Вы за него заплатили что ли? Не знал, что есть платные браузеры.


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

Я пользуюсь браузером на основании свободной лицензии mozilla public license. Я против использования моего оборудования и моего трафика (оплачиваемого мной) для сбора информации, на сбор которой с использованием моих ресурсов я согласия не давал. Согласие даётся посредством opt-in разрешения на определенные типы запросов. Разрешения нет — значит, я своего согласия не давал. Все просто, правда?

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

Давал. Я явно нажал send.


А вот на отправку данных в гугль и стопятьсот других доменов — не давал и давать не буду.



Расширение umatrix для FF, если кому интересно.

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

Да, можно было бы использовать такие языки. Только к сожалению ещё не разработали языки, которые на 100% предовращают рантайм ошибки.

Для отслеживания ошибок всё равно нет необходимости отправлять данные гуглу, достаточно было бы отправки обратно на сайт, в данном случае банка.
А разве сейчас это невозможно что всё необходимое для отображения страницы уже включено в html этой страницы?
И скрипты внутри тега script и стили внутри тега style и картинки и любые другие ресурсы в виде схемы data.
Только вот этим не спешат пользоваться.
насколько я понимаю тут дело в размере файла html. его стараются сделать минимальным, чтобы у пользователя быстрее на экране хоть что-то отображалось. а потом уже идет загрузка всего остального
Если я правильно понял статью, то ситуация будет та же. Браузер загружает весь бандл и только потом обращается к его ресурсам.

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

Добавьте в статью краткую плашку «какие конкретно проблемы собирается решить Bundles». Мне приходит в голову только отказ от тяжеловесной текстовой передачи данных, и решение, мягко выражаясь, странное.
НЛО прилетело и опубликовало эту надпись здесь

Как бандлы помогают или препятствуют блокировке рекламы?

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Проблемы возникнут. Server-side rendering для рекламы обсуждался (и обсуждается) в гугле давно. У него есть плюсы:


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

И минусы


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

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

НЛО прилетело и опубликовало эту надпись здесь

Не бандлы, а server-side rendering. Реклама в гугле запрашивается с доменов doubleclick.net и на нём рекламные куки пользователя сидят. Если мы перейдём на server-side то невозможно эти куки передать.

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

Как возможно передать? Пользователь открывает mysite.com, запрос ушёл на mysite.com сервер. Этому серверу нужно сделать запрос к серверам гугла, чтобы получить рекламу. Как при этом можно передать doubleclick.net куку в запросе?

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

Самый банальный вариант матчинга — сгенерировать для посетителя id, привязанный к сайту (сохранить в локальных куках или даже привязать к логину) и один раз загрузить картинку с домена doubleclick.net передав в url этот свой id посетителя.

И дальше при server-server запросах, передавать этот свой id посетителя, а doubleclick.net будет понимать, что это за пользователь.

Есть и менее тривиальные варианты.

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

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

На топовых сайтах например каких? nytimes и хабр не используют серверный рендеринг. А это весьма крупные сайты.

facebook, google, bing, yandex и т.д.

Доля mytimes, хабра и еще тысяч подобных сайтов, на рекламном рынке, ничтожна. Подавляющая часть денег у сайтов, типа тех, что я написал выше.
А как компоновка в bundle будет работать? А точнее на чем? На моём пк будет проходит сборка, или прямо сайт будет мне передавать готовый bundle?
В первом случае можно блокировать, например, хосты с рекламой.
Во втором случае можно будет «лОжить» такие сайты в качестве протеста(ха), ведь наверняка компоновка будет кушать процессорное время.

Скорее всего оно будет компоноваться заранее, на этапе сборки сайта, а вам будет приходить уже готовый запакованный архив (что-то вроде MHTML, только хуже). Повлиять на содержимое пакета у вас не будет возможности — скорее всего он будет подписываться или какое-нибудь DRM в него воткнут.

А если использовать проксю, и там уже модифицировать этот архив? Такое возможно?

Вряд ли — подпись совпадать не будет и браузер будет так же ругаться, как сейчас на незащищённое соединение. Ну и DRM-контент воспроизводиться не будет из-за битой подписи

Чем принципиально отличаются сценарии


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

Только то, что первые два сценария — это fire-n-forget, а для второго нужно немножко магии в трансляторе урлов?


И что мешает злому серверу отдавать криптомайнер под видом jquery или ещё какой-нибудь либы? Да он тупо склеит либу с вредоносной добавкой, вот и всё.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории