Remove the event URL security check out of the renderer and into the browser.

Move the event URL security check out of the renderer and into the browser.

R=mpcomplete@chromium.org
BUG=55316
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=203024

[not at google - send to devlin, 2013-05-29 00:36:50]

Only 1 test failed when I removed the security check entirely -
ExtensionApiTest.MessagingEventURL - which is a little bit worrying. But from
what I can tell this check is equivalent and superior.

mpcomplete - extensions
cdn - extension_messages.h

[not at google - send to devlin, 2013-05-29 00:37:49]

P.S. relation to bug 55316 is that I ended up needing to remove this code
anyway, this was easy to break off.

[Matt Perry, 2013-05-29 01:39:07]

LGTM

Though I wonder if we should just add chrome-extension://ID/ to the list of
effective host access for an extension.

[not at google - send to devlin, 2013-05-29 18:08:34]

On 2013/05/29 01:39:07, Matt Perry wrote:
> LGTM
> 
> Though I wonder if we should just add chrome-extension://ID/ to the list of
> effective host access for an extension.

Yes I think you're right, and I'm surprised they're not already in the host
permissions for the extension, though I guess in practice it works because:
1 - we don't allow content script injection on chrome-extension:// URLs, even
their own (that said I've seen bugs about this, I can't remember the reason for
that, I guess it would open up an eval() work-around? any other reasons?)
2 - XHR is always from the chrome-extension:// URL so cross-origin permissions
don't come into play.

If you're ok with (1) changing then we can explicitly add it to the extension
set.

[Matt Perry, 2013-05-29 18:16:48]

On 2013/05/29 18:08:34, kalman wrote:
> On 2013/05/29 01:39:07, Matt Perry wrote:
> > LGTM
> > 
> > Though I wonder if we should just add chrome-extension://ID/ to the list of
> > effective host access for an extension.
> 
> Yes I think you're right, and I'm surprised they're not already in the host
> permissions for the extension, though I guess in practice it works because:
> 1 - we don't allow content script injection on chrome-extension:// URLs, even
> their own (that said I've seen bugs about this, I can't remember the reason
for
> that, I guess it would open up an eval() work-around? any other reasons?)
> 2 - XHR is always from the chrome-extension:// URL so cross-origin permissions
> don't come into play.
> 
> If you're ok with (1) changing then we can explicitly add it to the extension
> set.

I'm OK with (1) changing. The content scripts would not execute in the
extension's context, so it's not a direct eval workaround. I can't think of any
other reasons we would disallow it.

It doesn't have to be in this CL.

[not at google - send to devlin, 2013-05-29 18:18:11]

> The content scripts would not execute in the
> extension's context, so it's not a direct eval workaround.

Ah true, though our browser-side process checks wouldn't work.

[not at google - send to devlin, 2013-05-29 20:07:27]

ping @cdn

[Cris Neckar, 2013-05-29 20:13:39]

On 2013/05/29 20:07:27, kalman wrote:
> ping @cdn

IPC changes LGTM

[commit-bot: I haz the power, 2013-05-29 20:18:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kalman@chromium.org/15825008/14001

[commit-bot: I haz the power, 2013-05-30 00:35:24]

Change committed as 203024