Privacy, Add-ons, and Cookie-less HTTP Requests

A recent article incorrectly suggested that Internet Explorer add-ons must send and store cookies when making HTTP requests. That’s simply not true-- Internet Explorer APIs enable add-ons to respect the user’s privacy and not leak information. Existing APIs are available to add-ons running in any version of IE to accomplish the task described in the article.

An add-on using WinINET to issue HTTP requests can suppress default cookie behavior by passing the flag INTERNET_FLAG_NO_COOKIES, which will suppress automatic sending and storage of cookies.



Does not automatically add cookie headers to requests, and does not automatically add returned cookies to the cookie database.

If the add-on is making HTTP requests using URLMon, it can pass BINDF2_DISABLEAUTOCOOKIEHANDLING in the bind flags.


Do not automatically add cookie headers to requests, and do not automatically add returned cookies to the cookie database. Setting this flag adds the Microsoft Win32 Internet (WinInet) flag INTERNET_FLAG_NO_COOKIES on the current moniker binding. You can still set cookies manually on the request, and read them from the response.

If the add-on wants to use a higher-level construct and the server supports Access-Control, IE8 offers the XDomainRequest object which suppresses cookies and authentication automatically.

If the add-on is hosting a Web Browser Control, it can implement an IInternetSecurityManager and/or the WinINET Privacy functions for fine-grained control over cookie behavior. Alternatively, the add-on could choose to make its HTTP requests using WinHTTP (which doesn’t support automatic handling of cookies at all).

Beyond the existing APIs to control whether or not cookies are sent along with HTTP requests, Internet Explorer 8 exposes new Privacy APIs to allow add-ons to support Delete Browsing History and become InPrivate Browsing-aware.

Thanks for your help in respecting users’ privacy!

Eric Lawrence
Program Manager

