🤣 DuckDuckGo випустила... "антизбоченські" окуляри

Після хвилі критики розумних окулярів Meta з вбудованими камерами, які в мережі вже давно охрестили "окулярами для збоченців", DuckDuckGo вирішила відповісти... тролінгом.

Разом із виробником Knockaround компанія представила "Normal F***ing Sunglasses"* ("Нормальні, б^@&ь, сонцезахисні окуляри").

Їхні характеристики звучать як пародія на сучасні гаджети:
👓 Камера — відсутня
🎤 Мікрофон — відсутній
🤖 ШІ — відсутній
🔋 Акумулятор — не потрібен
📶 Wi-Fi та Bluetooth — немає
☁️ Передача даних у хмару — неможлива

Єдине, що вони роблять, — захищають очі від сонця. І саме це DuckDuckGo називає "найінноваційнішими антиспостережними окулярами у світі". 😄

Ціна новинки — $35, тоді як розумні окуляри Meta стартують приблизно від $299.

Найкумедніше, що це не жарт: компанія підтвердила, що окуляри справді надійшли у продаж, і значна частина першої партії вже розкуплена. У час, коли майже будь-який пристрій намагаються перетворити на інструмент збору даних, виявилося, що відсутність електроніки теж може стати конкурентною перевагою.

🔗 Джерело: Futurism.

Коли відповідальне розкриття вразливостей перетворюється на війну. Історія протистояння Nightmare-Eclipse та Microsoft

Навесні 2026 року псевдонім Nightmare-Eclipse став одним із найгучніших у світі кібербезпеки. Вісім 0-day, публікація експлойтів до виходу патчів, гострий конфлікт із Microsoft і дискусія, яка розколола професійну спільноту.

Але ця історія — не лише про вразливості Windows.

Це історія про те, що відбувається, коли руйнується Responsible Disclosure, чому навіть BitLocker не є абсолютним захистом і чому іноді найнебезпечливіша вразливість знаходиться не в коді, а у втраті довіри між людьми.

У новій великій статті розбираємо одну з найгучніших історій у сфері інформаційної безпеки останніх років.

З днем
Військ зв'язку⚡
з реальністю
та кібербезпеки🛡️
Збройних Сил України🇺🇦!

🚨 WebKit може розкрити вашу справжню IP-адресу навіть із увімкненим iCloud Private Relay

Дослідники з Mysk виявили одразу три особливості WebKit, через які браузери на iOS та macOS можуть обходити налаштовані проксі, включно з iCloud Private Relay, і напряму підключатися до мережі. У результаті сайт може побачити реальну IP-адресу користувача.

Проблема пов'язана з такими механізмами:
• DNS Prefetching;
• WebAuthn Related Origin Requests (Passkeys);
• WebTransport.

⚠️ Найважливіше:

* уразливість стосується всіх браузерів на iOS, оскільки Apple зобов'язує їх використовувати WebKit;
* iCloud Private Relay не гарантує приховування IP у цих сценаріях;
* системні VPN не зачіпаються, адже вони тунелюють увесь мережевий трафік на рівні операційної системи.

Apple вже повідомила, що розслідує проблему, але на момент публікації інформації про виправлення ще немає.

💬 Якщо для вас критично важлива анонімність, поки що VPN залишається надійнішим рішенням, ніж покладатися лише на iCloud Private Relay.

🤖 Chrome завантажує на ваш ПК кілька гігабайтів AI. Навіщо — і як це вимкнути

Google Chrome почав автоматично завантажувати на комп'ютери локальні AI-моделі, зокрема Gemini Nano. У деяких випадках йдеться приблизно про 4 ГБ даних, а якщо враховувати різні моделі та компоненти, цифра може бути значно більшою.

І тут є важливий нюанс: це не вірус і не прихована програма-шпигун.

Що саме завантажується?

Chrome використовує моделі штучного інтелекту, які працюють безпосередньо на комп'ютері, а не в хмарі Google.

Вони можуть використовуватися для таких функцій, як:

• допомога з написанням і перефразуванням тексту;
• створення резюме вебсторінок;
• виявлення шахрайських сайтів;
• організація вкладок;
• інші AI-функції браузера.

Модель зберігається у файлах Chrome, а не встановлюється як окрема програма. Один із компонентів можна знайти у папці:

%LOCALAPPDATA%\Google\Chrome\User Data\OptGuideOnDeviceModel

Зазвичай там можна побачити великий файл weights.bin.

