这是一个创建于 1463 天前的主题，其中的信息可能已经有所发展或是发生改变。
从 2022 年 1 月 17 日，Chrome Web Store 将不再接受使用 Manifest V2 方法所构建的新扩展，但对现有扩展的更新仍然可以提交。
赶在 Chrome 停止接收前，成功用自己的信用卡（广发 visa ，似乎是美元单币种的）付了 Chrome Web store 的 5 美元 开发者账号 费用（弄了个美国 IP 的公共代理，不用填具体地址，只要了个美国邮编）。
秒过，直接收到消费短信，账号马上能用！
不然坑爹的 Google Manifest v3 可没有 webRequest 了。（以后很多保护隐私的扩展将要死掉）
]
把我的扩展从 Firefox 移植了几个过去。其中我最近在搞的一个搜索引擎扩展，有空可以重点给大家推荐一下
 | 1 cairnechen 2021-12-29 09:47:33 +08:00 所以现在立刻注册的意义就是赶紧上架几个 Manifest V2 构建的扩展，以后停止使用了，还可以继续更新？我怎么感觉最后还是会被全部干掉的 |
 | 2 garywill OP @cairnechen 我上的几个扩展中有 2 个是必须 webRequest 的（盾牌那两个）。其他的是 v2 v3 都可以，这些才是买账号的重点。 确实以后 Google 打算全部干掉 v2 的。幸而，我自己用 Firefox 做主力。Firefox 的 v3 将也提供 webRequest 。 |
 | 3 jy00566722 2021-12-29 12:11:32 +08:00 via iPhone Google 为了自己的广告，干掉 webRequest |
| 4 cairnechen 2021-12-29 12:16:48 +08:00  3 楼上怎么搞得是 Google 先搞的一样，是我 Apple 提不动刀了？ /t/811293 给大家科普下，iOS 的 Safari 15 支持扩展，是指通用的 Web Extension ，但也又有一部分 Web Extension API 不支持的，例如拦截广告需要的 webRequestBlocking ，所以 uBlock Origin 这种老牌广告拦截器注定无法移植到 iOS 上。作为取代，iOS 提供 declarativeNetRequest ，其实就是 iOS 9 提供的“内容拦截器”变种而已。 Chrome 也是一样，在新版的扩展标准 Manifest V3 ，也不提供 webRequestBlocking 了，只提供 declarativeNetRequest ，所以 uBlock Origin 一样无法移植到 Manifest V3 上，一堆人很大意见。 两种 API 的区别： * webRequestBlocking 浏览器告诉扩展用户每个请求的完整 URL ，扩展返回决定是否拦截。扩展得到完整 URL ，可以做其它事，例如把 URL 发送到自己的服务器记录下来。 * declarativeNetRequest 扩展告诉浏览器一些像正则表达式那样的“拦截规则”，浏览器自己做判断是否匹配拦截，扩展无法得知每个请求的完整 URL ，有效保证用户隐私。 如果在 iOS 的 Safari 的“扩展”管理页面，看到“内容拦截器”，说明使用了 declarativeNetRequest 这个 API ，所以在 iOS 上安装 Safari 去广告 App ，本质就是订阅了一堆拦截规则而已，就看谁家的写的规则够丰富而已，底层技术都一样，由浏览器提供，玩不出任何花来。 |
 | 5 dingwen07 2021-12-29 14:49:59 +08:00 一年之后也没了： > January 2023: The Chrome browser wll no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions. 微软似乎不打算去掉： > The Microsoft Edge extensions team replaces the Web Request API by the Declarative Net Request API, but we continue to keep the observational capabilities of the Web Request API. We recommend using the Declarative Net Request (DNR) APIs only, rather than the Web Request API, except in some specific scenarios where observational capabilities of the Web Request API are required by the extension. 微软，行！ |
| 6 dingwen07 2021-12-29 14:51:17 +08:00 1 #5 仔细看了下，Edge 也不支持 Blocking Behavior 。。。 |
 | 7 mywaiting 2021-12-29 15:50:55 +08:00 无论买不买开发者账号，Manifest V2 迟早都是会被干掉的，只是会留点时间给开发者迁移到 V3 吧 邮箱里都收到两个要求迁移的邮件了~ |
| 8 garywill OP @dingwen07 说到微软 Edge 我要吐槽！我的搜索扩展 https://github.com/garywill/BigSearch 直接不给上架 原因是？呵呵！必须是搜索引擎公司才可以做与该搜索引擎相关扩展。因此我的这个搜索引擎聚合 /切换工具直接被拒了，看这里 https://stackoverflow.com/questions/68612114 ms 守着个自己的破 bing 还不让搜索工具上架 (当然，上架 chrome 了谁还管 edge store 。还好搜索不需要 webRequest blocking) |
 | 9 journey0ad 2021-12-29 18:20:55 +08:00 这个变动会影响到油猴类扩展吗 |
 | 10 butanediol2d 2021-12-29 19:31:16 +08:00 @journey0ad 应该不太会吧，Safari 也有油猴，用起来没啥区别。 |
 | 11 kidonng 2021-12-29 20:04:08 +08:00 via Android @journey0ad UserScript Manager 并没有提供网络拦截器权限，所以禁用了也不听新闻。 |
| 12 kidonng 2021-12-29 20:04:45 +08:00 via Android 听新闻 -> 影响 Gboard 日常坑爹 |
 | 13 muzuiget 2021-12-29 21:14:58 +08:00 @journey0ad 会，油猴会死掉，Manifest V3 还有个限制是禁止“运行远程代码”，就是说简单禁用 eval 函数（或者类似 Javascript 特性），因为 eval(string)，你没有办法判断这个 string 是在服务器抓取的， 还是用户手动输入的，还是打包进扩展的，精准打击了油猴扩展场景。而且 eval 有时候是合理使用的，比如一些字符串模板引擎库，把一些模板里的 DSL 语法预先编译成函数，以提高运行效率。 所以一大批扩展在 Chrome 商店上会死掉，但是只要 Firefox/Edge 不跟进，就是抢用户的好时机。 |
| 14 kidonng 2021-12-29 21:43:49 +08:00 via Android @muzuiget 应该还是有回旋余地的，打击 content blocker 还能说是给自家业务找借口，跟 power user 的需求过不去属实自找苦头了 https://github.com/Tampermonkey/tampermonkey/issues/644#issuecomment-858224952 最糟糕的情况也无非是 userscript manager 变成一个本地生成未打包插件的工具，办法总是有的 |
| 15 muzuiget 2021-12-29 21:50:36 +08:00 @kidonng 开发者模式一样会弹出警告。 竟然都那么麻烦了，还不如自己编译一个 Chromium 把这些 API 开放出来，所有第三方 Chromium 浏览器开发商都有这个实力，还可以自建扩展商店，让用户用脚投票，根本不用鸟 Google 。 |
Select Language