IE8 SmartScreen筛选器的一个重要的里程碑

原文链接(Windows团队blog):http://windowsteamblog.com/ie/b/ie/archive/2010/07/23/internet-explorer-8-smartscreen-174-filter-reaches-important-milestone.aspx 原文作者:James Pratt   SmartScreen团队刚刚告知了我,我们已经到达了一个令人惊喜的里程碑:IE8已经阻拦了10亿次恶意软件下载! 社会工程学攻击和恶意软件一样,是互联网上一个正不断增长的威胁,也是人们上网时最常见的风险之一。作为SmartScreen筛选器(英文链接)的一部分,我们在IE8中加入了恶意软件防护,并且在过去的一年中,已经在Windows体验blog(英文链接)中谈论(英文链接)过若干次(英文链接)了。 关于这10亿次阻拦,我们提供了如下简要的事实: NSS实验室在2009年8月(英文链接)和2010年3月(英文链接)的两份报告中,对IE8,Chrome,Firefox和其他浏览器进行了比较并认可IE8的SmartScreen筛选器在阻止社会工作学的恶意软件攻击方面,处于领先地位。 我们的恶意软件阻拦率不断提高也源于我们不断地改进SmartScreen的后台服务。 比如在2009年8月,我们已经阻止了7千万次恶意软件下载(英文链接)——或者说每月阻止1千8百万次。在那时,根据Net Application的统计,大约15%的互联网用户使用IE8。在过去的两个月中,我们已经阻止了1亿次恶意软件下载。上个月,根据Net Application的统计,大约有26%的互联网用户使用IE8。和2009年8月相比,IE8的用户增长了1.7倍但我们每月阻止的恶意软件下载已经变成了之前的5倍。   10亿将恶意软件拦截是一个惊人的里程碑。它同时也证明着两件事:第一,社会工程学攻击,比如恶意软件,仍然是互联网用户的真正威胁。第二,为保证你的在线安全(英文链接),你的浏览器需要不断地改进并加强其服务。正是因为我们在2009年3月发布IE8之后仍不断地在后台服务方面进行投入,才使用SmartScreen筛选器能在阻止恶意软件方面做得越来越好。正是这样的投入,使得我们保持在社会工程学恶意软件图表(根据NSS实验室)的最上方。这项投入,已经保护了用户的在线安全。 如果你还没有升级到IE8,现在你就可以通过登录www.microsoft.com/ie来升级。如何你已经升级到了IE8,你可以检查SmartScreen筛选器是否已经打开。方法是:选择“安全”菜单,单击“SmartScreen筛选器”。如果菜单显示的是”关闭SmartScreen筛选器“,那说明SmartScreen筛选器已经打开。 原文作者:James Pratt,高级产品经理 原文来自:Internet Explorer Business and Marketing Team

0

硬件加速的HTML 5:第一个IE9平台预览版就绪(面向开发人员)

