Comments 82
По-умолчанию этого точно не будет. Возможно, что нужно будет в заголовке или где-то еще отправлять параметры для включения этой опции. Если она не включена, то будет в консоли крик об этом…
И вообще, кому надо, тот будет отправлять и так всю инфу в дополнительных параметрах запроса. Так что отключение юзер-агента ничем особо не спасет.
Их недавние манипуляции с SameSite cookies уже навели шороху, потому что обратной совместимости там нет и как раз за счет UA надо определять можно ли указывать SameSite. А теперь давайте UA отменим, почему бы и нет :)
Но попытка дать такой инструмент пользователю ни к чему не приведет — пользователь увидит глючный сайт, отключит настройку и продолжит работать.
Ещё это может решить провайдер. На медленном интернете у меня некоторые страницы хабра просто вылитали в таймаут: "Ошибка при установке защищённого соединения". Хотя это странная ошибка при условии что часть страницы уже была показана.
Это не странно, учитывая, что хабр качается кучу медиа с разных ресурсов… откройте водопад с загрузкой страницы
По моим наблюдениям не успевает догрузится имено страница. Браузер умеет отображать HTML страницу по мере загрузки а заодно и запрашивает изображения и остальные ресурсы. Поскольку эти ресурсы находятся на других хостах браузер открывает к ним отдельный канал и загружает их параллельно со страницей что ещё больше замедляет её загрузку. В результате через некоторое срабатывает таймаут и соединение сбрасывается.
Страница по ссылке, которую вам дали 14.5МБ (без ресурсов — 5.5).
Какой лимит вы предлагаете сделать (и можно ли будет после этого на хабр зайти ^_^)?
Какой лимит вы предлагаете сделать (и можно ли будет после этого на хабр зайти ^_^)?
Это, на самом деле не важно. Вам сейчас кажется, что страница на несколько мегабайт — это нормально? А если бы я Вам рассказал про страницу в 14 МБ в 2000-м году, Вы бы покрутили пальцем у виска. Значит или что-то в этой странице есть такое, что в 2000-м было невозможно впринципе, или есть куда худеть. Ну давайте закрепим 10МБ. А можно и 100 МБ. Только давайте в будущем не будем менять этот лимит, когда неперывно растущий ароматный компост из новомодных фреймворков перестанет влезать и в эти пределы.
Вам сейчас кажется, что страница на несколько мегабайт — это нормально?Нет, не кажется.
Это уже много для практически пустой страницы, но тут уж я ничем не помогу: это вопрос к команде ресурса.
Другой вопрос что за альтернативу они предлагают… это ведь не совсем понятно, в статье вообще ни слова. Так же не совсем понятно с разработчиками, они что против менеджеров восстание что ли подняли…
Со всех настольных компьютеров строка будет выглядеть следующим образом, независимо от устройства и версии браузера
Windows NT 10.0; Win64; x64
То есть десктопные линуксы теперь вообще со статистики исчезнут?
Вот с указание браузера много где надо, потому что юзеру нужно иногда вывести какие-то инструкции, учесть поведение браузера в разных ситуациях, учесть баги браузера, да хоть даже шорткаты учесть, чтобы не перебить дефолтные или не сделать неудобный шорткат. Всё это потому что юзер при использовании браузера не только смотрит страницы, но и взаимодействует с браузером, и в разных браузерах это взаимодействие отличается. Если бы лишили возможности смотреть браузер, было бы действительно обидно.
Для client hints же JavaScript нуженНет. В первую очередь, Client Hints — это заголовки.
Также предполагается какой-то доступ из JS.
В один запрос без JS, вероятно, нельзя, как минимум потому что как за один запрос браузер сможет узнать, что Вам нужна эта информация? Это технически невозможно.
Запрашивать в предварительном OPTIONS / HEAD запроосе, например? Технически это будет два запроса конечно, но контент будет отдаваться только при последующем GET / POST запросе
Ну доки же есть, я не видел никакого упоминания OPTIONS / HEAD, т. е. как я понимаю, запрашивать нужно в обычном GET / POST запросе.
Я допускаю, что разраб если очень захочет получить в один запрос, он сможет на своей стороне придумать какой-то хитрый редирект при первом открытии сайта. Таким образом, браузер на самом деле пошлёт 2 запроса, но для пользователя это будет выглядеть как один. Разумеется при этом:
- Сайт станет открываться медленнее.
- Обязательно нужно озаботиться об отсутствие бесконечного редиректа, т. к. браузер не обязан отдавать по запросу нужные заголовки, и определять по ним необходимость редиректа ни в коем случае нельзя. Вместо этого можно поюзать:
- Сохранение второго ответа по IP:
- Если Вы запросили данные, но ответ ещё не пришёл, не допускать редирект для этого IP.
- Если пришёл ответ хотя бы с одним запрошенным заголовком, разрешить редирект для этого IP в том случае, если заголовок станет отсутствовать.
- Если пришёл ответ без любого из запрошенных заголовков, больше не допускать редирект для этого IP.
- Редирект на GET со специальным параметром, содержащим специальную временную строку (уникальную для каждого пользователя), при наличии которой редирект не осуществляется. Строка может действовать сутки и только для этого IP (для других рассматривается как отсутствие строки).
- Можно также вместо редиректа попытаться поюзать обновление страницы. Уникальную строку здесь уже правда применить не получится.
- Сохранение второго ответа по IP:
Но в любом случае, предложенную мной схему редиректа я крайне не рекомендую. Используйте её только если у вас говносайт.
Также ни в коем случае не используйте её, если не имеете глубокого понимания работы браузеров, редиректов, Client Hints и HTML — сильно вряд ли, что Вы сможете сделать правильно. Не используйте мою инструкцию, если не имеете глубокого понимания каждого её пункта. Эта не та инструкция, по которой можно сделать в тупую по шагам без понимания вопроса.
При этом ещё одна причина не использовать её — она Вам не нужна. Отдайте пользователям одинаковый HTML, а если нужно настроить отображение или отдельные элементы, настройте их Javascript'ом и стилями уже после загрузки страницы. Это позволит не только быстрее её загрузить и избежать ошибок, но и в целом намного правильнее: не надо отдавать разный HTML людям, если это не динамический сайт. Причём если Вы настраиваете стилями, обычно можно вообще обойтись без Client Hints, используя вместо этого CSS Media Queries.
Раньше я ставил awstats, который парсил логи nginx'а и генерировал какую-то там статистику. А сейчас как надо?
Вы не совсем это спросили, но у Basecamp есть неприятный ответ, который мне понравился: никак.
When I’ve raised this concern in conversations with people in the marketing industry, a lot of them have taken offense to the term “spy pixels”. Affixing the spying label made a lot of them uncomfortable, because they were just trying to help! I get that nobody wants to think of themselves as the bad guy (Eilish not withstanding), but using the word “spy” isn’t exactly a reach.
m.signalvnoise.com/mailing-list-software-should-stop-spying-on-subscribers
В конкретно этой статье они предлагают отказаться от трекинга статистики открытий почты, несмотря на то, что это сделает нашу работу сложнее: А/Б тесты, детальные статистики по браузерам, и тд. Предлагают, потому что осуждают «слежку» в интернете.
Мой вариант ответа вам: возможно, вам не нужны эти данные, пускай они остаются у пользователя? Да, станет сложнее вытаскивать статистику и делать выводы, но и да, если вам действительно нужно, то есть способы эту статистику собрать. Но бесплатной слежки не останется.
Сайт моего опенсорс-проекта. Из-под каких ОС на него заходят? То есть, каким ОС лучше уделить внимание?
Последнее зачем ?
IP с GeoIP НИЧЕГО не говорит о том, откуда пришел человек. Может он с VPN выходит. Или GeoIP просто у вас устаревшая база
Я уж не говорю — всратый мегафон меня всегда с питерского (якобы) айпи выпускает, даже если я в Москве.
Писать в соответствии со стандартами, конечно, нужно, но этого недостаточно. Надо ещё чтобы а) эти стандарты неукоснительно соблюдались браузерами — причём всеми браузерами, и б) чтобы стандарты не развивались, а были замороженными раз и навсегда. И то, и другое, очевидно, в нашем мире невозможно.
С ростом популярности JavaScript большинство разработчиков начали использовать библиотеки вроде Modernizer, которые определяют конкретный список функций HTML, CSS и JavaScript, которые поддерживает конкретный браузер, обеспечивая гораздо более точные результаты, чем user-agent.
1. Как сервер узнает, что надо отдавать клиенту? Может, там какой-нибудь IE6, в котором этот Modernizer даже не запустится. А узнав старого клиента по UA мы могли бы сразу послать туда Lite-версию сайта, без плюшек, но работающую.
2. Как быть, если у клиента отключён JS?
2. Как быть, если у клиента отключён JS?
Поступить как 90% сайтов — отдать белую страницу… С NoScript не знаю ни одного сайта, который хотя бы показал контент верно, как минимум везде едет форматирование, хотя, казалось бы, при чём тут оно и JS…
да все уже… доигрались… нет браузера другого, чем пророк единого Хрома… ну, и сафари на заднем плане маячит
Вместо этого Chrome предложит новый API под названием Client Hints,
Всё просто, механизм идентификации который все научились обходить — уберут.
Вкрячат что-то свое, закрытое и пропиетарное в три слоя, что остальным просто так обходить не получится.
"Chrome"; v="73"
"Chrome"; v="73", "Chromium"; v="73"
"Chromium"; v="73", "adiogjaeiughjsiudgvbiaf_nonexistingBrowser"; v="999"
99,9% страниц прекрасно работают на всех десктопных браузерах без каких-либо изменений.Во-первых (даже если забыть, что 99,9% статистических данных в интернете берутся с потолка), не на всех, а только на современных. Есть немало пользователей устареших браузеров, и не все разработчики готовы выбросить таких пользователей на помойку. Во-вторых, браузинг со смартфонов сейчас занимает чуть ли не половину трафика, и ограничиваться только десктопами не комильфо. В-третьих, часть этих «прекрасно работающих без всяких изменений» могут прекрасно работать именно благодаря тому, что смогли определить браузер и адаптировать под него своё поведение.
Незнаю насколько это критично но: Недавно обнаружил что Firefox в XSLT match может использовать переменные а Chrome нет(ошибка копиляции). Так же для Chrome надо URL кодировать пути в xsl:import и document.
Можно конечно поумолчанию подстраиваться под Chrome. Firefox это примет. Но в случае xsl:import и document это делает код менее понятным.
del
Ну и дела, теперь помимо согласия с куками и отказа от уведомлений надо будет ещё дать разрешение прочитать user-agent через client hints. Всё сложнее и сложнее до контента добраться.
«По UA выполняется фингерпринтинг, давайте откажемся от UA, и заюзаем Client Hints».
А что поменяется-то? Те, кто фингерпринтят по UA, дружно заплачут, и не станут использовать Client Hints?
- UA string замораживается
- так же замораживаются navigator.appVersion, navigator.platform, navigator.productSub, navigator.vendor, navigator.userAgent (доступ из JS)
- тут бритва Оккама отказала, и пошла дичь: браузеры должны ввести поддержку ua-client-hints
- эта же дичь протекает и в JS
И только на последнем шаге описывается, чем же с точки зрения поведения это может отличаться: «браузер может решать, кому и в каком количестве отдавать эту информацию; например, 'топ-сайтам' или сайтам, которые пользователь посещает часто, можно отдавать более детализированную информацию, чем сторонним сайтам; и можно даже спросить у разрешение у пользователя, если мы решим, что это несильно его раздражит» («User agents can make intelligent decisions about what to reveal in each of these attributes. Top-level sites a user visits frequently (or installs!) might get more granular data than cross-origin, nested sites, for example. We could conceivably even inject a permission prompt between the site's request and the Promise's resolution, if we decided that was a reasonable approach.»)
А теперь вопрос:
Хотите, чтобы браузер принимал решения, кому отдавать полную информацию, а кому частичную — давайте это обсуждать. Будет принято решение, что части сайтов надо информацию «обрезать» — обрезайте UA string. Зачем способ передачи этой информации менять-то?
Просто отрасль айти, в которой основной целью было сделать удобнее, веселее или прикольнее, сменилась отраслью айти, в которой целью является освоить бюджет, отожрать кусок покрупнее и побрить лохозавров — а вместе с тем пришла и имитация бурной деятельности, и ящик в полтора гига фреймворков для макак с клавиатурами, которые кроме сайтов ничего писать не научились, а заказчику внезапно захотелось сделать десктопненько.
Так что привыкайте.
Руководство Google подчинённым: «Надо увеличить долю браузера Chrome»
Подчинённые: «За попу возьмут антимонопольные службы»
Руководство: «Придумайте что-нибудь, как обычно под лозунгом спасения человечества».
В итоге.
Теперь количество браузеров посчитать невозможно, у всех будет одинаковый юзерагент. Долю браузера хром можно доводить до 100%. Попутно сильнее вставляя палки в колёса конкурентам на своих сервисах.
Хотя, по большому счёту, сейчас уже куда не плюнь в клиентское ПО, везде возможность подмены User-Agent-а активно используется, так что смысла в разном поведении сервера уже нет. Собственно, и попадаются реагирующие на User-Agent сервера довольно редко, и основная идея у них не «предоставить разный контент», а «навредить неугодным User-Agent», зачем — непонятно.
Суть предлагаемого Client Hints не ясна. Для пользователя особого смысла нет, и подмена Client Hints при необходимости ничем не отличается от подмены User-Agent.
Google убирает из браузера Chrome строку 'user-agent'