BY THE TIME I’d “met” Nick Drake he was already long dead.

I believe it was after the “Pink Moon” Volkswagen commercial that aired in the United States. It’s possible I’d heard him before but I’m pretty sure I’d remember.

I’ve been listening to Nick Drake now nearly 10 years. What about you?

When did you see/hear/learn about Nick Drake?

Perfection has no stopwatch.

by Molly at August 27, 2008 04:09 AM

Hi! I'm Christian Stockwell, and I'm helping to improve Internet Explorer performance.

In the past few months, each of the browser makers has made very similar claims around their performance: "Superior speed and performance"�, "The fastest and most powerful Web browser available"�, and "The fastest web browser on any platform."� In some fundamental way, I think the likeness of these statements is a by-product of the complexity inherent in performance measurement and analysis.

Rather than join the chorus and trumpet IE as the fastest browser in the universe, this post is my attempt to demystify the performance work that is being delivered as part of IE8 so that you can understand how we are making you more productive.

Best of all, you don't need to take my word for it. As Dean mentioned back at MIX08, Google has commented on our IE8 Beta 1 improvements (emphasis mine), and we've made IE8 even faster since then:

"Some of the tests we have done show pure JScript performance improvements up to 2.5 times. We also measured the performance gains on common Gmail operations, like loading the inbox (34%), opening a conversation (45%) and opening a thread (27%) compared to IE7."�

Before I delve too far into the body of this post I am going to first take a step back to explain how the IE team thinks about performance. I will then discuss some of the performance work that has gone into IE8 and how it will make IE8 a better browser for user and developers. Lastly, I will touch on some of the great IE8 features that give web developers the right tools they need to be more productive and to build the next generation of great sites.

The Big Picture: Performance and Productivity

"Every language has an optimization operator. In C++ that operator is "˜//'"�

- Overheard at the O'Reilly's Velocity Conference, June 2008

To describe the effort we are undertaking with IE8 we first need to take a step back to consider the relationship between performance and productivity. Most importantly, recognize that browser performance is a means to an end. The end goal is to build a platform that makes users and developers more productive. If we ignore that target the task of building a fast product is suddenly much easier: do precisely nothing.

For IE8, the recognition that users want to accomplish a set of actions when they browse the web has manifested itself in many of the features we have disclosed to date in IE8. A clear example that improves user productivity is Web Slices. Consider, for example, how Web Slices delegate the browser to check for updated content on behalf of users.

Both of these features present new productivity options for both users and developers. For users, the benefit of having common actions distilled into two quick button presses is obvious. Developers, for their part, can consider the benefits of quickly introducing new lightweight Web Slices instead of investing hundreds of developer hours tuning site loading speed for the hordes of users compulsively refreshing their pages in the pursuit of updates.

Beyond these two manifestations of our focus on productivity, IE8 includes many key improvements. In the first section below I describe in greater detail the work we've done to date to improve your productivity. The last section of this article discusses some of the great developer features we've built that will give site developers the right foundation they need to efficiently build faster sites in Internet Explorer.

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:

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:

Even on a typical AJAX site (these numbers are for a leading webmail sites) it is telling that the JScript and DOM subsystems contribute less than a third of the total time.

Based on this data and other analyses we performed it was clear that to significantly improve browsing in IE8 we needed to make improvements to several areas of our code beyond JScript. In addition to discussing our improvements to the JScript engine I cover three of those areas below.

Performance benchmarking suites like SunSpider are still an important part of how we analyze our progress. They are a certainly valuable as a means to measure progress and to analyze some aspects of browsing performance in a laboratory environment. They are most useful when we understand how they fit into the larger scenarios we are trying to improve.

In particular, our analysis of IE subsystems has helped us understand where improvements to benchmarks translate into improvements to overall browsing speed. Ultimately though, performance benchmarking suites do not provide complete coverage for browsing performance and how well they represent your particular browsing habits may vary.

Scripting Improvements

As part of our broader effort to improve performance in IE8, we did make large investments in JScript performance to make pages faster and to help developers be more productive.

The JScript engine included with IE8 speeds up many common user scenarios. We have made huge improvements to widely-used JScript functionality including faster string, array, and lookup operations. We have also made changes to our core architecture to drastically reduce the cost of functions calls, object creation, and lookup patterns for variables scoped to the window or this objects.

