Hacker News Digest

AliExpress на главной странице тайно запускает два скрытых WebAudio-контекста через обфусцированные скрипты collina.js и fireyejs.js от Alibaba. Эти контексты генерируют синтетический сигнал (пилообразную волну), анализируют его через AnalyserNode и передают на аудиовыход через GainNode с громкостью ноль — так что пользователь ничего не слышит. Однако подключение к аудиоустройству заставляет систему активно обрабатывать аудиопоток, что мешает Bluetooth-наушникам с мультипоинтом переключаться между устройствами: даже при отключении звука в браузере или ОС переключение не работает.

Это не реклама и не медиа — а метод браузерного фингерпринтинга, используемый для антифрода. Скрипты собирают уникальные характеристики устройства через аудио-анализ, но не сообщают пользователю о своей работе. Проблема в том, что такой скрытый аудиопоток влияет на аппаратное поведение внешних устройств, обходя стандартные механизмы блокировки звука. Блокировка этих двух скриптов через uBlock Origin полностью решает проблему — наушники возвращаются к нормальному режиму работы, а фингерпринтинг прекращается.

Скрытый аудио-фингерпринтинг на AliExpress — не изолированный случай, а часть системной проблемы: аналогичные техники используются на Twitter, Stripe, Wolt, немецких новостных порталах, сайтах с рекламой, капчей и DRM. Он нарушает Bluetooth-мультипоинт, перехватывая аудиофокус у наушников (включая AirPods) и звуковых панелей, вызывая случайные переключения источников даже при отсутствии слышимого звука. Пользователи отмечают скрежет, скачки громкости и блокировку фоновой музыки — особенно на iOS, где вкладки продлевают работу через удержание аудиосессии. Браузеры не показывают значок динамика при тихом воспроизведении — это сознательное решение, а не ошибка. Проблема возникает на уровне аудиодрайверов и управления потоками, подтверждаясь даже при использовании SPDIF. Фингерпринтинг не требует разрешения пользователя, не использует микрофон или камеру, и обходит проверки App Store, так как WebAudio-код не выглядит как скрытая функция. uBlock Origin и аналогичные фильтры эффективно блокируют аудио-фингерпринтинг, доказывая, что проблема — в коде сайтов, а не в браузерах или ОС. Хотя современные браузеры (Chrome, Firefox, Safari) частично нейтрализовали WebAudio-фингерпринтинг унификацией выходных данных, он не устранён полностью. Предлагается ввести разрешение на доступ к аудиовыходу, как для камеры и микрофона, и внедрить проактивную блокировку подозрительных WebAudio-шаблонов браузерами — не полагаясь на пользовательские фильтры. Споры остаются: одни считают это творческим обходом ограничений, другие — нарушением Computer Fraud and Abuse Act. Apple не может выявить такие манипуляции через ревью приложений, так как они невидимы в коде.

Qwen 3.8 27B — Alibaba‑разработанная 27‑параметровая LLM с поддержкой визуального ввода, работает под лицензией Apache 2 и умеет генерировать сложные SVG‑рисунки, но по умолчанию включает «xhigh»‑уровень рассуждений, который превращает простые запросы в часы‑долгие раздумья. На ноутбуке с 128 ГБ RAM и на сервере NVIDIA DGX Spark я использовал 17 ГБ‑квантованную версию в LM Studio, увеличив контекст до 262 144 токенов; при включённом рассуждении модель потратила 21 минуту на создание SVG‑картинки пеликана, а без него — лишь 2 минуту, получив менее детализированный результат.

Запомните:

• 27 Б‑модель помещается в 17 ГБ файла и способна к полноценному генеративному рисованию и коду.
• Параметр reasoning_effort (xhigh/medium/low) сильно влияет на скорость; отключив «xhigh», время генерации падает почти в 10 раз.
• При работе через llama.cpp с MTP‑режимом (draft‑mtp) ускорение достигает ~72 % по сравнению с базовым GGUF‑режимом.

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

Избыточное рассуждение — системная проблема современных LLM, не уникальная для Qwen 3.8: аналогичное поведение у Opus 5, Claude и других моделей. Оно вызвано RLHF и дистилляцией, где перерассуждение выгодно для бенчмарков, но вредит интерактивному использованию: замедляет ответ в 7–9 раз, увеличивает токен-расход и снижает эффективность. Qwen 3.8 27B работает на потребительском железе (M4/M5 Max, 48–128 ГБ RAM), превосходит по качеству 3.6 и сопоставима с Opus 4.6 и Codex 5.3, но из-за медленной работы и неэффективности по токенам непрактична без настройки. Для локального использования рекомендуется квантованные версии Q4, а не 16-битные веса. Уровень рассуждений можно контролировать: через шаблоны GGUF (например, Froggeric), параметры llama.cpp (--thinking-budget, --thinking-message) или принудительные хаки (например, fork @shifto), отключая 'xhigh' и используя 'none' или 'low'. Это снижает задержку, но может слегка ухудшить качество. Для разработчиков — динамическое управление уровнем рассуждений по запросу. Скорость на CPU — до 8 минут на задачу, на GPU — до 11 часов на сложные; при частом использовании облачные API (например, Luna) экономически выгоднее. Модель способна находить баги в фреймворках (например, Next.js), но только после десятков часов рассуждений — непригодна как быстрый отладчик. MTP-слой позволяет предсказывать 6–8 токенов с высокой точностью, что частично компенсирует избыточность в генерации кода и SVG. Избыточное рассуждение делает модели неэффективными для продакшена, где важны скорость и лаконичность, а не идеальный бенчмарк.

Ollama представила новый API для веб-поиска, который позволяет моделям получать актуальную информацию из интернета, снижая риск галлюцинаций и повышая точность ответов. Бесплатный тариф доступен для индивидуального использования, а повышенные лимиты — через Ollama Cloud. API интегрирован с Python и JavaScript библиотеками, что упрощает создание инструментов для длительных исследовательских задач, включая работу с моделями вроде OpenAI gpt-oss.

Примеры кода демонстрируют использование через cURL, Python и JavaScript, возвращая структурированные результаты поиска с заголовками, URL и содержанием. Также показано, как построить поискового агента с помощью модели Qwen 3 от Alibaba, используя инструменты web_search и web_fetch для автоматизации запросов и обработки данных. Это расширяет возможности моделей, позволяя им активно взаимодействовать с веб-источниками в реальном времени.

• Вопросы о поисковом провайдере и лицензии на результаты поиска, включая возможность их хранения и перепубликации.
• Сомнения в бизнес-модели Ollama, её переходе от локального хостинга к облачным услугам и планам монетизации.
• Обсуждение технических альтернатив для локального поиска и индексации, а также интеграции с Ollama.
• Критика запуска функции веб-поиска без четкой документации по тарифам, лимитам и политике конфиденциальности.
• Предложения и опыт использования сторонних инструментов для поиска (SearXNG, Tavily, SERP API) и локальных решений.