7 ms·

> The big difference is that HTTPS is required to connect to all .app websites...Because .app will be the first TLD with enforced security made available for ge

> The big difference is that HTTPS is required to connect to all .app websites...Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way. This sounds good but how does it really help users or developers compared to having a .com website that uses HTTPS? Expecting that users will think "oh, .app, must be secure" doesn't seem like an improvement over expecting them to look for key icons in the browser, or showing them scary alerts for non-https sites. The only play I see here is that if the new TLD becomes so popular that everyone must have one, then, well, everyone must have HTTPS. But that's not going to happen either. Even .com never reached a high enough level of importance that absolutely every website, including those who weren't interested in providing HTTPS, needed to use .com for their domain.

CydeWeys 9y ago
Tech lead of Google Registry here. I can help answer some questions. HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... Preloading the entire TLD rather than individual domains has a number of benefits, including the fact that (a) it's effective now rather than several months from now for a newly created domain, (b) you don't individually have to configure anything, and (c) it keeps the size of the list down (which is important since the list is built into web browsers). And in addition to all that, you're right, it is a play to move more sites to HTTPS, which is better for the safety and security of the web overall. Chrome is soon going to display "Insecure" for every single http site, which is another nudge to help move the web towards a secure future.
- spronkey 9y ago
  As nice as an HSTS preload list is, using .app and .dev for this is infuriating. Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions. Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
  - Whitestrake 9y ago
    I've been told by a few people that it's my own fault, that I should have used something else like .test, etc. I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution. Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
