Preloading HSTS for TLDs across browsers

[Lucas Garron]

Hi everyone,

As recently announced, Google has just preloaded several new TLDs in Chrome. We are also talks with other security-conscious TLD owners about preloading their TLDs. This approach is powerful because it permanently protects a whole swath of domains, rather than requiring an entry for each domain (which takes more space in the preload list, and take time to roll out for each domain). We would like all these preloaded TLDs to reach all browsers. :-)

Right now, Mozilla’s script for filtering the Chromium list removes most TLDs, because it can’t connect to TLDs to verify their HSTS headers like it can for normal domains. This means the entries are not reaching Firefox, and they are also not reaching Microsoft's operating systems and browsers (which pull from the filtered Firefox list).

In a preliminary email thread, Mozilla indicated they were open to picking up TLD entries,  but we need to figure out how. I see two options:

• Keep the format of the Chromium list, and modify Mozilla’s script not to filter out any entries that appear to be TLDs.

• Annotate the entries in Chromium and update the Mozilla script not to filter out entries with certain annotations.

I have an idea for the latter approach that also solves several other problems I’m currently facing: add a “policy” field to each entry in the Chromium source. I’ve scoped this out here, and the set of policies would look something like this: "test", "etld", "google", "custom", "bulk-legacy", "bulk-18-weeks", "bulk-1-year", "etld-requested-gov".

Here's a strawman proposalIf Firefox only filters out domains with policies that start with “bulk”, they will automatically retain the eTLD and (eTLD-requested entries) entries, without hard-coding more specific knowledge in their script. At present, non-bulk HSTS entries only make up about 1% of the list, so this shouldn't make a significant size impact.

dkeeler@/Mozilla folks: Does this approach look reasonable to you? Do you have any other desires/requirements?

Gabriel/Microsoft: If Mozilla includes TLDs in their list, can you confirm whether Microsoft will automatically pick those up?

Anyone else who processes the preload list: Do you ever want to distinguish between kinds of preloaded entries beyond this kind of policy classification?

»Lucas

[Ryan Sleevi]

On Thu, Oct 19, 2017 at 5:31 PM, Lucas Garron <lga...@chromium.org> wrote:

Hi everyone,

As recently announced, Google has just preloaded several new TLDs in Chrome. We are also talks with other security-conscious TLD owners about preloading their TLDs. This approach is powerful because it permanently protects a whole swath of domains, rather than requiring an entry for each domain (which takes more space in the preload list, and take time to roll out for each domain). We would like all these preloaded TLDs to reach all browsers. :-)

Right now, Mozilla’s script for filtering the Chromium list removes most TLDs, because it can’t connect to TLDs to verify their HSTS headers like it can for normal domains. This means the entries are not reaching Firefox, and they are also not reaching Microsoft's operating systems and browsers (which pull from the filtered Firefox list).

In a preliminary email thread, Mozilla indicated they were open to picking up TLD entries,  but we need to figure out how. I see two options:

• Keep the format of the Chromium list, and modify Mozilla’s script not to filter out any entries that appear to be TLDs.

• Annotate the entries in Chromium and update the Mozilla script not to filter out entries with certain annotations.

I have an idea for the latter approach that also solves several other problems I’m currently facing: add a “policy” field to each entry in the Chromium source. I’ve scoped this out here, and the set of policies would look something like this: "test", "etld", "google", "custom", "bulk-legacy", "bulk-18-weeks", "bulk-1-year", "etld-requested-gov".

Could you clarify more about "etld" and "etld-requested-gov"? We've been trying to stay away from terminology re: eTLD in the various spaces, so it might be helpful to be precise. That is, is it just related to TLDs? Or is there more you expect (e.g. ccTLDs)?

[Lucas Garron]

