Background
I've been using the crx-hotreload package to auto-reload my chrome extensions during development because it's annoying to have to click the refresh button on the Extensions page every time you make a change; however, this package doesn't work with MV3 because it uses the chrome.runtime.getPackageDirectoryEntry method, which seems to have been removed from chrome.runtime in MV3. I can't find documentation to confirm that it was removed, but it's not there when I try to use it.
Questions
Does anyone know how to get access to all the files in the extension directory in Chrome Extension Manifest Version 3?
Or generally, is there a better way that I can hot-reload my chrome extensions during development that would work for MV3?
This is one of many things based on DOM capabilities of background pages that are removed from ManifestV3 because service workers don't have DOM. For example, getPackageDirectoryEntry is using the old nonstandard FileSystem API in its returned value.
As to why, apparently the switch to service workers simplifies the internal source code in Chromium, even if it doesn't provide any real improvements for extension authors or users.
At this point all you can do is present a convincing use case and ask Chromium developers via https://crbug.com to implement an alternative API.
Related
I developed an addon for firefox which I want to distribute among my group. I don't want to make it visible to everyone. How can I put that restriction for my published addon.
I did the same for chrome extension where my listed emails can install my chrome extension only.
Such an option is not available for extensions listed on AMO. It's either available for everyone or not at all.
Unlike CWS, with Firefox you can opt to self-distribute the extension (AMO will only do the signing, hosting and updating is on you), and then how you control access is up to you.
However, once someone has the XPI file, they can share it with anyone. This is technically true of Chrome extensions as well: once installed, they can be ripped and shared.
If you truly need to limit functionality for non-members, the only way is to offload some non-trivial part of the program to a server that requires access credentials.
I'm diving into the world of Chrome Extension development, primarily because there is a very small feature that is missing in Chrome that I miss dearly. The context-menu option to "Set as background/wallpaper" like that found in Firefox. Sounds trivial, but it's convenient.
I have most of the "basic" stuff worked out with the manifest file, am able to install it, even managed to get it to show up as a context menu item.
The problem obviously is that I am wanting to mess with a user's OS-level settings which is extremely difficult because of security issues (fully understand this).
I found an extension that allowed this in older versions of Chrome, and it looked like the developer used some type of .dll and C++ to accomplish this.
I'm not really sure how to make this work.
Since that Chrome doesn't allow these kind of manipulations (such as your PC's settings), you will need to create a native application that will run beside your extension. When the user chooses the image from your extension and selects "use as wallpaper", you will use the native messaging API to send a message to your desktop application, that will set the wallpaper (and do whatever else you can't do within a chrome extension) for you.
You can use the chrome.wallpaper app api to set the wallpaper after using the messaging api to send the image from your extension.
I may be a bit of paranoid when it comes to installing chrome extension that request access to all my tabs and data. While a extension may be safe for the moment, a simple auto background update can make it a malicious virus and you won't even get notified about updates.
I would like to specifically whitelist all my extension to access the content pear webpages bases. Is there any such tool out there already (natively perhaps) before i start hacking my own extension to control it on my own.
That would leave me to my next question. Extension can be a bit secured running sandboxed environment and have no access to the "real" filesystem (not the virtual sandboxed filesystem) but could i write a NaCl plugin and have have full access and change the manifest file to change the content_scripts settings? if so, could you point me in the right direction?
I'm not sure to understand clearly your question, but let's calrify some things about extensions and how they can be dangerous:
First: If an extension updates and want to have new authorisations, Chrome will warn you and you can choose if you want it to be updated
Second: Chrome sandboxes extensions running on your computer
Third: The only authorisation that may represent a real danger for your computer are the ones requesting authorisation to "Access all data on your computer"
.
.
.
If you are really worried that some extensions may represent a danger for you (and I understand you), you can restrict them to run on specific webpages by doing the following:
1. Go to the extensions folders [C:\Users(YOUR USERNAME)\AppData\Local\Google\Chrome\User Data\Default\Extensions(APPID)] and open the manifest.json file with any text editor
2. In "content_scripts" declaration, in "matches", specify sites where the extension will ONLY work on [ex:*://google.com/* will make extension be active ONLY for google.com]
You can even be more precise and set specific URLs/HTML pages (see more: https://developer.chrome.com/extensions/match_patterns)
Hope it helps!
If it doesn't, please clarify your question again.
As the question says, can an extension save files to a user-set location for all future downloads (that differs from the download location set in preferences)?
If so, how would this be done?
Thanks
See this issue for a lengthy discussion on the matter. Per the last qualitative entry on 8.10.2012:
The downloads ui is a very sensitive part of chrome from a security
perspective, so it is unlikely that we will ever be able to allow
extensions to completely replace chrome's downloads ui. We have plans
to allow extensions to extend chrome://downloads in a limited and
safe way, and extensions may add browser action buttons, but
replacing the downloads ui entirely is not likely in the foreseeable
future. Witness the search engine hijacking security issues. With the
--disable-downloads-shelf flag, extensions could suggest that users set that flag.
Please also feel free to write a download manager extension as a
browser action to demonstrate a better ui. If a download manager
extension gains sufficient popularity, we may consider adopting
something like it as chrome's native downloads ui. That's a more
likely way that extensions could replace the ui, but slower and safer.
My guess is that you can't. It would be a security issue if plugins had such abilities.
I have a popular Chrome extension that is being targeted by a specific site and they are messing with our extensions functionality and telling visitors to uninstall our extension. They are detecting we are running in the browser by checking for our manifest file via looking for the URL chrome-extension://our-app-id/manifest.json. Is there anyway I can prevent this?
I tried using content-security-policy but that seems to only help with cross-scripting. If not seems like a security hole on google's part; I don't want sites knowing what extensions I am running in my browser.
Manifest version 2 that is tentatively scheduled for version 18 should fix this.
[...] today, all the resources inside your extension (e.g., images)
are visible to web pages. We're changing the default to "not visible"
and then adding a manifest attribute to let you whitelist the
resources that you want to be accessible to web pages.