We'd really like to see if we can come up with something that we can get into M58. We're trying to deploy an extension internally to do debugging with fb employees and this blocks the rollout.

So, we already hide lots of UI for force-installed extensions (example: we don't prompt the user with any permission prompts). My inclination would be to just hide this notification for all force-installed extensions, and not add a policy to control this behavior.

Dominic/Kay - can you have someone chime in from the privacy side? Because if that's acceptable to you guys, I think it's a simpler/cleaner solution.

+Devlin

My gut feeling is that the debugging protocol is on a similar scariness level as an enterprise injecting SSL certificates and extensions with invasive content scripts and web request API based logging. If chrome://extensions lists the capability of the extension to see all your traffic, I think this is reasonable.

That said, I would like to understand why we have introduced the warning in the first place. That team should probably sign this change of.

Debugging gives you a little more control and power than content scripts do, and has a very specific use case (debugging :)).  Given this, we wanted to make sure users knew exactly what was happening, and why, and had an escape hatch.

Re policy extensions, this isn't *drastically* more powerful than other things we allow policy to do without warning the user; however, we have always shown the warning.  The reason I'd push for having an explicit policy (rather than just letting policy extensions use it automatically with no UI by default) is because there could be some enterprises that desire or rely on the behavior to inform their users of what is happening.  If the environment is such that it should be implicit, then the enterprise has that choice.  I'm just not comfortable automatically "opting in" every enterprise to the behavior change.

What's the specific concern, though - what specifically can an extension do with chrome.debugger API that it can't otherwise do (i.e. a force-installed extension can read cookies from any site, monitor and modify *all* network traffic, including SSL, change the DOM in any tab, etc - all with no warning to the user).

If the sole driver of having a policy here is that "some enterprises may rely on the behavior to inform their users of what is happening", then I'd like to understand why (what's the use case where an enterprise would force-install an app with chrome.debugging API, and would want users to know that it's doing stuff in the background, when we don't provide ways to know that the same extension is tracking keystrokes, monitoring network traffic, etc).

It's been awhile since I've looked in-depth at the debugger API, but my recollection is that it allows for more powerful interaction, including heavier modification of network requests (e.g. webRequest can't modify the response body) and emulation of user interaction.  Pavel, or maybe +Mustafa, might remember more off the top of their heads for what sets the debugger API apart.

At a higher level, we currently *do* have a infobar warning for extensions using the chrome.debugger API, even though we don't for e.g. content scripts or webRequest, so we already did come to the conclusion that the API was more dangerous.**  Additionally, for other powerful APIs (like proxy), we *do* have a native warning after installation, even for policy-installed extensions.  I think that having users aware of this is beneficial, and I think that some enterprises can also want their users to be aware - either for disclosure purposes (e.g., this data is being gathered) or even for alarm (e.g. if an extension was compromised and the debugging wasn't expected).  If we had, from the start, said that policy extensions are exempt from the debugging infobar, and it's the policy/extension's responsibility to make the user aware, then that's a fairly reasonable stance (though I have a preference for native UI).  But we didn't make that choice, and as a result, it would be difficult to prove that enterprises aren't relying on the current behavior, and the cost of a false negative here (not informing the user), could be high.

**We can, of course, revisit this decision, but if the argument is "the debugger API doesn't allow anything more than other extension APIs", I think that's an independent discussion to policy-installed extensions.

Here is what can and can't be done using chrome.debugger:

- there is a way to read cookies from any site
- there is a way to emit input events
- there is no way to modify any of the network traffic, but there might be one in the future

We've always considered cookie access as by far the scariest thing API can do, so if policy extensions can do it today, security-wise it is safe to proceed without the policy.

I'm also convinced that organizations that use this API under policy (FB) will only do it for data collection and would need to be aware in depth of how browser works. For all other capabilities (good or bad), there are easier-to-use APIs that are more lightweight and efficient.

Btw, I don't think that there was much though behind the infobar at the first place. API emerged before we had a lot of capabilities exposed to extensions and hence seemed scary. We just wanted a complete disclaimer to be able to do anything we'd like under that API. We immediately followed up with a way to silent that infobar using about:flags.

>> But we didn't make that choice, and as a result, it would be difficult to prove that enterprises aren't relying on the current behavior, and the cost of a false negative here (not informing the user), could be high.

I understand what you are saying and formally you are absolutely correct, however I can't come up with a use case where it would make sense for policy holder. Even if there is a policy extension that uses chrome.debugger and relies upon current behavior, it can follow up with the explicit warning bubble at no cost comparing to maintaining something that uses chrome.debugger. I am absolutely sure there is no policy that uses it today though - infobar is too invasive.

One way or the other, unblock me, please! I was going to spend 15 minutes on this, now I'm ready to drop it due to the bureaucracy.

Thanks for looking into this. For us either option would solve our use case and unblock us.

My 2 cents here is the warning dialog wouldn't be useful against an attacker that would attach debugging, read cookies, detach in a split second. Possibly doing so after a navigation event to a particularly valuable URI like a gmail login. It's unlikely the user could dismiss, or even read, the dialog because the debugging protocol leaked cookies and the dialog would hide itself. It could be providing a false sense of security. I think the dialog is mostly an hindrance to legitimate use cases.

But I want to stress that in practice it makes no difference to us if we need to set another enterprise policy or not to silence this warning. The only important point is unblocking the issue.

I just finished chatting with meacer@ offline, and we both agreed that, while we're a little uncomfortable with removing the UI unconditionally for policy installed extensions, it's probably fine as long as other folks are on board (which it sounds like they are).  So let's go ahead and do that approach.

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

commit c64e1a693b3207b89733909793721b9af2ca5cd2
Author: pfeldman <pfeldman@chromium.org>
Date: Fri Feb 24 01:22:50 2017

DevTools: disable the Chrome tab debugging warning for force-installed extensions.

BUG= 693621 

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

[modify] https://crrev.com/c64e1a693b3207b89733909793721b9af2ca5cd2/chrome/browser/extensions/api/debugger/debugger_api.cc

The patch here seems pretty small, is there anyway that we could get it merged into M57? It'd be pretty impactful if we could get this moved up by a release.

Thanks guys, and sorry for the bikeshe...er..."bureaucracy", but I do think we ended up with the right call here.

Late in the game for M57, but agreed that it's a small safe change so requested the merge.

Big thank you for making this happen and in less than a week. This is great :).

This will make it a lot easier for us to diagnose our own issues in the wild and have better data to share if we find chromium perf issues. Cheers!

Ah, we are merging? I'll keep it open then.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge your change to M57 branch 2987 by 5:00 PM PT Monday (02/27) so we can take it in for next week last M57 Desktop Beta release before Stable promotion. Thank you.

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

commit 575c533bb9a2e26a72fb1988d9d014bc13dc052e
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Mon Feb 27 22:49:44 2017

DevTools: disable the Chrome tab debugging warning for force-installed extensions.

BUG= 693621 

Review-Url: https://codereview.chromium.org/2696283007
Cr-Commit-Position: refs/heads/master@{#452706}
(cherry picked from commit c64e1a693b3207b89733909793721b9af2ca5cd2)

Review-Url: https://codereview.chromium.org/2722703002 .
Cr-Commit-Position: refs/branch-heads/2987@{#706}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/575c533bb9a2e26a72fb1988d9d014bc13dc052e/chrome/browser/extensions/api/debugger/debugger_api.cc

Fix verified in: Chrome Beta @ Version 57.0.2987.88 beta (64-bit)

Thanks again.