но напрямую рисковать не решили, закинули на краудфандинг https://www.makuake.com/project/sadokei/лол

Блин а зачем он такой здоровый то?

Эппл на фоне запрета тиктока в штатах анонсировала не оч приятную новую механику ограничений по загрузке приложений: теперь недостаточно сменить регион стора или подцепить VPN — региональные блокировки непосредственно для приложений ByteDance будут зависеть и от фактической геопозиции

Эта статья очень некисло залетела на хакерньюсе и я очень рилейчу, потому что у меня такую же боль вызывают сайты и интерфейсы в выворотке. В конце статьи автор кстати говорит что код предпочитает писать с тёмной темой, потому что встроенные в айдэишки тёмные темы удовлетворяют его требованиям к контрастности, но если честно тут видимо добавляется мой астигматизм, потому что даже такое мне часто юзать некомфортно.
Короче вот, дропну её перевод тут. Оригинал доступен по ссылке: iamvishnu.com/posts/please-dont-force-dark-mode


VIshnu's Pages — Пожалуйста, не форсите тёмный режим

Дорогие дизайнеры сайтов,

Пожалуйста, не навязывайте тёмный режим своим пользователям. Если тёмный режим — часть вашей идентики, убедитесь, что вы выбрали комфортное соотношение контраста для текста.

Я часто сталкиваюсь с сайтами, включая личные блоги, которые полностью оформлены в тёмном режиме. Это вызывает у меня невероятное раздражение, так как я не могу прочитать и абзаца, прежде чем мои глаза начинают слезиться. Тёмный режим может быть полезным в некоторых случаях, но его навязывание — ужасный пользовательский опыт.

«Мои глаза! Мои глаза!» 😵‍💫

Чтение в тёмном режиме не просто напрягает мои глаза — этот эффект остаётся ещё долго после. Каждый раз, когда я заканчиваю читать длинную статью, я начинаю видеть горизонтальные полосы повсюду, как будто мои глаза не могут это «отпустить».

Вот как видят мои глаза до чтения статьи в тёмном режиме:

В чём реальная проблема тёмного режима?

Проблема заключается в контрасте между текстом и фоном.

Пример 1, чисто белый текст #FFFFFF на полностью чёрном фоне #000000 сильно напрягает глаза и его сложно читать. Контраст такого сочетания — 21:1.

В то же время светло-серый текст #E0E0E0 на тёмно-сером фоне #666 намного комфортнее для глаз. В этом случае контраст составляет 4.34:1. Пример 2:

А есть ли рекомендации?
Руководство по доступности веб-контента (WCAG 2.1) рекомендует минимальное соотношение контраста 4.5:1 для текста (SC 1.4.3), но никаких ограничений на максимальный контраст не существует.

Это означает, что чисто белый текст на полностью чёрном фоне с соотношением 21:1 считается полностью доступным по текущим стандартам, хотя для многих людей такой контраст тяжело воспринимать. При этом более комфортное соотношение 4.34:1 (см. выше) не проходит проверку по стандартам.

Будущая версия WCAG 3.0 вводит исследовательское требование на максимальный контраст текста (Maximum text contrast), и я надеюсь, что рабочая группа учтёт эту проблему и предложит рекомендации.

P.S. Тем не менее, я люблю тёмный режим, когда:

• Читаю с OLED-экрана в тёмной комнате (например, перед сном).
• Пишу код. Большинство IDE имеют тёмный режим с комфортным контрастом по умолчанию.
• Контраст на сайте комфортный.

(Конец прямой речи если что)

Статья очень многое упрощает конечно, но куда важнее то что проблему начали обсуждать.

Рекомендую также почитать комменты на хакерньюсе к ней: https://news.ycombinator.com/item?id=42762054

в самый ответственный момент оператор потерял фокус)

Но таки да, есть пробитие. Спустя много много лет после Конкорда и Ту-144, первый пассажирский самолёт разработанный частной компанией вышел на сверхзвук.

На данный момент у компании есть 130 заказов/предзаказов от American Airlines, United и JAL

