5 ms·

I bet you can't answer the actual most likely question: What are you (Google) planning on doing with .dev domains anyway? However besides that...just curious:

I bet you can't answer the actual most likely question: What are you (Google) planning on doing with .dev domains anyway? However besides that...just curious: Will Chrome honor a header to disable HSTS for preloaded domains? (e.g. Strict-Transport-Security: max-age=0)? And what is going to happen if I submit my .dev site for removal from https://hstspreload.org/ https://hstspreload.org/ ? Also, reading the rules on hstspreload.org, I see the following statement: "Don't request inclusion unless you're sure that you can support HTTPS for your entire site and all its subdomains the long term" Since you cannot actually guarantee that every .dev site will support HTTPS considering the fact that many developers use it on their LAN...don't you think you're breaking the rules here and possibly causing more problems than solutions?

CydeWeys 9y ago
I would love to be able to answer that first question for you. Unfortunately I have nothing to share yet. My understanding is that HSTS carveouts are supported by Chrome but not yet other browsers. There's more standardization work to be done there. That said, you can only request entries on the HSTS list for domains that you own, and since no one (yet?) owns any .dev domain names, no one could request such changes. It goes without saying why you can only change security settings for domain names that you own. And for the last question: Again, there are no .dev domain names. There never have been. It's never been available for registration. The recommendation for a long time has been to only use either (a) domain names that you actually own, or (b) domain names that are reserved for testing and are guaranteed never to exist a la RFC 2606. Using domain names for testing that don't yet exist but could in the future is a huge security hole that you must fix now. Do it now while the domain names still fail to resolve. Once they resolve, and you don't own them, then your security situation gets a lot worse.
- xg15 9y ago
  > And for the last question: Again, there are no .dev domain names. There never have been. It's never been available for registration. It is, however, in widespread practical use. > The recommendation for a long time has been to only use either (a) domain names that you actually own, or (b) domain names that are reserved for testing and are guaranteed never to exist a la RFC 2606 If taken to its extreme, that recommendation would mean that any kind of internal hostnames - even dotless ones - are subject to potential override unless they are tied to a public DNS entry.
  - detaro 9y ago
    Yes. That's why it's recommended to have a subdomain of a domain you own under which all internal names live. (no need for it/them being in public DNS though)
  - JdeBP 9y ago
    As indeed they actually are. WWW browsers have a search path, that is added on to a second search path mechanism that DNS client libraries have. Domain names with dots in, but that are not fully qualified, suffer from this. Yes, this means that what http://wibble/ http://wibble/ is right now is subject to change; and even http://wibble.wobble/ http://wibble.wobble/ could be, depending from various factors. * http://jdebp.eu./FGA/web-fully-qualified-domain-name.html http://jdebp.eu./FGA/web-fully-qualified-domain-name.html Would that I had recorded the case some while back where, when I pointed this out, someone chimed in to note that xe had worked for a company that had actually taken advantage of this in order to usurp external WWW sites. And then there was WPAD. * http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.html#WPAD http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.ht... This is not taking things to an extreme. This is reality right now and has been for many years.
    - xg15 9y ago
      I wasn't aware of that. Thanks for the info!
- Can_Not 9y ago
  > Using domain names for testing that don't yet exist but could in the future is a huge security hole that you must fix now. I disagree that this is something that Google needs to do on my behalf. If a cybersquatter squats on <my-startup>.dev, I don't consider it broken if I can't access their squat page. If I'm overriding random domains without doing my due diligence, then I get what I deserve (and probably wanted the results anyways). If somebody is spoofing a domain as a method of cyber attacking, the domain owner should have had HSTS if they had dignificant digital assets and they would already be using a non .dev domain.
  - CydeWeys 9y ago
    "If I'm overriding random domains without doing my due diligence, then I get what I deserve." I mean, that is exactly what is happening here, so it sounds like you get it. We aren't doing things on other people's behalf; HSTS is part of our plans.
Wilya 9y ago
An interesting consequence of your last question, is that if Google added .dev and .foo to the HSTS preload list, it means they don't intend to make these domains available for public registration at all. If they did let people register them, they would have no way to enforce that the sites on there honored the hsts requirements.
- CydeWeys 9y ago
  That doesn't follow. Sites that did not abide by those requirements simply would not work. The requirements are enforced by the browser. The intention when registering such a domain name would be to follow said requirements, otherwise you wouldn't be able to use the domain name for hosting websites (though you could of course still use it for other services).
  - dullgiulio 9y ago
    Not to defend plaintext HTTP, but what you describe is a DNS registrar that mandates which services can be used with the registered domain... Would you buy a house where you cannot cook, only microwave?
    - wongarsu 9y ago
      There are already TLDs that restrict who can buy them or what kind of website you can run on them. How is mandating HTTPS categorically different?
    - CydeWeys 9y ago
      The house analogy doesn't really work as you could always install a stove. A better example would be "Why would you buy a plot of land that is zoned residential if you can't build an office building on it?" The answer is that you know what you're getting into before you buy it, and so you'd only buy it if you were building a house. If the restrictions are known up front then it's all good. I'd also like to point out that HSTS has very real security benefits, and if the entire TLD is already on the list then you don't have to go through the hassle of adding all your domains individually and waiting months for those updates to roll out widely. The expectation is that the pros vastly outweigh the cons.

