Riding Herd : IE

IE 7 security is already making a difference

jmazner — Fri, 05 May 2006 21:38:00 GMT

I've been using various beta builds of IE 7 for several months now, and I am really impressed with the new security features and default settings. I've seen gold bar and address bar warnings that highlight real issues with real commercial sites as I've been using the web. It's really amazing to find big commerce sites that don't have their SSL certs set up correctly, for example. I've seen multiple sites running with expired certs, as well as sites that have mismatched certs (so the cert for foo.company.com is used on bar.company.com, which IE flags as a potential security issue). I even discovered a Microsoft product (in beta) that ships an unisgned ActiveX control. In each case, when I send an email to let the owners know of the problem, they fix things up, but it's really been interesting seeing how many folks just don't get this right. I think IE 7 will raise awareness of these issues, which is a good thing.

The Register gets two facts wrong about IE 7 TechBeta

jmazner — Fri, 29 Jul 2005 07:12:00 GMT

Andrew Orlowski, of The Register, recently posted a very short blurb about problems with IE 7. He makes two significant errors that I want to clear up here. It took my all of 3 minutes to refute these statements on my XP SP 2 box running IE 7 TechBeta version 7.0.5112.0. I showed my results to Scoble, but wanted to post here as well.

Orlowski writes:
"IE7 integrates search into the browser, but the only option is Microsoft's own MSN Search"

Fact: IE 7 TechBeta contains the following providers for its search box (this is a verbatim listing from looking at my machine): AOL search, Ask Jeeves, Google, MSN Search, Yahoo! Search. Installing the most recent Yahoo! toolbar build then adds another search provider labelled "Yahoo!"

Fact: IE 7 honors the user's preference for default search provider. In Corey Gouker's screenshot, you can see that Google is selected as the default provider. To choose a different provider, you just click the little magnifying glass to the left of the search box.

Orlowski writes:
"Microsoft disabling third-party toolbars" and "it does raise ominous echoes of Microsoft previous tactics of foreclosing competition by hiding the alternatives"

Fact: As Scoble notes, the general manager of IE has said that there is nothing in product that blocks Yahoo! or Google toolbars from working. Nobody is hiding any alternatives.

Fact: the following toolbars are working correctly on my machine right now

Google toolbar: version 2.0.114.9-big/en (GGLD)
Y! toolbar: version 6.1.1.0

Fact: older versions of the Y! toolbar (I believe version 5.6 and earlier) do have issues that prevent them from working in IE 7 TechBeta. These issues were fixed in Y! toolbar versions 6 and above.

Orlowski writes: "Users with search toolbars from Yahoo! and Google have discovered that these vanish"

Fact: Some users evidently have run into problems. But plenty of other users, including the IE test team, have not

If you are experience any issues with Yahoo! or Google toolbars, I repeat Scoble's plea: send us specific version information of your OS, IE 7 build, and toolbar build.

Update: check out Tony Schreiner's post from May about how he implemented tabs in IE. Note where he says:

One design decision worth calling out is that our current implementation is fully multithreaded. Each tab is on a separate thread, and the frame is also on its own thread. This has some impact on the overall footprint of IE, but we believe this will allow IE7 to feel faster and provide an overall better user experience. Internally this creates some additional complexity as we have to deal with a lot of cross-thread communication, but it also gives us a way to do things we wouldn’t otherwise be able to do with a single-threaded approach.

If you have a browser extension, like a Toolbar, that wasn't designed to be multi-thread safe, IE 7's multi-threading might cause some compatability issues. That having been said, Tony also writes "one of the deciding factors for our design was to preserve compatibility with 3rd party applications", and I know the team has been doing a lot of test work to verify that as many extensions as possible are able to work unaltered on IE 7.

Update 2: I've been told by the IE team that the code to migrate toolbar settings when upgrading from IE 6 to IE 7 was one of the later items checked in for the TechBeta. So users with older interim builds of IE 7 might have seen a problem where toolbars weren't migrated properly. But again, all evidence I have is that this is working great in the actual TechBeta release.

Update 3: If you're having toolbar problems, let us know the following (as of right now, I only see know of one person reporting an issue in Scoble's comments):

