media: Add mojo MediaPermission service

media: Add mojo MediaPermission service

The CDM in the MojoMediaApplication needs to check media permissions in
some cases. Today in the non-mojo world the check is done in the browser
process in some ad-hoc places, in BrowserCdmManager on Android and
ChromeCast, and in PlatformVerificationFlow on ChromeOS. Now with
MojoMediaApplication, we have a unified way to host out-of-process CDMs,
we'd like to have a unified way to check the permission as well, e.g.
passing the MediaPermission to the CDM running in MojoMediaApplication.

Note that our CDMs know neither content nor mojo. So to request
permission, it can only talk to media::MediaPermission. Since permission
is hosted in the browser in content, we need some extra plumbing.

With this CL, now we have these interfaces and classes:
- media::MediaPermission: C++ interface in media/
- (new) media::interfaces::MediaPermission: mojo interface in media/
- content::mojom::PermissionService: mojo interface in content/
- content::PermissionServiceContext:
    hosts content::mojom::PermissionService
- (moved) content::MediaPermissionDispatcher:
    conent::mojom::PermissionService -> media::MediaPermission
- (new) media::MediaPermissionImpl:
    media::MediaPermission -> media::interfaces::MediaPermission
- (new) media::MojoMediaPermission:
    media::interfaces::MediaPermission -> media::MediaPermission

This is how we plumb media::MediaPermission to a CDM running in the
MojoMediaApplication:

PermissionServiceContext -> MediaPermissionDispatcher ->
MediaPermissionImpl -> mojo IPC -> MojoMediaPermission -> CDM

In the next CL:
- Create MojoMediaPermission in AndroidMojoMediaClient.
- Pass MojoMediaPermission to AndroidCdmFactory and MediaDrmBridge.
- Check protected media identifier permission in MediaDrmBridge.

An alternative solution is to create a MediaPermissionDispatcher in the
process where the MojoMediaApplication is hosted, and plumb it through
to the CDM. With the ServiceRegistry in GPU process, this is prototyped
in https://chromiumcodereview.appspot.com/1837143002/. It seems to have
less layers involved. However, this solution is not generic. We need to
do this differently when hosting the MojoMediaApplication in different
processes. Therefore, the current approach is preferred.

BUG=559839
TEST=Manually tested to verify the permission check is plumbed through.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

[xhwang, 2016-03-30 06:58:20]

Description was changed from

==========
media: Add mojo MediaPermission service

The CDM in the MojoMediaApplication needs to check media permissions in
some cases. Today in the non-mojo world the check is done in the browser
process in some ad-hoc places, in BrowserCdmManager on Android and
ChromeCast, and in PlatformVerificationFlow on ChromeOS. Now with
MojoMediaApplication, we have a unified way to host out-of-process CDMs,
we'd like to have a unified way to check the permission as well, e.g.
passing the MediaPermission to the CDM running in MojoMediaApplication.

Note that our CDMs know neither content nor mojo. So to request
permission, it can only talk to media::MediaPermission. Since permission
is hosted in the browser in content, we need some extra plumbing.

With this CL, now we have these interfaces and classes:
- media::MediaPermission: C++ interface in media/
- (new) media::interfaces::MediaPermission: mojo interface in media/
- content::mojom::PermissionService: mojo interface in content/
- content::PermissionServiceContext:
    hosts content::mojom::PermissionService
- (moved) content::MediaPermissionDispatcher:
    conent::mojom::PermissionService -> media::MediaPermission
- (new) media::MediaPermissionImpl:
    media::MediaPermission -> media::interfaces::MediaPermission
- (new) media::MojoMediaPermission:
    media::interfaces::MediaPermission -> media::MediaPermission

This is how we plumb media::MediaPermission to a CDM running in the
MojoMediaApplication:

PermissionServiceContext -> MediaPermissionDispatcher ->
MediaPermissionImpl -> mojo IPC -> MojoMediaPermission -> CDM

