Could you configure your network so that access to the Google servers needed during enrollment is possible without a proxy? That way, users can enroll without worying about proxies.

We already done that but due to security reasons, those rules have been removed since is too complex to manage IP and hostnames from Google servers. It moving quite fast.
As well as on the firewall equipement, we only can exclude IP's not hostnames..

Have you tried WPAD?

Security point too. WPAD distributes proxy settings for all devices as well as printers and non managed devices. This Is too risky.
Thats why we had try to wiresharck a chromebook to see if some data could be isolated to reduce the wpad scope.
But no analysed packets able us to check if its a chrome os device or not. HTH

Have you tried filtering based on (parts of the) MAC address?  It's not pretty, but maybe it could work as a stop-gap?

What would you suggest as a long-term solution?  Include a Vendor Class Identifier with the DHCP request?

Don't think @MAC is suitable since they don't belong to ChromeOS but each OEM. So it will be complicated to manage this such park...

Of course, best solution will be that ChromeOS sends a Vendor class ID in the DHCP request which able to identity as ChromeOS device.

Do this work seems faisible?

We definitely want to add policy to modify vendor class ID in the DHCP requests, but were thinking of only doing this in the context of managed networks, which wouldn't really help the case here.

In all other deployments, it is not users who enroll a device. The margin for error for users enrolling their device is very high and it will pose a bigger blocker to such a deployment than having to modify proxy settings. Why can't IT staff enroll the device before handing it over to users?

Usual concern remains the cost behind for such of service. That's why we want to let users do by themselves.
So using a solution like WPAD allows them to easily switch from direct internet connection to automatic proxy conf with no hassles.
Moreover, IT staff is not present in all affiliates over the group.
The long-term strategy is really "self-care".

I understand. We thought for a bit about changing vendor ID from DHCP for all connections. The problem is that we don't know how this would affect deployments in the field. Whether DHCP servers would understand a non-standard value like "chrome-os" or whether customers already used to the current value (I believe we send "linux") would break if this changes.

It seems the only way for you would be a Chrome OS system change that is not based on policy.


How long is the URL if users need to type it in?

Agree with that. A "chrome-os" value into DHCP requests seems viable.
Do you have any timeline about this FR?

Sure, in short-term, we can make some changes to reduce the URL which is now looks like "http://pac.zscaler.net/xxxxxxxxxxxx/xxxx.pac/".

Knowing that steps before are not quite user-friendly: Go to proxy settings > switch to APC > Check the box > Type the URL.

assign to +dskaram@ to prioritize 

+dskaram@chromium.org
Do we have a plan for this FR or do we use an internal alternative?

This is not on the roadmap at the moment. Please try to pursue internal alternatives. We can revisit this moving forward but hopefully your internal alternatives can work here.