5 ms·

If it’s not clear from the article, HTTPS is required for all .app domains, which Google accomplished by adding the .app TLD to the default chrome HSTS preload

If it’s not clear from the article, HTTPS is required for all .app domains, which Google accomplished by adding the .app TLD to the default chrome HSTS preload list. Interestingly that will only ensure HTTPS only when using a browser with HSTS enabled with a preload list that includes the .app TLD. Therefore non-web code, or code in browsers without the TLD in the HSTS preload list, will be able to make HTTP requests to a .app domain. It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. Also, and this is just a feeling, it seems obtrusive for google to force such a policy across the TLD. Of course it’s their right since they own the TLD, but the cynic in me can’t help but think it sets an overbearing precedent. Based on Google’s behavior in the past, this looks like the second step of the “embrace/extend/extinguish” cycle Google has used so effectively in the past.

hyder_m29 9y ago
I think that if .app becomes widely popular, it would set a precedent to force HTTPS across the web. That's really the only positive I see here. Other than, it just feels like a marketing gimmick to sell domains.
snarfy 9y ago
How does that work in say, Firefox?
- CydeWeys 9y ago
  The HSTS preload list is built into Firefox too (like all major browsers), and automatically rewrites any affected http URLs to https before issuing any requests over the network.
- detaro 9y ago
  Exactly the same, the preload list data is public and used by all the major browsers.
  - chatmasta 9y ago
    What is the "single source of truth" for the HSTS preload list? It must be on a server somewhere... who runs the server? Which browsers use this list by default?
    - CydeWeys 9y ago
      See https://hstspreload.org/ https://hstspreload.org/. And all major browsers. Chrome, Firefox, Safari, Opera, IE, and Edge for starters.
      - chatmasta 9y ago
        Thanks for that. But that site doesn’t seem to mention the loading process across browsers. Generally speaking , do the major browsers ship the HSTS list compiled into the build? Or do they update it at runtime? If so, from where do they fetch the updated list, and how often?
        CydeWeys 9y ago
        Yes, the major browsers ship the HSTS preload list compiled directly into the build. That's why it can take months for a domain to, once submitted, actually be preloaded across a majority of users -- because the browser nightly/beta/release build cycle alone is 2-3 months, plus the time that it takes the average user to update their browser. Incidentally, this is one of the major advantages of HSTS preloading at the TLD level, namely, that all .app domains are already preloaded and have been since 2017.
Klathmon 9y ago
> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement. .app will be HTTPS only from the start and for the foreseeable future, so (at least in my opinion) there's no need to care about HTTP, or even open port 80 at all. Granted you could do this before with HSTS preload, but setting that up yourself requires fiddling with headers and waiting a bit while browsers update with the new list. With ".app" it happens automatically, so it lowers the barrier, making it easier for strong encryption to be used by everyone for anything and everything. This makes HTTPS easier than HTTP, which doesn't look like much on paper, but is (again, in my opinion) one of the best ways to increase security overall.
- jetpks 9y ago
  > if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. Except the part where the `.app` domain is only "https-only" in Chrome.
  - Klathmon 9y ago
    It's not just Chrome. Chrome maintains the list that most browsers use, but it's not the only browser using the list. Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's. You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly. As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo). [0] https://github.com/mozilla/gecko-dev/blob/master/security/manager/ssl/nsSTSPreloadList.inc https://github.com/mozilla/gecko-dev/blob/master/security/ma...
  - fastball 9y ago