Some of those improvements have been driven by existing bottlenecks in our code. Two longstanding developer pain points, String and Array operations, are in some cases now faster by several orders of magnitude compared to their previous incarnations. These improvements mean that developers no longer need to expend time and effort developing arcane workarounds to avoid slow areas of IE's JScript implementation (no more array push-joins to avoid string concatenation!). Moreover, these changes have contributed to improve IE8's performance on the SunSpider benchmarking suite by 400% compared to IE7.

Since most users do not use their browser solely to run JScript benchmarking suites, what's even more important is that we've made many sites measurably faster. Our work to improve IE's JScript engine has been instrumental in earning us positive feedback like that from Google.

Memory Management Improvements

The second area in which we are invested heavily in IE8 is in improvements to our memory usage. To date we have fixed just under 400 separate memory leaks in Internet Explorer. We have also worked hard to improve our heap fragmentation and memory usage on AJAX pages. For users, these changes reduce the amount of memory consumed by IE, improve our startup times, speed up navigating between pages, and help IE remain stable for longer periods of time. Besides these great benefits to end users, our work in this area should take a significant burden off of developers.

Specifically, we have worked hard to mitigate some common causes of leaks between our JScript and DOM. In previous versions of IE the JScript garbage collector (GC) managed the lifetime of JScript objects but not that of DOM objects. As a result the GC was unable to break circular references between DOM and JScript objects, resulting in memory leaks unless site authors took it upon themselves to carefully manage their memory footprint. In complex AJAX sites this is a daunting task and can easily consume lots of developer time.

In IE7 we made some improvements to this area by breaking those circular references when users navigate away from leaking pages. That mitigation, however, is not a long term solution for the complex interactive pages that users expect today.

With IE8 we have significantly augmented the garbage collector so that it can break many circular references over the lifetime of a site, reducing the burden on developers. Due to that work developers can spend more of their time focusing on building world class user websites and less on the minutiae of memory management.

Networking Improvements

As we started building IE8 it was clear that we could do more to take advantage of the increasing prevalence of high bandwidth connections. Two key improvements we made with IE8 were to unblock downloads in the presence of external scripts and to increase the number of parallel connections per server that we support.

Early in the inception of IE8 we recognized that blocking on external scripts was suboptimal given the modern reality of relatively inexpensive CPU cycles and the important role network latency plays in the performance of many websites. When IE8 encounters an external script we continue parsing on a second thread to ensure that we continue downloading page elements as fast as possible. In many cases that change will users' favorite pages will download faster and developer will no longer need to spend time ensuring that scripts do not serialize their downloads.

In IE8 Beta 1 we also increased our per-server connection limit from 2 to 6. What this means is that in IE7 and below pages could only download 2 elements from a given server at any one time. Increasing that limit to 6 allows sites to download 3 times as much content in parallel, which should translate into faster page download times when bandwidth is available.

Rendering Engine Improvements

The last large area of I am going to cover in this post are the improvements we have made to layout and rendering in our new standards mode engine.

For those of you following IE8's development, it should come as no surprise that we are building a new CSS 2.1 compliant rendering engine. As you may have guessed from the subsystem data I presented earlier in this post, we have also recognized that rendering and layout performance is a large component of overall browsing speed.

To ensure that developers and users are more productive in IE8, it is therefore clear that we need to deliver a great engine that does not introduce any performance penalty vis-à-vis the browser as it exists today.

In Beta 1 our standards mode engine was much slower than our IE7 engine. Over the last few months we have been making improvements by leaps and bounds. By our upcoming Beta 2 we expect our standards mode engine to be at parity with our previous implementation for many sites. Going forward we will continue to invest in this area with the goal that when IE ships, developers do not have to make any difficult decisions: developing for our new engine will produce sites that work better across browsers and as an added bonus they will be faster too!

The combination of the performance improvements I've outlined above mean that many sites will be faster in IE8, allowing our users to be more productive than ever before. At the same time we have also eliminated numerous rough patches so that web developers can build great sites in less time.

Best yet, with IE8 Beta 2, developers can see further improvements to our developer tools that will make them more productive developing lighting fast sites.

New Developer Features

Beyond the various enhancements we've made to IE8 to make you more productive when browsing the web or creating new sites, we've also added support for several key new technologies that you can harness to make your websites faster. In the remainder of this post I will briefly discuss three of my favorite IE8 developer features.

Data URI

Are you tired of spending time writing code to use CSS spriting to minimize network overhead of using many small images on your site? If so, the first of my favorite features may be just for you. With IE8 we add support for RFC 2397's Data URIs. Instead of using a URL to point to an image file (and incurring additional round trip costs to transfer that file to the browser), you can use Data URIs to encode the data directly.