1) what version does IE 7 report? (Help->About IE)
2) go to Tools->Manage Add-ons. do you see entries for Google (of type Toolbar) and Google Toolbar Helper (of type Browser Helper Object), or Yahoo! Toolbar? If so, what status do they report? If you right click on the IE toolbar area, do you see your toolbar show up in the context menu? can you enable it that way?
3) what version of the toolbar are you running? if you managed to get the toolbar working, use it get the version number (Google: click the Google drop down, Help->About Google Toolbar, Yahoo!: click the pencil, choose About Yahoo! Toolbar). If not, the version number of the DLL would help (on my machine, Google is in program files\google\googleToolbar2.dll, Y! in program files\yahoo!\companion\installs\cpn\yt.dll)

Update 4: Orlowski has updated his post to correct the claim about only using MSN as search provider, and to agree that the latest version of Y! toolbar works fine. But he still says "The default search engine is MSN Search", which isn't what I saw on my machine (neither did Adam), and I'm still looking for anyone who has experienced a problem with the Google toolbar to let me know.

Why do we care so much about this? Because 1) if there's a problem, we want to fix it, and 2) misinformation spreads

Avoiding memory leak patterns in your IE script

jmazner — Wed, 22 Jun 2005 02:17:00 GMT

Justin Rogers, a dev on IE's object model team, posts about his recent MSDN article on leak patterns in IE.

If you're doing serious DHTML development for IE, this article is a must read. Says Justin:

let's look at the following patterns:

Circular References—When mutual references are counted between Internet Explorer's COM infrastructure and any scripting engine, objects can leak memory. This is the broadest pattern.

Closures—Closures are a specific form of circular reference that pose the largest pattern to existing Web application architectures. Closures are easy to spot because they rely on a specific language keyword and can be searched for generically.

Cross-Page Leaks—Cross-page leaks are often very small leaks of internal book-keeping objects as you move from site to site. We'll examine the DOM Insertion Order issue, along with a workaround that shows how small changes to your code can prevent the creation of these book-keeping objects.

Pseudo-Leaks—These aren't really leaks, but can be extremely annoying if you don't understand where your memory is going. We'll examine the script element rewriting and how it appears to leak quite a bit of memory, when it is really performing as required.

PDC registration now open

jmazner — Tue, 07 Jun 2005 21:14:00 GMT

I have a long list of backlogged things to post about...but for now, I just want to quickly note that registration is open! We also posted 50+ session titles -- these aren't the final titles, but they give a pretty good flavor for the kinds of things we'll be covering. You'll see some info about IE in there, and lots about Longhorn. There will be even more details coming over the next two months as we finalize the session list and speakers.

Why hire an IEvangelist

jmazner — Wed, 20 Apr 2005 10:17:00 GMT

More great comments are coming in about this position.

Why do I think we need an Evangelist? It’s because we need someone whose full time job is to focus on making sure the community understands what IE is about, what it offers, and responds to feedback. I’m not looking for someone who will don a blindfold and ear plugs and just shout “IE 7! IE 7!" all day long. I want someone who can look at everything the product team is building, figure out the value (and yes, the drawbacks where there are any) for developers, and then talk about that with the community. Call it ICommunityOutreach, or ISharerOfInformationForIEDevelopers if the word "evangelist" is what's getting you tied up here. You can put whatever you want on your business card :)

Should a great product speak for itself? Sure. But it doesn’t always work that way. XMLHTTP didn’t speak for itself in 2000 when we first invented it, but now with just a little help from Google it’s spun into this great excitement around AJAX experiences. Tivo is so stunning that it (or at least some other similar PVR) ought to be in every home in the universe by now, but I'm told their uptake rate is slow because too many still don't actually get what it is. They need an evangelist!

Sometimes it takes one person dedicated to community outreach to help the product teams keep their focus on what’s important:

Jim: The Internet Explorer team? [] It's like they are skulking at the back of the classroom because they didn't do their assignment.

To be fair, the IE team’s assignment is to build a great product that has the right mix of features for end-users, IT pros, web devs, and e-commerce sites, and ship it with high quality and security. The IEvangelist’s assignment, on the other hand, is all about taking it to the community. Do I hope the IE team steps up and blogs more about the topics that you all care about? Oh yes, and I sent a copy of Jim’s comments to their leadership team just now (and in fact their product unit manager already responded to me ;) But I can guarantee you that the IEvangelist on my team will be reviewed on how well he or she blogs and responds in a relevant way to community feedback.

Do I expect the IEvangelist to somehow force the IE team into implementing every idea that gets a lot of votes from the community? No. But I certainly expect this person to be able to explain, in every case, how the feedback was considered by the team and why a decision went a particular way.

