Green Dam become famous due to its STUPID

愚蠢的绿坝

绿坝开发者问到 - 未知长度的字符串还需要做截断处理?

是的, 你没有听错, 这就是绿坝开发者心里所嘀咕的问题, 国家花了4000万购买一年使用权, 要求所有在国内兜售的预装Windows视窗系统的PC所必须安装的「绿坝」!
密歇根大学的三名研究人员(一名研究系统安全的教授和两名研究生), 花了一天时间对绿坝展开逆向工程, 结果就发现了两处高危漏洞. 原始的调查报告在这里.

也许你不敢相信, 两处漏洞都是出于同样的编码错误, 试图用固定字长的字符数组来容纳未知长度的字符串. 相信任何对于计算机体系结构比较清楚, C语言功底扎实的朋友, 都会对这样两个错误嗤之以鼻.
下面简单说一下:
第一个, 由于绿坝读取url地址时所犯下的固定字长错误, 将会导致运行时栈溢出, runtime stack overflow.
此类错误绝对属于高危漏洞. 一般情况下, 普通的url不会产生什么问题, 但是经过精心编排的url字符串就可以利用这个bug轻松重写某段运行时栈, 用malicious data覆盖正常数据, 进而有机会掌握系统控制权.
第二个, 还是老问题. 由于blacklist的读取方式是文件line by line的读取, 而每一行也采用了固定字长的设定, 所以将会导致缓冲区溢出.

面对如此低级的错误和如此浅薄的计算机系统知识, 我们还能说啥? 愚蠢的绿坝. 跟着政府做开发, 你会一天天变得愚蠢, 就好比跟着国内的大部分学校做项目一样. 真是悲哀, sigh...

- EOF -

Green DAM is DAMN useless

绿霸 垃圾中的战斗机

「绿坝 - 花季护航」软件在不到一周的时间内, 占据了各大新闻版面的头条, 成为年轻人茶余饭后随口扯淡的焦点之一, 不能不说是个奇迹. 当然, 在这个神奇的国度, 这是不算啥的, 毕竟它的合作伙伴都是鼎鼎有名的「大户人家」, 工信部, 教育部, 财政部, 国务院新闻办. 这么一桩在我等普通民众眼中如此神奇的事情, 敬仰之余, 也很好奇这玩意儿究竟是何方神圣, 竟然能够让一个国家为其呐喊助威, 大笔一挥掏钱4000万, 而且还仅仅是一年的使用权?

网上的新闻已经足够多了, 但是百闻不如一见, 我昨天也测试了一番.
测试环境是VirtualBox v2.2.4虚拟机, 运行着Windows2000 SP4, 浏览器安装的是IE 6.0 + Firefox 3.0.10, 没有安装办公软件, 也没有安装安全类型的软件. 主要测试对象是针对其图像过滤功能和文字过滤功能, 以及传说中的自动关闭浏览器和字处理程序功能.
测试的「绿坝」版本是家庭版3.17, 在其官方站点下可以找到下载:


最后的测试结果就不罗嗦了, 大致总结一下:

1. 图像过滤.
可以在控制面板中选择是否开启图像过滤, 如果选择开启, 可以继续设置过滤级别.
技术上, 属于传统的肤色和脸部检测的综合识别, 没有什么新意. 只要出现了「大面积的黄色 + 脸型类似的图案布局」, 不论是 IE 6.0 还是 Firefox 3.0.10 都会被直接关闭. 大家可以尝试在 Google 中搜索 yellow, 对各类图像做一番测试.

2. 文字过滤.
这种过滤非常自吹自擂, 从网上一些朋友的测试结果, 譬如校园版软件的「学生玩摸球游戏」, 这款耗资4000万, 被国家大力推行的软件似乎并没有做什么语义分析, 而是直接根据关键字列表进行判断. 莫非是直接KMP匹配关键字, 然后吹嘘自己做了语义分析蒙骗工信部那些善良的老大爷老大妈?
不过, 我这里的测试结果并不理想, 很多传说的关键字都得不到过滤, 这一点比较汗.