For instance, here is a Data URI representing a 10x10 blue dot (base64 encoded):

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKAQMAAAC3/F3+AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAANQTFRFALfvPEv6TAAAAAtJREFUCB1jYMAHAAAeAAEBGNlaAAAAAElFTkSuQmCC

You should note, however, that Data URIs should be used sparingly because they incur some client processing overhead due to their base64 encoding and because they cannot be cached in the same as images retrieved over the network. Since Data URIs are embedded directly into a document, script, or stylesheet you should try to embed them within one such element that is in turn cacheable.

Selectors API

In addition to our support for Data URIs, IE8 also supports the Selector APIs querySelector and querySelectorAll to let you lookup selectors from JScript orders of magnitude faster than you would previously using implementations included in frameworks. In informal tests against our recent builds I've seen some tests improve from several seconds to mere milliseconds when comparing our native implementation against the alternatives offered by common frameworks. For more detail regarding our implementation of the selectors API please refer to our Selectors API whitepaper.

JSON

The last of my three favorite IE8 developer features is our support for JSON, announced in an earlier post on this blog.

Developers on AJAX websites often use JavaScript Object Notation (JSON) to pass data between components of their site. In previous versions of IE developers were often forced to use JSON insecurely by using JScript's eval method to revive JSON strings back into JScript objects. More secure sites typically used a more secure JSON parser to sanitize their JSON objects"”often at the price of significant performance penalties. In both cases user and developer productivity was severely compromised.

To make everyone's life easier with IE8 Beta 2 our JScript engine implements the ECMAScript 3.1 JSON proposal's JSON.stringify and JSON.parse methods, providing a speedy and secure solution to a common developer problem.

Other great features

Those are my three favorite features that developers can harness to build better sites in IE8. Of course, your favorites may vary because beyond those three features we have great collection of developer features that you can take advantage of to build faster sites.

Our support for DOM storage (10mb of local storage per site!), XDomainRequest (secure cross-domain communication without a server-side proxy), and Connectivity Events (script can now tell if a user is connected to the internet) are all very powerful features that developers can harness to build faster websites.

Moreover, I am confident that our investment in tools and features for developers ensures that building fast sites in IE8 will be an easier and more transparent process than in any previous version of our browser.

I hope that this article has helped you understand a little better how our performance work fits into the Internet Explorer team's goal of making us all more productive. Although it is often tempting to obsess about particular performance benchmarking suites I have always found it valuable to take a step back and look at the bigger picture for a moment to put everything in perspective.

With that in mind, I do recognize that your expectations are pretty high. We have lots more performance work planned for IE8 and I encourage you to keep following our progress as we release our upcoming Beta.

Christian Stockwell
Program Manager & Performance Geek

by ieblog at August 26, 2008 11:19 PM

In the "oh wow, I didn't know JavaScript could do that" category, I just came across a cool new jQuery plugin called jParallax which implements a parallax effect on selected elements. Now, I'm not ashamed to admit not knowing what "parallax" meant so I looked it up on Wikipedia which totally added closure to the concept being implemented. Till then, I just thought that was a really cool effect!

Parallax turns a selected element into a 'window', or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way.

jParallax includes several options for controlling the effect including setting the animation timing and layer positioning control. The demos can be viewed here.

We also covered Brett Taylor's implementation of a parallax effect last year where he showed how to build parallax backgrounds.

Update: I've added straight links to the demos

by Rey Bango at August 26, 2008 02:36 PM

Last week I wrote a simple WhereAreYou? application that used the Google Ajax APIs ClientLocation API to access your location via your IP address.

At the same time, we announced support for the Gears Geolocation API that can calculate your address using a GPS device, WiFi info, cell tower ids, and IP address lookups.

Add to all of that, the W3C Geolocation API that Andrei Popescu of the Gears team is editing. You will notice that it looks similar to the Gears API, with subtle differences. The ClientLocation API is quite different.

To make life easier, I decided to put together a shim called GeoMeta that give you the W3C Geolocation API, and happens to use the other APIs under the hood.

If you have the Geolocation API native in your browser (no one does yet, future proof!) that will be used. If you have Gears, that API will be used, and finally, with nothing the ClientLocation API will be used behind the scenes.

To you the API will look similar:

// navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options)
navigator.geolocation.getCurrentPosition(function(position) {
      var location = [position.address.city, position.address.region, position.address.country].join(', ');
      createMap(position.latitude, position.longitude, location);
}, function() {
      document.getElementById('cantfindyou').innerHTML = "Crap, I don't know. Good hiding!";
});

At least, that is what I would like. Unfortunately, there are a few little differences that leak through.

• The W3C API only seems to give you a lat / long, so you have to do the geocoding to get address info
• The Gears API gives you an additional gearsAddress object attached to the resulting position object. This can contain a lot of information on the resulting area (street address to city to ...) however for certain providers the API returns that as null, the same as the W3C standard
• That gearsAddress object has slightly different information from the address data that the ClientLocation API returns. NOTE: I would love to see this just called 'address' to help the shim.

To give you control when you need it, you can ask the navigator.geolocation object what type it is. navigator.geolocation.type will be null if it is native, but 'Gears' or 'ClientLocation' if a shim kicks in. You can also check navigator.geolocation.shim to see if it is augmented code.

Implementation

There is some fun implementation code in there if you poke around. For example, for the ClientLocation API, when you make a call, it will be added to a queue if the Google Loader hasn't fully loaded yet, and it will kick off that call when finished. Dealing with dynamically creating <script src> as a loading mechanism sure is fun!

I like the idea of jumping straight to the W3C standard and updating the shim as the APIs change. That way, when browsers catch up, the code will still work using the native APIs and you don't have to change a thing.

I also hope that we get general reverse geocoding in place, which would enable me to even take the native "standard" and strap on useful address info to the bare bones lat/long.

by Dion Almaer at August 26, 2008 02:14 PM

John has announced the Firebug 1.2 final release. As well as just supporting Firefox 3, there are some quality improvements:

The Script panel (the JavaScript debugger), the Net panel (network monitoring), and Console panel have all seen considerable updates. They're all much more performant and have a huge number of bug fixes.

Specifically the Console panel has seen a number of security improvements. We'll be discussing the specific nature of these changes once everyone has had enough time to upgrade to Firebug 1.2.

A list of all the bug fixes can be found in the full release notes.

Who enabled me?

Taking in to consideration the above performance points (namely the fact that enabling the Console, Script, or Net panels have the potential to incur a global overhead on all browser tabs) a feature was added to help you minimize your use of the panels in errant tabs.

If you position your mouse over the Firebug icon, in the Firefox tray, a tooltip will pop up telling you two things: The version of Firebug that you're using and which tabs have some Firebug panels enabled in them.

It should be noted that the Firebug will be a gray color if no tabs currently have a Firebug panel enabled at all.

Using the above tooltip you can now go in and selectively disable any panel usage that you are no longer utilizing.

Suspend/Resume Firebug.

Of course, when using the above tooltip (or seeing that the Firebug icon is lit up), you'll just want to suspend all use of Firebug panels straight out without having to poke-around each individual tab.

A new Suspend/Resume menu option has been added that will suspend/resume all active panels. This is a one-click way to keep Firebug in check.

Suspend/Resume Firebug.

by Dion Almaer at August 26, 2008 01:11 PM

Aza Raskin and the Mozilla Labs team looks like they are having a lot of fun. They have been putting up proposals for new UIs and the latest involves a smarter new tab screen.

Aza discusses how opening a blank screen doesn't really help you. Opera already allows you to have a quick dial screen show up there, but what else can be done?

Often a new tab is opened to do a search, so they can put a search bar right there, and it can be smart enough to search across your own tools and providers (e.g. delicious). I personally don't do this, as I use Apple-K to jump to the search bar in the browser and have the search results open in a new tab.

What I found even more interesting was the context specific smartness. How often do you do this:

• Find an address
• Select and copy the address
• Open a new tab
• Go to maps.google.com
• Paste in the new address

Instead, the new tab selector can be smart and automatically show you the map option. NOTE: there are of course other options such as plugins that find the addresses and give you links to the map.

by Dion Almaer at August 26, 2008 12:52 PM

In the latest issue of A List Apart, Dave Shea revisits his influential CSS Sprites technique for navigation treatment. This time around, however, the technique leans less on CSS as a sole driver and more on JavaScript, particularly the jQuery library. As evident by this very site, I’ve been delving more into jQuery, Moo, Prototype [...]

by reh3 at August 26, 2008 02:24 AM

