I wonder whether an intermediate step would be to show a warning similar to when an extension controls the proxy, and only use the WPAD if the user confirms.

But anyways, I'd be supportive of dropping WPAD support.

RE comment #1: Good idea! The warnings are conceptually related, as auto-detect is basically "the network is controlling your proxy settings".

RE comment #1: in that scenario we would still be paying the performance price though, right? Unless we let connections through un-proxied until the user confirms they want to use the WPAD proxy settings and then we retry them with the proxy.

If all we cared about was performance, we could implement issue 558754 and be done with it. In other words, make auto-detect a purely background best-effort attempt, and never block requests waiting for auto-detect. It would still consume memory and bandwidth to do the checks, but at least user latency wouldn't be noticeably affected as it is today.

Because WPAD/PAC can affect one's security, privacy, and connectivity expectations (by sending requests to a different location than intended), changes to the policy can have a notable impact, which is why changing the policy is non-trivial.

Enterprise will need to weigh in on how we could roll out any changes. I expect the enterprise use case is the most affected by changes to auto-detect.

My first thought would be of wholesale disabling WPAD for all non-enterprise users, without explicit prompting to opt-out. For Chrome enterprise we could have a Policy setting to enable/disable it, conservatively defaulting to Enabled.

I am not enthusiastic about more complicated approaches that rely on probing whether auto-detect found anything for the current network and then say prompting the user for an opt-in decision.

Such a probing of auto-detect would better be done as an after-the-fact check on say network error page / diagnostics.

Does Chrome benefit from SmartWPAD on modern Windows, whereby WinINET masks out the AutoDetect bit when on networks where WPAD resolution previously failed?

Eric, that might be part of the solution to https://bugs.chromium.org/p/chromium/issues/detail?id=798835.

Re #7: Issue 798835 concerns what happens when Chrome has decided that it needs to do proxy auto-detection. My question is concerns what happens just before that.

Chrome currently appears to ask Windows for proxy configuration via the WinHTTP API WinHttpGetIEProxyConfigForCurrentUser. In Windows 7, the Windows Networking team changed the WinINET API call that retrieved proxy settings such that it would effectively "lie" and mask out the PROXY_TYPE_AUTO_DETECT result for networks where WPAD had previously failed. This performance optimization benefits all WinINET-using applications by default (since getting the UI checkbox state now requires a flag that didn't exist previously); the change was called SmartWPAD [1].  

What I don't know (but ought to be easy to test) is whether WinHttpGetIEProxyConfigForCurrentUser (a WinHTTP API) inherits the same optimization, such that we're not paying a performance hit on networks where Windows doesn't expect a proxy to be found.  

Of course, this is only an optimization that exists on Windows, and doesn't diminish the general issue that we probably ought to improve our flexibility here.

[1] https://stackoverflow.com/questions/2871510/unable-to-query-proxy-automatically-detect-settings-on-windows-7/5138232#5138232

We are digressing from this bug topic (disabling WPAD, on the grounds of it being a bad/dangerous protocol).

Regarding Smart WPAD, we can discuss that separately in 118385 if needed. From my testing just now, neither wininet's mechanism (INTERNET_PER_CON_OPTION_LIST) or WinHTTPGetIEProxyConfigForCurentUser() are masking auto-detect on WPAD failure (modeled as a PAC server that hangs).

> * Performance: Users with auto-detect pay a non-trivial and annoying performance penalty.

On the (many? most?) company networks where proxies is the only way out, auto-detect is a massive performance *boost* because it saves the incredibly tedious and error-prone hassle of timing out and (re)configuring proxies. I think it was one of the reasons I started preferring Chrome in the first place... Having to manually enable WPAD (initially twice; before and after login) is conversely one of most tedious things when using ChromeOS. See recent comment in  issue 654733 

The title and description start with "remove WPAD support", on the other hand later comments discuss default settings, fallbacks etc. So is it just the latter?

Are companies requiring proxies generally aware of security issues with WPAD - especially when the same laptops get used outside the company's network - and has the design of any better replacement started?

BTW some WPAD configurations are pretty large and can only be approximated manually.

This issue is about support for WPAD, not for explicitly configured PAC scripts or PAC scripts configured via DHCP.  WPAD is just a mechanism to get a PAC script from a location that is not explicitly configured.

DHCP is (a mandatory) part of the WPAD RFC.

The description at the top describes DNS as the worst flavour of WPAD and suggests removing (not just disabling) all of them.

> DHCP is (a mandatory) part of the WPAD RFC.

FWIW draft-ietf-wrec-wpad never made it past DRAFT, and most user agents don't implement it as written. (For instance neither Chrome nor Firefox do its described DNS devolution).

> The description at the top describes DNS as the worst flavour of WPAD and
> suggests removing (not just disabling) all of them.

DHCP-based WPAD is certainly an improvement compared to DNS-based WPAD in regards to traffic escaping your network. However isn't widely supported by user agents. In fact Chrome only supports it on some platforms, and browser like Firefox don't support it at all.

If WPAD (DHCP) support was to be removed from Chrome, what realistic alternatives would a global corporation have for setting PAC URLs on clients when PAC URLs often need to be different per country?

We currently use Group Policy (specifically Group Policy Preferences). However we're looking to WPAD so we can remove this Group Policy dependency.  Group policy presents a significant challenge given the way it's processed, as well as cached, not to mention the dependency on IT admins to accurately represent the physical subnet > site associations in AD, so site based GPOs can accurately hit their mark. WPAD would pretty much address all that with much less administration!

The non-WPAD alternatives aren't great, and currently boils down to using a Chrome extension.

Which as noted is a less appealing solution for enterprises, especially those supporting multiple browsers.

An extension would go down like a lead balloon.
Rather than pull the rug out from under the feet of your customers by potentially removing support for WPAD, is there not scope to recommend improvements the specification instead? ;-)

I think it's worth noting that if we ever get to a world where DNS over HTTPS is the standard, WPAD will give ISPs a way to monitor quite a bit of information that would otherwise be private, for HTTPS requests.