1516465 - enterprise policy opt-in for incognito value

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P2)

Description

[Shane Caraveo (:mixedpuppy)]

from rob_wu

If we proceed with disabling extensions by default in PBM without offering opt-in for enterprise users, then we can expect complaints from enterprise users. Here is a similar, longstanding bug in Chrome with input from external (enterprise) users who complain about the lack of incognito support for pre-installed extensions:
https://bugs.chromium.org/p/chromium/issues/detail?id=173640

Comment 1

[Shane Caraveo (:mixedpuppy)]

Felipe, any guidance on making this happen?

I think we'd want a way:

• to support a list of extension IDs that can run in private browsing without user action
• to prevent a list of extension IDs from being enabled in private browsing by the user
• to prevent any change of the private browsing allowed flag globally

Comment 2

[Shane Caraveo (:mixedpuppy)]

Mike, what do you think of the options in comment 1? Is there anything else I didn't think of?

Comment 3

[:Felipe Gomes (needinfo for replies!)]

From the technical side, you can probably just extend the Extensions policy ([1] and [2]) by adding a new property which takes an array of addon ids that has the permission to run in PB mode.

The "Locked" property also takes a list of addon ids, so you can follow its example.

And then you could also look at the Locked property as a way of implementing #2. Currently its documentation says [3] it is meant for prevent installing/disabling add-ons, but we could change it to mean: "prevent making any changes to this add-on, including disabling, uninstalling or changing its PB-mode setting".

[1] https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/browser/components/enterprisepolicies/schemas/policies-schema.json#288

[2] https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/Policies.jsm#577

[3] https://github.com/mozilla/policy-templates/blob/master/README.md#extensions

Comment 4

[Mike Conca [:mconca]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #2)

Mike, what do you think of the options in comment 1? Is there anything else I didn't think of?

I can definitely see enterprise customers wanting all extensions to run in all contexts (PB and non-PB windows), presumably so that any corporate extensions always run. I think this is covered under the three options you listed. I'll ask mkaply to chime in, as well.

Comment 5

[Mike Kaply [:mkaply]]

Yep, I agree. Should be straightforward per the comments from felipe.

We should add a new category under extensions for this, not reuse Locked.

Note that Chrome decided against doing this.

Comment 6

[Shane Caraveo (:mixedpuppy)]

(In reply to Mike Kaply [:mkaply] from comment #5)

Note that Chrome decided against doing this.

Can you expand on that? Looking a the end of the bug it doesn't seem that way, but I didn't read any details.

Comment 7

[Mike Kaply [:mkaply]]

Comment 28

https://bugs.chromium.org/p/chromium/issues/detail?id=173640#c28

1. Incognito: No current plans to allow extensions within Incognito Mode without the user opt-in.

They ended up morphing the bug into primarily a discussion of "Allow access to file URLs"

Comment 42

https://bugs.chromium.org/p/chromium/issues/detail?id=173640#c42

This is unfortunately explicitly not permitted by our current privacy guidelines. What is possible is to completely disable incognito by policy if you prefer to make sure all navigation is subjected to your policies and monitoring instruments.

As for needing clean profiles for testing/temporary login information - creating multiple regular profiles is a viable alternative to using incognito even if slightly slower to create.

I am aware this is not ideal answer but incognito is considered a safe harbor for users as far as Chrome itself is concerned and this can not be guaranteed if extensions are permitted to run inside its scope.

Comment 8

[Shane Caraveo (:mixedpuppy)]

Interesting, makes sense and worth thinking about.

Comment 9

[Mike Conca [:mconca]]

I can see valid use cases for this feature: a library might want to run all sessions on a public terminal in private browsing (cleans up cookies, history, etc.) but still might want to force an extension to run in that mode (e.g. one that tracks usage time on the terminal). Same for an internet cafe.

That said, I can see where this could be easily abused. The above-mentioned internet cafe, for example, could advertise private mode for all its terminals, but secretly have an extension recording all cookies, history, traffic.

At this point I think I come down where Chrome did: extensions in private browsing windows must require an explicit opt-in by the user. For enterprise customers, the solution is to disable private browsing entirely. Not ideal, but it closes a potential attack vector that would seriously damage trust in Firefox's private browsing mode.

:mkaply, does our policy engine allow the disabling of private browsing? If not, we should get a bug filed.

Comment 10

[Mike Kaply [:mkaply]]

:mkaply, does our policy engine allow the disabling of private browsing? If not, we should get a bug filed.

Yep. And I'm totally OK with doing what Chrome does here.

Comment 11

[Mike Conca [:mconca]]

Closing as WONTFIX per the last several comments.