people.mozilla.org is not part of our bounty program because it's used for developers sharing experiments and tests. Content there is of variable quality and given the same-origin policy (a flaw in one employee's files puts them all at risk) our policy is not to put sensitive data on that server.
This report does, however, point out a potential problem: mwargers is no longer an employee, and in the past we removed these files when people left (with exceptions -- some people's files were preserved because others relied on their testcases).
Jeff: were mwargers' people.m.o files left active on purpose or has the auto-cleanup process broken down?

Hello Jonathan,
The vulnerability is caused by, the code below doesn't set the 'event.origin == "http://site-a.com"':
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
var r=document.getElementById('result');
r.innerHTML += event.origin + '<br>';
r.innerHTML += event.source + '<br>';
r.innerHTML += event.data + '<br>';
}
So any webpage under any domain could inject information into the web page by using the code below:
<iframe name="siteb" src="http://site-b.net"></iframe>
<button onclick="frames[0].postMessage('<img src=x onerror=alert(document.cookie)','*')">Send Attack</button>
The correct way to use postMessage is:
window.addEventListener('message', writeMessage, false);
function writeMessage(event) {
if (event.origin == "http://site-a.com") { // only site-a.com could postMessage to this webpage
document.getElementById("message").innerHTML = event.data;
} else {
return;
}
}
Nevertheless, the "r.innerHTML += event.source + '<br>';" here will cause an error in javascript code which will prevent the eval payload from being innerHTMLed into the vulnerable page, as a result, it couldn't trigger a DOM-XSS in fact. So, theoretically, it is just a tiny javascript code flaw, and the risk will be very low. Maybe we could change the status to 'Resolved' -> 'Won't Fix'.
Nonetheless, as Daniel's saying goes, although the people.mozilla.org is not part of our bounty program. but the XSS or other vulnerabilities on the web pages still could trigger low security impacts. Maybe, the expired webpages should be deleted.
Thank you so much for your prompt reply. Also, many thanks to Daniel, thank you!
Regrads.

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #4)
> :digi - do you know anything about this nuking process of old content from
> people.mo when people leave Mozilla? From the sounds of it, this content
> should have been removed when mwargers left Mozilla.
Ah, this is a bug. Since people moved to C7 the system account uid threshold is 1000 vs 500 on R6. Puppet wont purge system users. mwargers's uid was 664, so despite being disabled his account wasn't automatically purged from people.
It's a known issue and we did renumber folks in IT to avoid this very problem but as you can see other employees are effected. The UID_MIN issue can be tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1243727. Getting all these folks changed is non-trivial, but, I think I have a workaround. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1302426 to track the implementation of that
This would of been caught in the exit checklist if the user were in IT, but, we don't have a SOP for non-IT exits. EUS handles those.
The URL has been taken down.