Everybody can download chrome extension, edit and reupload, how i can protect my chrome extension and what i need to do if i see someone reupload my chrome extension?
You can't bulletproof-protect it. The only thing you can reasonably guarantee to be unique is the extension ID for published items - but any checks you would do against it can be circumvented.
It's not a technical problem. It's a social/legal problem.
If you see someone doing it, you should use the Report Abuse function of the Web Store.
What other does is to load the "actual" code of their extension remotely (via CDN)
The code that is packaged with chrome extension just act as loader or their "real" extension code.
See Streak's InboxSDK (sdk to build chrome extensions for gmail). It uses the same concept. https://www.inboxsdk.com/docs/
Related
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.
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 am looking for a sample project that would compile a chrome and firefox extension that would run some JavaScript code after a page is loaded.
I already wrote a Chrome extension that does this, but I am looking for something cross-browser, that would allow me to build the same extension for Chrome and Firefox.
If this would also allow me to publish the extensions it would be great.
You may refer this link http://www.extensionfactory.com/labs/conversion/
Here you can get firefox extension by submitting chrome extension.
With the Crossrider's framework you can build a cross-browser extension using only one code base that will work on Chrome, Firefox and also Internet Explorer and Safari.
So, with only using javascript single code base and the Crossrider API you can easily build your first cross-browser extension in no time.
(Disclosure: I work at Crossrider)
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.