Exactly. The self-installing executable is a fine example of convenience being the enemy of security: At first, it sounds like a good idea. The program knows how to install the program you want with no interference from you. But if the program installs something you don't want, you're screwed.
How is it more convinient for each program to have its own installer?
* It forces me to learn a new installer interface each time I download a new program.
* It allows software makers to get away with ridiculously worded English-only EULAs, where a single installer could have a set "named expandable-block" format which would look like "We are Netscape and you are about to install Netscape Navigator. We don't guarantee that it will work on your system, but it worked on ours. Not to be used in real-time systems." when collapsed. In addition to hurting users, this hurts software makers, since each software maker must hire expensive lawyers to write a program-specific EULA.
* It makes it easy for an individual installer to screw something up like not taking block size and breathing room into account when checking whether I have enough disk space. (Total file size 200MB, 209MB disk space free, plenty of free space!)
* It lets programs decide whether to be "Program Files\Mozilla" or "Program Files\Mozilla 0.9.9" or "Program Files\mozilla.org\Mozilla", instead of letting the user decide once.
* It makes downloads bigger, since each program feels a need to include its own installer.
* It makes uninstallation unreliable.
Throw in spyware and viruses, and it's much less convinient for users if each program has its own installer.
Radlight's official site uses an image that says "Download it now!" and has a CNet logo on it. But the link now points to simtel, not CNet. How did they get away with continuing to use CNet's logo and using it to point to a non-CNet site?
(cexx.org admin: if you're reading this, please make a page I can link to that has "Radlight" in the title. I wanted to link "Radlight" at the beginning of my comment to your site to push it up in the Google results like users have done for Gator.)
Again, this does NOT explain why a plain old link with no javascript involved cannot be allowed... All I want is for mozilla to recognize the cases where a "file:" URL is actually safe and allow it to be clicked.
In what cases are file: links safe? It seems to me that all of the problems listed could be exploited by what looks like a "plain link": the DoS attack linking to/dev/zero, checking whether a file exists, or planting a file using a helper app that doesn't follow the odd practice of creating files with random names. The malicious web site would just have to convince you to click a link, which is not hard.
It *seems* like they understand fair use...
on
Dataplay Ready to Launch
·
· Score: 2, Interesting
DataPlay users will be able to record directly from CDs they already own, but Quigley predicts those users will be a minority. Most people, he said, will go ahead and buy their favorites again in the new format.
But will we be able to record music from DataPlay to the next format?
See http://bugzilla.mozilla.org/show_bug.cgi?id=84128# c20. That explains why it's necessary to block links to file:/// urls. It also describes a hidden pref you or your corporation can set that will allow links to file:/// urls if backwards-compatibility is more useful than increased security.
"Rating: Medium because user interaction is needed"?! What's the chance that the user will hit the back button when they think it will take them back to a porn image gallery, 80%?
Hotmail does not have this problem. Netscape webmail does not have this problem. It's a bug in your code, and I bet you would have saved time by fixing it rather than trying to "teach" your users how to work around it.
I wouldn't call this a "dumb ass bug". It's subtle, and finding it requires being aware of several things and thinking to combine them:
* javascript: URLs run in the security domain of the page from which they originate. (Or, if they're stored in the user's bookmarks, they run as part of the current page, letting them do cool things like show the HTML source of the selection.)
* If a javascript: URL returns a non-null value, it acts like a data: URL. For example, javascript:1+2;3+4 is equivalent to data:text/html,7. (Most of the time, this is just an annoyance, forcing you to put "void 0" at the end of a javascript: URL unless you're sure that the last calculation always returns null.)
* It is possible to go "forward" from a javascript: URL.
* The Back button incorrectly runs a javascript: URL in the security domain and context the current page instead of running it with no context or with the context of the page that put the URL in session history.
The fact that the bug was present in both IE and Mozilla until Mozilla 0.9.3 is strong evidence that the hole is not an obvious "dumb ass bug". I only discovered the hole because I make bookmarlets (javascript: URLs) in my free time and was being paid by Netscape to work on Mozilla security last summer.
I found the same bug in Mozilla last summer while I was working at Netscape. My boss fixed it within a week, so versions after Mozilla 0.9.3 did not have the bug. It was bug 88167 if you're interested. I'm not sure why I didn't notice that IE was vulnerable as well. Anyone want to go through old Mozilla security holes and see how many of them affect IE 6?
Anyway, keep using that Back button. If you're using IE to browse warez/porn, you have more to worry about than someone looking at your cookie for another site. An attacker could just copy the IE exploit of the week from http://jscript.dk/unpatched/. I believe that page has had current IE security holes that allow running arbitrary instructions for two months straight. (That means you can keep up with the latest IE patches, but if an attacker reads jscript.dk and can get you to click a link in AIM or read a message in OE, the attacker wins.)
By the way, what's with IE turning every cross-domain hole into a full remote compromise by letting sites link to res: urls? Current versions of Mozilla block links to chrome/res and even file, so a cross-domain hole doesn't even let sites read local files.
My school's CS department recently published a "clarification of our [the college's] Honor Code as it applies to computer science course work". Most of the restrictions make sense: for example, it prohibits "incorporation of material from a passive source without proper acknowledgement or citation". But I have issues with the last restriction, "comparison of solutions between or among students for the purpose of possible revision" (unless you have received permission from the instructor). First, it doesn't specifically apply to looking at source code, so it could apply to verbal comparison or discussing solutions to written problems, both of which are encouraged in most classes. Second, it prevents me from discussing homework while it's still fresh in my mind, rather than a week later when I get it back graded.
The "clarification" also states that one of the possible penalties for infringement is a "required public letter of apology". Forcing someone to write a public letter that they disagree with is just screwed up. Last year, a group of students was forced to write such a letter even though the majority of the student body thought that what the students had done was a harmless prank.
I didn't want to waste time and make myself look stupid by asking every CS prof whether it's ok to discuss homework, so I just didn't sign the clarification. Nobody has seemed to notice...
I wish they would make their own ads be subject to the "ads with higher clickthroughs are displayed higher on the page" rule. (See your usenix link.) I'm running an ad on the phrase "programming contest" and it's hard to tell whether my ad is below Google's because they're cheating by "paying more" (to themselves) or because their ad actually gets more clicks. It's especially frustrating because their ad is also the first search hit on Google, which should make their ad unnecessary.
Agreed. If you want to run untargetable ads, put them in a place that generally carries untargeted ads (metafilter, fuckedcompany, etc). Don't try to put them in a space reserved for targeted ads and then complain when your ad is removed.
... Or that annoying Verisign SSL ad that shows up when you search for general or unrelated keywords like "html" or "security" or "netscape". That ad's green "interest" bar is only one pixel long for "netscape" and two pixels long for "html". (Btw, what's with the num=0 link? That confused me, I kept trying other searches and getting zero hits.)
Does xenu.net promote "hate"? I thought they just told the truth.
Are those mutually exclusive? Many Slashdotters promote hating Microsoft in their comments, but those same posters would, if asked, say that they were telling the truth.
The Adwords TOS says that the ad and the page linked to may be "neither defamatory, libelous, slanderous or threatening". I don't see anything saying that you can't make true accusations. Do they generally prohibit running ads on the keyword foo that link to pages speaking out against the foo organization, or do they only prohibit such ads when the sites seem to be "promoting hate" more than arguing and informing against the foo organization?
Unless the law specified dstribution of *machine readable* malicious code (ie binaries)
Internet Explorer may be full of security holes and an integral part of Microsoft's plan to maintain its operating system monopoly, but I wouldn't go as far as calling IE binaries "malicious code".
From the article "Google Loves Blogs": "Google weights fresh votes more than older votes... fresh links are more heavily weighted". If that's true, the links from pro-scientology sites like whatisscientology and exactscientology might have lost voting power when they stopped being new. Conversely, linking to xenu.net from your site might only help temporarily.
I don't think so. Note that shortening the paint suppression period would make many sites start to display before Mozilla can figure out the relative sizes of blocks. One reason for paint suppression is that without it, page elements jump around during the first second or so of rendering. (Another reason, which IMO is less important, is that it reduces the total time Mozilla takes to display a page.)
Slashdot Mirror
Exactly. The self-installing executable is a fine example of convenience being the enemy of security: At first, it sounds like a good idea. The program knows how to install the program you want with no interference from you. But if the program installs something you don't want, you're screwed.
How is it more convinient for each program to have its own installer?
* It forces me to learn a new installer interface each time I download a new program.
* It allows software makers to get away with ridiculously worded English-only EULAs, where a single installer could have a set "named expandable-block" format which would look like "We are Netscape and you are about to install Netscape Navigator. We don't guarantee that it will work on your system, but it worked on ours. Not to be used in real-time systems." when collapsed. In addition to hurting users, this hurts software makers, since each software maker must hire expensive lawyers to write a program-specific EULA.
* It makes it easy for an individual installer to screw something up like not taking block size and breathing room into account when checking whether I have enough disk space. (Total file size 200MB, 209MB disk space free, plenty of free space!)
* It lets programs decide whether to be "Program Files\Mozilla" or "Program Files\Mozilla 0.9.9" or "Program Files\mozilla.org\Mozilla", instead of letting the user decide once.
* It makes downloads bigger, since each program feels a need to include its own installer.
* It makes uninstallation unreliable.
Throw in spyware and viruses, and it's much less convinient for users if each program has its own installer.
Anyone have a photo of the new plate?
Roxen has a nice htmlized version of rfc 2321 and most other rfcs as well.
Few though have a better claim to what we think of as a digital computer than John Mauchly.
Does that mean he passed the reverse turing test?
Radlight's official site uses an image that says "Download it now!" and has a CNet logo on it. But the link now points to simtel, not CNet. How did they get away with continuing to use CNet's logo and using it to point to a non-CNet site?
(cexx.org admin: if you're reading this, please make a page I can link to that has "Radlight" in the title. I wanted to link "Radlight" at the beginning of my comment to your site to push it up in the Google results like users have done for Gator.)
Again, this does NOT explain why a plain old link with no javascript involved cannot be allowed... All I want is for mozilla to recognize the cases where a "file:" URL is actually safe and allow it to be clicked.
/dev/zero, checking whether a file exists, or planting a file using a helper app that doesn't follow the odd practice of creating files with random names. The malicious web site would just have to convince you to click a link, which is not hard.
In what cases are file: links safe? It seems to me that all of the problems listed could be exploited by what looks like a "plain link": the DoS attack linking to
DataPlay users will be able to record directly from CDs they already own, but Quigley predicts those users will be a minority. Most people, he said, will go ahead and buy their favorites again in the new format.
But will we be able to record music from DataPlay to the next format?
See http://bugzilla.mozilla.org/show_bug.cgi?id=84128# c20. That explains why it's necessary to block links to file:/// urls. It also describes a hidden pref you or your corporation can set that will allow links to file:/// urls if backwards-compatibility is more useful than increased security.
Chuck was talking about data: URLs, not this IE hole.
Actually, that's a pretty good reason to not use Flash for navigation.
"Rating: Medium because user interaction is needed"?! What's the chance that the user will hit the back button when they think it will take them back to a porn image gallery, 80%?
Hotmail does not have this problem. Netscape webmail does not have this problem. It's a bug in your code, and I bet you would have saved time by fixing it rather than trying to "teach" your users how to work around it.
I wouldn't call this a "dumb ass bug". It's subtle, and finding it requires being aware of several things and thinking to combine them:
* javascript: URLs run in the security domain of the page from which they originate. (Or, if they're stored in the user's bookmarks, they run as part of the current page, letting them do cool things like show the HTML source of the selection.)
* If a javascript: URL returns a non-null value, it acts like a data: URL. For example, javascript:1+2;3+4 is equivalent to data:text/html,7. (Most of the time, this is just an annoyance, forcing you to put "void 0" at the end of a javascript: URL unless you're sure that the last calculation always returns null.)
* It is possible to go "forward" from a javascript: URL.
* The Back button incorrectly runs a javascript: URL in the security domain and context the current page instead of running it with no context or with the context of the page that put the URL in session history.
The fact that the bug was present in both IE and Mozilla until Mozilla 0.9.3 is strong evidence that the hole is not an obvious "dumb ass bug". I only discovered the hole because I make bookmarlets (javascript: URLs) in my free time and was being paid by Netscape to work on Mozilla security last summer.
I found the same bug in Mozilla last summer while I was working at Netscape. My boss fixed it within a week, so versions after Mozilla 0.9.3 did not have the bug. It was bug 88167 if you're interested. I'm not sure why I didn't notice that IE was vulnerable as well. Anyone want to go through old Mozilla security holes and see how many of them affect IE 6?
Anyway, keep using that Back button. If you're using IE to browse warez/porn, you have more to worry about than someone looking at your cookie for another site. An attacker could just copy the IE exploit of the week from
http://jscript.dk/unpatched/. I believe that page has had current IE security holes that allow running arbitrary instructions for two months straight. (That means you can keep up with the latest IE patches, but if an attacker reads jscript.dk and can get you to click a link in AIM or read a message in OE, the attacker wins.)
By the way, what's with IE turning every cross-domain hole into a full remote compromise by letting sites link to res: urls? Current versions of Mozilla block links to chrome/res and even file, so a cross-domain hole doesn't even let sites read local files.
My school's CS department recently published a "clarification of our [the college's] Honor Code as it applies to computer science course work". Most of the restrictions make sense: for example, it prohibits "incorporation of material from a passive source without proper acknowledgement or citation". But I have issues with the last restriction, "comparison of solutions between or among students for the purpose of possible revision" (unless you have received permission from the instructor). First, it doesn't specifically apply to looking at source code, so it could apply to verbal comparison or discussing solutions to written problems, both of which are encouraged in most classes. Second, it prevents me from discussing homework while it's still fresh in my mind, rather than a week later when I get it back graded.
The "clarification" also states that one of the possible penalties for infringement is a "required public letter of apology". Forcing someone to write a public letter that they disagree with is just screwed up. Last year, a group of students was forced to write such a letter even though the majority of the student body thought that what the students had done was a harmless prank.
I didn't want to waste time and make myself look stupid by asking every CS prof whether it's ok to discuss homework, so I just didn't sign the clarification. Nobody has seemed to notice...
I wish they would make their own ads be subject to the "ads with higher clickthroughs are displayed higher on the page" rule. (See your usenix link.) I'm running an ad on the phrase "programming contest" and it's hard to tell whether my ad is below Google's because they're cheating by "paying more" (to themselves) or because their ad actually gets more clicks. It's especially frustrating because their ad is also the first search hit on Google, which should make their ad unnecessary.
Agreed. If you want to run untargetable ads, put them in a place that generally carries untargeted ads (metafilter, fuckedcompany, etc). Don't try to put them in a space reserved for targeted ads and then complain when your ad is removed.
... Or that annoying Verisign SSL ad that shows up when you search for general or unrelated keywords like "html" or "security" or "netscape". That ad's green "interest" bar is only one pixel long for "netscape" and two pixels long for "html". (Btw, what's with the num=0 link? That confused me, I kept trying other searches and getting zero hits.)
Does xenu.net promote "hate"? I thought they just told the truth.
Are those mutually exclusive? Many Slashdotters promote hating Microsoft in their comments, but those same posters would, if asked, say that they were telling the truth.
The Adwords TOS says that the ad and the page linked to may be "neither defamatory, libelous, slanderous or threatening". I don't see anything saying that you can't make true accusations. Do they generally prohibit running ads on the keyword foo that link to pages speaking out against the foo organization, or do they only prohibit such ads when the sites seem to be "promoting hate" more than arguing and informing against the foo organization?
The whole thing assumes you are using *n?x at home
I hope you use kleenex at home when your nose is runny...
Unless the law specified dstribution of *machine readable* malicious code (ie binaries)
Internet Explorer may be full of security holes and an integral part of Microsoft's plan to maintain its operating system monopoly, but I wouldn't go as far as calling IE binaries "malicious code".
From the article "Google Loves Blogs": "Google weights fresh votes more than older votes... fresh links are more heavily weighted". If that's true, the links from pro-scientology sites like whatisscientology and exactscientology might have lost voting power when they stopped being new. Conversely, linking to xenu.net from your site might only help temporarily.
I don't think so. Note that shortening the paint suppression period would make many sites start to display before Mozilla can figure out the relative sizes of blocks. One reason for paint suppression is that without it, page elements jump around during the first second or so of rendering. (Another reason, which IMO is less important, is that it reduces the total time Mozilla takes to display a page.)
Only a few times after 800 reports. That actually sounds amazing patient of the Mozilla developers.
That was the point I was trying to make. I didn't word my comment very well... I should have included the word "only".
The Mozilla browser is by far the best porn browser, even without the Pornzilla add-ons and the Increment URL bookmarklet.