Dwain totally gets what I’m thinking about for this position, and in fact he says it more articulately that I have, I think.

Let's keep the conversation going, I'm really enjoying it (although at some point, I'm going to have to get back to my other full time job, which is PDC planning, or my other full time job, which is hiring some Longhorn evangelists too)

IEvangelist's biggest challenge

jmazner — Tue, 19 Apr 2005 04:21:00 GMT

Sweet, the post about the IE job has been up for two hours, and already the blogsphere is making it clear why it will be a great challenge to tackle.

David Betz:

James Avery:

I could not think of a worse job: trying to convince developers that IE is good. The first thing I would ask this person is “How do I know that as soon as I switch back to IE you won’t cut development again?”.

Do we need a strong evangelist, or what?

We were pretty quiet about IE for a while. A long while. We're starting the process of making up for that long, dark teatime of the soul. The IE team is blogging. There's a developer center, and a community home. But still, we have a lot of work to do to win back the respect of the community. How's that for a challenging job!

I'm not on the IE team, but I spent the first 4 years of my career at Microsoft doing development work on projects that delivered their user interface via IE. Here's what I remember as the "principle" of IE, to use David's words: Empower developers, and make it possible for devs to build great user experiences.

I have no idea if that's what the marketing guys would say is the soul of IE, or even the dev team -- I'm sure there are loads of IE team members who worked on the end-user browsing features who'd say user experience is the soul of IE. But, as a dev, I loved that IE was focused on helping me. Is it too bold to assert that a significant amount of the programmability we find in web browsers today was driven from IE's soul as a developer platform? Here's what I remember fondly from the time in the late 90's when I was working with IE:

IE 3 COM/component model. Using IWebBrowser for the first time was an amazing experience -- there was an IE window, running inside my app!
DOM/DHTML -- real DHTML and a real DOM, that let me programmatically reach into the element tree and tweak it to my heart's content. Again, all easily accessible from any Windows app via lovely COM objects. My recollection is that IE 4 really pioneered this notion of a full featured programming API for the browser (I don't think Netscape's Layer + JavaScript stuff was as complete a solution? If I'm wrong, someone will correct me ;)
ActiveX -- The ability to embed a full featured Windows app in a web page via an ActiveX control was amazing. Did it have problems? Sure, and we're working even today to improve the situation, as evidenced by the features in XP SP2 and newer approaches to embedding Windows code like WinForms User Controls. But when ActiveX came on the scene, it was really an amazing tool for a developer to have at their disposal. Maybe this is a sign that in the old days, IE was too focused on enabling developers.
XMLHTTP -- It's all the rage now in the context of AJAX, but it came together 5+ years ago when teams at Microsoft focused on how to improve the developer experience for building responsive, asynchronous web apps like Outlook Web Access.

Of course this is all sort of ancient history by now. The challenge for the IEvangelist will be to reconnect with what the soul of the IE team is these days, and make that visible, accessible and understandable to the rest of the world. James asks a great question -- what promise is there that the IE team actually has a set of principles and will stick to them for years to come? If you interview for the job, I will make sure you get to talk to senior folks in IE land. You can ask them that question yourself, and decide for yourself how much credibility they have. And you can challenge them -- as evangelist, you are a voice for the community inside MS, your job is to understand what the community needs to succeed, and convincing the product team to make it happen.

If this is the kind of challenge that gets you excited, you know where to go ;)

[updated: minor edit, and added a new category tag]

Now hiring: Internet Explorer Technical Evangelist

jmazner — Tue, 19 Apr 2005 02:30:00 GMT

My team is also hiring a Technical Evangelist to focus on Internet Explorer. The goal of the IE evangelist (IEvangelist? not bad for a business card title…) is to help the web developer community take best advantage of new features and security mechanisms in IE 7. The job description has a bit more detail, but it really comes down to helping the community understand how to create the possible experience in IE. For some developers, “best possible experience” might mean “identical to the experience in every other browser.” For others, “best possible experience” might mean “I want to take full advantage of every extensibility point and programmability feature to build the possible interface for my users”. Either way, the IEvangelist will need to understand how to best support the developer.

If you’re interested, please submit a resume and get in touch with me. Send me your list of top 3 things you would do as an evangelist to help the web dev community.

I’d be happy if search engines noticed that this post is about “Microsoft evangelism jobs” ;)

[update: modified link to actually point directly to the job description, since MS.COM seems to have changed the format of their permalinks]