主题：【原创】云里雾里的云计算 [1] -- 邓侃
家园 关于Office文档修改问题 微软的方案是用sharepoint。如楼主说的那种文档，可以放到sharepoint上。这样只要公司有VPN，或者把sharepoint发布到internet上，就可以实现“无论你是在办公室里，还是在家里，你都可以对同一份文本进行修改”。而sharepoint有版本功能控制，可以很容易恢复到之前需要的版本。Office内置的修改追踪功能，可以很容易分辨出来何人做的修改。
Sharepoint的强大的搜索能力也让文档的寻找非常容易。
我觉得google doc和微软Office竞争，除了价钱，基本没什么优势。从功能上看，没有任何比微软先进的地方，反而从各方面看都不如。
家园 虽然如此，但既然做企业计算，WP总是要做的 好在google自己技术上也不怕MS，而且好的WP产品很多，需要的时候google收购来几个就OK了。而且，目前google doc是基于OOo的，基本功能足够一般用户使用了。
家园 邓太太这么强，那邓侃一定不差了 送花
家园 这篇写得很具体了 这篇写得很具体了。
作为用户体验，Google Docs还是比较慢，功能也不够多，目前还是office的补充，两种一起用。
gmail 对 outlook 完胜。
- 复 这篇写得很具体了
家园 "gmail 对 outlook 完胜"有些绝对吧。 几个地方gmail就明显比不上outlook，尤其是在企业用户上。
1。gmail的contact功能做得非常粗糙，而且不好用。这个问题由来已久，不知道为什么google一直都没有加强。
2。gmail没有schedule的功能。这块由google calendar完成。但这块功能做的不仅简陋，而且不能和gmail整合。所以在gmail上，想做个meeting request就很困难。而这在企业用户中是一个非常常用的功能。
3。gmail不能定时发送。比如你有一封邮件，因为各种原因，打算5点后才发给客户，但你现在马上要开一个长会，待会没时间，outlook你可以写一封email，然后让它在你选定的时间再发送。但gmail没有这个功能。而企业的销售经常会需要用到这个的。
4。最致命的。outlook整合info path, sharepoint可以很容易做出一套公文流转的OA来。比如公司里面你要报销差旅费。流程是你填表-〉交manager批准->转财务部->财务转账->通知你报销完成。如果中间被manager或财务否决，也应通知你。这个在很多企业都非常常用。但用gmail根本就没法实现。
在企业中，email系统不仅仅是一个邮件系统。很多地方都结合了商业逻辑和应用在里面，而这些gmail完全不行。所以仅仅作为一个面向internet用户的邮件系统，它是很好的。但放在企业应用中，它的不足太明显了，也太致命了。
家园 ［想法］如何为搜索加密 既然越来越多的河友对加密问题感兴趣或有质疑，我就把回帖直接放在邓侃原文下，期待更多的眼球，呵呵。
先总结一下大家的问题和论点：
－ 太守：（对于企业用户）如果只是把信息加密后存放在GOOGLE的服务器上，如何做加密后的搜索？
－ hansens 在“在基础架构层加密和不加密没什么区别”一文里说：加密的目的是要保密，这必须在信息生成的时候就加密，并且不能在最终用户读取前进行解密，这在原理上决定了，加密和检索是不相容的（也许可有单独的非加密关键字，但是对正文的全文检索肯定不行的）
上述问题是基本的，目前主流观点是搜索和加密并存在原理上不可行。
从实现上：
－ 对于我的“如果支持加密，个人认为应该是在基础架构层面”，hansens持相反意见：如果在Google的在基础架构层加密和不加密没什么区别。因为从技术上看，只要Google能解密就是不安全的。如果Google不能解密，那么也就不能检索。
从Google公开资料来看，它的确没有同时满足加密和检索的方案，但是，理论上是否可行？我先抛砖引玉一下，谈一个非常基本非常粗略的想法，很可能有大破绽，请太守，hansens和其他河友指教。
我们先来定义企业对于搜索的要求：相对于web search，企业搜索应该简单很多——没有spam，没有恶意点击，也许，email和docs搜索更简单，和传统information retrieval没有太大区别，连PageRank都不需要。
在这样的环境下：不考虑NLP，不考虑语义，不考虑name entity （例如，“张美美”明显是一个人的名字，所以搜索张美美最好不要出“一张美美的照片”等结果）等等，搜索就是看一篇文章是否含有搜索词：A, B, C, etc，以及这些词在该文中相隔的距离。
说到这，大家可能已经猜到我的答案了吧
——是的，办法就是：对原文加密，对于搜索关键词加密，只要它们用的是同一个密钥，就可以知道原文和搜索词之间的相关度了。在此过程中，原文和搜索词的加密都可以在信息进入Google的系统前进行，密钥可以掌握在企业手里，Google看到的就是一坨又一坨乱码。所以，找到答案的最好办法是简化问题
。家园 似乎不行。比如一加密后是1234，那么一二加密后肯定不是 12345678（假如二是5678的话），而一二三加密后肯定不是1234567890ab。同理，关键词加密后的密文，肯定与关键词在上下文中加密后的密文不相关。
而且google用的加密算法肯定要得到大家的认可，最省事的做法就是用通用的加密算法base64, des之类。这类算法大多采用了与明文无关的随机变换，没法做密文的关键词匹配的。
家园 这个方法理论上可行，实际上不可行! 为什么这么说呢？加密时，必须把数据进行分块对齐，比如8个字节或者512位为一块来加密，如果用这种算法加密的话，你说的用加密后的关键词去匹配是肯定匹配不到的！比如“我的名字叫张三三”，这句话，我们按四个字一块来加密，则会是“我的名字”、“叫张三三”两个数据块，你如果想查找“张三三”，那么“张三三”加密后的结果肯定是不同于“叫张三三”这个字符串的，这样你永远也搜不到正确的结果的。
那么，是不是就不能用这种办法了呢？
不是的！对中文，我们可以一个字一个字的进行加密，那么此时就可以用加密后的字符串去匹配加密文本了！
但是，这样做有如下问题：
1.当然是存储空间和计算时间的大大增加了
2.加密强度问题，如果用太简单的算法，可能较容易被破解，毕竟有那么大量的数据存放在别人那里，而且这些数据一般情况下是会显得很有规律性的（因为你是一个字一个字加密的）
不过，还是可以拿这个创意去找风投，前提是搞出一种适合这种情况的高效安全的对称加密算法来！
到时不要忘了兄弟哦！^_^
家园 乱谈12 首先声明，加密算法不是俺的特长，俺就知道个皮毛。为了简化问题，只能将待加密文件看作文本流文件。那些复杂格式中的文件（如XML,DOC,EXCEL,PDF,...ETC）暂不考虑。
1.楼上的帖子的答案建立在一个最基本的命题上 --- 加密算法知道如何分割词组（当然是对中文而言，西方文字不需要词分割，但需要组分割）。或者说加密算法具有天然的词组分割功能。情况真的如此吗？俺存疑？！
2.俺个人认为，数据压缩也可以视作一种非常简单的加密算法。不妨用ZIP方法做实验，看看能否用压缩后的关键词在压缩后的文件中搜索到结果。这样的做可能要对公开ZIP算法做点小小的改进。
家园 这个办法的保密性不高 虽然是同一个马甲，但是说话的人却有两个。
对原文加密，对于搜索关键词加密，只要它们用的是同一个密钥，就可以知道原文和搜索词之间的相关度了。在此过程中，原文和搜索词的加密都可以在信息进入Google的系统前进行，密钥可以掌握在企业手里，Google看到的就是一坨又一坨乱码。我觉得这个办法保密性不高。理由是这样的。
1. 虽然Google看到的是一坨又一坨乱码，但是通过索引，Google知道这坨乱码是怎么分词的。这个信息非常有助于Google解密。
2. 也是通过索引，Google能知道一篇文章中各个词出现的频率。这个信息也非常有助于解密。
所以，的确Google看到的是乱码，但是由于以上两个原因，Google很容易解密。
一旦解密了一篇文章，那么这个企业的密钥就被Google破解了。
这个办法可行，但是保密性不高。
家园 晕哦，注册一个“侃太"就那么麻烦吗？
家园 泼一下冷水 如果真的这么简单，早就实现了。。。。。
我的想法是，搜索在客户端实现，但也有其他问题。。。。
家园 信心最重要 信心是无价宝
对于google现在的云计算来说，对于安全的信心现在是软肋
ps：
恭喜：你意外获得【通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】