-
Notifications
You must be signed in to change notification settings - Fork 56
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
Comments
A related Mozilla Bugzilla issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1772433) has been closed as "INVALID". |
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. |
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:
|
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: How would an extension be set with high clearance? Few ideas:
|
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. The biggest issue I see is that host_permission is used not only to inject/modify current page. 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. |
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 |
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? |
Yes, previously granted host permissions should be retained across manifest versions. The field used to declare these permissions should not impact those grants.
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. |
Users should really get a permission popup when the extension is installed (or updated with new permissions) The removal of this feature perplexes me. Relevant discussion: 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 I'm really regretting adopting MV3 so quickly |
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?
The text was updated successfully, but these errors were encountered: