New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 762341 link

Starred by 4 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome , Mac
Pri: 2
Type: Feature

Blocked on:
issue 759185



Sign in to add a comment

Chrome feature request: Add policy to control External Protocol Handlers handling

Project Member Reported by vkhabarov@chromium.org, Sep 6 2017

Issue description

Summary:
User needs policy to be able to set Chrome Browser to run external protocol handler applications (in this case Citrix Receiver, receiver: ) without confirmation from users, not even once-shown dialog with "Remember my setting". 

Use case / Motivation:
Improve user experience, neutralize possibility of human error (eg clicking on "don't open" and remembering this setting) via centralized setting for all users.

Existing workarounds:
Editing Preferences file for user in local profile.

Case#: 13469955
 
Cc: bhthompson@chromium.org
Owner: dskaram@chromium.org
David, does this fall in your jurisdiction as a new enterprise feature?
Cc: elijahtaylor@chromium.org blumberg@chromium.org
Matt, I know this is on your radar for browser. Do you have any idea how this can work with ARC++ apps?

+Elijah to shed more light on how this would work with ARC++ intents.


Overall, if we solve this, we should for ARC++ apps and not for Chrome apps.
Labels: OS-Chrome
This technically possible on Windows today via URL whitelist.  We will do a better job documenting this. Can we clarify/narrow the scope of this to Chrome OS + ARC++?

Comment 4 by jgc...@costco.com, Sep 6 2017

I have actually already tried adding 'receiver:*' to the URLWhiteList policy and it did not fix the issue.  

Comment 5 by jgc...@costco.com, Sep 6 2017

From the testing I've done, the policy in question would need to effectively manipulate the 'excluded_schemes' section under 'protocol_handler' in the Preferences file.  Once I add a line for "receiver": false,  it works as desired.  This has been tested mostly in version 60.0.3112.113 of Chrome on Windows 7, 10, and Server 2012R2.  
Blockedon: 759185
We have found the root issue and the work-around for the near term.

Please add something to the URLblacklist such as "foo:*" and the proper URLWhiteList should begin to work.

Please share your findings.

Thanks
Labels: OS-Linux OS-Mac OS-Windows
Original issue was for Windows browser, Mac/Linux possibly affected as well, not sure if ARC++ is using same schemes, sorry for misrouting.
Labels: -OS-Windows
Support for external proto handlers exists in windows today via the URLWhiteList.  Chrome OS + Android + Linux need to be investigated.

We will add this to the help center documentation to ensure it is more easily accessible from the IT-Admin perspective.

Comment 10 by jgc...@costco.com, Sep 6 2017

Unfortunately setting the URLBlackList as well as URLWhiteList did not fix the issue, prompt is still generated.  Screenshots attached.
Prompt.png
13.4 KB View Download
Blacklist.png
29.8 KB View Download
Whitelist.png
36.1 KB View Download
policies.png
59.7 KB View Download

Comment 11 by jgc...@costco.com, Sep 6 2017

Looks like the capital 'L' was upsetting it, windows doesnt care about case but apparently Chrome does :)

Testing via GPO now

Comment 12 by jgc...@costco.com, Sep 6 2017

Confirmed!  Prompt was removed successfully with either GPO or registry values.  Thank you very much.
Status: Verified (was: Untriaged)

Sign in to add a comment