(本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/03/16/html5-hardware-accelerated-first-ie9-platform-preview-available-for-developers.aspx) (译者注:我正尝试以更有文采的方式翻译此后的技术文章,如有与原文冲突之出,以原文为准。本译文不代表IE官方观点。特此声明,永远有效。)       当我们开始深入地接触HTML 5时,我们便感觉到其必将开拓一系列新的应用。而这些应用也必将以不同于今天既有的方式,对浏览器及硬件提出更高的要求。我们很快便认识到,正确实现HTML 5——我们最开始的初衷——更多的是关于如何设计支持HTML 5新应用的浏览器子系统,而不只是一组新的功能罢了。所以从一开始,我们给IE9规划的目标便是:通过Windows,基于先进的硬件系统,打造专业级别的,现代的,对HTML 5的支持。       在今天(译者注:美国西部时间2010-3-16,下同)的MIX大会(英文网站)上,我们展示了那些开发人员已经了解并广泛使用的标准网页模式,如何在Windows上的IE9中利用计算机硬件更出色地运行。这一篇博客将提供我们今天所展示的内容的概况,其包括:性能、标准、硬件加速的HTML 5图像及面向开发人员的IE9平台预览版就绪信息。       首先,我们展示了IE9的新脚本引擎——内部称之为“轮”(英文Chakra,见百度百科Chakra和七轮)。与此同时,我们也展示了在一项JavaScript性能基准测试中所取得的进展。通过把脚本引擎在基准测试中的差距区别缩小至一眨眼的工夫,我们借此诠释了我们是如何让真实的网络运行得更迅速。Chakra会以和IE并行的方式,在后台使用独立的CPU内核编译JavaScript脚本。       我们致力于使基于标准的HTML,脚本和格式化标记(formatting markup)可以跨浏览器工作。我们分享了可以说明我们使上述目标得以实现的数据和框架,并展示了对若干标准更好的支持,这包括:HTML5, DOM和CSS3。我们展示了IE9最新的Acid3得分:55。随着我们不断地追求行业标准被制定时的目标——使开发者真正使用的标记(markup)在各浏览器中工作,我们的Acid3得分必将不断提高。我们已经向标准组织提交了测试用例,这是我们承诺参考标准流程的一部分。我们已经将这些测试用例公开,任何人都可以用来在任何浏览器上尝试。       我们通过若干实例,向大家展示了具有丰富图像的交互性的网页可以获得的,来自浏览器的性能上的巨大提升——当这个浏览器通过操作系统充分利用PC硬件能力时。同样的HTML,脚本和CSS标记可以跨浏览器工作,且在IE9上自然而然地更快速地运行——因为IE9使用了硬件加速。IE9还是第一个提供SVG硬件加速的浏览器。       最后,我们宣布第一个面向开发人员的IE平台预览版已经就绪,并保证我们将每8个星期左右,提供一次更新。我们希望开发社区可以更早地亲身体验我们在IE这个平台上所进行的工作。与以前的IE发布相比,平台预览版及其反馈标志着IE发布工作的一个主要变化。 性能       IE9有一个新的JavaScript引擎,“轮”。这里有一张图,展示了IE9在一项特定的JavaScript性能基准测试,Webkit Sunspider,中的表现:       你可以注意到,在这项基准测试中,IE9比IE8和其他一些浏览器更快。值得指出的是,IE9预览版和在其右边的浏览器的差别很有意思:我们需要大约70秒才能识别出这300毫秒的区别。       随着我们使IE9的脚本引擎在真实的网站中执行得更快,IE也将会在这一特定基准测试中表现得更好。到目前为止,我们几乎没有针对Webkit Sunspider进行任何的优化。和大多数的基准一样,测试结果可能随机器的不同而得出不同的结果。       我们在浏览真实网站时所体验的性能,相比起JavaScript,更多地取决于浏览器的其它子系统。比如,一些网站会花更多的时间布局其页面或渲染,而不是运行脚本。在这个博客贴(英文IE博客,未翻译)里的第一张图表用数据表明了这一点。今天的PC拥有特定的硬件来加速图像性能。IE9使用广泛应用的硬件来加速网页中的所有文字和图像,从而使网页显示得更快。       为了进一步提高JavaScript的性能,“轮”做了一些和其他脚本很不同的事。“轮”使用一个单独的后台线程来编译JavaScript。如果有一个单独的CPU内核可用,Windows将使用它并行地执行此线程。后台编译将使得IE可以在生成更快的代码的同时,让用户不中断地浏览和使用网页。因为是在后台单独运行,这样的工作流程,可以充分利用今天的多内核机器——所以,拥有Core2Due,QuadCore,i7或者Phenom II的用户已然可以拥有使网页显示得更快的能力。       对于开发人员来讲,无需更改其网站的任何内容,便可得到现代PC硬件所带来的性能提高。用户则拥有更少的等待,更多的交互——就像一个本地程序一样。这样的设计使得已经在众多真实网站中应用的网络开发模式,获得更好的性能。而这些的关键就在于把最好的技术,带入到开发者所使用的最重要的语言,JavaScript,当中去。 标准       标准和互操作性的目的是使相同的HTML,脚本和格式化标记在不同的浏览器当中一样地工作。消除为不同浏览器写不同代码的需要可以使每一个人受益,也会带给开发人员更多的机会从事创新工作。       许多标准仍在不断完善。他们要么还只是草案,要么被不同的浏览器以不同的方式部分地实现。开发人员正面对一个艰难的选择:他们需要更加努力地工作,写更多而且不同的HTML,脚本和标记,只是为了在不同的测量员中得到相似,而并不总相同的结果。       我们希望相同的标记真的能在不同的浏览器中有同样的结果。在IE9中,我们继续完善我们的平台,正如我们在IE8中为CSS 2.1所做的一样。IE8提供了一个高质量的CSS 2.1的实现,坚持标准又兼顾其他浏览器在标准不明确之处的行为。开发人员可以期待业界为此有更多的努力以使HTML5的应用更容易开发。       我们在这方面的努力是从数据开始的。开发人员真正使用的DOM(Document Object Model,文档对象模型,译者注)和JavaScript API是IE9标准支持方面的基准。为了得到这些数据,我们开发了一个工具,用以检验7000多个最常见网站的API使用情况。这里有一个分布图表,表明了每一个API被多少网站所使用。我们会在以后的博客中讨论这些数据的更多的细节。        我们致力于完成每一项出现在上述数据中的业界标准。在IE9中,你也会看到我们支持了一些并没有出现在上述数据中的标准——那是因为我们需要提供一个完整HTML 5应用所必须的一切。       …