CydeWeys 9y ago

I would love to be able to answer that first question for you. Unfortunately I have nothing to share yet. My understanding is that HSTS carveouts are supported by Chrome but not yet other browsers. There's more standardization work to be done there. That said, you can only request entries on the HSTS list for domains that you own, and since no one (yet?) owns any .dev domain names, no one could request such changes. It goes without saying why you can only change security settings for domain names that you own. And for the last question: Again, there are no .dev domain names. There never have been. It's never been available for registration. The recommendation for a long time has been to only use either (a) domain names that you actually own, or (b) domain names that are reserved for testing and are guaranteed never to exist a la RFC 2606. Using domain names for testing that don't yet exist but could in the future is a huge security hole that you must fix now. Do it now while the domain names still fail to resolve. Once they resolve, and you don't own them, then your security situation gets a lot worse.

xg15 9y ago
> And for the last question: Again, there are no .dev domain names. There never have been. It's never been available for registration. It is, however, in widespread practical use. > The recommendation for a long time has been to only use either (a) domain names that you actually own, or (b) domain names that are reserved for testing and are guaranteed never to exist a la RFC 2606 If taken to its extreme, that recommendation would mean that any kind of internal hostnames - even dotless ones - are subject to potential override unless they are tied to a public DNS entry.
- detaro 9y ago
  Yes. That's why it's recommended to have a subdomain of a domain you own under which all internal names live. (no need for it/them being in public DNS though)
- JdeBP 9y ago
  As indeed they actually are. WWW browsers have a search path, that is added on to a second search path mechanism that DNS client libraries have. Domain names with dots in, but that are not fully qualified, suffer from this. Yes, this means that what http://wibble/ http://wibble/ is right now is subject to change; and even http://wibble.wobble/ http://wibble.wobble/ could be, depending from various factors. * http://jdebp.eu./FGA/web-fully-qualified-domain-name.html http://jdebp.eu./FGA/web-fully-qualified-domain-name.html Would that I had recorded the case some while back where, when I pointed this out, someone chimed in to note that xe had worked for a company that had actually taken advantage of this in order to usurp external WWW sites. And then there was WPAD. * http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.html#WPAD http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.ht... This is not taking things to an extreme. This is reality right now and has been for many years.
  - xg15 9y ago
    I wasn't aware of that. Thanks for the info!
Can_Not 9y ago
> Using domain names for testing that don't yet exist but could in the future is a huge security hole that you must fix now. I disagree that this is something that Google needs to do on my behalf. If a cybersquatter squats on <my-startup>.dev, I don't consider it broken if I can't access their squat page. If I'm overriding random domains without doing my due diligence, then I get what I deserve (and probably wanted the results anyways). If somebody is spoofing a domain as a method of cyber attacking, the domain owner should have had HSTS if they had dignificant digital assets and they would already be using a non .dev domain.
- CydeWeys 9y ago
  "If I'm overriding random domains without doing my due diligence, then I get what I deserve." I mean, that is exactly what is happening here, so it sounds like you get it. We aren't doing things on other people's behalf; HSTS is part of our plans.

Wilya 9y ago

An interesting consequence of your last question, is that if Google added .dev and .foo to the HSTS preload list, it means they don't intend to make these domains available for public registration at all. If they did let people register them, they would have no way to enforce that the sites on there honored the hsts requirements.

CydeWeys 9y ago
That doesn't follow. Sites that did not abide by those requirements simply would not work. The requirements are enforced by the browser. The intention when registering such a domain name would be to follow said requirements, otherwise you wouldn't be able to use the domain name for hosting websites (though you could of course still use it for other services).
- dullgiulio 9y ago
  Not to defend plaintext HTTP, but what you describe is a DNS registrar that mandates which services can be used with the registered domain... Would you buy a house where you cannot cook, only microwave?
  - wongarsu 9y ago
    There are already TLDs that restrict who can buy them or what kind of website you can run on them. How is mandating HTTPS categorically different?
  - CydeWeys 9y ago
    The house analogy doesn't really work as you could always install a stove. A better example would be "Why would you buy a plot of land that is zoned residential if you can't build an office building on it?" The answer is that you know what you're getting into before you buy it, and so you'd only buy it if you were building a house. If the restrictions are known up front then it's all good. I'd also like to point out that HSTS has very real security benefits, and if the entire TLD is already on the list then you don't have to go through the hassle of adding all your domains individually and waiting months for those updates to roll out widely. The expectation is that the pros vastly outweigh the cons.