In chrome://settings/content, with Chrome 56 at least, the plugin settings are now labeled as "Unsandboxed plugin access" and there is a separate checkbox for controlling the PDF Documents. Given this separation, I would expect the reported behavior to be working as intended, in that chrome.contentSettings.plugins (documented on [1]) corresponds to "Unsandboxed plugin access" and have no control over the PDF Viewer, which is a sandboxed plugin.

However, we should add a new chrome.contentSettings.pdf setting for controlling the PDF setting via the extension API.

[1] https://developer.chrome.com/extensions/contentSettings#property-plugins

The chrome.contentSettings.plugins documentation probably needs an update to point mention the unsandboxed part.

Wait, but we also have chrome.contentSettings.unsandboxedPlugins so I'm confused on exactly what does what. So I will shut up and defer to the experts.

I should also mention there are other bugs like  bug 624497  where users have expressed the desire for more controls for the PDF plugin setting. e.g. whitelist by domain rather than just a simple toggle. We may want to iron out those issues before implementing any contentSettings APIs.

Others probably know better than I, but I would expect plugins to affect the pdf plugin, and unsandboxPlugins to affect the rest, so to me, this seems like a real bug that we should fix.

In which case, ignore my incorrect statements in comment 2 and comment 3.

Thanks for the replies! :-) The insight has been very helpful.

On my computer, I observe the following:
* chrome.contentSettings.plugins.getResourceIdentifiers() returns all the plugins I have installed, including Flash + PDF. So, are all these plugins sandboxed? and if so, why is PDF special in that I cannot block it?

* chrome.contentSettings.unsandboxedPlugins.getResourceIdentifiers() doesn't return any plugins.

This sounds like a bug to me too.

There are two ways to go about this though - 
1. fix this api to cover the pdf plugin (which should be the case all the way) I don't even see why it doesn't right now...or/and...
2. add a new specific to pdf knob in this api for pdfs like we did in the user visible settings.

I think that option 1 makes the most sense.

Here is a minimal extension to use for testing this problem.

Interestingly the get api itself returns the "block" status for a sample url.

Deleted: test_ext.zip 811 bytes

test_ext.zip 811 bytes Download

Hi Tommy,

I am assigning this one to you because I believe that your recent changes to  use the content settings only for Flash seem to have broken the contentSettings API which intuitively should work for all plugins. At the very least we have to document that this is not possible anymore and provide alternatives in the API.

sorry wrong tommi :D

Hi,
Does that mean the only plugin that can be blocked with the contentSettings
API is Flash? That's bizarre, and really unexpected (as an end user of the
API). I would expect the API to work with all plugins it returns, which by
default i think is 4 (at least on OSX). I am trying to block all plugins,
because as an the author of an extension i can not trust them to use the
proxy i have configured chrome to use.

Thanks the replies.

Yes, I think this is the right way to solve this. The list of plugins and this API should be consistent. Either the list should not contain things not considered plugins anymore or the api should block whatever it lists.

It is important for privacy-related extensions to be able to disable these plugins, especially flash and native client plugins, but in general all plugins should be block-able, so i hope the solution doesn't remove that option.

rgleeson: Whoa you work for londontrustmedia? Makers of PIA right? Cool.

Anyways -- I have one big question: Which plugins are you trying to block?

