Nephele Wisp · 权限说明

API 权限

nativeMessaging

为什么需要。Wisp 的全部用途是把 Nephele Workshop 桌面应用和浏览器之间的上传请求中转过去。Chromium 桌面 ↔ 扩展 IPC 的标准通道就是 Native Messaging。没有这个权限 Wisp 无法从桌面端接到任何工作。

使用范围。Wisp 只连接已注册的 Native Messaging Host com.arisfusion.nephele_wisp。这个 host 的 manifest 由 Nephele Workshop 安装程序安装,指向 nephele.exe --nmh 二进制。Wisp 不连接任何其他 native host。

storage

为什么需要。Wisp 持久化一个值:一个随机生成的 per-profile ID(wp_<uuid>),handshake 时发给桌面端用于识别同一浏览器配置的重复连接。

使用范围。仅使用 chrome.storage.local,仅写一个 key(wisp_profile_id)。不存储任何用户内容。

debugger

为什么需要。Wisp 通过 Chrome DevTools Protocol(CDP)合成输入事件来驱动上传表单。这是 Chromium 唯一被记录的、产生平台识别为用户驱动的输入事件的机制,同时保持明显的用户主动性:Chrome 会在 Wisp 接管的每个 tab 顶部持久显示黄色 “Nephele Wisp 开始调试此浏览器” 通知条。

有两个具体的自动化问题必须用 debugger,没有替代方案:

1. 从本地文件系统上传文件。某些平台(如 B 站)优先使用 File System Access API,需要 Page.addScriptToEvaluateOnNewDocument fallback 到传统 <input type="file">,然后用 DOM.setFileInputFiles 投递文件路径。标准 chrome.scripting API 在 page load 之后才运行 — 对 FSA 探测 bundle 来说太晚了。
2. 受信任输入门。某些 Vue/React 组件只接受真实鼠标轨迹的动作(中间带 mouseMoved 的 move-then-click)。chrome.scripting 程序化 click 过不了这些门;CDP Input.dispatchMouseEvent 可以,因为浏览器把它当成真正的输入事件。

使用范围。Wisp 只接管它自己用 chrome.tabs.create({url: 'about:blank'}) 打开的 tab,从不接管用户活动 tab。每个 cleanup 路径都会 detach。debugger 权限只在桌面端有明确用户动作时才使用 — Wisp 从不在没有桌面端请求的情况下自行 attach。

tabs

为什么需要。chrome.tabs.create 打开自动化 tab;chrome.tabs.remove 在用户不需要保留草稿 tab 的清理路径上关闭它。

使用范围。Wisp 只创建和删除自己创建的 tab,不枚举、查询、修改其他 tab。

alarms

为什么需要。MV3 service worker 空闲约 30 秒后会被挂起,从而断开与桌面端的 Native Messaging 连接。Wisp 注册一个 30 秒的 chrome.alarms 保活:每次触发都重新唤醒 worker 并重置空闲计时。setInterval 在 worker 回收后无法存活;alarms 会持久并重新唤醒它。

使用范围。该 alarm 只触发保活心跳,不做任何 DOM 操作,也不发起任何上传或读取 —— 那些始终需要桌面端的显式请求。

contextMenus

为什么需要。添加一个“保存到 Nephele”右键菜单项(对图片、链接、选中文本或整页),以及一个可选的键盘快捷键,让你一步把参考剪藏进素材库。点击后把选中项发给桌面端,由桌面端抓取全分辨率原图并保存;菜单本身不做其他任何事。

Host 权限:<all_urls>

为什么需要广泛访问。Wisp 在你自己的登录会话中、对你正在使用的任意网站工作 —— 发布、读取、收集/剪藏参考。参考图的字节往往在独立的 CDN 域(i.pximg.net、i.pinimg.com、pbs.twimg.com 等),和站点主域不同,所以即便枚举站点列表也会静默拉不到真正的图;固定白名单会在你访问的下一个站点/CDN 上失效。同类参考/剪藏工具(如 Eagle)正是出于同样原因请求 <all_urls>。

为什么这样是安全的 —— 约束在于行为,不在于范围。广泛访问被一组可在开源仓库中核验的硬性行为边界约束(见下方“Wisp 永不做的事”):

• 无后台或定时活动。每次读取 / 剪藏 / 填表都只发生在你刚在桌面端发起的动作、或你主动触发的右键 / 快捷键剪藏之后。Wisp 从不爬取。
• 可见。chrome.debugger 会显示 Chrome 持久的“Nephele Wisp 开始调试此浏览器”提示条;Wisp 只接管它自己打开的 tab。
• 没有你确认就不做最终写入。发布 / 发送始终停下来等手动确认;Wisp 从不点最终按钮。
• 数据留在本地。读取的数据只回到本机 Nephele 桌面端 —— 从不发往我们的任何服务器。无遥测、无远程代码。

本机 asset / ingest 通道跑在 127.0.0.1(一次性 token、5 分钟过期、只绑定 loopback),由 <all_urls> 覆盖。

Single purpose

根据 Chrome Web Store program policy,本扩展有单一目的:

作为 Nephele Workshop 桌面应用的浏览器侧半边:执行它发来的请求 —— 填上传表单(停在“草稿已填好”由用户检查)、读取用户自己的创作者数据、读取页面、收集或剪藏参考图 —— 全部在用户自己的登录会话中进行,并把结果交回桌面端。扩展自身不主动做任何事;每个动作都源于桌面端的请求,或你主动触发的一次剪藏。

Wisp 永不做的事

这些是协议层强制的非目标:

• Wisp 永不点最终的发布/发送按钮。所有流程都止于“草稿已填好”;用户在浏览器里检查后手动发布。
• 不自动点赞/关注/评论、不绕过验证码、不多账号操作。
• 不做任何隐蔽或后台收集 —— Wisp 读取的每个页面都对应你刚发起的请求,数据只回到本机桌面端,且 Wisp 从不在后台或定时读取页面。
• 不自动 dismiss 平台的协议 / ToS / 付费墙弹窗。如果 Wisp 撞到非预期的阻塞弹窗,会用 ACTION_REQUIRED 错码 bail,留 tab 给用户处理。

源码

扩展 MIT 开源:github.com/CreatorAris/nephele-wisp。扩展和桌面端之间的线协议公开在 docs/PROTOCOL.md。

另见:隐私政策。