Describing the `sandbox` workflow for extension developers.

Describing the `sandbox` workflow for extension developers.

BUG=117154
TEST=Just docs, no tests.

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

[Mike West, 2012-07-23 05:06:54]

Hello, Mihai, Aaron, and Meggin! Would you mind taking a look at this CL? I've
pulled the text out into
https://docs.google.com/a/google.com/document/d/1UL2VpFEm7KXerkRT-9t_7slRUjJA...
for ease of commenting.

I haven't rebuilt docs yet; I'll do so (and correct the TODO links in the doc)
once we're happy with the text.

CCing a few folks who might be interested (abarth, jschuh, erikkay).

Thanks!

-mike

[Mike West, 2012-07-23 05:08:43]

On 2012/07/23 05:06:54, Mike West (chromium) wrote:
> Hello, Mihai, Aaron, and Meggin! Would you mind taking a look at this CL? I've
> pulled the text out into
>
https://docs.google.com/a/google.com/document/d/1UL2VpFEm7KXerkRT-9t_7slRUjJA...
> for ease of commenting.
> 
> I haven't rebuilt docs yet; I'll do so (and correct the TODO links in the doc)
> once we're happy with the text.
> 
> CCing a few folks who might be interested (abarth, jschuh, erikkay).
> 
> Thanks!
> 
> -mike

To answer the inevitable question that my email left untouched: this CL adds
documentation regarding the sandboxing workflow we're offering extension and app
developers. Specifically, it wraps Handlebars in a trivial messaging API just as
a toy example, but it's a toy that I think would get many developers 80% of the
way to where they want to be.

Thanks!

-mike

[Mihai Parparita -not on Chrome, 2012-07-25 03:00:57]

LGTM

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
File chrome/common/extensions/docs/examples/howto/sandbox/sandbox.html (right):

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
chrome/common/extensions/docs/examples/howto/sandbox/sandbox.html:34: case
'new':
This doesn't seem to be used.

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
File chrome/common/extensions/docs/static/sandboxingEval.html (right):

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
chrome/common/extensions/docs/static/sandboxingEval.html:1: <div
id="pageData-name" class="pageData">Using eval in Chrome Extensions.
Safely.</div>
This isn't in the generated docs. To get that to work, I believe you need touch 
docs/{extensions|apps}/sandboxingEval.html (see
http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/common/extensions/d...)

I think this should be in both the apps and extensions doc families, since both
have the same CSP constraints.

