Firefox WebExtensions require the applications key in extension's manifests.
Chrome's extensions do not appear to support the applications key and Chrome throws an error when the key is present, unlike Firefox which simply ignores unsupported keys.
Is there a way around this error that does not require the use of two different manifests for each browser?
Chrome gives this error when the applications key appears in the manifest:
Unrecognized manifest key 'applications'.
Maybe not directly answer the question, but according to a blog from Microsoft Microsoft Edge extensions now available to preview,
In keeping with our commitment to an interoperable web, we’re participating in the W3C Browser Extension Community Group’s efforts to define standardized extension APIs based on familiar web technologies.
So maybe we can look forward to the future.
Related
I am working on a Chrome extension running on Chrome OS.
The extension needs the enterprise.hardwarePlatform permission to be able to get hardware information about the device.
The question is: How can I test my extension?
After installing the extension manually, the API to get the hardware information will not work as it needs the extension to be forced-installed by the enterprise policy.
But how to force-install the extension if it is not published in the Chrome Web Store?
Google Workspace seems to allow to refer only to published extensions in the enterprise policy. But obviously I do not want to publish the extension under development. Also I didn't find a "Web Store for development" where I could upload the extension and then refer to it from the policy.
So how to do this?
I found this question:
https://support.google.com/chrome/a/thread/107510644/how-do-i-develop-a-chrome-extension-with-enterprise-permissions?hl=en-gb
However, did not find the answer in any of the provided links. All information seem to point to publishing on Chrome Web Store first. But then would it be impossible to manually test a feature like this before publishing?
Thank you for your answers in advance.
The article from here shows a method for websites to determine whether a user has a particular extension installed, if "web_accessible_resources" (in case of Chrome) allows this. My question is why do browsers not filter these requests themselves? The only use case I came up with was to fingerprint the user.
The author of an extension lists such accessible resources in its manifest.json intentionally. This is a feature used by extensions to add a UI or a font/image to the web page(s) and so on.
Fingerprinting is possible only due to a poor implementation in Chrome (and Chromium-based browsers), which will be eventually fixed in ManifestV3 so extensions can set use_dynamic_url.
Firefox WebExtensions aren't affected because Firefox uses a unique per-machine UUID, more info.
When navigating to "native massaging" documentation, first thing you see is a warning:
Important: Chrome will be removing support for Chrome Apps on all
platforms. Chrome browser and the Chrome Web Store will continue to
support extensions. Read the announcement and learn more about
migrating your app.
Since all this documentation located under Chrome Apps docs, is it means that "native messaging" feature going away as well? If it is, what is the alternative for communicating with chrome extension from the outside?
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.
In doing research on "Chrome Extensions Security" most of the results are about the extensions themselves being threats (malware, etc.).
If I write an extension to be used with my web application, what are the security threats against the extension (not from the extension)? Is the extension secure against malicious attacks? Can the code running in the extension be compromised?
It is interesting that there is not a "Security" section in the Chrome Extensions documentation nor is the word "security" mentioned in the Chrome Extensions FAQs.
This video from December of 2009 answers one of my major concerns: Google Chrome Extensions: Content Scripts and Isolated Worlds
Aaron Boodman, an engineer at Google, presents content scripts, one of the features of Google Chrome's extension system, as well as the concept of isolated worlds (keeping content scripts isolated from each other and from the pages they are running on).
Good quote from the video: "Since no JavaScript objects are shared between 'Isolated Worlds', it is not possible for web page JavaScript to use the shared DOM to break out of the normal web page sandbox and somehow get access to the content script or its APIs."
Good image from the video: Isolated Worlds
If you have any other good references on Chrome Extensions Security, please post in a comment to this question. Thx.