As others have written here before, users should be in control of their information. That's at the core of privacy. Privacy has two aspects: disclosure and choice. Disclosure means informing users in plain language about the data collected about them and how it's used. Choice means putting users in control of their data and giving them tools to protect it.

Have you ever wanted to take your web browsing "off the record"�? Perhaps you're using someone else's computer and you don't want them to know which sites you visited. Maybe you need to buy a gift for a loved one without ruining the surprise. Maybe you're at an Internet kiosk and don't want the next person using it to know at which website you bank.

What if you want to delete your browsing history after the fact, but you don't want to lose your preferences at websites that you use frequently?

When we began planning IE8, we took a hard look at our customers' concerns about privacy on the web. As evidenced by some of the comments on this blog during the IE7 days, many users are concerned about so-called "over-the-shoulder privacy"�, or the ability to control what their spouses, friends, kids, and co-workers might see.

What about your privacy as you browse the web? As Dean outlined is his post earlier today, there is so-called "3^rd-party"� content on websites, some of which can gather data about how you browse the web. How do you know what that is, or how to control it?

With respect to privacy, IE8 gives users more choice about controlling what information they keep and exchange. In the first part of this post I'll describe two Internet Explorer 8 features that help you control your history, cookies, and other information that Internet Explorer stores on your behalf. In the latter part, I'll describe two more features that can help you control how your browsing history is shared by websites. By default, IE8 browses the web the same way IE7 does.

• InPrivateâ„¢ Browsing lets you control whether or not IE saves your browsing history, cookies, and other data
  
• Delete Browsing History helps you control your browsing history after you've visited websites.
  
• InPrivateâ„¢ Blocking informs you about content that is in a position to observe your browsing history, and allows you to block it

• InPrivate Subscriptions allow you to augment the capability of InPrivate Blocking by subscribing to lists of websites to block or allow.

InPrivate Browsing

If you are using a shared PC, a borrowed laptop from a friend, or a public PC, sometimes you don't want other people to know where you've been on the web. Internet Explorer 8's InPrivate Browsing makes that "over the shoulder"� privacy easy by not storing history, cookies, temporary Internet files, or other data.

Using InPrivate Browsing is as easy as launching a new InPrivate Browsing window. When you're done, just close the window and IE will take care of the rest.

While InPrivate Browsing is active, the following takes place:

• New cookies are not stored
  • All new cookies become "session"� cookies
  • Existing cookies can still be read
  • The new DOM storage feature behaves the same way
• New history entries will not be recorded
• New temporary Internet files will be deleted after the Private Browsing window is closed
• Form data is not stored
• Passwords are not stored
• Addresses typed into the address bar are not stored
• Queries entered into the search box are not stored
• Visited links will not be stored

Delete Browsing History

In Internet Explorer 7, we added a feature called Delete Browsing History that lets you delete in one click all of the information that IE saves. This is a necessary tool that is a standard feature in all modern web browsers. If there are things in your web browsing past that you want to erase, you can do that easily.

The problem is that usually you don't want to delete everything! Cookies, in particular, are really useful for storing preferences on websites that you use frequently. Many sites have a "remember me"� option, which stores a cookie on your PC and identifies your user account. Other sites, particularly financial websites, will store a cookie on each computer that you use to eliminate extra challenge questions (i.e. "What was your high school mascot?"�).

IE8 solves this problem by adding an option that lets you keep cookies and temporary Internet files from websites saved in your Favorites list:

To avoid having your favorite sites "forget you"�, simply add them to your Favorites, and make sure the "Preserve Favorites website data"� checkbox is selected. IE will preserve any cookies or cache files that were created by websites in your favorites.

Oh "“ and by the way "“ we heard your feedback about checkboxes! Now Delete Browsing History will remember your preferences. We also added a "Delete Browsing History on Exit"� feature if you really want to keep your history squeaky-clean! To do so, click Tools->Internet Options:

In his post earlier today, Dean outlined some of the privacy issues surrounding third-party content, which powers some of the rich experiences you get on the web today, such as interactive maps and social networking shortcuts ("add to Digg"�).

Some third-party content is shared by multiple websites. If you happen to browse to sites that refer to the same third-party resource, i.e. a script, image, stylesheet, information is sent to that third-party. Over time, the third-party can create a profile of which websites you go to, what links you click on, etc. It's hard to know exactly how your data will be used and with whom it will be shared without reading and understanding the privacy policy of each third-party site providing content to the website you visit,.

