Google设立的Chromium浏览器安全奖励计划想必大家都还记忆犹新，找出漏洞并成功修复的人将有重赏，总计将有100万美金用于奖励支出。想看看Chromium的开发团队对于安全性问题的看法吗？ 别跳出来挡道 确保用户的安全就意味着需要仔细地平衡产品的可用性、性能以及安全性。如果我们实现的很好的话，所有这些因素应该能够紧密的关联在一起而且这一切对用户来说这几乎是透明的。我们通过透明式的自动更新来避免给用户带来过多的升级提示，并且避免出现弹出对话框这类东西，这些只会让有条件的用户忽略安全提示。当安全提示确实有必要出现时，确保提示的内容清晰明了，而且只将最重要的信息着重呈现出来，比如地址栏中的用户名和SSL状态。 我们设计Chrome的安全性架构的目标就是实现层级性防御，并且要避免出现单点故障。Chrome的沙盒架构代表了这种策略中最有效的部分之一，但这离完整的架构还远着呢。我们也采用了最优秀的反攻击技术——包括ASLR、DEP、JIT hardening和SafeSEH，以及我们在Chrome OS项目中自定义的技术像是Safe Browsing、out-of-date plugin blocking、silent auto-update以及verified boot。我们将继续努力研究，并推进关于沙盒和控制流完整性等方面的研究成果。 有一种常见的误区，那就是安全性只是产品的一种特性或者是可增加的组件。事实上，任何复杂的软件产品的安全性问题都是横跨领域的，由数百万个看似无害的决策而定，这些决策每天都会在开发者脑中跳出来。这就是为什么对于开发团队的每个成员来说都要注意安全开发实践准则，并协同安全团队一起在整个项目的生命周期内协同工作，这一点至关重要。开发人员对于安全开发的常识性认识有助于我们在正常的安全审查过程中完成审计和回归测试。 用户的安全性取决于快速响应并解决安全漏洞问题，无论这个缺陷是内部测试发现的还是由第三方提交的报告中出现的。我们致力于解决所有的安全性问题，并通过快速自动更新机制来提供给我们的用户。这种方式让我们在处理安全缺陷问题的响应时间上一度保持着业内领先水平。即使是在处理一个复杂的以及带有政治色彩的问题上，尽管我们并不是内容发布的源头，但我们依然尽力去解决了（这就是传说中的内容审查和过滤机制吧）。 我们不会去淡化安全性问题带来的影响，或者通过默默的升级来掩埋缺陷，因为这么做对用户的体验来说是很差的。相反的，我们会提供给用户和管理员他们所需要的信息，以此来准确定位和评估风险。我们已经对外公开了我们的安全性问题处理步骤文档，关于Chrome以及依赖于Chrome组件的缺陷报告，凡是修补过的我们都已经关闭了——不管是我们内部发现的还是外部报告的。只要有可能，我们就会在release note中列出所有已经修补过的安全性问题，并公开底层的细节，只要其它受此影响的项目有足够的时间来应对。 |
