一名用户发现Chrome浏览器播放B站等网站视频时,CPU单核长期满载、核心温度升至约70°C,风扇噪音明显,随即展开排查。最初怀疑硬件解码失效,设置后无效;通过进程监控发现chrome的SpeechRecognitionService子进程CPU占用在20%至135%间波动,且人声密集的视频负载更高,暂停视频后占用立即归零。禁用全部扩展、怀疑字幕翻译插件均未奏效,而无痕模式下播放恢复正常,成为关键线索。用户离线检查配置文件,发现唯一激活的字幕项为headless_caption_enabled=true,但手动改为false后,Chrome运行时会在数秒内将其写回true;删除SODA目录后重启又会重新生成,常规手段无法关闭。通过逆向分析chrome.dll,确认真凶是Chrome 155内置的Glic(Gemini in Chrome)媒体理解模块,该模块会自动分析网页视频音频,且代码中将YouTube排除在外。由于chrome://flags中无相关开关,作者编写Python脚本,在Chrome完全退出的状态下修改Local State与各Profile的Preferences文件,显式禁用headless-live-caption、glic.media_understanding_enabled等配置项。应用修复后,播放视频时CPU核心温度降至40°C,风扇恢复安静。
事件分析
核心观点:浏览器正沦为AI功能的强制分发渠道,用户对自身设备算力的支配权,正在被默认开启的策略悄然收回。
原文链接:Linux.do

评论前必须登录!
立即登录 注册