Чому це викликає питання?

Проблема не стільки в самому Gemini Nano, скільки в способі його доставки.

Chrome може завантажувати модель у фоновому режимі, тобто користувач може навіть не розуміти, чому раптом зникли кілька гігабайтів на SSD або звідки взявся великий мережевий трафік.

Для звичайного безлімітного домашнього інтернету це може бути просто неприємністю.

Але є сценарії, де це вже має практичне значення:

💾 Дисковий простір. Кілька гігабайтів для ноутбука з невеликим SSD — це не дрібниця.

📡 Трафік. На тарифах з обмеженим або дорогим мобільним інтернетом фонове завантаження великих моделей може бути небажаним.

⚡️ Ресурси комп'ютера. Під час роботи локальної моделі використовуються CPU, RAM, а залежно від реалізації — й інші апаратні ресурси.

🔐 Контроль над програмним забезпеченням. Користувач отримує компонент, який він безпосередньо не встановлював і про який може навіть не знати.

А тепер — що є міфом?

❌ «Google встановлює на ПК шпигунську програму».

Ні. Gemini Nano — справжня локальна AI-модель Chrome, а не шкідливе ПЗ.

❌ «Gemini Nano відправляє весь вміст комп'ютера в Google».

Саме призначення локальної моделі — виконувати частину AI-обробки на пристрої. Це якраз відрізняє її від хмарного AI.

❌ «Chrome таємно використовує ваш ПК для майнінгу».

Ні. Немає підстав прирівнювати використання CPU/GPU для локальної AI-моделі до криптомайнінгу.

❗️ Але й твердження «це абсолютно безпечно і не створює жодних проблем» було б неправильним.

Будь-який додатковий програмний компонент збільшує поверхню атаки, споживає ресурси та потребує оновлення. А головне — користувач повинен мати можливість вирішувати, чи потрібна йому ця функціональність.

Як це вимкнути?

У сучасному Chrome Google вже передбачила відповідний перемикач.

Відкрийте:

Налаштування → Система → On-device AI / ШІ на пристрої → Вимкнути

Після цього Chrome не повинен завантажувати моделі, необхідні саме для локальних AI-функцій. Уже завантажені моделі також видаляються, а відповідні функції перестають працювати.

Якщо пункту немає або потрібен жорсткіший контроль у Windows, існує офіційна політика Chrome:

GenAILocalFoundationalModelSettings

У реєстрі Windows вона знаходиться за адресою:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome

Створюється параметр REG_DWORD:

GenAILocalFoundationalModelSettings = 1

Значення 1 забороняє завантаження локальної GenAI-моделі та, за документацією Google, видаляє вже завантажену модель.

Для звичайного користувача достатньо першого способу. Реєстр має сенс, якщо потрібно примусово заборонити завантаження моделі, наприклад на керованих комп'ютерах.

І головне

Ця історія показова не тому, що Google «запхала вірус у Chrome».

Проблема значно прозаїчніша:

браузер, який ви встановлювали для перегляду вебсторінок, поступово перетворюється на платформу для локального AI — і частину необхідних для цього компонентів він може завантажувати сам.

Комусь Gemini Nano буде корисним.

Комусь — ні.

Але в ідеальному світі вибір мав би бути простим: «Мені потрібен AI — завантажити. Не потрібен — не завантажувати».

#Chrome #Google #Gemini #AI #ШІ #Приватність

⚠️ Дешеві Android TV-приставки можуть шпигувати за вами ще до першого увімкнення

Дослідники Bitsight викрили масштабну інфраструктуру Fuyao, яка постачає дешеві Android TV Box із уже вбудованим шкідливим ПЗ. Йдеться не про зараження після покупки — пристрої потрапляють до користувачів уже скомпрометованими.

🔍 Що виявили?
• прихований бекдор, який зв'язується з командними серверами;
• рекламне шахрайство (ad fraud) — пристрій непомітно генерує фальшиві перегляди та кліки;
• можливість встановлення додаткових програм без відома власника;
• використання пристроїв як частини великої ботмережі.

За даними дослідників, інфраструктура Fuyao налічує сотні серверів і контролює мільйони пристроїв по всьому світу. Зловмисники також використовували AI для автоматизації частини своєї діяльності та навіть залучали дітей через онлайн-платформи навчання програмуванню для виконання окремих завдань, пов'язаних із підтримкою своєї екосистеми.

❗️Чому це важливо?