Good to know! I also find eTLD a pretty awkward term. :-(

In general, it is beneficial to preload parent domains instead of individual child domains. Although we are only in talks with gTLDs right now, I would be eager to preload any public suffix that is ready – old TLDs, gTLDs, ccTLDs, or anything at publicsuffix.org.

For "eTLD-owner requested", the only TLD with which we currently have an arrangement is .gov. However, I believe there is interest from gov.uk (an SLD), and I'm hoping the approach might help other public suffixes who want to deprecate HTTP for new domains going forward.

 

If it's just a matter of terminology, is "public suffix" or oversimplification to "TLD" a good alternative?

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.
To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvZOntrTEZ2jTrj7rryZ1zKNR57%3DGh3PSKpX88WM-e4nHA%40mail.gmail.com.

[Eric Mill]

On Fri, Oct 20, 2017 at 4:15 PM, 'Lucas Garron' via HSTS Discuss <hsts-d...@chromium.org> wrote:

On Thu, Oct 19, 2017 at 7:19 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Oct 19, 2017 at 5:31 PM, Lucas Garron <lga...@chromium.org> wrote:

Hi everyone,

As recently announced, Google has just preloaded several new TLDs in Chrome. We are also talks with other security-conscious TLD owners about preloading their TLDs. This approach is powerful because it permanently protects a whole swath of domains, rather than requiring an entry for each domain (which takes more space in the preload list, and take time to roll out for each domain). We would like all these preloaded TLDs to reach all browsers. :-)

Right now, Mozilla’s script for filtering the Chromium list removes most TLDs, because it can’t connect to TLDs to verify their HSTS headers like it can for normal domains. This means the entries are not reaching Firefox, and they are also not reaching Microsoft's operating systems and browsers (which pull from the filtered Firefox list).

In a preliminary email thread, Mozilla indicated they were open to picking up TLD entries,  but we need to figure out how. I see two options:

• Keep the format of the Chromium list, and modify Mozilla’s script not to filter out any entries that appear to be TLDs.

• Annotate the entries in Chromium and update the Mozilla script not to filter out entries with certain annotations.

I have an idea for the latter approach that also solves several other problems I’m currently facing: add a “policy” field to each entry in the Chromium source. I’ve scoped this out here, and the set of policies would look something like this: "test", "etld", "google", "custom", "bulk-legacy", "bulk-18-weeks", "bulk-1-year", "etld-requested-gov".

Could you clarify more about "etld" and "etld-requested-gov"? We've been trying to stay away from terminology re: eTLD in the various spaces, so it might be helpful to be precise. That is, is it just related to TLDs? Or is there more you expect (e.g. ccTLDs)?

