Make ConnectionSecurityHelper a namespace instead of a class

chrome/browser/ssl/connection_security_status.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_SSL_CONNECTION_SECURITY_STATUS_H_
+#define CHROME_BROWSER_SSL_CONNECTION_SECURITY_STATUS_H_
+
+#include "base/macros.h"
+#include "content/public/common/security_style.h"
+
+namespace content {
+class WebContents;
+}  // namespace content
+
+// This namespace contains functions responsible for computing the
+// connection security status of a page.
+namespace ConnectionSecurityStatus {

[estark, 2015/06/09 21:39:50]

Is naming a namespace like this allowed? (as opposed to e.g. chrome_browser_ssl)

ConnectionSecurityStatus seemed more descriptive than chrome_browser_ssl, and
someone (I forget who) told me that we weren't doing namespaces-named-by-path
anymore. (Though I do remember that the person who told me that couldn't
remember why and couldn't find a citation.)

[Peter Kasting, 2015/06/10 00:09:08]

No:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Namespace_Names

"Namespace names are all lower-case"

The example there makes clear that unix_hacker_style is the appropriate style
for namespace names.

It's possible to name a namespace other than by its pathname.  For example, I
wouldn't be opposed to "connection_security" here.

[estark, 2015/06/10 00:41:15]

Ah, ok, I missed that, thanks. I renamed it to connection_security_status. (Do
you prefer connection_security over connection_security_status?) 

[Peter Kasting, 2015/06/10 01:53:36]

I don't have a strong preference, the former just seemed shorter and potentially
more flexible if this were ever to include something other than getters, without
losing much clarity.

[estark, 2015/06/10 04:16:17]

Fair enough; changed to connection_security.

+
+// TODO(wtc): unify this enum with SecurityStyle.  We
+// don't need two sets of security UI levels.  SECURITY_STYLE_AUTHENTICATED
+// needs to be refined into three levels: warning, standard, and EV.
+// See crbug.com/425728
+//
+// If you reorder, add, or delete values from this enum, you must also
+// update the UI icons in ToolbarModelImpl::GetIconForSecurityLevel.
+//
+// A Java counterpart will be generated for this enum.
+// GENERATED_JAVA_ENUM_PACKAGE: org.chromium.chrome.browser.ssl
+// GENERATED_JAVA_CLASS_NAME_OVERRIDE: ConnectionSecurityStatusSecurityLevel
+enum SecurityLevel {
+  // HTTP/no URL
+  NONE,
+
+  // HTTPS with valid EV cert
+  EV_SECURE,
+
+  // HTTPS (non-EV)
+  SECURE,
+
+  // HTTPS, but unable to check certificate revocation status or with insecure
+  // content on the page
+  SECURITY_WARNING,
+
+  // HTTPS, but the certificate verification chain is anchored on a
+  // certificate that was installed by the system administrator
+  SECURITY_POLICY_WARNING,
+
+  // Attempted HTTPS and failed, page not authenticated
+  SECURITY_ERROR,
+};
+
+// Returns a security level describing the overall security state of
+// the given |WebContents|.
+SecurityLevel GetSecurityLevelForWebContents(
+    const content::WebContents* web_contents);
+
+// Returns the content::SecurityStyle for the given |web_contents|.
+// Note: This is a lossy operation. Not all of the policies
+// that can be expressed by a SecurityLevel (a //chrome concept) can
+// be expressed by a content::SecurityStyle.
+// In general, code in //chrome should prefer to use
+// GetSecurityLevelForWebContents() to determine security policy, and
+// only use this function when policy needs to be supplied back to
+// layers in //content.
+content::SecurityStyle GetSecurityStyleForWebContents(
+    const content::WebContents* web_contents);
+
+}  // namespace ConnectionSecurityStatus
+
+#endif  // CHROME_BROWSER_SSL_CONNECTION_SECURITY_STATUS_H_