Да, сотрудничают. Их доменные имена палятся в java-скриптах.
Некоторые даже сами промышляют такими "плагинами" к браузерам и "левыми" доменами-прокладками.
Судя по более чем 5-летнему опыту - не будет.
Вы не нарушаете их лицензии на использование Я-карт.
У всех - ненормально. Только мужики пока ещё не знают.
Сегодня в логах сайта обнаружены запросы с IP: 62.210.75.170
PS: http:// creditstat.ru МНОЙ вставлен пробел, чтобы не делать ссылку на вредителя
Вырезать можно прямо Апачем, регуляркой по SetEnvIfNoCase
У дорвеев по определению трафика должно быть больше. Иначе он не окупится за свой короткий срок.
А вот, почему метрика работает на "левом" домене - непонятно.
Да. Или разрешить картинки отовсюду img-src *;(через них редко ломают), или явно указать data: img-src 'self' data:*;
Можете поиграться с CSP online tools, они правильные директивы генерят.
Своим, я ещё ЮзерАгента в репорты пишу и Remote IP.
Но фишка - та же: надо лезть через 'php://input', тк имя параметра не присылается - массивы-обёртки php не заполняет.
Похоже, поможет. Они потом рекламу отдельным скриптом тянут. Но в следующих версиях - могут исправится, почитав этот топик.
Даже с разрешённым eval режет кучу непонятно откуда взявшегося мусора:
http:// cdncache-a.akamaihd.net/i/items/z7b85/js/z7b85.js
http:// p.display-trk.com
http:// www. superfish.com/ws/slideup2/main.js?ver=2014.9.25.NaN.1
http:// www. superfish.com/ws/getSupportedSitesJSON.action?ver=14.08.31.1&callback=SF_isURISupported
http:// c.imrk.net
http:// c.imrk.net/tag/1.js
http:// rjs.mzcdn.com/v3/app.js
http:// rjs.mzcdn.com/v3/loader.js?16340&appid=63&subid=@@@
http:// rjs.mzcdn.com/v3/actions/_adult.js
http:// spk2pk.ru
http:// xlrngostyn.ru
http:// ttz.people-are-thought.info
http:// gamblespot.ru
Несколько страниц ранее давали код для htaccess(я не пробовала, тк работаю через php):
Да, у меня опечатка, ") - лишние, они остались от php-шой функции header("...").
Обязательно подключайте.
Если хотите, могу скинуть вам в личку php-код для приёма таких репортов - он немного "неординарный", тк массивы-обертки $GET_, $_POST и $_FILES - пустые, и json из них не получить.
В репортах есть один идеологический "косяк" - на онлайн-скрипты и на попытку вызова eval() репорт показывает одинаковую и совершенно неинформативную диагностику, не позволяющую найти причину - пустой blocked-uri:
Это сильно затрудняет отладку. Видно только, что Директ путался запустить eval() (ибо инлайн-скрипты у меня разрешены в CSP). Но был заблокирован, пока непонятно за что.
Тс-с-с-с...
Думаю, вы правильно думаете :) Но надо проверить.
Все делается просто - в CSP штатно предусмотрен отладочный режим
Сначала ставите на сайт CSP-заголовок с добавкой -Report-Only, он включает CSP, но ничего не запрещает, а только шлёт диагностику вам на сервер по указанному в report-uri скрипту:
Настраиваете скрипт csp.php на приём json-объектов, которые браузеры будут слать методом POST, см http://www.w3.org/TR/CSP/#report-uri. Их надо писать в "файл репортов".
Далее - прописываете в заголовок CSP желаемые правила и домены "белого списка"(это мой отладочный пример для Я и G карт, метрики и Директа с Адсенсом, инлайн скпипты - разрешены, тк пока не могу быстро убрать их в файл):
и смотрите, в "файле репортов" что браузеры запретили из того, что надо разрешить. Вносите поправки в свой "белый список".
Если после тестирования пару дней ничего заблокированного из "нужного" в "репортах" не появилось - убираете от CSP-заголовка добавку -Report-Only, и Content Secure Police начинает работать. Репорты в файл будут продолжать писаться, его надо периодически чекать.
PS: Под все браузеры надо давать 3 заголовка "Content-Security-Policy", на PHP это делается так:
Неплохо убрать Метрику и коды Директ/адсенс в отдельный js-файл и полключать его через <script src='/metrics.js' type='text/javascript'></script>. Тогда CSP не будет блокировать запускаемое из этого файла.
Таких "умников" много развелось в последнее время.
Вот только что CSP отловил на сайте "свежачок": fluxx.crazytall.com, с мая 2014 начал "светиться".
