I found the following info on this site: devguru. More concretely, here's the quote:
This property sets or returns the
domain name of the server from which
the document originated. This defaults
to the domain name of the server that
the document was retreived from, but
can be changed to a suffix (and only a
suffix) of this name. This allows the
sharing of script properties, security
allowing, between documents delivered
from different servers providing they
share the same domain suffix.
It seems to me that it allows cross site scripting for same domain (even if subdomain is different).
I would suppose that if you don't touch document.domain, the js engine only allows other javascripts from same domain. With that property, you'll be able to deploy to other sub-domains like the orbited docs state.
When trying to do cross-subdomain/port comet, the iframe needs to have the same document.domain value as the parent frame. Unfortunately, the browser stores the domain name AND port internally for the original document.domain value. But the getter and setter in javascript knows nothing about the port. So the problem is this: if the top frame document.domain is ('example.com', 80), and the bottom frame is ('comet.example.com', 80), how do you get the bottom frame to be ('example.com', 80) as well?
You can't, as changing the hostname portion will necessarily cause the port to be set to null, so the best you can do is ('example.com', null) in the bottom frame. So the top frame also needs to be set to that value, and setting document.domain=document.domain does just that. It changes the internal representation in the browser from ('example.com', 80) to ('example.com', null) and then everything matches up and cross-port/subdomain frame communication works.
Browsers distinguish between
(a) document.domain when not explicitly set
and
(b) document.domain when explicitly set
... even if they return the same value.
Explicitly setting the value indicates intent to "cooperate" with a script on another subdomain (under the same parent domain).
If BOTH the parent page AND the external script explicitly set document.domain to the same value, the same-origin policy restriction may be bypassed and each script may access all the (otherwise restricted) objects and properties of each others' contexts.
The document.domain pulls a default from the actual URL if not explicitly set. Browsers will record if document.domain has come as a default from the URL or if it was explicitly set. Both must be a default for the same domain or both must be explicitly set to the same domain for this to work. If one is default and one is explicitly set, both matching if read, the two pages will still be forbidden from talking with each other.