Simple-tab-groups: Usage blocked by permanent private browsing mode on Tor Browser

[rufketo]

The add-on currently cannot be used on Tor Browser, as it only shows the add-on page "Please disable add-on access to private mode in windows:" (instructions page) when clicking on the toolbar button of the add-on. This is even the case when "Always use private browsing mode" is disabled in the browser settings. Differently from vanilla Firefox, the add-on settings in Tor Browser do not comprise an option to "disable add-on access to private mode".

To Reproduce

1. Install Tor Browser and add-on. -> A toolbar icon in the form of a warning triangle is shown.
2. Click on the add-on‘s toolbar icon. -> The instructions page mentioned above is opened.
3. Go into the add-on details. -> You will not find an option as depicted in the instructions page.

Expected behavior

• Solution A: Requirements A and B

  - Solution B: Requirements A and C

• Requirement A: Do not show the instructions page in Tor Browser when private browsing mode is actually disabled.

• Requirement B: There should be an option to disable the check for private browsing mode in the add-on’s settings and on the instructions page. Maybe show a warning why that may lead to unintended results.
• Requirement C: Show a message why the add-on cannot be used in private browsing mode.

Desktop

• Gnome Desktop 3.38.1 on Fedora 33
• Tor Browser 10.0.2
• Simple Tab Groups 1.2

[Drive4ik]

The fact of the matter is that the tor browser was created for privacy. And in private mode, STG has very meager capabilities - everything that a browser gives. More than half of the addon will not work.
I will not rewrite the entire tor browser addon.

[rufketo]

@Drive4ik Thanks for your response!

From your answer I can conclude that solution A would require much work, so I think some version of solution B seems to be more appropriate.

For the purposes of using the extension in Tor Browser with private browsing mode disabled, it is only required to remove following lines in function init() in background.js (I have already tested this):

        let isAllowedIncognitoAccess = await browser.extension.isAllowedIncognitoAccess();

        if (isAllowedIncognitoAccess) {
            openHelp('disable-incognito');
            throw '';
        }

…because isAllowedIncognitoAccess() cannot be made to return false in Tor Browser.

That means we need a way to disable the check when private browsing mode is disabled. For this, browser.extension.inIncognitoContext could suffice. Alternatively, the incognito property on window could suffice, please see the docs the docs as I never programmed a Firefox add-on. [Legend: added, removed]

Maybe it would also suffice if we would set "incognito": "not_allowed" in the manifest.json and completely remove the disable-incognito.html.

For the "Requirement C" stuff in my opinion a short statement in the extensions description would suffice.

What do you think? Would you cooperate when I provided a pull-request?

[rufketo]

Note that using Tor Browser with private browsing mode disabled is in my opinion a valid usage scenario – it allows you to stay anonymous towards websites while not requiring you to bookmark all URLs you might want to find in the future again.

[Drive4ik]

Hi!

I have already tested this

Did you really test an addon on the Tor browser with these strings removed? (which prevent the addon from working in incognito mode) And how does it behave in this case? Are there any bugs or features that do not work?

Maybe it would also suffice if we would set "incognito": "not_allowed" in the manifest.json and completely remove the disable-incognito.html.

That's what this page was created for. Because if you specify in manifest.json "incognito": "not_allowed", users have no possibility to turn off incognito in the addon settings. This is just like your situation with Tor. Only here is the bug - in a certain case the browser does not turn off the incognito mode for the addon, although the manifest clearly states that "incognito": "not_allowed". This hides the choice of incognito for the addon for the user. This means that the addon does not work because the incognito mode is turned on and cannot be turned off. The situation is exactly like yours, only for thousands of users.
That's why a workaround with disable-incognito.html was invented.

No need for pull-request. I know about this problem and I do not like it myself. If this bug is fixed in FF with auto disable incognito mode, I will gladly delete that html and add the parameter to manifest.json.

[Drive4ik]

See #419 #420 #424

[rufketo]

I have already tested this

Did you really test an addon on the Tor browser with these strings removed (which prevent the addon from working in incognito mode)

Yes, I installed a modified XPI of the add-on.

And how does it behave in this case? Are there any bugs or features that do not work?

The add-on works as expected in non-private windows. The only obvious user-facing bug I encountered is that the add-on also runs in private windows while then only showing a spinner:

