FYI: we eventually want to move the mojo:media service out of the browser process as a standalone mojo service.

It doesn't matter where mojo:media runs. You can still use BrowserContext's
Connector (or the renderer's ChildThreadImpl::GetMojoShellConnection(),
which uses the same user ID as its browser-side BrowserContext) to connect
to it.

The Connector you use to connect to it really only determines the identity
mojo:media sees on the incoming connection, and determines whether the
connection is to a new instance or an existing instance (e.g. if there's
already an instance of the service running for that user ID).

rockot@: If mojo:media were a standalone mojo service (not an embedded service in browser/gpu process), does this mean launching a new process for each client with unique user ID?

The only thing it means strictly is that the registered service request
handler
<https://cs.chromium.org/chromium/src/content/browser/mojo/mojo_shell_context.cc?rcl=0&l=287>
will be invoked once for each client with a unique user ID.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f78815009d7a7801126d30a76c71a2554ea86f93

commit f78815009d7a7801126d30a76c71a2554ea86f93
Author: slan <slan@chromium.org>
Date: Thu Aug 18 16:59:59 2016

Use the process-level MojoShellConnection to connect to mojo:media.

The interface provided by mojo:media, media::mojom::MediaService, is
registered in mojo_shell_context.cc on the browser process
MojoShellConnection. Use this ShellConnection to connect to this
interface (rather than the connection for the BrowserContext).

BUG=638950

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2255223002
Cr-Commit-Position: refs/heads/master@{#412859}

[modify] https://crrev.com/f78815009d7a7801126d30a76c71a2554ea86f93/content/browser/frame_host/render_frame_host_impl.cc

+dcheng from security's perspective.

For comparison, when hosting the desktop CDM using pepper plugin, we'll have a CDM process per CDM/plugin type, and per user profile (BrowserContext). Now when hosting the CDM using mojo CDM (media/cdm service), we have a CDM process per CDM type (see  issue 664364 ). But since we use the browser process connector, all user profile (BrowserContext) shares the same CDM process for one CDM type.

dcheng: Is this a concern from security/privacy's perspective? The CDM process is sandboxed. Each CDM instance runs in it's own context in the CDM process. They talk to the browser to access resources, where the browser side services are bound to RenderFrameHost (see FrameServiceBase).

rockot: As you pointed out, I could easily move our code to use the BrowserContext Connector, so that we'll have different user ID based on different BrowserContext. But as we discussed, I am now using different user ID for different CDM types because using different instance ID didn't work. When I switch to using BrowserContext connector, shall I switch back to use different instance ID for different CDM types? Will that work?

Using a different instance ID for different CDM types *will* work now, and
should be preferred. The issue before was that we did not have a proper
support for singleton services, so we were tripping over the lack of a
content_packaged_services instance with a matching instance ID.

Since then, we have introduced real singleton services, and
content_packaged_services is one.

rockot: Cool, then I'll switch back to use instance ID.

Any comment on what service should use the BrowserContext connector instead of the browser process connector? Or should we always prefer the former to avoid potential cross-user-profile issues?

Totally your call there, as I don't understand the security or privacy
constraints of your use case. In general the deciding factor is: do you
want different profiles using the service to have their service-side state
isolated from each other, or does it not really matter?

Resource constraints (like too many processes) are probably less concerning
here given that multiprofile use is uncommon, and I would expect that to be
especially true on mobile.

dcheng: See #7, any comments?

dcheng: kindly ping :)

dcheng: kingly ping!

+jam since you are familiar with the old pepper model. See #7 and https://chromium-review.googlesource.com/c/chromium/src/+/952469 for existing discussion. Thanks!