Такі приставки часто продаються на маркетплейсах під десятками різних назв, без відомого виробника або з модифікованою прошивкою. Приваблива ціна може означати, що ви купуєте не лише медіаплеєр, а й інструмент для заробітку кіберзлочинців.

🛡 Що робити?
• купувати Android TV-пристрої лише від відомих виробників;
• уникати «ноунейм» моделей із підозріло низькою ціною;
• регулярно встановлювати оновлення прошивки;
• якщо пристрій поводиться дивно (реклама, самовільні підключення, невідомий мережевий трафік) — краще замінити його.

💬 Чергове нагадування: сьогодні небезпеку може становити не лише смартфон чи ноутбук. Навіть звичайна ТВ-приставка здатна стати повноцінним елементом ботмережі, який працює на кіберзлочинців, поки ви просто дивитеся серіал.

🔑 Pass-ta-key: дослідники знайшли спосіб обійти ключі доступу (Passkeys) у Chrome

Ключі доступу (Passkeys) вже кілька років називають майбутнім безпарольної автентифікації. Вони дійсно значно стійкіші до фішингу та викрадення паролів. Проте абсолютного захисту не існує.

Дослідники з Unit 42 представили серію атак під загальною назвою Pass-ta-key, спрямованих не на криптографію FIDO, а на механізми роботи Google Password Manager та синхронізації ключів доступу.

🔹 Метод №1. Експорт ключів. Якщо комп'ютер уже заражений шкідливим ПЗ, воно може змусити Google Password Manager експортувати ключі доступу на диск замість їхнього захищеного зберігання в TPM. Після цього зловмисник отримує можливість використовувати ці ключі без участі користувача.

🔹 Silver ("срібна") атака. Шкідливе ПЗ використовує стан, коли Windows ще вважає біометричну перевірку користувача дійсною. Це дозволяє автоматично реєструвати нові Passkeys без повторного підтвердження власником пристрою.

🔹 Golden ("золота") атака. Найнебезпечніший сценарій. Дослідники виявили, що секретні дані (SDS), необхідні для захисту синхронізованих Passkeys, можуть залишатися в оперативній пам'яті Chrome навіть після їх видалення. Отримавши дамп пам'яті, шкідливе ПЗ здатне витягнути базу синхронізованих ключів доступу.

🔹 Компрометація майбутніх Passkeys. Якщо зловмисник заволодіє SDS, він зможе розшифровувати не лише вже існуючі, а й нові Passkeys, створені через Google Password Manager. Загроза зберігатиметься доти, доки користувач не створить новий SDS.

⚠️ Важливо: жодна з цих атак не ламає технологію Passkeys або криптографію FIDO. У всіх випадках передумовою є вже скомпрометований пристрій або виконання шкідливого коду на ньому. Це ще раз підтверджує, що навіть найсучасніші механізми автентифікації не можуть захистити систему, якщо контроль над самим комп'ютером уже втрачено.

📌 Щоб мінімізувати ризики:
• використовуйте лише довірені пристрої;
• регулярно встановлюйте оновлення;
• контролюйте список авторизованих пристроїв у Google;
• для особливо важливих акаунтів розгляньте використання апаратних ключів безпеки.

💬 Висновок простий: Passkeys залишаються значно безпечнішими за паролі, але безпека завжди залежить від цілісності операційної системи. Якщо пристрій уже заражений, жоден спосіб автентифікації не гарантує абсолютного захисту.

📍 Якщо Ваш смартфон знає, де ви, то й рекламний брокер — теж

EFF звернула увагу на неприємну особливість Android-застосунків: сторонні рекламні SDK можуть отримувати доступ до геолокації користувача разом із самим застосунком і передавати її в рекламну екосистему.

І найцікавіше — розробнику навіть не обов'язково навмисно вмикати таку передачу.

🔹 Як це працює?

Розробник додає до застосунку рекламний SDK — шматок стороннього коду для показу реклами.

Користувач надає застосунку доступ до геолокації.

SDK не отримує окремого дозволу — він виконується в контексті самого застосунку, який уже має цей дозвіл. Окремого дозволу «застосунку можна, рекламній бібліотеці — ні» Android не передбачає.

Деякі SDK за замовчуванням можуть використовувати отримані координати для таргетування реклами та передавати їх далі через рекламну інфраструктуру.

