On 17/09/13 03:24, Brian Smith wrote: > Unfortunately, we heard from Google that it is actually difficult for > them to send these headers in HTTPS responses from their servers due > to some special requirements that I am not so familiar with.
Can we work out what those requirements are by studying the pinning configuration for google.com and its subdomains in Chrome? > I know > that Google's servers require exceptions to the HSTS includeSubdomains > rules, but providing a way to specify exceptions was rejected during > the work on defining HSTS. My understanding is that that isn't the > only roadblock. So, just to be clear: Google is achieving pinning in Chrome by preloading, and is 'happy' (willing) not to be pinned in other browsers because they are not sending the headers? > So far, we've taken the stance that we should avoid treating Google > specially. In what context? :-) I think that if we have a convenient "just set it up and it'll work" scanning system, and an inconvenient "you have to contact us and register" system, then the use of the latter will be limited to companies who can't use the former, and hopefully we'll avoid scaling issues. > Perhaps it is time to admit that perfect is the enemy of > the good here. We should find some way to work with Google and other > Google-like targets to get their SSL-related metadata preloaded into > Firefox sooner than our current policy would otherwise allow. I don't have an issue with people registering to be preloaded, as long as we allow more people than just Google to do so. Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
