I'm not 100% sure about this issue, but I am raising it for further investigation. My concern relates to the registration for system messages here[1]. The child(SystemMessageManager.js) tells the parent (SystemMessageInternal.js) which manifest and innerWindowID should register for a certain message. If the child process is compromised, I am concerned that the child could fake the manifestURL and then recieve messages intended for other applications. There is a permissions check [2] but this is done based on the manifestURI and the target pageURI, not the InnerWindowID. (e.g what happens if child said its manifest was the the URL of the SMS app, would it receive SMS related system messages?) My thought was that there needs to a check in the parent that the manifest is the correct one for this app. Or don't even supply the manifest from the child, just let the parent get it from the message? [1] http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageManager.js#210 [2]http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#371

Likewise, there may be other risks here such as with |SystemMessageManager:GetPendingMessages|. The type, URI and manifest could be spoofed, to get pending messages for any page. And perhaps combined with |SystemMessageManager:Unregister| the child could guarantee that message would be waiting to be delivered. If these are actually issues, then all of the messages in the API will need to be reviewed to ensure they validate parameters from the child properly. But as I said, I am a little vague on the exact use of this code - needs info from someone who knows this code better.

Is this necessary for v1? If so, please nominate for b-b?

Gene: This sounds like a bug for you :)

Very glad to take it but I'm afraid I won't be able to have 100% full time to fix that because I'm going to be on a vacation (12/24~1/3). I'll still try to get it fixed before C3 as possible as I can. No worries!

This bug can be solved based on the support of Bug 821671, which provides a new utility function |aMessage.target.assertContainApp(aMessage.json.manifestURL)| to check if the message carries the right manifest URL belonging to that child.

Note that this bug depends on the support of a new utility function .AssertContainApp() at Bug 821671. We need to check if the message carries the correct manifest URL that exactly belongs to the child process.

Any reason not to land this?

(In reply to JP Rosevear [:jpr] from comment #7) > Any reason not to land this? This patch is actually on top of bug 821671, so it'd be better to check that in first.

r=sicking

Try: https://tbpl.mozilla.org/?tree=Try&rev=a8d766fda7bd