[net] Add an informational bubble to about:net-internals#proxy when using a single SOCKS v5 proxy s…

[net] Add an informational bubble to about:net-internals#proxy when using a single SOCKS v5 proxy server.

Explains how to use --host-resolver-rules to prevent Chrome from making local DNS requests outside of the proxy.

BUG=123716
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=188012

[eroman, 2013-03-06 22:55:25]

This is what it looks like:
http://i.imgur.com/YdzczYt.png

[mmenke, 2013-03-07 15:27:35]

On 2013/03/06 22:55:25, eroman wrote:
> This is what it looks like:
> http://i.imgur.com/YdzczYt.png

Why socks5 proxies only?  Shouldn't the same be true of HTTP and SPDY proxies,
but not socks4 proxies?

Who's the target audience for this?  net-internals isn't internationalized, or
part of the "public" Chrome interface, so this will only be useful to people who
know about net-internals and speak English.

[eroman, 2013-03-07 19:58:08]

On Thu, Mar 7, 2013 at 7:27 AM, <mmenke@chromium.org> wrote:

> On 2013/03/06 22:55:25, eroman wrote:
>
>> This is what it looks like:
>> http://i.imgur.com/YdzczYt.png
>>
>
> Why socks5 proxies only?  Shouldn't the same be true of HTTP and SPDY
> proxies,
> but not socks4 proxies?
>

I can include socks4 too. However selecting the wrong protocol version
doesn't seem to be a problem anymore, since I changed the defaults to SOCKS
5.


>
> Who's the target audience for this?  net-internals isn't
> internationalized, or
> part of the "public" Chrome interface, so this will only be useful to
> people who
> know about net-internals and speak English.
>

Understood.

The issue is that DNS not being "forwarded" through SOCKS is an often
reported issue. There are complaints almost every month, see for instance:

https://code.google.com/p/chromium/issues/detail?id=29914
https://code.google.com/p/chromium/issues/detail?id=18142
https://code.google.com/p/chromium/issues/detail?id=105262
https://code.google.com/p/chromium/issues/detail?id=123716
https://code.google.com/p/chromium/issues/detail?id=161224
https://code.google.com/p/chromium/issues/detail?id=55744
https://code.google.com/p/chromium/issues/detail?id=91156

In those bug threads, the majority of the users appear to be configuring
things from the command line, and also look like power users, often quoting
about:net-internals.

Continually mentioning that DNS prefetching and the like must be disabled
for these users is not a scalable strategy.

My intention with adding this information bubble is to at least increase
awareness among these users, who may in turn circulate the knowledge.

The biggest usecase seems to be using SOCKS v5 as an anonymizing proxy
(TOR). The best longterm solution would be adding a mode specifically for
these privacy concerned users.
https://code.google.com/p/chromium/issues/detail?id=123716 also covers some
middle ground.


>
https://codereview.chromium.**org/12549010/<https://codereview.chromium.org/1...
>

[mmenke, 2013-03-07 20:00:39]

On 2013/03/07 19:58:08, eroman wrote:
> On Thu, Mar 7, 2013 at 7:27 AM, <mailto:mmenke@chromium.org> wrote:
> 
> > On 2013/03/06 22:55:25, eroman wrote:
> >
> >> This is what it looks like:
> >> http://i.imgur.com/YdzczYt.png
> >>
> >
> > Why socks5 proxies only?  Shouldn't the same be true of HTTP and SPDY
> > proxies,
> > but not socks4 proxies?
> >
> 
> I can include socks4 too. However selecting the wrong protocol version
> doesn't seem to be a problem anymore, since I changed the defaults to SOCKS
> 5.

I was wondering more about HTTP and SPDY proxies, actually, neither of which
need to do local lookups.

[eroman, 2013-03-07 20:05:43]

Number of times I have seen users complain about "dns leaking" for HTTP or SPDY
proxies ---> ZERO.

[eroman, 2013-03-07 20:06:14]

(in case it wasn't clear, that was using the bill clinton "ZERO")

[mmenke, 2013-03-07 20:16:57]

Ok, sounds reasonable.  Suppose the only place we surface that we really are DNS
prefetching is net-internals, too.

LGTM.

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
File chrome/browser/resources/net_internals/proxy_view.js (right):

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:69: if (!proxySettings)
Should we be hiding the hints here?

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:117: // exclusions for host
resolving.
If this isn't a TODO, should this be in the displayed comment?

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:141: return undefined;
I think returning null is a bit more natural.

[eroman, 2013-03-07 20:23:32]

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
File chrome/browser/resources/net_internals/proxy_view.js (right):

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:69: if (!proxySettings)
On 2013/03/07 20:16:57, mmenke wrote:
> Should we be hiding the hints here?

Good point. Yes we should.

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:117: // exclusions for host
resolving.
On 2013/03/07 20:16:57, mmenke wrote:
> If this isn't a TODO, should this be in the displayed comment?

I considered just implementing this, however the supported formats for
--host-resolver-rules and proxy bypass rules are not 1:1. Proxy bypass rules
allow for things like IP block ranges "ffe1::3/17", and "<local>". I could
expand on the C++ side, but not sure that is worth the effort.

Another difference is host-resolver-rules just does string matching, so it won't
compensate for IP literal normalization (you could specify an IPv6 address that
will never be matched, if it is not given in normalized form).

Since this is just a mini-hack, which will hopefully be superceded in the future
when there is better understanding, or better support for setting proxies in
Chrome.

Hence I don't think that complexity is something worth implementing in the
Javascript, that is why no TODO.

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:141: return undefined;
On 2013/03/07 20:16:57, mmenke wrote:
> I think returning null is a bit more natural.

Will do.

[mmenke, 2013-03-07 20:26:06]

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
File chrome/browser/resources/net_internals/proxy_view.js (right):

https://codereview.chromium.org/12549010/diff/3001/chrome/browser/resources/n...
chrome/browser/resources/net_internals/proxy_view.js:117: // exclusions for host
resolving.
On 2013/03/07 20:23:32, eroman wrote:
> On 2013/03/07 20:16:57, mmenke wrote:
> > If this isn't a TODO, should this be in the displayed comment?
> 
> I considered just implementing this, however the supported formats for
> --host-resolver-rules and proxy bypass rules are not 1:1. Proxy bypass rules
> allow for things like IP block ranges "ffe1::3/17", and "<local>". I could
> expand on the C++ side, but not sure that is worth the effort.
> 
> Another difference is host-resolver-rules just does string matching, so it
won't
> compensate for IP literal normalization (you could specify an IPv6 address
that
> will never be matched, if it is not given in normalized form).
> 
> Since this is just a mini-hack, which will hopefully be superceded in the
future
> when there is better understanding, or better support for setting proxies in
> Chrome.
> 
> Hence I don't think that complexity is something worth implementing in the
> Javascript, that is why no TODO.

That sounds reasonable.  But I was actually thinking if it's not a TODO, it
should perhaps be mentioned in the text we display to the user.  Just something
along the lines that anything set to bypass the proxy will require additional
rules.

[commit-bot: I haz the power, 2013-03-13 22:38:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eroman@chromium.org/12549010/13001

[commit-bot: I haz the power, 2013-03-13 22:38:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/eroman@chromium.org/12549010/13001

[commit-bot: I haz the power, 2013-03-14 07:23:11]

Change committed as 188012