Zimbra's chief executive, Satish Dhamaraj, says that when he started his company in December 2003, "I really thought that Ajax was just a bathroom cleaner."
Shame the (bloody stupid) term "AJAX" wasn't coined until February 18, 2005.
Then if people want to send random games via email, we need managed execution for all files (as in.NET/Java). It should either be that, or nothing at all.
The day when running an EXE on Windows that's been delivered over the Web or email and can't by default can't access anything sensitive will be great indeed.
Automobiles can kill people. If you could stop cars from killing people, and add extra safety features, would you?
There's a limited amount you can do though. There's a hell of a lot more that can be done to protect users on computers though.
The analogy I thought of (although please let's not get into analogy hell going round and round) is that imagine for some odd reason a lift (er, "elevator") has one button to go up, one button to go down and one to cut the cables and fall to doom (ok maybe not entirely likely). The labels for the buttons are in a language you don't understand.
If the user presses the button and falls to their doom, is it the fault of the manufacturer or the user for not fully understanding what they were doing? Currently with MS email clients by default you basically have to confirm you meant to press the button. I say the button should just never be there.
I'm sorry, but trojans like this aren't the user's fault. They're the fault of their computer, allowing an executable from email (or other untrusted source) to run with no restrictions.
Users should *not* have to be scared of using their computer. The computer should simply stop them from doing anything wrong.
Users won't learn, so teach the computers instead.
Wish Microsoft bundles both Java and.NET - wasn't the whole reason why.NET does not come bundled yet, Microsoft's apprehension of being forced to bundle Java too?
The.NET Framework came on my XP SP1 CD, but isn't installed by default. You have to hunt to find it a bit:)
I don't know. I'm still waiting to figure out why after 5 years, Mozilla still hasn't implemented the W3C's standard for a click() method on an A tag. IE has supported this for many years.
Please show me one single page on w3.org where it mentions click() as a standard. Wait, you won't, as it isn't.
You're missing the point, Mozilla is about the w3c standards, if they put IE layer tags in the browser they'd effectively be going back on 4 years of development and vision.
Just wtf are "IE layer tags"? NS4 is the only browser to have had a proprietary layer system.
IE is terrible with CSS. You are FORCED to use DIV tags everywhere. You cannot apply width to the document body, for example. Mozilla does it all, and does it RIGHT.
Sorry, have you used IE since v4? They corrected the BODY positioning problems in IE6, you've been able to position all elements since IE5. Nothing wrong with DIVs for positioning anyway, as long as the content is properly marked up.
It disables frames in the Restricted Sites zone. Since the OE/Outlok all read email in the Restricted Sites zone by default, this enhancement means that those products now effectively disable frames in HTML email by default. This new behavior makes it impossible for an HTML email to automatically open a new window or to launch the download of an executable.
It also breaks HTML4 compliance by not showing the content of the noframe tag if the browser is configured to not display frames.
I expect someone will find a way round it in a week or two:)
In the UK, children under 12 aren't allowed to view a 12 rated film, even with an adult. PG (parental guidance) is the rating for "under 12 with adult".
However the BBFC are looking into changing this. In the easter school holidays they ran some trial tests at a few cinemas where they allowed under-12's to view 12-rated films with an adult.
From what I heard the trials were a big success.
All of Microsoft's programming documentation contains proprietary enhancements to the spec that are VERY IE specific. They make no distinction as to which objects, events, methods are standard, and which are cooked.
Utter rubbish.
The IE DHTML references on MSDN very clearly mark which objects, events, methods and properties are standard and which ones are not.
We now have one version of Gecko in Netscape, a different one in Galeon, another one in CompuServ, and then we'll have Mozilla and AOL with different versions again.
Actually, standards-complaint designs are most often the most backwards-compatible ones.
If you use CSS for all layout, older browsers will simply ignore it and display a nice, text-only version.
The problem is with bastard browsers that attempted to support CSS, and failed miserably - such as (*SCREAMS*) Netscape 4.
Most of these browsers parse the CSS so poorly however, its simple to get them to ignore it. In the case of NS4, adding media="all" to tags makes it take no notice.
> w3.org/Style/ uses "position: absolute;position: fixed;"; when a client that supports absolute positioning, but not fixed, it should accept the first then ignore the second, not accept both and then drop down to default positioning, which is what IE6 does.
<div style="top: 100px; left: 100px; position: absolute; position: relative;">test</div> positions fine in my IE6 - in both doctype modes.
IE6 still lacks support for anything but the most utterly basic CSS2, and claims to support things like position: fixed when it really doesn't (http://www.w3.org/Style/ is a good example of this; if a browser can't fix the menu to the viewport, it should just fix it in the document, but because IE6 thinks it supports that when it really doesn't, it screws it up and positions it as if it doesn't know any CSS positioning. Argh.)
MS have never claimed to support position:fixed within IE6. They have only ever claimed full CSS1 - which they mostly have - although with a few major bugs, but have shown an interest in fixing these.
I make a lot of my own cgi scripts for personal use, and javascript helps *a lot*
Maybe so, but the problem is web developers relying on scripting being on the client. I've made a series of articles on my site, showing how developers can better provide for users with no scripting.
Hi there, I was the one along with Thor Larholm who originally demoed this exploit on my website.
We did so as to attempt to put pressure on Microsoft to patch several major holes in Internet Explorer - the one we exploited (document.open) took MS exactly fifty four days to make a patch from, from it being publicly disclosed.
We felt this was pathetic, and the public had a right to know what Microsoft's bad programming could cause - none of the previous examples of the document.open hole had shown to what extent this could be exploited.
This new worm, although harmless, is a direct rip of the example code from our bulletin, modified to also e-mail the contact list and MSN sing-in name to an e-mail address.
As long as Microsoft continues to support the flawed security model of ActiveX, integrating products together this closely, such things will continue to happen.
The next MSN worm might be far worse.
Please, please all Internet Explorer users patch your systems now. If you are using IE5.0 or lower, MS haven't produced a patch for you - they clearly care more about their product lifecycles than customer's security. I strongly suggest upgrading to 5.5 or 6, failing that disable active scripting.
I'm also interested as to why Slashdot felt the need to approve this article about a worm, as several people submitted stories about my original MSN exploit example. Oh well, guess you need things in the wild before telling people?
Shame the (bloody stupid) term "AJAX" wasn't coined until February 18, 2005.
Please also see AJAX = Fraud.
Then if people want to send random games via email, we need managed execution for all files (as in .NET/Java). It should either be that, or nothing at all.
The day when running an EXE on Windows that's been delivered over the Web or email and can't by default can't access anything sensitive will be great indeed.
Automobiles can kill people. If you could stop cars from killing people, and add extra safety features, would you?
There's a limited amount you can do though. There's a hell of a lot more that can be done to protect users on computers though.
The analogy I thought of (although please let's not get into analogy hell going round and round) is that imagine for some odd reason a lift (er, "elevator") has one button to go up, one button to go down and one to cut the cables and fall to doom (ok maybe not entirely likely). The labels for the buttons are in a language you don't understand.
If the user presses the button and falls to their doom, is it the fault of the manufacturer or the user for not fully understanding what they were doing? Currently with MS email clients by default you basically have to confirm you meant to press the button. I say the button should just never be there.
I'm sorry, but trojans like this aren't the user's fault. They're the fault of their computer, allowing an executable from email (or other untrusted source) to run with no restrictions.
Users should *not* have to be scared of using their computer. The computer should simply stop them from doing anything wrong.
Users won't learn, so teach the computers instead.
The .NET Framework came on my XP SP1 CD, but isn't installed by default. You have to hunt to find it a bit :)
And it was originally posted in May
Please show me one single page on w3.org where it mentions click() as a standard.
Wait, you won't, as it isn't.
Just wtf are "IE layer tags"? NS4 is the only browser to have had a proprietary layer system.
That's the last time they use VBScript for their systems then.
It also breaks HTML4 compliance by not showing the content of the noframe tag if the browser is configured to not display frames.
I expect someone will find a way round it in a week or two :)
At least Mozilla patch very quickly - that read local files was fixed virtually overnight. It took MS months to fix the same issue.
Netscape however then released 6.2.3, which is basically an 8Mb (min download) security patch.
However this is rubbish, his code is wrong - this has nothing to do with the patch.
Don't name form elements "submit", folks.
And here's information about it: http://news.bbc.co.uk/cbbcnews/hi/tv_film/newsid_1 627000/1627976.stm
Thor Larholm released another IE universal cross-site-scripting bug today. And there are more where that came from...
The IE DHTML references on MSDN very clearly mark which objects, events, methods and properties are standard and which ones are not.
Their CSS Property Index clearly lists non-standard entries.
We now have one version of Gecko in Netscape, a different one in Galeon, another one in CompuServ, and then we'll have Mozilla and AOL with different versions again.
"Great"
Actually, standards-complaint designs are most often the most backwards-compatible ones.
If you use CSS for all layout, older browsers will simply ignore it and display a nice, text-only version.
The problem is with bastard browsers that attempted to support CSS, and failed miserably - such as (*SCREAMS*) Netscape 4.
Most of these browsers parse the CSS so poorly however, its simple to get them to ignore it. In the case of NS4, adding media="all" to tags makes it take no notice.
1) Take a look around Slashdot.
2) Do the complete opposite to everything Slashdot has done.
> w3.org/Style/ uses "position: absolute;position: fixed;"; when a client that supports absolute positioning, but not fixed, it should accept the first then ignore the second, not accept both and then drop down to default positioning, which is what IE6 does.
<div style="top: 100px; left: 100px; position: absolute; position: relative;">test</div> positions fine in my IE6 - in both doctype modes.
MS have never claimed to support position:fixed within IE6. They have only ever claimed full CSS1 - which they mostly have - although with a few major bugs, but have shown an interest in fixing these.
We did so as to attempt to put pressure on Microsoft to patch several major holes in Internet Explorer - the one we exploited (document.open) took MS exactly fifty four days to make a patch from, from it being publicly disclosed.
We felt this was pathetic, and the public had a right to know what Microsoft's bad programming could cause - none of the previous examples of the document.open hole had shown to what extent this could be exploited.
This new worm, although harmless, is a direct rip of the example code from our bulletin, modified to also e-mail the contact list and MSN sing-in name to an e-mail address.
As long as Microsoft continues to support the flawed security model of ActiveX, integrating products together this closely, such things will continue to happen.
The next MSN worm might be far worse.
Please, please all Internet Explorer users patch your systems now. If you are using IE5.0 or lower, MS haven't produced a patch for you - they clearly care more about their product lifecycles than customer's security. I strongly suggest upgrading to 5.5 or 6, failing that disable active scripting.
I'm also interested as to why Slashdot felt the need to approve this article about a worm, as several people submitted stories about my original MSN exploit example. Oh well, guess you need things in the wild before telling people?