KDE does in fact scale it's buttons, etc. It does about as well as could be expected at scaling the GUI if you assumme they don't want to scale pixmaps.
The problem is that it is completely the wrong size! It usually comes out really tiny for me when I go to somebody's screen that is set to 72 dpi. And if they go to my screen set to 100 dpi their graphics come out really big.
Yes, in theory, it is compensating correctly for the dot scale. However experience has shown that this is absolutly not what users want! For ratios less than 2 everybody seems to expect the graphics to scale to match the size of the pixels. Microsoft seems to have realized this and fixed their screens at 96 dpi, no matter what the resolution or screen size. Also check out Freedesktop.org's Cairo, where they have also decided that the default scale should not be 72/inch or anything, but instead the nearest integer multiple of pixels to 96/inch (thus if there was a 200-dpi screen it might double the pixels of all graphics, but a 100-dpi screen draws pixels exactly the same as a 72-dpi one).
Sure there is: the two parameters you specify are point size and resolution.
As I said, this would make sense IF THERE WAS A CALL THAT TOOK BOTH! Please point out to me the call in X, Xft, Macintosh, or GDI32, or any other popular graphic system that takes both a size and a point size to render.
Yes, an interface that said "render the point size N so it is M pixels tall" would be very useful. However none of the current graphics systems offer this, they just take "render points size N and I will calculate M internally so it is N*DPI/72". Since M and N are absolutely irretrivably linked, there is no reason not to specify M instead of N. This is all I have been saying!
Internally, Xft (I guess fontconfig now) allows you to choose sizes in pixels and accepts a floating-point number. You use XFT_PIXEL_SIZE as an argument to XftFontOpen.
I have been quite annoyed with KDE's insistence on storing the point size as an integer. Pretty much this means that to get useful sizes you have to set the DPI of the screen to 72. Really stupid of them.
To be a little more specific, unless you provide a call that takes two sizes (ie the size in pixels and the point size you are trying to simulate) the fact that fonts might render differently at different sizes is irrelevant, as it is trivial to convert the requested size into the other size. Since none of the interfaces I see take two sizes, specifying the size in points serves no purpose!!!
Knuth certainly does know what he is talking about. That is why he seperates the generation of the outlines (which may use a point size, and weight, and arbitrary other information that most people think of as specifying different fonts) from the rasterization (which only uses a scaling matrix).
Re:Huh? Targetting Outlook? Not this time...
on
Darl Goes to Harvard
·
· Score: 1
No, it relied on Outlook bugs that hid the extension of the file and made it look like a.txt file.
However there are lots of indications that people are stupid enough that they clicked on it in other mail readers that did not have this bug and clearly indicated the file was executable. So you could claim that it did not rely on Outlook bugs, but somebody certainly wrote some code to use the Outlook bug if it could.
Also if I understand it right, it sometimes sent the file as a.zip. This would indicate a bug in the unzip code as it executed the file rather than just put it on the disk. Or possible they just disguised the.exe as a.zip and thus relied on the Outlook bug. I don't know about this one.
[QUOTE] "The minute (IBM) puts its 10,000 patents into the public domain, I will follow you with my product," he said. [/QUOTE]
Absolutly this statement is rubbish. We don't want him to put his code in public domain. We want him to clearly identify it so we can stop violating his copyrights. If his claims are correct, distributors of Linux are voilating his copyright, but he is providing zero information on how to stop doing so. He does not even say "you have to stop distributing it", instead he claims he will get money from the receivers of the Linux copies, which is bogus because he is not punishing the copyright violator.
SCO's actions are like IBM telling SCO "you are violating one of our patents, but we aren't going to tell you which one, so you have to go out of business".
All modern font rendering systems render those two fonts exactly the same. Check the source code for FreeType if you don't believe me. Font renderers are much more concerned with pixel mapping and hinting and thus only change the rendering depending on the pixel size. You are probably thinking about kerning issues (which are easily handled at a higher level, especially because the user wants to control them anyway) or obsolete photographic effects involving blooming and focus that are better compensated by processing the entire page image before it is printed.
Your argument also makes no sense because there is no way to seperately specify the point size and pixel size. Because of this, it is trivial to figure out the point size from the pixel size (just multiply the other way) and use this result to control your fancy font renderer. Thus you have lost absolutely NOTHING by specifying the font size in pixels.
There does seem to be an incredible mental block on the part of a lot of posters here. There is NO reason why exactly one graphics call (select a font) is specified in a different coordinate system than every other graphics call! Fonts are not special, if you think they are you seem to be stuck in 1960's graphics!
Notice that if the graphics interface took everything in points, or let you scale and transform and applied that same transform to fonts (like Postscipt does) I would have no complaint. There is nothing wrong with points, but there is a serious problem with not being consistent!
All your arguments make sense if there were calls to draw scaled things other than fonts. For instance a call that is "draw a rectangle this many points in size at this many points from the top and left of the window" would allow you to mix rectangles with point-sized fonts.
The fact is that X, Win32, and Xft, do not provide any such calls except for fonts. This indicates that the whole idea is a mistake, not some intelligent design.
Actually I found the information in a "insiders guide to Windows" book, and since some other posters here seem unaware of it I guessed Microsoft did not document it well.
That does not really explain why X came up with the same bogusity at the same time Apple was developing the Mac, and well before Windows did it.
It does seem a bunch of people all came to the same mistaken conclusion that people wanted to see fonts the same physical size on all screens, but for some reason were uninterested in seeing any other graphics be the same physical size.
Quite awhile ago I fixed fltk to take the font size in pixels. That is why I know about the (somewhat undocumented) negative value to the GDI32 call. In X there is also a "pixel size" field in those long stupid -*-dash-font-names-* so I used that. Fortunately Xft got smarter and at least provides a clean and documented way to request font sizes in pixels (though they STILL provide a way to select it in points, despite the fact that none of the rest of Xrender does any such scaling, so even Keith Packard seems to not have learned...)
That's bullshit. They should keep and display the letters '%', '0', and '0'. That's what they need to send in the http request anyway.
I'm not sure, but I think the http request is null-terminated. If so, using a different type of string (such as a counted one) would actually result in more security holes. Perhaps you could fool it to disguise a call to "evil" as a call to "evil_fighters" by putting a \0 after "evil" (this is just an example of why using different types of strings is bad, not necessarily what could actually happen).
Get rid of this and any ability to hide the destination of a URL. The status bar should show the URL (it can show the javascript status when you are *not* pointing at a URL).
If sites are relying on this information being visible, show it in the tooltip for the URL instead.
Absolutlely agree about the image "DPI" stuff. I work in computer graphics for a living and can tell you the #1 important detail about a picture is "how many pixels it is wide, and how many pixels it is tall". But you go to Photoshop or any consumer program that manipulates pictures, and they will not tell you this information! Instead they tell you all this "DPI" stuff and perhaps, if you look carefully, they tell you the dimensions of the picture, so that you are forced to multiply to get the actual useful information. Tons of documentation says "change the DPI" which is meaningless: it can either mean you just change some DPI field which makes the picture bigger or smaller, or that you are resampling it so it draws the same size but has a different number of pixels (in reality it typically means both, Photoshop changes some internal DPI field and also resamples the image, but because the new size and dpi are both integers, it necessarily rounds the actual size to a different value, thus destroying any ability to do accurate sizing and defeating the only plausable reason for this DPI stuff in the first place!).
I disagree with you that X works ok. Try setting up KDE to look nice, and then change the DPI of your monitor and restart X. The display is completely screwed up because only the fonts change size, nothing else does! The fact that Microsoft had the same bug is no excuse, this is a failure. I recommend the exact same solution that Microsoft did, which is to force the DPI to a defined value such as 96 so this does not happen anymore.
Isn't pulling the DNS records the correct thing to do? This stops the virus from sending any traffic and thus actually helps the network. I felt sure SCO wanted the virus to be damaging to everybody, but it does seem that some sysadmin at SCO decided to not be an asshole.
Making just sco.com go to their home page would work perfectly. They could also make www.sco.com go to some big server that they pay that delivers a simple "click here" page, though I doubt they will do that because it will make most people think the site is up, when they want people to think it is down.
I don't know what the article is talking about for Microsoft. The second virus is a dud and Microsoft's site is easily handling the traffic and works perfectly.
Yes it primarily relies on user stupidity. But it really exploits a bug in Outlook in order to hide or disguise the file type. Anybody who claims this does not use a Windows bug is lying. Yes I'm sure some people managed to run it from other mail readers, but there is specific code in there to take advantage of the extension-hiding bug and I'm sure that tripled or more how many clicks there were!
This is not Microsoft's problem. If you did the minor detail of checking you would see that the Win32 API for selecting a font size takes the size in *points*. The same call takes a negative number to indicate pixels, which appears to be an addition at the last minute in an attempt to allow the DPI to change, but that appears to not have worked due to too many programs using the point interface.
It is true they assumme the screen is 96 dpi so they multiply this by 96/72 to get the number of pixels. There is an internal setting for the screen DPI but changing it will screw up most programs because all the other calls are in pixels.
The exact same bug exists on X, with the addition that screens are (correctly?) set to all kinds of different DPI values. Like GDI32, all other graphics are measured in pixels, which means if your screen is set to a DPI different than the original programmer had, your display is probably messed up. This is why your KDE display suddenly comes up with tiny fonts when you change the X driver. If this DPI was forced to 96 (or 100 which is popular on X) it would solve these problems the same as Windows does.
I have no idea why X, Microsoft, and you all seem to think points are important, especially when every other graphics call measures stuff in pixels. It really would not be hard to have a DPI report from the device and let the program pick the pixel size to match, since they have to do this anyway to draw a 1" square or any other fixed-size graphic.
I agree. I am absolutely floored by how stupid this "patch" is. It does not even address the basic bug! (the basic bug is that the preview always ends at a %00).
There are a hundred other fixes they could do that would be better than this one. It is going to break sites! Certianly in-house things use this plenty for low security, and it should be quite good security for one-off passwords that only work for a very short time.
Number 1 fix would be to preview the url in it's entirety. %00 should show as %00.
Now a lot of people have pointed out that the '@' syntax still fools a lot of people anyway (that was why a bunch of MS trolls claimed the same bug was in Mozilla, because they were stupid enough to be fooled by this). So number 2 fix, while they are looking at that code, is change it so that everything before the @ is not displayed. This also will hide the username/password for (obviously weak) security.
Removing the '@' does nothing for people fooled by "//www.microsoft.com.evil.org" thinking it goes to Microsoft and not Evil. So maybe rearrange URL's like "//com.evil.org(www.microsoft.com.evil.org)/..." or come up with a new standard for previewing them like "///org/evil/com/microsoft/www//..." so the most importante information is first. Obviously this is tough to design, but Microsoft could do this and perhaps impress people here, rather than annoy them with their incredibly lame "solutions".
. This is getting more tricky since it could be used to hide information
No, because anybody that stupid can be fooled by simply having the URL go directly to the evil site.
The basic problem is that IE displays the URL "http://www.good.com/foo%00@www.evil.com/bar" as "http://www.good.com/foo" and thus completely hides the fact that it actually goes to "www.evil.com", even for an expert user. This is the bug in IE that needs to be fixed.
Even if fixed, the above URL would certainly fool a lot of people that it goes to "good.com". All browsers today seem vulnerable to this. So some solution is necessary.
My recommended solution is to preview starting with the '@' sign so the user sees "@www.evil.com/bar". This also has the nice effect of hiding the username & password for (obviously extremely weak) security.
I do think Microsoft's solution is about the stupidest thing they can do after the "do nothing" solution. I find it hard to believe they cannot fix their status bar preview, this would indicate the innards are such a horrible mess of spagetti that they cannot make even simple changes and they had to attack the only single point of entry which is where the http get command is processed.
Of course the '@' is not a standard, but neither is ActiveX and Microsoft does not seem to be removing that. Saying that it is ok because it is not an official standard is stupid. It will break plenty of sites.
Actually I think my suggestion would require minimal effort. All you have to do is go to the code that adds links to the hash table, and make it add several links.
The only defect is if you visit the "parent" of a visited page, the preview link will highlight. This can either be considered a "feature" or you could fix it by adding an extra character to the end of all the prefixes before putting them in the table, so that they don't match (the code to highlight the status bar would also add this character so it works).
Re:My god how stupid can you be?
on
SCO Offline
·
· Score: 1
And you are saying this behavior is not a bug or security problem?
This requires the program to actually LOOK INTO THE.EXE to find the icon! This means they KNOW the program is exectuable, so they are actively trying to assist it in fooling the user!
How about the mail or browser programs display some EXE icon. If the user copies it to the desktop then the icon can be changed to what is imbedded in the program. They should also refuse to run it or copy it to the desktop without a big warning message, but the fact that there is no warning cannot really be considered a bug.
Better yet, it should show the EXE icon even if it goes on the desktop. You have to run it and it has to do something to the registry for the actual icon to appear. The icon does not appear for "documents" until the registry is messed with so I can't see this being too much of a problem for any real program.
I am absolutely amazed that people like you can be so blinded by your use of Windows that the concept of "don't display the icon imbedded in the.exe" is apparently inconcievable to you! So I will reiterate that you are pretty stupid. Think for a change!
Who said anybody using Linux has to release their code to the public?
Only people who modify Linux (not who write programs atop it), and who distribute the modified version (ie they sell or give it to somebody outside their organization) have to release the code, and only to their modifications to Linux.
Saying you have to release the source code is as accurate as saying everybody who writes software that works on Windows must be a Microsoft employee. Stop spewing the FUD and lies.
That seems to be a new version of their older Linux commercial.
I have no idea why they blew one million dollars (or whatever it cost) to run that. For the Superbowl they should have come up with a funny ad of some sort.
My god how stupid can you be?
on
SCO Offline
·
· Score: 1
Give a file "virus.exe" the same icon graphic as a word file, and most users wouldn't know the difference.
And showing the wrong icon is not a bug? Get a clue: that's part of the whole "hiding the extension" bug! You could "unhide" the extensions by drawing the correct icon for the extension. It's part of the bug!!!
On the other hand, if you don't hide the extension, then each of us here would be constantly dealing with dumb users who have renamed "Document1.doc" to "Report" (no extension). For 99% of users, hiding extensions is a good idea.
Please explain why "hiding the extensions" has anything to do with "stop the user from changing the extensions"
Slashdot Mirror
KDE does in fact scale it's buttons, etc. It does about as well as could be expected at scaling the GUI if you assumme they don't want to scale pixmaps.
The problem is that it is completely the wrong size! It usually comes out really tiny for me when I go to somebody's screen that is set to 72 dpi. And if they go to my screen set to 100 dpi their graphics come out really big.
Yes, in theory, it is compensating correctly for the dot scale. However experience has shown that this is absolutly not what users want! For ratios less than 2 everybody seems to expect the graphics to scale to match the size of the pixels. Microsoft seems to have realized this and fixed their screens at 96 dpi, no matter what the resolution or screen size. Also check out Freedesktop.org's Cairo, where they have also decided that the default scale should not be 72/inch or anything, but instead the nearest integer multiple of pixels to 96/inch (thus if there was a 200-dpi screen it might double the pixels of all graphics, but a 100-dpi screen draws pixels exactly the same as a 72-dpi one).
Sure there is: the two parameters you specify are point size and resolution.
As I said, this would make sense IF THERE WAS A CALL THAT TOOK BOTH! Please point out to me the call in X, Xft, Macintosh, or GDI32, or any other popular graphic system that takes both a size and a point size to render.
Yes, an interface that said "render the point size N so it is M pixels tall" would be very useful. However none of the current graphics systems offer this, they just take "render points size N and I will calculate M internally so it is N*DPI/72". Since M and N are absolutely irretrivably linked, there is no reason not to specify M instead of N. This is all I have been saying!
Internally, Xft (I guess fontconfig now) allows you to choose sizes in pixels and accepts a floating-point number. You use XFT_PIXEL_SIZE as an argument to XftFontOpen.
I have been quite annoyed with KDE's insistence on storing the point size as an integer. Pretty much this means that to get useful sizes you have to set the DPI of the screen to 72. Really stupid of them.
Oh yea, Dell's been hurt real bad because that MyDoom virus runs on their machines. People are suing them all over the place.
NOT!
I will explain this once again because people here are too dumb to understand:
Lets say that all sizes above 10 point need to be done with A() and all smaller sizes done with B(). You are saying this requires this code:
pick_font(float points) {
if (points > 10) A(); else B();
}
Now look carefully and try not to get confused when I show you how I would write the EXACT SAME FUNCTIONALITY:
pick_font(float pixels) {
if (pixels*72/DPI > 10) A(); else B();
}
To be a little more specific, unless you provide a call that takes two sizes (ie the size in pixels and the point size you are trying to simulate) the fact that fonts might render differently at different sizes is irrelevant, as it is trivial to convert the requested size into the other size. Since none of the interfaces I see take two sizes, specifying the size in points serves no purpose!!!
Knuth certainly does know what he is talking about. That is why he seperates the generation of the outlines (which may use a point size, and weight, and arbitrary other information that most people think of as specifying different fonts) from the rasterization (which only uses a scaling matrix).
No, it relied on Outlook bugs that hid the extension of the file and made it look like a .txt file.
.zip. This would indicate a bug in the unzip code as it executed the file rather than just put it on the disk. Or possible they just disguised the .exe as a .zip and thus relied on the Outlook bug. I don't know about this one.
However there are lots of indications that people are stupid enough that they clicked on it in other mail readers that did not have this bug and clearly indicated the file was executable. So you could claim that it did not rely on Outlook bugs, but somebody certainly wrote some code to use the Outlook bug if it could.
Also if I understand it right, it sometimes sent the file as a
[QUOTE]
"The minute (IBM) puts its 10,000 patents into the public domain, I will follow you with my product," he said.
[/QUOTE]
Absolutly this statement is rubbish. We don't want him to put his code in public domain. We want him to clearly identify it so we can stop violating his copyrights. If his claims are correct, distributors of Linux are voilating his copyright, but he is providing zero information on how to stop doing so. He does not even say "you have to stop distributing it", instead he claims he will get money from the receivers of the Linux copies, which is bogus because he is not punishing the copyright violator.
SCO's actions are like IBM telling SCO "you are violating one of our patents, but we aren't going to tell you which one, so you have to go out of business".
They have offered that for 8 years. The only change is that it is free now.
All modern font rendering systems render those two fonts exactly the same. Check the source code for FreeType if you don't believe me. Font renderers are much more concerned with pixel mapping and hinting and thus only change the rendering depending on the pixel size. You are probably thinking about kerning issues (which are easily handled at a higher level, especially because the user wants to control them anyway) or obsolete photographic effects involving blooming and focus that are better compensated by processing the entire page image before it is printed.
Your argument also makes no sense because there is no way to seperately specify the point size and pixel size. Because of this, it is trivial to figure out the point size from the pixel size (just multiply the other way) and use this result to control your fancy font renderer. Thus you have lost absolutely NOTHING by specifying the font size in pixels.
There does seem to be an incredible mental block on the part of a lot of posters here. There is NO reason why exactly one graphics call (select a font) is specified in a different coordinate system than every other graphics call! Fonts are not special, if you think they are you seem to be stuck in 1960's graphics!
Notice that if the graphics interface took everything in points, or let you scale and transform and applied that same transform to fonts (like Postscipt does) I would have no complaint. There is nothing wrong with points, but there is a serious problem with not being consistent!
All your arguments make sense if there were calls to draw scaled things other than fonts. For instance a call that is "draw a rectangle this many points in size at this many points from the top and left of the window" would allow you to mix rectangles with point-sized fonts.
The fact is that X, Win32, and Xft, do not provide any such calls except for fonts. This indicates that the whole idea is a mistake, not some intelligent design.
Actually I found the information in a "insiders guide to Windows" book, and since some other posters here seem unaware of it I guessed Microsoft did not document it well.
That does not really explain why X came up with the same bogusity at the same time Apple was developing the Mac, and well before Windows did it.
It does seem a bunch of people all came to the same mistaken conclusion that people wanted to see fonts the same physical size on all screens, but for some reason were uninterested in seeing any other graphics be the same physical size.
Quite awhile ago I fixed fltk to take the font size in pixels. That is why I know about the (somewhat undocumented) negative value to the GDI32 call. In X there is also a "pixel size" field in those long stupid -*-dash-font-names-* so I used that. Fortunately Xft got smarter and at least provides a clean and documented way to request font sizes in pixels (though they STILL provide a way to select it in points, despite the fact that none of the rest of Xrender does any such scaling, so even Keith Packard seems to not have learned...)
That's bullshit. They should keep and display the letters '%', '0', and '0'. That's what they need to send in the http request anyway.
I'm not sure, but I think the http request is null-terminated. If so, using a different type of string (such as a counted one) would actually result in more security holes. Perhaps you could fool it to disguise a call to "evil" as a call to "evil_fighters" by putting a \0 after "evil" (this is just an example of why using different types of strings is bad, not necessarily what could actually happen).
Get rid of this and any ability to hide the destination of a URL. The status bar should show the URL (it can show the javascript status when you are *not* pointing at a URL).
If sites are relying on this information being visible, show it in the tooltip for the URL instead.
Have any browsers addressed this?
Absolutlely agree about the image "DPI" stuff. I work in computer graphics for a living and can tell you the #1 important detail about a picture is "how many pixels it is wide, and how many pixels it is tall". But you go to Photoshop or any consumer program that manipulates pictures, and they will not tell you this information! Instead they tell you all this "DPI" stuff and perhaps, if you look carefully, they tell you the dimensions of the picture, so that you are forced to multiply to get the actual useful information. Tons of documentation says "change the DPI" which is meaningless: it can either mean you just change some DPI field which makes the picture bigger or smaller, or that you are resampling it so it draws the same size but has a different number of pixels (in reality it typically means both, Photoshop changes some internal DPI field and also resamples the image, but because the new size and dpi are both integers, it necessarily rounds the actual size to a different value, thus destroying any ability to do accurate sizing and defeating the only plausable reason for this DPI stuff in the first place!).
I disagree with you that X works ok. Try setting up KDE to look nice, and then change the DPI of your monitor and restart X. The display is completely screwed up because only the fonts change size, nothing else does! The fact that Microsoft had the same bug is no excuse, this is a failure. I recommend the exact same solution that Microsoft did, which is to force the DPI to a defined value such as 96 so this does not happen anymore.
Isn't pulling the DNS records the correct thing to do? This stops the virus from sending any traffic and thus actually helps the network. I felt sure SCO wanted the virus to be damaging to everybody, but it does seem that some sysadmin at SCO decided to not be an asshole.
Making just sco.com go to their home page would work perfectly. They could also make www.sco.com go to some big server that they pay that delivers a simple "click here" page, though I doubt they will do that because it will make most people think the site is up, when they want people to think it is down.
I don't know what the article is talking about for Microsoft. The second virus is a dud and Microsoft's site is easily handling the traffic and works perfectly.
Yes it primarily relies on user stupidity. But it really exploits a bug in Outlook in order to hide or disguise the file type. Anybody who claims this does not use a Windows bug is lying. Yes I'm sure some people managed to run it from other mail readers, but there is specific code in there to take advantage of the extension-hiding bug and I'm sure that tripled or more how many clicks there were!
This is not Microsoft's problem. If you did the minor detail of checking you would see that the Win32 API for selecting a font size takes the size in *points*. The same call takes a negative number to indicate pixels, which appears to be an addition at the last minute in an attempt to allow the DPI to change, but that appears to not have worked due to too many programs using the point interface.
It is true they assumme the screen is 96 dpi so they multiply this by 96/72 to get the number of pixels. There is an internal setting for the screen DPI but changing it will screw up most programs because all the other calls are in pixels.
The exact same bug exists on X, with the addition that screens are (correctly?) set to all kinds of different DPI values. Like GDI32, all other graphics are measured in pixels, which means if your screen is set to a DPI different than the original programmer had, your display is probably messed up. This is why your KDE display suddenly comes up with tiny fonts when you change the X driver. If this DPI was forced to 96 (or 100 which is popular on X) it would solve these problems the same as Windows does.
I have no idea why X, Microsoft, and you all seem to think points are important, especially when every other graphics call measures stuff in pixels. It really would not be hard to have a DPI report from the device and let the program pick the pixel size to match, since they have to do this anyway to draw a 1" square or any other fixed-size graphic.
I agree. I am absolutely floored by how stupid this "patch" is. It does not even address the basic bug! (the basic bug is that the preview always ends at a %00).
There are a hundred other fixes they could do that would be better than this one. It is going to break sites! Certianly in-house things use this plenty for low security, and it should be quite good security for one-off passwords that only work for a very short time.
Number 1 fix would be to preview the url in it's entirety. %00 should show as %00.
Now a lot of people have pointed out that the '@' syntax still fools a lot of people anyway (that was why a bunch of MS trolls claimed the same bug was in Mozilla, because they were stupid enough to be fooled by this). So number 2 fix, while they are looking at that code, is change it so that everything before the @ is not displayed. This also will hide the username/password for (obviously weak) security.
Removing the '@' does nothing for people fooled by "//www.microsoft.com.evil.org" thinking it goes to Microsoft and not Evil. So maybe rearrange URL's like "//com.evil.org(www.microsoft.com.evil.org)/..." or come up with a new standard for previewing them like "///org/evil/com/microsoft/www//..." so the most importante information is first. Obviously this is tough to design, but Microsoft could do this and perhaps impress people here, rather than annoy them with their incredibly lame "solutions".
. This is getting more tricky since it could be used to hide information
No, because anybody that stupid can be fooled by simply having the URL go directly to the evil site.
The basic problem is that IE displays the URL "http://www.good.com/foo%00@www.evil.com/bar" as "http://www.good.com/foo" and thus completely hides the fact that it actually goes to "www.evil.com", even for an expert user. This is the bug in IE that needs to be fixed.
Even if fixed, the above URL would certainly fool a lot of people that it goes to "good.com". All browsers today seem vulnerable to this. So some solution is necessary.
My recommended solution is to preview starting with the '@' sign so the user sees "@www.evil.com/bar". This also has the nice effect of hiding the username & password for (obviously extremely weak) security.
I do think Microsoft's solution is about the stupidest thing they can do after the "do nothing" solution. I find it hard to believe they cannot fix their status bar preview, this would indicate the innards are such a horrible mess of spagetti that they cannot make even simple changes and they had to attack the only single point of entry which is where the http get command is processed.
Of course the '@' is not a standard, but neither is ActiveX and Microsoft does not seem to be removing that. Saying that it is ok because it is not an official standard is stupid. It will break plenty of sites.
Actually I think my suggestion would require minimal effort. All you have to do is go to the code that adds links to the hash table, and make it add several links.
The only defect is if you visit the "parent" of a visited page, the preview link will highlight. This can either be considered a "feature" or you could fix it by adding an extra character to the end of all the prefixes before putting them in the table, so that they don't match (the code to highlight the status bar would also add this character so it works).
And you are saying this behavior is not a bug or security problem?
.EXE to find the icon! This means they KNOW the program is exectuable, so they are actively trying to assist it in fooling the user!
.exe" is apparently inconcievable to you! So I will reiterate that you are pretty stupid. Think for a change!
This requires the program to actually LOOK INTO THE
How about the mail or browser programs display some EXE icon. If the user copies it to the desktop then the icon can be changed to what is imbedded in the program. They should also refuse to run it or copy it to the desktop without a big warning message, but the fact that there is no warning cannot really be considered a bug.
Better yet, it should show the EXE icon even if it goes on the desktop. You have to run it and it has to do something to the registry for the actual icon to appear. The icon does not appear for "documents" until the registry is messed with so I can't see this being too much of a problem for any real program.
I am absolutely amazed that people like you can be so blinded by your use of Windows that the concept of "don't display the icon imbedded in the
Who said anybody using Linux has to release their code to the public?
Only people who modify Linux (not who write programs atop it), and who distribute the modified version (ie they sell or give it to somebody outside their organization) have to release the code, and only to their modifications to Linux.
Saying you have to release the source code is as accurate as saying everybody who writes software that works on Windows must be a Microsoft employee. Stop spewing the FUD and lies.
That seems to be a new version of their older Linux commercial.
I have no idea why they blew one million dollars (or whatever it cost) to run that. For the Superbowl they should have come up with a funny ad of some sort.
Give a file "virus.exe" the same icon graphic as a word file, and most users wouldn't know the difference.
And showing the wrong icon is not a bug? Get a clue: that's part of the whole "hiding the extension" bug! You could "unhide" the extensions by drawing the correct icon for the extension. It's part of the bug!!!
On the other hand, if you don't hide the extension, then each of us here would be constantly dealing with dumb users who have renamed "Document1.doc" to "Report" (no extension). For 99% of users, hiding extensions is a good idea.
Please explain why "hiding the extensions" has anything to do with "stop the user from changing the extensions"