RTM Platform Changes

Hi, I’m Kris Krueger, the Test Lead for the developer platform in Internet Explorer.

When we announced the IE8 Release Candidate, the call to action for site owners, software developers, designers, and administrators was to test with the Release Candidate build and make any changes necessary to create the best possible customer experience with IE8. We stated that we would continue listening to feedback from the community, but would be very selective about the changes to the platform made from there on out. This is an important point – we wanted to be mindful of the work we’d asked you to do. We didn’t want to “pull the carpet out from under you†by changing fundamental ways the IE platform behaved. We did, though, commit to acting on the most critical issues, particularly reports concerning security, backwards compatibility, and completeness with respect to planned standards work. I’d like to communicate the critical platform changes we’ve made in these areas.

Security

For IE8 Beta-1, we closed off the information-disclosure problem whereby JavaScript can read the .value attribute of a file upload control and determine the full local pathname, which might include information like the user’s name, profile directory, etc. Specifically, we changed from ALLOW to DENY for the Internet Zone “Include local directory path when uploading files†security setting. So, rather than sending the filename “C:\users\bill\desktop\temp\upload.txtâ€, we instead send just “upload.txtâ€.

Over the last few months, we’ve run into a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers) that this security improvement breaks, because the sites use JavaScript to attempt to parse the filename (e.g. to determine its extension). In many cases, the script will attempt to get the indexOf() the last REVERSE_SOLIDUS (\) character in the string, and since we now return only the leaf filename, those scripts will fail to parse the string and complain to the user.

For instance, here’s a screenshot of the dialog you get from the router’s firmware update UI after you click the “Start to Upgrade†button:

Clearly, the user can’t easily understand what caused this problem. While we’d obviously prefer that developers fix broken scripts, in some cases this would be really tricky. In the router’s case, for instance, the user would need to update the firmware to get the fix, and it is the firmware upgrade code itself that’s broken!

In light of this, we started looking into compatibility mitigations for this problem. One proposal was that we could prepend a bogus path to the leaf filename so that such scripts will continue to work. We wanted to use a prefix which is descriptive (e.g. so it can be searched for by any confused web developers looking into problems) and which is simple (contains no special characters) because the parsing code we’re trying to help out is likely not very robust.

Upon investigation, we found that Opera 10 alpha is already doing this compatibility mitigation, although their prefix (“C:\fake_path\â€) includes an underscore that we’d like to avoid because we don’t want to use special characters and would like to ensure that file path segments are