Standards?

[fleetfootmike]

We're Microsoft. We don't have to obey fucking STANDARDS.

In which Microsoft unilaterally remove support for

<protocol>://<user>:<password>@<site>/

URLs from IE with the latest security patch. See http://support.microsoft.com/default.aspx?scid=kb;en-us;Q834489 and weep.

(Yes, there's a registry hack to get round it. And yes, I know *why* they're doing it. )

Comments

[redaxe.livejournal.com]

Hrm.

Looks like they're only removing support for http: and https:, not, for example, ftp:. (Then again, when was the last time you used M$IE for ftp: access?)

Nonetheless, if they had created a product that had more security than cheesecloth to begin with, this would probably not be necessary.

Pfui.

[pbristow.livejournal.com]

Has the relevent standards body been looking at this issue at all? Are they anywhere close to making a recommendation?

If MS just want a butt-covering measure pending and official standard solution, I think a smarter approach would have been for IE to *by default* disallow the format, but with an option to turn it back on for users who require it, and with a decent associated Help item that actually explains what it's for and what the issue is... Oh, but that would be breaking the MS standard for Help items, wouldn't it? =:o\

Or then again, they could just fix the way the URLs are displayed so that the *real* domain name is highlighted in bold red, or something.

Has this come to light due to a real-world support issue, then, or was it just spotted in passing?

Re:

[fleetfootmike.livejournal.com]

From a heads up in my ISP's very clued up support newsgroup.

Otherwise I'd have missed it totally.

Re:

[keristor.livejournal.com]

I saw in The Register several days ago that they were planning to do that. My view is that if they want to cripple their own product that's their lookout, people will use alternatives which work (Opera, Mozilla, etc.)...

Re:

[hrrunka]

At least part of the problem is that there were already bugs in the way M$IE handled and displayed URLs, and they've chosen to resolve the difficulty not by fixing their code so it does the right thing, but by taking something standard out. Then again, M$ have never been particularly good at following standards...

[hrrunka]

The comments in this handler's report on ISC gave me cause to smile wryly, as did The Register's treatment of the story...

[antonia-tiger.livejournal.com]

The version of the story I heard was that the URL format was specified in one RFC, with all the options, and further RFCs specified the different valid options for ftp, http, news, etc.

And this particular User-ID/password format was not one of the options in the actual http section of the tree.

I think the argument could run and run.

I ought to check Demon's instructions for using their homepages system: the basic web server for customers. I'm pretty sure it used the ftp version of this in the instructions.

[rickbooth.livejournal.com]

Much as I hate to intervene in any MS-bashing, it is important to note that, unlike everyone else, they are now obeying the fucking standards. In fact, the relevant RFCs recommend against [Unknown site tag]@ being used in any URI-scheme and specifically forbid it in http URIs.

Reference: http://2lmc.org/spool/id/3971 and the links from there.