一. 功能定义
首先要从功能上明确无痕浏览的作用和目的。涉及的功能包括: Bookmark, History (Input, Browse, Download, Forms/Auto complete), SSL Certs,Cookie, Local Storage, WebSQL, Application Cache, HTTP Cache,Disk Cache,Web App/Plugin 以及所有这些可能会引起持久化及透露用户信息(如Gelocation, Notification)的功能项。
*还有剪贴板中从无痕浏览模式下复制出来的内容。
行为上主要区别正常模式与无痕模式的相互影响, 三个问题:
1. 什么可以清除
2. 什么可以禁用
3. 什么可以相互共享，
其中包括三个场景:
1. 从正常模式进无痕模式
2. 从无痕模式退出到正常模式
3. 再次进入无痕模式 (与之前无痕模式的关系)
以下是一份针对流行的浏览器进行的调查 (原文在这里, 时间大概在2011年)。 针对项目包括进入无痕模式前的信息是否会在无痕下使用(下表):
以及退出无痕模式后，是否可以在正常模式下使用。
在前一无痕模式下设置的项目，是否可以在下一次无痕模式下使用:
这是一份比较系统的梳理，很有指导意义。
BTW, 这篇文章也做了进入无痕浏览模式的主要浏览内容的占比, 还是很有代表性的。
二. Chrome的实现方式
Chrome的做法则完全将无痕浏览与正常浏览区分开来，没有共享这些资料。我大致过了一下Chrome的代码，其核是通过Profile的机制来完成的，无痕浏览下对应off the record profile (OffTheRecordProfileImpl in off_the_record_profile_impl.cc 以及OffTheRecordProfileIOData in off_the_record_profile_io_data.cc)。
每一个profile可以视为不同的帐号的session，彼此间从数据上隔离开来。很多类实现了ServiceIsCreatedWithProfile并且返回True, 用来表示在无痕模式下将共享profile。
比如在profile::GetSpecialStoragePolicy()指定一个存储策略，在其它需要的类(如StoragePartitionImpl)中必要的时机调用它进行处理。
下面是Google文档的描述:
Profile should be a minimal reference, a sort of handle object that doesn't own the world. There were separate versions of Profile for Normal, Incognito and Testing profiles. In this world, the Profile was the center of all activity.
以下是Chrome无痕浏览模式涉及的Cookie和Storage的类图，其中CookieMonster和DOMStorageArea各有一个负责持久化的成员store_和backing_ (directory_为空时，backing_不创建)， 从OffTheRecordProfileIOData初始化开始，会指定不同的参数使得CookieMonster和DOMStorageArea没有持有一个可用的持久化对象，只能操作各自的map, 以此达到设计的目的。这样做的目的，可以有效区分内存操作和持久化的逻辑，方便上层的控制。
详细的代码还需要进一步学习，至少可以了解到关于无痕浏览这是一个需要系统加以组织实现的方式。
*参考:
http://www.cnblogs.com/kwliu/archive/2013/06/06/3116053.html
三. 安全问题
无痕模式面临的另一个问题是一些潜在的恶意软件的问题。比如下面这个链接就是作者展示进行无痕浏览时，可以从PageFile.sys和RAM中找到浏览记录:
http://www.magnetforensics.com/how-does-chromes-incognito-mode-affect-digital-forensics/
在上面提到的文章中，结尾处也提到了安全性的问题，可见这个问题的重要性。
基于以上对于无痕浏览的理解，下一步可以规划再深入理清问题，研究Firefox的实现方式，以方便评估改善计划。实现上未必需要以Chrome的profile方式，只要能够将用户数据有效的组织和分离就可以了。
转载请注明出处: http://blog.csdn.net/horkychen