In the next CL:
- Create MojoMediaPermission in AndroidMojoMediaClient.
- Pass MojoMediaPermission to AndroidCdmFactory and MediaDrmBridge.
- Check protected media identifier permission in MediaDrmBridge.

An alternative solution is to create a MediaPermissionDispatcher in the
process where the MojoMediaApplication is hosted, and plumb it through
to the CDM. With the ServiceRegistry in GPU process, this is prototyped
in https://chromiumcodereview.appspot.com/1837143002/. It seems to have
less layers involved. However, this solution is not generic. We need to
do this differently when hosting the MojoMediaApplication in different
processes. Therefore, the current approach is preferred.

BUG=559839
TEST=Manually tested to verify the permission check is plumbed through.
==========

to

==========
media: Add mojo MediaPermission service

The CDM in the MojoMediaApplication needs to check media permissions in
some cases. Today in the non-mojo world the check is done in the browser
process in some ad-hoc places, in BrowserCdmManager on Android and
ChromeCast, and in PlatformVerificationFlow on ChromeOS. Now with
MojoMediaApplication, we have a unified way to host out-of-process CDMs,
we'd like to have a unified way to check the permission as well, e.g.
passing the MediaPermission to the CDM running in MojoMediaApplication.

Note that our CDMs know neither content nor mojo. So to request
permission, it can only talk to media::MediaPermission. Since permission
is hosted in the browser in content, we need some extra plumbing.

With this CL, now we have these interfaces and classes:
- media::MediaPermission: C++ interface in media/
- (new) media::interfaces::MediaPermission: mojo interface in media/
- content::mojom::PermissionService: mojo interface in content/
- content::PermissionServiceContext:
    hosts content::mojom::PermissionService
- (moved) content::MediaPermissionDispatcher:
    conent::mojom::PermissionService -> media::MediaPermission
- (new) media::MediaPermissionImpl:
    media::MediaPermission -> media::interfaces::MediaPermission
- (new) media::MojoMediaPermission:
    media::interfaces::MediaPermission -> media::MediaPermission

This is how we plumb media::MediaPermission to a CDM running in the
MojoMediaApplication:

PermissionServiceContext -> MediaPermissionDispatcher ->
MediaPermissionImpl -> mojo IPC -> MojoMediaPermission -> CDM

In the next CL:
- Create MojoMediaPermission in AndroidMojoMediaClient.
- Pass MojoMediaPermission to AndroidCdmFactory and MediaDrmBridge.
- Check protected media identifier permission in MediaDrmBridge.

An alternative solution is to create a MediaPermissionDispatcher in the
process where the MojoMediaApplication is hosted, and plumb it through
to the CDM. With the ServiceRegistry in GPU process, this is prototyped
in https://chromiumcodereview.appspot.com/1837143002/. It seems to have
less layers involved. However, this solution is not generic. We need to
do this differently when hosting the MojoMediaApplication in different
processes. Therefore, the current approach is preferred.

BUG=559839
TEST=Manually tested to verify the permission check is plumbed through.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[xhwang, 2016-03-30 07:04:36]

xhwang@chromium.org changed reviewers:
+ ddorwin@chromium.org, rockot@chromium.org

[xhwang, 2016-03-30 07:04:36]

I hope the CL description is self-explanatory. It's mostly trying to convert one
interface to another and plumb the permission check/request through. I did try a
different approach (see CL description) which seems simpler but is not generic
so I don't like it at the moment.

Please take a look and let me know what you think.

[xhwang, 2016-03-30 07:11:34]

https://chromiumcodereview.appspot.com/1838903007/diff/1/content/browser/medi...
File content/browser/media/media_permission_impl.cc (right):

