This is working as intended.

In this case, once a resource has been loaded from an intercepted page, it's possible for that resource to be used in other contexts (e.g. consider an intercepted resource stored into the cache).

During the design review and implementation of the Policy-provided certificates (which is the distinction here, as you note CPanel in step 1), this was an intentional mitigation to communicate to users about the use of the certificate. We explored (but could not assure) name constraining the use of the CA certificate to the enterprises CPanel domain (which was too limited), and we explored a message similar to the Android messaging in which a consistent warning about possible MITM is displayed. This is handled by the PolicyCertServiceFactory to intentionally signal such usage (see https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/policy_cert_service_factory.h?rcl=e21c061fd4207addb26de6913693364d19585248&l=46 )

Based on offline discussion with rsleevi: This is working as intended, however it is not ruled out that we may change the intention. Thus re-opening to discuss whether we should change the intention.

Would it be possible to set a "tainted" bit on any resource that came through an admin-configured local trust anchor and base the security indicator on whether any tainted resource is being used on the page?

I'm concerned about warning fatigue. In my opinion the current approach is very unsatisfying because it's close to impossible to understand for users.

No, the //net stack does not allow setting such bits, by virtue of intentionally trying to separately layer these notions.

Further, this doesn't achieve the security goal, given that a 'tainted' load may also affect any web storage mechanism - such as localStorage, cookies, etc. All of those would have to be enabled for taint tracking, and if the boundary was drawn in that way, we would have to expend significantly more effort to maintain it.

I understand your concern about warning fatigue, but I also think we should do the right thing to the user and notify them when their connections may be affected. I would prefer we more consistently and thoroughly warn about potential monitoring, when said monitoring is unrestricted. We intentionally did not go down that route at the implementation time, due to the lack of ability to consistently restrict such usage (e.g. to domains), nor did UI and Enterprise want to offer that level of configurability.

Do you have any information or data to suggest there is a risk of warning fatigue? For example, how many users have enterprise MITM certificates deployed, how and in what cases are they used, and what the potential user behaviour you think is desirable. Absent that, I think the current approach is the minimum necessary, and I don't think we have any new data that would justify re-evaluating.

I don't think warning fatigue is the right lens to look at this. For one thing, I don't consider the office indicator to be a warning; it's more of a disclosure. IMO it's not realistic to expect users to notice and understand what's going on every time it appears and disappears. Instead, I would like users to understand that their browsing session is not private from the machine's owner. I also don't expect we're going to make a meaningful dent in how often the "warning" is shown by trying to taint resources: there will be many common situations in which every resource is MITMed or a content script is injected on every page.

So rather than trying to reduce how often the office indicator is shown, I'd advocate for a once-per-session disclosure UI that the user sees, along with helpful Page Info strings.

Triage question: is there more to do here?

OP - what are your thoughts about comment 4 and comment 5?

Marking back as WontFix, if that is wrong please reopen.

WontFix is fine, thanks. Discussion around the more general theme of enterprise disclosures will continue in issue 831572.

Whoops, that was too fast. One more question for Ryan: Since an attacker may poison cache, cookies or any other kind of state, should the office building indicator not be shown if a local trust anchor has ever been used in the lifetime of the profile (and not only the current session)?

Re #10: Isn't this already a property of the user profile, not the session?

  g_browser_process->local_state()->GetList(prefs::kUsedPolicyCertificates);

Thank you, you're right. I guess that answers my questions, then... ;)