Remove the "content_script" context from a number of APIs that shouldn't be

Remove the "content_script" context from a number of APIs that shouldn't be
exposed to content scripts.

In some cases this dates way back pre-features to when they were incorrectly
first added with an {"unprivileged": true} annotation, like runtime.reload().

R=asargent@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=282153

[not at google - send to devlin, 2014-07-09 03:02:24]

I noticed this because Freddy sent me a patch which generates the APIs available
to content scripts, and it was surprising what it showed up.

[not at google - send to devlin, 2014-07-09 03:06:54]

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
File extensions/common/api/_api_features.json (left):

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
extensions/common/api/_api_features.json:81: },
I will need to send out a PSA to the extensions mailing list about these
changes.

[asargent_no_longer_on_chrome, 2014-07-09 18:09:47]

mostly lg with one question

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
File extensions/common/api/_api_features.json (left):

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
extensions/common/api/_api_features.json:81: },
On 2014/07/09 03:06:54, kalman wrote:
> I will need to send out a PSA to the extensions mailing list about these
> changes.

Is there a downside to allowing runtime.reload and runtime.requestUpdateCheck to
be called from content scripts? Anything worse than just potential Denial Of
Service attacks if attacker-controlled script ran in the content script's world?

[not at google - send to devlin, 2014-07-09 18:14:26]

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
File extensions/common/api/_api_features.json (left):

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
extensions/common/api/_api_features.json:81: },
On 2014/07/09 18:09:47, Antony Sargent wrote:
> On 2014/07/09 03:06:54, kalman wrote:
> > I will need to send out a PSA to the extensions mailing list about these
> > changes.
> 
> Is there a downside to allowing runtime.reload and runtime.requestUpdateCheck
to
> be called from content scripts? Anything worse than just potential Denial Of
> Service attacks if attacker-controlled script ran in the content script's
world?
> 
> 

I think anything that only makes sense to be mediated from a single choke point
should be in the background page?

[asargent_no_longer_on_chrome, 2014-07-09 19:29:25]

On 2014/07/09 18:14:26, kalman wrote:
>
https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
> File extensions/common/api/_api_features.json (left):
> 
>
https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
> extensions/common/api/_api_features.json:81: },
> On 2014/07/09 18:09:47, Antony Sargent wrote:
> > On 2014/07/09 03:06:54, kalman wrote:
> > > I will need to send out a PSA to the extensions mailing list about these
> > > changes.
> > 
> > Is there a downside to allowing runtime.reload and
runtime.requestUpdateCheck
> to
> > be called from content scripts? Anything worse than just potential Denial Of
> > Service attacks if attacker-controlled script ran in the content script's
> world?
> > 
> > 
> 
> I think anything that only makes sense to be mediated from a single choke
point
> should be in the background page?

Ok, that makes sense. The question we should weigh is whether this is important
enough that it warrants a breaking change or not. I'd expect few developers to
be affected in this case, but every time we break anything for a developer that
costs us something.

[not at google - send to devlin, 2014-07-09 20:59:24]

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
File extensions/common/api/_api_features.json (left):

https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
extensions/common/api/_api_features.json:81: },
On 2014/07/09 18:14:25, kalman wrote:
> On 2014/07/09 18:09:47, Antony Sargent wrote:
> > On 2014/07/09 03:06:54, kalman wrote:
> > > I will need to send out a PSA to the extensions mailing list about these
> > > changes.
> > 
> > Is there a downside to allowing runtime.reload and
runtime.requestUpdateCheck
> to
> > be called from content scripts? Anything worse than just potential Denial Of
> > Service attacks if attacker-controlled script ran in the content script's
> world?
> > 
> > 
> 
> I think anything that only makes sense to be mediated from a single choke
point
> should be in the background page?

We've never documented it as being available in content scripts, and I don't
want to document it as such of course. We could always write code to hide those
functions from appearing in that list I suppose, and then add UMA to track when
they're being called. I'm not having much luck on codesearch.

[asargent_no_longer_on_chrome, 2014-07-09 21:16:37]

On 2014/07/09 20:59:24, kalman wrote:
>
https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
> File extensions/common/api/_api_features.json (left):
> 
>
https://codereview.chromium.org/375173002/diff/20001/extensions/common/api/_a...
> extensions/common/api/_api_features.json:81: },
> On 2014/07/09 18:14:25, kalman wrote:
> > On 2014/07/09 18:09:47, Antony Sargent wrote:
> > > On 2014/07/09 03:06:54, kalman wrote:
> > > > I will need to send out a PSA to the extensions mailing list about these
> > > > changes.
> > > 
> > > Is there a downside to allowing runtime.reload and
> runtime.requestUpdateCheck
> > to
> > > be called from content scripts? Anything worse than just potential Denial
Of
> > > Service attacks if attacker-controlled script ran in the content script's
> > world?
> > > 
> > > 
> > 
> > I think anything that only makes sense to be mediated from a single choke
> point
> > should be in the background page?
> 
> We've never documented it as being available in content scripts, and I don't
> want to document it as such of course. We could always write code to hide
those
> functions from appearing in that list I suppose, and then add UMA to track
when
> they're being called. I'm not having much luck on codesearch.

Ok, that's a good point. On
https://developer.chrome.com/extensions/content_scripts we explicitly state that
most APIs cannot be called from content scripts, and on
https://developer.chrome.com/extensions/extension we don't mention these
functions as being available in the list of things that are available. 

So lgtm.

[not at google - send to devlin, 2014-07-09 21:59:25]

thanks

[not at google - send to devlin, 2014-07-09 21:59:27]

The CQ bit was checked by kalman@chromium.org

[commit-bot: I haz the power, 2014-07-09 22:00:34]

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

[commit-bot: I haz the power, 2014-07-09 22:47:08]

Change committed as 282153