Create FormatUrlForSecurityDisplay helper function.

chrome/browser/ui/elide_url.h

Index: chrome/browser/ui/elide_url.h
diff --git a/chrome/browser/ui/elide_url.h b/chrome/browser/ui/elide_url.h
index bd5321a633fbfb5513374903427ca6353be26ada..5df634c0e3779a3ade840c0b2b2a8ac20819ae34 100644
--- a/chrome/browser/ui/elide_url.h
+++ b/chrome/browser/ui/elide_url.h
@@ -45,4 +45,15 @@ base::string16 ElideHost(const GURL& host_url,
                          const gfx::FontList& font_list,
                          float available_pixel_width);
 
+// This is a convenience function for formatting a URL as an origin in a concise
+// and human-friendly way. Use this instead of |net::FormatUrl| when the reader
+// needs only to understand the origin (rather than the entire URL).
+//
+// - Omits the path for standard schemes, excepting file and filesystem.
+// - Omits the port if it is the default for the scheme.

[Ryan Sleevi, 2015/06/01 21:18:46]

This is more a comment nit, but after the discussion about filesystem, and the
fact that we're including path for filesystem, it does feel weird to call this
origin. That is, it's not an origin in the scheme/host/port tuple, and it's not
an origin in the sense of "globally unique" origin (e.g. as in RFC 6454 for non
scheme/host/port , or data URls)

This is more about formatting the effective security boundary, but "ish".
Ontologies and naming are hard, and I don't think we'd want to take a
hypothetical url::Origin or blink::SecurityOrigin here in this function (which
feels somewhat implied by FormatOrigin and naming |origin|), so maybe

FormatUrlForSecurityDisplay?

Note, I absolutely hate that naming, but at least it works as a strawman to
explore the slight unease I feel at naming.

ElideUrlForSecurityDisplay? 

[palmer, 2015/06/01 23:30:34]

Do you mean the discussion about file: ?
As currently implemented in this CL, the code only does that when the inner URL
is a file: URL.
As I understand, paths are (the only) part of an origin for file: URLs. (As
discussed previously.)

So, I do think that this function returns a string that displays, as
human-readably as is currently possible, the
origin-as-web-security-boundary-as-enforced-right-now-in-Chrome.
Right, but, what is the "ish"? Are there aspects of certain kinds of origins
that form part of the effective security boundary that we are not displaying?
And/or, are we displaying aspects of certain kinds of origins that do not form
part of the security boundary? (Perhaps you mean I should leave off the
"filesystem:" prefix for filesystem: URLs?)
Why not? I do have some concern that FormatOriginForDisplay is closer to correct
than GURL::GetOrigin, if that's what you mean. (ISTR that GURL::GetOrigin
returns objects whose spec() is "file://" for *all* file: URLs, which implies
untrue things about Chrome's behavior. But I don't own GURL.)

(In my dream world, FWIW, url.GetOrigin().spec() would be pretty close to
FormatOriginForDisplay(url).)
I mean, sure, I could do that, with the appropriate comment changes too. But
first I want to make sure I have understood your concern correctly.
No; "elide" here means "replace long strings with '...'."

[Ryan Sleevi, 2015/06/02 01:08:14]

No, I meant filesystem. Filesystem is a non-standard URL that has an inner URL
that is the true origin, as discussed on url.spec.whatwg.org (and not handled by
RFC 6454)
Put differently, you aren't returning globally unique identifiers, which is the
true origin (in RFC 6454 sense) for data URIs, for example.

And you are reaching inside filesystem: (because //URL knows about it, but 6454
says unique identifier), but not blob (because //URL doesn't know about it, even
though it is the same as blob), which are the true origins-as-a-principle.

I left this a nit because, as discussed with Mike, the origin terminology is
heavily overloaded (two specs, three concepts at play, multiple implementations)

In Windows terms, I think it is like using "Account" to refer to both the SID
and the NtLogonName. They overlap, but not completely, you can have duplicate
but distinct SIDs (in the Local space arc, distinct machines can have the same
sid, but different principles; in origins, the null origin is unique and
non-identity), you can have abbreviations (omitting Domain or DC and omitting
port/path), things like that.

Just like Account is confusing, I think there is reasonable confusion here.
See above.
Because a SecurityOrigin is lossy. It could be simply a unique number or "null".
It doesn't convert back to a user friendly URL.
I don't have the CL handy (mobile), but if you look at the introduction of
URL::origin, you can see abarths explanation to tsepez on why that is bad.
Origin is a loaded term. If you got a GURL for a sandboxed iframe, what is the
expectation? An empty string? That's the true origin.

+//
+// Do not use this for URLs which will be parsed or sent to other applications.
+base::string16 FormatOriginForDisplay(const GURL& origin,
+                                      const std::string& languages);
+
 #endif  // CHROME_BROWSER_UI_ELIDE_URL_H_