最近做 WebRTC 视频通话 /t/1066232 的时候, 发现这东西有个很坑的地方.
只要第一次允许使用摄像头和麦克风后, 下次就能默认调用了. 被开摄像头时只会显示个图标而已.
需要在其他地方做处理决定是否接听才行.

@NewYear #10 谢谢提醒, 我这个确实颜色鲜艳了, 尤其是登录页的. 这个站的代码写起来不费劲, 但是调整界面用了好久.
@NewYear #11 这个东西的目的就是给人一个轻松说话的地方. 现在对一些 IM 的私聊也不放心.

@iqoo #4
@0o0O0o0O0o #5

只是全站静态资源 hash 固定还不够 也不够灵活

还要要求原始的代码够简单, 不说能完全让人读懂, 但至少能粗略审核保证没有主观恶意或漏洞/后门

要保证从服务器动态获取的只有数据, 不能有执行代码, eval 和动态加 script 标签肯定不行.
(注: 我的 webd 网盘的早期版本就是远程加载 js 文件, 当时想的是将来灵活加广告.
近期版本都改成了请求远程数据, 解析成链接加上去, 即便服务器被攻陷了, 用户也很安全.)

如果浏览器发现网站代码更新了, 做一次简单的分析, 改颜色改大小改文字图片这种, 可默认放过.

js/wsam 代码则用 AST 语法树分析, 给高级用户们显示个比较直观的 diff 代码, 给麻瓜们显示这次修改的风险等级.

这个原则下的网站/APP 需要做到真正小而美, 一坨坨的东西肯定不行.

Q: 如果依赖了太多东西整体庞大分析起来费劲怎么办?
A: 被依赖的东西做成标准模块, 带上签名, 避免重复分析.

下面的贴提到一些杀毒软件在做类似的工作, 但不是标准化行为.
/t/1064948 火绒 SSL 流量嗅探？

我觉得以后浏览器应该考虑这个东西, 毕竟现在浏览器已经是操作系统了.
如果有认识 chrome 或 ladybird 浏览器的大佬, 可以提一下这个想法.

@Michae1Jacks0n #4 确实有这个问题, 应该加上这个提醒

@zhng920823 #13 总是忍不住要按嘛?

@daqing #11 开始不要考虑那么多

搭车推荐我的匿名聊天室 /t/1066232 可 WebRTC 视频 可任意创建聊天室

@0o0O0o0O0o #1 大佬果然博学

厉害了, 不错的检测思路

@z1645444 #8 有不少积累的代码, 直接用了.

@z1645444 #6 多谢夸奖, 这个访问速度应该能保持住的. 只要体积够小加载就够快. 后端优化我比较擅长, 直接 C 写的 web/websocket 服务器.

文字文本用我的聊天室 /t/1066232
文件用我写的网盘 https://github.com/webd90kb/webd

@PbCopy111 #2 还是不太一样的, 我这个主要是自己创建自己拉人的情况
如果碰到相联系但又不想透露其它联系方式的, 或不想在别的软件上留下记录的.
可以创建一个新的聊天室, 把链接发给对方即可聊天.

你这个 antiland 主打的是随机匿名吧. 另外你说的这个不用部署是什么意思.

@rekulas #4 让你见笑了, 写前端的水平太差

如果进入聊天室后发现没人, 应该也是正常的. 新开一个标签页再打开上面的链接就能看到有两个人了.

或者用别的设备打开上面的链接. 可自己和自己体验视频通话.

刚做了一个, 能文字群聊, /t/1066232
前端加密后发送到服务段转发的, 理论上服务端看不到内容
支持 1 对 1 视频聊天.

在两端都有 IPv6 的情况下, 不管双方的光猫路由器防火墙的配置情况, 多数情况 WebRTC 是直连的.

还有两边都是 OpenWRT 路由器, 只有一边的路由器有公网 IPv4, 跨运营商, 没有开启 uPnP, 没有配置 DMZ, 没映射端口, 关了 IPv6, 的情况下 WebRTC 也能直连. 不知道它是怎么穿透的 NAT.

webrtc 视频通话, 大多数情况下能直连.
如果不能直连会通过 TURN 中转, 可能比较卡.

可输入 组名 密码 昵称 创建分享链接, 然后把分享链接放入收藏夹, 以后可直接点开使用.

手机浏览器打开分享链接后, 用手机浏览器菜单的 添加到主屏幕/Add to Home Screen 可在桌面生成图标. 打开后是全屏显示的, 用起来有些类似 APP.