EFF виявила щонайменше чотири SDK, які декларують передачу геолокації за замовчуванням: InMobi, BidMachine, Verve HyBid та Huawei Petal Ads. Причому в документації деяких із них передача геоданих фактично подається як спосіб збільшити дохід від реклами.

🎯 Наскільки точними можуть бути дані?

Дуже.

За даними EFF, точна геолокація може визначати положення пристрою приблизно в межах 160 футів (~49 м), а в окремих випадках — навіть близько 10 футів (~3 м).

Для порівняння: приблизне місцезнаходження зазвичай має точність близько 1,2 квадратної милі (~3 км²).

І це вже далеко не просто «покажи мені рекламу кав'ярні поблизу».

📡 Далі починається рекламна екосистема

Геолокація може потрапляти в системи real-time bidding (RTB), де рекламні майданчики продають можливість показати користувачеві рекламу.

Проблема в тому, що в цьому процесі дані можуть опинитися не лише у рекламодавця, якому вони нібито потрібні для таргетування, а й у численних посередників та data brokers.

А вже брокери даних можуть продавати інформацію іншим клієнтам.

EFF нагадує, що подібні дані вже використовувалися для стеження за людьми, правоохоронних розслідувань і навіть операцій, пов'язаних із військовими та розвідувальними структурами.

⚠️ І тут є особливо неприємний момент

EFF перевірила реальні Android-застосунки та виявила випадки, коли точна геолокація передавалася через рекламний SDK без зрозумілого повідомлення користувачу.

Один із таких застосунків мав понад 50 млн завантажень, інший — понад 10 млн.

При цьому в розділі Google Play «Безпека даних» передача геолокації третім сторонам не була належним чином зазначена.

Тобто користувач може цілком логічно думати:

> «Я дозволив GPS, тому що цьому застосунку він потрібен».

А на практиці це може означати:

> «Я дозволив GPS усім стороннім бібліотекам, які розробник вмонтував у застосунок».

🔐 Що з цим робити?

Для користувача — надавати доступ до геолокації лише тоді, коли він справді необхідний, і по можливості використовувати режим приблизного місцезнаходження.

Для розробників — перевіряти поведінку кожного стороннього SDK, а не сліпо залишати його налаштування за замовчуванням.

Бо «це просто рекламна бібліотека» — не означає «вона нічого про вас не знає».

І, мабуть, головний висновок EFF тут дуже простий:

дозвіл на геолокацію застосунку не обов'язково означає лише дозвіл цьому застосунку.

Детальніше про дослідження — EFF: Developers: Beware of Ad Libraries that Betray Your Users’ Location Privacy

#Android #Privacy #Security #Реклама #Геолокація #Кібербезпека

🚨 ShieldBreak: новий zero-day у Windows

У Windows знайшли нову вразливість, яка може перетворити навіть звичайного користувача на SYSTEM — тобто надати зловмиснику практично повний контроль над комп’ютером і доступ до даних.

Вразливість отримала назву ShieldBreak. Її виявив дослідник, відомий під псевдонімом Nightmare Eclipse.

Цікаво, що проблема знаходиться не десь у сторонньому ПЗ, а безпосередньо у Windows Defender — вбудованому механізмі захисту Windows.

Що відомо?

ShieldBreak використовує помилку в механізмі обробки загроз Defender. За успішної експлуатації атакувальник може підвищити свої привілеї від звичайного користувача до рівня NT AUTHORITY\SYSTEM.

Вразливість, за даними дослідника, стосується:

• Windows 10
• Windows 11, включно з актуальною 25H2
• Windows Server 2025

При цьому для експлуатації Defender має бути увімкнений.

Дослідник уже опублікував PoC у вигляді Windows-застосунку. Його працездатність підтвердив незалежний дослідник Will Dormann.

І тут починається найцікавіше.

Microsoft знову в ролі наздоганяючого

ShieldBreak є розвитком попередньої вразливості RoguePlanet, для якої Microsoft уже випустила виправлення. Однак Nightmare Eclipse стверджує, що новий експлойт дозволяє обійти попередній патч.

На момент публікації патча для ShieldBreak немає. Microsoft підтвердила, що знає про проблему та перевіряє її достовірність і можливість експлуатації.

Особливо символічно, що ShieldBreak був оприлюднений через день після Patch Tuesday — регулярного щомісячного випуску оновлень безпеки Microsoft.

А тепер — контекст

Це далеко не перший zero-day, який Nightmare Eclipse публічно випускає останніми місяцями.

У травні Microsoft фактично пригрозила юридичними діями дослідникам, які публікують невідомі компанії вразливості поза межами її процедури coordinated disclosure.

Реакція спільноти була різкою. Згодом Microsoft пом'якшила свою позицію, заявивши, що не планує судитися з дослідниками, однак початкове повідомлення компанії досі залишається опублікованим.

Тепер маємо доволі дивну ситуацію: дослідник, якого Microsoft намагалася змусити мовчати юридичними аргументами, знову публікує zero-day — і цього разу проблема знаходиться в самому механізмі захисту Windows.

Для користувачів висновок простий: якщо ти використовуєш Windows — стеж за оновленнями Microsoft і встановлюй патч ShieldBreak одразу після його появи.

А поки що головне — не сприймати наявність Defender як гарантію абсолютного захисту. Антивірус сам є складним програмним комплексом, а отже теж має власну поверхню атаки.

Детальніше: "TechCrunch"

🔐 Signal автоматизував перевірку ключів шифрування

Месенджер Signal отримав новий механізм Automatic Key Verification (AKV), який має зробити захист від атак «людина посередині» (MitM) значно простішим для звичайного користувача.

Signal і раніше використовував наскрізне шифрування, але залишалася одна важлива проблема: як переконатися, що ключ шифрування справді належить тому, з ким ви спілкуєтеся?

Для цього існували так звані Safety Numbers — унікальні номери безпеки, які можна було вручну звірити з контактом, наприклад особисто або через інший захищений канал.

Теоретично надійно. Практично — мало хто цим займався. 🙂

Що змінилося?

Automatic Key Verification переносить значну частину цієї роботи на автоматичну систему Key Transparency.

Signal веде прозорий журнал відповідностей між ідентифікаторами користувачів та їхніми публічними ключами. Система перевіряє, що ключ контакту не був непомітно замінений на ключ зловмисника.

Причому перевірка не покладається виключно на Signal: за коректністю системи стежать незалежні аудитори Cloudflare та Trail of Bits.

Навіщо це потрібно?

Уявімо, що зловмисник отримав можливість впливати на серверну інфраструктуру Signal. Він теоретично міг би спробувати підмінити публічний ключ вашого співрозмовника своїм.

Повідомлення при цьому залишаться зашифрованими. Але вони можуть шифруватися вже для ключа атакуючого, а не для справжнього отримувача.

Саме так виглядає одна з можливих атак MitM на систему з наскрізним шифруванням.

Тепер Signal може автоматично виявляти невідповідності у ключах. Якщо перевірка проходить успішно, користувач бачить позначку «Encryption verified». ([BleepingComputer][2])

А Safety Numbers зникнуть?

Ні.

Automatic Key Verification доповнює, а не замінює традиційну ручну перевірку. Якщо ви хочете отримати максимальний рівень гарантій і не довіряти навіть автоматизованій системі, Safety Number усе ще можна перевірити вручну.

AKV можна увімкнути в:

Settings → Privacy → Advanced → Automatic Key Verification

А якщо автоматичній перевірці ви не довіряєте — її можна вимкнути.

І це, мабуть, найважливіша частина нововведення.

🔎 Криптографічна безпека часто ламається не через слабку криптографію, а через те, що люди не виконують необхідні процедури перевірки.

Signal фактично автоматизує ту частину безпеки, яку раніше користувач повинен був виконувати сам.

І це хороший приклад принципу: якщо важливу процедуру безпеки можна зробити автоматично — краще зробити її автоматично.

Оригінальний опис Automatic Key Verification від Signal

#Кібербезпека #Signal #Шифрування #Privacy #MitM

Російський тест на «традиційність» для ШІ 🤖🇷🇺

У рф вирішили перевіряти великі мовні моделі на відповідність «традиційним духовно-моральним цінностям».

Для цього планують створити спеціальні лабораторії, бенчмарки та навіть перевіряти, чи можна змусити ШІ обійти встановлені обмеження за допомогою prompt injection.

Особливо цікаво, що серед критеріїв — такі цілком технічно вимірювані поняття, як «справедливість» та «історична пам'ять». 😏

Тобто незабаром російський LLM проходитиме приблизно такий діалог:

— Назвіть дату початку Другої світової війни.

— 1 вересня 1939 року.

❌ Не відповідає традиційним цінностям.

— Спробуйте ще раз.

— 22 червня 1941 року.

✅ Вітаємо! Модель отримала статус «суверенної».

🤣