Why IE XDomainRequest does not send Referer header

Question

When I am doing CORS in IE via XDomainRequest object, the Referer HTTP header is not being sent. Is there any official documentatation covering this? I fully understand, that relying on Referer HTTP header is basicaly wrong idea, however without hard evidence I am stuck here, and not able to prove our architect wrong.

Example dump:

IE Request

GET http://example.com/some/url HTTP/1.1
Accept: */*
Origin: http://another.domain.com
Accept-Language: sk-SK
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)
Host: example.com
Connection: Keep-Alive
Pragma: no-cache

Chrome Request

GET http://example.com/some/url HTTP/1.1
Host: example.com
Connection: keep-alive
Origin: http://another.domain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36
Accept: */*
Referer: http://another.domain.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sk-SK,sk;q=0.8,cs;q=0.6,en-US;q=0.4,en;q=0.2

Answer 1

Eric Law (former IE program manager) answered this in his blog post, as expected limitation comming back from IE8 times:

we wanted to ensure that the XDomainRequest object would not allow an attacker to issue a request that a HTML Form could not issue. This is important because the Access-Control-Allow-Origin header isn’t available until after the response is returned, so there’s no way to tell before the request is issued whether or not the server is willing to accept cross-domain HTTP requests. Without these restrictions, a “Fire and Forget” CSRF attack could take place against a legacy server, even if the server doesn’t return the Access-Control-Allow-Origin header

http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx