Во первых - вы говорите сейчас неправду, вы никогда не были в суде, по крайне мере по таким делам
Это реальная история конца 19-го года. Детали скинул в личку.
Не, информационный посредник, это как правило соц. сеть, или хостинг (на них тоже одно время наезжали по поводу авторских прав, если владельца сайта не найти), или что то типа этого, поисковики там же тоже, форумы вроде тоже, но там как повезет. Там такое размытое толкование - всегда по итогу решает суд.
А суд опирается на "экспертные заключения" и по итогу, чья сторона предоставила больше экспертиз, тот и выиграл. Меня так однажды назначили хостингом и обязали удалить контент, которого у меня никогда не было и услуг хостинга я никогда не предоставлял, но "эксперты" заявителя предоставили заключение, что раз имя сайта ресолвит IP, а в whois по данному IP указаны мои данные, то и хостинг однозначно я...
Поправил exif и получил статью 303 УК РФ
Не исключено, но я не об этом, а о том, что метаданные как аргумент подлинности фото уж больно хлипкий, практически на уровне ОБС
в свойствах фото прописано кто и когда
Которые за полминуты правятся в ExifTool?
Спасибо, как это можно сделать?
Поймите, готового рецепта нет. Это всё зависит от настроек вашего веб-сервера, ос и т.п. Наймите разово админа, для такой задачи работы немного.
Здесь вам дадут только рецепты, а не готовое блюдо, но если по шагам, то всё просто:
1) выделить в отдельный локейшин / access-лог.
2) найти самые назойливые ip а-ля
cat /var/log/nginx/example.com | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 10 1114 77.75.76.165 445 77.75.78.165 362 85.208.98.23 299 85.208.96.203 271 85.208.96.210 263 85.208.96.201 262 85.208.96.211 257 85.208.96.206 252 185.191.171.15 247 185.191.171.14
3) проверить, что это не полезные поисковые боты
# host 77.75.76.165165.76.75.77.in-addr.arpa domain name pointer fulltextrobot-77-75-76-165.seznam.cz.# host 85.208.96.210210.96.208.85.in-addr.arpa domain name pointer 210.bl.bot.semrush.com.
4) сделать для них отдельный map
5) для подпадающих под этот map задйствовтаь ngx_http_sub_module
дальше только зависит от полёта фантазии
Ну и, разумеется, всё это автоматизировать, а не делать руками :)
Раз я уже дважды упоминал ситуацию, то опишу её полностью.
Года 3 назад на своём en-сайте я разместил статью из Википедии. Статья была скопирована полностью без всяких правок, то есть включала элементы изображений, ссылки, логотипы и т.п. Так как я стараюсь соблюдать авторские права, то разместил отсылку на лицензию CC BY-SA 4 , ссылку на первоисточник и авторов. Был уверен, что ничего не нарушил.
Страница стала весьма популярной, на неё шло ну очень много трафика, каким-то макаром она даже влетела в рекомендуемый ответ гугла. А спустя несколько месяцев домен оказывается разделегированным. По определенным причинам у меня был утерян доступ к e-mail, который был указан на хостинге OVH и регистраторе Нэймчип. Восстановив доступ к почте, обнаруживаю, что на протяжении 14 дней и хостинг и регистратор шлют уведомления об абузе от Фонда Викимедиа о нарушении авторских прав (и права были достаточно основательно подтверждены ссылками/копиями документов, хотя и так понятно что лого Википедии явно принадлежит Викмедиа).
Списываюсь с Викимедиа (ещё не понимая до конца, что я мог нарушить). Выясняется, что по CC BY-SA 4 я могу копировать и видоизменять текст, а вот оставлять логотипы/плашки Викимедиа нельзя. Обещаю устранить в ближайшее время.
Боясь получить отключение сервера, созваниваюсь с ОВХ (спустя почти час добираюсь до ответственного за мою абузу) - сообщаю, что с заявителем связался и в ближайшее время устраню проблему. Получаю ответ в духе: "до решения суда, нам вообще пофиг будет ли устранена проблема, но нам важен факт реагирования на абузу - отразите это в кабинете"
Пишу в нэймчип, что по абузе ответил и уточняю за что меня отключили. Ответ - за неподтверждение e-mail, то есть не реагирование на e-mail в течении 14 дней они расценили как нарушение wdpr (домен в зоне gTLD). И теперь, раз я таки пишу с этого e-mail, они мне возобновляют делегирование.
Полностью восстанавливаю работу сайта, ничего ещё не устранив, но уже и не имея претензий ни от хостера, ни от регистратора.
Хэппи-энд: убираю логотипы, пишу в Викимедиа и даже получаю в ответ "спасибо за понимание". На всякий случай дублирую ответы Викимедиа хостеру и регистратору и получаю ещё два "спасибо".
В моем случае сайт именно парсится, а не отображается на чужом домене. Заменяются некоторые ссылки, рекламные блоки. Страниц на сайте более 50 тысяч, то есть парсят огромное количество, как можно это отследить?
Как пример, тогчто написал -= Serafim =-
Для начала проанализируйте частотность запросов per IP, выделите тех, кто обращается к динамике сайта чаще N запросов в час/минуту.
Что получится проверьте по whois или обратной зоне - очистите от поисковых ботов. Всех остальных в бан.
Глупости. Всё зависит от того, как составить жалобу. Если писать, что некий Вася с такого-то сайта тырит тексты, то ничего не будет. А если составить претензию юридическим языком, при этом в ответчиках указать саму хостинг компанию, т.к. стыренный текст находится на серверах, принадлежащих хостингу, и в случае неудаления пригрозить судом хостингу, то хостинг быстро начинает шевелиться, т.к. ему лишние проблемы не нужны.
Школошарашку напугаете, от нормального хостинга получите, что-то вроде (только размазанное на 10+ страниц):
---
Удаление запрашиваемых материалов невозможно до соответсвующего решения компетентного органа (суда и т.п.), так как, не обладая соответствующими правами ХОСТЕР не может выносить оценочных суждений о соответствии действительности требований заявителя, а также законности или незаконности информации, размещенной третьим лицом. Исходя из этого и, поскольку ХОСТЕР не наделен оперативно-розыскными полномочиями и правом устанавливать происхождение контента и/или виновное поведение лица его разместившего, до момента установления компетентным органом нарушения прав заявителя, ХОСТЕР не берёт на себя ответственность за вмешательство во взаимоотношения третьих лиц, и определять противоправность поведения клиента, если деятельность клиента не противоречит правилам ХОСТЕРА.
Для вменяемого хостинга действенным фактором будет только решение ркн или суда. Да, они могут притянуть за уши какой-нибудь пункт правил (типа подозрения на фрод) и отключить под левым основанием, но беспричинно на основании жалобы, как бы она не была составлена, нормальный хостер не отключит. Ну а если хостер допускает аракчеевщину, то бежать от него надо без оглядки.
Как пример такого случая, как раз когда викимедиа писал в OVH, параллельный запрос от него ушёл в нэймчип, и тот в итоге мне разделегировал домен, НО не за сам факт жалобы, а за то что я не ответил на их e-mail в течении 14 дней, то есть подвёл под пункт нарушения WDPR, но никак не нарушения авторрских прав.
Опять, же самое примитивное - посмотрите не идут ли запросы с того же ДЦ, где они хостятся. Да и вообще закройте доступ со всех автономок хетнера, ovh, лизвеба, зомро, do и т.п. - живые пользователи оттуда не придут.
Совсем кривой вариант (если парсят не headless-браузерными ботами) - навесьте проверку js/testcookie, только поисковых ботов не порежьте. Опять же спрячьтесь за cf - вдруг будет достаточно.
Конечно, особо прошаренные будут парсить через, например, гугл-прокси, но опять же всё индивидуально, пока не проанализируешь трафик, выводов и рекомендаций не сделать.
Как найти, откуда идет парсинг?
Здесь однозначного рецепта нет.Анализировать трафик веб-сервера в первую очередь. Критерии всегда есть. Конечно, если страниц мало, то есть парсится 1-2 в день, то шансов не много. У меня, в основном, опыт с сайтами миллионниками - там это несколько проще.
Также бывает, что страницы не парсятся, а просто используется реверс-прокси, то есть сайт-паразит просто транслирует контент с сайта донора, даже без хранения его у себя. В таком случае достаточно просто в режиме tail-инга отследить запрос в логе.
