Make URLs https by default and 301 redirect http requests

[sinak]

Google Fonts currently suggests http URLs by default to users for both css and javascript resources.

• Google Fonts should suggest https URLs by default.
• Google Fonts should also redirect http requests to https. More guidance by @konklone here.

[adrianhopebailie]

+1

[vsaw]

👍

[parkr]

👍

[konklone]

Switching the recommended URL from http:// to https:// should be a no-brainer.

Turning on HSTS and preloading the domain, whether or not a redirect is in place, should be problem-free.

As for turning on the HTTP->HTTPS redirect, my experience from testing HTTP->HTTPS redirects was that <script> tags are completely unaffected by 301 redirects from HTTP to HTTPS, even as far back as IE6.

If Google Fonts currently observes significant CORS usage from Safari and Android browsers, that might be a hindrance to forcing a redirect. However, CORS doesn't seem to be a formally or universally supported feature for Google Fonts, and so this issue may be moot.

In short, HSTS and preloading will improve the safety and privacy of a great number of people right away. If there's no significant CORS usage, then a forced redirect should, to the best of my knowledge and research, also work without breaking Google Fonts for clients.

[Croydon]

👍

[lenovouser]

+1

[kuettel]

Google Fonts supports both HTTP and HTTPS, thus allowing the integration (or browser, when using protocol-relative URLs) the method of choice.

There are interesting trade-offs (which will vary by integration) either way, such as the latency savings from intermediate caches in-between with HTTP.

A forced HTTPS and/or redirect would adversely affect the latency of existing integrations, esp. ones which benefit tremendously from an intermediate caching of the fonts.

[konklone]

A forced HTTPS and/or redirect would adversely affect the latency of existing integrations, esp. ones which benefit tremendously from an intermediate caching of the fonts.

Yet allowing Google Fonts to be served over HTTP allows Google Fonts to be modified, hijacked, or otherwise weaponized by network owners. It's because Baidu Analytics allows plain HTTP use of its analytics snippet, for example, that allowed it to be so easily weaponized by China's Great Cannon during the recent DDoS of GitHub. This is separate from other, less martial, attacks on unencrypted traffic by domestic ISPs in the US.

Google Fonts has immense reach on the web today, and fonts.googleapis.com makes a highly attractive target on any given network. Choosing security and privacy, both for yourself and on behalf of your users, is a tradeoff whose value has become much more clear to many more popular services over the last year or so -- especially at Google.

I strongly urge you to reconsider, and to make the security of individual end users of Google Fonts a top priority. As it stands, Google Fonts is catering to the desires of integrators, and allowing them to make the wrong choice -- a choice that effects millions of people who have no way of noticing what's happening or expressing an opinion on the matter.

[bifurcation]

I would also observe that the latency impact is likely to be negative, at least for modern browsers that support HTTP/2. With HTTP/2 connection re-use, new HTTPS transactions will re-use an existing TLS connection. And most of the world already has a TLS connection to Google. So not only will you not be incurring an additional TLS handshake, you'll be saving a TCP handshake and slow start.

Have you actually done the experiment to see the latency impact? Given the above, I would suggest giving it a try before concluding that HTTPS causes a latency hit.