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.
0x00080000
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.
BINDF2_DISABLEAUTOCOOKIEHANDLING
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
Anonymous
May 26, 2010
For security, you should DISABLE COM in standard mode, only manually enabled in compacity view! That's all.Anonymous
May 26, 2010
Hey IE team, please take a look at this Firefox addon called BarTab: addons.mozilla.org/.../67651 This is how tabbed session restore should be done. Hope something as revolutionary can be added to IE9.Anonymous
May 26, 2010
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.Anonymous
May 26, 2010
The comment has been removedAnonymous
May 26, 2010
@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.Anonymous
May 27, 2010
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)...Anonymous
May 27, 2010
The comment has been removedAnonymous
May 27, 2010
@FremyCompany: I'm not sure how passing one additional flag qualifies as "complex"?Anonymous
May 27, 2010
The comment has been removedAnonymous
May 28, 2010
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.Anonymous
May 28, 2010
The comment has been removedAnonymous
May 28, 2010
The comment has been removedAnonymous
May 28, 2010
@Eric, that's a fair distinction and a valid point. Thanks for the clarification!Anonymous
May 28, 2010
The comment has been removedAnonymous
May 28, 2010
@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... :)Anonymous
May 29, 2010
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 :DAnonymous
May 29, 2010
@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.Anonymous
May 29, 2010
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... blog.mozilla.com/.../hardware-accelerating-firefox blog.chromium.org/.../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.Anonymous
May 29, 2010
@John 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.Anonymous
May 29, 2010
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.Anonymous
May 29, 2010
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.Anonymous
May 30, 2010
Viktor: It was announced at MIX that IE9 will require Windows Vista. news.cnet.com/8301-13860_3-20000561-56.html John: Windows XP is now in "Extended Support" mode, which means that ONLY security updates are made available.Anonymous
May 30, 2010
The comment has been removedAnonymous
May 30, 2010
@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.Anonymous
May 30, 2010
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.Anonymous
May 31, 2010
What Internet Explorer has always been >> img689.imageshack.us/.../1275360189032.png <<Anonymous
June 01, 2010
what will happen to silverlight? will it be disbanded? there are any other feature in silverlight that there aren´t in ie9?Anonymous
June 01, 2010
it´s true that microsoft has made a download manager? if so, will microsoft improve it and attach it to IE9?Anonymous
June 02, 2010
Might you know what rendering engine that Expression Web uses for rendering its WYSIWYG pages, Eric? It would be nice to know.Anonymous
June 04, 2010
The comment has been removedAnonymous
June 04, 2010
The comment has been removed