3. 安装卸载.
可能很多人关心的是这个部分. 经过测试, 的确是可以被卸载的.
至于卸载是否干净, 不是特别清楚, 但是没有出现网上盛传的那么多流氓行为, 可能是我没有安装安全类软件的原因. 至于如何卸载, 是通过密码打开「设置」选项页面后, 通过「日常管理 - 卸载」来uninstall之.
如果有人再做测试, 可以在 cmd 中提前将 %Windows_Dir% 和 %Windows_Dir%\System32 文件夹中的文件做一个 dir 重定向, 然后安装, 继而卸载, 再做一番重定向, 将两份文件 diff 比较一番.
如果不出意外, 默认的卸载程序应该是可以卸载干净的, 咱们也不能太低估他们了不是. 囧

4. 密码部分.
网上盛传的伪造dll文件是真实的, 这个实际上是文本文件的 kwpwf.dll 文件, 包含了软件密码的md5值, 初始为 D0970714757783E6CF17B26FB8E2298F, 也就是112233的md5, 用户可以轻松将其修改成其他值. 一旦修改, 便可以通过 %Windows_Dir%\System32 下的 gn.exe 打开软件控制界面, 将软件卸载抑或是禁用.

至于目前最权威的分析评测报告, 应该是来自于这份文档了, 其中不仅仅分析了驱动模块和文件构成, 还指出了「绿坝」违背了所采用的 OpenCV 开源图像处理库的BSD协议.
BSD开源协议尽管是商业友好型的协议, 但是绿坝没有作出任何声明就擅自使用, 明显违背BSD协议的条款, 更何况绿坝还将自身申请了专利, 也是不合理的, 正常情况下, 只能够对算法做出专利申请保护, 而不能对整个软件申请专利保护. 当然了, 我们都知道, 绿坝根本就没有用什么新鲜的算法, 不然也不会这么遮遮掩掩.
其次, 我们在被破解后的关键字列表中也可以看到, 大部分关键字都是 Political-Related, 而非 Porn-Related, 国务院新闻办所发表的声明, 真实性还能够有几分?

总之, Green Dam is Damn useless. 国内GFW控制下的超级局域网确实不是一块净土, 可爱的互联网也不是, 但是, 如果真想让我们的孩子和青少年不受垃圾信息的毒害, 就要从教育抓起, 而不是通过一款「绿霸」一样的「绿坝」来强行关闭程序, 这不仅仅是没用的, 而且, 也是很愚蠢的. 甚至可以说, 这种方式连一种「临时应对之策」都称不上.

- EOF -

The Google Music Product

我也来说谷歌音乐

都是一些老生常谈的问题, 但是在blog里从来没谈过, 就破例写一篇 囧.

和菜头同学写了一篇向山寨致敬 写在谷歌音乐上线之后.
如果说这是一篇「无厘头」的文章, 那么是可以理解的 --- 现状就是如此, 与其抗争, 不如顺应潮流, 「山寨」一把, 「无厘头」一回.
如果说这不是一篇无厘头文章, 而是正儿八经的讨论, 那么和菜头同学就大错特错了.
首先要指出, 谷歌音乐不是什么山寨, 百度mp3也不是啥山寨, 只是歌曲的来源不同, 拉拢客户的方法有所区别. 一个没有踏及法律的灰色地带, 另一个踩着灰色地带不愿退出来. 而在设计上, 真的没有必要在「词汇」上大做文章, 用户习惯才是王道. 譬如播放器的 UI 以及「收藏夹」之类的功能. 至于名字怎么取, 只要别太离谱就ok.
MP3本身就是一个颇具争议的东西. 谷歌音乐当前只对中国地区开放, 国外用户根本没法访问, 为啥? 就是顾及到世界各地的版权状态不一致. 打个不恰当的比方, Amsterdam 红灯区世界闻名, 你如果去了可以随便消费, 就好比百度mp3抑或是酷狗酷我之类的音乐客户端一样, 但是如果把这些红灯区放到其他国家, 就并非如此了, 起码得要遮遮掩掩的进行, 就好比 torrents 种子站一样. 谷歌音乐只是google全球战略的一个试点, 如果模式逐渐清晰, 很有可能全球推广, 同 last.fm 和 iTunes 之类的付费站点争夺客户. 当然, 到时候的模式究竟如何谁也说不清, 「不作恶」只是个大框架, 框架之下究竟如何实施, 条条大路通罗马.
所以, 如果真像和菜头所言, 取名「谷歌mp3」, 绝对是行不通. music 和 mp3 两个词汇之间范畴太不一样, 尤其是在唱片公司和经纪人眼中, 后者简直就是撒旦的代名词, 就好比 Hollywood 对待 p2p 就像如临大敌一样.
从20世纪40年代开始, 技术催生产业, 规模改变模式, 无一例外.

