FYI @codinghorror，Chrome 团队仍然没有任何行动。
Chrome 上的问题依然存在，我们可以通过将垃圾信息保护的蜜罐替换为某种工作量证明机制来轻松修复。
再关闭两个月。
Chrome 团队似乎很乐意修复此问题，但需要在此处提供日志：
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
我看看明天能否收集一些。如果有人比我先做到，你就是我的英雄，请标记此帖子。
编辑 … 已向他们发送了日志。
@codinghorror 这个问题在 Google 内部已经陷入循环争论。他们表示该行为是设计使然，且无法准确检测文本域是否可见。
普遍的回应是：“机器人绕过这个轻而易举，那这样做的意义何在？”我确实没什么好反驳的，某种程度上我也同意他们的观点。这个蜜罐机制有点滑稽，我可以轻易用其他方式替代它，以确保用户在注册账户时至少运行了 JavaScript。
我已经在上面耗费了太多时间，感觉像是在与风车搏斗。我只想尽快落实一个修复方案，然后继续推进。
好的，但我希望这是一个相当复杂的工作量证明。有现成的代码可以调用吗？
没问题，我可以整理出一个方案，它肯定比我们目前的系统要好。我们目前的“工作量证明”机制是“反转字符串”。
我在思考这个问题上花了太多时间，所以决定是时候让它告一段落了：
根据这个提交，这里的原始发帖人（OP）的问题已“修复”：
这个修复方案有点复杂，涉及两个部分，我很高兴已经完成这两部分。
-
我大幅收紧了蜜罐（honeypot）和挑战（challenge）的逻辑。
-
我添加了一个仅客户端的变通方案，以解决 Chrome 在自动填充方面的 bug。我对此感到放心，因为它不会改变服务器端的协议。
之前，我们曾为网站上所有账户注册复用同一个蜜罐和挑战随机字符串，这使得脚本化创建账户变得非常简单，因为你只需硬编码一个值即可。
新的实现为每个用户提供一个唯一的验证字符串，该字符串绑定到你的 Cookie 存储（在我们的安全会话存储中）。该字符串在一小时后过期。
这意味着在编写脚本处理此类问题时，你必须在请求之间定期调用接口以获取全新的挑战和蜜罐，而不能简单地批量创建账户。
第 2 点中的变通方案只是将 Chrome 感到困惑的一个 INPUT 元素移出，并替换为一个 Chrome 不会混淆的 type="text" 类型的 INPUT 元素。
总体而言，我认为第（2）点并不会让“通用”编写的、在未知网站上注册账户的机器人变得更简单。首先，该机器人需要使用 Chrome WebDriver，解析我们所有的 Ember 代码，然后遵循非常特定的流程。这一特定障碍非常低，与新的每用户轮换挑战机制相比简直不值一提。
至于添加工作量证明（proof of work），我想再等一段时间。这并不是因为构建它特别困难，而是因为我并不想四处寻找最快的 SHA1 算法，然后按需将其发送给客户端。
我将此问题保持开放状态一段时间，以便大家确认我的修复是否解决了该问题。我将在一周后关闭此问题。