Change Win32k PPAPI lockdown to use finch params for mime type.

Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
Committed: https://crrev.com/c91e967e98ace8db59aa9c29b0949603caa51050
Cr-Commit-Position: refs/heads/master@{#371651}

[Will Harris, 2016-01-20 01:36:05]

Description was changed from

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
==========

to

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
==========

[Will Harris, 2016-01-20 01:36:05]

wfh@chromium.org changed reviewers:
+ asvitkine@chromium.org, avi@chromium.org

[Will Harris, 2016-01-20 01:36:35]

avi: what do you think about this addition to DEPS :)

asvitkine: is my finch-fu valid now?

[Avi (use Gerrit), 2016-01-20 15:13:48]

I'm OK with the DEPS but I'm not familiar enough with the components/ directory
to know. Don't you need approval from someone on that side?

[Will Harris, 2016-01-20 15:56:04]

On 2016/01/20 15:13:48, Avi wrote:
> I'm OK with the DEPS but I'm not familiar enough with the components/
directory
> to know. Don't you need approval from someone on that side?

I'm hoping asvitkine will be able to assert this is okay from the
components/variations perspective, as he is an OWNER there.

[Alexei Svitkine (slow), 2016-01-20 16:19:52]

Dependency looks good to me. Have a comment about the usage of the API.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:61: 
Nit: Remove empty line.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:66: if (param.first == mime_type ||
param.first == "*") {
Hmm, I was thinking you just have a single "MimeTypes" param and treat its
content the same as what's specified via the kEnableWin32kLockDownMimeTypes
command-line. That way, you have a single code path to parse these params, which
seems simpler to me and less error-prone.

[Will Harris, 2016-01-20 16:42:54]

wfh@chromium.org changed reviewers:
+ alexei svitkine (slow). forshaw@chromium.org
- asvitkine@chromium.org

[Will Harris, 2016-01-20 16:44:08]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:66: if (param.first == mime_type ||
param.first == "*") {
On 2016/01/20 16:19:52, Alexei Svitkine (slow) wrote:
> Hmm, I was thinking you just have a single "MimeTypes" param and treat its
> content the same as what's specified via the kEnableWin32kLockDownMimeTypes
> command-line. That way, you have a single code path to parse these params,
which
> seems simpler to me and less error-prone.

This code allows us to enable for all plugins except one e.g. if we want to
experiment with enabled for all plugins except Flash, then we can set the value
to:

| key                           | value    |
+-------------------------------+----------+
| application/x-shockwave-flash | Disabled |
| application/futuresplash      | Disabled |
| *                             | Enabled  |

That was the reasoning why, but forshaw might have views on whether we would
ever use this or not...

[forshaw, 2016-01-20 16:57:48]

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

[forshaw, 2016-01-20 16:57:48]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:66: if (param.first == mime_type ||
param.first == "*") {
On 2016/01/20 16:44:08, Will Harris wrote:
> On 2016/01/20 16:19:52, Alexei Svitkine (slow) wrote:
> > Hmm, I was thinking you just have a single "MimeTypes" param and treat its
> > content the same as what's specified via the kEnableWin32kLockDownMimeTypes
> > command-line. That way, you have a single code path to parse these params,
> which
> > seems simpler to me and less error-prone.
> 
> This code allows us to enable for all plugins except one e.g. if we want to
> experiment with enabled for all plugins except Flash, then we can set the
value
> to:
> 
> | key                           | value    |
> +-------------------------------+----------+
> | application/x-shockwave-flash | Disabled |
> | application/futuresplash      | Disabled |
> | *                             | Enabled  |
> 
> That was the reasoning why, but forshaw might have views on whether we would
> ever use this or not...

Well I could see it being useful in this scenario although probably we're not
likely to test all plugins. It would also be helpful in order to override
existing user preferences if necessary (say flash lockdown is found to be
completely broken). But I'm happy either way.

[Will Harris, 2016-01-21 18:03:54]

ping. I think having the ability to selectively disable by mime id is enough
reason to support the fine grained parameters. This gives us a kill switch as
well, which we've learned is a good thing to have for new sandbox mitigations
which often have complex 3rd party software interactions (especially on Stable).

[Will Harris, 2016-01-22 19:23:50]

wfh@chromium.org changed reviewers:
+ asvitkine@chromium.org
- alexei svitkine (slow). forshaw@chromium.org, forshaw@chromium.org

[Alexei Svitkine (slow), 2016-01-22 19:27:50]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:65: for (auto param : mime_params)
{
Nit: const auto&

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:79: return true;
So if something is not explicitly listed as enabled in the params (or via *),
there's a fallback to use the command-line param?

I'd add a comment about this behavior to clarify. Although, it seems strange to
support this hybrid behavior. Maybe better to always use one or the other?

Also, usually it's a good idea to make the command line override the experiment
params, rather than vice versa. But in some cases (e.g. if you suspect malware
might use the command line to mess with it), the opposite might be preferable.
I'll leave it up to you to choose which one this should be, but it should likely
have a comment about it.

[Will Harris, 2016-01-25 18:20:28]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:79: return true;
On 2016/01/22 19:27:50, Alexei Svitkine (very slow) wrote:
> So if something is not explicitly listed as enabled in the params (or via *),
> there's a fallback to use the command-line param?
> 
> I'd add a comment about this behavior to clarify. Although, it seems strange
to
> support this hybrid behavior. Maybe better to always use one or the other?
> 
> Also, usually it's a good idea to make the command line override the
experiment
> params, rather than vice versa. But in some cases (e.g. if you suspect malware
> might use the command line to mess with it), the opposite might be preferable.
> I'll leave it up to you to choose which one this should be, but it should
likely
> have a comment about it.

The idea is that there is a global disable - which is on line 57. this can
disable everything via command line.

then, finch can selectively enable or disable for certain mime types or for
everything.

then, the user can selectively enable or disable via command line (also exposed
by chrome://flags).

I think this covers all the cases. Does that seem reasonable or would you prefer
a different order of precedence here?

[Alexei Svitkine (slow), 2016-01-25 18:54:51]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:79: return true;
On 2016/01/25 18:20:28, Will Harris wrote:
> On 2016/01/22 19:27:50, Alexei Svitkine (very slow) wrote:
> > So if something is not explicitly listed as enabled in the params (or via
*),
> > there's a fallback to use the command-line param?
> > 
> > I'd add a comment about this behavior to clarify. Although, it seems strange
> to
> > support this hybrid behavior. Maybe better to always use one or the other?
> > 
> > Also, usually it's a good idea to make the command line override the
> experiment
> > params, rather than vice versa. But in some cases (e.g. if you suspect
malware
> > might use the command line to mess with it), the opposite might be
preferable.
> > I'll leave it up to you to choose which one this should be, but it should
> likely
> > have a comment about it.
> 
> The idea is that there is a global disable - which is on line 57. this can
> disable everything via command line.
> 
> then, finch can selectively enable or disable for certain mime types or for
> everything.
> 
> then, the user can selectively enable or disable via command line (also
exposed
> by chrome://flags).
> 
> I think this covers all the cases. Does that seem reasonable or would you
prefer
> a different order of precedence here?

That's fine. In that case, I would suggest changing this line to "return
enabled;" - so that if the params are used, it doesn't fall through to also use
the kEnableWin32kLockDownMimeTypes command line.

[Will Harris, 2016-01-25 19:08:11]

one question for you before I upload a new patchset.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:62: if
(variations::GetVariationParams("EnableWin32kLockDownMimeTypes",
Q: should this call be above line 57 to ensure that all clients get placed into
an experiment group? Line 57 will return false for all platforms before windows
8, so I suppose it depends whether I want to filter the experiment groups on the
client or the server, what do you think is best here?

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:79: return true;
On 2016/01/25 18:54:51, Alexei Svitkine (very slow) wrote:
> On 2016/01/25 18:20:28, Will Harris wrote:
> > On 2016/01/22 19:27:50, Alexei Svitkine (very slow) wrote:
> > > So if something is not explicitly listed as enabled in the params (or via
> *),
> > > there's a fallback to use the command-line param?
> > > 
> > > I'd add a comment about this behavior to clarify. Although, it seems
strange
> > to
> > > support this hybrid behavior. Maybe better to always use one or the other?
> > > 
> > > Also, usually it's a good idea to make the command line override the
> > experiment
> > > params, rather than vice versa. But in some cases (e.g. if you suspect
> malware
> > > might use the command line to mess with it), the opposite might be
> preferable.
> > > I'll leave it up to you to choose which one this should be, but it should
> > likely
> > > have a comment about it.
> > 
> > The idea is that there is a global disable - which is on line 57. this can
> > disable everything via command line.
> > 
> > then, finch can selectively enable or disable for certain mime types or for
> > everything.
> > 
> > then, the user can selectively enable or disable via command line (also
> exposed
> > by chrome://flags).
> > 
> > I think this covers all the cases. Does that seem reasonable or would you
> prefer
> > a different order of precedence here?
> 
> That's fine. In that case, I would suggest changing this line to "return
> enabled;" - so that if the params are used, it doesn't fall through to also
use
> the kEnableWin32kLockDownMimeTypes command line. 

okay yes that makes good sense, will add comments too.

[Alexei Svitkine (slow), 2016-01-25 19:32:48]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:62: if
(variations::GetVariationParams("EnableWin32kLockDownMimeTypes",
On 2016/01/25 19:08:10, Will Harris wrote:
> Q: should this call be above line 57 to ensure that all clients get placed
into
> an experiment group? Line 57 will return false for all platforms before
windows
> 8, so I suppose it depends whether I want to filter the experiment groups on
the
> client or the server, what do you think is best here?

So, if its here, those users won't show up on the dashboard. The other option is
to move this above and then use go/variations-flags in the config, so that you
can see the users who explicitly use this flag via the dashboard. Whichever you
prefer. However, if you do move it above, you should make sure to have the flag
in the config, else you'll get misleading data for these users (they'll show up
as being in the group even if it's disabled).

[Will Harris, 2016-01-25 19:35:39]

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:62: if
(variations::GetVariationParams("EnableWin32kLockDownMimeTypes",
On 2016/01/25 19:32:48, Alexei Svitkine (very slow) wrote:
> On 2016/01/25 19:08:10, Will Harris wrote:
> > Q: should this call be above line 57 to ensure that all clients get placed
> into
> > an experiment group? Line 57 will return false for all platforms before
> windows
> > 8, so I suppose it depends whether I want to filter the experiment groups on
> the
> > client or the server, what do you think is best here?
> 
> So, if its here, those users won't show up on the dashboard. The other option
is
> to move this above and then use go/variations-flags in the config, so that you
> can see the users who explicitly use this flag via the dashboard. Whichever
you
> prefer. However, if you do move it above, you should make sure to have the
flag
> in the config, else you'll get misleading data for these users (they'll show
up
> as being in the group even if it's disabled).

sounds like leaving it here is easier, so users who can't use win32k lockdown
just won't appear in the experiment at all. Thanks!

[Will Harris, 2016-01-25 19:46:56]

Patchset #3 (id:40001) has been deleted

[Will Harris, 2016-01-25 19:50:28]

changes made.

PTAL.

avi: please rs the DEPS change
asvitkine: everything else.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:61: 
On 2016/01/20 16:19:52, Alexei Svitkine (very slow) wrote:
> Nit: Remove empty line.

Done.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:65: for (auto param : mime_params)
{
On 2016/01/22 19:27:50, Alexei Svitkine (very slow) wrote:
> Nit: const auto&

Done.

https://codereview.chromium.org/1609133002/diff/1/content/browser/ppapi_plugi...
content/browser/ppapi_plugin_process_host.cc:66: if (param.first == mime_type ||
param.first == "*") {
On 2016/01/20 16:57:48, forshaw wrote:
> On 2016/01/20 16:44:08, Will Harris wrote:
> > On 2016/01/20 16:19:52, Alexei Svitkine (slow) wrote:
> > > Hmm, I was thinking you just have a single "MimeTypes" param and treat its
> > > content the same as what's specified via the
kEnableWin32kLockDownMimeTypes
> > > command-line. That way, you have a single code path to parse these params,
> > which
> > > seems simpler to me and less error-prone.
> > 
> > This code allows us to enable for all plugins except one e.g. if we want to
> > experiment with enabled for all plugins except Flash, then we can set the
> value
> > to:
> > 
> > | key                           | value    |
> > +-------------------------------+----------+
> > | application/x-shockwave-flash | Disabled |
> > | application/futuresplash      | Disabled |
> > | *                             | Enabled  |
> > 
> > That was the reasoning why, but forshaw might have views on whether we would
> > ever use this or not...
> 
> Well I could see it being useful in this scenario although probably we're not
> likely to test all plugins. It would also be helpful in order to override
> existing user preferences if necessary (say flash lockdown is found to be
> completely broken). But I'm happy either way.

Acknowledged.

[Alexei Svitkine (slow), 2016-01-25 19:52:40]

lgtm

[Will Harris, 2016-01-25 21:12:33]

wfh@chromium.org changed reviewers:
- avi@chromium.org

[Will Harris, 2016-01-25 21:14:06]

wfh@chromium.org changed reviewers:
+ nasko@chromium.org

[Will Harris, 2016-01-25 21:14:15]

-avi +nasko

[nasko, 2016-01-25 21:40:20]

LGTM

[Will Harris, 2016-01-25 21:46:33]

The CQ bit was checked by wfh@chromium.org

[commit-bot: I haz the power, 2016-01-25 21:46:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1609133002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1609133002/60001

[Will Harris, 2016-01-25 21:51:30]

The CQ bit was unchecked by wfh@chromium.org

[Will Harris, 2016-01-25 21:51:36]

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

[Will Harris, 2016-01-25 21:52:11]

jam@ can you look if this new DEP between content/browser and
components/variations is okay from a html_viewer perspective?

[jam, 2016-01-26 00:37:01]

On 2016/01/25 21:52:11, Will Harris wrote:
> jam@ can you look if this new DEP between content/browser and
> components/variations is okay from a html_viewer perspective?

Thanks for checking. components/variations isn't something that's used by
html_viewer, so content should not depend on it.

Realistically at this point, html_viewer is not adding any new dependencies
since it's in maintenance mode. So there shouldn't be any more components/
dependencies from content.

[Alexei Svitkine (slow), 2016-01-26 01:02:10]

Sounds like we need a delegate API to get it from chrome/ layer then, that
can depend on the component. :\

On Mon, Jan 25, 2016 at 4:37 PM, <jam@chromium.org> wrote:

> On 2016/01/25 21:52:11, Will Harris wrote:
>
>> jam@ can you look if this new DEP between content/browser and
>> components/variations is okay from a html_viewer perspective?
>>
>
> Thanks for checking. components/variations isn't something that's used by
> html_viewer, so content should not depend on it.
>
> Realistically at this point, html_viewer is not adding any new dependencies
> since it's in maintenance mode. So there shouldn't be any more components/
> dependencies from content.
>
> https://codereview.chromium.org/1609133002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Will Harris, 2016-01-26 01:10:53]

On 2016/01/26 01:02:10, Alexei Svitkine (very slow) wrote:
> Sounds like we need a delegate API to get it from chrome/ layer then, that
> can depend on the component. :\

yup. I'm not going to do that in this CL.

I'll refactor this to still use experiment names but just wire up a fixed list
which mirrors the list already in
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/abo....
We lose flexibility but should still give us valid data for what we need.

I'd agree that if finch parameters are to be more widely used, it sounds like we
need some sort of content api, perhaps the UMA team could address this in a
subsequent CL.

[Will Harris, 2016-01-26 04:10:48]

On 2016/01/26 01:10:53, Will Harris wrote:
> On 2016/01/26 01:02:10, Alexei Svitkine (very slow) wrote:
> > Sounds like we need a delegate API to get it from chrome/ layer then, that
> > can depend on the component. :\
> 
> yup. I'm not going to do that in this CL.
> 
> I'll refactor this to still use experiment names but just wire up a fixed list
> which mirrors the list already in
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/abo....
> We lose flexibility but should still give us valid data for what we need.
> 
> I'd agree that if finch parameters are to be more widely used, it sounds like
we
> need some sort of content api, perhaps the UMA team could address this in a
> subsequent CL.

Actually, on second thoughts, wiring this via content browser client makes a lot
of sense; in fact, delegating this to the embedder is what we already do for the
AppContainer mitigations. I will upload a CL with that soon.

[Will Harris, 2016-01-26 06:20:31]

Refactored the CL to go via ContentBrowserClient and call into
components/variations/ from chrome/

The logic should be identical.

PTAL. Thanks!

[Alexei Svitkine (slow), 2016-01-26 08:23:40]

lgtm

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
content/browser/ppapi_plugin_process_host.cc:95: if
(GetContentClient()->browser()->IsWin32kLockdownEnabledForMimeType(
Nit: Store the result of GetContentClient()->browser() in a var outside the
loop.

[jam, 2016-01-26 15:18:51]

lgtm

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
File chrome/browser/chrome_content_browser_client.cc (right):

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
chrome/browser/chrome_content_browser_client.cc:169: #include
"base/strings/string_util.h"
this is already above, so remove

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
chrome/browser/chrome_content_browser_client.cc:172: #include
"components/variations/variations_associated_data.h"
ditto

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
content/browser/ppapi_plugin_process_host.cc:95: if
(GetContentClient()->browser()->IsWin32kLockdownEnabledForMimeType(
On 2016/01/26 08:23:40, Alexei Svitkine (very slow) wrote:
> Nit: Store the result of GetContentClient()->browser() in a var outside the
> loop.


given that the list of mime types should be pretty small, why do this without
seeing that it's slow?

[Will Harris, 2016-01-26 22:57:55]

thanks for reviews.

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
File chrome/browser/chrome_content_browser_client.cc (right):

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
chrome/browser/chrome_content_browser_client.cc:169: #include
"base/strings/string_util.h"
On 2016/01/26 15:18:51, jam wrote:
> this is already above, so remove

Done.

https://codereview.chromium.org/1609133002/diff/80001/chrome/browser/chrome_c...
chrome/browser/chrome_content_browser_client.cc:172: #include
"components/variations/variations_associated_data.h"
On 2016/01/26 15:18:51, jam wrote:
> ditto

Done.

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
File content/browser/ppapi_plugin_process_host.cc (right):

https://codereview.chromium.org/1609133002/diff/80001/content/browser/ppapi_p...
content/browser/ppapi_plugin_process_host.cc:95: if
(GetContentClient()->browser()->IsWin32kLockdownEnabledForMimeType(
On 2016/01/26 15:18:51, jam wrote:
> On 2016/01/26 08:23:40, Alexei Svitkine (very slow) wrote:
> > Nit: Store the result of GetContentClient()->browser() in a var outside the
> > loop.
> 
> 
> given that the list of mime types should be pretty small, why do this without
> seeing that it's slow?

GetContentClient() does seem to do a CALL and it's done twice (once here and
once below) so saving to a stack variable seems like a reasonable optimization.

[Will Harris, 2016-01-26 22:58:01]

The CQ bit was checked by wfh@chromium.org

[Will Harris, 2016-01-26 22:58:02]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org,
asvitkine@chromium.org, jam@chromium.org
Link to the patchset: https://codereview.chromium.org/1609133002/#ps100001
(title: "code review changes")

[commit-bot: I haz the power, 2016-01-26 23:04:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1609133002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1609133002/100001

[commit-bot: I haz the power, 2016-01-27 00:14:26]

Description was changed from

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
==========

to

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
==========

[commit-bot: I haz the power, 2016-01-27 00:14:27]

Committed patchset #5 (id:100001)

[commit-bot: I haz the power, 2016-01-27 00:15:44]

Description was changed from

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278
==========

to

==========
Change Win32k PPAPI lockdown to use finch params for mime type.

BUG=523278

Committed: https://crrev.com/c91e967e98ace8db59aa9c29b0949603caa51050
Cr-Commit-Position: refs/heads/master@{#371651}
==========

[commit-bot: I haz the power, 2016-01-27 00:15:45]

Patchset 5 (id:??) landed as
https://crrev.com/c91e967e98ace8db59aa9c29b0949603caa51050
Cr-Commit-Position: refs/heads/master@{#371651}