短期内, 让大众产生「盗版就等同于偷窃」的意识很不容易, 也不现实. 我的 Windows 操作系统就是盗版, 尽管我现在已经全面转向 linux, 但是诸如黑莓手机的「桌面管理器」, 还是必须得在 Windows 平台下进行, 尽管从技术上来讲, javaloader on linix 基本可以替代「桌面管理器」, 但是对于普通大众用户, 显然不现实, 哪怕是我这等喜欢折腾新兴事物之人, 也更愿意使用「桌面管理器」.
但是, 大多数互联网产品和传统的软件产品很不同. 就拿互联网音乐来说, 如果正版音乐和盗版音乐体验一致, 甚至更好, 譬如搜索结果更好, 没有死链, 音质更佳, 播放体验更好, 音乐社区更有互动更好玩, 那么, 年轻的用户, 以及大批潜在的「重要用户」自然会过来. 毕竟大家都知道, 互联网产品的赢利主要是10%的用户所带来的, 争取这一部分用户才是重中之重. 到时候, 就是轮到踩踏着灰色地带的mp3们来哭了. 当然, 到时候这些mp3也自然会改变策略, 迎合那时的市场规律. 毕竟, 达尔文的适者生存法则, 在市场规律中永远都不会失效, 何况互联网这个只有第一没有第二的领域.

当下, 正版与否真的只是一个概念. 除非有朝一日酷我酷狗都成了死链, 百度mp3没法mp3, 才是真正正版时代的到来. 可以预计, 到时候, 谷歌音乐也绝对不会这么开放, 让大家伙随意的免费下载了.

ok, 说了这么多, 谷歌真正该抓紧做的, 究竟是啥呢? 当然, 这轮不到咱们这些普通用户来说, 毕竟谷歌内部的互联网产品设计人士绝对不是吃素的. 但是, 根据我的看法, 当下谷歌一直没有触碰的, 就是「社区」这一块, 这也是谷歌和其他本土互联网产品的重要区别. 而谷歌音乐很有可能是一个极好的切入点.
豆瓣, 虾米, 这两个站点, 都有很多创新的模式, 很值得谷歌音乐产品组参考. 有时候, 音乐站点不仅仅只是歌曲数量多少的问题.

- EOF -

三款网络电话服务

VoIP 服务商也可谓是「日新月异」. 不论是价格策略, 还是运营范围, 都可谓是「士别三日, 当刮目相看」, 当然, 也可能是「士别三日, 当侧目相看」囧.
自然, 这里所介绍的内容, 其有效性, 仅仅能够保证到今天, 因为指不定到了明天, 用户协议就改变了呢?

首先指出 --- 这里提到的三款网络电话服务, 都是能够让大家伙, 通过低廉的资费, 很方便的从手机上直接拨打国内 & 国际长途的服务.
其次指出 --- 这里所提到的服务, 尽管资费低廉, 但是并非完全免费, 毕竟天底下没有免费的午餐.

