I believe we weren't sending cookies or auth prior to my change (Maybe we were using system auth credentials, actually, not sure, we certainly weren't using user-entered credentials, not sure about extension-provided ones).

We were sending cookies and auth prior to your change, but the dependencies were a bit different - the cookie store was that of the system url request context, whereas now it is that of the main context's. So the scope of those cookies is wider now (is the system request cookie store persisted to disk?)

I want to say that PAC fetches have no business using cookies:
There shouldn't be any user interaction with PAC scripts that warrants cookies, or stateful interactions, and allowing them simplifies some cross network tracking. Also our other wonky side-requests like OCSP don't send cookies.

So conceptually I don't think we should allow cookies.

There is some risk in blocking cookies.
Given past experience with favicons when blocking cookies, general redirect loops from websites that redirect based on present cookies, or more recently observing broken HSTS + WPAD deployment, there may well be some wonky PAC server that stops working, but I would expect it to be a minority.

I'll go ahead and try this, as it easy enough to roll-back.

Note that the auth cache is part of the NetworkSession, and the ProxyURLRequestContext had its own NetworkSession.  So no user entered authentication information was used with PAC requests.  Similarly, extension auth is hooked up through ChromeNetworkDelegate - and while the ProxyURLREquestContext may have had one of those, extensions are per-profile, so no extension-provided credentials were available, either.

I'm not sure about platform credentials - ProxyScriptFetcherImpl::OnAuthRequired returns ERR_NOT_IMPLEMENTED, but I can't remember if we call that or not when using system credentials.  We do at least bounce up to the URLRequestJob layer, so I'd be surprised if we didn't jump above that layer as well.

Authentication via ambient credentials happen without bubbling up a OnAuthRequired callback. It is likely that some enterprise deployments perhaps unknowingly rely on ambient authentication for PAC fetches. Something to keep in mind.

One option is to explicitly disable prompting, and only allow Negotiate for PAC script fetches.

Note that disabling prompting and only allowing negotiate are not the same thing, because we're now sharing the auth cache.

Also, there's a plan to merge LOAD_DO_NOT_SEND_COOKIES, LOAD_DO_NOT_SET_COOKIES, and LOAD_DO_NOT_SEND_AUTH_DATA (So we don't have sockets with mixed values in the privacy mode / non-privacy mode socket pools), so we probably don't want to mix and match, and instead stick with either sending everything, or sending nothing.