Twitter's HTTP response vs Google's HTTP response

Question

I was looking at the HTTP responses form https://twitter.com and https://encrypted.google.com. These two responses have interesting similarities and differences in their security definitions.

Both Twitter and Google have these header elements in common for the purposes of security:

X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Server: *custom*
Expires: *in the past*
Cache-Control: private***

However, twitter has a more extensive cache-control declaration and uses HSTS:

cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
strict-transport-security: max-age=631138519

Questions:

1. Is there any reason not to use HSTS? Is Google depending on HSTS preloading, and "normal" web application should enable HSTS?
2. Are Google users more susceptible to Cache related information disclosure than Twitter users because of the differing cache-control definition?

For completeness I have included the full HTTP header for both sites.

The HTTP response from https://encrypted.google.com:

HTTP/1.1 200 OK
Date: Sun, 06 Oct 2013 19:27:33 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=REMOVED
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 443:quic
Content-Length: 100392

The HTTP response from https://twitter.com:

HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Length: 50221
content-type: text/html;charset=utf-8
date: Sun, 06 Oct 2013 19:33:08 GMT
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Sun, 06 Oct 2013 19:33:08 GMT
ms: S
pragma: no-cache
server: tfe
set-cookie: _twitter_sess=REMOVED
status: 200 OK
strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-transaction: 699d2669d76b27f5
x-ua-compatible: IE=10,chrome=1
x-xss-protection: 1; mode=block

Answer 1

Google is not using HSTS enforcement. Neither in preloading nor headers. The preloaded HSTS entry in Chrome is set to "OPPORTUNISTIC" which basically means "unenforced", though it contains a set of allowed certificate hashes to prevent MITM.

Google's redirect to https depends on browser detection criteria, such as user-agent. I don't know precisely what criteria they check, but for example browsing google.com using Links does not redirect to https, and searching over unencrypted channels is still allowed, though browsing from Chrome will redirect (with a 302) to https. Furthermore, many URLs on the domain are not redirected to https no matter what browser you use. For example: http://www.google.com/services/

Their reason for not requiring SSL is not explicitly documented anywhere, but it probably has to do with the fact that doing so might "break things" -- albeit poorly-written things, most likely. The current trajectory seems to point toward migrating all of Google over to SSL, but they're doing so one piece at a time. My best guess would be to expect HSTS enforcement within 5 years.

The cache-control difference reflects the fact that Google's homepage is static, while Twitter's is constantly updated with new tweets. Google allows the browser to (privately) cache the search box splash page for a limited time, but twitter requires a reload in order to fetch the latest batch of deep philosophical insights from all your Twitter friends.

As for cache-related information disclosures; I'm not aware of any. The Google homepage contains no personal information unless delivered over HTTPS (in which case you get that bar at the top), which limits disclosure potential.

Answer 2

To my knowledge there is no reason to not use HSTS if your site already enforces TLS using other means. Non-compliant user agents will simply disregard the header so there is no problem there. Would HSTS reduce load on the host? It no longer needs to keep serving the redirects as compliant user agents navigate directly to the https:// URI. The HSTS pre-loading covers a lot of users but not all as you state, it is slightly odd they don't issue HSTS Policy.

As for number 2 I'm unsure sorry.