EQO - Mobile VoIP, free texts, and free mobile IM with EQO
这是一个超级服务大集合, 又是 VoIP, 又是免费 EQO 短信, 又是 twitter, 又是 msn & gtalk & icq 等等知名 im, 又是 rss 阅读器. 囧
其国际化运营相当成功, 技术支持很强悍.
需要下载手机客户端. 不过客户端支持的手机 OS 类型非常广泛, 只要不是特别旧的老手机, 应该不必担心兼容问题.
这里要提到一个缺点, 就是 eqo 的资费标准似乎一直在变动, 而且帮助文档 & FAQ 都编写的较混乱, 不够明晰, 甚至有前后矛盾的地方.
我已经和他们的 support 发送了邮件, 过一段时间将会在这个博客上给出一个详细的说明.

JAJAH
和skype差不多是同一个时期的产品了. 无需下载任何客户端, 仅仅通过手机访问其站点, 就可以在线拨打低资费高通话品质的国内国际长途电话了. 属于 callback 类型的网络电话, 用来拨打国际长途非常合适.
你可以选择在拨通电话前, 是否接听一段广告. 如果选择接听广告, 那么将会有一定的通话折扣.
这里对 callback 类型稍作解释 --- 譬如你想要拨打某个国际长途电话, 那么你通过手机抑或是 PC 访问 jajah 站点(两者稍有不同, 前者访问的是 mobile 版本), 使用你的 id 登陆, 输入对方手机号, 选择「call」接通. 马上, 你就可以接收到一个电话, 你按下接听, 便可以听到一段广告(如果你选择了接听广告的话), 继而是嘟嘟的等待声 --- 也就是 jajah 在帮你接通另一位了. 等到另一位拿起话筒, ok, 你们可以通话了. 换句话说, jajah 进行的是一个「语音中转站」一般的操作.
值得注意的是, 如果你正在漫游, 那么一旦接听jajah给你打来的「国际长途」, 中国移动会不会征收高额的漫游接听费呢? 我没尝试, 不敢说, 哪位尝试了可以告知一声.
关于 jajah 所谓「free-calls」的说明, 可以参见JAJAH 免费全球呼叫计划, 自然, 不是彻底的免费 --- JAJAH公平使用原则.

和悦网络电话
在腾讯软件的首页上看到的. 不过可不是腾讯的产品, 而是香港启悦发展有限公司的产品, 2005年在香港成立, 号称是「目前亚洲市场上最大也是最优秀的互联网语音通讯服务提供商」.
如果你要注册成为用户, 必须是中国大陆的座机, 手机, 小灵通; 相比较而言, jajah 和 eqo 对注册用户运营商的类型支持更为广泛.
有「PC客户端」和「callback」两种方式, 前者更加便宜. callback方式的资费情况简直就是 jajah 的山寨化 囧.

总结 ---
对于个人用户而言, 如果不是需要拨打国际长途, 此类服务的吸引力并不是很大. 毕竟国内长途有其他方式可以降低花费.
对于企业而言, 此类服务可能非常棒, 譬如多方通话, 在线会议等等. jajah & 和悦都支持类似的服务.
如果你并非特别频繁的拨打国际长途, 那么我推荐使用 jajah, 无需任何客户端, 话音质量良好, 而且价格低廉.
另外, 推荐这篇文章 --- 用EQO免费拨打国内长途电话, 但是这个办法似乎已经失效了 囧, 大家伙姑妄看之吧.
如果特别频繁的想要和某人拨打国际长途, 那么还是使用 QQ 抑或是 msn 的语音聊天吧.

史上最清新「因特網之歷史」

这是一段很强悍的视频 --- History of the Internet.
从超级大型机时代开始, 一直说到了当代的网络电话网络银行.
简要的讲述了当年北美和欧洲的若干互联网早期开发机构的历史; 现代互联网通信分组交换机制, package switch, 产生的背景; 稍微涉及了 OSI 架构和后来更加实用的 TCP/IP 协议; 还扯了一下 X.25, 倒腾了一把冷战历史...

这段视频称不上是关于「因特網之歷史」的最清晰的视频, 却必然是最清新的视频 --- 这段视频的背后, 就是某小团队的堪称庞大的计划, PICOL, PIctorial COmmunication Language, 图片化沟通语言. 而这段视频, 就是这计划中诞生的无数「具有明确象征意义的图标」的第一次试水.

PICOL is an project for providing free and open icons for electronic devices.
The aim is to find a common pictorial language for electronic communication.

这项计划的反响, 以及被接受程度, 都还有待观察. 特别是那些繁杂的规约, 几乎可以与 OSI 的复杂和面面俱到相「媲美」. 但是可以肯定的是, 必有一部分可以构成一套不错的 subset, 组成一些不错的事物, 譬如这项计划的博客的模板, 譬如某类技术书籍中的简单标识.
而且个人觉得在普通电子商品的说明书中, 如果不是追求出奇制胜, 这套图标可以简化很多东西. 对于某些追求与众不同的地方, 这类超级图标集合恐怕难以找到太多用武之地.

更多信息, 以及这套图标, 可以从这里获取: http://blog.picol.org/pre-release-picol-icons/
很多人在那里讨论pre-release的缺陷, 如果你有强烈兴趣, 也可以下载好好研究之.

这里举三个例子, 大家伙猜猜这三个图标代表啥意思? ---



ps.
标题之所以使用繁体「因特網之歷史」, 是因为这段放在 youtube 上的视频, 其字幕的中文翻译者是台湾人.
如果谁有兴趣, 可以联系视频的创作者将其翻译成简体中文. 譬如将「網路」转换成「网络」, 「伺服器」转换成「服务器」.
俺开始联系了一次, 那时候还没有中文翻译, 后来又主动联系了一次, 估计那时候已经有了繁体翻译. 再后来就是被告知, 已经有了中文版本的翻译. 可见对于好东西大家伙都是很热心的. 囧
现在貌似不好意思再告诉作者说啥繁体简体之类的了.

赫然发现 google 的所有离线服务原来都如此危险 o_o

google 的离线服务非常好, 起码大多数时候都是如此.
不过今天在豆瓣的 google 小组中, 碰到一个问题, 我这里摘要一下 ---

　　1. 第一次同步时会自动替我选择同步的时间范围, 那之后同步下来的邮件, 如果超出时间范围的会自动删除以保证硬盘文件容量不变吗? 还是以后就不删了?
　　
　　2. 近期的邮件, 如果我在Online模式时删除了, 会同步从硬盘上的同步文件中删除吗?

　　因为看到C盘正在被无情蚕食中...

由于对于 gears 没有啥研究, 唯一的「接触」也就是第一次 gmail 离线同步失败后, 搜索离线数据的存放目录时, 有一次亲密接触. 所以决定亲自试验下, 毕竟咱折腾, 咱娱乐嘛. 囧 何况咱们都是 google 的 fans, 自然希望能够有更多了解.

申请了一个新帐号, jtuki.0x2665@gmail.com, 至于0x2665究竟是啥玩意儿, 您就 google 去吧. 囧
gmail 会对每一个新用户发送一封欢迎邮件 ---

Messages that are easy to find, an inbox that organizes itself, great spam-fighting tools and built-in chat. Sound cool? Welcome to Gmail.

To get started, you may want to:

<XXX 此处省略摘要 XXX>

Thanks,

The Gmail Team

进入 lab 开启 offline 模式, 继而点击之. 等待大约1分钟后, 同步完成. 接下来的任务就是寻找数据究竟存放在哪里.

根据上面的亲密接触的信息, 层层 cd 后来到
~/.mozilla/firefox/q0pvp6rn.default/Google Gears for Firefox/mail.google.com/https_443

查看文件信息

