Яндекс.Метрика — Счётчики перестали работать (полный ноль без https)

ЛОР похож на багтрекер Яндекса? :)

Parental Controls restricts access to secure websites

лол

Тебе ж родители запретили, зочем ты лезешь?

С разморозкой. xml.yandex так уже пару месяцев минимум делает

А можно что-то подобное с газовым счётчиком провернуть?

Ну так мне на BXR.SU не запрещали, а на mc.yandex.ru я сам-то вообще не хожу! Мамочка, это вирус?

ЯННП, на моих сайтах все нормально считает, просадки не видно.

Ну так это разные вещи — в xml.yandex идёт аутентификация, TLS нужен для секурности, ну и вообще, там разве раньше без https работало?

А здесь они просто напросто отрубили считалку для X процента пользователей, да ещё и несанкционированные всплывающие окна отдают. Такое поведение ну ни в какие ворота не лезет.

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

Ну уж не знаю, как ты не заметил. Может аудитория разная?

А я вот заметил просадку где-то месяц или два назад.

Сам счётчик вон, например, из OpenBSD вообще теперь не грузится:

% curl -L -v http://mc.yandex.ru/watch/21237232 ; uname -rms
* About to connect() to mc.yandex.ru port 80 (#0)
*   Trying 93.158.134.119...
* connected
* Connected to mc.yandex.ru (93.158.134.119) port 80 (#0)
> GET /watch/21237232 HTTP/1.1
> User-Agent: curl/7.26.0
> Host: mc.yandex.ru
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.8.0
< Date: Sat, 05 Dec 2015 12:47:38 GMT
< Content-Type: text/html
< Content-Length: 184
< Connection: keep-alive
< Location: https://mc.yandex.ru/watch/21237232
<
* Ignoring the response-body
* Connection #0 to host mc.yandex.ru left intact
* Issue another request to this URL: 'https://mc.yandex.ru/watch/21237232'
* About to connect() to mc.yandex.ru port 443 (#1)
*   Trying 87.250.250.119...
* connected
* Connected to mc.yandex.ru (87.250.250.119) port 443 (#1)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection #1
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
* Closing connection #0
OpenBSD 5.2 amd64
%

Это да, я тоже так чувствую. Просто лень везде менять. Пытался несколько раз обращаться в суппорт, но они вообще прикидываются, что проблемы даже не понимают. Мол, счётчики пользователи иногда блокируют. WTF?

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

Неужели и правда всем всё безразлично?

Ведь теперь у всех пользователей в Казахстане, например, тоже будет всё всплывать, т.к. В Казахстане аннулировали шифрование АО «Казахтелеком» информирует www.linux.org.ru/forum/talks/12167454 www.linux.org.ru/forum/talks/12167947 и т.д.

Я вот тут ответил: https://medium.com/@ivlad/почему-яндекс-метрика-стала-https-only-581b9286c7bb...

Т.е., вы просто не хотите, чтобы можно было сменить DNS у пользователя, и с минимальными затратами запускать любой JavaScript на любых сайтах рунета?

ИМХО, здесь проблема громоздких счётчиков, а не https. Mail.ru (бывший top.list.ru) выдаёт счётчики с простейшим JavaScript для учёта HTTP_REFERER и разрешения экрана, и никаких внешних скриптов, а вся остальная статистика, которую можно собирать исключительно с JavaScript, для многих всё равно особого интереса не представляет. Они по определению не подвержены вашей уязвимости, так как внешнего JavaScript'а у них таким образом нет.

Так что long-term нужно делать не принудительный https, а опциональную подгрузку внешнего громоздкого JS, возможно с обязательным https и с отдельного хоста. А сам пиксель счётчика оставить типа «//mc.yandex.ru/watch/21237232» — по желанию.

Для меня проблема в том, что из-за принудительного gif'а по https, некоторые пользователи теперь конкретно на моих сайтах получают навязчивые popup сообщения об ошибках, конкретно на OS X как указано выше. Т.е. из-за Яндекса, мне конкретно теперь нужно встать с дивана, и удалить ваш (вредоносный) код, который лично у меня вообще никакого JavaScript'а не содержит:

 title="Served by OpenGrok"><span id="fti"></span></a></p>
<div><img src="//mc.yandex.ru/watch/21237232" style="position:absolute; left:-9999px;" alt="" /></div>
<p>Indexes created Wed Dec 16 03:56:26 PST 2015</p></div>

А в Android 4.2 Browser, например, есть такой баг, что при проблемах сертификата одного из элементов, выдаётся всплывающее окно о сертификате, и если в нём не нажать Continue (например, игнорировать, и перевести фокус обратно на страницу), то браузер автоматически переходит на предыдущую страницу. Мой сайт на моём девайсе в данный момент не подвержен данной проблеме, но кто знает, что будет с завтрашним сертификатом, или на другом чуть устаревшим девайсе?

Хотелось бы видеть отмены https для подгрузки изображений счётчика без JS (как у меня), и введения легкой версии счётчика JavaScript, которая не загружает никакого стороннего JS. Технически, в данной ситуации и с вашей позиции, придётся в определённое время изменить исходный код из-за HSTS, так как Yandex.Metrica не предусмотрела отдельного хоста для самого изображения пикселя.

Предлагаю отменить https при запросе gif'ов, и ввести отдельный новый хост http для продолжения gif'ов, дабы избежать проблем с потерей учёта посетителей по http из-за HSTS в будушем.

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

Я не могу говорить за Яндекс, я там больше не работаю, но, думаю, что

Предлагаю отменить https при запросе gif'ов, и ввести отдельный новый хост http для продолжения gif'ов, дабы избежать проблем с потерей учёта посетителей по http из-за HSTS в будущем.

это предложение расходится со стратегией всех крупных сайтов быть полностью https-only на всех своих доменах.

Представь, как бы ты сам чувствовал, если на твоём сайте в библиотеке тебе бы выдавались постоянные ошибки как выше, при том, что сам сайт у тебя специально является справочным ресурсом, и доступен по http, конкретно для избежания подобных проблем?

Как я написал в блоге, в свое время измерили penalty по тотальному https и оно было признано незначительным по сравнению с теми рисками, которые этот тотальный https предотвращает. Например, не нужно забывать, что некоторые пользователи (их много, десятки миллионов) аутентифицированы в Яндексе и куки для домена yandex.ru могут передаваться открытым текстом в случае обращения к mc.yandex.ru.

В противном случае, я останусь очень недоволен данной ситуацией, и никогда больше не буду использовать такую ненадёжную штуку, как Yandex.Metrica.

Мне искренне жаль. Напомню, что Google уже объявлял, что Google Analytics будет https-only, но я не следил, сделали они это уже, или нет.

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

аутентифицированы в Яндексе и куки для домена yandex.ru могут передаваться открытым текстом в случае обращения к mc.yandex.ru

Ну, блин, тоже мне! Т.е. вы сами хотите до сих пор использовать http, а мне навязываете https? Кто мешает выдавать куки secure, или использовать отдельный домен, как это делает Google-Analytics?

Если https:// так хорош и безпроблемен, почему и yandex, и google, до сих пор можно использовать по «устаревшему» http://?

Google уже объявлял, что Google Analytics будет https-only, но я не следил, сделали они это уже, или нет.

Нет, всё до сих пор работает.

% curl --head http://www.google-analytics.com/ga.js
HTTP/1.1 200 OK
Date: Thu, 17 Dec 2015 03:47:23 GMT
Expires: Thu, 17 Dec 2015 05:47:23 GMT
Last-Modified: Thu, 05 Nov 2015 22:24:16 GMT
X-Content-Type-Options: nosniff
Content-Type: text/javascript
Vary: Accept-Encoding
Server: Golfe2
Cache-Control: public, max-age=7200
Age: 1630
Transfer-Encoding: chunked
Accept-Ranges: none

%

Дополнительно, у них весь API cчётчика открытый: https://developers.google.com/analytics/devguides/collection/protocol/v1/para..., т.е. мало того, что, получается, можно скорее всего их собственный код просто самому себе на сайт залить, и сделать code review, но и использовать GA с более простым кодом счётчика, как на Mail.ru, например. Т.е. они уже предоставляют массу вариантов защиты от атаки.

Ни про какой переход на https я ничего не слышал, и на сайте такого не указано. Более того, это может вызвать многочисленные проблемы на embedded devices, так что очень сомневаюсь, что они будут отключать пиксели по http. Чего и Яндексу рекомендую.

В этой конкретно ситуации я считаю, что проблема находится на стороне браузеров, которые в XXI веке не понимают https — по технологическим или по политическим причинам.

Я привёл личный пример, где лично мне был запрешён https на публичном компе. PHK говорит, что это ситуация, между прочим, встречается очень часто:

http://queue.acm.org/detail.cfm?id=2716278

The so-called «multimedia business,» which amounts to about 30% of all traffic on the net, expresses no desire to be forced to spend resources on pointless encryption. There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on. Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at least three out of four of the major browsers, in order to force a particular political agenda. The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost.

И чем https поможет пользователем Казахстана? Раньше они могли банковские счета проверять без MitM, теперь — нет, всё из-за вездесущего https на каждом левом сайте. Или в ситуации enterprise, использование https — хороший способ несанкционированной передачи коммерческих тайн и секретной информации, распространению вирусов, так что им тоже приходится https либо полностью запрещать, либо ломать. И в чём тогда мне смысл, если мой сайт либо неоткрывается вообще, либо выдаёт ошибки? Яндекс и Гугл не хотят терять ни одного посетителя, а почему я для них должен с HSTS?

Например, мне очевидно, что объяснять выключение https защитой детей — это просто обман.

Это почему ещё так?

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

Чушь.

Считаю ли я, что должна быть возможность подписания/шифрования контента интернет ресурсов? Конечно, полностью за.

Нужно ли запрещать http://, или отказываться показывать весь неподписанный контент, для которого никакой аутенфикации пользовательских данных не требуется? Абсолютно нет.

Не вижу никакой необходимости ломать backwards compatibility, которая работала десятилетиями.

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

Если Казахстан хочет следить за тем, какой файл является более популярным на моём сайте, флаг им в руки!

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

Мою полную позицию по https:// можно почитать здесь: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0106.html.

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

Выкладывай на FTP.

FTP ни у кого уже не поддерживается, это вообще устаревший протокол, есть проблемы с NAT и firewall, например. Файлы нужно специально «качать» и сохранять на диск, и т.д.

Кстати, т.к. HSTS подразумевает автоматическую замену `http://` на `https://` для хоста (http://tools.ietf.org/html/rfc6797#section-8.3), то, собственно, зачем тогда вообще делать постоянный redirect из http в https? Ведь некоторые сайты всё же используют https сами, вот пусть через их счётчики и прописывается HSTS (для которого нужно установленное и корректное соединение https, http://tools.ietf.org/html/rfc6797#section-8.1), а у кого https не работает, те будут ходить по http. Получаем win/win — и хорошую защиту для активных пользователей с передовыми устройствами, и полную обратную совместимость для всех остальных.

Кстати, в документации написано, что даже нельзя пользователю давать опцию игнорировать ошибки. http://tools.ietf.org/html/rfc6797#section-12.1 Это так действительно везде сделано, или всё-таки разумность победила, и такого функционала защиты сайтов от пользователей реализовывать не стали?

Это так действительно везде сделано

Да. Прямо сегодня столкнулся - у меня на тестовом сервере несколько копий сайта запущено для отладки на разных портах. После того как один поставил HSTS с нормальными сертификатами, браузер на второй с самоподписными не захотел ходить. Пришлось сертификаты подкрутить.

Но вообще http должен помереть. То что кто-то хочет трафик снифить - не аргумент.

Но вообще http должен помереть. То что кто-то хочет трафик снифить - не аргумент.

С чего же это не аргумент? Аргументируй. HTTP нужен, и будет ещё очень долго жить.