Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: minimal permission option? #201

Open
sammymax opened this issue Jan 7, 2019 · 9 comments
Open

Feature request: minimal permission option? #201

sammymax opened this issue Jan 7, 2019 · 9 comments
Milestone

Comments

@sammymax
Copy link

sammymax commented Jan 7, 2019

I find it somewhat ironic that an extension meant to enhance privacy needs the <all_urls> permission. What if there were a "minimalist" setting where:

  • websites aren't auto-reopened in temporary containers, they're opened in their current container
  • there's no automatic interoperability with other container add-ons

Or at the very least can we get better evidence that the Github source is what's installed on our computers? I personally don't find these extra features useful and I'd much rather have a simpler extension that doesn't need permissions--something like Containers on the Go but open-source and with Ctrl-T overridden.

@crssi
Copy link

crssi commented Jan 8, 2019

^^ Thats full of BS.

I find it somewhat ironic that an extension meant to enhance privacy needs the <all_urls> permission.

Well as you said for auto mode this is a must.

Or at the very least can we get better evidence that the Github source is what's installed on our computers?

And how do you do that?
Don't be lazy. Download AMO version, download Github version, UnZIP and do a file comparison.

I personally don't find these extra features useful

Fine... but auto mode is the main point here for me.

something like Containers on the Go

Ironically you are suggesting a web extension, which doesn't even have an open source.

@sammymax
Copy link
Author

sammymax commented Jan 9, 2019

Ctrl-T override in auto mode is the most important and certainly doesn't require <all_urls>, but I guess we have different opinions. I'd certainly use the closed-source Containers on the Go over a project with unreasonable permissions and maintainers that call "BS" on a feature request.

@crssi
Copy link

crssi commented Jan 10, 2019

And there you go again.

I'd certainly use the closed-source Containers on the Go over a project with unreasonable permissions and maintainers that call "BS" on a feature request.

  1. you are posting negative criticism and call it a feature request.
  2. and another one with a "maintainers". In which virtual reality you decide that I am a maintainer. I have nothing to do with TC, except that I am a grateful user.

Did you even read my previous post or you just stuck on "BS"?

@sammymax
Copy link
Author

Did you even read my original post? There's clearly a feature request stated.

  1. and another one with a "maintainers". In which virtual reality you decide that I am a maintainer. I have nothing to do with TC, except that I am a grateful user.

In that case I'll wait for the opinion of someone who actually does have something to do with TC.

@stoically
Copy link
Owner

The core feature of cancelling requests in the default container and reopening them in a new Temporary Container needs the <all_urls> permission. Nothing I can do to change that.

Regarding the source, as mentioned on AMO

If you want an easy way of taking a look into the source that actually is installed when clicking the "Add to Firefox" button, you can use the excellent Extension source viewer Add-on.

@stoically
Copy link
Owner

Going to make the following permissions optional and request them on demand

  • Automatic Mode

    • tabs to check the tab.url for about:blank / about:newtab / about:home
    • <all_urls> to allow reopening websites that load in the default container, which happens if
      • Advanced Don't instantly reopen Automatic Mode is active
      • Opened by external programs
    • management to avoiding conflict with other container add-ons which can also reopen the link
  • Isolation

    • tabs, <all_urls>, webNavigation, webRequest, webRequestBlock and management to do its job properly
  • Context Menu

    • contextMenus
    • tabs because it needs access to tab.url

This will make it so that no permission prompt is made on install.

Still required permissions to have the basic toolbar icon functionality: contextualIdentities, cookies and storage.

@stoically
Copy link
Owner

stoically commented Jul 5, 2019

Well, there goes that plan. Firefox does not support requesting <all_urls> as optional permissions (and management neither, although it's stated that it should work, Firefox will throw a warning if you put in the optional_permissions key in the manifest.json). And since they are the only ones (besides tabs, but who cares about that) that pop up as permission request, it doesn't make any sense to implement any of that.

If someone wants to give it a go over at Firefox's Bugzilla and ask if they're willing to add <all_urls> and/or management, let me know. Until then, closed.

@stoically stoically removed this from the v1.0 milestone Jul 5, 2019
@stoically
Copy link
Owner

stoically commented Jan 29, 2020

So it seems that this was fixed on Firefox's end, it's now possible to request <all_urls> programmatically; and they seem to be willing to land a patch that accepts management as optional permission as well (Bug 1458585 / Bug 1630419 should land in FF 77).

Important additional functionality before landing:

  • Request permissions when importing preferences

Implementing this makes especially sense considering that web developers use TC to just get throw-away containers on click and might not want to grant massive permissions in that case.

Something to consider: Deploying managed preferences wouldn't work anymore for things that have optional permissions.

@stoically
Copy link
Owner

Blocked by Bug 1618500

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants