Internet's biggest annoyance: Cookie laws should target browsers, not websites 🔥 Горячее 💬 Длинная дискуссия
Законы о cookie, такие как GDPR и CCPA, создали ежедневный ритуал раздражения для пользователей интернета. Вместо того чтобы дать реальный контроль над данными, они заставили миллионы сайтов показывать навязчивые cookie-баннеры, которые большинство пользователей механически принимают. Эта система неэффективна по трем причинам: вызывает усталость от согласия, несправедлива к небольшим сайтам, которые не могут позволить себе дорогие платформы управления согласием, и не предоставляет реального выбора.
Предлагаемое решение — перенести управление cookie в браузеры. Пользователи могли бы один раз установить свои предпочтения приватности в настройках браузера (например, "только необходимые", "аналитика", "персонализация"), и браузер автоматически применял бы эти настройки ко всем сайтам. Такой подход устранит необходимость в миллионах повторяющихся запросов согласия, снизит нагрузку на небольшие сайты и предоставит пользователям реальный контроль над их данными, сделав интернет более удобным и приватным.
Комментарии (517)
- Веб-сайты используют "malicious compliance", превращая диалоговые окна в инструмент давления на пользователя, вместо того чтобы предоставлять реальную возможность отказа.
- Браузеры могли бы автоматически применять настройки приватности пользователя, но вместо этого веб-сайты вынуждают пользователей вручную отказываться от сбора данных, даже если это технически возможно.
- Законодательство, похоже, нацелено на веб-сайты, но не на браузеры, даже если последние могли бы решить проблему. Это приводит к тому, что вместо того, чтобы просто запретить отслеживание, веб-сайты вынуждены запрашивать согласие, что создает видимость соблюдения закона.
- Попытка сделать приватность доступной для всех, вместо того чтобы просто запретить отслеживание, привела к тому, что вместо того, чтобы браузер просто сообщал веб-сайтам "не отслеживать", они должны спрашивать, что создает видимость соблюдения закона.
Google Safe Browsing incident 💬 Длинная дискуссия
25 сентября 2025 года Google Safe Browsing внезапно заблокировал весь домен statichost.eu как «обманчивый» — даже поддомены, включая пользовательские сайты клиентов. Почти шесть часов ни один браузер на Chromium-основе не открывал ни одну страницу на домене без жёсткого предупреждения. Это затронуло и сам сайт компании и все её поддомены, включая личные сайты клиентов.
В итоге, Google Search Console показал, что причиной стало то, что на платформе появились фишинговые сайты. Вместо того, чтобы сообщить владельцу и дать ему возможность удалить их, Google просто внёс весь домен в чёрный список.
Это стало поводом для публикации, в которой компания подчеркнула, что теперь она будет выдавать всем новым сайтам домен statichost.page, чтобы избежать повторения ситуаций в будущем.
Комментарии (151)
- Google Safe Browsing блокирует сайты, если на них размещают фишинг-контент, но при этом не всегда ясно, кто именно блокирует — Google или другие сервисы.
- Провайдеры, которые не разделяют пользовательский контент на отдельном домене, рискуют, что весь их домен попадёт в чёрный список.
- Public Suffix List помогает браузерам и поисковикам различать, где заканчивается домен первого уровня и начинается поддомен.
- Размещая пользовательский контент на отдельном домене, можно избежать риска, что весь домен попадёт в чёрный список.
XSLT removal will break multiple government and regulatory sites
- Удаление XSLT в браузерах разрушит работу правительственных и регуляторных сайтов по всему миру.
- Сотни порталов (Финляндия, Германия, США, Канада, Австралия и др.) используют XSLT для отображения XML-документов (законы, отчёты, статистика).
- Без XSLT эти ресурты станут недоступны для граждан, нарушатся юридические обязательства и процессы e-government.
- Предлагается сохранить поддержку XSLT как критическую инфраструктуру или предоставить механизм миграции.
Комментарии (71)
- Участники спорят о предложении WHATWG исключить XSLT из HTML-спецификации: одни считают технологию мёртвой и опасной, другие — полезной для «без-JS» задач и госсайтов.
- Поднимаются вопросы безопасности (libxslt на C), обратной совместимости и «доктрины never break the web».
- Некоторые предлагают вынести XSLT в расширение или полифил, а также сравнивают судьбу XSLT с Flash, ActiveX и другими удалёнными технологиями.
- Отмечается, что процесс удаления может занять годы, а пока лишь начато обсуждение, а не принято решение.