接上回 如何反广告拦截？

很多人说了可以直接操作 dom，由此想到，如果我写一个主打 view 的(组件库 | 框架)，在 build 的是 view 是由 canvas 全程渲染的，整个网页只有 html 、body 、canvas 。

负责路由，video 、audio 、img 之类的多媒体渲染，等，很大程度接管现在浏览器做过的工作，感觉要做的东西太多，很可能会变成一个框架。。。类似 react 、flutter 这样的东西。

不过没做过也不知道性能如何，那么可以一步一步来。 比如就先做一个利用 canvas 渲染的一个 dom，然后可以在网页局部使用。

比例可以在列表页，这样正常的元素和广告元素就无法利用 dom 去除了，再加上我上个帖子里提到的网络请求方式。知乎和微博就适合这种，feed 列表用我这个东西去渲染，然后其他地方还是原来的 html，影响也小。

在使用这个(框架 | 组件库)的时候，可以考虑用 js 编写 reader 或者也可以像 flutter 一样嵌套写 dom(编译时当然会变成 js)

因为要框架自己去渲染，所以就不能使用 css 了，只能在 reader 里为这个节点去设置样式，就和 flutter 一样吧。

大家有什么建议不？当然大家格局也别那么小，虽说一开始是拿来反广告拦截，但是换种思路，是不是也可以国外服务器防中间人串改呀？对不对？。。大家发挥脑洞

你要真整这么一个框架出来，做广告拦截的理论上也可以用 Monkey Patch 之类的方法到你框架的内部，把渲染广告之类的业务逻辑屏蔽掉。而且你这框架如果真要做完善，等于直接一个新的浏览器了，从工作量上考虑就几乎无法完成。
要我说，真要完美屏蔽广告，可以参考云游戏的做法，搞个云浏览器，把 DOM 节点之类的渲染工作也全部放到服务端做，客户端能做的只有转发用户的键盘鼠标输入，这样就基本不怕反广告了，你把满屏都塞满广告都没人能去的了

用 webassembly 编写业务逻辑呢？

你要真有功夫去用 WASM 去写业务逻辑，那还不如直接上 C++ 写桌面客户端，体验比网页端好，去广告也比浏览器难。

把用户往 app 里赶
国内大厂就这么操作的

建议给用户放直播，只不过是实时操作的

同志，这和防 MITM 不沾边。如果你乐意的话，可以给 DOM 上 HMAC, 然后再检查浏览器 DOM 的 HMAC 是否匹配。但这样最终是逃不过浏览器内的各种魔改的：我可以屏蔽你的检查脚本；我可以 hook 进你的检查脚本，在你检查完毕之后再修改页面；我甚至可以通过透明代理直接将整个页面内容拦截重写，只保留我需要的那部分；如果有流量加密，那我就找到渲染广告的部分，再屏蔽这一块，广告虽然被请求也不会被渲染——就算你的框架有混淆，我也可以通过 DOM 修改断点找到关键部分；如果说再带上全量 Canvas 渲染，性能会变得特别成问题，以及届时你会发现自己在用 JS 实现一个浏览器内核，以及你得想办法让搜索引擎能读懂这一堆东西。Good luck, have fun.
防止页面内容被篡改的唯一方式是：不可能，除非用户主动参与校验。或者放弃 B/S 转战 C/S, 后者你甚至可以自己再在 TLS 之上加一个非对称加密，这样就算通过透明代理也难以过滤任何请求。但这么折腾下来，值得么？屏蔽广告的人不是你的广告受众；不屏蔽广告的人也不会对你的广告产生兴趣；页面上堆了一堆的无关内容只能导致 PV 进一步下降；性能损失带来的还包括搜索引擎降权。

好蛋疼啊，这让我想到了以前有种电视节目类型，通过拨打声讯电话，点播节目。。。

建议快进到服务端渲染，通过 gif 串流传输到用户页面，然后通过 Server Side Image Maps 技术拿到用户点击的相对坐标
大体框架如下



全程无需 js 参与，兼容性直接爆表，下到 ie 5.0 （包括 windows ce 上跑的那个）上至最新 chrome 90 都支持
这样要屏蔽大约得上机器学习语义分割（