Added characters that look like padlocks to URL unescaping blacklist.

net/base/escape.h

Index: net/base/escape.h
diff --git a/net/base/escape.h b/net/base/escape.h
index c4abe1469a86de71cd4fe3dd5a7a32ed38b3a5ab..0ff10ed2d539e513e13c90b86aa539a5577fc8ed 100644
--- a/net/base/escape.h
+++ b/net/base/escape.h
@@ -94,7 +94,8 @@ class UnescapeRule {
 
     // Unescapes control characters such as %01. This INCLUDES NULLs. This is
     // used for rare cases such as data: URL decoding where the result is binary
-    // data. This flag also unescapes BiDi control characters.
+    // data. This flag also unescapes BiDi control characters and spoofable
+    // characters (such as LOCK).

[Peter Kasting, 2015/06/22 07:35:22]

Nit: This might call out the spoofable part more:

Unescapes characters that can be used in spoofing attempts (such as LOCK) and
control characters (such as BiDi control characters and %01).  This INCLUDES
NULLs.  This is used for rare cases such as data: URL decoding where the result
is binary data.

(This suggests maybe SPOOFING_AND_CONTROL_CHARS would work as a new enum name...
although now that I read the bit about "includes nulls", I'm not as disinclined
toward my original DANGEROUS_CHARS name as I was.)

[Matt Giuca, 2015/06/23 04:14:10]

OK, I'm getting that you want me to rename this ;)

I chose to call it NON_DISPLAY_CHARS. I don't like names like "DANGEROUS_CHARS"
because characters are only dangerous in certain contexts (in this case, if you
display them). Also control chars aren't dangerous per se, some of them probably
would just show as boxes. What these all have in common is that they are
characters that should not be displayed in UI (all the documentation surrounding
CONTROL_CHARS says "don't use this if you are going to display them in the UI"),
so I think NON_DISPLAY_CHARS is an appropriate name and could later be expanded
to include other things that shouldn't be displayed, like non-breaking spaces.

WDYT?

[Peter Kasting, 2015/06/23 04:35:53]

The whole point of this function is to prepare a URL for display, so this
objection seems a bit odd.
Embedded control characters could change the appearance and function of the URL
either in Chrome or in other applications you copied and pasted the URL to.  I
don't think "characters might show as boxes" is the limit of the danger here,
even in the omnibox.
I don't like NON_DISPLAY_CHARS (sorry...).  I think it reads as "non-displaying
characters", e.g. control characters, zero-width characters, soft hyphens, etc. 
But these banned characters are displaying characters.

I think either of my original suggestions is clearer.

[Matt Giuca, 2015/06/23 06:21:24]

No it isn't, it's used about equally for the two purposes of a) preparing a URL
for display, and b) decoding binary data that was encoded in a URL (like data:
URLs). The distinction at the call site is that in case (a) you do not use
CONTROL_CHARS, and in case (b), you do use CONTROL_CHARS.

So it seemed appropriate to rename CONTROL_CHARS to NON_DISPLAY_CHARS, for times
where you are not preparing a URL for display.
Fair enough.
I still don't like DANGEROUS_CHARS because it implies that a client using this
function for use case (b) (decoding a data URL) is doing something dangerous.
Whereas in fact it is perfectly safe as long as you don't display the decoded
string in a context of a URL.

Let's go with SPOOFING_AND_CONTROL_CHARS then.

[Peter Kasting, 2015/06/23 06:55:15]

How I think of it: That second case _is_ preparing the URL for display.  You're
prepping a data: URL for display as data, to be displayed to the user in the
content area.

Semantics :P
SGTM.

     //
     // DO NOT use CONTROL_CHARS if the URL is going to be displayed in the UI
     // for security reasons.