This morning, my editor asked why I hadn't blogged about Internet Explorer 8. My response: "Who cares?" Do you? Maybe we both should. For weeks, Microsoft has been dribbling out information about IE 8, which has to be released as a public beta this week to make the self-pronounced August release. The most recent IE 8 blog post discusses new privacy features.
Simply put: IE 8 will let its users decide to whom they release information about their browsing habits. There are also security benefits to the new privacy features, which could be useful for limiting increasing malware risks posed by file-sharing or social networking sites. I'll be interested to see how the new privacy features work with parental controls, seeing as how IE 8 also could allow troublesome teens to better hide online activities from parents.
Internet Explorer has long had better privacy controls than competing browsers because it supports P3P, or Platform for Privacy Preferences. Because of P3P, IE has more granular control over first-party and third-party cookies and what users do about them. For years, I've used custom settings under IE's Privacy control to "block" third-party cookies and to "prompt" for first-party cookies. P3P support offers some opt-in, where the user can once and for all accept or reject all cookies from the originating site.
Firefox 3 improves the open-source browser's cookie controls with an option to "accept third-party cookies," which is on by default. The user can also specifically designate Web sites for which cookies are always accepted or rejected. It's a nice implementation, but IE 8 is set to greatly extend cookie control and how session data is handled. Microsoft is catching up on its early privacy lead and, in some respects, retaking it from Firefox.
Great Performance: How to build a faster browser
As we started planning what we wanted to accomplish with IE8, we made a conscious decision to improve how people use Internet Explorer to browse the web. Broadly stated, some of the areas we pinpointed for improvement include browser startup, navigation, and user interactions (including AJAX-style interactions within a webpage).
Part of that focus has translated into our investment into new features like Web Slices, because in some cases the fastest browser is the one that does not need to load a webpage at all. Beyond these efforts, we have also concentrated on improving IE as a web platform.
When we took a hard look at our goals and considered what we could do to build the best browser we were presented with a quandary. On the one hand, we could focus very narrowly on scripting performance, trusting that our investment would noticeably improve our users’ browsing experience. Alternatively, we could invest more broadly in realistic scenarios, measuring heavily-used subsystems and investing our optimization effort accordingly. We opted for the latter approach.
After some analysis, what we found was that investing the entirety of our effort on improving JScript would not substantially improve our users’ browsing experience in most cases. For a sample of the type of data we used in our analysis, I’ve included below a breakdown of the CPU cycles consumed by some of our key subsystems when navigating to the top 100 sites in IE8 Beta 1:
| Layout | Rendering | HTML Parsing | Marshalling | CSS Formatting | DOM | JScript | Other |
| 43.16% | 27.25% | 2.81% | 7.34% | 8.66% | 5.05% | 3.23% | 2.49% |
Notice that when navigating to the top 100 sites the systems exercised in typical JScript/DOM benchmarks (e.g. SunSpider) account for less than 10% of the total time. Furthermore, we analyzed several common AJAX applications and performed similar analyses, with similarly surprising results:
| Layout | Rendering | HTML Parsing | Marshalling | CSS Formatting | DOM | JScript | Other |
| 8.87% | 8.68% | 1.48% | 7.40% | 36.72% | 11.72% | 13.59% | 11.54% |
source: microsoft-watch.com
www.vista123.net, easily tweak and customize your Windows Vista.
