But what do you do with a non-ASCII character that's within the part you've visited before?
These can probably be displayed the same as ascii characters in the already-visited url.
You are right about the hash tables. Best solution I can think of is to also hash each of the different lengths of prefix at the same time you hash the full URL.
The signing could be done right as the data comes out of the CCD, and not accessible anywhere else. Anybody trying to make legally-provable pictures had better know they cannot edit or color correct the pictures after they are taken, even in the camera.
It does not have to be impossible to get the private key. It just has to be impossible to get it and still have a working camera. To prove the picture is authentic you must produce the non-broken camera. It will also be necessary for manufactures to put different keys in each camera (so cracking one does not get the other) and to insure that the manufacturing process completely forgets about the keys immediately after they are burned into the chips, so there is no other leak of the private key.
Your scheme assummes nobody can get the image back onto the memory card, which is quite unlikely if the memory cards are any kind of standard.
Instead the camera could have a private key and a public RSA-like key. These are generated as the camera is manufactured, hopefully different for every camera. The private key is locked inside the chip in a way that hopefully cannot be retrieved without destroying the camera.
The camera makes an MD5 sum of the image, and then encrypts it with the private key, and then writes the result of this encryption and it's public key in the file.
Anybody wanting to check the image would also make the MD5 sum, and then use the public key to decrypt the encrypted data and see if they match.
Because they don't know the private key, they cannot encrypt a different MD5 sum correctly.
You will also have to prove that a given public key belongs to a given camera. This can be proven by taking a picture with the camera and checking the public key it produces. If you don't have the camera, you can check in a database of public keys that the manufacturers maintain to see if that one was ever manufactured. Nobody making up their own key pair has any chance of getting an existing public key.
As several people here have said, if you just slow it down the wget will just take all week, and perhaps use more resources (you will have to keep track of it to slow it down).
Instead, when they pass the bandwidth limit (or more likely a number-of-requests limit) you should deliver a dead-end page from which there are no links to go anywhere else. Then when they wget it you will get a lot of these dead-end pages instead of the data they want. If a normal user hits it, it can tell them to wait a few minutes and then reload the page.
If the owner of the material does not mind, it does sound like a bittorrent download would help a lot too. Have the dead-end page give instructions on how to retrieve the bittorrent.
Anyway these are just my ideas, I really have zero experience in web sites so feel free to dismiss them as stupid.
In fact you could make an installer that contains the entire operating system! Why doesn't Microsoft allow that? Or why don't Linux apps come that way? Just imagine how convienent it would be if every program came with it's own copy of the operating system, modified to work perfectly with that program!
I agree with most of the posters here, this Joel guy does not know what he is talking about, or he thought he could get site hits by making up a silly complaint about Microsoft.
Researched this a bit more, having now been able to see the article.
The "errno.h" file here is a different one than the Linux one. You must compile with this errno.h if you want to use the SCO-style ABI, since the error numbers are different. If you want to use the Linux ABI (which all Linux programs you have probably seen do) you use the one in/usr/src/linux, which Linus wrote.
There is also an errno.h distributed with Microsoft Windows, and Microsoft can rightly claim copyright on this, and it does not have anything to do with Linus's file or with the one SCO is claiming.
It does seem likely that SCO was talking about these files when they listed the "infringing header files" so it was rather stupid of everybody to fall into their trap and waste time discussing the history of the Linux header files.
Obviously the same problem applies to putting code in the public domain, or the BSD license, or even giving closed source under NDA to another party, and every other method of releasing copyrighted information. You can always claim it was inadvertent and try to retrieve the rights you gave away.
Trying to say this is a "problem with the GPL" is pure FUD. It is like saying auto accidents are proof that there is a problem with the Lincoln Continental.
The ABI files being discussed here are some files that it was considered quite likely SCO owns, and were never included in Linux although they were added by some third parties to installations to port their software from SCO to Linux. They duplicate the SCO ABI which is different than the Linux ABI. It is a lot like Wine being used to run Windows programs, though a lot easier.
In fact these files probably contain code to patch over the differences between the Linux errno.h and the Unix one, so it certainly is not the Linus header files.
The header file stuff is a joke anyways, as Daryl clearly said many times that only Linux after 2.4 is infringing. The header files did not change between 2.2 and 2.4.
It would mean SCO is stupid enough to launch the virus from their machines and in such a clear way that the FBI could find it in a few days. I doubt it. Some joker typed up something that sounded official enough that this site (which looks legit) posted the article without checking anything.
There are also rumors that the virus "doesn't work" in that it never calls the DDOS code. This sounds like it is trivial to confirm or disprove, so does anybody know what's up with that?
Actually deleting everything before the '@' in the preview may still be a good idea. Certainly there are users who would be confused by a "www.microsoft.com" prefix even if there was an '@' later in the string. You can also make the excuse that you are hiding the name & password from casual copying.
They definately should fix the %00, because there may be another exploit of that bug by putting it after the '@' or into a URL without an '@' at all.
The only plausable damage to an end-user is if they wanted to modify XFree86 and distribute the result to other users, and their modification was to add a large chunk of code that was GPL and not theirs and they could not find a way to achieve their results without using that code. This is an extremely unlikely scenario, almost any useful algorithims that could be added to the X server are already public domain or BSD or LGPL.
Programs that use X are unaffected. This includes GTK and Qt. Just from a practical point, there is no way XFree86 could change their license so these are not allowed, they would make their product instantly useless.
I cannot think of any other problem. I thought this might prevent freedesktop.org from adding some GNU library to their standard, but that was not allowed under the previous XFree license, so this isn't any worse, and in fact disallowing the addition of GPL to their standard has always been their intention.
You have NO problem if you only intend to use the software.
Only if you want to actually rewrite the code (and in most cases only if you want to rewrite and distribute it) is there any problem.
You also run into trouble with lots of commercial closed-source libraries if you want to use more than one in a program, so this is in no way a unique problem with open source.
Maybe you should try reading the other posts here before blindly jumping to a conclusion as to what the most popular opinion is on Slashdot. It would appear that the majority agree with you.
The only counter argument I can think of for hiding the user/pass syntax before the @ in the first place...
Actually that is not the bug they have. The bug they have is that it does not display a "%00" and anything after it in the URL. This is combined with the fact that the part before the '@' is not used to figure out what site to go to. Therefore putting a "%00" before an '@' will allow you to display arbitrary text in the preview bar and still go to any site (assumming the site ignores or accepts the text before the '@').
I actually suggested truncating before the '@' as a fix, before somebody explained the actual bug to me.
1. Display something for EVERY byte in the URL! (this is Microsoft's main problem). The only character that could plausably display as a blank area is the byte with the value 32, and even that could show an underscore or something. If "%0102" is in the url, show the characters '%', "0', etc. And obviously the text "%00" in the url should not cause the rest to disappear. In case you think only Microsoft is stupid, Unix software often displays '\n' characters as breaks making multiple lines, in Mac's Safari this makes those spoof URL's display almost as badly as IE.
2. Display all non-ascii characters in a different color. Please ignore the probably loud Politically Correct crowd that will say you are demonstrating anglo-centric bias, those same people kept UTF-8 from being adopted for over 12 years (since it is obviously a bias to have westerners have the shorter characters) and actually hurt i18n far more than the most ignorant midwestern Cobol programmer did.
3. Display as much of the URL that corresponds to a site you have visited before in a different color. Ie similar to showing a visited link a different color in the page, show the preview of the URL with the hostname and leading directory levels colored that match some URL you visited before. Then, assumming you visited your bank once, the fake bank address will be noticable by not being colored.
Even principle animation is going overseas now. A girlfriend of mine worked at Warners on shows like Tazmania and started out animating scenes (she is an excellent character animator) but they changed during that time (1994) to just drawing storyboards.
Even from the quick description you gave, it sounds pretty safe to me. Not modifying the underlying file system is IMHO a good idea and mitigates all the paranoia you are having.
Windows already has the file associations like knowing that clicking a.jpg should run a certain image viewer. This is not done in the file system it is instead done by another program that reads normal files and determines this information from the normal files. Now we all know that those file associations can be mucked with (ie hijacked to run another program) but in fact any such messing with it can be determined by a program reading the setup files, and easily avoided by a program using *less* code to run a program.
Compare with a worst-case scenario where the system only had a "run this file" command and you could not determine what it did because it was encrypted into the file system (sort of what you really fear WinFS would do). Then somebody hijacking the.jpg extension would be a real and unfixable disaster. But in fact they are avoiding this if your description is at all accurate. This is a *good* thing.
I do worry about some peoples intentions for meta data. In my opinion meta data should be used *only* as a "cache" of data that could be determined from the file itself. An obvious example is an image preview. But the file type and program should also be figured out using a program like the Unix "file" command and the result cached in the metadata. You could even make schemes by which the author, owner, permissions, date and time, and even filename are considered cached metadata and determined from the file contents. We should not have to rely on the correct transmission of anything other than the "data" bytes and the file length in order for a program using a file to do the correct and predictable thing.
I am worried that in fact most recent ideas in filesystems are going exactly the wrong way, and in fact Microsoft may be doing this right for a change.
Just wanted to say that in my opinion this is a PITA. Can somebody explain why apparently equal kernel version numbers have different header files? Did Mandrake do this?
Also here is the URL for getting the correct Kernel source:
ftp://mirror.sit.wisc.edu/mirrors/linux/distribu ti ons/mandrake/9.2/i586/Mandrake/RPMS/kernel-source- 2.4.22-10mdk.i586.rpm
First: to fix it you have to download the correct kernel source *from Mandrake*. I will have to locate the URL for this, I found it in a web search looking for help in getting the driver to work. Try googling for "Nvidea mandrake 9.2 kernel source"
The message is not from Mandrake, but from the kernel. And I think it is misleading.
I have Mandrake 9.2 and I ran into the same problem. The 9.2 install did not come with the source or header files for the Kernel.
If you download the Nvidea compile & install shell script, it complains about the missing ones. I then downloaded what appeared to be the correct version from kernel.org and put the header files in. The Nvidea driver then compiled but the installer complained that it failed. It said to look in some log file, that file contained module load complaining about a lot of missing symbols, and then adding the misleading (and IMHO somewhat nasty) message about this not being a GPL component. I think it always adds this when there are missing symbols.
I wasted a good deal of time actually compiling the kernel source I downloaded. I discovered the the Nvidea driver works perfectly with that, but I lost a lot of Mandrake stuff, in particular Superdrive, and my network interface refused to work.
Then further searches on the web revealed lots of people who figured this out and said where to download the correct kernel source. I got that, and simply stuck the header files in the correct/usr/src/linux location (did not compile the kernel at all) and this time the nvidea driver compiled and installed flawlessly.
We would pay good money for a 5% improvement! (this is the promised, but so far undelivered, advantage of using Intel's CC over GCC on Linux. We already use it on Windows, but there it is 40% better than VC6).
That's a little bogus. If all I wanted to do was change the set of C files to compile and change the libraries to link with and did not worry about cross platform, I could do that easily by editing a Makefile. In fact it is far easier to add/remove a C file from a Makefile than from VC++.
Now admittedly creating the Makefile to get to the point where you can match VC++ is really a pain in the ass and the result is incredibly ugly. But that is like saying VC++ is a pain because you have to write it from scratch, ignoring the fact that Microsoft convienently sells you one they already wrote for you.
You really can't say anything positive about Microsoft here. I go and say that C# may be "better written" and people jump like crazy to call me an idiot. Hey: there are real intelligent people working at Microsoft! I don't like what they do all the time, but they are not stupid.
Face it, Java does not do primitives in the containiers. It does not do them "slower", it just DOES NOT DO THEM!!!
Therefore C# is not "faster". It is instead, better designed.
And I would like it if somebody came up with a language that did not have these artificial restrictions in it. C# is closer but it still treats primitives different all over the place.
C# generics can be faster for primitives because the JITter compiles a separate native image when the type parameter is a primitive.
Of course. That's why I said that it does not have to be slower. But that has nothing to do with whether C# handles non-primitives in a container faster. It may make them slower, or if correctly written it makes them the same speed. But it does not make them faster!!!
The only (good) reason Java doesn't support this in their impl of generics is for backward compatibility with older JVM's.
Good point, though I thought they also introduced syntax problems so that this could not be fixed even if they were willing to break the JVMs.
That fix is for a different bug ("%00" in a URL causes the status an location bar to only show the text before the %00. This can be combined with the fact that the text before an '@' in the URL does not determine what the site you visit is. So putting "%00@" in an URL will hide the real location. Their "fix" is to completely disable the ability of '@' to work at all). So one wrong for you.
Slashdot posted an article about this fix: "Microsoft To Remove Support For http(s) auth URLs". Look down a few articles in the main page. So two wrong for you.
Microsoft has not announced a fix for this bug (which involves some things called CLSID's from the registry). So three wrong for you.
Slashdot Mirror
But what do you do with a non-ASCII character that's within the part you've visited before?
These can probably be displayed the same as ascii characters in the already-visited url.
You are right about the hash tables. Best solution I can think of is to also hash each of the different lengths of prefix at the same time you hash the full URL.
The signing could be done right as the data comes out of the CCD, and not accessible anywhere else. Anybody trying to make legally-provable pictures had better know they cannot edit or color correct the pictures after they are taken, even in the camera.
It does not have to be impossible to get the private key. It just has to be impossible to get it and still have a working camera. To prove the picture is authentic you must produce the non-broken camera. It will also be necessary for manufactures to put different keys in each camera (so cracking one does not get the other) and to insure that the manufacturing process completely forgets about the keys immediately after they are burned into the chips, so there is no other leak of the private key.
Your scheme assummes nobody can get the image back onto the memory card, which is quite unlikely if the memory cards are any kind of standard.
Instead the camera could have a private key and a public RSA-like key. These are generated as the camera is manufactured, hopefully different for every camera. The private key is locked inside the chip in a way that hopefully cannot be retrieved without destroying the camera.
The camera makes an MD5 sum of the image, and then encrypts it with the private key, and then writes the result of this encryption and it's public key in the file.
Anybody wanting to check the image would also make the MD5 sum, and then use the public key to decrypt the encrypted data and see if they match.
Because they don't know the private key, they cannot encrypt a different MD5 sum correctly.
You will also have to prove that a given public key belongs to a given camera. This can be proven by taking a picture with the camera and checking the public key it produces. If you don't have the camera, you can check in a database of public keys that the manufacturers maintain to see if that one was ever manufactured. Nobody making up their own key pair has any chance of getting an existing public key.
As several people here have said, if you just slow it down the wget will just take all week, and perhaps use more resources (you will have to keep track of it to slow it down).
Instead, when they pass the bandwidth limit (or more likely a number-of-requests limit) you should deliver a dead-end page from which there are no links to go anywhere else. Then when they wget it you will get a lot of these dead-end pages instead of the data they want. If a normal user hits it, it can tell them to wait a few minutes and then reload the page.
If the owner of the material does not mind, it does sound like a bittorrent download would help a lot too. Have the dead-end page give instructions on how to retrieve the bittorrent.
Anyway these are just my ideas, I really have zero experience in web sites so feel free to dismiss them as stupid.
In fact you could make an installer that contains the entire operating system! Why doesn't Microsoft allow that? Or why don't Linux apps come that way? Just imagine how convienent it would be if every program came with it's own copy of the operating system, modified to work perfectly with that program!
I agree with most of the posters here, this Joel guy does not know what he is talking about, or he thought he could get site hits by making up a silly complaint about Microsoft.
Researched this a bit more, having now been able to see the article.
/usr/src/linux, which Linus wrote.
The "errno.h" file here is a different one than the Linux one. You must compile with this errno.h if you want to use the SCO-style ABI, since the error numbers are different. If you want to use the Linux ABI (which all Linux programs you have probably seen do) you use the one in
There is also an errno.h distributed with Microsoft Windows, and Microsoft can rightly claim copyright on this, and it does not have anything to do with Linus's file or with the one SCO is claiming.
It does seem likely that SCO was talking about these files when they listed the "infringing header files" so it was rather stupid of everybody to fall into their trap and waste time discussing the history of the Linux header files.
You might want to look up the word "inadvertantly" in a dictionary.
Obviously the same problem applies to putting code in the public domain, or the BSD license, or even giving closed source under NDA to another party, and every other method of releasing copyrighted information. You can always claim it was inadvertent and try to retrieve the rights you gave away.
Trying to say this is a "problem with the GPL" is pure FUD. It is like saying auto accidents are proof that there is a problem with the Lincoln Continental.
No this is not errno.h and so on.
The ABI files being discussed here are some files that it was considered quite likely SCO owns, and were never included in Linux although they were added by some third parties to installations to port their software from SCO to Linux. They duplicate the SCO ABI which is different than the Linux ABI. It is a lot like Wine being used to run Windows programs, though a lot easier.
In fact these files probably contain code to patch over the differences between the Linux errno.h and the Unix one, so it certainly is not the Linus header files.
The header file stuff is a joke anyways, as Daryl clearly said many times that only Linux after 2.4 is infringing. The header files did not change between 2.2 and 2.4.
It would mean SCO is stupid enough to launch the virus from their machines and in such a clear way that the FBI could find it in a few days. I doubt it. Some joker typed up something that sounded official enough that this site (which looks legit) posted the article without checking anything.
There are also rumors that the virus "doesn't work" in that it never calls the DDOS code. This sounds like it is trivial to confirm or disprove, so does anybody know what's up with that?
Actually deleting everything before the '@' in the preview may still be a good idea. Certainly there are users who would be confused by a "www.microsoft.com" prefix even if there was an '@' later in the string. You can also make the excuse that you are hiding the name & password from casual copying.
They definately should fix the %00, because there may be another exploit of that bug by putting it after the '@' or into a URL without an '@' at all.
In reality the discussion is purely academic.
The only plausable damage to an end-user is if they wanted to modify XFree86 and distribute the result to other users, and their modification was to add a large chunk of code that was GPL and not theirs and they could not find a way to achieve their results without using that code. This is an extremely unlikely scenario, almost any useful algorithims that could be added to the X server are already public domain or BSD or LGPL.
Programs that use X are unaffected. This includes GTK and Qt. Just from a practical point, there is no way XFree86 could change their license so these are not allowed, they would make their product instantly useless.
I cannot think of any other problem. I thought this might prevent freedesktop.org from adding some GNU library to their standard, but that was not allowed under the previous XFree license, so this isn't any worse, and in fact disallowing the addition of GPL to their standard has always been their intention.
You have NO problem if you only intend to use the software.
Only if you want to actually rewrite the code (and in most cases only if you want to rewrite and distribute it) is there any problem.
You also run into trouble with lots of commercial closed-source libraries if you want to use more than one in a program, so this is in no way a unique problem with open source.
Maybe you should try reading the other posts here before blindly jumping to a conclusion as to what the most popular opinion is on Slashdot. It would appear that the majority agree with you.
The only counter argument I can think of for hiding the user/pass syntax before the @ in the first place...
Actually that is not the bug they have. The bug they have is that it does not display a "%00" and anything after it in the URL. This is combined with the fact that the part before the '@' is not used to figure out what site to go to. Therefore putting a "%00" before an '@' will allow you to display arbitrary text in the preview bar and still go to any site (assumming the site ignores or accepts the text before the '@').
I actually suggested truncating before the '@' as a fix, before somebody explained the actual bug to me.
Possible fixes:
1. Display something for EVERY byte in the URL! (this is Microsoft's main problem). The only character that could plausably display as a blank area is the byte with the value 32, and even that could show an underscore or something. If "%0102" is in the url, show the characters '%', "0', etc. And obviously the text "%00" in the url should not cause the rest to disappear. In case you think only Microsoft is stupid, Unix software often displays '\n' characters as breaks making multiple lines, in Mac's Safari this makes those spoof URL's display almost as badly as IE.
2. Display all non-ascii characters in a different color. Please ignore the probably loud Politically Correct crowd that will say you are demonstrating anglo-centric bias, those same people kept UTF-8 from being adopted for over 12 years (since it is obviously a bias to have westerners have the shorter characters) and actually hurt i18n far more than the most ignorant midwestern Cobol programmer did.
3. Display as much of the URL that corresponds to a site you have visited before in a different color. Ie similar to showing a visited link a different color in the page, show the preview of the URL with the hostname and leading directory levels colored that match some URL you visited before. Then, assumming you visited your bank once, the fake bank address will be noticable by not being colored.
Even principle animation is going overseas now. A girlfriend of mine worked at Warners on shows like Tazmania and started out animating scenes (she is an excellent character animator) but they changed during that time (1994) to just drawing storyboards.
Even from the quick description you gave, it sounds pretty safe to me. Not modifying the underlying file system is IMHO a good idea and mitigates all the paranoia you are having.
.jpg should run a certain image viewer. This is not done in the file system it is instead done by another program that reads normal files and determines this information from the normal files. Now we all know that those file associations can be mucked with (ie hijacked to run another program) but in fact any such messing with it can be determined by a program reading the setup files, and easily avoided by a program using *less* code to run a program.
.jpg extension would be a real and unfixable disaster. But in fact they are avoiding this if your description is at all accurate. This is a *good* thing.
Windows already has the file associations like knowing that clicking a
Compare with a worst-case scenario where the system only had a "run this file" command and you could not determine what it did because it was encrypted into the file system (sort of what you really fear WinFS would do). Then somebody hijacking the
I do worry about some peoples intentions for meta data. In my opinion meta data should be used *only* as a "cache" of data that could be determined from the file itself. An obvious example is an image preview. But the file type and program should also be figured out using a program like the Unix "file" command and the result cached in the metadata. You could even make schemes by which the author, owner, permissions, date and time, and even filename are considered cached metadata and determined from the file contents. We should not have to rely on the correct transmission of anything other than the "data" bytes and the file length in order for a program using a file to do the correct and predictable thing.
I am worried that in fact most recent ideas in filesystems are going exactly the wrong way, and in fact Microsoft may be doing this right for a change.
Just wanted to say that in my opinion this is a PITA. Can somebody explain why apparently equal kernel version numbers have different header files? Did Mandrake do this?
u ti ons/mandrake/9.2/i586/Mandrake/RPMS/kernel-source- 2.4.22-10mdk.i586.rpm
Also here is the URL for getting the correct Kernel source:
ftp://mirror.sit.wisc.edu/mirrors/linux/distrib
First: to fix it you have to download the correct kernel source *from Mandrake*. I will have to locate the URL for this, I found it in a web search looking for help in getting the driver to work. Try googling for "Nvidea mandrake 9.2 kernel source"
/usr/src/linux location (did not compile the kernel at all) and this time the nvidea driver compiled and installed flawlessly.
The message is not from Mandrake, but from the kernel. And I think it is misleading.
I have Mandrake 9.2 and I ran into the same problem. The 9.2 install did not come with the source or header files for the Kernel.
If you download the Nvidea compile & install shell script, it complains about the missing ones. I then downloaded what appeared to be the correct version from kernel.org and put the header files in. The Nvidea driver then compiled but the installer complained that it failed. It said to look in some log file, that file contained module load complaining about a lot of missing symbols, and then adding the misleading (and IMHO somewhat nasty) message about this not being a GPL component. I think it always adds this when there are missing symbols.
I wasted a good deal of time actually compiling the kernel source I downloaded. I discovered the the Nvidea driver works perfectly with that, but I lost a lot of Mandrake stuff, in particular Superdrive, and my network interface refused to work.
Then further searches on the web revealed lots of people who figured this out and said where to download the correct kernel source. I got that, and simply stuck the header files in the correct
We would pay good money for a 5% improvement! (this is the promised, but so far undelivered, advantage of using Intel's CC over GCC on Linux. We already use it on Windows, but there it is 40% better than VC6).
That's a little bogus. If all I wanted to do was change the set of C files to compile and change the libraries to link with and did not worry about cross platform, I could do that easily by editing a Makefile. In fact it is far easier to add/remove a C file from a Makefile than from VC++.
Now admittedly creating the Makefile to get to the point where you can match VC++ is really a pain in the ass and the result is incredibly ugly. But that is like saying VC++ is a pain because you have to write it from scratch, ignoring the fact that Microsoft convienently sells you one they already wrote for you.
You really can't say anything positive about Microsoft here. I go and say that C# may be "better written" and people jump like crazy to call me an idiot. Hey: there are real intelligent people working at Microsoft! I don't like what they do all the time, but they are not stupid.
Face it, Java does not do primitives in the containiers. It does not do them "slower", it just DOES NOT DO THEM!!!
Therefore C# is not "faster". It is instead, better designed.
And I would like it if somebody came up with a language that did not have these artificial restrictions in it. C# is closer but it still treats primitives different all over the place.
C# generics can be faster for primitives because the JITter compiles a separate native image when the type parameter is a primitive.
Of course. That's why I said that it does not have to be slower. But that has nothing to do with whether C# handles non-primitives in a container faster. It may make them slower, or if correctly written it makes them the same speed. But it does not make them faster!!!
The only (good) reason Java doesn't support this in their impl of generics is for backward compatibility with older JVM's.
Good point, though I thought they also introduced syntax problems so that this could not be fixed even if they were willing to break the JVMs.
That fix is for a different bug ("%00" in a URL causes the status an location bar to only show the text before the %00. This can be combined with the fact that the text before an '@' in the URL does not determine what the site you visit is. So putting "%00@" in an URL will hide the real location. Their "fix" is to completely disable the ability of '@' to work at all). So one wrong for you.
Slashdot posted an article about this fix: "Microsoft To Remove Support For http(s) auth URLs". Look down a few articles in the main page. So two wrong for you.
Microsoft has not announced a fix for this bug (which involves some things called CLSID's from the registry). So three wrong for you.