Good to know! I also find eTLD a pretty awkward term. :-(

In general, it is beneficial to preload parent domains instead of individual child domains. Although we are only in talks with gTLDs right now, I would be eager to preload any public suffix that is ready – old TLDs, gTLDs, ccTLDs, or anything at publicsuffix.org.

For "eTLD-owner requested", the only TLD with which we currently have an arrangement is .gov. However, I believe there is interest from gov.uk (an SLD), and I'm hoping the approach might help other public suffixes who want to deprecate HTTP for new domains going forward.

 

If it's just a matter of terminology, is "public suffix" or oversimplification to "TLD" a good alternative?

I think you could probably drop "-gov" from the label either way. Though .gov is the first, and maybe the second will also be a government, there's nothing inherently government-specific about it. The idea here would be a class of domains for which the TLD is in a position to authorize their preloading as a policy matter, but not in a technical manner (at least not via the currently employed technical manner, via a HSTS flag).

Though I don't work on a browser, I do parse the preload list as part of enforcement/compliance efforts, and an annotation approach would be the easiest from a client perspective (and also likeliest to lead to consistent results across clients/browsers).

-- Eric

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvZOntrTEZ2jTrj7rryZ1zKNR57%3DGh3PSKpX88WM-e4nHA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAKj7jtt19Hr9O%3DkpF5JFqaVsendh_2-X6TZNDntbTqq2bzYNpA%40mail.gmail.com.

--

Eric Mill

Senior Advisor, Technology Transformation Services, GSA

eric...@gsa.gov, +1-617-314-0966

[bi...@eff.org]

As stated in the issue here and discussion here, the HTTPS Everywhere extension would benefit from annotation.

Currently, we use our CI to determine if a domain in a submitted ruleset is HSTS preloaded or not.  Since we don't want to repeat the preloaded domains within our extension, if it's already included in the preload list for all supported browsers, we fail the test.  However, if a ruleset is included in the preload list but it does not have the prerequisite headers to keep it there for very long, we pass the test.  We don't want to be removing rulesets which will potentially be useful in the future.

However, as stated above, certain domains are not going to be removed regardless of their failure to include the prerequisite headers.  It would be useful to know this for our CI, and for a clear policy to be stated on how this affects inclusion in each of the browsers.

Bill Budington

Security Engineer & Technologist

Electronic Frontier Foundation

https://www.eff.org/

[Lucas Garron]

On Fri, Oct 20, 2017 at 1:32 PM Eric Mill <eric...@gsa.gov> wrote:

On Fri, Oct 20, 2017 at 4:15 PM, 'Lucas Garron' via HSTS Discuss <hsts-d...@chromium.org> wrote:

On Thu, Oct 19, 2017 at 7:19 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Oct 19, 2017 at 5:31 PM, Lucas Garron <lga...@chromium.org> wrote:

Hi everyone,

As recently announced, Google has just preloaded several new TLDs in Chrome. We are also talks with other security-conscious TLD owners about preloading their TLDs. This approach is powerful because it permanently protects a whole swath of domains, rather than requiring an entry for each domain (which takes more space in the preload list, and take time to roll out for each domain). We would like all these preloaded TLDs to reach all browsers. :-)

Right now, Mozilla’s script for filtering the Chromium list removes most TLDs, because it can’t connect to TLDs to verify their HSTS headers like it can for normal domains. This means the entries are not reaching Firefox, and they are also not reaching Microsoft's operating systems and browsers (which pull from the filtered Firefox list).

In a preliminary email thread, Mozilla indicated they were open to picking up TLD entries,  but we need to figure out how. I see two options:

• Keep the format of the Chromium list, and modify Mozilla’s script not to filter out any entries that appear to be TLDs.

• Annotate the entries in Chromium and update the Mozilla script not to filter out entries with certain annotations.

I have an idea for the latter approach that also solves several other problems I’m currently facing: add a “policy” field to each entry in the Chromium source. I’ve scoped this out here, and the set of policies would look something like this: "test", "etld", "google", "custom", "bulk-legacy", "bulk-18-weeks", "bulk-1-year", "etld-requested-gov".

Could you clarify more about "etld" and "etld-requested-gov"? We've been trying to stay away from terminology re: eTLD in the various spaces, so it might be helpful to be precise. That is, is it just related to TLDs? Or is there more you expect (e.g. ccTLDs)?

Good to know! I also find eTLD a pretty awkward term. :-(

In general, it is beneficial to preload parent domains instead of individual child domains. Although we are only in talks with gTLDs right now, I would be eager to preload any public suffix that is ready – old TLDs, gTLDs, ccTLDs, or anything at publicsuffix.org.

For "eTLD-owner requested", the only TLD with which we currently have an arrangement is .gov. However, I believe there is interest from gov.uk (an SLD), and I'm hoping the approach might help other public suffixes who want to deprecate HTTP for new domains going forward.

 

If it's just a matter of terminology, is "public suffix" or oversimplification to "TLD" a good alternative?

I think you could probably drop "-gov" from the label either way. Though .gov is the first, and maybe the second will also be a government, there's nothing inherently government-specific about it. The idea here would be a class of domains for which the TLD is in a position to authorize their preloading as a policy matter, but not in a technical manner (at least not via the currently employed technical manner, via a HSTS flag).

Good point. I imagined we would distinguish different eTLD-owner requested TLD policies, but on reflection there is unlikely to be a functional policy difference, and you can get the eTLD from the domain itself. I've dropped the "-gov" suffix from the tentative plan. :-)

 

Though I don't work on a browser, I do parse the preload list as part of enforcement/compliance efforts, and an annotation approach would be the easiest from a client perspective (and also likeliest to lead to consistent results across clients/browsers).

-- Eric

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvZOntrTEZ2jTrj7rryZ1zKNR57%3DGh3PSKpX88WM-e4nHA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

[Ryan Sleevi]

On Fri, Oct 20, 2017 at 4:15 PM, Lucas Garron <lga...@google.com> wrote:

On Thu, Oct 19, 2017 at 7:19 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Oct 19, 2017 at 5:31 PM, Lucas Garron <lga...@chromium.org> wrote:

Hi everyone,

As recently announced, Google has just preloaded several new TLDs in Chrome. We are also talks with other security-conscious TLD owners about preloading their TLDs. This approach is powerful because it permanently protects a whole swath of domains, rather than requiring an entry for each domain (which takes more space in the preload list, and take time to roll out for each domain). We would like all these preloaded TLDs to reach all browsers. :-)

