Вы уже точно знаете, что такое веб-скрапинг, если задаетесь вопросами об этике.
Это и основа для исследований, и источник инсайтов для бизнеса, и способ сделать много скучной работы за 5 минут с помощью одного скрипта.
Но если подойти к скрапингу недостаточо подготовленным, можно не только собственноручно записать свои IP-адреса в черный список, но и схлопотать юридические проблемы.
Сейчас разберемся, как соблюдать этику сбора данных — с уважением к людям, сайтам и законам.
Почему вы должны задумываться об этике веб-скрапинга?
Потому что вы имеете дело с чужими ресурсами, чужими правилами и, чаще всего, чужими данными. То, что информация находится в открытом доступе, не делает ее общей. Особенно, если речь идет о персональных данных.
Кроме этики, есть и очень практичные причины.
- Нарушите правила сайта — получите бан IP или судебный иск.
- Зацепите чувствительные данные — попадете под действие GDPR или аналогичных законов.
- Начнете парсить слишком активно — уроните сервер и лишитесь хорошей репутации.
Большинство платформ не против сбора данных и скраперов. Они против неконтролируемого доступа к данным и их несанкционированного использования. Если вы действуете прозрачно, соблюдаете ограничения и не собираете лишнего, то вы в зоне допустимого.
Далее — основные моменты этичного веб-скрапинга, которые вы должны знать.
Роль robots.txt в этичном сборе данных
Файл robots.txt лежит в корне сайта и сообщает ботам, какие страницы можно сканировать, а какие — нет. Этот файл читают поисковые системы, и его же должны читать все приличные скраперы.
Пример простого файла:
User-agent: *
Disallow: /private/
Это значит: «всем ботам запрещено ходить в /private/». Дальше уже на совести бота — соблюдать это или нет. В техническом плане robots.txt не остановит ваш скрипт, но с точки зрения этики (и иногда закона) — игнорировать его плохо.
Нужно понимать, что robots.txt не говорит: «можно парсить всё, что не запрещено». Он говорит: «вот, что точно нельзя». Этический подход — не выискивать лазейки, а принимать ограничения всерьёз.
Как правильно читать директивы
Основные инструкции в robots.txt:
- User-agent — к какому боту применима директива (например, * — ко всем);
- Disallow — какие пути запрещены;
- Allow — какие разрешены (чаще используется вместе с Disallow);
- Crawl-delay — просьба не торопиться (не всеми ботами поддерживается, но уважать стоит).
Если видите Disallow: / — это полное табу на обход сайта. Если Disallow: без пути — значит, ограничений нет. Главное: не врать, кто вы. Не притворяйтесь Googlebot’ом. Указывайте честный User-Agent, чтобы сайт понимал, кто к нему пришёл. Это минимальное проявление уважения.
Также важно учитывать, что некоторые сайты настраивают отдельные правила для разных user-agent’ов. Например:
User-agent: Googlebot
Disallow: /nogoogle/
User-agent: *
Disallow: /allbots/
В этом случае ваша программа (если вы используете кастомный User-Agent) должна следовать правилам из блока User-agent: *, а не тем, что прописаны для Google.
Если в robots.txt указан Crawl-delay, даже если ваша библиотека не обрабатывает его автоматически, имеет смысл добровольно ограничить скорость запросов. Это снизит риск блокировки и покажет вашу добросовестность.
Соблюдение пользовательских соглашений
Если robots.txt — это вежливое «не надо», то пользовательское соглашение сайта — это уже юридическое «нельзя». И вы, заходя на сайт, автоматически соглашаетесь с его условиями.
Ограничения на парсинг в соглашениях
Во многих TOS (Terms of Service) можно встретить прямые запреты:
- «Запрещено автоматизированное извлечение данных»;
- «Доступ к сайту только через официальные интерфейсы (API)»;
- «Сбор контента возможен только с разрешения администрации».
Это значит, что даже если данные доступны без авторизации, их парсинг может нарушать условия использования. А значит — давать право сайту подать в суд или заблокировать доступ.
Более того, в некоторых юрисдикциях нарушение TOS может интерпретироваться как нарушение закона о несанкционированном доступе (например, CFAA в США).
Реальные последствия игнорирования соглашений
Некоторые компании не церемонятся. Facebook (теперь Meta), например, подали и выиграли несколько дел против скраперов.
В октябре 2020 года Meta подала судебные иски против компаний BrandTotal Ltd. и Unimania Inc., которые через браузерные расширения собирали данные пользователей (имена, ID, пол, дату рождения, статус отношений, местоположение и др.) с Facebook, Instagram и других соцсетей без разрешения и в нарушение условий использования.
Компании вынуждены были прекратить это и выплатить значительную сумму в рамках досудебного урегулирования.
Другой знаковый пример — дело hiQ Labs против LinkedIn.
hiQ Labs собирала данные из публичных профилей LinkedIn для анализа трудовых тенденций (retention, skills mapping и др.). LinkedIn попытался остановить скрапинг и выслал уведомления о нарушении пользовательского соглашения.
hiQ подал в суд, заявив, что сбор публичной информации законен и не нарушает CFAA — федеральный закон США о компьютерном мошенничестве (Computer Fraud and Abuse Act).
В 2019 году суд встал на сторону hiQ, указав, что доступ к публичным профилям не является «неавторизованным доступом» по CFAA.
Однако позже суд признал нарушение условий использования LinkedIn, и дело завершилось мировым соглашением с запретом парсить и уничтожением данных.
Кроме судебных последствий, бывают и технические: бан по IP, блокировка аккаунта, внесение в чёрный список. Для исследователя или стартапа это может быть фатально: ни данных, ни доверия, ни будущих партнёров.
Законы о защите персональных данных (GDPR и CCPA)
GDPR (ЕС) и CCPA (США) — два мощных закона, регулирующих сбор и обработку персональных данных. И они касаются даже «открытых» данных.
По GDPR (General Data Protection Regulation) персональными считаются любые данные, по которым можно идентифицировать человека: имя, фото, email, IP-адрес, аккаунт в соцсети и т.д. GDPR требует наличия законного основания для их сбора — «они лежали в открытом доступе» не считается таким основанием.
Публичность данных не отменяет обязанности по соблюдению закона. Если вы собираете такие данные, вы обязаны указать цель, минимизировать объём, хранить безопасно и удалить после использования. Иначе штраф.
CCPA (California Consumer Privacy Act) чуть мягче: он делает исключение для информации, которую пользователь сам сделал публичной (например, открытая запись в Twitter). Но даже в этом случае использование данных должно соответствовать разумным ожиданиям пользователя. Скрапинг приватных профилей или данных из закрытых групп точно за гранью.
Важно: законы действуют не только на компании, находящиеся в ЕС или США. Если вы собираете данные граждан ЕС — GDPR распространяется и на вас. То же самое с США и CCPA.
Персональные данные и их чувствительность
К данным группы PII (Personally Identifiable Information) относятся имена, email, телефонные номера, IP-адреса, геолокация, аккаунты в социальных сетях, фотографии и видео.
Все это требует аккуратного обращения. А если есть еще и передача третьим лицам, то это потенциальный повод для жалобы.
Есть и особо чувствительные категории данных: здоровье, политические взгляды, этническая принадлежность и биометрия.
В 2023 году сразу несколько стран — Великобритания, Канада, Австралия и другие — выпустили совместное заявление: массовый сбор данных с публичных страниц в соцсетях без согласия может рассматриваться как нарушение закона. Особенно если используются фото, комментарии и другая контекстная информация.
Тут как раз нужно рассказать про пример из ИИ-мира.
Компания Clearview AI собрала миллиарды лиц из открытых источников для обучения распознавания лиц. В итоге — иски, запреты в ЕС, Австралии и Канаде. Даже если фото лежали «в открытом доступе», массовый сбор и новая цель (идентификация) сделали это незаконным.
NL DPA (Нидерланды) оштрафовал Clearview AI на €30,5 млн за незаконный сбор изображений граждан и нарушение GDPR.
Резидентные прокси
Идеальные прокси-серверы для доступа к ценным данным со всего мира.
Хорошие и плохие практики веб-скрапинга
Это просто быстрая самопроверка.
Пример «хорошего» парсинга
Так выглядит этичный парсинг: минимальный вред, прозрачность, соответствие правилам и законам.
- Вы собираете данные с сайтов городских администраций.
- У всех сайтов есть открытые CSV-файлы и лицензии на использование.
- Вы проверили robots.txt и TOS — всё разрешено.
- Запросы идут медленно, с User-Agent’ом вида ResearchBot (email@example.com).
- Вы не берёте персональные данные, не храните их дольше, чем нужно, и указываете источник.
Хорошая практика — использовать API, если он есть. Если у платформы есть официальный способ получения данных, лучше выбрать его. Это стабильнее, этичнее и юридически безопаснее.
Пример «плохого» парсинга
Это не просто неэтично, это вполне может быть незаконно (особенно в ЕС). И это точно удар по репутации и доверию к вам как к специалисту или проекту.
- Стартап парсит миллионы профилей из соцсети, игнорируя robots.txt и соглашение.
- Используются фейковые аккаунты для доступа к закрытым данным.
- Собираются фото, имена, связи между людьми, геометки — всё это без уведомления и цели, понятной пользователю.
- Данные перепродаются или используются в коммерческих целях без согласия.
Хуже всего, когда такие проекты маскируются под «инновации» или «исследования», но по сути занимаются массовым сбором личной информации без контроля. Такие действия подрывают доверие к отрасли в целом.
Чек-лист перед началом скрапинга
- Проверили ли вы robots.txt сайта? Если да, то уважаете ли ограничения, заданные в нём?
- Ознакомились с пользовательским соглашением? И нет ли в нём явных запретов на автоматизированный доступ?
- Есть ли у сайта официальный API или открытые данные? Если есть, то лучше использовать их.
- Собираете ли вы персональные данные? Если да — у вас есть законное основание? Согласие? Механизмы защиты?
- Соблюдаете ли вы принцип минимизации? Вы точно берёте только то, что нужно для вашей цели?
- Настроен ли лимит скорости запросов? Есть ли User-Agent, указывающий на вас честно и явно?
- Планируете ли вы публикацию, монетизацию, передачу данных? Если да, точно уверены, что не нарушаете ничьих прав?
- Готовы ли вы, чтобы кто-то поступил так же с вашими данными? Если ответ «не очень», стоит пересмотреть подход.
Технические нюансы в дополнение к чек-листу:
- Использование User-Agent с контактной информацией.
- Установка Crawl-delay вручную, если сайт явно слабый.
- Автоматическое чтение и парсинг robots.txt перед началом сбора.
- Ограничение количества одновременных соединений.
- Настройка логов и отслеживание исключений (например, 403 или 429).
- Добавление капчи-детектора и реакция на блокировку — не как вызов, а как «всё, стоп».
Заключение
Собирайте данные этично и все будет хорошо.
Уважайте robots.txt. Читайте пользовательские соглашения. Не лезьте за данными, которые явно не для вас. И особенно будьте аккуратны с персональной информацией. Это не только про законы, но и про уважение к людям и сообществу в целом.
Если сомневаетесь — скорее всего, лучше не скрапить. Или спросить разрешения. Лучше потратить лишний час на проверку, чем месяцы на разборки.
Часто задаваемые вопросы
Что если я собираю данные только для себя?
Допустим, вы — исследователь, студент или просто энтузиаст, который собирает данные «в стол», без публикации, без монетизации. Это снимает часть рисков, но не все:
- Если вы собираете персональные данные, даже для некоммерческого использования, всё равно действует GDPR или аналогичные нормы. Сам факт хранения чувствительной информации обязывает вас обеспечить её безопасность.
- Некоторые сайты прямо запрещают автоматический сбор независимо от цели. Нарушение TOS может иметь последствия, даже если вы не публикуете результаты.
- В случае утечки (например, из-за взлома ноутбука) ответственность может наступить даже за «личную» базу.
Так что «для себя» — это не абсолютная защита. Лучше действовать аккуратно, как если бы вы работали с продакшн-проектом.
Как оформлять результаты скрапинга этично?
Если вы планируете использовать собранные данные в отчётах, дашбордах, научных публикациях или даже просто показывать результаты коллегам — вот несколько рекомендаций:
- Агрегируйте данные, если можно обойтись без PII.
- Удаляйте поля, которые не нужны для анализа, но могут идентифицировать человека (имя, email, фото, handle соцсети).
- Указывайте источник с датой и URL, особенно если данные могли измениться.
- Не публикуйте дампы персональных данных, даже если они получены легально.
- Обеспечьте хранение данных в соответствии с нормами безопасности, если в них есть чувствительные поля.
А если я просто анализирую страницы, не сохраняя данные?
Если вы делаете это вручную — вопросов нет. Если используете бота, даже без сохранения, — вы всё равно технически залазите глубже. Поэтому всё то же: robots.txt, TOS и ограничения важны. К тому же, лог-файлы сайта всё равно фиксируют ваш трафик — и если он чрезмерен, вас могут заблокировать.
Нужно ли читать TOS, если сайт государственный?
Да, обязательно. Даже если сайт принадлежит органу власти, на нём может быть размещено пользовательское соглашение или политика в отношении автоматизированного доступа. Некоторые государственные порталы прямо запрещают массовый сбор без согласования. К тому же, такие сайты могут использовать нестандартные правила доступа или предусматривать API, которые нужно использовать вместо парсинга.
Что делать, если в robots.txt всё запрещено, но данные отображаются в поиске?
Если страницы индексируются поисковыми системами, но в robots.txt стоит Disallow: /, это может быть результатом устаревших настроек или разночтений. Но, если в момент вашего сбора запрет явно указан, то лучше его соблюдать. Исключение — только если у вас есть письменное разрешение владельца ресурса или вы используете официальный API, который не подпадает под ограничения robots.txt.
Как быть, если у сайта нет API, а данные нужны срочно?
Это типичная ситуация. Вот что можно сделать:
- Проверить наличие открытых данных в других форматах (XML, CSV, RSS, Open Data портал);
- Написать администратору с просьбой о временном доступе или выгрузке;
- Использовать парсинг с максимальной деликатностью: один запрос в несколько секунд, только по разрешённым URL, без PII;
В крайних случаях — использовать скриншоты, OCR или браузерную автоматизацию, но только для личного пользования и при условии, что данные точно не защищены.
