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

Making host permissions optional by default appears to be harmful for extensions with global host permissions #227

Open
ghostwords opened this issue Jun 9, 2022 · 10 comments

Comments

@ghostwords
Copy link

Making host permissions optional by default will introduce another prompt, and a new state where the extension is installed but isn't actually able to do its job. However, users do not read prompts and are already confused by extension icons being hidden by default in Chrome/Edge and easily lost in Firefox.

When a user installs a privacy content blocker or a password manager, the user does not want to wade through multiple prompts just to get the thing to work. Yes, it's good to offer control to users who want it. However, the general user does not want this ability, the general user often does not know how to find the extension's icon. The general user just wants the extension to work.

It's not at all clear how this will curb malicious extensions, but the potential to further confuse users is very clear. Consider that malicious extensions will and do come up with wonderful on-boarding experiences.

Additionally, how will this interact with Selenium/Geckodriver/Chromedriver? Will browsers add command line flags to auto opt into all permissions?

@ghostwords
Copy link
Author

A related Mozilla Bugzilla issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1772433) has been closed as "INVALID".

@ks-rainer
Copy link

My concerns are in two areas. How will this work out for technically challenged consumer users who perceive that the extension suddenly has disappeared and is no longer available. Likewise we have many very large enterprise customers who deal with a variety of end users with varying technical skills, and such customers rely on a vendor to offer a smooth user experience when they roll out our extension. These customers are very worried about a seamless user experience with no distraction for the user. How will enterprise customers be able to deploy the extension and ensure it remains in focus and prevalent in their user environments? We constantly hear from customers that they want more automation around onboarding users and providing a low friction user experience particularly for their security products. This proposal appears counterintuitive to such demands.

@THeflinKeeper
Copy link

Making host permissions optional by default is a bad solution to the problem of installing malicious extensions with the <all_urls> permission. Although this will prevent malicious extensions from placing malicious content scripts on install, this also makes the onboarding experience for extensions providing a good service more complicated. Users already click through prompts presented to them to access the application after install recklessly so any onboarding seems like a worthless endeavor, but the rest of this post assumes that the user will read these onboarding prompts to allow the permission.

My solution to this would be to have the browser, not the installed extension, present a prompt asking the user if they want to allow permissions, and if they deny it, then an additional prompt would show them how to have those permissions enabled. These prompts can also look like the various alert messages provided by the browser to let the user know that this request is coming from the browser. These alert messages are hard to spoof, assuring the users that the prompts are from the browser. This does assume that the users will read and follow the prompts, but its better than:

  1. Having the user install a malicious extension with <all_urls> and compromise their browser immediately
  2. Having the extension in charge of the onboarding experience, allowing malicious actors to provide that onboarding experience

@nir-walkme
Copy link

I think this is another case where trying to stop malicious extensions is actually affecting the good extensions, some of them are security-related extensions, so overall the user's security/privacy is worsen.

I would like to suggest a different approach to solving this problem:
The extension web stores will classify extensions with different levels of security clearance. A high security clearance extension would continue to perform like today (host permissions not optional), while a low security clearance extension would have optional host permissions by default.

How would an extension be set with high clearance? Few ideas:

  1. An extension that was published over 1 year ago with no complaints.
  2. The extension's author has extensions published for at least 2 years. Number of users using the extensions over X users.
  3. The extension author is a company with over X employees.
  4. The extension author has passed standard security certifications (SOC2, ISO 27001)
  5. The extension would pass an extended (paid?) security review.

@xeenon
Copy link
Collaborator

xeenon commented Jul 21, 2022

Apple's reasoning for making host permissions optional from the start in Safari Web Extensions has been covered in WWDC presentations from 2020 and 2021 (at the 31 minute mark).

@Juraj-Masiar
Copy link

Juraj-Masiar commented Sep 26, 2022

I've migrated some of my addons to Safari where host permissions needs to be granted and it's crazy confusing. Even for me as developer I often can't say why is my addon not working anymore (or freezes with deadlocks!). Then I notice a small warning badge next to my addon icon on the toolbar.
"Maybe" they just implemented it badly :)

The biggest issue I see is that host_permission is used not only to inject/modify current page.
We are trying to "disable addons on important pages", like banking, right? Or allow it only on specific pages.

But host permissions are used also to access favicon, or URL or to fetch data from a private server that user never visited before. How is this gonna break these and many, many, many (!!!) other API?

Alternatively (brainstorming), it may be worth to invest more effort into preventing malicious addons in the store than preventing what they can do once they are installed. I'm 100% for having issues publishing addon than dealing with bad API and complaining users.
For example, I think removing remote code execution is the best MV3 feature (from the security point of view)!
Or, validating publishers, or making "verified publishers". For example, which of these 3 accounts is actually the "Microsoft Corporation": a), b), c). There should be ONE with a huge badge "Real Microsoft" and the two others should be banned with "impersonating Microsoft" message!

@dessant
Copy link

dessant commented Oct 27, 2022

Hi @dotproto, I'm having some concerns ragarding the update of currently installed Manifest V2 extensions to V3 in Chrome. Do currently installed extensions which have been previously granted the <all_urls> permission inherit host access if they declare the same permission in host_permissions? Is the update process seamless for users, or do they need to take some action for the updated extension to continue working?

@dessant
Copy link

dessant commented Nov 1, 2022

It would be important to clarify how granted permissions are handled for existing installations during a Manifest V2 to V3 extension update. I have not been able to find any documentation on this issue, and extension permissions may be handled differently while simulating an update with unpacked extensions in developer mode, so it's difficult for us to check the exact behavior.

I'm currently holding off Manifest V3 updates in Chrome for several extensions because I'm concerned about existing users ending up with broken extensions, which would generate a large amount of negative reviews and support requests. Can someone share how Chrome handles permissions during an update to Manifest V3?

@dotproto
Copy link
Member

Do currently installed extensions which have been previously granted the <all_urls> permission inherit host access if they declare the same permission in host_permissions?

Yes, previously granted host permissions should be retained across manifest versions. The field used to declare these permissions should not impact those grants.

Is the update process seamless for users, or do they need to take some action for the updated extension to continue working?

Generally speaking it should be seamless. The only caveat to this is that any new permissions that, as always, an update that introduces a new permission with warnings will cause the extension to be disabled until the user grants the extension the new permission.

@Araxeus
Copy link

Araxeus commented Jan 20, 2023

Users should really get a permission popup when the extension is installed (or updated with new permissions)
especially if it's an extension that is just a content script for specific websites

The removal of this feature perplexes me.
Most users don't want to wade through settings to make the extension they just installed work

Relevant discussion:
https://chat.mozilla.org/#/room/#addons:mozilla.org/$Y3OIxLZkmUsdJoqmA7xBByil61_yF1VoIYx2aECcJWQ

here's an email I received from a user who luckily had some patience to dig and find the options to make it work, which most users obviously won't do
image

I'm really regretting adopting MV3 so quickly

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

No branches or pull requests

10 participants