If Click to play is enabled we aren't blocking users from executing plugins on a page anyway. Allowing them to manually modify their local whitelist reduces user annoyance at a very very small security cost.

Pros:

Fixes the UX, users aren't surprised when their changes don't take effect
Users are most likely going to click "allow" when they navigate these sites anyway, the number of plugin executions blocked is minimal at best.

Cons:

Users might whitelist pages they didn't intend to/don't actually need to whitelist. This could cause some pages to execute plugins needlessly.

More info - It seems improvements to the chrome://content/settings API were made in https://codereview.chromium.org/1963203002 where the "ignored" URL exceptions are shown strikethrough - see screenshot (from Canary) and  issue 568031 . It sounds like a conscious decision was made there to not allow user overrides.

image

Deleted: strikethrough.png 23.6 KB

	strikethrough.png 23.6 KB View Download

I support this bug.

If the Enterprise has chosen ASK instead of BLOCK, their intent is to allow users to run plugins at their discretion.

User-set exception seem consistent with that.

Caveat: We are discussing to allow global wildcarding for "allow". THAT part, we probably shouldn't allow for an enterprise setting of ASK. 

When the enterprise setting is CONTENT_SETTING_ASK, users can allow at will already. Letting users save the allow setting permanently is a usability boost without any serious lessening in security (they can allow it whenever they want anyway). 

I support people being able to persist that per/ url preference (agreed should honor the wildcard for this case), since they already have the ability to run the content.

Who would be the best owner for this?

> Currently it's made more confusing for users, as it is possible to add
> sites to the overrides in chrome://settings/content, but they have no effect.

That specific aspect is an UI bug that's being addressed in  issue 588721 .

As to whether we should allow users to override policy settings: I would rather not open that can of worms.  In a managed setting, the admin is in control and that is by design.  The admin should not have to wonder whether Chrome is second-guessing their policies.

As a concrete example how that could go wrong: Admin sets policy to "ask" in order to increase security.  User is annoyed by that and configures "always run" for example.com because they often watch videos on that page.  Later example.com is compromised to serve exploit code hidden in a pixel-sized plugin.  The user would have never clicked that pixel in the "ask" case, but now that the setting is "always run" the user is owned.

Thus I'm leaning heavily towards duping this issue on 588721.

re: #12, the user visiting example.com to watch cat videos will just click "allow once" every single time, and having them do that every time is not actually increasing security here at all, in fact it probably makes them more likely to do this for other (dangerous) sites due to warning fatigue so is a net security decrease.

The "ASK" setting is intended to prevent e.g. drive-by iframe flash attacks on new/unknown sites, not to prevent users from running Flash on sites that they visit often and trust.

If an enterprise wishes to prevent users from running Flash on sites except a whitelist, then the enterprise should set DefaultPluginsSetting to 2 (BLOCK) and centrally manage that whitelist.

I don't think that example is compelling.  If the user's expected plugin is at the top, and there's a pixel-sized plugin at the bottom, he'd click "Run all plugins this time" so he'd be compromised regardless.

There is another argument to be made, which is that "Always allow plugins on this site" is so easy to click that many users would probably click it every time they encounter it.

Oh well.  Assigning to enterprise PM for their input then.

Note, my (#14) comment refers to the example in #12.  I hadn't seen #13 yet.

One more note, my comment that "Always allow plugins on this site" is really easy to click could be mitigated by a scary confirmation dialog.  (Which we may have already.)

I agree w/ Will, there is little advantage here in over prompting the user since they will either become blind to UI path or they will seek out other browsers (which is the alternative in Google).

Given that we are allowing users to run the content, letting them statefully persist (and us honor) the site specific settings seems consistent and correct with the intention of both the user and the admin (i.e. the user is making a decision to trust the site, which the admins are granting them the privilege to do - otherwise they would have used BLOCK).  We're effectively just not making them do it repeatedly.

Based on the amount of internal feedback, requesting this specific behavior, it seems reasonable and correct.

+finnur, +raymes

While I agree with the motivations for wanting to allow users to override the enterprise decision, this is hard to model in the code right now. Enterprise defaults always override user decisions. Allowing users to override enterprise defaults again makes things complicated. We'd have to add special cases to make this work: "use the enterprise default, except if it's ask/click-to-play and only if the user setting is non-wildcard". I'm afraid it might also be hard to reason about for someone who is trying to enforce policy. We could do this if we felt the tradeoff was really worth it.

FYI: huangs@ did work on solving a more general instance of this problem: allowing enterprises to specify a "recommended" policy that can be overridden by users, see go/chrome-suggested-policy. This never ended up getting landed - it also added a fair amount of complexity and didn't end up being needed.

raymes: Okay I see. Yeah, if the eng effort is too large to make this happen, we can just wait until HBD lands.

In that new world, we'll map ASK to DETECT (which allows exceptions), so this bug will be fixed anyways.

The frequently visited site where this problem is most annoying is the NBC olympics site currently.

Is it possible to maybe add this site to enterprise whitelist itself?

This bug is about the how the policy is implemented in Chrome, not about enterprise specific policy settings. I suggest you contact the administrator for your enterprise if you feel the specific settings there should be changed.

One other consideration to add is some sites fail when the plugin is initially blocked or if the user doesn't enable the plugin fast enough (e.g. tv.xfinity.com). For those sites using a rule is the only way to get the page to successfully run.

I'm marking this WontFix. Allowing the user to add custom exceptions to override ASK is technically hard and it's also questionable whether it goes against the intention of the policy.

M56 is going to have different enterprise behavior which will solve the issue described in #26.