I currently have notifications added as an optional_permission for my Chrome extension.
If I change that to a required permission, what will happen to the users that have already accepted notifications? Will they still have the extension disabled for them? Will it be a seamless transition?
Related Links: extension permissions, extension permission warnings
Judging by the source code there won't be a warning for users that have already accepted notifications because the update routine accounts for these runtime-granted permissions explicitly.
But if you add several permissions of which some aren't yet granted, the extension will be disabled.
Related
While pruning the number of sites that are allowed to send notifications to me, I discovered one allowed notification rule that surprised me: *://www.goko.com/*:
(This is found at chrome://settings/content/notifications )
How can I find out which of my Google Chrome Extensions is enforcing that I allow notifications from goko.com (without brute-force disabling/uninstalling them until I discover that the permission is gone)?
For internal use in my department I wrote a Chrome extension. It works fine in developer mode and I delivered it to my colleagues by e-mail attaching the .crx-file. They opened chrome://extensions and drag-and-drop it there. The message
drop to install extension
appeared, Chrome installed the extension and it works like a charm.
Nevertheless, on the very first restart of Chrome, a message appears that Chrome deactivates an unsupported extension.
A link to the help page Extensions disabled by Chrome is added to the message, and states:
To protect you while you browse, Chrome only lets you use extensions that have been published on the Chrome Web Store.
While I understand the reason, is there any other way a user can explicitly tell Chrome an extension is safe? Some effort is acceptable as publishing the extension to the webstore is not.
I have no administrative access, so no changes to registry nor active directory are possible.
As noted, you need Active Directory level policies to whitelist / auto-install extensions. See Policy List.
Chrome will use many defense mechanisms to detect and fight other trickery. The stance is simple: anything an unprivileged user can do any other software can do to implant malware.
However, you should consider publishing in CWS.
This can be done unlisted; unless someone has the listing link, the extension won't be discoverable.
This approach will present a risk of a leak of the link, but with your current delivery mechanism crx can leak as well; in general, copy-protecting extensions is basically infeasible.
This can be done with enforced control over accounts; you can publish to a Google Group of "trusted testers", who will be the only ones to see the listing.
Won't work if you're not allowed to sign into your Google accounts in Chrome.
This can be published with enforcing access only to your domain's users - if you use GApps for your work.
All of the above might not work if your extension is somehow questionable by CWS policies; if you can't publish for this exact reason, and can't use AD policies, I'm afraid you're SOL.
There isn't a way without domain level management to make this work. You can't just have the user "say" it is safe, since the user "saying" something could very well be the attacker. Any mechanism put in place to get around this would simply be used by attackers and unthoughtful companies to add more junk into your browser.
When using chrome.webNavigation the webNavigation permission is needed. As stated on Permission Warnings, using that permission makes the installer to show the warning message:
Read your browsing history
In my case, I only want to listen to one specific domain, let's say domain.com. So, I need to filter the callback for chrome.webNavigation.onCompleted.addListener().
Now, from the user perspective, they could distrust the chrome extension since "Read your browsing history" is too broad and the extension should only work on domain.com.
When a match pattern is used in the permissions, a message like Read and change your data on all domain.com sites and www.domain.com is used.
Is there any other way to use chrome.webNavigation and only listen to one domain? where chrome extension issues/feature requests should be sent?
Update: I had to use webNavigation in order to support AJAX calls. That is, listen to changes in the DOM and the URL made with AJAX. I solved this particular case by using a MutationObserver. Thus, I could remove the permission. The original question was already reported as a bug by Rob W.
In this case, I've already posted a feature request over a year ago: https://crbug.com/431108 ("Allow extensions to use webNavigation API without webNavigation permission").
where chrome extension issues/feature requests should be sent?
Report feature requests and bugs at https://crbug.com/new (points to https://bugs.chromium.org).
If you want to get the equivalent effect of chrome.webNavigation.onCompleted without using the webNavigation API or adding extra permissions, then you can declare a content script and send a message to the background page when the window.onload event fires.
I know that in the case when some extension is updated and requires additional permissions compared to a previously installed version, a dialog with the permission warnings will be shown.
My question is: is any dialog is going to be shown if some permissions are removed compared to the previous extension version?
is any dialog is going to be shown if some permissions is cutted off comparing with the previous extension version?
If your permissions decrease, no dialog will be shown.
Interesting fact: Chrome will still consider those permissions granted on installs that had the broad-permissions version before.
So if your next version reintroduces the same permission, only users that had the restricted-permission version as their first installed version will be notified. Makes it easier (but still not completely trivial) to recover from accidental permission deletion.
From the source code (thanks to Sungguk Lim for the link):
// Extensions can also silently upgrade to less permissions, and then
// silently upgrade to a version that adds these permissions back.
// The extension could then release a new version that
// removes the "omnibox" permission. When the user upgrades, Chrome will
// still remember that "omnibox" had been granted, so that if the
// extension once again includes "omnibox" in an upgrade, the extension
// can upgrade without requiring this user's approval.
Extension will be disabled when permissions increase, and dialog will be shown
See actual chromium code:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/extension_service.cc&sq=package:chromium&type=cs&l=1582&rcl=1453955600
According to the answers here if I hypothetically follow this path of publications in chrome store:
step 1) Publish extension example_v1 / permissions x
step 2) Update extension to example_v2 / permissions x+y (increasing permissions)
step 3) Update extension to example_v3 / permissions x (decreasing permissions to the initial state (v1))
The final state of the extension should be enabled once the permissions at the end will be the same as at the beginning, isn't it?
Could be possible that once chrome mark your extension as disabled (step 2) it doesn't mark it as enabled again by itself, but the user should do it instead?
Once a user has allowed for a getUserMedia request to access their camera/microphone, is it possible to programmatically "remember" that permission across future page loads?
Not sure this answers your question, but for Chrome at least, if you use HTTPS, permission is only requested once. (Looks like this isn't implemented in Firefox.)
For Chrome apps you can add audioCapture and videoCapture permissions, which mean the user is only asked for permission on installation.