很早以前 就基本不用IE了，Firefox的标签页做的很好，对于我这种标签控来说，似乎这样的界面就能一劳永逸解决我的乱七八糟的任务栏的问题了。直到后来Google大张旗鼓的推出了Chrome浏览器，有被它的急速所吸引，于是改投Chrome阵营。可是不知为啥，有段时间在学校（其实就是我们系那幢楼），Chrome无法打开Gmail, Google Reader等一干内容。阉割掉Google的服务的Chrome简直就一无是处。于是只好继续趴在Mozilla阵营。期间写给网管邮件无数。网管估计是不会考虑这种小鱼小虾的需求（说起来此人对Faculty member那可是真恭维啊，不可同日而语）。最近学校统一升级networking infrastration, 终于搞好了网络，现在上Chrome，一点问题没有。坚决去掉Firefox，家里的Ubuntu也和FF说byebye了。
Chrome到底有多好？在同样的我的机器上（一台烂机），Mozilla自己的Javascript测速页面。FF8 的时间是Chrome的两倍。=.=b
不过全面变革成Chrome带来的一个问题就是FF插件的迁移。其他的还好，但是两个FF插件的失去让我觉得简直是断腕之痛：Echofon和HTTPS Everywhere. 前者是FF下面最好用的一个Twitter客户端，后面一个就是著名的EFF基金会的一个广受好评的“便民项目”。当今年代，网络攻击，cyberattack, man-in-the-middle层出不穷，为了保护好自己的隐私，加密HTTP连接成了一个目前比较好的解决方式。连接时，确认服务器端证书有效，可信，然后用密钥加密HTTP通讯。这样基本上可以保证通讯不受窃听和man-in-the-middle攻击。（关于窃听的potential危害，可以查看Firesheep项目，演示了同一无线网络内截取普通HTTP链接的facebook, twitter用户名密码等等）。
悲催的是，Chrome上面没有相关的HTTPS everywhere类似的插件。主要原因？Chrome至今都没有实现URL Rewrite 机制。什么是URL Rewrite?就是在发起HTTP连接之前，修改源URL里面的http前缀，改成https前缀。这样就可以保证在所有数据通讯前强制使用HTTPS机制。当然，为何chrome没有提供这个API原因未知，但是现在所有chrome下面的https型插件，都是通过javascript的document.location来实现的。这样并不能避免在转入https通讯前已经使用了http通讯。特别是大部分电脑上我们都是用“remember on this computer”选项的。
好在Google已经自动在搜索结果上开启了https，大家在搜索的时候可以查看URL栏里面，基本上都是https开头的了。Facebook和twitter都已经默认可以直接强制https登录，所以基本上没有了这个HTTPS Everywhere插件问题也不是很大了。
最后稍微离题一点。大家有没有发现，在天朝，基本上没有https服务。这点看银行就知道了，天朝银行最流行的是ActiveX安全控件。而在米国，https反而是业界标准。这是为啥呢？我有一个不负责任的猜测（谢绝跨省），天朝基于网络审查的需要，不能允许有这种https的加密通讯的存在（或者普遍存在），因为明文更加方便墙系统的sniffer。于是我们只好和这样优秀的技术无缘了。