https://chromiumcodereview.appspot.com/1838903007/diff/1/content/browser/medi...
content/browser/media/media_permission_impl.cc:19: NativeType
ConvertMediaPermissionType(MojoType type) {
rockot: What's the new recommendation on consolidating native and mojo enums? I
kinda hate conversion or static_assert. Always using the mojom one is one
solution. But at least at this moment, our core media code knows nothing about
mojo.

https://chromiumcodereview.appspot.com/1838903007/diff/1/content/browser/medi...
File content/browser/media/media_permission_impl.h (right):

https://chromiumcodereview.appspot.com/1838903007/diff/1/content/browser/medi...
content/browser/media/media_permission_impl.h:28: static void
Create(PermissionServiceContext* permission_service_context,
rockot: We'll use PermissionService in the same browser process to implement the
media::interfaces::MediaPermission service. When we use a service in the same
process, I assume we'll still go through all the serialization. Is there any
concern over this use pattern? In this case the calls are infrequent and very
light-weighted, so I don't think performance is a concern.

[mlamouri (slow - plz ping), 2016-03-31 21:54:40]

mlamouri@chromium.org changed reviewers:
+ mlamouri@chromium.org

[mlamouri (slow - plz ping), 2016-03-31 21:54:40]

Why do you create a new MediaPermission instead of using the existing
PermissionService?

[xhwang, 2016-03-31 22:26:19]

On 2016/03/31 21:54:40, Mounir Lamouri wrote:
> Why do you create a new MediaPermission instead of using the existing
> PermissionService?

Good question. I hoped my CL description is clear about this but apparently it
failed.

PermissionService is in content. We cannot use "content" in media. That's why we
invent our MediaPermission. I thought about moving PermissionService to a common
place but it seems odd that we expose GeoLocation etc to "media".

[xhwang, 2016-04-01 03:32:25]

On 2016/03/31 22:26:19, xhwang wrote:
> On 2016/03/31 21:54:40, Mounir Lamouri wrote:
> > Why do you create a new MediaPermission instead of using the existing
> > PermissionService?
> 
> Good question. I hoped my CL description is clear about this but apparently it
> failed.
> 
> PermissionService is in content. We cannot use "content" in media. That's why
we
> invent our MediaPermission. I thought about moving PermissionService to a
common
> place but it seems odd that we expose GeoLocation etc to "media".

Is it actually possible to more PermissionService to a component instead of
keeping it in "content"? If so "media" can connect to PermissionService directly
and our implementation could be greatly simplified.

[xhwang, 2016-04-01 17:07:18]

xhwang@chromium.org changed reviewers:
+ jam@chromium.org

[xhwang, 2016-04-01 17:07:19]

+jam since rockot is OOO at the moment.

This is not super high priority but we do like to get this in M51. Thanks!

[jam, 2016-04-01 23:17:02]

yes the goal is to have a low level permission service as part of moving towards
components using mojo, see
https://docs.google.com/document/d/1Q40FQiphP1SZNr010ZERqo9aKSY3ozcMjDl7NjeMf....
it could live in components/permission

also see https://codereview.chromium.org/1771743002/#msg28 where we discuss this
for the cl that moved this from content to blink yesterday. until then, since
the only consumer of that interface was blink we wanted to wait to move it to a
low-level directory once we see what other callers need and we can move the
implementation there. Given that you need this now, perhaps we can reorder the
tasks to unblock you. i.e. start by moving permission.mojom &
permission_status.mojom to components/permission. that unblocks you.

then when we find someone to work on the permission component, they can change
the enum to either a string or some token that is returned by a registration
mechanism so that the list of permissions isn't contained in one central place.
and then move the implementation from content&chrome to there, so that we can
eventually run this permission service without chrome running.

[xhwang, 2016-04-01 23:20:44]

On 2016/04/01 23:17:02, jam wrote:
> yes the goal is to have a low level permission service as part of moving
towards
> components using mojo, see
>
https://docs.google.com/document/d/1Q40FQiphP1SZNr010ZERqo9aKSY3ozcMjDl7NjeMf....
> it could live in components/permission
> 
> also see https://codereview.chromium.org/1771743002/#msg28 where we discuss
this
> for the cl that moved this from content to blink yesterday. until then, since
> the only consumer of that interface was blink we wanted to wait to move it to
a
> low-level directory once we see what other callers need and we can move the
> implementation there. Given that you need this now, perhaps we can reorder the
> tasks to unblock you. i.e. start by moving permission.mojom &
> permission_status.mojom to components/permission. that unblocks you.
> 
> then when we find someone to work on the permission component, they can change
> the enum to either a string or some token that is returned by a registration
> mechanism so that the list of permissions isn't contained in one central
place.
> and then move the implementation from content&chrome to there, so that we can
> eventually run this permission service without chrome running.

Great! Thank you!!!!!

I assume moving the PermissionService mojom isn't too hard. Is it possible to do
this fairly soon so I can land my work in M51? (Merge back to M51 shortly after
branch cut should be fine.)

[jam, 2016-04-04 15:37:51]

On 2016/04/01 23:20:44, xhwang (OOO Apr4 - Apr8) wrote:
> On 2016/04/01 23:17:02, jam wrote:
> > yes the goal is to have a low level permission service as part of moving
> towards
> > components using mojo, see
> >
>
https://docs.google.com/document/d/1Q40FQiphP1SZNr010ZERqo9aKSY3ozcMjDl7NjeMf....
> > it could live in components/permission
> > 
> > also see https://codereview.chromium.org/1771743002/#msg28 where we discuss
> this
> > for the cl that moved this from content to blink yesterday. until then,
since
> > the only consumer of that interface was blink we wanted to wait to move it
to
> a
> > low-level directory once we see what other callers need and we can move the
> > implementation there. Given that you need this now, perhaps we can reorder
the
> > tasks to unblock you. i.e. start by moving permission.mojom &
> > permission_status.mojom to components/permission. that unblocks you.
> > 
> > then when we find someone to work on the permission component, they can
change
> > the enum to either a string or some token that is returned by a registration
> > mechanism so that the list of permissions isn't contained in one central
> place.
> > and then move the implementation from content&chrome to there, so that we
can
> > eventually run this permission service without chrome running.
> 
> Great! Thank you!!!!!
> 
> I assume moving the PermissionService mojom isn't too hard. Is it possible to
do
> this fairly soon so I can land my work in M51? (Merge back to M51 shortly
after
> branch cut should be fine.)

yes we can do it anytime. can you do this?

[xhwang, 2016-04-04 16:16:58]

On 2016/04/04 15:37:51, jam wrote:
> On 2016/04/01 23:20:44, xhwang (OOO Apr4 - Apr8) wrote:
> > On 2016/04/01 23:17:02, jam wrote:
> > > yes the goal is to have a low level permission service as part of moving
> > towards
> > > components using mojo, see
> > >
> >
>
https://docs.google.com/document/d/1Q40FQiphP1SZNr010ZERqo9aKSY3ozcMjDl7NjeMf....
> > > it could live in components/permission
> > > 
> > > also see https://codereview.chromium.org/1771743002/#msg28 where we
discuss
> > this
> > > for the cl that moved this from content to blink yesterday. until then,
> since
> > > the only consumer of that interface was blink we wanted to wait to move it
> to
> > a
> > > low-level directory once we see what other callers need and we can move
the
> > > implementation there. Given that you need this now, perhaps we can reorder
> the
> > > tasks to unblock you. i.e. start by moving permission.mojom &
> > > permission_status.mojom to components/permission. that unblocks you.
> > > 
> > > then when we find someone to work on the permission component, they can
> change
> > > the enum to either a string or some token that is returned by a
registration
> > > mechanism so that the list of permissions isn't contained in one central
> > place.
> > > and then move the implementation from content&chrome to there, so that we
> can
> > > eventually run this permission service without chrome running.
> > 
> > Great! Thank you!!!!!
> > 
> > I assume moving the PermissionService mojom isn't too hard. Is it possible
to
> do
> > this fairly soon so I can land my work in M51? (Merge back to M51 shortly
> after
> > branch cut should be fine.)
> 
> yes we can do it anytime. can you do this?

I am OOO this week. I can do this next week if not done by anyone else. Thanks!