coolspot 9y ago
"embrace/extend/extinguish" is Microsoft's invention [1]. What are examples of Google's use of EEE? [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Examples https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
- ocdtrekkie 9y ago
  It was Microsoft's strategy roughly twenty years ago. It's Google's strategy today.
  - andybak 9y ago
    Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.
    - ocdtrekkie 9y ago
      Google Reader would be the often mentioned first example: Google entered the RSS reader market, became the best, added a bunch of features and really became "the" de facto place to read feeds. ...Then closed up shop and killed much of the ecosystem outright, directing people towards proprietary places to get their news like social networks or Google News. Hangouts did very much the same with XMPP, a move which a Googler once suggested to me was viewed internally as a betrayal of the company's values. I think we may be approaching EEE territory with email: Gmail's already centralized a large portion of the email industry, to the point that Google has about two-thirds of all emails on one side or the other, and now they're moving into introducing a proprietary email format (AMP 4 Email), which isn't being developed in a standards-focused way. I'm sure the same argument could be made for their push into RCS over texting, browsers (now pushing Chrome-only websites and features in a lot of places), Android (embracing third party OEMs before moving into locking down much of newer Android functionality and launching a first party iPhone competitor), etc. If there was a movie quote that best exemplified Google's business strategy, it would be "I have altered the deal. Pray I do not alter it any further."

hyder_m29 9y ago

I think that if .app becomes widely popular, it would set a precedent to force HTTPS across the web. That's really the only positive I see here. Other than, it just feels like a marketing gimmick to sell domains.

snarfy 9y ago

How does that work in say, Firefox?

CydeWeys 9y ago
The HSTS preload list is built into Firefox too (like all major browsers), and automatically rewrites any affected http URLs to https before issuing any requests over the network.
detaro 9y ago
Exactly the same, the preload list data is public and used by all the major browsers.
- chatmasta 9y ago
  What is the "single source of truth" for the HSTS preload list? It must be on a server somewhere... who runs the server? Which browsers use this list by default?
  - CydeWeys 9y ago
    See https://hstspreload.org/ https://hstspreload.org/. And all major browsers. Chrome, Firefox, Safari, Opera, IE, and Edge for starters.
    - chatmasta 9y ago
      Thanks for that. But that site doesn’t seem to mention the loading process across browsers. Generally speaking , do the major browsers ship the HSTS list compiled into the build? Or do they update it at runtime? If so, from where do they fetch the updated list, and how often?
      - CydeWeys 9y ago
        Yes, the major browsers ship the HSTS preload list compiled directly into the build. That's why it can take months for a domain to, once submitted, actually be preloaded across a majority of users -- because the browser nightly/beta/release build cycle alone is 2-3 months, plus the time that it takes the average user to update their browser. Incidentally, this is one of the major advantages of HSTS preloading at the TLD level, namely, that all .app domains are already preloaded and have been since 2017.

Klathmon 9y ago

> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement. .app will be HTTPS only from the start and for the foreseeable future, so (at least in my opinion) there's no need to care about HTTP, or even open port 80 at all. Granted you could do this before with HSTS preload, but setting that up yourself requires fiddling with headers and waiting a bit while browsers update with the new list. With ".app" it happens automatically, so it lowers the barrier, making it easier for strong encryption to be used by everyone for anything and everything. This makes HTTPS easier than HTTP, which doesn't look like much on paper, but is (again, in my opinion) one of the best ways to increase security overall.

jetpks 9y ago
> if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. Except the part where the `.app` domain is only "https-only" in Chrome.
- Klathmon 9y ago
  It's not just Chrome. Chrome maintains the list that most browsers use, but it's not the only browser using the list. Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's. You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly. As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo). [0] https://github.com/mozilla/gecko-dev/blob/master/security/manager/ssl/nsSTSPreloadList.inc https://github.com/mozilla/gecko-dev/blob/master/security/ma...
- fastball 9y ago

coolspot 9y ago

"embrace/extend/extinguish" is Microsoft's invention [1]. What are examples of Google's use of EEE? [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Examples https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

ocdtrekkie 9y ago
It was Microsoft's strategy roughly twenty years ago. It's Google's strategy today.
- andybak 9y ago
  Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.
  - ocdtrekkie 9y ago
    Google Reader would be the often mentioned first example: Google entered the RSS reader market, became the best, added a bunch of features and really became "the" de facto place to read feeds. ...Then closed up shop and killed much of the ecosystem outright, directing people towards proprietary places to get their news like social networks or Google News. Hangouts did very much the same with XMPP, a move which a Googler once suggested to me was viewed internally as a betrayal of the company's values. I think we may be approaching EEE territory with email: Gmail's already centralized a large portion of the email industry, to the point that Google has about two-thirds of all emails on one side or the other, and now they're moving into introducing a proprietary email format (AMP 4 Email), which isn't being developed in a standards-focused way. I'm sure the same argument could be made for their push into RCS over texting, browsers (now pushing Chrome-only websites and features in a lot of places), Android (embracing third party OEMs before moving into locking down much of newer Android functionality and launching a first party iPhone competitor), etc. If there was a movie quote that best exemplified Google's business strategy, it would be "I have altered the deal. Pray I do not alter it any further."