Now, I discovered that with @im314's hint (disable extensions.allowPrivateBrowsingByDefault in about:config) the option to disable the add-on in private windows becomes available in the add-on settings as it is with vanilla Firefox. So that would be a work-around for the current official add-on version in Tor Browser. (Note that directly after changing above configuration, the about:addons preferences GUI shows wrongly that "Run in Private Windows" is on "Don't Allow" in incognito mode while it is actually enabled. You need to click on "Allow" and then "Don't Allow" to really disable the add-on in incognito mode).

Maybe it would also suffice if we would set "incognito": "not_allowed" in the manifest.json and completely remove the disable-incognito.html.

That's what this page was created for. Because if you specify in manifest.json "incognito": "not_allowed", users have no possibility to turn off incognito in the addon settings. This is just like your situation with Tor. Only here is the bug - in a certain case the browser does not turn off the incognito mode for the addon, although the manifest clearly states that "incognito": "not_allowed". This hides the choice of incognito for the addon for the user. This means that the addon does not work because the incognito mode is turned on and cannot be turned off. The situation is exactly like yours, only for thousands of users.
That's why a workaround with disable-incognito.html was invented.

No need for pull-request. I know about this problem and I do not like it myself. If this bug is fixed in FF with auto disable incognito mode, I will gladly delete that html and add the parameter to manifest.json.

Ok, as I understand you and the people in #419, the bug in Firefox is that while "incognito": "not_allowed" is in manifest.json, browser.extension.isAllowedIncognitoAccess() may still return true and the browser hides the setting about:addons. Please let me know if I understood correctly so that I can file a bug on Mozilla's Bugzilla.

However, I think it could be possible to make the add-on behave correctly in all the circumstances even with the mentioned bug in Firefox. This is my new idea for the algorithm:

• If browser.extension.inIncognitoContext:
  
  
  
  • If browser.extension.isAllowedIncognitoAccess(): Show the disable-incognito.html.
  
  
  • Else: Show a message that Firefox is buggy.
  
  
• Else: Operate normally

[rufketo]

I said:

Ok, as I understand you and the people in #419, the bug in Firefox is that while "incognito": "not_allowed" is in manifest.json, browser.extension.isAllowedIncognitoAccess() may still return true and the browser hides the setting about:addons.

Now I can't verify this. I created minimal test extension for that purpose. Summary of findings.md:

• If "incognito": "not_allowed" in manifest.json:
  
  
  
  • If extensions.allowPrivateBrowsingByDefault: true in about:config (which is the default for Tor Browser): The extension cannot be installed. (bug)
  
  
  • Else: browser.extension.isAllowedIncognitoAccess() always returns false.
  
  
• Else:
  
  
  
  • If extensions.allowPrivateBrowsingByDefault: true in about:config:
  
  
  • browser.extension.isAllowedIncognitoAccess() returns true
  
  
  • This cannot be changed by the user (bug)
  
  
  • Else: browser.extension.isAllowedIncognitoAccess() returns the value configured by the user.
  
  

So it seems there are actually two bugs in Firefox. I created these issues in Mozilla's bugtracker:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1678841
• https://bugzilla.mozilla.org/show_bug.cgi?id=1678847

I still propose the algorithm I mentioned in my previous comment for this extension.

[Drive4ik]

Yes, you got it all right. And you correctly made a logical chain to output a window with private mode off. There is only one catch... webextensions has no access to about:config page and its parameters...
https://wiki.mozilla.org/WebExtensions/FAQ#Does_the_WebExtensions_API_provide_access_to_preferences.3F

only the following are available:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browserSettings

[Drive4ik]

I will leave the issue open so as not to forget. You might be able to convince FF dev's to fix it.

[rufketo]

Thanks for your patience.

webextensions has no access to about:config page and its parameters

I did not want to propose that the extension changes settings. My opinion is that it would be better to replace the simple check of browser.extension.isAllowedIncognitoAccess() with that "algorithm" (copied from above):

• If browser.extension.inIncognitoContext:
  
  
  
  • If browser.extension.isAllowedIncognitoAccess(): Show the disable-incognito.html.
  
  
  • Else: Show a message that Firefox is buggy.
  
  
• Else: Operate normally

That way we would walk around the bugs and pitfalls of just relying on browser.extension.isAllowedIncognitoAccess(), I think.

[rufketo]

And I think setting "incognito": "not_allowed" and removing the incognito.html logic would also be a solution (nowadays). But the solution above would less likely break things.

[Drive4ik]

Not everything is as simple as it seemed)
Let's see what happens :)

[rufketo]

Thank you very much!