У нас есть уязвимость Спектр дома. В целом выглядит как довольно типичная проблема с аппаратными предикторами.

Недавно обнаруженные уязвимости в процессорах Apple (A- и M-серии) позволяют злоумышленникам красть данные из браузеров Safari и Chrome.

В чем проблема?

Уязвимости связаны с механизмом спекулятивного исполнения, который ускоряет работу процессора, предугадывая будущие вычисления. Исследователи обнаружили два метода атак:

• FLOP (на основе Load Value Predictor, LVP): Вкладка атакующего веб-сайта обучает браузер (Safari/Chrome) предсказывать ложные данные, позволяя считывать в целом любые участки памяти браузера, и таким образом «выуживать» историю местоположений (Google Maps), содержимое писем (Proton Mail) или события из календаря (iCloud Calendar). Работает и в Safari, и в Chrome. Проблеме подвержены устройства на процессорах M3, A17 (iPhone 15 Pro; iPad mini 7) и новее

• SLAP (на основе Load Address Predictor, LAP): переносит «неправильные» адреса и позволяет считывать данные из других вкладок Safari. Таким образом атакующий может, к примеру, увидеть фрагменты Gmail или Reddit, открытых параллельно. Проблеме подвержены устройства на процессорах M2, A15 (iPhone 13, SE3; iPad mini 6) и все последующие


Подробное исследование FLOP будет представлено на USENIX Security 2025, а SLAP – на IEEE Symposium on Security and Privacy 2025. Apple пока не подтвердила выпуск патча, но заявила, что риск для пользователей “не является немедленным”.


Источник и более наглядные примеры атак:
https://arstechnica.com/security/2025/01/newly-discovered-flaws-in-apple-chips-leak-secrets-in-safari-and-chrome/

Ещё вот хорошие новости:

Google делает reCAPTCHA платной: опубликованы новые тарифы

Google обновил условия использования reCAPTCHA — популярного инструмента защиты от ботов, и теперь он становится платным для активных пользователей. Бесплатное использование останется, но с жесткими ограничениями.

Компания начала рассылку писем пользователям reCAPTCHA, предупреждая об изменениях в работе сервиса. В письме говорится, что все ключи reCAPTCHA должны быть переведены в Google Cloud до конца 2025 года.

Google будет переводить ключи на новую систему поэтапно и уведомлять владельцев ключей об этом. Однако пользователи могут самостоятельно выполнить миграцию заранее, чтобы сразу выбрать, к какому проекту Google Cloud будет привязан их ключ.

Новые тарифы reCAPTCHA:
1. Essentials (Базовый) – бесплатно до 10 000 проверок в месяц, без дополнительных функций.
2. Standard (Стандартный) – первые 10 000 проверок также бесплатны, но далее 100 000 проверок обойдутся в $8 в месяц.
3. Enterprise (Корпоративный) – включает расширенные функции и масштабируемую оплату: после 100 000 проверок взимается $1 за каждую 1 000 проверок.

Как работает биллинг?
- Если у вас нет привязанного платёжного аккаунта Google Cloud, вам автоматически назначается тариф Essentials.
- После активации биллинга учетная запись переходит в Standard, предоставляя 10 000 бесплатных проверок и дополнительные функции.
- Если превышено 10 000 проверок в месяц, автоматически списывается $8 за использование до 100 000 проверок.
- Если лимит в 100 000 проверок превышен, активируется Enterprise-тариф с оплатой $0.001 за каждую дополнительную проверку.
- Организации с высокими нагрузками могут обсуждать скидки с Google.

Что делать пользователям?
Если ваш сайт или приложение активно использует reCAPTCHA и превышает 10 000 проверок в месяц, вам придется включить биллинг в Google Cloud, иначе сервис перестанет работать после исчерпания лимита. Google обещает отправлять уведомления перед отключением.


Google заверяет, что изменения в коде не требуются, и текущие ключи продолжат работать с устаревшим API SiteVerify. Однако компания рекомендует перейти на CreateAssessment API, чтобы использовать последние возможности reCAPTCHA.