ls -l |less
---------------------------------
total 208
drwx------ 2 jerome jerome   4096 2009-02-06 22:31 GoogleMail[24]#localserver
drwx------ 2 jerome jerome  12288 2009-02-06 22:31 GoogleMail_managed[22]#localserver
drwx------ 2 jerome jerome   4096 2009-02-06 22:29 GoogleMail_managed[23]#localserver
drwx------ 2 jerome jerome   4096 2009-02-02 13:33 icons#desktop
-rw------- 1 jerome jerome   6144 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail-b#database
-rw------- 1 jerome jerome 157696 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail#database
-rw------- 1 jerome jerome  13312 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail-t#database
---------------------------------

可以发现其中几个很显眼的字眼, database, 而且一个文件, jtuki.0x2665@gmail.com-GoogleMail#databas 的体积比另外几个含有database字眼的文件要大不少, 莫非数据就是存放在这里?

为了先稍加验证, 重新开了一个terminal, 进入 ~/.mozilla/firefox/q0pvp6rn.default/Google Gears for Firefox/docs.google.com/https_443 , 也就是 google-docs 的数据存放基地, 查看文件信息

ls -l |less
---------------------------------
total 23144
drwx------ 2 jerome jerome     4096 2009-02-06 16:22 DocImg[14]#localserver
drwx------ 2 jerome jerome    12288 2009-02-05 12:03 Doclist_managed[11]#localserver
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Doclist_managed[12]#localserver
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Documents_managed[7]#localserver
drwx------ 2 jerome jerome     4096 2009-01-30 19:13 icons#desktop
-rw------- 1 jerome jerome   270336 2009-02-06 22:22 jerome.rivest.long@gmail.com-Doclist#database
-rw------- 1 jerome jerome 22886400 2009-02-06 22:40 jerome.rivest.long@gmail.com-Documents#database
-rw------- 1 jerome jerome     8192 2009-02-06 11:51 jerome.rivest.long@gmail.com-Logging#database
-rw------- 1 jerome jerome   449536 2009-02-06 10:38 jerome.rivest.long@gmail.com-Presentations#database
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Presentations_managed[8]#localserver
drwx------ 2 jerome jerome    12288 2009-01-30 19:23 PresImg[13]#localserver
---------------------------------

果然, 相同类型的 jerome.rivest.long@gmail.com-Documents#database 的体积已经非其他database文件所能比拟.
初步估计就是此文件.

不过这些也没啥. 关键是咱们的数据怎么保存的呢? 用文本编辑器打开 gmail 的那个瞅了瞅, 居然发现了明文信息, 顿时冷汗就出来了.. 明文! 没有任何加密..
莫非 gears 没有任何数据保密措施么?..

不妨测试一下:

