What previous version ?
I was unable to find a previous version that doesn't display the Advanced sync settings in a frame, or it's blocked with your policy.

Blocking chrome://* it's too much you can block ALL the settings page with blacklisting 
chrome://settings-frame

Abdul, could you help us triage this issue ?

Hi, this still an issue. We already blocked chrome://settings/cupsPrinters but whenever we access chrome://settings > Advanced > Printing > Printers, it's still shows up and not blocked.

But when I copy the URL [chrome://settings/cupsPrinters] then paste it in the address bar of the browser, that's the time that it will be blocked. 

Any answer will be very much appreciated. Thank you!

Case: 15835392

1. Add 
https://myaccount.google.com/security
https://myaccount.google.com/permissions
to to the URL blocking to user settings in admin console.

2. Navigate to 
https://myaccount.google.com/security
make sure it's blocked, as expected.

3a. navigate to gmail.com
3b. Click on 9 dots-> My Account" > clicked "Sign-in & security"
See that https://myaccount.google.com/security is opened.

Tried on many versions, from 53 to 66, same effect, so
'In previous versions this kind of URL blocking worked." from #0 is maybe more to old version of "9dots UI" (very old times, when they were not 9 dots yet, were either 3 lines or 6 dots)?

Any updates on this? Can we raise the priority of this bug? This is critical to customers who block URLs like the "My Account" sub-pages. We don't have a feature on blocking those sub-pages, we only have workarounds to give them, and now, the workarounds don't work too? 

Blocking subpages of chrome://settings in an effort to prevent a user from reaching certain functionality is not the right direction to begin with, IMO.

chrome://settings is a single page, regardless of how many sub-URLs it has. An advanced user can reach any place within settings, with our without manipulating URLs (for example by opening the developer console and typing

settings.navigateTo(settings.routes.SYNC)

Blocking certain settings from being editable from chrome://settings  should be done via dedicated policies, which chrome://settings should respect, as is already the case with a large amount of various settings. This way the user is also informed using a "policy indicator" that a certain setting is disabled for XYZ reason (see icon in screneshot).

Deleted: policy_icon.png 10.9 KB

	policy_icon.png 10.9 KB View Download

+ jayhlee, atwilson 

We have more customer asking about this issue so bumping priority.
Can we clarify if this is expected behaviour of a new Chrome UI? 

So, I'm interested in understanding how this navigation is being done behind the scenes - it doesn't feel like this is an actual top-level navigation, which is all that URL blocking is intended to block. Anyone have any info on this?

Settings is a single page app [1]. Navigation is done by simply switching the contents of what the user sees, and also using window.history API [2] to manipulate [3] the displayed URLs and history stack (so that it is perceived as a top-level nav).


[1] https://en.wikipedia.org/wiki/Single-page_application
[2] https://developer.mozilla.org/en-US/docs/Web/API/History
[3] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/route.js?l=527

Our customer is still waiting for an update on this issue as this is already critical on their end.
The only way for them at the moment is to use URL blacklist policy to restrict their students and now, they are unable to do it.
They're saying that it shouldn't be an intended behavior as this policy was working before. All intentions to help are very much appreciated. Thank you!

OK, the way these pages work are:

1) User takes some action.
2) Javascript in the page rearranges the DOM
3) As a convenience for the user, the page updates the URL with a different URL (example: go to the JS console and type "window.history.pushState({}, "FOO", "zzz") and you'll see the URL in the omnibar get "zzz" appended without any actual navigation happening.

It's fundamentally not possible for Chrome to do anything in step 3 - it's too late, as the DOM has already been updated to display the content that the admin wants to block.

If admins want to block access to functionality under MyAccounts, then they'll need to drive a feature request with the Dasher team to do this via Google Account policies. It's not something we can build for them in Chrome (and also, they'll want to prevent users from turning on two-factor auth or other such things via unmanaged browsers).

Agreed with comment #7 - the right way to block sub-pages of the settings page is via settings-specific policies. abdulsyed, please work with dskaram@ to prioritize this request - understood that this is a regression compared to how this page used to work, but it cannot be addressed as a simple bug fix, but rather as a new feature.

dpapad - one other thought - if we determine that the URL blacklist contains chrome://settings, we could have navigateTo() call location.reload() to force a real navigation. That might be enough to fix this case without requiring a bunch of new policy work. WDYT?

@atwilson: I don't think that implementing an enterprise policy inside the UI is the way to go. As said earlier, an advanced user could still open the DevTools and invoke any action anyway (by directly calling chrome.send() with the correct parameters).

There need to be C++ side checks for disabling whatever feature is meant to be disabled, so even a chrome.send() is manually called by DevTools, it still has no effect. Blocking a settings sub-URL is fragile, and insufficient.

Fair enough, and as I've thought about this more I think URL blocking is not the right path forward.

vnikolov/vkasatkin/jayhlee: What is the actual use case that the admin is trying to address here by blocking access to syncSetup? Perhaps there's a better way to do this - we really don't want to support blocking URLs as a way to restrict settings changes because as we change the settings UI (for example, moving the sync setup stuff into another settings sub-page) it will break admins. So if people want to block specific parts of settings (printer setup, sync setup, etc) let's put together a list and we can explicitly add policies to cover those cases.

In general, we can't use URL blocking to impact the behavior of pages that use window.history to directly inject fake navigations into the history stack. So we can't block access to myaccount.google.com/security and other similar pages.

Updates on this? Thank you.

Waiting for input on the set of use cases we actually want to support here.

Also note that there are already a ton of enterprise policies that chrome://settings respects. So IIUC, the question is which policies are missing, and should be implemented.

Ideally, we should not endup with overlapping policy responsibilities, because that would make it harder to implement on the UI side.

We are so close to allowing our students to access chrome://settings on their Chromebooks so they can change change accessibility settings, clear browsing data, access touch pad settings, set language, and so much more.  Most options in chrome://settings that would raise an eyebrow are now configurable by policy. 
 However, here are the settings that we do not want students to be able to change:

printers - We don't want them adding CUPS or cloud printers.  We want to push those via google admin.

certificates - We don't want them to be able to install their own certs.  We want to push those via google admin.

VPN - We don't want them to have the ability to add a VPN.  Even though our content filter (Securly, an extension) will still work by blocking URL's, this should be locked down.

Name servers - We don't want them to have the ability to set their own DNS servers.

related: crbug.com/665941

We would like to keep blocking all settings, and allow them one by one, those we will open to the students to change. Now we are blicking it all, because it provides a stable operating environment.

Assigning to Naveen to get this on the roadmap, esp given the regression in control now that URL blacklisting no longer works on settings subpages.

Can you elaborate on locking down DNS servers - is this for managed networks (in which case I'd presume they are already locked down)? I'm trying to understand the use case for locking down DNS servers for unmanaged networks - do you just have an environment where you want devices to connect to an unmanaged network, but want to force the device to accept all default DHCP settings? Maybe the right thing to do there is to make the network managed?

atwilson, precisely, I do think some network admins would like the ability to force the device to accept all default DHCP settings, and not allow the user to change DNS servers to google dns / custom dns servers (i.e. under chrome://settings > Network > Wi-Fi > user clicks the wireless network they are connected to > scroll down to Name Servers, lock down the ability to change from 'Automatic Name Servers' to google / custom dns servers).  Ideally under 'Device management > Chrome > User Settings' there would be a setting to allow/block the ability for the user to change their DNS servers.

THE USE CASE - Network admins who use DNS for content-filtering may only want their users to only use the DNS servers provided by DHCP, otherwise the user might change their DNS servers to bypass content-filtering, or the user may inadvertently break the ability to resolve addresses by setting the wrong custom DNS servers.  This possibility does not affect us much, though.  On our Chromebooks we push the Securly Chrome extension for content-filtering (and we use Securly DNS on our internal DNS servers as well), so even if the user changes their DNS servers or are off-site and connect to an unmanaged network they will continue to be filtered based on URL by the Securly extension.  So in our case, it really doesn't matter what DNS server the student is using.  However, I can see where other network admins would make use of this proposed setting if they only use DNS filtering.

SEPARATE BUT RELATED - If a user sets their DNS servers to hacked/malicious servers, or if they receive hacked/malicious DNS servers via DHCP, they could connect to a malicious captive portal / website instructing them to install a trusted root cert authority so that https traffic could be intercepted, and steal info.  While not directly related to locking down the ability to change DNS servers, this reinforces how important it is to block the ability for them to install their own certs (i.e. chrome://settings/certificates).

If network admins are using DNS for content-filtering, then I presume those networks are managed (setting up a proxy, etc) - are you saying that managed networks (networks configured via cpanel) can still be edited by users? Because if so that's a significant bug we need to address.

Or are we just talking about unmanaged networks (networks the admin has not configured in CPanel)?

Sorry to be overly careful, just trying to make sure I'm not accidentally missing a P0 bug here :)

@atwilson there is not a P0 bug, but a cosmetic bug I've already opened  crbug.com/847429 
"
the configuration is made on the Admin Console
the customer is trying to disable the DHCP for a wifi network configured/pushed in the policy.
in the video it's shown what is happening, you try to disable, for some millisecond it's shown the input field, then it's back enabled
I've tried with some very old version(M55),(before the change of the UI) and in that version it was "This setting is enforced by your administrator" 
"

naveenv@, can you please take a look and provide an update?

Hi naveenv@ many customers are interested with updates, if we have any!

imho, we should be building policies to lock down these individual settings as necessary rather than hiding the settings themselves which falls apart when the settings later get exposed in quick settings, task bar or anywhere else.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

I agree that the individual settings should be able to be blocked.  I block all settings for our students and of course if you allow one specific setting, the students can go backwards and get to everything.  We have students asking for trackpad access and while I can do that, I don't want them going backwards to clear their history, etc.

 Issue 895702  has been merged into this issue.

 Issue 895713  has been merged into this issue.

Any update on this? Can we have the check on the urls before pushing them onto history stack so that the urlBlockListing policy will work in case of direct access or when the frame is switched by javascript.