前不久，在Gmail里翻墙可以打免费的美国和加拿大的电话。
首先，这绝不是耸人听闻，而是我本人（王佳冬）自己尝试过的方法，目前此方法在业界流传颇广，伟大的google再次创造了奇迹——使用 Gmail 拨打国内电话，通话双方均免费。
使用方法，超级简单
首先，你要确保你的gmail加载了chat模块，并且已经拥有call phone的功能（如上图所示），开通方法：
1、使用美国或加拿大 IP 地址登录 Gmail 肯定能有该功能（最简单的方法就是翻墙，必须的！）；
2、把 Gmail 语言设置成 US English ，也是有可能使用到呼叫功能的（不保险，不如翻墙）。
其次，要确保安装了 Gmail voice and video chat 浏览器插件。
然后，你必须拥有一个Google Voice帐号的美国电话号码。
最后，你就能使用 Gmail 拨打国内电话，通话双方均全部免费：
1、拨打自己的Google Voice 手机号
2、听到 Google Voice 的英文语音提示：“您当前没有新的消息，按“2”健拨打电话，按“2”健。
3、再次听到 Google Voice的英文语音提示：“请按键输入您要拨打的电话号码，按“#”号健确认。如果是国际长途，则请先按键“011”，再输入国家号，最后输入电话号码”。比如国内的手机号码是：0118613999999999# 国内的固定号码是：011862166666666# 。按完之后就会提示“it‘s a free call”，电话开始接通了。
还不快去试试？？？
谷歌要让全世界电信公司关门？
通过以上的方法，目前用Gmail内嵌电话拨本账户的Google Voice号码，然后拨2继续打电话011+国际区号+电话号码，任何国际长途都是免费。谷歌准备让全世界电信公司关门了？
虽然说gmail的这项服务可能在未来的某个时候会收费（就像skype）那样，但是我们依然相信它比传统的电信公司要强得多，因为资费显然要比传统电信便宜的多，并且它不像skype那么复杂，所有的操作只需要在web上进行，这一切真是太奇妙了。
不过说到底，google还没那么大的本事让全世界的电信公司关门，毕竟通讯这项高科技需要电信公司们的基础建设，google暂时还没有办法一家独大，只是便宜了我们这些老百姓罢了。
最后，再次感谢google给我们带来了这么精彩的web应用。
2010年9月3日 星期五
行记：pub里普及中国政治常识
来源：http://blog.renren.com/blog/232656204/398649230
晚上，去了城堡里面的pub。我们几位中国女生坚持不要带酒精的饮料。于是就只点了lemonade。
难以想象，白天这群加拿大的学生谈论的话题无外乎昨天去了希腊，明天去爱尔兰之类的话题。但是晚上在pub里面，话题居然是加拿大、美国和中国的政治。
“胡主席是经过选举上台的吗？”
“为什么中国的政党制度是那样子的？那些党为什么不竞选呢？”
“为什么中国要侵略西藏？”
......
甚至，问道了***事件。
她的眼神告诉我，她并不是有什么偏见或者误会，只是她真的不知道，那双无知的双眼瞪得大大的一直瞅着我，她所有的认识不过是从旁人的话语中获得，当她产生 疑问的时候，别人告诉她的是“这个问题不许谈论”，她困惑：“为什么他们说这个问题不能谈？到底发生了什么？”
我这样回答。
“我觉得可以做一下对比。如果说中国侵略了西藏，为什么不说19世纪的美国侵略的印第安人呢？当年西进运动以及通过战争、购买手段获得的西部土地，难道不 是侵略么？更何况，手段极其不人道和血腥。而西藏自唐朝开始就是中国的领土，已经有了一千多年的历史，20世纪50年代解放西藏使用的则是和平方式。印第 安人至今只在少数西部地区聚集生活，并且处在种族灭绝的边缘。而西藏人民则过着幸福向上的生活，相比之下，哪个才是侵略？”
“如果总是问为什么中国没有所谓的‘民主选举’，这就好比我有一杯啤酒，你有一杯汽水，我拿着啤酒问你‘为什么你拿的是汽水不是啤酒？我的啤酒最好了！” 那么，难道你不可以问我‘为什么你拿得的啤酒而不是汽水？’吗？当然可以这么问，只是这种问题毫无意义，因为你就是适合啤酒，而我就是适合汽水，无所谓好 坏，也不要拿你的标准来评价别人。”
她点头称赞。
归来，仰望星空，北斗七星在头顶闪烁。在国内，真的感觉不到“中国”这二字的含义，而现在，面对那些质疑的声音，我绝不妥协，用我有限的政治知识（不过和他们相比已经算多了）来维护祖国的尊严。
能做的，还有很多。我来自PKU，China.
晚上，去了城堡里面的pub。我们几位中国女生坚持不要带酒精的饮料。于是就只点了lemonade。
难以想象，白天这群加拿大的学生谈论的话题无外乎昨天去了希腊，明天去爱尔兰之类的话题。但是晚上在pub里面，话题居然是加拿大、美国和中国的政治。
“胡主席是经过选举上台的吗？”
“为什么中国的政党制度是那样子的？那些党为什么不竞选呢？”
“为什么中国要侵略西藏？”
......
甚至，问道了***事件。
她的眼神告诉我，她并不是有什么偏见或者误会，只是她真的不知道，那双无知的双眼瞪得大大的一直瞅着我，她所有的认识不过是从旁人的话语中获得，当她产生 疑问的时候，别人告诉她的是“这个问题不许谈论”，她困惑：“为什么他们说这个问题不能谈？到底发生了什么？”
我这样回答。
“我觉得可以做一下对比。如果说中国侵略了西藏，为什么不说19世纪的美国侵略的印第安人呢？当年西进运动以及通过战争、购买手段获得的西部土地，难道不 是侵略么？更何况，手段极其不人道和血腥。而西藏自唐朝开始就是中国的领土，已经有了一千多年的历史，20世纪50年代解放西藏使用的则是和平方式。印第 安人至今只在少数西部地区聚集生活，并且处在种族灭绝的边缘。而西藏人民则过着幸福向上的生活，相比之下，哪个才是侵略？”
“如果总是问为什么中国没有所谓的‘民主选举’，这就好比我有一杯啤酒，你有一杯汽水，我拿着啤酒问你‘为什么你拿的是汽水不是啤酒？我的啤酒最好了！” 那么，难道你不可以问我‘为什么你拿得的啤酒而不是汽水？’吗？当然可以这么问，只是这种问题毫无意义，因为你就是适合啤酒，而我就是适合汽水，无所谓好 坏，也不要拿你的标准来评价别人。”
她点头称赞。
归来，仰望星空，北斗七星在头顶闪烁。在国内，真的感觉不到“中国”这二字的含义，而现在，面对那些质疑的声音，我绝不妥协，用我有限的政治知识（不过和他们相比已经算多了）来维护祖国的尊严。
能做的，还有很多。我来自PKU，China.
google devfest 2010
Google is excited to announce DevFest 2010 developer conference in Hyderabad and Pune in the month of february and march.
This event is focused on sharing latest offerings for Google developer products : App Engine, Maps APIs, Chrome Extensions and Orkut APIs. We would also talk about the new HTML standard which is already adopted by wide variety of browsers.
This event is focused on sharing latest offerings for Google developer products : App Engine, Maps APIs, Chrome Extensions and Orkut APIs. We would also talk about the new HTML standard which is already adopted by wide variety of browsers.
“西厢计划”的研究
待月西厢下，迎风户半开。隔墙花影动，疑是玉人来。
最近 twitter 上最流行的一个关键词是”西厢计划”. 这个计划名字取得很浪漫，客户端叫做张生，对，就是西厢记里面那个翻墙去见崔莺莺小姐的张生；显然，服务器端必然叫做崔莺莺。客户端的张生是最重要的部件，可以不依赖于服务端工作。
我是个特别好奇的人，遇到好玩的总要学习一下看看是怎么弄的。因为西厢计划的作者只是简要的介绍了一下原理，其他报道又语焉不详，我当时就觉得很好奇，花了昨天一个晚上详细读了一下源代码，终于知道怎么回事了，觉得原理非常漂亮，所以写篇文章介绍总结一下。
先说大方向。大家都知道，连接被重置的本质，是因为收到了破坏连接的一个 TCP Reset 包。以前剑桥大学有人实验过，客户端和服务器都忽略 Reset, 则通信可以不受影响。但是这个方法其实只有理论价值，因为绝大多数服务器都不可能忽略 Reset 的 (比如 Linux, 需要 root 权限配置iptables, 而且这本身也把正常的 Reset 给忽略了)。只要服务器不忽略 Reset, 客户端再怎么弄都没用，因为服务器会停止发送数据，Reset 这条连接。所以，很多报道说西厢计划是忽略 Reset, 我从源代码来看应该不是这样。在我看来，西厢计划是利用了墙的一个可能的弱点–墙只在连接发起的时候把一个 TCP 连接加入监听序列，如果墙认为这个连接终止了，就会从监听序列中去掉这条记录，这样，这条连接上后续的包就不会被监听。西厢计划就是让墙“认为”这个连接 终止的一个绝妙的方法。只要墙认为这个连接两端都是死老虎，墙就不会触发关键词检测，其后所有的数据，都不存在连接被重置的问题了。
如何让一个连接置之死地而后生，就是西厢计划那帮黑客神奇的地方了。这也不是一日之功。 首先，这帮牛人发现，墙的是一个入侵检测系统，把含有关键字的包当成一种“入侵”来对待。采取这种设计有很多好处，但缺点是入侵检测系统可能具有的问题， 墙都可能有。西厢计划主页上那篇著名的论文就是讲这些七七八八的漏洞的。可以说处理这些七七八八的漏洞是非常困难的，迫使墙的设计者“拆东墙，补西墙”。 这样补来补去，外表看起来好像很牛逼的墙，其实有很多本质上无法简单修补的漏洞，其中有一个致命的，就是 TCP 连接状态的判定问题。 出于入侵检测系统这种设计的局限，墙没有，也没办法准确判定一条 TCP 连接的状态，而只是根据两边收到的数据来“推测”连接的状态。而所有的关键词检测功能，都是基于“连接还活着”的这个推测的结果的。因为墙的规则是在连接 发起的时候开始对这条连接的检测，在连接终止的时候停止对这条连接的检测，所以，一旦对连接的状态推测错误，把还活着的连接当成已经关闭的连接，墙就会放 弃对这条连接上随后所有的包的检测，他们都会都透明的穿过墙的入侵检测。
上面只是想法，具体到 TCP 协议实现这一层，就要只迷惑墙，还不能触及我要通信的服务器。最理想的情况下，在任何有效通信之前，就能让墙出现错误判断，这些，就需要对 TCP 协议有深刻理解了。西厢计划的那帮黑客，居然真的去读 TCP 几百页的 RFC，还居然就发现了方法（这里我假设读者都知道 TCP 的三次握手过程和序列号每次加一的规则）。 我们都知道，三次握手的时候，在收到服务器的 SYN/ACK 的时候，客户端如果发送 ACK 并且序列号+1 就算建立连接了，但是客户端如果发送一个序列号没 +1 的 FIN （表示连接终止，但是服务器知道，这时候连接还没建立呢， FIN 这个包状态是错的，加上序列号也是错的，服务器自己一判断，就知道这个包是坏包，按照标准协议，服务器随手丢弃了这个包）, 但这个包，过墙的时候，在墙看来，是表示连接终止的(墙是 ma de in china, 是比较山寨的，不维护连接状态，并且，墙并没有记下刚才服务器出去的 SYN/ACK 的序列号，所以墙不知道序列号错了）。所以，墙很高兴的理解为连接终止，舒了一口气去重置其他连接了， 而这个连接，就成了僵尸，墙不管你客户端了，而这时候，好戏才刚刚开始。
事实上，墙是双向检测的（或者说对每个包都检测的），因此，对服务器和客户端实现相同的对待方法，所以，墙不管客户端还不行，假如服务端有关键词传 给客户端，墙还是有可能要发飙的（这里说有可能，因为我也不知道）。所以，最好的办法就是，让服务端也给墙一个终止连接的标志就好了。可是这个说起来简 单，做起来难，怎么能让不受自己控制的服务器发一个自己想要的包呢？ 西厢计划的那帮黑客，再次去读几百页的 RFC, 令人惊讶的发现，他们居然在 RFC 上发现了一个可以用的特性。我们上面说了，三次握手的时候，在收到 SYN/ACK 后，客户端要给服务器发送一个序列号+1 的ACK，可是，假如我不+1呢，直接发 ACK 包给服务器。 墙已经认为你客户端是死老虎了，不理你了，不知道你搞什么飞机，让这个 ACK 过了。可是服务器一看，不对啊，你给我的不是我期待的那个序列号， RFC 上说了，TCP 包如果序列号错了的话，就回复一个 Reset. 所以，服务器就回复了一个 Reset。这个 Reset 过墙的时候，墙一看乐了，服务器也终止连接了，好吧，两边都是死老虎了，我就不监听这条连接了。而至于客户端，这个服务器过来的 Reset 非常好识别，忽略就是。随后，客户端开始正确的发送 ACK, 至此，三次握手成功，真正的好戏开始，而墙则认为客户端和服务器都是死老虎，直接放过。所以，张生就这样透明的过了墙。 至于过墙以后所有的事情，《西厢记》里面都有记载，各位读者自行买书学习。
现在的西厢计划客户端，即“张生”模块的防连接重置的原理就是这样，服务器端，即莺莺模块的实现也是类似的。防DNS那个，不懂 DNS 协议，所以看不懂。我猜想，因为开发人员都是黑客，所以自然喜欢用最经得起折腾和高度定制的 Linux 开发。 现在看西厢计划的实现，因为依赖于 Linux 内核模块 netfilter, 在 Linux 上如鱼得水，但往其他平台的移植可能是个亟待解决的问题。 我觉得，在其他平台上，可以通过 libpcap 和 libnet ，在用户态实现相同的功能，就是有点麻烦而已，有兴趣的懂网络的可以照西厢计划原理，在家自行做出此功能；当然，全中国人民都用 Linux 最好 :)
PS 1: 据说是西厢计划一个作者画的原理图：http://img.ly/DIi
PS 2: 我对 TCP 的理解仅限于课本，如果上面的对技术的理解有错，请大家指出。
PS 3: 有些漏洞，可能是设计上本质缺陷，不是那么容易修复的。
PS 4: 除了最后一个图，本文没有其他相关链接，如需相关资料，自行 Google。
最近 twitter 上最流行的一个关键词是”西厢计划”. 这个计划名字取得很浪漫，客户端叫做张生，对，就是西厢记里面那个翻墙去见崔莺莺小姐的张生；显然，服务器端必然叫做崔莺莺。客户端的张生是最重要的部件，可以不依赖于服务端工作。
我是个特别好奇的人，遇到好玩的总要学习一下看看是怎么弄的。因为西厢计划的作者只是简要的介绍了一下原理，其他报道又语焉不详，我当时就觉得很好奇，花了昨天一个晚上详细读了一下源代码，终于知道怎么回事了，觉得原理非常漂亮，所以写篇文章介绍总结一下。
先说大方向。大家都知道，连接被重置的本质，是因为收到了破坏连接的一个 TCP Reset 包。以前剑桥大学有人实验过，客户端和服务器都忽略 Reset, 则通信可以不受影响。但是这个方法其实只有理论价值，因为绝大多数服务器都不可能忽略 Reset 的 (比如 Linux, 需要 root 权限配置iptables, 而且这本身也把正常的 Reset 给忽略了)。只要服务器不忽略 Reset, 客户端再怎么弄都没用，因为服务器会停止发送数据，Reset 这条连接。所以，很多报道说西厢计划是忽略 Reset, 我从源代码来看应该不是这样。在我看来，西厢计划是利用了墙的一个可能的弱点–墙只在连接发起的时候把一个 TCP 连接加入监听序列，如果墙认为这个连接终止了，就会从监听序列中去掉这条记录，这样，这条连接上后续的包就不会被监听。西厢计划就是让墙“认为”这个连接 终止的一个绝妙的方法。只要墙认为这个连接两端都是死老虎，墙就不会触发关键词检测，其后所有的数据，都不存在连接被重置的问题了。
如何让一个连接置之死地而后生，就是西厢计划那帮黑客神奇的地方了。这也不是一日之功。 首先，这帮牛人发现，墙的是一个入侵检测系统，把含有关键字的包当成一种“入侵”来对待。采取这种设计有很多好处，但缺点是入侵检测系统可能具有的问题， 墙都可能有。西厢计划主页上那篇著名的论文就是讲这些七七八八的漏洞的。可以说处理这些七七八八的漏洞是非常困难的，迫使墙的设计者“拆东墙，补西墙”。 这样补来补去，外表看起来好像很牛逼的墙，其实有很多本质上无法简单修补的漏洞，其中有一个致命的，就是 TCP 连接状态的判定问题。 出于入侵检测系统这种设计的局限，墙没有，也没办法准确判定一条 TCP 连接的状态，而只是根据两边收到的数据来“推测”连接的状态。而所有的关键词检测功能，都是基于“连接还活着”的这个推测的结果的。因为墙的规则是在连接 发起的时候开始对这条连接的检测，在连接终止的时候停止对这条连接的检测，所以，一旦对连接的状态推测错误，把还活着的连接当成已经关闭的连接，墙就会放 弃对这条连接上随后所有的包的检测，他们都会都透明的穿过墙的入侵检测。
上面只是想法，具体到 TCP 协议实现这一层，就要只迷惑墙，还不能触及我要通信的服务器。最理想的情况下，在任何有效通信之前，就能让墙出现错误判断，这些，就需要对 TCP 协议有深刻理解了。西厢计划的那帮黑客，居然真的去读 TCP 几百页的 RFC，还居然就发现了方法（这里我假设读者都知道 TCP 的三次握手过程和序列号每次加一的规则）。 我们都知道，三次握手的时候，在收到服务器的 SYN/ACK 的时候，客户端如果发送 ACK 并且序列号+1 就算建立连接了，但是客户端如果发送一个序列号没 +1 的 FIN （表示连接终止，但是服务器知道，这时候连接还没建立呢， FIN 这个包状态是错的，加上序列号也是错的，服务器自己一判断，就知道这个包是坏包，按照标准协议，服务器随手丢弃了这个包）, 但这个包，过墙的时候，在墙看来，是表示连接终止的(墙是 ma de in china, 是比较山寨的，不维护连接状态，并且，墙并没有记下刚才服务器出去的 SYN/ACK 的序列号，所以墙不知道序列号错了）。所以，墙很高兴的理解为连接终止，舒了一口气去重置其他连接了， 而这个连接，就成了僵尸，墙不管你客户端了，而这时候，好戏才刚刚开始。
事实上，墙是双向检测的（或者说对每个包都检测的），因此，对服务器和客户端实现相同的对待方法，所以，墙不管客户端还不行，假如服务端有关键词传 给客户端，墙还是有可能要发飙的（这里说有可能，因为我也不知道）。所以，最好的办法就是，让服务端也给墙一个终止连接的标志就好了。可是这个说起来简 单，做起来难，怎么能让不受自己控制的服务器发一个自己想要的包呢？ 西厢计划的那帮黑客，再次去读几百页的 RFC, 令人惊讶的发现，他们居然在 RFC 上发现了一个可以用的特性。我们上面说了，三次握手的时候，在收到 SYN/ACK 后，客户端要给服务器发送一个序列号+1 的ACK，可是，假如我不+1呢，直接发 ACK 包给服务器。 墙已经认为你客户端是死老虎了，不理你了，不知道你搞什么飞机，让这个 ACK 过了。可是服务器一看，不对啊，你给我的不是我期待的那个序列号， RFC 上说了，TCP 包如果序列号错了的话，就回复一个 Reset. 所以，服务器就回复了一个 Reset。这个 Reset 过墙的时候，墙一看乐了，服务器也终止连接了，好吧，两边都是死老虎了，我就不监听这条连接了。而至于客户端，这个服务器过来的 Reset 非常好识别，忽略就是。随后，客户端开始正确的发送 ACK, 至此，三次握手成功，真正的好戏开始，而墙则认为客户端和服务器都是死老虎，直接放过。所以，张生就这样透明的过了墙。 至于过墙以后所有的事情，《西厢记》里面都有记载，各位读者自行买书学习。
现在的西厢计划客户端，即“张生”模块的防连接重置的原理就是这样，服务器端，即莺莺模块的实现也是类似的。防DNS那个，不懂 DNS 协议，所以看不懂。我猜想，因为开发人员都是黑客，所以自然喜欢用最经得起折腾和高度定制的 Linux 开发。 现在看西厢计划的实现，因为依赖于 Linux 内核模块 netfilter, 在 Linux 上如鱼得水，但往其他平台的移植可能是个亟待解决的问题。 我觉得，在其他平台上，可以通过 libpcap 和 libnet ，在用户态实现相同的功能，就是有点麻烦而已，有兴趣的懂网络的可以照西厢计划原理，在家自行做出此功能；当然，全中国人民都用 Linux 最好 :)
PS 1: 据说是西厢计划一个作者画的原理图：http://img.ly/DIi
PS 2: 我对 TCP 的理解仅限于课本，如果上面的对技术的理解有错，请大家指出。
PS 3: 有些漏洞，可能是设计上本质缺陷，不是那么容易修复的。
PS 4: 除了最后一个图，本文没有其他相关链接，如需相关资料，自行 Google。
2010年9月2日 星期四
Echofon最新版使用Twip API(for OAuth)
Echofon的前身是TwitterFox，是Firefox上一个关于Twitter的插件，由于使用方便，一直备受各路推友的欢迎！自从 Twitter被伟大的GFW墙奸之后，人们纷纷开始自行修改nsTwitterFox.js中的TWITTER_API_URL，即自定义 Twitter API地址，来访问自己的twitter。但是自从Echofon的某次更新之后，新版Echofon 1.9.6.x似乎通过这种简单方式再也无法绕过GFW访问Twitter了！其原因是新版本中启用了新的OAuth身份验证方式…
那么如果自己手头有一个可用的Twitter API，怎么修改Echofon来继续访问Twitter呢？ 本文以新版Twip API(for OAuth)为例，介绍下如何修改Echofon(1.9.6.4)使之通过Twip API访问Twitter
关于Twip API(for OAuth)如何配置请参考这里…
新版Echofon(1.9.6.4)更改Twitter API的方式和老版本一样，也是通过更改nsTwitterFox.js中的TWITTER_API_URL来指定Twitter API地址的
首先用文本编辑工具打开nsTwitterFox.js
Windows下路径是：%AppData%\Mozilla\Firefox\Profiles\xxxx.default\extensions\twitternotifier@naan.net\components
Linux下路径是：~/.mozilla/firefox/profiles/xxxx.default/extensions/twitternotifier@naan.net/components
找到 const TWITTER_API_URL 这行，修改后面的数据为你的Twip API
因为新版本优先使用OAuth验证，因此直接更改TWITTER_API_URL是不能访问Twitter的。通过观察 nsTwitterFox.js代码，不难发现新版Echofon启用了2种验证方式，即OAuth和BasicAuth，那么只需要简单的修改下代码就 能让它使用BasicAuth验证了！方法很简单，就是直接注释掉第64行代码！
最后别忘了清理一下Echofon的数据库文件twitterfox_1.9.sqlite(老版本是twitterfox_1.8.sqlite) ，然后重新打开Firefox
那么如果自己手头有一个可用的Twitter API，怎么修改Echofon来继续访问Twitter呢？ 本文以新版Twip API(for OAuth)为例，介绍下如何修改Echofon(1.9.6.4)使之通过Twip API访问Twitter
关于Twip API(for OAuth)如何配置请参考这里…
新版Echofon(1.9.6.4)更改Twitter API的方式和老版本一样，也是通过更改nsTwitterFox.js中的TWITTER_API_URL来指定Twitter API地址的
首先用文本编辑工具打开nsTwitterFox.js
Windows下路径是：%AppData%\Mozilla\Firefox\Profiles\xxxx.default\extensions\twitternotifier@naan.net\components
Linux下路径是：~/.mozilla/firefox/profiles/xxxx.default/extensions/twitternotifier@naan.net/components
找到 const TWITTER_API_URL 这行，修改后面的数据为你的Twip API
11 | const TWITTER_API_URL = "twitter.martin-d.com/"; |
63 64 65 66 67 | try { // this._signer = Cc['@naan.net/twitterfox-sign;1'].getService(Ci.nsITwitterFoxSign); this._schema = this._pref.getBoolPref("useSSL") ? "https://" : "http://"; this.log("Use OAuth"); } |
订阅：
帖子 (Atom)
