It sounds like the right people are already on this, so adding Enterprise-Triaged label.

If I am understanding your proposal in comment #0, it is to exclusively use client-side name resolution when using a proxy? That doesn't sound like a practical change given how proxies behave and are used today.

WPAD and proxy config over DHCP (Is that enabled by default?) should not give middleboxes to sniff visited hostnames that would otherwise be encrypted.

Why not just remove support for proxies alltogether then?

In this end state, a proxy can't see the URL, hostname, or the bytes of the request/response. All it would have access to is the IP address of destination.

I guess it could still layer on proxy auth.

Either SSL hostnames are private or they are not.  Historically, we've considered them not.  However, investments DoH and ESNI only make sense if they are private information.

I am sympathetic to the end goal, but my concern is in how to bridge this gap given how proxies have and are being used.

Explicit proxies are frequently used specifically _because_ they let you decide name resolution. For instance a SOCKv5 proxy from an SSH tunnel, lets you defer name resolution to the remote end. Or enterprises that use a HTTP(S) proxy to access corporate resources, whose names are not locally resolvable (think also non-FQDN).

If we break those use-cases for a proxy, we need to be prepared to offer alternatives to achieve those goals.

I think requiring more explicit opt-in might be the best solution (i.e., no automatic WPAD or DHCP - no idea of what are reasonable alternatives here).

Matt, assigning this to you to get it out of our triaging queue.

Leaving as available to get it out of my bug queue, and as I currently have no plans to tackle this.  If that gets it back in your triaging system, suggest removing the Enterprise label - network team generally doesn't assign people a bunch of bugs they don't plan to work on.