Так никто же не явился на заседание)) Поэтому судья, не обладающая знаниями об it-технологиях, вынесла решение на основании заявления истца))
Ну то есть на некомпетентном экспертном мнении, о чём я пару страниц назад и говорил :) Здесь же наверняка никто из ответчиков даже хостингом не является.
Когда мне аналогичное прилетело, то я таких дел десятки (если не сотни) находил, есть правда, изредка, и альтернативные решения (А40-263756-2018__20191105):
---
Суд первой инстанции установил, что ссылка истца на сервис Whois
Service не является допустимым доказательством по делу, поскольку на
данном сервисе не указан ни ИНН, ни ОГРН администратора домена,
юридический адрес либо иные данные, которые бы позволили суду
надлежащим образом идентифицировать администратора сайта.---
Еще раз, граждане - не важно где находятся файлы физически, важно где они отображаются, и то что за отображение таких файлов на сайте отвечает администратор домена.
Осмотр проходит просто, открываем сайт, фиксируем что видим в момент открытия - все, остальное не важно, вообще. И далее за все что зафиксировали на сайте отвечает администратор доменного имени.
Один из примеров.
В ответчиках только КлаудФлэр Инк (CloudFlare Ink), ООО "ДДОС - ГВАРД", ЮЭЙБИ ОВХ (UAB OVH), то есть CDN, защита от DDoS и ДатаЦентр :)
Про администратора домена даже упомнинания нет.
Согласно данным открытых сервисов Whois в сети «Интернет», предоставляющих доступ к публичным серверам баз данных регистраторов сетевых адресов и регистраторов доменных имен, на момент принятия судом предварительных обеспечительных мер по делу, провайдером хостинга сайтов ... является ЮЭБИ ОВХ (UAB OVH), сайтов ... является ООО «ДДОС-ГВАРД», сайтов ... является КлаудФлэр Инк (CloudFlare Inc).
Всё обоснование сделано на данных взятых из whois, то есть на филькиной грамоте, которую можно состряпать в течении часа, и кто там владелец сайта / администратор домена никого не волнует.
Оно и есть в реестре, но номер дела увы не дам (там фигурируют мои данные), хотя в статье достаточно информации, при желании по ней не сложно найти.
Во первых - вы говорите сейчас неправду, вы никогда не были в суде, по крайне мере по таким делам
Это реальная история конца 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 или обратной зоне - очистите от поисковых ботов. Всех остальных в бан.
