Add a new webstorePrivate API to show a permission prompt for delegated installs

chrome/browser/resources/webstore_app/manifest.json

 {
   "key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtl3tO0osjuzRsf6xtD2SKxPlTfuoy7AWoObysitBPvH5fE1NaAA1/2JkPWkVDhdLBWLaIBPYeXbzlHp3y4Vv/4XG+aN5qFE3z+1RU/NqkzVYHtIpVScf3DjTYtKVL66mzVGijSoAIwbFCC3LpGdaoe6Q1rSRDp76wR6jjFzsYwQIDAQAB",
   "name": "Web Store",
-  "version": "0.2",
+  "version": "0.3",
   "description": "Chrome Web Store",
   "icons": {
     "16": "webstore_icon_16.png",
     "128": "webstore_icon_128.png"
   },
   "app": {
     "launch": {
       "web_url": "https://chrome.google.com/webstore"
     },
     "urls": [
-      "https://chrome.google.com/webstore"
+      "https://chrome.google.com/webstore",
+      "https://www.google.com/settings/chrome/manage",

[Marc Treib, 2015/02/04 12:34:25]

We will need to call the new function from our dashboard (hosted on
accountcentral) as well as from the web store.

[not at google - send to devlin, 2015/02/04 21:28:29]

So the problem is that |urls| actually gives scope to the entire domain. So this
will make the scope of the webstorePrivate API... www.google.com. That can't
happen. Can you at least make this settings.google.com?

If not - and perhaps, even if so - I need to think about this. We may need to
pull this all into another namespace (like managedInstallPrivate or something)
to avoid leaking the entire webstorePrivate API to anything other than
webstore.google.com.

[Marc Treib, 2015/02/05 10:33:37]

Woah, that's quite unexpected! Why can I even specify a full URL if the whole
domain will be whitelisted anyway?
Anyway: I agree allowing all of www.google.com looks like a bad idea.
Unfortunately, our dashboard doesn't have its own subdomain yet. We're planning
to move to chrome.google.com, but that's probably still a ways out. I'll
investigate and see if I can accelerate that.
But then, we wouldn't need any extra entries here, since all of
chrome.google.com is whitelisted anyway, correct?
It's actually chrome.google.com, but afaik only the webstore is hosted there so
far.

[not at google - send to devlin, 2015/02/05 17:34:20]

That's a good question. One difference is that the UI behaves differently. If
you were to go to www.google.com then www.google.com would have these
bindings[*], but the search app's icon in the taskbar wouldn't be lit up. It's
only lit up on www.google.com. The webstore's icon would only be lit up on
www.google.com/settings/chrome/family.

Which reminds me - I don't think that the scope of the webstore app should
include anything other than chrome.google.com/webstore. There are places in the
code where the webstore domain is treated specially, for example, extensions
aren't allow to run content scripts on webstore.google.com. You'd need to apply
the same logic to here as well.

Which is why - despite the refactoring you did - I think this does need to be in
its own API, one that is carefully controlled. Even that... not fantastic.

Best situation IMO would be to continue to have the installation served off
chrome.google.com/webstore, but set up some sneaky redirects so that
installation can be triggered from the family console? Is that possible?
Yeah, you wouldn't need any additional rules here if you were to host on
chrome.google.com.

[Marc Treib, 2015/02/06 13:58:17]

I see, thanks. Still somewhat surprising that the whole host will be
whitelisted, but oh well.
I've removed the extra URLs again. We hope to be moving our dashboard to
chrome.google.com by the end of the quarter, which will make all this moot. For
testing before that, we can easily work around the restriction locally.
[I'll upload a new patchset after the refactoring/cleanup CLs.]
Well, the scope of the webstore app already is all of chrome.google.com :)
Note that the installation itself is not triggered by this API at all; all it
does is show a permission prompt. The actual installation is handled
server-side.

[not at google - send to devlin, 2015/02/06 18:27:55]

I agree. There are reasons, which are strictly correct, but IMO impractical for
a couple of reasons.
SGTM.
Oh, right - good point. Definitely makes this less of an issue.

+      "https://www.google.com/settings/chrome/family"
     ]
   },
   "permissions": [
     "webstorePrivate",
     "management",
     "system.cpu",
     "system.display",
     "system.memory",
     "system.network",
     "system.storage"
   ]
 }