1

技术文档翻译并不轻松啊

本以为三天可以完成的关于IE9的第一篇博客,竟然用了近一个月的时间。而且,对于遣词造句,也没有能做到我当初想像中的那样精致。不过也感觉到了一些翻译的乐趣。那就是用不同的语言,表达相同的情感——即使文字上相差很多,却微妙地表达了同样的内容,语气和情感。 我只希望读者能觉得我的翻译有用。至于有益,甚至有趣,却是不敢奢望。如果读者见到译得不妥之处,还望不惜赐教。 如果读者希望我翻译哪篇IE的博客,也请告之。我尽力而为。

1

IE8 如何确定文档模式

(本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx) (译者注:由于时间关系,没有办法将图解完全翻译——因为我太希望开始翻译关于IE9的内容。如有关于IE博客翻译或相关技术文章翻译的请求、建议及意见,欢迎留言。如留有联系方式,我会在必要时联系留言者,谢谢!) 本文将讨论IE8如何确定用以渲染网站的文档模式,如怪异模式(又称IE5模式)和标准模式(更多资料,英文:http://en.wikipedia.org/wiki/Quirks_mode)。该内容对于开发人员和客户来说,是很重要的。 与此相关的,是我们最近更新的兼容性视图列表。此列表内容自从去年3月IE8发布以来,已经减少了1000多个网站。从最初的3100多,减少到了现在的2000多一点。在与网站开发人员及标准制定人员的共同努力下,我们很高兴地看到需要出现在兼容性视图(CV)列表中的网站不断地在减少。 数据驱动的设计 在讨论设计细节之前,我想和大家分享一些我们用于设计兼容性体验的数据。 让我们来看一下世界范围内的上千个高流量网站,如qq.com和netlog.com,以及那些最初列入兼容性视图列表中(英文资料:兼容性视图列表)的网站的doctype(wikipedia英文资料,百度百科,CSDN社区)和X-UA-Compatible meta标签和头部: 26%的网站指定使用怪异模式,如果amazon.com,tworld.co.kr和unibanco.com.br。 41%的网站使用了Transitional文档类型,即准标准模式(mozilla英文资料)。 14%的网站已经添加了X-UA-Compatible meta标签或HTTP响应头,从而使用IE7标准模式进行渲染。 以上的数据是可以理解的:许多高流量网站需要在尽可能多的浏览器中渲染,这就是为什么他们会使用怪异模式。许多网站有专门针对IE7的页面而且许多网站创作工具,如Aptana Studio(英文网站)和Expression Web,则默认指定使用Transitional文档类型: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 如果考虑一下网络的规模,那么将有几十亿的网页,分别指定使用怪异模式,IE7,准标准模式,或最新的标准模式。IE需要支持所有这些网站以确保世界范围内的用户拥有最好的体验。 有这些数据在手,我们设计IE8时考虑到了以下一些原则: 默认情况下,使用最标准的方式渲染网页。 如此前(IEblog英文,未翻译)的帖子(IEBlog英文,未翻译)所明确的,我们致力于互操作性,这便意味着默认情况下,使用最标准的方式渲染网页。 用户只是期待网页在IE中正常工作。 一小部分用户将需要改进那些在IE7标准模式中工作得最好的网站,以便使其可以工作在IE8的最标准的默认模式中。至于其他所有人,IE8提供了兼容性视图设置(IEBlog英文,未翻译)。 在这里,最好的用户体验是一切自动地如网站设计者希望的那样工作。这就是为什么我们提供了兼容性视图列表(MSDN英文资料)。与此同样重要的是,用户可以通过兼容性视图按钮,修复那些尚未加入列表中网站。 网站开发者完全掌控他们的内容如何被渲染。 X-UA-Compatible meta标签和头部会覆盖IE和用户的设置。他们也使网站开发者可以细粒度地调控如何在IE中渲染每一个网页。 比如,有些网站拥有一些专门为怪异模式写的网页,而另一些则为IE7标准模式。当IE收到的X-UA-Compatible头的值为EmulateIE7时,便会相应地以怪异模式或IE7标准模式进行渲染。 给网站开发者以工具和时间,帮助他们转换到IE8标准模式。 IE8引入了X-UA-Compatible meta标签和头部,这便给网站开发者提供了时间以转换到IE8标准模式。正如上文提到的,许多网站已经使用了这些机制来指定他们的内容必须使用IE7标准模式。 IE8如何确定文档模式的图解 给定了以上的原则,这里有四条规则明确了IE如何处理文档类型(doctype),X-UA-Compatible meta标签和头部,开发人员工具,以及兼容性视图设置。这些标准自上而下出现在下面的图解中。 开发人员工具的设置会覆盖一个标签(tab)中所显示的页面的全部文档模式。 X-UA-Compatible meta标签及此后的头部,覆盖兼容性视图设置和文档类型(doctype),除非X-UA-Compatible的值是EmulateIE7或EmulateIE8。 用户的兼容性视图设置(IEBlog英文,未翻译)会覆盖微软兼容性视图列表(MSDN英文资料)。 如果没有上述规则中的任何一种可以适用,则有文档类型(doctype)将决定网页使用以下哪一种模式进行渲染:IE8标准模式,IE8准标准模式,或怪异模式。 兼容性和互操作性是很复杂的。为了降低开发人员和用户使用的复杂度,我们希望看到更多的网站淘汰旧式的浏览器模式。我们也尊重网站开发人员对模式的选择。我们很高兴和网站所有者及标准组织成员继续(IEBlog英文,未翻译)提高(IEBlog英文,未翻译)IE的(IEBlog英文,未翻译)互操作性标准的实现。 非常感谢Jesse Mohrland对图解的检验。 原文作者: Marc Sibey Program Manager

0

Adobe Flash现已支持InPrivate浏览

本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/02/11/adobe-flash-now-supports-inprivate-browsing.aspx Adobe Flash现已支持InPrivate浏览     作为一款浏览器,IE也是一个支持各种各样加载项(add-on)的平台(这里有一些很不错的实例)。IE使用者通常在涉及性能,稳定性或隐私性的时候,并不将加载项和IE本身区分开。大家都只是使用IE并希望其正常工作。这就是为什么那些最棒的加载项可以和IE很好的集成并让用户只是“浏览”。     最近,Adobe宣布他们最新的Flash已经支持InPrivate浏览。现在,Flash版本10.1将会响应我们在IE8中加入的接口。当你浏览一个包含Flash的网站时,Flash可以保存“Flash Cookies”。“Flash Cookies”是一些由Flash创建的,网站可以用来保存数据的文件。现在,就如同IE的浏览历史和cookie一样,这些Flash文件也会在InPrivate浏览窗口关闭时被删除。     我们非常高兴看到Flash集成了InPrivate浏览功能,而且很高兴地看到他们也同样支持Firefox和Chrome中的隐私浏览。好样的,Flash团队! 原文作者: Andy Zeigler Program Manager   相关内容: InPrivate浏览: Internet Explorer 8 隐私浏览 加载项:加载项资源库

0