Update to Internet Explorer's Cookie Jar
As a part of the August Cumulative Update for Internet Explorer, a small enhancement was made to Internet Explorer’s HTTP Cookie handling. This post describes that enhancement, and presents some other considerations for using cookies on your site. A knowledge base article referencing this change can be found here.
Background
In the past, IE’s cookie jar stored a maximum of 20 cookies per domain. If more than 20 cookies were sent by the server, older cookies were automatically dropped by the browser. The dropped cookies could lead to lost website settings, an empty web shopping basket, or similar problems. In order to store more than 20 name-value pairs per domain, web developers were forced to create a “dictionary cookie”, a single cookie that contains multiple name-value pairs. Creation of dictionary cookies is described in this Knowledge Base article.
Note that IE’s cookie limit is applied on per-domain basis. If https://example.com sets 20 cookies, each with Domain=example.com, and https://subdomain.example.com also sets 20 cookies, each with Domain=subdomain.example.com, then 40 cookies will be sent on subsequent requests to subdomain.example.com.
New Cookie Limit
As a part of the Internet Explorer update announced yesterday, the cookies per domain limit has been increased from 20 to 50. This change was made to simplify the development and hosting of web applications on domains that use a large number of cookies.
Please note that even after installing this update, two other cookie limits remain unchanged:
- The DOM's document.cookie property will return an empty string if the current cookie string is longer than 4096 bytes
- Internet Explorer (and the WinINET HTTP stack) will ignore any Set-Cookie header if the header value's length exceeds 5118 bytes
For functionality and performance reasons (discussed next), it’s recommended that you continue to use the smallest cookies possible.
Watch Your Weight
You might be tempted to take advantage of the new higher cookie limit and add more cookies to your site. Unfortunately, cookies can dramatically impact the size of HTTP requests, slowing down the user’s browsing experience significantly. Many of today’s web users have connections with asymmetrical bandwidth, having download speeds 2 to 5 times faster than their upload speeds. This means that in some cases, HTTP request size is a more important factor than the size of the server’s response in determining overall transfer time.
There are three strategies you can use to minimize the impact of cookies on your site’s site performance:
- Minimize the size of your cookies
- Deliver static content from a different domain
- Use the Path attribute to send cookies only when necessary
The first strategy is simple: use the shortest cookie names and values possible. For instance, rather than naming a cookie USERNAME, name it U.The seven bytes saved might not sound like much, but multiplied over dozens or hundreds of requests, these savings can add up.
The second strategy can yield even better results, particularly if your pages use many static resources (images, CSS, JS, etc) that do not change based on the value of the visitor’s cookie. For instance, if you use the Fiddler Web Debugger to look at the Office Online clipart site, you’ll see that the static clipart images are delivered from https://officeimages.microsoft.com rather than https://office.microsoft.com. This means that the relatively large cookie set on office.microsoft.com isn’t sent when requesting each clipart thumbnail, saving more than 2K of request bytes per page of search results.
The last strategy is similar to the second, except that you can undertake it with just one domain. If you can keep all of your pages that need access to cookies within a single path (e.g. https://example.com/webapp/) you can use the Path attribute on the cookie to specify that the cookie should only be sent for requests within that path. This will ensure that requests sent outside of that path (e.g. https://example.com/images/) are not forced to carry unneeded cookies.
You can easily use Fiddler to monitor your uploaded cookie sizes. Inside Fiddler, click Rules > Customize Rules. Scroll down to OnBeforeResponse, and add the following line:
oSession["ui-customcolumn"] = oSession.oRequest["Cookie"].Length.ToString();
After you save the script, the size of the uploaded cookie (if any) for each request will be shown in the User-defined column at the far right side of the Web Sessions list.
Protecting Your Cookies
While you’re looking at your cookie code, you should determine if you need to expose your cookies to scripts running on your site. If your cookies are only used by your server, and your scripts don’t require access to your cookies, use the HttpOnly attribute to help protect your site against cookie theft via cross-site scripting attacks. Simply add the HttpOnly attribute to your Set-Cookie headers, and Internet Explorer will ensure that your cookie is not available to any script running in your pages. Cookies with the HttpOnly attribute are still sent in each HTTP request, but will not appear in the script-accessible document.cookies property. This means that if a hacker finds a cross-site scripting hole in your site, he cannot easily use the hole to steal logged-on visitors’ cookies.
Over the coming months, I’ll be posting more tips for developers. If you have any suggested topics, please leave me a comment below. Thanks!
EricLaw
Program Manager
Comments
Anonymous
August 29, 2007
PingBack from http://www.ie7security.net/2007/08/29/update-to-internet-explorers-cookie-jar/Anonymous
August 29, 2007
The 4096 byte limit on cookies from a single domain was acknowledged as a problem by Microsoft four years ago. Isn't that enough time to have corrected it? Because of this limit in Explorer and Explorer only, I am having to redesign my entire approach to cookies. And now you're upping the allowed number of cookies without upping the byte limit along with it? Does this make sense? Personally, I think the whole thing is disgraceful. AaronAnonymous
August 29, 2007
I keep adding preferences that visitors can set (cookies expire after 30 days) at my latest test case (17 total options with 44 total choices to choose from) and only had a vague idea that there was a ceiling though I usually stick to using integers for the value...exactly what kind of sites use 5KB+ sized cookies? Well this is a welcomed change I suppose. Now if the Webkit team would be so kind as to "allow" JavaScript to create cookies and understand how to handle multiple HTTP queries in a single request work (to any extent) Safari (gah, the latest version that is) wouldn't be such a pain to work with. Thanks for the post!Anonymous
August 29, 2007
"Disgraceful"? Someone's got a bit of a flair for the dramatic. :-) I don't think anyone ever acknowledged it as a "problem" but rather an intentional limitation. And since such a limit has been there for four years, it makes one wonder why you're having to "redesign" anything. The post mentions that there are perf problems caused by uploading huge cookies, so maybe they're really doing you a favor?? Since you've got the data on the client anyway, why not use IE's userdata feature to avoid wasteful roundtrips?Anonymous
August 29, 2007
Excuse me, may I ahve a question? Once I write a cookie with domain like http:\a.net, it's failed in IE and successful in firefox. Does this domain to short? How can I solve this problem? Thanks a lot!Anonymous
August 29, 2007
@PIC: How exactly are you attempting to set the cookie? What page is attempting to set the cookie? Is the cookie used in a "third-party" context? (http://msdn2.microsoft.com/en-us/library/ms537343.aspx#first_and_third_party_context)Anonymous
August 29, 2007
PIC, I am under the understanding that domain names need to have at least two characters so "a.net" is (if I'm correct) technically not a domain name.Anonymous
August 29, 2007
"This means that in some cases, HTTP request size is a more important factor than the size of the server’s response in determining overall transfer time." I'm happy to see that the official stance is to reduce the size of requests, and look forward to __VIEWSTATE's being removed from the next version of ASP.Anonymous
August 29, 2007
domain names do not have to be at least 2 characters. x.org for example.Anonymous
August 29, 2007
IE does not set cookies for 1 or 2-letter domains: http://therealcrisp.xs4all.nl/blog/2007/02/12/ie-and-2-letter-domain-names/ Furthermore it is good to see that MS is finally paying some attention to the problems with state-management although I think the total number of cookies allowed per domain was the least of the problems. I agree though that it does not make much sense to increase this limit but do nothing about the size limit (which is still a leftover of the /minimum/ requirements mentioned in the Netscape cookie draft and RFC2109). What is really needed is an overhaul of RFC2109/RFC2965 since there are numerous problems with these standards and state-management in general resulting in many differences in implementations between UA's...Anonymous
August 30, 2007
The comment has been removedAnonymous
August 30, 2007
Marty: well, the problem with 1 and 2-letter domains is mostly in combination with a 2-letter TLD (and without www subdomain), but there is more: y.com works y.org does not work y.net does not work on the other hand, Firefox behaves the same in a.m. situations. I'm not sure what the actual rule used here is, it isn't even what the Netscape cookie draft describes because there .com, .org en .net are all 'special toplevel domains'. Like I said before: we definitely need a new specification for this because at the moment state management is a complete and utter non-interoperable mess.Anonymous
August 30, 2007
Correction, my testcase was flawed: all of the abovementioned examples (y.com, y.org, y.net) actually do work in IE7 and other browsers as well, so the problem is mainly with 1 and 2-letter domains with a 2-letter TLD.Anonymous
August 30, 2007
@Tino As far as the Netscape Docs I have got, these are the specs:
- Up to 20 cookies for each server or domain, and up to 300 cookies for all URLs.
- Max length of a cookie is 4000 bytes
- "If a script or server attempts to create a cookie longer that that, it will be truncated, but the name will remain intact if it is less than 4000 bytes long." Netscape Press, 1997
-
- Definately says nothing about returning an empty string. Probably because that would be completely useless. Oh, by the way, we were not able to store all your data, so we erased it all. * *
Anonymous
August 30, 2007
Hi. I hate to post support questions on the blog, but maybe you guys can point me in the right direction. I run Windows Server 2003 x64 edition, which supplies both a 32- and 64-bit edition of Internet Explorer. Recently (in the last month or so, after the last batch of security updates) my 32-bit edition of IE stopped working altogether (it just exits immediately without presenting any UI at all). I often need to run the 32-bit IE because it seems the Office 2007 integration with SharePoint 2007 does not work with the 64-bit IE. Now I am really stuck. I tried downloading and running the 32-bit version of IE from Microsoft, but the installer complains "This installation does not support your system architecture (32/64bits)". Given that my 32-bit installation is completely hosed, is there any way (short of reinstalling the OS) to restore it? Thanks!Anonymous
August 30, 2007
@Chad: Try running IE without addons iexplore.exe -extoff You also might try resetting IE to defaults by running the Internet Control Panel (from the system control panel) and choosing "Reset IE to defaults".Anonymous
August 30, 2007
steve: here's the link to the Netscape draft: http://wp.netscape.com/newsref/std/cookie_spec.html - it was drafted in 1994 note that it says that those are /minimum/ requirements, as does RFC2109 ( http://www.ietf.org/rfc/rfc2109.txt - Feb 1997) which can be seen as the standard that followed up on the Netscape draft (although IE's implementation is still mainly based on the Netscape draft wereas other browser vendors' implementations are more based on RFC2109). It is however true that the Netscape draft also says that servers should not expect clients to be able to handle larger limits, wereas RFC2109 is more clear on the fact that the requirements are a bare minimum (using the words "at least"). RFC2109 does not document behaviour when the implemented limits are exceeded, the Netscape draft does define that behaviour including the behaviour for cookies larger than 4KB (trim to fit but leave the name intact when the name itself is less than 4KB).Anonymous
August 30, 2007
@EricLaw: Thank you! The -extoff trick works. IE 7 32-bit is now loaded and seems to be working. However, the Tools|Manage Add-Ons menu is grayed out and cannot be used. How can I find out which add-on is causing the problem and then disable it?Anonymous
August 30, 2007
@EricLaw I figured it out. I had to go to Tools | Internet Options and then access the add-ons page. Guess what the problem was. Sun's Java 6 browser plugin. This is apparently a known problem (and has been fixed by Sun), see: http://blog.saddey.net/2007/07/10/java-6-update-2-may-stop-internet-explorer-from-starting/ Thanks so much for your help.Anonymous
August 30, 2007
@Chad: Thanks for the followup. Glad you're running again. :-)Anonymous
September 01, 2007
The comment has been removedAnonymous
September 01, 2007
I need to report something to someone at Microsoft that is MS related though not IE related. I do not believe the correct place to report the topic is viable at this time (will clarify in email). Please contact me and I'll get back to you with all the info I can, thanks! PS: Name is direct contact link and feel free to remove this OT post once you get this, if you're not with MS please don't contact about this post.Anonymous
September 03, 2007
IEでは、同一ドメインのクッキー値は20までしか保存されない制限があったのが、5...Anonymous
September 03, 2007
Blog post comments not working?Anonymous
September 03, 2007
@garth "Blog post comments not working?" They work, but they don't make any sense.Anonymous
September 05, 2007
Is this update applicable to IE 6 SP2 for XP?Anonymous
September 05, 2007
"IE does not set cookies for 1 or 2-letter domains" Wow, that is totally bizarre. I was wondering why it was impossible to log into my blog at http://mg.to/ using IE when Firefox works fine. Now I know. "Domain too short? No cookies for you!"Anonymous
September 05, 2007
If I open a new tab it keeps the cookies from the other tab, this behavior is by design?Anonymous
September 05, 2007
@Ernest: Yes, cookies (or rather sessions) are shared across Tabs, by design. (same as other browsers) If you truly want 2 different sessions, start another IE process (however you normally launch IE) and that will enable multiple sessions.Anonymous
September 05, 2007
@Patrick Whittingham: Yes, this update applies to IE6 SP2 for XP.Anonymous
September 05, 2007
When could I have a clean vista free of Internet Explorer?Anonymous
September 06, 2007
>When could I have a clean vista free of Internet Explorer? When you learn English. And when Firefox is finally dead.Anonymous
September 06, 2007
The comment has been removedAnonymous
September 06, 2007
What do you mean by cookies when you are talking about the Internet?Anonymous
September 06, 2007
@Chela: Web browser use small data files called "cookies" to help websites store your preferences. See http://en.wikipedia.org/wiki/HTTP_cookie for a more detailed explanation.Anonymous
September 07, 2007
Oyun, feel free to send me a note. My email address is ericlaw@microsft.comAnonymous
September 07, 2007
The comment has been removedAnonymous
September 08, 2007
ii think the reason they updated the cookie jar is because Firefox has 50 cookies limitAnonymous
September 09, 2007
50 cookies limit? LOL... max. 15-20 cookies, shure not more...Anonymous
September 09, 2007
What version of Javascript will IE8 support? I'm developing new applications and want to know if I should put in checks for the native versions of foreach() etc. or just skip the query because they won't be there. (yes, I am serving up different Javascript for IE vs. all the other browsers since I have to work around so many bugs.) Thanks in advance for the info. JamesAnonymous
September 09, 2007
Is this update applicable to IE 6 SP2 for XP?Anonymous
September 09, 2007
The comment has been removedAnonymous
September 10, 2007
IE Team is afraid of complying of W3c standard, since following the standard would discourage people from downloading IE.Anonymous
September 10, 2007
The comment has been removedAnonymous
September 10, 2007
The comment has been removedAnonymous
September 10, 2007
@DMassy "If you don't believe them then that is your right but don't make statements that have no foundation." My statements are founded on e-mail correspondence with several Microsoft's employees. At present, IE team is in the doldrums, and MS doesn't care twopence about IE. It doesn't matter to me if someone doesn't believe my words.Anonymous
September 10, 2007
@DMassy I don't understand. Is it really that difficult to comply with W3C standard? Convince me, please.Anonymous
September 11, 2007
@DMassy "I'd certainly expect to hear something in the next year or so." - WHAT?! A YEAR! Are you serious!?!? So, this is the new status quo?! 2 years of silence and no public bug tracking between releases?! Wow, that sounds like a super-duper plan! Who dreamed up this public relations nightmare? Seriously, if IE intends to be a big player in the online/web browser/development platform game, they need to get their act together. In a world of open standards, with technology changing by leaps and bounds every quarter, WAITING TWO WHOLE YEARS to talk about the next version of "your version of the web platform" is mind-boggling! Are you telling us then, that not only has the last 3,4,5 years of griping about NO DECENT 2 way communication and NO BUG TRACKING gone completely unheard? Those of us that STILL^H^H^H^H^H believe in the IE team are really loosing any faith we had left! I was under the impression that the IE team was hard at work making a public bug tracking system, but hadn't announced it, since is wasn't quite ready yet.... and now you tell us (effectively), that we can kiss that idea goodbye (cause we need it now, not after IE8 is built) and that we won't hear any details about IE8, until 4TH QUARTER, 2008 or even later.... if we're lucky! OMG - I'm absolutely speachless! Unless DMassy does not speak on behalf of MS, and there is comm tools on the way asap, you've officially just lost massive support from the development community. Why are you leaving us out here in the cold? What happened to "we care, and we're listening"? What happened to "Developers, developers, developers"? Signed, Royally P-O'dAnonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
Every time I read the sign on the websites that claimed to be compatible with IE, I wish I could legislate a law coercing MS to comply with the standard. The reality? IE is bundled with MS Vista. Worse, the IE team never made IE confirm to W3C standard.Anonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
@paul "ARE YOU SERIOUSLY BUILDING A WALL OF SILENCE ON IE8 UNTIL 2009" As far as I know, until 2010. However, there's no certainty. Maybe the next version of IE will be released in five or ten years, or will be no released at all.Anonymous
September 11, 2007
Did you know? http://www.webdevout.net/ie-is-dangerous Dear IE developers, I have a suggestion for you: switch from Trident to Gecko. Yes, complying with the W3C standard recommendations is no easy task. So replace the very bad-written and poor Trident to Gecko. By the way: http://www.spreadfirefox.com/node/28337 400 000 000 FF downloads. People start to recognize how dangerous IE is. Get Firefox.Anonymous
September 11, 2007
@Firefox "...switch from Trident to Gecko" Gecko engine has VERY POOR support for Unicode standard, although Unicode is the underlying technology for HTML, SSS and many other standards. Without reasonable Unicode support there is no point in supporting other Unicode-based standards.Anonymous
September 11, 2007
@henry "Unless DMassy does not speak on behalf of MS, and there is comm tools on the way asap, you've officially just lost massive support from the development community." DMassy does NOT speak on behalf of MS. I have not worked for Microsoft or been part of the IE team since February of 2007. My comments here are based on my experience and having been on the receiving end of ill informed, arrogant and silly comments on this blog :) Thanks -DaveAnonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
Silly comments are not pleasing, because they point out underlying issues behind IE. If you needs someone to woo you, please rename this blog "Praise to IE"Anonymous
September 11, 2007
@challenge Clearly not all the comments are silly. But here are three examples from comments on this particular post. There are much sillier ones on other posts here :)
- "Dear IE developers, I have a suggestion for you: switch from Trident to Gecko." If you don't know why this suggestion is silly then it shows a lack of understanding of the market. Compatibility is one reason. The other being that I wouldn never expect Microsoft to abandon such a key platform technology to someone else.
- "Every time I read the sign on the websites that claimed to be compatible with IE, I wish I could legislate a law coercing MS to comply with the standard. The reality? IE is bundled with MS Vista. Worse, the IE team never made IE confirm to W3C standard." There is no single W3C standard. If you want to have a conversation and show yourself to have some understanding of the issues at all then be specific about which recommendations and why they are needed. That's pretty easy considering that IE is lacking in a few key areas. Do you really think that legislation is the answer? Please!
- "When could I have a clean vista free of Internet Explorer?" It should be pretty clear that as 3rd party software and parts of Windows rely on IE being present as part of the OS that this really isn't going to happen. What is the point anyway. If you don't want to use IE then use a different browser as the OS default. Oh and please don't start on about bundling or are you against Apple shipping Safari with the Mac? These are just a few examples from a quick glance at the comments here. I can only assume that the reason for the recent increase in these types of comments is the fact that school is back in. Certainly there is a lack of maturity in many of them. I totally agree that the IE team are doing themselves no favors by their silence and lack of explanation of even simple issues. The team clearly has big challenges ahead of them and need to engage with the developer community in a way that they currently aren't. paul's list above starts to get specific but then loses focus. E.g. "Is the QuickTabs going to be fixed?" "Is the toolbars going to be fixed?" I can only guess at what he is referring to here. I'd love to see a full dialog around issues like this with repro steps etc. Unfortunately a blog like this is not really a good place and the IE team continues to fail to present a public bugtracking system with links to appropriate KB articles that would help people with workarounds. It's all a little sad and I can understand why people here are venting their frustration. If the IE team does care about developers then they have to do better and show the developer community that they understand the issues and plan to address them. @rc Don't trust your sources. The only source I'd trust about what is happening with IE8 is from the team itself. -Dave
Anonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
The comment has been removedAnonymous
September 11, 2007
"Microsoft continues to invest in IE." no wayAnonymous
September 12, 2007
IE team should be pleased to have people venting their frustration on IE, since we mind IE as much as you [IE team]. I was too an former follower of IE and had automatically filtered out any mentioning of keyword "firefox" and "mozilla" in the past 3 years. But IE development was simply too close-minded and lagged behind W3C standard by a large margin. I truly believed funding is not a major holdback to IE team; it's the volition (or motivation) that impaired IE development. You could choose to live in your dreamland or return to reality and catch on to the trend. We can't wait until the IE 8 came out. Action, action!Anonymous
September 12, 2007
Quote from Chris Wilson, "Packing up office for move."
- http://twitter.com/cwilso Quote from Cyra Richardson, "Packing, but fightened that movers will break my delicates! One meeting then off to 50."
- http://twitter.com/MsCyra They're obviously not leaving MS, so what's going on with the IE team?
Anonymous
September 12, 2007
@EricLaw: "but we are hard at work on the next release and feedback from the community on IE7 is helping to guide our work" Thats funny? because I've been trying to submit bugs, test cases, and feature requests but MS shut the IE Feedback site down. So either there is some magical site that you are pulling this data from.. or you are pulling stale data from the old feedback site.. or you are just making this up. WE HAVE TONS OF FEEDBACK to provide on IE7, but ALL VIABLE AVENUES to present it to you have been closed. Posting bugs to this blog is not the answer, nor does it even scratch the surface about the issues with IE7. Please advise where bug reports can be sent, and where features can be requested, and obviously most importantly so that we are not overwhelming MS with duplicates a location where we can search for previously submitted issues. For example, where is the list of "known to MS" issues with "CSS conflicting with inline form element style declarations"? I came across another nice one today I would love to post. Finally, your quote: "I'm sorry we don't have anything to announce yet" That's fine. But please do tell us when you think you might have some news to tell. Seriously, is it days away? weeks away? months away? or years away?Anonymous
September 12, 2007
@Move Office moves are not uncommon at Microsoft. Their frequency is often the subject of many jokes. Not an issue.Anonymous
September 12, 2007
The comment has been removedAnonymous
September 12, 2007
The comment has been removedAnonymous
September 12, 2007
Proof that IE is the worst browser in existance: http://www.w3.org/People/mimasa/test/xhtml/media-types/resultsAnonymous
September 13, 2007
Did you bother to look at the table or not? The W3C's own Amaya browser intended for editing crashed regardless of the media type. If you can't even get your own color coded messages right don't even bother posting here.Anonymous
September 13, 2007
@EricLaw: Re: "The about;blank issue you mention is almost certainly caused by registry corruption or a buggy extension; I've never seen that issue elsewhere." Are you serious? you don't know about this? this affects EVERY install of IE7 on WinXP that I have ever installed or used. EVERY Go into: ALT > Menu > Tools > Internet Options: General Tab > Home Page Groupset > Click the Use Blank button. "about:blank" is placed in the textarea above the button. Now, open a new window, new tab, or any links that open a new window. Notice that string of text in the address bar, "about:blank". right-click on the page, click properties... "about:blank" appears there too. We understand that is the system url to go to a blank page, but it shouldn't need to be rendered in the address bar. If there is a special registry entry to get rid of this, please advise because it looks horrible.Anonymous
September 13, 2007
@dave "Are you serious? you don't know about this? this affects EVERY install of IE7 on WinXP that I have ever installed or used. EVERY" Are you serious? I've never had that problem on any IE7 on WinXPSP2 I've ever had. EVER.Anonymous
September 13, 2007
@Dave: Ah, you mean you're seeing about:blank, not about;blank as was noted above. Thanks for the clarification. I'm not sure I understand why showing you the URL of the about:blank page is horrible or unexpected; after all, that's why the Address bar is there. :-) Among many other things, showing the URL clearly indicates that the page you're on is ~supposed~ to be blank, rather than leaving you to wonder if there's just a lag or rendering glitch, etc. Make sense?Anonymous
September 13, 2007
The comment has been removedAnonymous
September 13, 2007
There is only one email program http://web.enjoychn.com/blog/510-there-is-only-one-email-programAnonymous
September 14, 2007
Chris Wilson on IE, past, present, and future: http://sessions.visitmix.com/default.asp?event=1011&session=2010&pid=XBD04&disc=&id=1562&year=2007&search=XBD04Anonymous
September 14, 2007
i bet 5 bucks that they will say somthing on October 18thAnonymous
September 14, 2007
please goto see my blog http://www.cqspeed.com it's a good blog youcan know more about china and web designAnonymous
September 14, 2007
@gabe "i bet 5 bucks that they will say somthing on October 18th" ..., 2009 or 2010.Anonymous
September 14, 2007
2007 most likely also im so fed up with ppl giving disrescpt to ie team they should send a build to me so i can confirm its exsentance (i wont share it with anyone) thats probly the only way short of public build that can change ppls minds that ie is still being devlopedAnonymous
September 14, 2007
The comment has been removedAnonymous
September 15, 2007
Ive been reading all the comments with much interest recently about the IE development and tracking issues. I took a look to see if there were any other sites that offered a public database of issues that was very complete but there simply isn't one. I did however find a site that tracks vulnerabilities (in all kinds of software by many manufacturers) This link (minimized using tinyurl) will take you to a list of the "Verified, Microsoft Internet Explorer" vulnerability issues. It won't show CSS and DOM bugs that render badly, but it will at least explain some of the memory and crashing issues. OSVDB: Open Source Vulnerability DataBase. http://tinyurl.com/2rw3cz or you can run your own search at: http://osvdb.org/search.php If anyone knows where a good public database of IE rendering and behavior bugs is, please post a link, i'm sure there are literally thousands of people interested in finding out the issues, and workarounds for them. tx, gordonAnonymous
September 16, 2007
@gordon There is Gerard Talbot's page of IE bugs at http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/ that includes links to other such pages. It's a page though and still not the same a database which is what is really needed. I'm sure someone could establish a wiki for the collection of issues and links to workarounds. However everyone just complains and fails to do anything about it. People are looking to Microsoft to supply such a databse, which they probably should. I'm not sure we'll see anything before IE8 enters beta though. We'll see.... Thanks -DaveAnonymous
September 16, 2007
"I'm sure someone could establish a wiki for the collection of issues and links to workarounds. However everyone just complains and fails to do anything about it. People are looking to Microsoft to supply such a databse, which they probably should." I'd start my own bug tracking site if I knew MS weren't going to release their own, but they refuse to comment.Anonymous
September 16, 2007
They haven't "refused to comment". Tony Chor the Group Program Manager of the IE team responded to an earlier post at http://blogs.msdn.com/ie/archive/2007/06/22/from-microsoft-teched-2007-web-development-tools-for-internet-explorer.aspx#3621151 Clearly there is a challenge to having a public bug database that is truly useful rather than just full of noise and poor bug reports with lack of reproducible steps. However other teams manage to do this so the challenge can clearly be met if there is the commitment to do it. There is little point though if the team is not willing to put the necessary resources into making it work. The bug reporting mechanisms in place while IE7 was under development were clearly not working well enough to continue with for a fully released product. When we will see anything from the IE team on this is unclear. I suspect they will not establish anything until IE8 enters beta when they will actually be really interested in bug reports. Who knows when IE 8 will enter beta though! The real shame is that there is a use to a bug database to all developers using currently released and supported versions of IE in pointing people to recommended workarounds to issues. Without such support web developers end up frustrated and feel the IE team does not care about them at all. Thanks -DaveAnonymous
September 17, 2007
The comment has been removedAnonymous
September 17, 2007
The reality? IE is bundled with MS Vista. Worse, the IE team never made IE confirm to W3C standard.Anonymous
September 17, 2007
The comment has been removedAnonymous
September 18, 2007
@rc Why do you persist in making these statements which members of the IE team deny. They have no basis beyond your assertion that people at Microsoft outside of the IE team make these statements. Anyone familiar with the culture at Microsoft will tell you that teams routinely trash talk each other and usually have little or no clue what other teams are actually doing. The only source you can trust is the team concerned themselves. Work on IE8 continues as they have repeatedly said, but they are not going to discuss it before they are ready. It's fine to disagree with the team for their silence which I believe is a huge mistake on their part. Their silence certainly doeasn't help. However please don't make these statements as though they are fact when they are only rumour that you alone persist in pursuing. -DaveAnonymous
September 18, 2007
PLease we need a new version,for better support in standards,why MS hasn't releases an updates version of the Browser,u promised that to us!Anonymous
June 16, 2008
一、浏览器允许每个域名所包含的cookie数： Microsoft指出InternetExplorer8增加cookie限制为每个域名50个，但IE7似乎也允许...Anonymous
July 02, 2008
Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote aboutAnonymous
March 16, 2009
    안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저 에 대한 저희의 생각을