Chrome extension is packed to zip archive. After setup it is installed on folder and user can access to it. Also he can rewrite extension and even clone to new extension.
How i can protect extension from user modifications and cloning?
I find possibility for dll files (can be compiled) - but it is not very nice.
In case you have some proprietary code (e.g. special algo you want to keep safe etc') and you are targeting Chrome - I would suggest to go with Native Client. Nacl let you run C/C++ code in your browser. It's very powerful and you can be sure it will be very hard for someone to pick into your binary.
The premise seems to be simple. By default browser interprets HTML/Javascript, so are the chrome extensions which run along with the page.
One way is to obfuscate your javascript code , or rely on NPAPI compiled-binary plugins, or use NaCL
Obfuscating the code might no longer be a solution after Chrome forbade obfuscating extensions: https://stackoverflow.com/a/49509913
Currently there is no way you can hide your Chrome extension source code from users or competitors.
There is a statement in Chrome web store faq:
Can I sell extensions in the store?
Not yet, but this functionality is coming soon.
You may wait for this feature or try the following alternatives:
Obfuscate your Javascript source: Check this for more details How can I obfuscate (protect) JavaScript?
Keep your key logic on a remote server and make Ajax calls from the background script to communicate to the server
Chrome extensions are free from 'same origin policy' if cross-origin permission is defined in the manifest:
Regular web pages can use the XMLHttpRequest object to send and
receive data from remote servers, but they're limited by the same
origin policy. Extensions aren't so limited. An extension can talk to
remote servers outside of its origin, as long as it first requests
cross-origin permissions.
Define the following in your manifest:
{
"name": "your extension",
...
"permissions": [
"http://www.yourserver.com/"
],
...
}
I'm using Gulp plugin for JavaScript obfuscation. It doesn't break extension's code.
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.
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/
For security considerations I am wondering if Chrome extensions had access to an app. I design a Chrome App which handles sensitive data. As far as I understand it, that app runs in a sandboxed environment which should be fairly isolated. If a user had by mistake installed a malicious Chrome extension, would that extension be able to intercept/modify any of the sensitive data in the app?
Please note that I do not consider other ways of interceptions outside of the Chrome environment, e.g. some virus that allows someone to get root access or alike. I would just like to understand to what degree a Chrome app is more susceptible to interception than a standard stand-alone application.
Sebastian
On one hand, extensions cannot touch your app's windows (as in, inspection / script injection) in the default environment, even with "debugger" permission. Your "local" data should be safe.
On the other, I tested it and conclude that webRequest API will catch all XHRs you send.
This includes headers for both request and response, and request body. Response body is currently not available for inspection; however, a malicious extension can perform a redirect, modify your request or cancel it.
This was deemed a security issue; as of Chrome 45, extensions can no longer intercept traffic from other extensions and apps. Hosted apps were accidentally included too, but it's a bug that will be fixed soon - traffic from hosted apps will be open to webRequest as normal.
I don't know any other possibility for an extension to snoop on an app (without any anomalous chrome://flag configuration).
Extensions or other apps cannot access data inside other extensions or apps. An exception may be data in the syncFileSystem api, since an extension could be granted access to the user's Gdrive.
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.