前端安全问题主要围绕两个方面：①策略泄露 ②策略遗失 我们做了大量设计与开发相关工作来解决这两点

避免策略泄露

我们采用了重前端无后端服务器的设计方案，使得创建预言机时的策略加密原象信息只保留在本机前端中，通过物理隔离和网银普遍采用的浏览器同源策略，使得个人加密数据不被第三方破解。

无服务器设计：防止泄露到浏览器之外

通过浏览器访问https://play.nashpt.co，通过SSL的443端口下载到您浏览器中的前端界面，与官方服务器是无后续通信的。这样的设计避免了策略被官方获知的可能性。

您也可能自行下载前端开源源码代码@Github 在您的本机直接运行该前端，并通过Metamask与区块链上的智能合约进行交互。
前端源码并没有使用Webpack之类会降低人类可读性并提高人类可读成本的框架进行开发，源码开源并直接可读，为的就是让您能放心使用，不必担心自己的策略原象被发送至浏览器以外的第三方。

Webpack 是一个模块打包器。它的主要目标是将 JavaScript 文件打包在一起,打包后的文件用于在浏览器中使用。

浏览器同源策略：防止在浏览器之内泄露

纳什协议的加密原象保存在浏览器的LocalStorage中，该储存受到浏览器同源策略标准的保护，使得不被其他页面的JS代码访问。浏览器的同源策略wiki

浏览器的同源策略能有效防止其他Tab的页面获取纳什协议Tab页面下的LocalStorage。利用同源策略+LocalStorage是许多网页钱包的标准开发方案例如下面图中这些项目，是直接将私钥放在前端中。
这比纳什协议的前端只是将临时的加密Hash原象放前端中要狠多了……狠多了……狠多了……image.png

Myetherwallet中直接用私钥作为JSON数据的PrivateKey：0x8bc5a567c46444ad18ed49db896acaee92c2861508c1e175be1e548f9b163532 导入之后的地址就是：0xe30CEae388c0a31c95dBcc88faC817Af9dC9267e

image.png

circles.ubi 为了简化用户操作，直接把privateKey放在前端的LocalStorage中，通过安全路径来派生出安全地址

避免策略遗失

上面我们设计了系列方案来防止您的策略被除了您以外的其他人获知的情况。 但同时，我们还需要设计另外方案，来防止以下情况的发生： —— 您的策略只有上帝知道。 ** 为了避免出现策略遗失，导致预言机创建人无法提交原象进行最终仲裁。我们设计了策略缓存方案，来避免以外情况下的策略遗失。

策略缓存

由于从发起交易到链上确认与传统互联网应用相比较长的时间差，通常为10秒到10分钟不等。在交易被打包并返回预言机ID之前，由于存在同时多个预言机被创建，或者创建失败的可能性，又因为矿工在对多个交易进行打包排序的细节是我们无法掌控的，所以我们无法确定您创建的预言机的具体ID是多少。
在等待打包成功这段时间内，可能由于各种各样的原因导致页面被刷新，监听被取消，但是在这之后交易也可能依旧被打包成功。
所以，针对以上情况，我们将在您调用metamask发起交易钱包弹出，且您确认交易发送之前，对您的策略做一个无预言机ID的本地缓存。
只当创建成功之后，才会通过预言机ID作为key来储存加密参数的系列value。并同时删除最近一次的缓存释放空间。

策略恢复

在之后提交仲裁Anneal的时候，我们会优先获取【预言机ID作为key来储存加密参数的系列value】，如果查找不到，便会去之前的缓存中获取加密Hash，并使用该加密Hash去链上日志中获取对应的预言机ID。
这种方法可以避免因为操作不当导致的策略丢失，但是并不能完全依靠这类方法，所以在弹出提示框，要求不要刷新的时候，请尽量遵照提示。

缓存回收

鲁棒性设计：tips：↓
image.png
创建时由于需要通过获得链上的ID来保存本地对应预言机创建时的加密参数，所以尽量请不要刷新。
image.png
当然，即便刷新也不会丢失，因为在弹出确认信息点击确定之后，就已经将相关参数保存到本地安全隐私缓存中，如果在仲裁时发现相关加密参数丢失，会自动从链上请求对应加密hash的预言机，并获取对应的IDimage.png
此处演示了从LSCache(LocalStorage Cache)中恢复#13号预言机的LSSent(LocalStorage Sent)的全过程。
这种暂时丢失是由于在钱包签名并发出交易，而Pending界面还未收到链上确认的回调执行界面关闭并按OracleID储存加密Hash，页面就被刷新和关闭导致。
image.png

所以尽可能不要在以上窗口出现且您已经在钱包发送了交易的时候【关闭】或【刷新】页面。