HTTP not being converted to HTTPS with HSTS

To cite from the source code you mention:

354  // Other Google-related domains that must use an acceptable certificate
355  // iff using SSL.
     ...
361  { "name": "doubleclick.net", "include_subdomains": true, "pins": "google" },

This means that the certificate is pinned iff the site is served over https. It does not mean that the site needs to be served over https. This is different for other domains where the force-https attribute is set:

264  { "name": "accounts.google.com", "include_subdomains": true, "mode": "force-https", "pins": "google" },

---

EDIT: based on the source code of Chromium (function TransportSecurityState::GetStaticDomainState in net/http/transport_security_state.cc) I'll try to explain the information which can be seen in chrome://net-internals/#hsts and how it relates to the static information from net/http/transport_security_state_static.json using the example doubleclick.net:

static_sts_domain: doubleclick.net
static_upgrade_mode: OPPORTUNISTIC

OPPORTUNISTIC is the default mode (STSState::MODE_DEFAULT). This means that it does not force HTTPS. The default mode is used since no explicit force-https setting was given in the configuration.

static_sts_include_subdomains: true

Since it does not enforce https this setting does not matter. But the value might be caused by the configuration of include_subdomains shown above even if this configuration line does not include force-https.

static_sts_observed: 1476162000

This is the build time of the static HSTS/HPKP list, i.e. 2016/09/04 in this case.

static_pkp_domain: doubleclick.net
static_pkp_include_subdomains: true
static_pkp_observed: 1476162000
static_spki_hashes: sha256/IPMbDAjLVSGntGO3WP53X/zilCVndez5YJ2+vJvhJsA=,sha256/7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=,sha256/h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=

These are the information about pinning. These have a direct relation to the settings shown above (i.e. include_subdomains and which pins should be used).

HSTS only apply for the domain it's been set.

What you are looking for is upgrade-insecure-requests CSP directive.

Content-Security-Policy: upgrade-insecure-requests

In the HSTS preload list, doubleclick.net is NOT listed for HSTS for for key pinning.

More details on https://scotthelme.co.uk/migrating-from-http-to-https-ease-the-pain-with-csp-and-hsts/