Consider this hypothetical example. You walk into a shopping mall. In the middle of the shopping mall, there is someone in front of a kiosk who asks you if he can record what stores you visit while you're there as part of a survey. In order to do so, he writes down a description of what you look like "“ not your name "“ but what you're wearing, your height, etc. In several of the stores throughout the mall, there are people who identify you based on this data, and record whether or not you visit a particular store. When the mall closes, the surveyors in the store report their tallies back to the kiosk. What the surveyor ends up with is a list of some of the stores you visit while you're at the mall.

This is analogous to how some third-party content works on the web today. Again, without reading specific privacy policies, it's hard to say in general what third-parties do with the data (or whether or not they record it at all).

The first difference between this mall example and the real world is that the mall survey is hypothetical. Again, different third-party sites do different things with the data they can collect, and the best way to understand what they actually do is reading their privacy policy. The other major difference between this example and the web is how explicitly users are presented with a choice about sharing their information. Clearly there are benefits to sharing your information, starting with richer experiences. Many web sites rely on third-parties to provide content and services like interactive maps and financial data, or analytics and advertising in order to operate effectively. These third-party services often collect information in order to do their jobs. There are also potential drawbacks, such as privacy risks (who has what information?) and increased exposure to malicious content. Put simply, the web relies on a trade, or value exchange, between users and sites. Information goes back and forth: in exchange for "free"� services and content, users "pay"� with information, not money. There is nothing wrong with such a trade, as long as users are informed and are in control of the choice.

InPrivate Blocking

InPrivate Blocking is a feature designed to help give you information about third-party content that has a line of sight into your web browsing, and gives you a choice about what information you share with these sites. As Dean mentioned in his post, it's possible for sites to track users without cookies. The only way to ensure that your data is not disclosed is to block content and prevent communication to sites.

While you browse the web, your IE keeps a local record of which third-party items your browser accesses, and where they were accessed from. For example, if you visit http://www.contoso.com/index.html, which contains the following snippet:

<html>
<head> <title> Contoso.com Homepage </head>
"¦
<script src=http://www.woodgrove-int.com/tracking.js>
"¦
</html>

and then visit http://www.wingtiptoys.com/, which contains the same snippet:

<html>
<head> <title> Great deals at Wingtiptoys.com </head>
"¦
<script src=http://www.woodgrove-int.com/tracking.js>
"¦
</html>

Woodgrove-int.com is now in a position to know that you've been to both contoso.com and wingtiptoys.com.

InPrivate Blocking keeps a record of third-party items like the one above as you browse. When you choose to browse with InPrivate, IE automatically blocks sites that have "seen"� you across more than ten sites.

You can also manually choose items to block or allow, or obtain information about the third-party content directly from the site by clicking the "More information from this website"� link. Note that Internet Explorer will only record data for InPrivate Blocking when you are in "regular"� browsing mode, as no browsing history is retained while browsing InPrivate. An easy way to think of it is that your normal browsing determines which items to block when you browse InPrivate.

InPrivate Subscriptions

Users can augment the capability of InPrivate Blocking with InPrivate Subscriptions. Some users want to protect their privacy, but don't want to make granular decisions about content to block or allow. Users can delegate these decisions to publishers of InPrivate Subscriptions. Users can subscribe to a list the same way they add an Accelerator, Web Slice, or search provider to IE: by clicking a link on a web page and confirming that they want this functionality:

Under the covers, InPrivate Subscriptions are simply RSS feeds of Regular Expressions that specify sub-downloads to block or allow. Anyone can publish an InPrivate Subscription on their website, just as they can offer an Accelerator or Web Slice on their website. We'll post details about the file format as part of the updated IE8 Developer's Guide with Beta 2.

Conclusion

IE8 helps put you in control of your data, both on your PC and on the Web. IE8 Beta 2 is coming soon, and I encourage you to download it and give us feedback.

Andy Zeigler
Program Manager

P.S. Check out Dean and Andy talking about IE8 and Privacy on Channel 9.

Edit: Added a P.S.

by ieblog at August 25, 2008 07:02 PM

Previous posts have covered trustworthy principles in general and some product specifics as well. Privacy is an important part of trustworthy computing. This post discusses one aspect of privacy on the web: third-party content.

When most people browse the web, they think what they see in the address bar and the site they are visiting are the same thing. However, web sites today typically incorporate content from many different web sites. For the sake of clear terminology, the site the user browses to directly (seen in the address bar) is the first-party site; the other sites that the first-party site incorporates in its site experience (but that the user hasn't navigated to directly) are third-party