Looking for the best way to lock chrome browser tweaking per user on shared lab computers so each user gets a consistent experience on login. Currently some users will pollute the chrome experience requiring the IT team to do some housekeeping. I would like to remove all user changes if possible, so each experience is fresh clean browser.
Tried: GPO in place to block the settings url changes and clear history on exit but customize is still available. Reached out with no luck, seems like support is firewalled at google and out of reach.
Related
In my current chrome extension, I have a popup that has settings for content a content script it uses. I want to be able to save these user settings and have them synced up across devices (different browsers but same user).
I also have my extension connected to a server which has access to a database. Should I create my own login system to save these settings across devices? Or is there a better way to approach this.
I found documentation on OAuth, but there is not much information on if the user tokens are permanent or not, or how effective this would be for the features I am looking for.
I'm resurrecting an old project of mine as a way to learn some new stuff.
I'm doing this code lab from IO Add Your Web App to a User's Home Screen.
Is there any way, other than connecting a phone and waiting a lot, to test if users will be shown the prompt below?
I've tested it with Lighthouse and all tests come back green, but I've never seen the prompt. It feels very random at the moment.
The answer to This question puts the stuggle into perspective:
The user has visited your site twice over two separate days during the course of two weeks
Does that mean I need to wait 2 days between changes to see if it worked?
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Increasing Engagement with Web App Install Banners
anshulix has correctly answered the question, but I thought I'd put in a more verbose answer.
To remove the waiting and other requirements for the save to homescreen prompt, then you need to enable a flag.
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Which comes from Increasing Engagement with Web App Install Banners
It's important to remember that you are setting this flag on the mobile browser, not on your desktop browser. For some reason this didn't occur to be for a while!
You also need to restart mobile Chrome for the flag to take effect. If you've got your tabs mixed in with your other apps, this can be tricky because you need to hunt down all the tabs and close them. (Or find a better way to close Chrome.)
I found it much easier to do this debugging in Chrome Dev, rather than regular chrome because a) I know it's got the latest fixes in it, and b) because I only have 1 tab open, so it's easy to restart the browser.
If you are doing remote inspection, there is an issue about the messages that come up in the console. In Chrome 50 you get:
App banner not shown: could not determine the best icon to use
This doesn't seem to be true; in more recent builds—e.g. mobile Chrome 52—save to desktop works just fine. It's a disconcerting but useless error.
As a bonus helpful thing, realfavicongenerator does an excellent job of generating all the icons and the manifest file that you need.
I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.
I need to capture image from web page without security warning.
Page where i need webcam functionality can not be switched to https protocol.
I've installed root certificates and made them trusted.
I tried to insert iframe (which pointed to secure protocol https://mysecurepage.com) inside page (http://mypage.com), but not worked.
#bjelli is correct - this is a major security flaw for any internet content. Just imagine if you could go to a website which would start taking photos/recording everything going on without any permissions or notifications!
However, I am working on an intranet project where disabling the prompt would be quite safe.
If you are in this sort of position - there is one thing you can do;
Google Chrome Policies
If you are deploying the browser, you can override the security prompt for sites you specify. I don't know if you are working in such an environment, but this is the only way you can avoid the prompt all together. Similar things probably would apply for other browsers too.
As defined in http://www.w3.org/TR/mediacapture-streams/
When the getUserMedia() method is called, the user agent MUST run the following
steps:
[9 steps omitted]
Prompt the user in a user agent specific manner for permission to provide the
entry script's origin with a MediaStream object representing a media stream.
[...]
If the user grants permission to use local recording devices, user agents are
encouraged to include a prominent indicator that the devices are "hot" (i.e. an
"on-air" or "recording" indicator).
If the user denies permission, jump to the step labeled failure below. If the
user never responds, this algorithm stalls on this step.
If a browser does not behave as described here it is a serious security problem. If you find a way of making a browser skip the "permission" you have found a security problem.
What do you do if you find a security problem?
Report it IMMEDIATELY! Wikipedia: Vulnerability Disclosure
Firefox: http://www.mozilla.org/security/#For_Developers
Internet Explorer: http://technet.microsoft.com/en-us/security/ff852094.aspx
Safari: https://ssl.apple.com/support/security/
Chrome: http://www.google.com/about/appsecurity/
Opera: http://www.opera.com/security/policy
This is not just a question of technical possibilities, it's also a question of
professional ethics: what kind of job would I not take on? should I be
loyal to my customer or should I think of the welfare of the public? when do I
just follow orders, when do I stop bad stuff from happening, when do I blow the whistle?
Here are some starting points for computing professionals to think about the ethics of their work:
http://www.acm.org/about/se-code
http://www.acm.org/about/code-of-ethics
http://www.ieee.org/about/corporate/governance/p7-8.html
http://www.gi.de/?id=120
Some browsers does not asks the client if he want use the application cache, but simply just downloads the whole thing at first visist (e.g. the browser on android). That can cause troubles when the application cache is many MB's and the client is on a mobile network - that is expensive! And is it possible to stop the cache from being downloaded? Pressing the menu button on e.g. android will not close the browser, it will be running in the background.
Is it a good idea to only add the manifest based on a cookie set when the client pushes a "hey i want to offline cache this site" button? Will that cause any new challenges?
I've tested this, and it seems to work. Needs more testing though. Can provide a link to the site in about two weeks if anyone is interrested.
One possible solution, as a you hinted at yourself, would be to ask the user if he/she wants to cache the app offline, and if so, only then redirect to a page which has a link to the manifest file (which is subsequently downloaded by the browser). You cannot stop a download midway unless of course, your network disconnects mid way.