---------------------------------
$ grep "Messages that are easy to find" ./*
Binary file ./jtuki.0x2665@gmail.com-GoogleMail#database matches
---------------------------------

-_- 真的很吃惊.

那么 docs 文档又是如何呢?
在一篇 doc 文档中挑选了一句测试:

---------------------------------
$ grep "The usual arithmetic conversions" ./*
Binary file ./jerome.rivest.long@gmail.com-Documents#database matches
---------------------------------

更加惊讶, 原来都是明文保存的, 只不过是加上了众多 tag 罢了.

再次回到 gmail offline 的话题, 如果在线删除了 gmail 中的邮件, 再次同步后, 本地会删除么? 就好比 IMAP 邮件存取协议一样, 支持本地和在线同步更新? 测试结果是, no.
换句话说, 在线删除了的文档, 本地依然被保存着, 而且还是明文形式.

So --- 如果不是家庭电脑, 如果 gears 的这个问题总是存在, 如果你身边有一个喜欢偷窥你信息, 而且懂得如何偷窥的人, 如果你的很多信息较为 private, 不希望被他人看到, 那么 --- 您还是关闭 gears 吧. 囧

ps. 当然, 对于大多数, 譬如俺, 就可以坦然的使用啦. 除非, 是在公用电脑上.

update: 2009年2月6日
刚才搜索了一把, 这里提供几个非常有价值的链接:
> http://markmail.org/message/x54ucaczxtfrmaz6 --- 信息爆料: gears 团队已经考虑到了这个信息加密的问题, 只是还没人开始做 囧. 可以有多种办法实现手动加密, 譬如firefox插件, 又譬如 Tara Kelly 的回复(说不定今后很可能被直接整合进入gears).
> http://www.insideria.com/2009/01/google-gearsa-great-tool-to-en.html --- 摘要一段

Gears provides no security of data stored locally, so it is entirely up to the programmer to not store any sensitive data on a local store. Currently, offline data encryption/decryption is completely under the control of the local machine, and any user with access to that machine could conceivably access the data.

同时, 各位也可以看到, 使用gears的服务还真是不少. 囧 还有不少好信息, 大家就去 google 搜索结果上翻吧.

- EOF -

胡同学的 Dedicated to *

此篇 blog 绝对属于八卦, 彻头彻尾的八卦 (今天下午歪打正着, 继而再接再厉, 一共半小时左右的成果). 而且我现在还有些担心是否会触犯某些人的隐私权. 如果回答是 YES, 请您立马提醒我, 保证立即删除之. -__-

按照时间顺序表述之 ---

0> 由于喜欢<谷歌-金山词霸>, 所以考虑是否有办法将 Google 的网络词典搬到 Stardict (linux中最流行, 也是最好用的一款字典软件) 中来.

1> 搜索到了一个链接. 原本是个没什么用的链接, 熟料下方的某个评论爆了一个猛料. 八卦神经立刻被触碰, 于是想要弄明白究竟是怎么回事. -_- (俺承认这样确实很八卦.. 太八卦了..)

2> 轻松找到了 Stardict 的原作者 (胡正同学) 的个人站点. 猛一看, 都可以知道确实有点教主色彩.. 我这里所说的教主, 不同于豆瓣团队中行事低调, 感情上略带「闷骚」(百分百褒义, absolutely -_-) 的 zsp 教主.
具体原因, 各位有兴趣的同学可以下载 <我的世界之源代码> 在第1页查看原委 --- 也就是出版社的名称.

3> 在胡同学的个人首页的「合作伙伴」中, 轻松找到了「hwj的blog」的链接名 (做了化名处理, 有八卦爱好的同学, 可根据我上面提供的多个链接, 寻找蛛丝马迹得到答案. 而且这个链接本身也就和其他链接不一样, 几乎一眼就可看出来, 想必胡同学也是很希望大家伙看到 -_-).

4> 如果你理解了上述「而且这个链接本身也就和其他链接不一样」, 那么想必你一定点击开了那个与众不同的链接. :) 我在这里废话一句, 有点神似咱们寝室某男生的 GF..

5> 此人究竟何方神圣? 和胡同学究竟是何关系? (我所感兴趣的, 也就是到达「是何关系」这个层面)
继续八卦, 前面提到的某个 pdf 材料 <我的世界之源代码> 确实给了我一个轻而易举八卦线索. -_-
各位有兴趣自己翻吧, 两个重要的页面是 219 和 69.

总之, 有点无语. 相比当年在 Spybot 的 license 文件中看到的 dedicated to the most wonderful girl on earth , 胡同学的这种对待感情的极为不成熟的行为, sigh, 不多评论了. -_-

ps.

尽管胡同学在感情问题上的处理太值得商榷, 但是 Stardict 还是一款很优秀的软件. :)

对于一开始的那个想法, 似乎没有办法完全照搬. 涉及到解析并且综合多个 query 结果的工作, 而且说实话, 我貌似还没弄清楚, 它究竟是从哪些站点搜罗信息. -_-
如果退而求其次, 可以将爱词霸的 firefox 搜索插件添加到 firefox 右上角的搜索引擎中, 也还是挺不错的. 相比那些固定XX数量词汇的词典, 这种 wiki 类型的, 甚至借力于搜索引擎的在线词典, 确实够海量词汇.

最后提供两个关于 homeboy 的好玩链接, 也就是这个家伙 (照片上居然还有红眼 -_-) 的这件衬衫.

- EOF -