Comments (31)

  1. Infinte says:

    For security, you should DISABLE COM in standard mode, only manually enabled in compacity view!

    That's all.

  2. Anonymuos says:

    Hey IE team, please take a look at this Firefox addon called BarTab:…/67651 This is how tabbed session restore should be done. Hope something as revolutionary can be added to IE9.

  3. Cool post, Eric!

    I like the new PrivacyAPI and would like to suggest also making an InPrivate Blocking API in order to make it easier to implement an ad blocker for IE.

    For the InPrivate Blocking API, I envision a mechanism to turn it programmatically on or off, query the current state, and most importantly a callback when new resources are loaded into the page including the requested URL and also a reference to the DOM element which caused the request in order to make informed decisions on whether to block that request or not.

    Additionally, the API could give access to the current blocking settings, the collected data and the collection of XML files and their contents.

  4. Mario Cossi says:

    @Viktor Krammer: an API to turn off InPrivate Mode would be open to abuse. If users choose to start their browser with InPrivate on, it isn't the business of any add-on to turn it off. Ever. IMHO this is one of those areas that are best left to user choice, without a way for any software component to double guess it.

  5. @Mario

    I disagree. You are assuming that every add-on, every piece of software, has bad intentions. If an add-on is abusing its possibilites, users will eventually uninstall, or not install it in the first place, because of bad reputation, anit-malware protection, IE guidelines etc.

    If you entirely forbid meaningful interactions of add-ons with the browser, you are severly limiting the space add-ons can explore. As a consequence you will only see dumb "toolbars" in IE, whereas other browsers are offering a rich set of interesting add-ons worth installing.

  6. FremyCompany says:

    It's great it's possible. As usual, it's complex. Why is making add-ons for IE so complex (at least for people not used to C++ and COM API)…

  7. alvatrus says:

    @ Victor

    That is just the most naive approach to security that I've witnessed in a long time.

    People *won't* notice they're under malware attack. These programs are designed to be as unobtrusive as possible.

    Basically, you say that the browser must rather listen to a random piece of software and elevate its privileges, than to *explicit* settings made by the user.

    That's not an just attack vector, it's opening the floodgates.

  8. EricLaw [MSFT] says:

    @FremyCompany: I'm not sure how passing *one* additional flag qualifies as "complex"?

  9. @alvatrus

    I am aware of the security impact and agree that software vendors have to draw a line somewhere.

    But following your argument, you can almost forbid every API, because every API has the potential to get misused.

    Example 1: IHTMLDocument2::createElement can be misused by an add-on to inject malicious code into the current page, i.e. to alter the content or steal information

    Example 2: ITHMLWindow2::navigate can be misused by an add-on to navigate the browser to a malicous page

    Example 3: BeforeNavigate2 event can be misused in order to redirect the browser to a malicous page, etc.

    The question what should be allowed and what should be forbidden is certainly not an easy one.

    What if the "privileged" action the add-on wants to perform was initiated by a user request (i.e. pressing a button, altering a settings in the add-on itself etc.)? Example: Resize Window Add-on (provides a button, or option, to maximize the IE window). Would you like to forbid this add-on? (resizing the windows is a privileged operation in IE8)

  10. Phil (an other one) says:

    Alright!  New style of blog, and 2 pieces of spam on it already!!!

    @Viktor – the point is if I have InPrivate turned on, NO OTHER PLUGIN should be able to turn it off EVER without me specifically allowing it.  Your proposal would let plugins switch other plugins on and off at will, totally defeating the point of something like InPrivate.

  11. Neil Dunensach says:

    @Viktor –

    "For the InPrivate Blocking API, I envision a mechanism to turn it programmatically on or off"

    This is a Really Bad Idea ™.  I surf porn InPrivate, my wife installs a plugin which can turn InPrivate off and record everything I look at?  No thanks.

  12. EricLaw [MSFT] says:

    @Neil: A general principle of computer security is that once an adversary installs code on your box, it's not your box anymore. In this case, your "wife" could simply install a keylogger (either software or hardware) to defeat the protections.

    However, it's important to understand that InPrivate Filtering has no relationship to InPrivate Browsing. In InPrivate Browsing, no browser extensions run by default, so a browser extension couldn't "turn it off." In contrast, InPrivate Filtering independently of InPrivate Browsing, and Filtering does not disable extensions.

  13. Neil Dunensach says:

    @Eric, that's a fair distinction and a valid point.  Thanks for the clarification!

  14. Thanks Eric for the clarification, I just wanted to post the same.

    I think if you install an add-on or software in general you are actually establishing a trust relationsship between you and the software. A use case for turning InPrivate Blocking on and off could be the implementation of a user-controlled whitelist in a third-party add-on for example or implementing a keyboard shortcut for that feature, or an additional more accessible button etc.

    It is also important to distinguish between the capabilites Web sites can perform through script and the capabilities intentionally installed software can perform.

  15. RobertWrayUK says:

    @Viktor… How many times have you provided "tech support" for a relative? I suspect probably more than once… We've all been there! 😉

    On that basis "you are actually establishing a trust relationsship between you and the software" is largely irrelevant, simply because most people who install an "addon" don't actually know what they're letting themselves in for. Nor do they care. They just see "SuperInstaMaxiToolbar lets you find things quicker" and click "OK"… That's why, to me anyway, IE not surfacing API access to everything is a good thing… 🙂

  16. FremyCompany says:

    Hum, additionnaly, it would be great to be able to recover what we typed in a <TEXTAREA> textbox even when the page isn't loaded anymore. Sometimes, during a crash or a bad manipulation, we may loose a whole text. It's never fine 😀

  17. @RobertWrayUK

    This is a valid point. THAT should be part of the add-on guidelines: add-ons have to clearly state their puropose and privacy implications in an understandable (maybe standardized) way.

    Add-ons, which are misleading the user, could be blocked by the new IE add-on guidelines enforcement mechanism.

    But I still think that a richer set of APIs is important to stay competitive with other browsers.

  18. John says:

    Hello guys, sorry to be off topic, but with regards to Microsoft ignoring XP because it doesn't support Direct2D or something for GPU acceleration……/hardware-accelerating-firefox…/introducing-angle-project.html

    It looks like Mozilla and Google are doing good work to ensure that as much computers as possible will have the best performance as possible and hopefully you guys do the same.

  19. alvatrus says:


    Currently, Microsoft is ending support for XP, meaning that any remaining security holes will not be fixed.

    If people want to stay with XP, then that is fine. But they must be aware they're running a system that's become obsolete.

    Encouraging and even facilitating people to stay with an unsupported system is irresponsible at best.

  20. John says:

    Microsoft will support XP SP3 through April 2014. Office 2010, Silverlight 3, Visual Studio 2010, all work on XP. So you are simply incorrect that "any remaining security holes will not be fixed" or that it is "an unsupported system". XP was the latest and greatest until about 3 years ago anyhow, and of course, enterprise systems keep PCs for even longer than that. My place is still on XP. We will be deploying Office 2007 this fall, would you believe that.

    I have asked before and I think an actual Microsoft employee responded that because IE9 will leverage Direct2D that XP doesn't have, that is the actual reason they won't support XP, which actually makes sense, as opposed to just not allowing XP to have the fastest browser. My GMA 3100 ran Quake Live like a beast, so the underlying capabilities are there. It's up to vendors to decide if they want to leverage the huge market share of XP (60% overall, 80% in US enterprises). We all know what happened the last they let IE6 stagnate.

  21. As far as I know, the IE team has neither confirmed nor denied Windows XP support of IE9.

    IE9 Platform Preview builds (we are talking here of a pre beta release) require Windows Vista/7, because there purpose is to test and demonstrate the new GPU-powered Web rendering engine, which is not available on XP.

    I think Microsoft could release a version of IE9 for Windows XP without GPU acceleration and will probably do so.

  22. EricLaw [MSFT] says:

    Viktor: It was announced at MIX that IE9 will require Windows Vista.

    John: Windows XP is now in "Extended Support" mode, which means that ONLY security updates are made available.

  23. wechrome says:


    an API to override InPrivate settings is definitely one of the worst ideas ever. Privacy and security related settings should have the highest priority. Yes when one installs some add-on, one should have established some trust relationship with the software, BUT when one enables the InPrivate settings, it means one wants to limit the level of trust due to privacy and security concerns, and THAT should have the highest priority, that can never be override without explicit consent from the user.

    If some add-on wants to unblock itself from InPrivate settings, it should just pop-up a prompt, explain the reason and ask the user to white-list it manually, and whether it will be white-listed must rely on the user's explicit action. InPrivate settings must not be bypassed automatically, if InPrivate settings needs to be changed, it must require explicit actions from the user to configure the settings manually oneself.

    Say, if you specifically set the browser to accept no cookies, do you want some API for third-party software to automatically bypass that setting and accept certain cookies without your explicit action?

  24. EricLaw [MSFT] says:

    @wechrome: I think you misunderstand what Viktor is proposing. Viktor is proposing a mechanism whereby an add-on could be created to block MORE content with InPrivate Filtering, not less. InPrivate Filtering is not related to InPrivate Browsing, and it is disabled by default.

    Browser add-ons are based on a "Full-Trust" model; you should only install add-ons that you fully trust. As this blog post discusses, it's the responsibility of the add-on to ensure that they make API calls in such a way so as to respect the user's security and privacy.

  25. InPrivate Browsing != InPrivate Filtering

    InPrivate Browsing: disables all add-ons by default, does not save browsing history, does not store permanent cookies, deletes cache etc.

    InPrivate Filtering: content filter for tracking and advertisment scripts, "Web bugs" (invisble images) etc.

    I am talking of an API for "InPrivate Filtering" in order to implement better ad blockers and content filters as IE add-ons.

  26. The Truth says:

    What Internet Explorer has always been >>…/1275360189032.png <<

  27. DavidPaulo says:

    what will happen to silverlight? will it be disbanded? there are any other feature in silverlight that there aren´t in ie9?

  28. DavidPaulo says:

    it´s true that microsoft has made a download manager? if so, will microsoft improve it and attach it to IE9?

  29. Johnnyq3 says:

    Might you know what rendering engine that Expression Web uses for rendering its WYSIWYG pages, Eric?

    It would be nice to know.

  30. Dock says:

    InPrivate browsing is a fraud: first you can get the same results in IE8 by setting up IE manually; I am not even sure that InPrivate browsing disables DOM storage which is enabled by default in IE8… Second If the IE team was so interested in users' privacy, IE8 would manage flash cookies or at leat develop an add-on to manage them. This is not the case despite some wrong articles published even on this blog.

  31. @Dock: No, you cannot really get the same results with a manual configuration, although you can get close. Had you tested, you would find that InPrivate Browsing properly restricts DOM Storage.

    Current versions of Flash are InPrivate Browsing aware.

    @Johnnyq3: I believe that Expression uses their own engines for rendering their WYSIWYG views. IIRC, the "SuperPreview" tool uses forked copies of the IE rendering engines for its IE-views.

Skip to main content