- toomuchtodo 9y ago
  What are your thoughts on HSTS for a TLD when a CA can then revoke a site’s cert, preventing access entirely (See: Comodo and Sci-Hub).
  - CydeWeys 9y ago
    You can always get a new SSL certificate from someone else quite easily (e.g. Let's Encrypt). So that's a temporary problem at worst.
    - toomuchtodo 9y ago
      As long as the CA is in a jurisdiction that can require revoking access, it becomes an attack vector if HSTS is enabled and you’re at the mercy of preloaded root CAs.
      - CydeWeys 9y ago
        There are much worse attack vectors if the entire connection is unencrypted, though.
      - Buge 9y ago
        There are many preloaded root CAs. Are you saying you're worried that every single one of them will simultaneously be required to revoke your certificates?
    - michaelt 9y ago
      Finally, "there are several dozen CAs and some are really sketchy" becomes a strength, rather than a weakness!
      - CydeWeys 9y ago
        Sketchy CAs that issue certificates to people that don't actually own the domains in question tend to get nuked from the chain of trust very quickly.
- carreau 9y ago
  Trying to register via google domain says "Google Domains does not support the .APP ending". Is that on purpose (Google domain is listed on get.app as compatible) ? A cache issue ?
  - CydeWeys 9y ago
    I can't speak specifically for Google Domains as that's a completely different team that we have limited interactions with. What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.
    - dcosson 9y ago
      Wait, so you put out this launch announcement telling people they can early register .app domains. It links to a bunch of partners including Google Domains, but you have no idea whether I can actually register a domain there or not? Why promise it in your launch announcement then?
      - CydeWeys 9y ago
        Choice of domain registrar is up to the end user. We cannot recommend any one over the other. There are plenty that are offering the full range of registrations/preorders (including EAP), and you need to pick your own. The full list of registrars onboarded for .app, including annotations for those supporting EAP, is here: https://www.registry.google/about/register.html https://www.registry.google/about/register.html
      - bigiain 9y ago
        They put this announcement out so they can sell spots on the "Priority Pre Registration" list for $16,000. It's just another fucking cash grab.
        nl 9y ago
        For end users it costs ~$20, right now from one of the EAP registrars. Outrage is great, but it's a good idea to read before firing off like this.
- vthallam 9y ago
  I know TLD's doesn't affect SEO, but does Google enhance .app domain SEO when people search for apps on Google search?
  - hk__2 9y ago
    > I know TLD's doesn't affect SEO So you have your answer.
- chrisfinazzo 9y ago
  I'm not saying I agree with his stance, but I think it's important to mention Dave Winer's concerns re how the ongoing transition to HTTPS will affect older sites. Many of these played an important role in the web's rise to prominence, but could lose out if HTTPS becomes the baseline for trustworthy content. Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been any discussion within the Registry or Search teams about how to address these kinds of situations?
  - brlewis 9y ago
    I have some really old sites myself running on Jetty 5. I recently put them behind nginx and set up letsencrypt. It wasn't terribly difficult.
  - cbr 9y ago
    Can you give an example of a site that couldn't be moved to HTTPS? I would expect that even if the serving stack doesn't support HTTPS you could put a proxy in front of it.
    - chrisfinazzo 9y ago
      Winer's argument seems to be that he owns a number of sites that don't need the explicit security that HTTPS provides (a blog archive, for example), but that shouldn't affect how Google and the rest of the web view whether or not the content is trustworthy. Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS. As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases. You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with. The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.
- needToSay 9y ago
  Go fuck yourself scumbag you work for nazis. Shame on you!!!
- Ayesh 9y ago
  IIRC, .app isn't the first TLD to be included in HSTS preload list. I hope the registrars will make it clear to customers that .app itself is in the HSTS preload list to prevent any confusion.

CydeWeys 9y ago

Tech lead of Google Registry here. I can help answer some questions. HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... Preloading the entire TLD rather than individual domains has a number of benefits, including the fact that (a) it's effective now rather than several months from now for a newly created domain, (b) you don't individually have to configure anything, and (c) it keeps the size of the list down (which is important since the list is built into web browsers). And in addition to all that, you're right, it is a play to move more sites to HTTPS, which is better for the safety and security of the web overall. Chrome is soon going to display "Insecure" for every single http site, which is another nudge to help move the web towards a secure future.

spronkey 9y ago
As nice as an HSTS preload list is, using .app and .dev for this is infuriating. Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions. Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
- Whitestrake 9y ago
  I've been told by a few people that it's my own fault, that I should have used something else like .test, etc. I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution. Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
toomuchtodo 9y ago
What are your thoughts on HSTS for a TLD when a CA can then revoke a site’s cert, preventing access entirely (See: Comodo and Sci-Hub).
- CydeWeys 9y ago
  You can always get a new SSL certificate from someone else quite easily (e.g. Let's Encrypt). So that's a temporary problem at worst.
  - toomuchtodo 9y ago
    As long as the CA is in a jurisdiction that can require revoking access, it becomes an attack vector if HSTS is enabled and you’re at the mercy of preloaded root CAs.
    - CydeWeys 9y ago
      There are much worse attack vectors if the entire connection is unencrypted, though.
    - Buge 9y ago
      There are many preloaded root CAs. Are you saying you're worried that every single one of them will simultaneously be required to revoke your certificates?
  - michaelt 9y ago
    Finally, "there are several dozen CAs and some are really sketchy" becomes a strength, rather than a weakness!
    - CydeWeys 9y ago
      Sketchy CAs that issue certificates to people that don't actually own the domains in question tend to get nuked from the chain of trust very quickly.
carreau 9y ago
Trying to register via google domain says "Google Domains does not support the .APP ending". Is that on purpose (Google domain is listed on get.app as compatible) ? A cache issue ?
- CydeWeys 9y ago
  I can't speak specifically for Google Domains as that's a completely different team that we have limited interactions with. What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.
  - dcosson 9y ago
    Wait, so you put out this launch announcement telling people they can early register .app domains. It links to a bunch of partners including Google Domains, but you have no idea whether I can actually register a domain there or not? Why promise it in your launch announcement then?
    - CydeWeys 9y ago
      Choice of domain registrar is up to the end user. We cannot recommend any one over the other. There are plenty that are offering the full range of registrations/preorders (including EAP), and you need to pick your own. The full list of registrars onboarded for .app, including annotations for those supporting EAP, is here: https://www.registry.google/about/register.html https://www.registry.google/about/register.html
    - bigiain 9y ago
      They put this announcement out so they can sell spots on the "Priority Pre Registration" list for $16,000. It's just another fucking cash grab.
      - nl 9y ago
        For end users it costs ~$20, right now from one of the EAP registrars. Outrage is great, but it's a good idea to read before firing off like this.
vthallam 9y ago
I know TLD's doesn't affect SEO, but does Google enhance .app domain SEO when people search for apps on Google search?
- hk__2 9y ago
  > I know TLD's doesn't affect SEO So you have your answer.
chrisfinazzo 9y ago
I'm not saying I agree with his stance, but I think it's important to mention Dave Winer's concerns re how the ongoing transition to HTTPS will affect older sites. Many of these played an important role in the web's rise to prominence, but could lose out if HTTPS becomes the baseline for trustworthy content. Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been any discussion within the Registry or Search teams about how to address these kinds of situations?
- brlewis 9y ago
  I have some really old sites myself running on Jetty 5. I recently put them behind nginx and set up letsencrypt. It wasn't terribly difficult.
- cbr 9y ago
  Can you give an example of a site that couldn't be moved to HTTPS? I would expect that even if the serving stack doesn't support HTTPS you could put a proxy in front of it.
  - chrisfinazzo 9y ago
    Winer's argument seems to be that he owns a number of sites that don't need the explicit security that HTTPS provides (a blog archive, for example), but that shouldn't affect how Google and the rest of the web view whether or not the content is trustworthy. Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS. As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases. You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with. The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.
needToSay 9y ago
Go fuck yourself scumbag you work for nazis. Shame on you!!!
Ayesh 9y ago
IIRC, .app isn't the first TLD to be included in HSTS preload list. I hope the registrars will make it clear to customers that .app itself is in the HSTS preload list to prevent any confusion.