Maybe have a paragraph at the start or end saying something like "The techniques
described in this page apply to both extensions and apps. For the sake of
brevity, the rest of the page will use "extension" to refer to both item types."

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
chrome/common/extensions/docs/static/sandboxingEval.html:64: be moved to a
<em>unique origin(#TODO: link)</em>, and will be denied access
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#san...
is the most appropriate spec link I could find about unique origins. Adam may
know of something better.

https://chromiumcodereview.appspot.com/10810054/diff/1/chrome/common/extensio...
chrome/common/extensions/docs/static/sandboxingEval.html:153: directly for
rendering. The rendered HTML will be passed back to the Event
You may want to mention that you can't pass back the template function itself
via postMessage (or in general, anything else that can't be serialized).

[Mike West, 2012-07-26 12:51:46]

I've addressed your feedback, Mihai, and incorporated some of Meggin's comments
as well. The built documentation is staged at
http://www.corp.google.com/~mkwst/no_crawl/docs/extensions/sandboxingEval.html
and http://www.corp.google.com/~mkwst/no_crawl/docs/apps/sandboxingEval.html

If no other comments pop up by tomorrow, I'll fix the TODO links and land this
then.

Thanks!

http://codereview.chromium.org/10810054/diff/1/chrome/common/extensions/docs/...
File chrome/common/extensions/docs/static/sandboxingEval.html (right):

http://codereview.chromium.org/10810054/diff/1/chrome/common/extensions/docs/...
chrome/common/extensions/docs/static/sandboxingEval.html:64: be moved to a
<em>unique origin(#TODO: link)</em>, and will be denied access
On 2012/07/25 03:00:57, Mihai Parparita wrote:
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#san...
> is the most appropriate spec link I could find about unique origins. Adam may
> know of something better.

That's good enough, I think. :)

http://codereview.chromium.org/10810054/diff/1/chrome/common/extensions/docs/...
chrome/common/extensions/docs/static/sandboxingEval.html:153: directly for
rendering. The rendered HTML will be passed back to the Event
On 2012/07/25 03:00:57, Mihai Parparita wrote:
> You may want to mention that you can't pass back the template function itself
> via postMessage (or in general, anything else that can't be serialized).

Done.

[jschuh, 2012-07-26 13:14:55]

I don't know this workflow very well. Probably best to get feedback from
@jorgelo, since he's spent quite a bit of time on it.

[Mike West, 2012-07-26 13:16:22]

On 2012/07/26 13:14:55, Justin Schuh wrote:
> I don't know this workflow very well. Probably best to get feedback from
> @jorgelo, since he's spent quite a bit of time on it.

Alright. CCing Jorge. Hi!

[Mihai Parparita -not on Chrome, 2012-07-26 17:51:57]

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
File chrome/common/extensions/docs/static/sandboxingEval.html (right):

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/static/sandboxingEval.html:187: <a
href='https://github.com/GoogleChrome/chrome-app-samples/blob/master/regex-tester/'>Regex
Tester</a>
https://github.com/GoogleChrome/chrome-app-samples/tree/master/eval-in-iframe is
my sample. It does basically what your sample does, except in a less
nice/structured way, so I'm not sure it's worth pointing out.

[Jorge Lucangeli Obes, 2012-07-26 18:28:05]

What happened with resource loading inside sandboxed iframes? At some point we
needed to whitelist those in web_accessible_resources and add
chrome-extension:// to CSP.

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
File chrome/common/extensions/docs/apps/sandboxingEval.html (right):

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/apps/sandboxingEval.html:208: <a
href="http://angularjs.com/">Angular.js</a>) support CSP out of the box,
.org

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/apps/sandboxingEval.html:343: of the extension's
UI. Inserting it via <code>innerHTML</code> doesn't pose a
The risks introduced by innerHTML don't completely disappear, since you could
inject other types of content, not necessarily blocked by the default CSP in
manifest v2.

It is, of course, greatly reduced. We probably can keep the wording as-is, but
it's good to keep this in mind.

[Mihai Parparita -not on Chrome, 2012-07-26 18:40:24]

On Thu, Jul 26, 2012 at 11:28 AM, <jorgelo@chromium.org> wrote:

> What happened with resource loading inside sandboxed iframes? At some
> point we
> needed to whitelist those in web_accessible_resources and add
> chrome-extension:// to CSP.
>

At least with the built-in sandbox support, that should not be necessary
(the web_accessible_resources checks pass, since the sandboxed resource is
still a request from one chrome-extension:// page to anoter).

Mihai

[Jorge Lucangeli Obes, 2012-07-26 18:41:43]

On 2012/07/26 18:40:24, Mihai Parparita wrote:
> On Thu, Jul 26, 2012 at 11:28 AM, <mailto:jorgelo@chromium.org> wrote:
> 
> > What happened with resource loading inside sandboxed iframes? At some
> > point we
> > needed to whitelist those in web_accessible_resources and add
> > chrome-extension:// to CSP.
> >
> 
> At least with the built-in sandbox support, that should not be necessary
> (the web_accessible_resources checks pass, since the sandboxed resource is
> still a request from one chrome-extension:// page to anoter).

Cool, that's what I thought, we were doing this with a regular <iframe sandbox>
tag.

[Mike West, 2012-07-27 07:58:56]

Thanks for your feedback, folks. I've addressed them, and I'll land this as-is.

I think we should probably merge this back through to stable. I'll do that in a
separate bug.

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
File chrome/common/extensions/docs/apps/sandboxingEval.html (right):

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/apps/sandboxingEval.html:208: <a
href="http://angularjs.com/">Angular.js</a>) support CSP out of the box,
On 2012/07/26 18:28:05, Jorge Lucangeli Obes wrote:
> .org

Done.

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/apps/sandboxingEval.html:343: of the extension's
UI. Inserting it via <code>innerHTML</code> doesn't pose a
On 2012/07/26 18:28:05, Jorge Lucangeli Obes wrote:
> The risks introduced by innerHTML don't completely disappear, since you could
> inject other types of content, not necessarily blocked by the default CSP in
> manifest v2.
> 
> It is, of course, greatly reduced. We probably can keep the wording as-is, but
> it's good to keep this in mind.

Good point. We should be careful about the security promises we make here. I'll
rephrase.

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
File chrome/common/extensions/docs/static/sandboxingEval.html (right):

http://codereview.chromium.org/10810054/diff/8001/chrome/common/extensions/do...
chrome/common/extensions/docs/static/sandboxingEval.html:187: <a
href='https://github.com/GoogleChrome/chrome-app-samples/blob/master/regex-tester/'>Regex
Tester</a>
On 2012/07/26 17:51:57, Mihai Parparita wrote:
> https://github.com/GoogleChrome/chrome-app-samples/tree/master/eval-in-iframe
is
> my sample. It does basically what your sample does, except in a less
> nice/structured way, so I'm not sure it's worth pointing out.

Alright. Thanks. :)

I'll point to Jorge's I/O talk instead. The document viewer is a good example
not only of sandboxing, but also least privilege.

[Mike West, 2012-07-27 08:07:20]

On 2012/07/27 07:58:56, Mike West (chromium) wrote:
> I think we should probably merge this back through to stable. I'll do that in
a
> separate bug.

I meant beta, not stable.