只能用神作来形容的Javascript游戏开发库，代号Akihabara（秋叶原），利用了HTML5的小部分特性，制作纯(X)HTML + Javascript的游戏。和以往常见的游戏库不同，这个库的运行速度相当快，它运行塞〇达传说的流畅度与精细度让我惊叹！
这个游戏库惹人喜爱的另一个地方是它的独立性，放弃jQuery这类常用的跨平台库意味着Akihabara可以用最高效的代码完成功能；事实上，Akihabara库的源代码十分易读，对网页游戏开发将来趋势有兴趣的旅客不妨看看。
via ajaxian
PS: 说起网页游戏，就不得不说最近宣布由韩国Mgame开发的《美少女梦工厂OL》。本来让一群“爸爸”在游戏大厅交流育女信息就够让人头大了，这次还准备把养女党（抱歉）带到手机与网页上。虽然觉得RIA更有可能成为网页版的构架基础，但要有HTML5的版本就拽死了！“爸爸开个Chrome再来好好教育你”之类的台词浮想联翩……
Afterthought:
This is NOT a secure solution, although Mallory is not currently equipped to handle response from Charlie, it certainly can be adapted to do so (eg. filter incoming traffic, script injection).
I am almost certain Bob cannot trick Charlie into establishing a HTTPS connection with Alice, but I could be wrong, as one of the pre-condition for securing connection is for Alice to NOT give the key to a third-party, which we will in this case.
As a temp solution this should work seamlessly with West Chamber (which filters fake responses so Alice can maintain the connection), the difference between server Bob and Web Proxy/VPN/SSH tunnel/whatnot is that data from Charlie goes directly to Alice, so Bob’s bandwidth/CPU cost can be kept to minimal.
As mentioned in the diagram, each Bob should only handle a limited amount of users, otherwise it will be flagged as DoS. On the plus side, since no service other than authentication or request forging is offered by Bob, it has limited exposure, making it harder to identify.
If you think about it, this is effectively “a MITM solution to a MITM attack” :-) Just to keep the cat-n-mouse game exciting.
UPDATE: anchors added to image.
UPDATE2: what Mallory does is “ICMP DoS attack” (not to be confused with “ICMP flood”), once West Chamber can handle forged CM(control message), this MITM plan will be achievable.
先定义问题：大家都知道，CSS超链接的outline属性一直是为键盘用户增加易用性的好帮手（按Tab键focus下一条链接，是除Safari Win外的默认操作）。可以说，outline通常伴随着:focus事件出现。但如果你重新定义了:focus的样式，这个边框就显得很多余了。
对于标准的浏览器而言（IE8+，FF2.0+等），定义:focus时的outline:0足以解决问题。但不支持:focus的IE6和只支持超链接:focus的IE7的黑点边框又怎么解决呢？
今天花了点时间研究这个问题，最早发现的解决办法是通过Javascript解决。思路是：既然IE6和7的outline不是标准的outline（无法通过CSS定义），那肯定有某种JS可以解决。通过这篇Cody Lindley的老文章我们知道hideFocus可以禁用IE的特殊边框。
<a href="#test" onfocus="this.hideFocus=true;">link</a>
但这个方式要求每个链接都有onfocus属性，实在不太美观。Cody Lindley选择用getElementsByTagName对应添加，这是第一种思路。
在上述文章留言中有一个变种方案：既然只有IE不听话，我们用CSS Expression替换不就好了？把JS写入CSS文件，用Conditional Comment避开其他浏览器（只有IE支持CSS Expression，但我有洁癖，喜欢避免CSS警告）。
a { outline:expression(hideFocus='true'); }
众所周知，CSS Expression很耗费资源，若你的页面上链接很多那就更折磨CPU了。因此我们需要一个纯CSS的方式，cssplay的Stu Nicholls老头说纯CSS的方式可行，但没几个人看懂了他给的神奇例子。各位可以用IE去测试，每块拼图都是超链接，Tab键和右键点击却不会有黑色边框。
我花了点时间研究它的CSS，发现原来通过在超链接里附加其他inline标签，通过CSS定位可以做到隐藏IE边框的效果。
首先是HTML
<a href="#test"><span>关于萌番</span></a>
然后是CSS
a { position:relative; margin:0 48px 0 0; }
a span { position:absolute; top:-1px; left:0; cursor:pointer; white-space:nowrap; }
a:hover { background:transparent; }
a:hover span { background:#1C72B7; height:17px; overflow:hidden; }
a:active { background:transparent; }
a:active span { background:#FFF799; height:17px; overflow:hidden; color:#F4B036; }
a:focus { background:transparent; }
a:focus span { background:#FFF799; height:17px; overflow:hidden; color:#F4B036; }
基本原理是让超链接完全坍塌，IE的focus边框就不会显示了。把文字藏在span标签中，再绝对定位于链接区域里（不理解position的请看这篇文章），这样坍塌时文字就不会被隐藏了。加入white-space:nowrap避免文字换行，cursor:pointer模仿鼠标指针，最后定义span为我们希望链接显示的样式，完成对黑点边框的回避。
当然纯CSS方式也有问题：由于链接标签坍塌，我们没办法让标签宽度自适应文字长度。为避免文字相互重叠，这里使用margin增加链接的宽度，换成display:inline-block与width的组合亦可……对于特定宽度的需求，我暂时想不到任何绕过办法。
客栈的吹毛求疵到此为止，我可以满足的休息了。有CSS恶趣味的旅客不妨进一步意淫。
有鉴于Proxy将成为贫苦大众（特指“没能力购买网络服务”的网民）今后数年的必备用品，Proxy 1.0的原始框架已无法承载这种压力。最近不少Proxy 2.0的设计蓝图浮出水面，本人亦有一些考量，这里简单小结一下。
Build your dam for reasonable tsunami, not 2012. Lay your tarmac for reasonable vehicles, not Transformers.
2.0的其中一种思维是增强Proxy Security，强制HTTPS协议是首选的方式。我觉得还可以换个角度看，很多时候用户需要的并不是安全性，或者说使用Proxy的网民大多数并不清楚如何增强安全性。这时我们需要的是增加Obscurity，当然不是指降低用户界面的易用性，而是增加生成HTML代码的委婉性。
搞过计算机安全的人都知道Security through Obscurity是没戏的，那为什么放弃Security选择Obscurity呢？理由简单，基于使用Proxy的初衷。若我们希望完全防止MITM，那Security是必须的；但“窃听者是全能的”的假设是否适合一个Public Proxy？我认为值得商榷。如今用户期待的是“能正常浏览网页”，而不是“安全匿名的浏览网页”。再者，安全匿名不仅必须加密通信，还需要用户完全信任服务器运营者才行，验证后者比技术上保证前者更加困难。
降低安全假设的好处在于它能大幅度延展Proxy的设计选择。说得很玄乎，实际操作很简单。举个例：关键词破坏是国内网站常用的手段，为什么我们不能挪为己用？当然，实际运行时我们可以稍微修改一下“破坏”的方式。
正太什么的最讨厌了，萝莉万岁！
以上句子在客户端上看没有任何问题，但对于机器来说，它是——
<p>正太<span style=”display:none;”>什么的最讨厌了，萝莉</span>万岁！</p>
如此一来，正太控的内容被正常浏览了，而机器还以为我们是不懂网页标准的萝莉控。这种设计有数条好处——
牺牲复制粘贴（插入文字也会被复制）换来的是运行效率与更新速度。Proxy服务器用display:none和eval等方式处理文字与链接（Pattern Matching）比加密整个页面便宜得多。更可以在站外维护一个Keyword List，允许用户提交反馈，定时更新，照顾最新的指示。
智能系统最喜欢的东西：可预测的环境。不要给它们任何机会，尽可能破坏所有既定的网络规定。假如对方熟悉Base64与ROT13，我们就把URL换成用户可自定义的同样快速的Substitution Cipher，把随机的Client Key藏在Cookie里。若Client Key对不上，相同的请求服务器只会返回错误。我们甚至可以进一步混合时间限制，以免Client Key被重复利用。
破解Substitution Cipher需要26!个单位时间，已经大幅度超出智能系统可承受的范围。若尝试截取Client Key，则陷入Uncertainty的游击战。Obscurity再次立功。
等你成功穿越Overlord，它的手下就要来找你了，于是谈到Proxy 2.0真正的瓶颈所在——假如IP或域名下水了，Proxy的命运也到此为止。在IPv6和TLD大开放的时代（又称“网络廉价化”的时代）还没到来之前，这些东西都是非常珍贵的资源。
为此，所谓Proxy Chain需要与时代并进，履行Behavioral Separation，设置一个Reverse Proxy在Web前端，将后端服务器处理过的内容传送至客户端。不少简单的Proxy都可以改造为Reverse Proxy，放置在可爱的免费空间上，即便Reverse Proxy不幸意外，主服务器还是安全的。
与此同时，一个只处理数据的服务器也比一个拥有华丽前端的服务器隐蔽，降低被当成炮灰的危险。
回应小标题的提问——你不用的时候往invisible coat上贴个标签不就好了。别让问题卡在找invisible coat，将它转变成找标签的问题。Reverse Proxy就是这个标签，水下的冰山却是invisible coat。
除此之外，还有什么旁门左道可以使用？欢迎分享。
Secrecy is over-rated, when Google is your proxy.
