kMaxHSTSAgeSecs is currently 1 year [1].
I didn't know/had forgotten about this when I updated htspreload.org to include a recommendation for a max-age of 2 years [1]. That choice was basically due to two factors:

1. Many sites in the wild use max-ages up to 2 years; very few go higher.
2. If you visit a site roughly once a year, but not always within less than 1 year of the previous time, then 2 years provides value over 1 year. (For example, imagine you do your taxes on a site that uses HSTS one year on Feb. 2, but next year on Feb. 20.)

Based on my scans of preloaded domains that send an HSTS header:

-  4.4% of max-ages are <= 18 weeks
- 30.8% of max-ages are <= 1/2 year
- 65.5% of max-ages are <= 1 year
- 98.4% of max-ages are <= 2 years

See [2] for scans of the Alexa top 1M (2 years is common, but not relatively as common) and preloaded sites (roughly match my values above).

Alternatively, Firefox and IE/Edge do not cap max-age for dynamic HSTS at all, without ill effects. At some point, exactly how large an HSTS max-age is doesn't really affect risk for the site owner (although it could affect a new site owner if the site changes hands).

It feels weird for hstspreload.org to recommend a larger value for the dynamic header than Chrome will store, so I'd like to make the values match if it's not too much trouble. Considering the reasons above, I currently favor 2 years.

rsleevi@, agl@, estark@: Any concerns about landing a simple CL to increase kMaxHSTSAgeSecs to 2 years?

[1] https://cs.chromium.org/chromium/src/net/http/http_security_headers.h?type=cs&q=kMaxHSTSAgeSecs&sq=package:chromium&l=21
[2] https://github.com/chromium/hstspreload.org/issues/62#issuecomment-245797280
 

kMaxHSTSAgeSecs is currently 1 year [1].
I didn't know/had forgotten about this when I updated htspreload.org to include a recommendation for a max-age of 2 years [1]. That choice was basically due to two factors:

1. Many sites in the wild use max-ages up to 2 years; very few go higher.
2. If you visit a site roughly once a year, but not always within less than 1 year of the previous time, then 2 years provides value over 1 year.

As an example for #2, imagine you do your taxes on a site that uses HSTS one year on Feb. 2, but next year on Feb. 20.
And the variation could be significantly more – without thinking hard, I can provide evidence of a yearly event that changed from September to December in successive years [2].

Based on my scans of preloaded domains that send an HSTS header:

-  4.4% of max-ages are <= 18 weeks
- 30.8% of max-ages are <= 1/2 year
- 65.5% of max-ages are <= 1 year
- 98.4% of max-ages are <= 2 years

See [2] for scans of the Alexa top 1M (2 years is common, but not relatively as common) and preloaded sites (roughly match my values above).

Alternatively, Firefox and IE/Edge do not cap max-age for dynamic HSTS at all, without ill effects. At some point, exactly how large an HSTS max-age is doesn't really affect risk for the site owner (although it could affect a new site owner if the site changes hands).

It feels weird for hstspreload.org to recommend a larger value for the dynamic header than Chrome will store, so I'd like to make the values match if it's not too much trouble. Considering the reasons above, I currently favor 2 years.

rsleevi@, agl@, estark@: Any concerns about landing a simple CL to increase kMaxHSTSAgeSecs to 2 years?

[1] https://cs.chromium.org/chromium/src/net/http/http_security_headers.h?type=cs&q=kMaxHSTSAgeSecs&sq=package:chromium&l=21
[2] https://www.worldcubeassociation.org/competitions?utf8=%E2%9C%93&region=all&search=german+nationals&year=all+years&state=past&delegate=&display=list
[3] https://github.com/chromium/hstspreload.org/issues/62#issuecomment-245797280