Since NPAPI has been deprecated, and no one has really written any PPAPI plugins, the only plugins that exist are: 

 1. NaCl (internal component, which can't be disabled right now). 
 2. Widevine (also internal, separate checkbox under Protected Content content setting) 
 3. PDF (also internal, and now there's a separate checkbox to disable)
 4. Flash (still controlled by the plugins content setting)
 5. Custom plugins loaded by command line (I'm pretty sure no one uses this, but you could just not inculde in via command line.)

Is the problem that you can no longer control #1, #2, and #3 via extension?

Is the inability to block Native Client a problem?

Thanks,

Tommy

Thanks for the reply Tommy :)

Yeah, #1, #2, and #3 are an issue. The reason is because it seems that any native plugin has the potential to not respect the browsers proxy settings, and that's an issue for me because i'd like to configure chrome to always use the proxy, or fail/block if it can't.

2/3 plugins seem like they won't do any network stuff, but because plugins have the potential to, it would be ideal to be able to block any of them. NaCI/native client seems like it would have the same issues as Adobe Flash, so i think it is a problem but i haven't confirmed that for sure. maybe chrome disallows network access from NaCI?

for 2/3, i understand there is separate switches elsewhere in UI, but it would be great if the content setting could take precedent, if a rule is set.

maybe the background can help. i hope so :)
cheers. 



 

Re-titling it to reflect the new understanding:

Extensions used to be be able to control plugins. Since axing chrome://plugins, they can't anymore. We should investigate updating the extensions API to bring back the old functionality...

Julian: Any thoughts on priority?

+blumberg 

Adding our pm for prioritization. 

I think as long as the policies work most enterprises are going to be ok so I would not call it a P0 but somewhere between 1 and 2 sound right to me.

Hi Folks,

We will discuss this tomorrow and follow up.

Thanks

Hey.
It also looks like this is an issue with the javascript contentSettings API as well.
This code will print "blocked" and get() show it as blocked as well: 

chrome.contentSettings.javascript.set({
      primaryPattern: "<all_urls>",
      setting: "block",
      scope: "regular"}, () => {
        if(chrome.runtime.lastError) {
          console.log("error")
        } else {
          console.log("blocked")
        }
      })

If you go to a website though, Javascript isn't blocked at all.
The contentSettings API is nice for deciding what can and cannot run, but unfortunately chrome tends to ignore it. At the very least the docs should be updated, but ideally alternatives would be provided, or the current API is updated to work as documented.

Hm, sorry. My last comment is wrong. I can block JavaScript.
I'll report again if i see the issue.

Hey.
Just some feedback. I noticed that it would be useful to have something like contentSettings.plugins.clear() but specific to Adobe Flash, the PDF plugin, etc. It is easiest way to revert back to the users default settings. 

I am un-ownering myself, so someone else can jump in if they have time.

I found another bug that's probably related to this. If an extension does block Adobe Flash, on OSX clicking the "Secure" text in the address bar shows a popup that says Flash is permission is "Ask (default)". It should be "Blocked by extension". Camera/Location/Microphone don't have this issue.

Filed two new bugs related to contentSettings API:
https://bugs.chromium.org/p/chromium/issues/detail?id=700404
https://bugs.chromium.org/p/chromium/issues/detail?id=700402

Unowned -> no longer assigned.

Hi all.
Are there any plans to fix this issue? It seems like a nasty regression to me.
Before, the content setting API could block any plugin. Now, only Flash can be blocked.
The bug also presents itself in a way that isn't obvious, so extensions that relied on the old behaviour could be broken yet totally unaware. 

Please consider fixing the content setting API or providing an alternative.
Cheers. 

Hi all, again.

Given Chrome v61, and the two vulns directly related to PDFium, can I ask you please consider restoring access once again to the API that allows this to be blocked?

The documentation on the website has still not been updated.
At least do that, and not ignore this issue entirely.
Thank you.

Also, "PDF" seems totally valid as a "content setting" that can be blocked. This API support was silently removed, never replaced, and documentation never updated. 
Come on, guys.
Thanks.

Assigning to raymes@, +emilyschechter@, content settings extraordinaires.

This seems reasonable to me, but these folks will know better.

Thanks. Sorry if i was snarky.

Hi again.

On Chrome v61, here is the most recent output of getResourceIdentifiers():

chrome.contentSettings.plugins.getResourceIdentifiers((o) => console.log(o))
(5) [{…}, {…}, {…}, {…}, {…}]
0
:
{description: "Widevine Content Decryption Module", id: "widevinecdmadapter.plugin"}
1
:
{description: "Adobe Flash Player", id: "adobe-flash-player"}
2
:
{description: "Chrome PDF Viewer", id: "google-chrome-pdf"}
3
:
{description: "Native Client", id: "internal-nacl-plugin"}
4
:
{description: "Chrome PDF Plugin", id: "internal-pdf-viewer"}

Of those 5, only Flash can be blocked (iirc). This doesn't make sense to me.
The API needs some sort of update, where these are not returned by getResourceIdentifiers(), or other.

Thanks for filing this bug and the related ones. 

Widevine or NaCl have been gated behind the plugins content setting, they have always been gated behind the JS content setting so that's certainly not a regression.

PDF was at some point but we made a decision to change it (that I wasn't involved in).

> The reason is because it seems that any native plugin has the potential to not respect the browsers proxy settings, and that's an issue for me because i'd like to configure chrome to always use the proxy, or fail/block if it can't.

PDF should never make requests that don't respect the proxy settings of the browser.

The issue in #35 is certainly a bug. Issue 754178 is to remove resource identifiers completely and that can probably be addressed at the same time.

> Widevine or NaCl have been gated behind the plugins content setting, they have always been gated behind the JS content setting so that's certainly not a regression.

What do you mean by gated? Only discoverable, but rules cannot be applied to them? Please mention this in the docs, if you can. Or elaborate on the situation entirely, in the documentation - it is confusing, as it stands.

> PDF should never make requests that don't respect the proxy settings of the browser.

It's not the only concern. Extension authors cannot control PDF content. Is this intentional, and if so, why? 

> What do you mean by gated? 

Sorry I meant to say they "have never been gated". What I mean that Widevine/NaCl weren't ever controllable via the plugins content setting, at least not in the past 4 years.

> It's not the only concern. Extension authors cannot control PDF content. Is this intentional, and if so, why? 

We do not aim to expose controls for every feature in Chrome via extensions APIs, only when there is considered to be significant value in doing so. 

> Sorry I meant to say they "have never been gated". What I mean that Widevine/NaCl weren't ever controllable via the plugins content setting, at least not in the past 4 years.

Understood, then please consider removing them (unfortunate) or updating the documentation to mention they are *only* discoverable, but rules cannot be applied to them. 

An extra object prop, like 'manageable' to imply the setting can be used managed could be useful, with a 'false' value being applied to: PDF, NaCI, etc.


> We do not aim to expose controls for every feature in Chrome via extensions APIs, only when there is considered to be significant value in doing so. 

I see. I use extension API as portable settings that I can take with me, certain things I don't want chrome to manage, such as PDFs. I'm left with no options here, so this too is unfortunate, and "enterprise policies" don't feel the same for me (if they can solve it, not sure).

> Understood, then please consider removing them (unfortunate) or updating the documentation to mention they are *only* discoverable, but rules cannot be applied to them. 

Yes, we need to do this as a part of issue 754178. 

> I see. I use extension API as portable settings that I can take with me, certain things I don't want chrome to manage, such as PDFs. 

Note that it is possible to override the default PDF viewer with an extension (this happens via a completely different API). Take a look at https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?hl=en. 

I'm going to close this as WontFix now. Thanks again for filing this and the other bugs.

Thank you :)
I will check it out.

#40 -
> Note that it is possible to override the default PDF viewer with an extension (this happens via a completely different API). Take a look at https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?hl=en. 

This is only available in Chrome OS, if I am not mistaken, so this is not a solution for other platforms.

I can confirm that the solution is #40 does work on Desktop (non ChromeOS) as well.

Nice. Thank you.