Right now, Mozilla’s script for filtering the Chromium list removes most TLDs, because it can’t connect to TLDs to verify their HSTS headers like it can for normal domains. This means the entries are not reaching Firefox, and they are also not reaching Microsoft's operating systems and browsers (which pull from the filtered Firefox list).

In a preliminary email thread, Mozilla indicated they were open to picking up TLD entries,  but we need to figure out how. I see two options:

• Keep the format of the Chromium list, and modify Mozilla’s script not to filter out any entries that appear to be TLDs.

• Annotate the entries in Chromium and update the Mozilla script not to filter out entries with certain annotations.

I have an idea for the latter approach that also solves several other problems I’m currently facing: add a “policy” field to each entry in the Chromium source. I’ve scoped this out here, and the set of policies would look something like this: "test", "etld", "google", "custom", "bulk-legacy", "bulk-18-weeks", "bulk-1-year", "etld-requested-gov".

Could you clarify more about "etld" and "etld-requested-gov"? We've been trying to stay away from terminology re: eTLD in the various spaces, so it might be helpful to be precise. That is, is it just related to TLDs? Or is there more you expect (e.g. ccTLDs)?

Good to know! I also find eTLD a pretty awkward term. :-(

In general, it is beneficial to preload parent domains instead of individual child domains. Although we are only in talks with gTLDs right now, I would be eager to preload any public suffix that is ready – old TLDs, gTLDs, ccTLDs, or anything at publicsuffix.org.

For "eTLD-owner requested", the only TLD with which we currently have an arrangement is .gov. However, I believe there is interest from gov.uk (an SLD), and I'm hoping the approach might help other public suffixes who want to deprecate HTTP for new domains going forward.

 

If it's just a matter of terminology, is "public suffix" or oversimplification to "TLD" a good alternative?

Oh, I see. I was assuming, apparently incorrectly, that entries on the public suffix list would be excluded. That is, I think it's reasonable to preload gTLDs (under the new ICANN contracting structure), and potentially ccTLDs (due to the existing [lack of] restrictions), but would be uncomfortable with preloading legacy TLDs or arbitrary public suffices as a special case. 

[Gabriel Montenegro]

Hi folks,

 

At this moment we can’t consume “eTLD”s, unfortunately. I have not had a chance to discuss in detail with the developers in charge. I think the “policy” field makes sense going forward, although, of course, we can’t consume it at this point.

 

Gabriel

[Daniel Veditz]

On Sun, Oct 22, 2017 at 4:31 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

Oh, I see. I was assuming, apparently incorrectly, that entries on the public suffix list would be excluded. That is, I think it's reasonable to preload gTLDs (under the new ICANN contracting structure), and potentially ccTLDs (due to the existing [lack of] restrictions), but would be uncomfortable with preloading legacy TLDs or arbitrary public suffices as a special case. 

​I agree. I've got no problem preloading gTLDs (assuming the registrar explicitly acknowledges the unhappiness this could cause existing customers)​ and get more uncomfortable when we start talking about legacy TLDs. Entries on the public suffix list could already serve HSTS headers so I'm less concerned about adding them to the preload list if they request it.

-

​Dan Veditz​

[Eric Mill]

I don't think anyone's been suggesting preloading legacy TLDs in a blunt way. Right now, entries that in some way relate to TLDs fall into two buckets:

1. New TLDs that opt in to being preloaded. These don't get processed downstream by Mozilla or Microsoft right now.

2. SLDs that legacy TLDs request be preloaded by fiat (regardless of any ability for a client to see an HSTS header for them). These may get processed by some clients, but Mozilla would drop those that don't advertise an HSTS header (and IIRC Microsoft is downstream from Mozilla).

Right now, #1 is used by a handful of recent TLDs, including .google and .dev. 

Right now, #2 is just .gov, whose policy as a managed TLD is to routinely preload a category of newly registered domains as they are registered[1], but there's nothing specific to .gov (or government) about this process.

In late 2016, at the gathering Lucas referenced, I proposed that browsers consider possible mechanisms to give legacy TLDs (and public suffixes) a viable pathway towards preloading themselves -- if not entirely, at least asymptotically. 

One mechanism would be for browsers to support carveouts (i.e. preload this zone *except* for these specific names within it). This has been requested before by SLD owners for carveouts for particular subdomains, and reasonably rejected as not worthwhile at that level. However, carveouts for TLDs that except specific SLDs might have a better cost-benefit ratio, if it allows small- or medium-sized TLDs and public suffixes to set rules like "preload *.gov except for these X,000 legacy hostnames". This creates a fully known and contained HTTP surface area, and allows the TLD to focus on deleting those whitelist entries over time, while all future hostnames within its zone are automatically covered.

But regardless of whether a carveout mechanism for TLDs ever happens, the policy attributes that Lucas is suggesting don't speak to any imminent plan to preload legacy TLDs that I'm aware of. I would expect that any legacy TLD, small or large, would want to examine more graceful pathways that don't risk breaking swathes of things, while still finding ways to lift its security level.

-- Eric

[1] https://cio.gov/automatic-https-enforcement-new-executive-branch-gov-domains/

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CADYDTCBDJSVOfTw3e%3Dd4_vPFasUDNQ%3DA6F0xKN1ks4J1P1MWBA%40mail.gmail.com.

[Ryan Sleevi]

To be clear: My concern is specifically with public suffices, which do not have the same administrative boundaries of control as legacy TLDs such as .gov, ccTLDs such as .uk, or gTLDs such as .google.

gTLDs' policies on registration are addressed during the ICANN application process as to whether they will allow open registration, limited registration subject to policies, or sole registration

ccTLDs are allocated based on the country code recognition and neither ICANN or IANA apply specific policies with respect to registration

Legacy TLDs are handled on a case-by-case basis - that is, .com, .gov, .org, and .aero each had their own policies with respect to registration, handled by ICANN

gTLDs and ccTLDs rarely change in "surprising" ways - that is, gTLDs go through enough process that, in general, change constitutes removal, rather than a transfer of ownership and a change in policies (the process is designed to prevent more restrictive policies from being negotiated once delegated). ccTLDs can change based on administrative whim, but a set of policies as significant as HSTS are not ones to get into lightly.

Legacy TLDs are more or less inflexible - change is measured glacially, given their broad use.

However, those sorts of SLDs and eTLDs undergo incredible change - and the bounding of the policy expression is only as long as the domain registration, and these registrations are, fairly frequently (unfortunately), short lived (O(1-3 years)) and will change as companies rise and fall.

For that reason, and the administrative burden in determining who are the acceptable entities to appropriately request such policy imposition, I think allowing such registrations is probably more detrimental than positive.

These are just the experiences of (one) PSL maintainer who gets increasingly concerned with new consumers of the PSL, due to its many (unsolved) problems.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAC7uhV-vqA4Sfb1RVb-uYMAoWRAmB400A%2Bb1AQCX5UzfahLfmA%40mail.gmail.com.

[Lucas Garron]

I don't believe I've heard back from Mozilla on this thread yet, but it looks like this change will be sufficiently useful for other purposes, and also work with Mozilla's script if they are willing to take TLD entries. Martijn C. has sent a CL for adding annotations in the Chromium source, and I will plan to land it.

I'll keep in mind the concerns about preloading public suffixes that aren't as likely to have long-term stewards who are comfortable with the security tradeoff.

Public suffixes can't be preloaded through hstspreload.org and I don't really get emails requesting to preload any non-gTLD public suffixes (although some preloaded domains were added to the public suffix list afterwards?), so I'll worry about that when we get there.

»Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CADYDTCBDJSVOfTw3e%3Dd4_vPFasUDNQ%3DA6F0xKN1ks4J1P1MWBA%40mail.gmail.com.

--

Eric Mill

Senior Advisor, Technology Transformation Services, GSA

eric...@gsa.gov, +1-617-314-0966

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAC7uhV-vqA4Sfb1RVb-uYMAoWRAmB400A%2Bb1AQCX5UzfahLfmA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvaAYRm33soYcb0YXOZw9qpJfgNzna8kmSnh44Z3a-u60w%40mail.gmail.com.

[J.C. Jones]

Lucas,

Sorry for the delay. This policy approach in Issue #111 works for Mozilla. We'll be standing by to update our scripts when the new format is settled.

Cheers,

J.C.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CADYDTCBDJSVOfTw3e%3Dd4_vPFasUDNQ%3DA6F0xKN1ks4J1P1MWBA%40mail.gmail.com.

--

Eric Mill

Senior Advisor, Technology Transformation Services, GSA

eric...@gsa.gov, +1-617-314-0966

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAC7uhV-vqA4Sfb1RVb-uYMAoWRAmB400A%2Bb1AQCX5UzfahLfmA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvaAYRm33soYcb0YXOZw9qpJfgNzna8kmSnh44Z3a-u60w%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAKj7jtsEHAZcPcQ4DR8YCZx55OK5iVo-yRa2ZB0RZzG3Rz4D9Q%40mail.gmail.com.

[Lucas Garron]

Hello J.C.,

Excellent, it all just landed! 😊

I've filed Bugzilla bug 1418112 to track this.

Thanks,

»Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CADYDTCBDJSVOfTw3e%3Dd4_vPFasUDNQ%3DA6F0xKN1ks4J1P1MWBA%40mail.gmail.com.

--

Eric Mill

Senior Advisor, Technology Transformation Services, GSA

eric...@gsa.gov, +1-617-314-0966

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAC7uhV-vqA4Sfb1RVb-uYMAoWRAmB400A%2Bb1AQCX5UzfahLfmA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvaAYRm33soYcb0YXOZw9qpJfgNzna8kmSnh44Z3a-u60w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss...@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

[Eric Lawrence]

Support for HSTS preloading of TLDs has landed for Microsoft Edge and Internet Explorer, slated to reach stable with the Windows 10 Fall Update coming later this year. The improvement should be visible in the Windows Insider fast ring builds shortly.

-Eric Lawrence

Microsoft Edge Networking

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CADYDTCBDJSVOfTw3e%3Dd4_vPFasUDNQ%3DA6F0xKN1ks4J1P1MWBA%40mail.gmail.com.

--

Eric Mill

Senior Advisor, Technology Transformation Services, GSA

eric...@gsa.gov, +1-617-314-0966

--

You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CAC7uhV-vqA4Sfb1RVb-uYMAoWRAmB400A%2Bb1AQCX5UzfahLfmA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/hsts-discuss/CACvaWvaAYRm33soYcb0YXOZw9qpJfgNzna8kmSnh44Z3a-u60w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "HSTS Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hsts-discuss+unsubscribe@chromium.org.

To post to this group, send email to hsts-d...@chromium.org.