1457001 - Require an explicit opt-in to enable extensions in Private Browsing

Status: RESOLVED DUPLICATE of bug 1511636

(WebExtensions :: General, enhancement, P3)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

We currently allow Extensions in private browsing mode, while Chrome blocks extensions from private browsing by default, and requires the user to opt-in (whilst showing a warning to the user about the consequences of allowing extensions in private browsing[1])

It's a somewhat philosophical decision - there are definitely a lot of valid use cases for extensions (e.g. anti-tracking, adblocking) in private browsing, so just blocking extensions access to private browsing would likely end up harming the users more than helping.

I see the following options:
a) leave the existing behavior, at the risk that extensions my be capturing data in private browsing sessions without user knowledge

b) adopt chrome's opt-in approach, and require users to enable the extensions they want in private browsing mode via an additional step

c) something else? We could add UI for clearing storage.local/.sync for example, but ultimately that's something extensions would have to allow us to do (they could store data server side where we can't remove it). 


This is well known (at least to the add-on team) but I wanted to file this bug so we at least have something on file for an explicit decision here (please dupe if this exists, I couldnt find anything). 


[1] "Warning: Google Chrome cannot prevent extensions from recording your browsing history. To disable this extension in incognito mode, unselect this option."

Comment 1

[Croydon]

What about leaving it active by default for the already named reason that anti-tracking/anti-spying add-ons can work, but also that user stay in their known environment (e.g. vertical tabs, other UI elements, website helpers etc.)
- and in addition to that consider an opt-out functionality for the end users.

Example: Users might want to use add-ons which analyze website content/webservers in non-private windows, but since these kind of add-ons might save and/or send this data, users might want to opt-out such add-ons in private mode.

Comment 3

[(no longer active)]

I think the right default as adopted by the majority of the browsers is disallowing extensions on private windows by default (BTW similar concerns apply to file:// URIs which we've now sandboxed in its own content process).

The idea of providing UI for clearing extension data is interesting to explore, I'm not sure what technical implications it may have but from a privacy standpoint it's definitely desirable.

Comment 6

[Luke Crouch [:groovecoder]]

:ddurst or :jorgev - is there any way to get the list of add-ons that have webRequest and <all_urls> host permissions? Can we sort that list by # of installs?

Comment 7

[Shane Caraveo (:mixedpuppy)]

(In reply to Luke Crouch [:groovecoder] from comment #6)
> :ddurst or :jorgev - is there any way to get the list of add-ons that have
> webRequest and <all_urls> host permissions? Can we sort that list by # of
> installs?

a) this question is seemingly unrelated to this bug
b) not the right place to ask it anyway
c) ping mconca via email or irc, he has scripts to get that stuff

Comment 8

[(no longer active)]

The reason why this question is related to this bug is that extensions that have webRequest and <all_urls> permissions are one of the biggest cases that we're worried about here from the privacy perspective, so knowing how common that case is helps us assess how quickly we should try to address this bug.

Comment 9

[Shane Caraveo (:mixedpuppy)]

(In reply to :Ehsan Akhgari from comment #8)
> The reason why this question is related to this bug is that extensions that
> have webRequest and <all_urls> permissions are one of the biggest cases that
> we're worried about here from the privacy perspective, so knowing how common
> that case is helps us assess how quickly we should try to address this bug.

That context helps.  The work is scheduled, and I have preliminary patches on bug 1345474, which is required to do anything user facing. The plan is to hopefully land that into 65.  There are already designs somewhere for the ui, which is currently opt-in.  I don't see it going any quicker.

Comment 10

[(no longer active)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)
> (In reply to :Ehsan Akhgari from comment #8)
> > The reason why this question is related to this bug is that extensions that
> > have webRequest and <all_urls> permissions are one of the biggest cases that
> > we're worried about here from the privacy perspective, so knowing how common
> > that case is helps us assess how quickly we should try to address this bug.
> 
> That context helps.  The work is scheduled, and I have preliminary patches
> on bug 1345474, which is required to do anything user facing. The plan is to
> hopefully land that into 65.  There are already designs somewhere for the
> ui, which is currently opt-in.  I don't see it going any quicker.

Great, thanks a lot for the update!  Having this in 65 would be quite nice indeed.

Here is a question to ensure that I'm understanding things correctly, if you don't mind.  Would that bug only add support for extensions that specify the "incognito": "not_allowed" permission in their manifest?  Does it change anything about our handling of the "incognito": "spanning" (the default) permission?

Also, are we going to support "incognito": "split" as well?  (AFAICT from the documentation, that permission is required in order to support running extensions inside private windows "properly", but admittedly I may be missing some big parts in my understanding here.)

Thanks!

Comment 11

[Shane Caraveo (:mixedpuppy)]

(In reply to :Ehsan Akhgari from comment #10)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #9)

> Great, thanks a lot for the update!  Having this in 65 would be quite nice
> indeed.

To be clear, it probably wont be turned on in 65.  It will likely take extra time to get all the APIs right, and right now I'm revisiting the basic design.

> Here is a question to ensure that I'm understanding things correctly, if you
> don't mind.  Would that bug only add support for extensions that specify the
> "incognito": "not_allowed" permission in their manifest?  Does it change
> anything about our handling of the "incognito": "spanning" (the default)
> permission?

So one bug is to implement not_allowed support.  Then we will add UX for users to allow an extension to work in private browsing mode.  With that, a spanning extension will not, by default, get access to private browsing.  It will run as "not_allowed" until the user gives permission.  Caveat is that we need to decide what to do with currently installed extensions (e.g. default them to having pb access, or not).

> Also, are we going to support "incognito": "split" as well?  (AFAICT from
> the documentation, that permission is required in order to support running
> extensions inside private windows "properly", but admittedly I may be
> missing some big parts in my understanding here.)

We've been rehashing this today on irc.  The issue is communicating with the background script in a non-private process.  There is a [less than desirable] workaround extensions can use now.

Chrome does not allow extension pages to be loaded into a tab in incognito windows, unless you use split mode.  We currently do allow it, but those tabs cannot directly [as normal] communicate with the background page.  If that's not needed, it works fine.

The tracking bug is blocked by this one, it lists bug 1380812 for split mode.  Given the few extensions that use split mode in chrome store (1300 out of 130K) I don't feel like its a priority.  Some use case may change my mind later.

Comment 12

[(no longer active)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #11)
> (In reply to :Ehsan Akhgari from comment #10)
> > (In reply to Shane Caraveo (:mixedpuppy) from comment #9)
> 
> > Great, thanks a lot for the update!  Having this in 65 would be quite nice
> > indeed.
> 
> To be clear, it probably wont be turned on in 65.  It will likely take extra
> time to get all the APIs right, and right now I'm revisiting the basic
> design.

Noted, thanks.  :-)

> > Here is a question to ensure that I'm understanding things correctly, if you
> > don't mind.  Would that bug only add support for extensions that specify the
> > "incognito": "not_allowed" permission in their manifest?  Does it change
> > anything about our handling of the "incognito": "spanning" (the default)
> > permission?
> 
> So one bug is to implement not_allowed support.  Then we will add UX for
> users to allow an extension to work in private browsing mode.  With that, a
> spanning extension will not, by default, get access to private browsing.  It
> will run as "not_allowed" until the user gives permission.  Caveat is that
> we need to decide what to do with currently installed extensions (e.g.
> default them to having pb access, or not).

Makes sense, thanks for explaining this.

> > Also, are we going to support "incognito": "split" as well?  (AFAICT from
> > the documentation, that permission is required in order to support running
> > extensions inside private windows "properly", but admittedly I may be
> > missing some big parts in my understanding here.)
> 
> We've been rehashing this today on irc.  The issue is communicating with the
> background script in a non-private process.  There is a [less than
> desirable] workaround extensions can use now.
> 
> Chrome does not allow extension pages to be loaded into a tab in incognito
> windows, unless you use split mode.  We currently do allow it, but those
> tabs cannot directly [as normal] communicate with the background page.  If
> that's not needed, it works fine.
> 
> The tracking bug is blocked by this one, it lists bug 1380812 for split
> mode.  Given the few extensions that use split mode in chrome store (1300
> out of 130K) I don't feel like its a priority.  Some use case may change my
> mind later.

Great, sounds good.  Thank you again.

Comment 14

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Luke Crouch [:groovecoder] from comment #6)
> :ddurst or :jorgev - is there any way to get the list of add-ons that have
> webRequest and <all_urls> host permissions? Can we sort that list by # of
> installs?

Cruetten can give you this data - she has written a tool for answering  exactly these sorts of questions. cr, when you get a chance can you provide data here?

Comment 15

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(Tool is https://github.com/cr/webextaware for anyone who is interested)

Comment 16

[Christiane Ruetten [INACTIVE]]

This requires some clarification. Looking for <all_urls> obviously also implies looking for *://*/*/ as well, but what about the various explicit combinations of schemes?

Comment 17

[Christiane Ruetten [INACTIVE]]

Here's a preliminary list filtered by a rather lax standard: It includes individual schemes targeting "<scheme>://*/*", optional_permissions, as well as content_script matches.

https://docs.google.com/spreadsheets/d/1eL7zkYYxVX8DSgcJhAk5FOAdGAvrBvYizLscGP6_7vA/edit?usp=sharing

Comment 18

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Christiane Ruetten [:cr] from comment #17)
> Here's a preliminary list filtered by a rather lax standard: It includes
> individual schemes targeting "<scheme>://*/*", optional_permissions, as well
> as content_script matches.
> 
> https://docs.google.com/spreadsheets/d/
> 1eL7zkYYxVX8DSgcJhAk5FOAdGAvrBvYizLscGP6_7vA/edit?usp=sharing

Thanks cr, looks good!

Comment 19

[Shane Caraveo (:mixedpuppy)]

The opt-in work is progressing in bug 1511636, so am just going to dup this one now.

Comment 20

[KOLANICH]

We currently allow Extensions in private browsing mode, while Chrome blocks extensions from private browsing by default, and requires the user to opt-in

Chrome is a piece of junk Mozilla should not consider as a masterpiece. The only reason of Chrome taking the largest market share is its aggressive promotion by bundling it with software in adware-like fashion, Chrome forks and TV ads. Please stop mocking Chrome!

Chrome marketplace is a junkyard. That's why they need this means.

It's a somewhat philosophical decision - there are definitely a lot of valid use cases for extensions (e.g. anti-tracking, adblocking) in private browsing, so just blocking extensions access to private browsing would likely end up harming the users more than helping.

And I want all the anti-tracking addons be active by default. In fact all the addons I install have their source code audited by me, some because of curiosity, some because I have sent some pull requests.

I see the following options:

a) leave the existing behavior, at the risk that extensions my be capturing data in private browsing sessions without user knowledge
b) adopt chrome's opt-in approach, and require users to enable the extensions they want in private browsing mode via an additional step c) something else? We could add UI for clearing storage.local/.sync for example, but ultimately that's something extensions would have to allow us to do (they could store data server side where we can't remove it).

I vote for something else. Just banning non-free addons and addons with tracking from AMO, so if some mf managed to publish an addon with tracking, anyone had permission to remove the tracking and publish the addon, then remove the original addon by reporting it and substituting it with own one without tracking.