When submitting updates for our extension, we receive the following message with rejection from the Chrome store:
"To have your item reinstated, please ensure:
The purpose of the extension is clear to users; and
The extension either limits its functionality to a narrow focus area of subject matter or to a narrow browser function.
To serve multiple purposes with your extensions, please package each purpose as a separate extension."
Does anyone know the criteria used when determining if the purpose is clear or if the extension is trying to do too much? Our extension is used to demonstrate metrics more conveniently that our clients would normally go to our webpage to see, so it shows a few different but very related items (all of which fit the central theme of showing connected metrics).
Check the Chrome Extension Quality Guideline:
Extensions Quality Guidelines
An extension must have a single purpose that is narrow and
easy-to-understand. Do not create an extension that requires users to
accept bundles of unrelated functionality, such as an email notifier
and a news headline aggregator, or downloads a local executable. If
two pieces of functionality are clearly separate, they should be put
into two different extensions, and users should have the ability to
install and uninstall them separately. For example, functionality that
displays product ratings and reviews, but also injects ads into web
pages, should not be bundled into a single extension. Similarly,
toolbars that provide a broad array of functionality or entry points
into services are better delivered as separate extensions, so that
users can select the services they want.
This is further explained in the FAQS page answering these questions:
Why did Google launch a “single purpose” Chrome extensions policy?
Where can I find the “single purpose” policy?
What does “single purpose” actually mean?
Related
I asked this question a little over a week ago on the Atom forums (link below), and didn't receive a response, so I am reposting it here in the hopes that someone may be able to provide insight on my problem.
Recently, I have taken up an open source project which uses Electron as it’s front-end. This project has two requirements: it must be cross-platform, and it must have an embedded web browser (which should be able to browse the web and render content like a typical browser). Considering the rather large footprint Electron has already netted my application, it seems like a bad idea to attempt to use another embedded web framework alongside it. So, in the interest of simplifying my project and retaining the UI built on top of Electron, I am looking into using Electron itself as the web browser. Here’s where I’ve come into a problem.
In a security page for Electron’s documentation, it is explicitly stated that,
it is important to understand … Electron is not a web browser
This quote comes within the context that Electron–or rather the code running on top of it–carries the unique ability to interact with the user’s operating system, unlike typical web applications. The page goes on to say,
displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle
At this point, I was tempted to give up on the idea of using Electron as an inbuilt browser, but further down on that same page, you can find another very interesting tidbit:
To display remote content, use the <webview> tag or BrowserView , [and] make sure to disable the nodeIntegration and enable contextIsolation
Link: https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
First, in regard to using webviews, Electron’s own documentation recommends outright avoiding them:
Electron’s webview tag is based on Chromium’s webview , which is undergoing dramatic architectural changes. This impacts the stability of webviews , including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe , Electron’s BrowserView , or an architecture that avoids embedded content altogether.
Link: https://electronjs.org/docs/api/webview-tag
Seeing as though I cannot avoid embedded content, I opted to look into using a BrowserView, but what I found was not very motivating either. The advice, as it stands, is to do two things:
disable nodeIntegration
enable contextIsolation
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
That is a fair amount of steps to undergo in securing external content. Not to mention, there were several additional warnings scattered through the best practices page such as the following:
(On verifying webview options before creation)
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
Link: https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
(On disabling the remote module)
However, if your app can run untrusted content and even if you sandbox your renderer processes accordingly, the remote module makes it easy for malicious code to escape the sandbox and have access to system resources via the higher privileges of the main process.
Link: https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
Not to mention, upon navigation to the BrowserView page, the whole class is listed as experimental.
This all isn’t even to mention the added attack surface created by Electron, such as a vulnerability in the webview component just last year: CVE-2018-1000136
Now, taking into account all of the above, numerous developers have still opted to create web browsers that routinely consume external and uncontrolled content using Electron.
Browser’s using Electron (linked directly from Electron’s website):
https://electronjs.org/apps/wexond
https://electronjs.org/apps/dot
https://electronjs.org/apps/beaker-browser
To me, it seems irresponsible to submit users to the above security implications as a trade-off for convenience.
That being said, my question is: can you safely, to the point at which you could ensure the integrity of your users, implement web browsing capabilities for uncontrolled content using Electron?
Thank you for your time.
Link to the original post:
https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
Some ideas that don't fit into a comment box:
[the project] must have an embedded web browser
So I presume then that this project isn't just a web browser. There's other content there that may have access to Node, but you just want the embedded-web-browser portion of it to be sandboxed appropriately, right?
Regarding the comments about <webview>, yes, it is considered unstable and Electron recommends using a BrowserView instead. I don't think that the fact that it's marked as "experimental" should necessarily deter you from using it (especially considering that the Electron team is recommending it [though maybe as the best of two evils]).
Experimental doesn't imply it's unstable. It can just mean that the Electron team is experimenting with this approach, but this approach may change in the future (at which point I would expect Electron to provide a transition path forward). Though this is one possible interpretation and ultimately Electron would have to comment on this.
The advice... is to do two things:
disable nodeIntegration
enable contextIsolation
I would also make use of the sandbox option inherited from BrowserWindows. BrowserView's docs on the constructor options say:
webPreferences Object (optional) - See BrowserWindow.
which tells me that BrowserView accepts the same options as BrowserWindow.
You would set it up like so:
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
See more information about this approach here. The preload script is what would expose some Node IPC APIs to the sandboxed content you're loading. Note the Status section at the bottom, which says:
Please use the sandbox option with care, as it is still an experimental feature. We are still not aware of the security implications of exposing some Electron renderer APIs to the preload script
If the content you're loading in the BrowserView never needs to communicate back to the application, then you don't need a preload script at all and can just sandbox the BrowserView.
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
Sure, those sound reasonable. Note that if your embedded browser needs to be able to open new windows (via window.open or <a target="_blank" />) then you'd have to allow popups.
That is a fair amount of steps to undergo in securing external content.
Sure, but is your main concern with the security of the app, or with how much work it takes to make it secure? Browser developers need to consider similar things to ensure webpages can't get access to the OS. It's just part of the game.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
This is just saying that if all you're trying to do is display a website, then just use a browser since that's what they're there for.
If you need to do other things, well then you can't use a browser, so you'll have to make your own app, making sure it's reasonably secure.
I think that if you follow what's recommended in the Security document and keep up to date with new Electron releases, then you're doing the best you can do.
As for whether that's good enough, I can't say. It depends on what you're developing and what you're trying to protect against.
However, my thoughts can't substitute the more expert opinions of those on the Electron team. This question could certainly use some guidance from them.
I want to build a task-specific web browser. For example, when the user uses that browser, the program should give options like these:
What is your interest today? Please select from the following:
computer science
data science
web development
psychology
biology
social media
etc.
After the user selects their interest, the browser should allow the user to search or study only those selected content types, so the user cannot get diverted from their task. The purpose of this browser is to avoid time-wasting. Because whenever someone tries to study or do some professional work, they get diverted by opening social media tabs and movies.
Which programming language will be suitable for making this browser?
You could do this by making a custom version of an existing browser, as guest271314 suggested, but that would require far more effort than necessary. All you need to make is a browser extension, such as a Firefox Add-on or a Chrome Extension. Browser extensions are usually written with JavaScript, HTML, and CSS. Each browser needs to have an extension made individually, but you can usually share a lot of the code between them. Read the linked documentation for help creating an extension for each browser.
There are already existing browser extensions like you describe that prevent you from visiting sites that you put on a list ahead of time, such as StayFocusd and WasteNoTime. Maybe you just want to use one of those extensions instead of writing a new one.
Before deciding to write this issue on Stackoverflow, we tried everything that we could through the normal/official (and slow) contact process (contact form and developers emails).
So this is actually our last try to solve it and also expose some of the Google's review mistakes and inconsistency when reviewing new items (extensions).
We currently have an extension (item hjdkfeeffbfcoanbnkeedjccphcmpehm) that was approved and published few months ago and that is now used by more than 70,000 people, with excellent rating on Chrome Web Store.
https://chrome.google.com/webstore/detail/ad-block-chega-de-publici/hjdkfeeffbfcoanbnkeedjccphcmpehm?hl=pt-BR
This extension is an Ad Blocker and was primarily focused in the Brazilian market, for Portuguese-speaking people.
Due the success of this extension, last week we decided to add two new extensions (Ids: mmcgdfakfmbepgnoogipkccigohjjcim and hgekbffcnpflnhfjkdfdlhffigdfbnae) that would focus on English-speaking and Spanish-speaking countries and, when we tried to add these extensions with the exact same source code that we used for the item that is approved and published, the Chrome review team is always rejecting with these arguments below:
To have your item reinstated, please make any necessary changes to ensure:
All of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
So, just to make it clear:
1) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does have minified code and even so was approved.
Even so, we did what Chrome's team was requesting and uploaded new packages with human-readable code (not minified) and even so, again, our extensions were rejected;
2) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does load dynamic content from our server, as we need to daily and automatically update our URL list for blocking ads, its impossible to simply build and publish a new extension version every time we need to block a new URL or type of Ad.
Ad Block Plus, uBlock and other Ad Blockers do the same and they are approved and published on the Chrome Web Store.
3) The extension source code of the new items, except by the text that needed to be changed, as the new extensions are in different languages (English and Spanish), is exact the same of the extension that is approved and published, line by line;
In order to prove that from them, we even created a diff file comparing line by line the source of the approved extension with the new extensions, even so this was not enough to prove them we were right and also to simply get some answer on our emails.
We have already argued all of that through email with Chrome's team, but never received any answer or reply, except by the standard "rejection and removal" emails. They simply don't care.
That being said, it's clear to me that:
Google Chrome team is deliberately trying to prevent us for publishing two new Ad Blocker extensions, because they saw the growth that we had with our first extension (that is approved and published);
or
Someone at Chrome's team is simply making repeated mistakes and no one cares nor read our emails;
I hope this message can help us get some human attention within Google's team and also alert you guys about the "really strange" problems that we are facing.
Although this issue was more related to Google's policies than programming in the first place, the solution is still relevant to share for other Chrome extension developers, as it was somehow related about how to load remote resources for your extensions.
After posting this issue Google's team contact us and their question for keeping rejecting our extensions was related to the way we were loading remote resources for our extension.
Google's reply by email
Your new extensions are fetching resource(s) from AAA.com.br. However, the official website(s) registered for your new items is BBB.com. This means that the resource(s) being fetched are coming from remote/third-party source(s) and as per our program policies, we had requested you to check the following:
If all of the files and code are included in the item’s package,
All code inside the package is human readable (no obfuscated or minified code), and
If the items are requesting or executing any remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests)
The specific issue here is with #3.
It'll be great if you can give us some context on the resource that you're fetching and how the two websites in question are related. Once we have that information, we'll be happy to help you guys with the publishing process.
As we have two different URLs related to the same extensions (we have three extensions), for the new extensions the URL BBB.com was configured on Chrome Web Store Developers Console, but we were actually loading the resources from the URL AAA.com, that have being in use since we published our first extension.
Although both URLs were added and owner-validated to our Chrome Web Store Developers Console and both URLs were related to the same extensions, we now understood that is a good practice to load the resources from the URL that is actually configured on the extension details, even if you have more than one URL for the same extensions.
So, if you have URL AAA.com and BBB.com, and both are used for the extensions A and B, try to load the resources of the extension A from the URL AAA.com and the resources of the extension B from the URL BBB.com, even with both share the same backend.
This will avoid Google's team to think that you might be loading resources for your extension from unknown 3rd parties, that is forbidden according to the program policies.
I'm trying to make an extension that is able to find a specific resource loaded by the page, filtering by name and downloading it. The reason I want to do this is because I usually go to the network tab in the developer tools, filter the requests/responses, for example, looking for one with the word "foobar" in its name, and open the link in a new tab so I can download it (it's an xml file).
I was wondering if this could be automated with an extension, even if the word used to filter is hardcoded.
I don't have any experience with chrome extensions, so I wondered if this could be done or if it's just not possible with the devtools api. In case it could be done, if you could give me some guidelines on how to make it I would really appreciate it.
Thanks!
There are several ways to access the information you need in an extension.
You can write a Dev Tools extension. In that case, you have access to chrome.devtools.network API which will provide you that information.
This requires you to open Dev Tools and interact with your own UI there (such as an extra tab in Dev Tools).
You can go low-level and use chrome.debugger API to attach to a page like Dev Tools would. It's a complex topic, I'm just pointing you in that direction.
Since you rely only on filtering by name, not response itself, you can use chrome.webRequest API to intercept network requests and log those that interest you for processing. This is probably simplest to do.
Is there any good reason why I can't use two of them together?
browser_action
page_action
app
I can't think why single extension can't use browser and page specific actions together. Why should I have to write single extension for each action ...
For a browser that boasts about its simplicity I believe that is the clearest explanation. To prevent clutter.
Packaged Apps is the easiest to explain as they are basically an alternative to Hosted Apps for developers that don't wish to host a service or wish to make their app fully integrated in to Chrome and/or work offline. However, since packaged apps are bundled as extensions this prevents them from adding anything to the browser's chrome since hosted apps don't have this ability.
Regarding the action choice, I can only imagine this restriction is to help prevent extensions from overcrowding the address bar and the toolbar with duplication.
In a lot of cases using badges and the onClicked event correctly can replicate a lot of the functionality of page actions in browser actions while using a combination of content scripts and message passing to trigger changes.
The StumbleUpon extension rotates its browser action's behavior depending on whether or not its toolbar is currently displaying.