Hm, IIRC there also was the idea to somehow make the UI show which extensions are active for a given page regardless of where the extension comes from? If that isn't just an artifact of my fallible memory, then maybe this should integrate with that effort?

Interesting.  I'm not entirely sure how this would look, or if it would be beneficial to the user (I think that the vast majority of enterprise extensions just inject everywhere).

Re #1, we are working on allowing users to restrict script injection, and badging extensions that have injected.  This might be sufficient.  +bklmn@ FYI.

One thing to note here is that there are plenty of ways these extensions could modify a page, not just content scripts.  Finding all of them and badging appropriately would be very difficult, and I'm not sure we'd want to give users a false sense of security.

Would be interested in what ways you know of - I was thinking we'd need to badge any page that either:

a) loads a resource from an origin for which an extension has declared webRequest host permissions
b) has tabs permission for the origin
c) has defined content_scripts for the origin

I don't think we want to wait for the extension to inject scripts, because we don't want extensions to wait N seconds and then inject scripts to try to avoid users noticing. We should just badge the page if the extension can do it at all.

Are there other cases we should be aware of?

> loads a resource from an origin for which an extension has declared webRequest host permissions

Note that webRequest permissions aren't different from regular host permissions.

> has tabs permission for the origin
I think by this you mean host permissions ("tabs" just lets you see the URL, host permissions lets you inject via chrome.tabs.executeScript, modify cookies, etc).  So this actually ties into a).

There are some other edge cases, too - e.g. pageCapture, which implies all urls.

If we accept that we only care about *if* an extension can modify the page (rather than *does* the extension), I think this does become a lot simpler.


That said, I'd still be curious how often this indication *wouldn't* show across all sites.  If we find that the vast majority of enterprises have at least one extension that could monitor all traffic, I wonder if it would instead make sense to just have a global warning somewhere if the user is part of an enterprise policy, rather than attaching it somehow to each site.  That might also reduce the risk of warning fatigue.

I suspect you'd see lots and lots of "buildings" instead of "green padlocks" -
 for example, in our google.com corp browser, I suspect Password Alert would taint every single page.

It's up to privacy and security if hiding the padlock for the vast majority of corp browser users is worth the extra disclosure - I don't really understand the subtleties of what's encoded in that padlock icon and the ramifications of changing it to "buildings" for hundreds of millions of enterprise users.

Is there a good owner for this?  Drew, would this be your team, or the privacy team?

My team will own this I think. Right now up to David to chase down privacy approvals (I think we're close) at which point isandrk@ can tackle.

Agreed with Devlin that we should base the indicator on permission to read or modify a page, not the actual act of reading or modifying it.

Emily, as Drew points out above, implementing this will lead to many users never seeing the green lock. (As he points out e.g. Googlers would lose the green lock because of the Password Alert extension.) Would that be reason for concern or working as intended?

I'd also like to reiterate that my strong suspicion (though I don't have data, and don't know how easily we could get it) is that enterprises that add policy-installed extensions are very likely to have at least one extension that runs *everywhere*.  So chances are this wouldn't just be for googlers, but rather a semi-permanent change for all enterprise users.

Not saying that's necessarily bad - I'm all for transparency - but it might be worth designing with that in mind.

Every ad-blocker user in the world would be affected as well.

I don't think this proposal is very practical or good for the security ecosystem as a whole.

Eric, note that this is only intended for admin-configured extensions, i.e. unmanaged users wouldn't be affected.

Re #14: Got it; I should've said "Any admin-configured ad-blockers" which is a subset of "Every". 

Nevertheless, I still don't believe this change would be good for the ecosystem. Corporate users will become accustomed to seeing this UI on every HTTPS page. It further feels weird to notify the user of monitoring only on HTTPS pages and not HTTP pages (which introduce even *more* likelihood of monitoring). The change will encourage third-parties to stop using extensions and start using other mechanisms for hooking Chrome that do not light up this warning indicator. Users may transition to other browsers without such notices ("Oh, only Chrome is spying on me."), etc.

Agree with #16 that this is probably too common to be meaningful. I think a disclosure at session start would be more effective rather than trying to remind users on every page load.

I'm not clear - why are we treating this case differently than MITM proxies? Is it because we feel that page-modifying extensions are more common?

In any case, happy to roll this into our start-of-session disclosures if Privacy is OK with this in general.

Re #18: personally I think we'll have better results with a start-of-session disclosure for MITM proxies as well (https://bugs.chromium.org/p/chromium/issues/detail?id=802215#c5 and preceding discussion). That said, I think it does make a little more sense for MITM proxies beacuse (a) probably less common than the extensions case, and (b) the security indicator is mostly about connection security, really -- to which MITM proxies are relevant but extensions are not.

The problem with session-start disclosures is that not all users get to see them, i.e. they may walk up to an already started session. (I expect a significant fraction of Managed Session deployments to disable idle-logout.)

If we consider replacing the green lock by an office building too invasive, maybe we could consider one of the following options:
a) place the office building next to the green lock (and add explanatory text to the origin info bubble)
b) place the office building at the right edge of the URL bar (similar to "popup has been blocked" icon)

In any case, I would advocate for a consistent solution for both admin-configured trust roots and extensions -- most users likely don't understand the difference of being MITM'd versus being monitored by an extension, and my point is that they shouldn't need to.

I'm not sure that we should be treating "users sharing the same session and missing disclosures" as a real use case - there are *so* many problems with this method of use (first user could sign in to Google, and use search history to track search activity of second user, first user could enable WebRTC permissions and location permissions and use those to spy on the second user via an open tab, etc. It's such a poisonous and obviously untrustworthy mode of using the device that I don't believe we should be planning our disclosure UI around it.

In any case, if what you are saying is "Chrome should be displaying a disclosure when starting the browser whenever MITM certs or content-script extensions are used" - I think this proposes a really invasive change to how our enterprise users use Chrome. I could maybe do this for Chrome OS public sessions, but if the ask is that we start throwing up scary notifications in front of every employee of every enterprise using Chrome, then I think that's a non-starter as it would drive enterprises to flee our platform for others that are less aggressive about user disclosure.

+blumberg for enterprise PM guidance, but I think this is only something we would entertain for the narrow "chrome os public sessions" use case.

I think we should treat everything that we suspect is going to happen as a real use case. If we really want to exclude "users sharing the same session" from our consideration, in my mind the first step would be to hard-code a very low value for idle-time logout in Public Session.

In general, we've never treated this as a real use case (none of our extension or content permissions auto-reset over time for example). If you walk up to a browsing session you may miss out on disclosures/permission grants that were previously completed (I can grant Location permission to google.com for example, and anyone who walks up to this session just inherits this).

The reason I'm pushing back on this is I've seen where trying to address these kinds of use cases leads us - it leads us into a place that's actively hostile to our core use case which is a single-user session. We end up proposing things like permissions that expire after the device goes idle, persistent on-screen notifications to users that cannot be dismissed, etc.

That said, I'm not opposed to something narrowly focused on public session login expiration, as we've discussed offline. But let's take that out of this discussion which I *thought* was about disclosures in the general case of managed chrome on all platforms.

Drew, as we're discussing disclosures in general, that discussion should include all use cases. During the course of that discussion we might come to the conclusion that some use cases should be treated differently from others, but I don't consider it fair game to exclude specific use cases from the get-go.

Emily, do you have thoughts on a)/b) from comment 20?

triage: Untriaged w/ owner -> Assigned