目前有很多互联网服务要求用户提供其他网络应用的帐号密码以得到一些私人信息，比如各类SNS导入邮件系统联系人作为好友时。
不得不说，对于一些不那么知名且有信誉保障的网站，我根本不敢填入自己邮箱的账号密码。而即使是一些有信誉保障的网站，也难免出现员工作乱或者黑客入侵一类的事件。将如此敏感的信息就这样交付他们，始终还是不放心。
目前为止，比较可行的方法也许就是Google的帐户认证及OpenSocial功能，将身份验证及通讯录读取过程都回归到Google这边，让用户放心。
不过目前采用这类方法的毕竟是少数，而且除开Google，其他站点就不适用了。我有一个想法，自己感觉在理论及技术上可行的，与大家讨论一下：
- 公开需要用户提供邮件类帐号密码网页的源码。
- 比如用户在“import_contacts.php”这个页面填写自己的敏感信息，那么这个页面的源码就得对所有用户公开。
- 由所有用户来监督这个页面的代码，保证账号密码只做验证用，而不会被该网站记录下来。
暂时就想到这些，应该还有很多细节没想到，各位朋友一起来讨论下吧。
“如何让用户放心交出账号密码?”上的10条回复
如果用户看不懂源代码怎么办？
这种事情最好的办法还是长时间的积累，对于信用的积累以消除用户的疑心。
@oxygen, 不是一个用户在监督，而是所有用户啊。只要有一人发现问题就够了吧
我想你應該去看看OAuth和AuthSub，GData支持基於這兩種協議的守保護資源請求。
基本原理，就跟你用uploader訪問Flickr時一樣，Flickr明確授權這個客戶端僅可以上傳還是瀏覽和刪除。只不過，OAuth可以根據具體根據業務邏輯設計上層協議，例如我要從Flickr某個相冊輸出照片到打印服務，那麼就僅僅授權這個相冊的只讀訪問，並且時間只有一個小時。當然Flickr不支持這樣的設置，只是打個比方。
最最重要的，這樣授權，第三方服務只能得到一個授權令牌，你不需要給用戶名和密碼它。
可以想FriendFeed的API一样，提供一个非密码的验证码来做账户验证
现在网络越来越不安全了，什么骗术都有，只有纯洁的网络才能让用户安心。
所以特怀念2002年以前的网络.
那时候人特单纯.
@Cat Chen, Oauth这个得从服务提供端考虑，我指的是在OAuth一类服务普及前，作为资料需求方的方案。
@hidecloud, 現在Google支持OAuth和AuthSub，你要讀取Gmail好友可以通過這種方式讀取。至於不支持OAuth或者AuthSub的服務運營商，可以直接去死了。
公开源码这个肯定做不到，即使做到了也没用，他始终不会全部公开，或者说公开了那部分跟实际的不同。
这方面还是得考诚信吧
公开验证页面的代码并不会泄漏什么该站信息，验证一个状态而已。