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.
Related
I have switched to using Content-Security-Policy for my website. I'm starting to see reports about the following not being allowed: https://www.pagespeed-mod.com/v1/taas
Does anyone know why the website is trying to load this file? I'm using Google Analytics and Tag Manager, but I don't think that I have any page speed mod installed. Maybe this is an extension in the user's browser? Or when they open developer tools? Another source I could think of is automatic optimization through Cloudflare which I'm also running on.
Extra info: The source of loading this script is https://3001.scriptcdn.net/code/static/1 which doesn't reveal much about who made that.
Had the exactly the same issue and preventing me from using Element Inspector/ debugger. It appears to be some Chrome extension you have installed gone rogue, see if you have extension called "Auto Refresh Plus" installed like i did before.
I also see reports on https://www.pagespeed-mod.com/v1/taas being blocked with the same source of loading. It seems to happen in short periods on the various resources I have reports from. This indicates that it is related to the user/browser and not related to the site itself.
The same can be seen with translators, extensions, security proxies etc. I have given up trying to attribute the source of anything that is likely not caused by legitimate site content.
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.
We have created a Chrome Extension that is a companion to web sites that we host for our customers. These web sites are hosted under our domain name and interact with the extension using external messaging and relying on the sites being configured in the manifest similar to the following (abcdefg.com is a ficticious domain name):
"externally_connectable": {
"matches": [ "http://*.abcdefg.com/*", "https://*.abcdefg.com/*"]
}
This works great in these cases. However, we have a subset of customers that prefer to host the website themselves under their own domain. The problem is that we do not want to update the extension manifest for the published extension to include all of these sites.
Is there any option of distributing a version of the extension (on Windows) where the "externally_connectable" site list can be set upon installation?
Thanks to kzahel for highlighting the obstacles I was facing and thanks to wOxxOm for providing a solution that will work.
Rather than trying to find a way to override the "externally_connectable" matches configuration upon installation, we found the easiest alternative was to avoid external messaging and use messaging via a content script instead.
The following is a copy of the solution posted above by wOxxOm:
chrome extension - alternative to externally_connectable?
Unfortunately there's no way to do this. You'll need to create a custom extension for every customer with their own domain name. Luckily, there is an API for updating the extension, so you would be able to at least update multiple extensions without too much difficulty. However, the 20 extension limit per account would be a little annoying. I think you can get more extension allowed per account by creating a publishing group and assigning the extensions there.
You could if you are willing to have customers install this in developer mode. That would bypass the 20-extension limit.
So I've built the main functionality for an extension already, and have it uploaded as a web page on my server. I'd like to have it interact with any page a visitor goes to though and not just my page on the server. It's just the HTML/CSS/Javascript and jQuery.
I've been reading the documentation, and it says/implies I need to use a content script. I do have this script included as a content script as well though, however I'm probably doing it wrong. Mainly looking for some guidance/direction as to where to go on this.
The extension is to be one that removes all images from a page.
The site is http://199.127.226.221/testsites/chromeapp/
This is the manifest file: http://199.127.226.221/testsites/chromeapp/manifest.json
This is the .crx file: http://199.127.226.221/testsites/chromeapp/chromeapp3.crx
You should supply the extension as a .crx file.
Also it seems you should specify desired urls for content scripts in permissions of manifest
I'm making an extension for Google Chrome and I use code for autoupdating. This is because the extension isn't yet in Google Chrome webstore. But in a few days I will upload it to the Webstore and Google says you can use the Webstores autoupdating. But if I don't want to use that, will my app still update by my own server, like the way it does now?
Thanks in advance!!
I agree that docs are not very clear about this:
If you publish your extension using the Chrome Developer Dashboard,
you can ignore this page. You can use the dashboard to release updated
versions of your extension to users, as well as to the Chrome Web
Store.
But, I've tested it myself and your update_url setting in manifest.json will be overridden when you publish your extension via Chrome Web Store (CWS). In other words, publishing to CWS means that you can't use self hosted autoupdating anymore.
The reasons for that, that I could think of, may be as follows:
CWS wants to keep track of each extension stats (i.e. number of users using each extension)
privacy concerns (people don't want you to track them when they update extension)
security concerns (each extension update must go through CWS verification process)
If you want to track people (please don't) use Google Analytics on i.e. background page of your extension.