Во многих странах обсуждают законы, которые требуют подтверждать возраст пользователей не только на сайтах, но и на уровне операционной системы или магазина приложений. Для разработчиков и open source это может обернуться новыми обязанностями, даже если продукт не связан с «контентными» рисками для детей.
Регуляторы в разных странах продвигают инициативы по так называемому age assurance — способам определить, сколько лет пользователю, чтобы ограничить детям доступ к вредному контенту. Новая деталь в том, что требования всё чаще пытаются «спустить вниз по стеку»: не только на сайты и приложения, но и на устройства, операционные системы и магазины приложений.
Для обычных пользователей это звучит логично: если ребёнок пользуется смартфоном, «пусть телефон сам поймёт, что он ребёнок». Но у такого подхода есть побочный эффект: правила могут затронуть инструменты разработки и open source-проекты, которые не похожи на соцсети или видеоплатформы и не создают сопоставимых рисков для несовершеннолетних.
Что именно называют age assurance
Под одним термином часто смешивают разные методы:
- Age verification — «жёсткая» проверка возраста с высоким уровнем уверенности (например, сверка документа или проверка через финансовые/идентификационные системы).
- Самоотчёт — пользователь просто указывает возраст.
- Age estimation — возраст оценивают по косвенным сигналам: от сканирования лица до поведенческих признаков.
У каждого подхода свои компромиссы: точность, приватность, безопасность, доступность для людей с ограничениями и совместимость между платформами. Поэтому два законопроекта с одинаковой целью могут давать абсолютно разные последствия для разработчиков.
Почему это касается разработчиков, даже если вы «не про контент»
В ряде инициатив предполагается, что возрастной сигнал будет формироваться на уровне устройства/ОС/магазина приложений и передаваться дальше — в приложения и на сайты. Здесь и возникает риск «широкой сети»: если закон написан неаккуратно, в зону регулирования может попасть инфраструктура, которая вообще не рассчитана на обработку персональных данных пользователей.
Есть несколько типовых сценариев, которые особенно болезненны для open source:
- Централизованный сбор данных на уровне ОС: если операционная система должна хранить «возрастные атрибуты» или подтверждения, это повышает ценность такого хранилища для злоумышленников и усложняет архитектуру даже там, где это не нужно.
- Запрет установки софта «в обход магазина»: попытка заставить всех ходить через один «контрольный пункт» конфликтует с привычной моделью распространения свободного ПО, где пользователь может сам собирать и устанавливать приложения.
- Обязанности для “издателей” ОС без оглядки на масштаб: open source-системы часто перерабатывают, переупаковывают и распространяют маленькие команды и отдельные энтузиасты. Если требование одинаково для корпорации и для сообщества из нескольких человек, поддерживать проект становится резко сложнее.
Почему инструменты разработки — не социальные сети
Платформы совместной разработки и хостинга кода выполняют другую задачу: они помогают создавать и поддерживать программное обеспечение, а не удерживать аудиторию и «раскручивать» потребление контента. Из-за этого профиль рисков обычно ниже, чем у массовых потребительских платформ.
Когда регуляторы не различают эти типы сервисов, получается парадокс: требования, придуманные для борьбы с травлей или опасными видео, начинают «прилипать» к инфраструктуре для сборки, ревью и публикации кода — со всеми расходами, юридическими рисками и техническими переделками.
Что можно сделать, чтобы решения не стали проблемой
В этой теме важнее всего не «спорить с целью», а уточнять реализацию. Законы пытаются закрыть реальные угрозы (груминг, насилие, буллинг), но дизайн требований должен учитывать, как устроена разработка ПО и почему open source держится на добровольных усилиях.
Практические шаги, которые выглядят наиболее разумно:
- Следить за формулировками: ключевые слова вроде “publisher”, “platform”, “app store”, “operating system” и “age signal” часто определяют, попадёте ли вы в область требований.
- Поддерживать профессиональные организации, которые умеют объяснять законодателям технические нюансы языком политики и комплаенса.
- Говорить про границы ответственности: где заканчивается защита детей и начинается попытка превратить разработчиков в операторов идентификации.
Отдельный плюс — обсуждение идёт не только вокруг «запретов», но и вокруг того, как защитить несовершеннолетних, не ломая доступ к обучению и практике. Для многих подростков участие в разработке, комьюнити и open source-проектах — часть образования и будущей карьеры.
Даты, которые важно не потерять: в повестке прямо упоминаются текущие обсуждения в отдельных юрисдикциях, а также публичные форматы дискуссии в рамках сообщества мейнтейнеров (включая запланированное мероприятие 22 мая 2026 года).
