@mywaiting 我觉得更重要的是解决问题的思路，要勇于抛开一些陈旧观念，向前看

@mywaiting 没有 100%的安全

@luvxy 遇到问题，解决问题

@qdwang 在 vm 内部通过一些算法取出，所以你有可能能获取到，但是即使取到意义也不大，源码已经变成 opcode，因为你没有 opcode 的设计以及一个供其运行的 runtime

@qdwang opcode bytes 我们是会进行二进制混淆的，并且会对 bytes 进行二次加密，每次加密的 key 是随机的，你说的 shuffle 是在二进制混淆的阶段做么

@qdwang 没有 100%的安全（逃

@Mutoo 如果整体开源了就没有安全性可言了，流程和 opcode 设计都能看到，如果上传不信任当然也没办法了

@binux SecurityWorker 只是保证代码安全，但是其他安全流程是需要使用者去设计的，包括数据的签名检验防止重放，检验 key 唯一下发等等，防止被大规模使用，这不是 SecurityWorker 要解决的问题

@binux 哦，我懂你意思了，但是那样如何被大规模利用是个问题，我们还有一些环境监测，防止 node 运行，如果有时间可以试着破一破帮助我们改进（逃

@binux
1.上传代码
2.JS 翻译为 opcode bytes
3.二进制数据加密并重打包
4.核心压缩加壳
5.得到最终文件

运行时解密得到 opcode bytes，然后 vm 执行，除非你知道我的 opcode 设计，否则很难继续 debug

@binux 里面不存在 js 源码了，只会有离线翻译的 opcode bytes，opcode bytes 会做第二次加密

@tyrealgray 并不是，ob 实际上是混淆，但仍然可以通过代码逆出核心算法，相比 SecurityWorker 的强度来说低很多很多

@kimown 你嵌入 jsc 后和我们的做法就差不多了，邮箱在官网页脚有（逃

@polythene “ SecurityWorker 不同于普通的 Javascript 代码混淆，我们使用 独立 Javascript VM + 二进制混淆 opcode 核心执行 的方式防止您的代码被开发者工具调试、代码反向。”以及“ SecurityWorker VM 与 V8 等强调性能的 Javascript 引擎不同，SecurityWorker VM 主要目标是更小的 emscripten 生成体积以及更少的内存使用。对于 SecurityWorker VM 来说，我们并没有集成类似 V8 一样的 JIT 机制，而是使用通过离线翻译你的 Javascript 代码为 SecurityWorker VM 指令，然后在运行时解释执行的方式，因此在性能上会有一定的损失。”

@kimown 浏览器整个都是不安全环境，只要你的代码以原始代码动态执行在不安全环境，他就是不安全的

@kimown 不行，因为我可以拿到你的代码，然后改文件输入 debug，你可能会因为代码太大导致 devtool 崩溃，但我们还有其他办法，比如通过 chrome 的协议远程调试然后跟踪到你 eval 逻辑前，或者直接在你 eval 前 ajax 发送代码，file api 操作等。这些弯路我们都走过。

@kimown 是的，不然我们不会做 SecurityWorker

@kimown 你们 js 最终会被 eval 执行，那么就存在风险。SecurityWorker 是独立的 vm，代码会被编译为 opcode bytes 然后混编，不存在 eval 之类的动态执行。但目前跟 WebWorker 一样，没有 DOM/BOM，需要两个环境通信

@yixiang 并不是，是独立 vm 和执行 opcode，相比 ob 强度要大很多很多