Does IE8 Really Pass Acid2? [Updated]

thevirtualcat found some inconsistencies in IE8's Acid2 results that made him wonder what's going on. Can anyone replicate these results or, better yet, explain them?
Update: 03/22 23:54 GMT by KD : Several readers pointed out this has to do with cross-site scripting prevention, as described here.

Comments

The answer...

[26199]

As TFA mentions (at the very end!) this is explained here.

Summary: cross-site security means that if you move the test off the original domain, the test changes. In fact IE8 does the wrong (nonstandard) thing in these cases, but according to them it's more secure (it fails earlier). They're considering making it more standards compliant once they're convinced it's secure enough.

Re:The answer...

[zappepcs]

I can go one better for you. Technically, MS is correct. MS is thumbing it's nose at standards because they can say "Look, we did it your way. We made IE8 extremely secure and now you claim it's broke. We are not the people that broke web browsing and the Internet, you did it. If we did everything people suggest the Internet just doesn't work."

To a point, they are right, but they did this to show they are better and only seem insecure because if they don't do such things as they have done the Internet will not work. Oh yes, btw, those other browsers are not secure either... see how their stuff still works?

Re:The answer...

[pohl]

So the behaviour mandated by the standard is insecure?

No, that is not the case. IE8 is trying to prevent exploitation of their own, proprietary ActiveX API, and simply needs to make some minor corrections to make sure that they do it in such a way that does not violate the standards. The standards don't need to be revised since nobody else implements the swiss cheese that is ActiveX.

Re:The answer...

[VGPowerlord]

I disagree. It should fall back to the data url when loading the other object failed. Not only that, but the HTML standard agrees with me on this:

If the user agent is not able to render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render its contents.

and

One significant consequence of the OBJECT element's design is that it offers a mechanism for specifying alternate object renderings; each embedded OBJECT declaration may specify alternate content types. If a user agent cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.

Known Cross-domain security issue

[Ececheira]

The reason you're seeing the result is due to an "overly secure" default for beta 1 when it comes to cross-domain embedded objects.

Here's the explanation:
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx

Google is your friend next time... :)

Re:Yes, that's true.

[Naughty Bob]

M$ has gone it's own way so long that the quickest route for them to a standards compliant browser is to download Firefox.

Another way would be to update iTunes....

Re:I smell bullshit at the IE blog

[Chris Snook]

IE8 is using ActiveX *internally* because it can't natively render the html OBJECT. Invoking ActiveX triggers XSS checks. The bottom line is that they technically pass the test, but many web designers will do things that really should work, but won't in IE8. It's not because MS is cheating, just that they haven't fully implemented this feature, and they're erring on the side of caution with their partial implementation. Regardless of standards compliance, they'll need to fix this before IE8 is released.

Re:On another note... Acid3

[Naughty Bob]

Did anyone else find it intriguing that a day or two Microsoft announces that they passed Acid2 with IE8, The Web Standard Project announces Acid3 which IE8 epically fails?

It's like this- The Web Standards Project is like a kindly teacher, who waited patiently for the slowest kid in the class to understand the current lesson, before moving on to the next one.