This is an app API, not an extension API, right?

Over to benwells@ for review.

-> raymes to have a look and +cc calamity for info

Re #2,
We would like to make something similar to chromeosInfoPrivate (https://cs.chromium.org/chromium/src/chrome/common/extensions/api/chromeos_info_private.json)
I think this should be an extension API.

We think it is more like an extension API. As Sheng-hao mentioned, we expect it as something like chromeosInfoPrivate API. Please correct me if I am wrong. Thanks.

Which extension is going to use it?  I thought this was going to be used by the camera app?

wtlee/rdevlin.cronin: Could we just expose the mojo API directly using the mojoPrivate extensions API? This would be whitelisted for the camera app specifically.

We'd like to move toward a world where we expose mojo APIs for built-in system apps, rather than private extensions APIs as a stepping stone to using WebUI+mojo for system apps.

rdevlin.cronin: 
After reading some documents, I am still not sure about the difference between extension API and platform app API. We have a Chrome Camera App, which I believe is a platform app, that wants to have chromeosCameraPrivate API that could be used like chromeosInfoPrivate API. Is chromeosInfoPrivate API also a platform app API? If so, then I think I was wrong in previous comment. The chromeosCameraPrivate API should also be a platform app API. Many thanks.

raymes: 
It would be great if we can have exposed mojo API on our Chrome Camera App. Could you provide some pointers about mojoPrivate so that I could check if we can use it for our usage. Many thanks.

Re #8 and #6,
The camera app *is* an extension. It's served through CWS and users can remove it easily. 

The camera app is a platform app, which is a bit different to an extension. Both are served through the webstore: https://developer.chrome.com/webstore/apps_vs_extensions

wtlee: I only know a little about it but sammc knows more. Here's a starting point: https://cs.chromium.org/chromium/src/extensions/common/api/mojo_private.idl?q=mojoprivate&sq=package:chromium&dr=C&l=5

Re #10,
Sorry I was wrong. Wei just showed me https://chromium.googlesource.com/chromium/src/+/master/extensions/docs/extension_and_app_types.md and yes our camera app is a platform app.

Yeah, apps vs extensions are confusing, but since the camera app is a platform app, this would be a platform app API.  On that note, passing back to raymes@ (per Ben's triage in #3).

Raymes:
> Could we just expose the mojo API directly using the mojoPrivate extensions API? This would be whitelisted for the camera app specifically.

Good question.  I think historically in the past, we've been hesitant to do this because mojo interfaces don't always have a security review from the perspective of the API being exposed to arbitrary renderer processes (and it's important to note that multiple extensions can share the same renderer process).  I think that's the primary reason we've had the guidance for "wrap your mojo service in an extension API that's well-defined".  If we can move more towards a world where we don't have to do that, I'd be very happy, because it would allow us to cut down on some of these private APIs.

I don't have (fundamental) concerns from an extensions standpoint, so if all the security folks are on board, we should see what it would take to make it happen.

Thanks Devlin. Leo mentioned this security concern.

Do component extensions run in their own process? Could we limit usage of the mojoPrivate API to component extensions? 

+meacer for thoughts from a security perspective also.

> Do component extensions run in their own process? Could we limit usage of the mojoPrivate API to component extensions?

Not currently - the only guarantee we have today is that "extensions only share with extensions", which could be any of component extensions, policy extensions, or user-level extensions.  One of my hopes and dreams is to segment extension processes more so that component extensions will never share with non-component extensions (and potentially further, e.g., policy will only ever share with policy).  This is technically possible, but no one (i.e., neither my team nor the site isolation team) currently has the bandwidth to tackle it.  If someone wanted to take this on, I'd be happy to support where I can.

Thanks Devlin - does that also apply to platform apps? 

> Thanks Devlin - does that also apply to platform apps? 

AFAIK, yes - though platform apps have a separate storage partition, they can still share processes with other apps (or extensions).  So the case of a compromised renderer is equally bad in all scenarios.

googleo: I think you mentioned there was a way to force extensions/apps into their own process that you were exploring? Do you have more details on that?

It's a few months ago. Devlin and Nasko had reviewed my IME Mojo service CL. 

The main concern from security is just what Devlin said in Comment 15 and 17.
And the 2 main questions we discussed: 

1, Whether an extension could use its one process, especially for a component extension.
2, What the severity if your Mojo service is hijacked by other extension.

Questoin 1 didn't work for us.
Question 2, our Mojo service runs in a standalone process with utility sandbox (which is kinda safe for security).
So we got LGTM finally after a few clarifications.  

But to resolve the security concern eventually, IMO
either we can guarantee our app/extension running in an exclusive process.
or we can provide a check on Mojo request level but not on the process level.

Thanks Leo.

+creis

Would it be hard to load component apps (or a whitelist of apps) in a dedicated process?

There seems to be code in https://cs.chromium.org/chromium/src/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc?rcl=dd3ead7798d4262965e3b26a42be07e9e87536bb&l=410 to isolate all extensions, but that doesn't seem to take effect?

Devlin: also, referring to your post in #13:

> Good question.  I think historically in the past, we've been hesitant to do this because mojo interfaces don't always have a security review from the perspective of the API being exposed to arbitrary renderer processes (and it's important to note that multiple extensions can share the same renderer process)

What if we just had an extensions/security OWNER for adding the API to mojoPrivate that verified that the API was safe enough that we're ok with it being potentially exposed to other extensions. I think that should save the same purpose as a full API review, but without all the work?

> Would it be hard to load component apps (or a whitelist of apps) in a dedicated process?

I talked with Charlie awhile back about this, because I think it'd be great if we could isolate component extensions (at least, so that they only share with other component extensions), and potentially also policy extensions.  In theory, we have all the necessary bits.  It's a non-trivial amount of work, but certainly feasible.  (It's also something I've debated whether the extensions team can just take on, but we don't have the bandwidth this quarter).

> What if we just had an extensions/security OWNER for adding the API to mojoPrivate that verified that the API was safe enough that we're ok with it being potentially exposed to other extensions. I think that should save the same purpose as a full API review, but without all the work?

Do we have the ability to restrict (on the browser side) which interfaces an extension can access through the mojoPrivate API?  I wasn't sure if this was the case, and if it's not, then it means that an extension with mojoPrivate could potentially access any interface (or maybe, any interface any individual extension could access?).

Otherwise, I think that's largely a security question. :)  One concern is that even extension API updates go through a security review (even if it's cursory), because its inherently understood that those APIs are exposed to extensions/renderer processes.  I'd be a little concerned about a situation where we add mojo interface Alpha, expose it to extension Gamma, and review the interface and decide it's secure.  Then later, we add new functionality to Alpha, and forget that it's exposed to Gamma, and have a potential security hole.  I don't know whether this is a validated concern or not.  If the security team is comfortable with being able to give extensions access to mojo services (after some kind of review process), I have no objections.

First: AFAIK mojoPrivate only provides mojoPrivate.requireAsync, which supports loading our old AMD-style mojom module resources. Only media router uses this, and I'm actually surprised it even still works (does it?). In any case, *no new code should ever use this API.*

For modern Mojo JS usage, we have a Mojo IDL enabled in certain script contexts[1]. New generated bindings just assume window.Mojo is present, and there is no special one-off module loading system required: you bring your own generated bindings and load them like you would load any other JS.

Today the Mojo IDL is enabled only for WebUI and web-tests (or with --enable-blink-features=MojoJS). We would need a way to enable it for certain extensions; I could for example imagine enabling it in any script context which belongs to an extension with mojoPrivate permission, assuming that's possible to deduce.

In any case, Mojo.bindInterface is then the singular entry point for scripts to request mojom interfaces from the browser, and this always results in the request reaching either RenderProcessHostImpl or RenderFrameHostImpl (depending on the |scope| given to bindInterface[2]), where we have enough context to make capability decisions. 

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/mojo/mojo.idl
[2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/mojo/mojo.idl?rcl=6dd060768d1c1183e0d29e422a2213f106d98299&l=9

Given the number of concerns here, I'm a little worried about holding up this API. I'll set up a meeting with Sheng-hao and Wei to discuss but it may be that for now we add chrome.chromeosCameraPrivate and look at migrating to WebUI in the future.

> I'd be a little concerned about a situation where we add mojo interface Alpha, expose it to extension Gamma, and review the interface and decide it's secure.  Then later, we add new functionality to Alpha, and forget that it's exposed to Gamma, and have a potential security hole.

I'm a bit confused but I'd like to understand more here. I'll set up a meeting to chat :)

> I could for example imagine enabling it in any script context which belongs to an extension with mojoPrivate permission, assuming that's possible to deduce.

Thanks rockot! There is code here that enables MojoJS if certain permissions are granted: https://cs.chromium.org/chromium/src/extensions/renderer/module_system.cc?q=WebContextFeatures::EnableMojoJS&sq=package:chromium&dr=C&l=184

But perhaps this is only exposed to extensions bindings and not extensions themselves? sammc/rockot: do you know? 

Oh, cool. No, that looks sufficient to expose the Mojo bindings to
extensions as long as they have access to mojoPrivate. I probably even knew
this was added at some point but I forgot :)

Just chatted with Sheng-hao and Wei. Here were the takeaways:
1) They would rather use a mojo API if possible because they're experimenting with how easy it is to add features to the camera app on Chrome OS and it's obviously easier not to implement an extensions API every time.
2) They'd like to make the camera app a component extension and have it released in-sync with Chrome releases which would mitigate any versioning issues with the mojo API. They'd rather not go all the way to WebUI for the time being but are open to it in the future. Sheng-hao is going to look into how to keep Chrome/camera app versions in-sync.
3) We still need to make sure we have an answer for the security concerns Devlin raised. I will follow up on those and make sure we adequately address them.

Sorry for missing this earlier.  Re: #20, Devlin summarized the issue where component extensions can share with normal extensions (issue 766267).  We'd like to fix this, but our team doesn't currently have the bandwidth.  The code you point to is for something slightly different; the tricky part is how to update the extension process sharing logic if some (limited but possibly large) number of extensions need to be in processes locked to a single extension.

I'll point out that *platform apps* already have dedicated processes and don't share with other extensions or apps, which might make that problem irrelevant here.  However, I'm not sure if the "component extension" mentioned in #26 is still going to be this type of app, or an actual extension that might share a process with others.

> I'll point out that *platform apps* already have dedicated processes 

Oh that's great news since they are currently using a platform app. When I said "component extension" in #26 I actually meant component *app* so we should be good on that front!

For reference, could you point us to the code that isolates platform apps? 

Sure.  Platform apps get their own StoragePartition (via ChromeContentBrowserClient::GetStoragePartitionConfigForSite and AppIsolationInfo::HasIsolatedStorage):
https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?rcl=737a81a1808c71e5b48e6e1c4706212ec08bb739&l=1223

As a result, RenderProcessHostImpl::IsSuitableHost doesn't allow them to share with other processes in a different StoragePartition:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_process_host_impl.cc?rcl=737a81a1808c71e5b48e6e1c4706212ec08bb739&l=3728

Re #26,

I have a question about the versioning concerns you raised in the meeting. It seems that we can utilize the [MinVersion=X] mechanism as mentioned https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md#versioned-structs ?
Is the mojo API in this doc different from what we are trying to adapt here?

Hmm, I think you're right.

rockot originally raised the concerns about avoiding releasing an app that uses mojo out of sync with Chrome. rockot: can you elaborate on your specific concerns here?

Yes you can use versioning, but this severely limits the mojom types you can use in your app. For example, it would be a major issue if you wanted to use any of the types defined in mojo/public/base/mojom (like Value, or String16, or TimeDelta, etc) because those types are not yet committed to any kind of stable format, and I think it would be unwise to do so at this time or to version them.

So you would have to guarantee that all your mojom dependencies are hermetic and stable/versioned. As soon as you need something for which we already have a suitable representation in the tree, you will have to duplicate it for your app if you want to avoid random changes breaking your app. This is undesirable for obvious reasons.

But this is all moot of it's a component app. If it's a component app you don't need to worry about any of that, and you don't need to (and please, don't) version any of your structs or interfaces.