Comment by chatmasta | Hacker News Reader

Comment by chatmasta | Hacker News Reader

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.

> 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.

> 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.

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/ma...

This is more about expectations though. The idea is that you shouldn't make a request over HTTP to a .app website and expect it to succeed.

"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_extinguis...

It was Microsoft's strategy roughly twenty years ago. It's Google's strategy today.

Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.

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."

Google Reader does not fit the pattern of EEE; if anything, it shows their failure to pursue it. EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system. What they actually did was lose a bunch of people for alternative readers, for Twitter and for Facebook.

AMP for email does seem a good example.

RCS is not developed by or supported exclusively by Google. They weren't even the first; Vodafone had it on their phones for years. Google is late to the party.

--

My opinion is not that Google is ethically above doing EEE; it's that they're often too disorganized and erratic to actually pull it off even if they wanted to.

> EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system

Like Google+?

Reader didn't transform into Google+. Google+ was a Facebook clone.

No. The intent might have been to move Reader users to G+, but they did not perform an EEE to accomplish it.

Google Reader is pretty much the opposite of EEE. They built and publicised the market and then walked away.

Just having the best app isn't EEE.

I was thinking primarily of Google AMP when I wrote that. Google's strategy is not necessarily the same as Microsoft's was; often it's a bit more subtle, but the common theme is that Google pushes standards that are primarily beneficial to itself, but often paints them disingenuously as "helping the web" or some equally meaningless BS.

Some examples which might not qualify specifically as EEE, but certainly qualify as Google pushing for biased standards:

- Google AMP (not clearly EEE, but definitely anti-open web)

- Google Chrome (not quite EEE, but barrier to entry in browser market is now extremely high)

Some more clearly EEE examples:

- GChat (clear EEE strategy on XMPP)

- Google flights (EEE the travel industry)

- Google shopping (EEE affiliate offers)

- ....

Note that these examples are not solely "competing with an existing business" as you described, because the initial announcement of them was usually welcoming and open, e.g. opening with federated xmpp compatibility, promoting it, and then extinguishing it later. If developers back then had known google would shut down xmpp, maybe they would have put effort into building a better federated xmpp ecosystem instead of wasting time interoperating with google's system. That kind of bait and switch is the hallmark of an EEE strategy.

Barrier to enter browser market is now just fork Chrome source and apply your logo, thanks to Google (see Opera, Brave and hundred others as an example).

Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.

That's not competition in the browser space that's just giving Google more power.

Google is an incredibly evil company and are hellbent on destroying the open web.

Gmails embraces and extends regular email with new features that only work when sending Gmail to other Gmail users.

I can:

Chrome.

Sadly the Chrome team together with web devs everywhere are creating a web where "works best in IE6^h^h^hChrome" is making a very unwelcome comeback.

This should be so unnecessary in 2018.

I don't think the devs are necessarily doing this on purpose. I do however wish they'd be somewhat more considerate about the web ecosystem.

I'd also wish they hadn't used their dominant position in ads to push Chrome as "a better browser" for years to everyone including people who already used modern browsers.

GChat/Hangouts is a prime example. The embraced XMPP and Jabber much to the delight of the open protocols communities. They then expanded on the protocol adding stickers and drawings and other stuff. Then closed off their XMPP gateway once they were huge (stickers no longer work with the protocol they said), essentially killing the future (at least mainstream) of XMPP, and pushing more people to proprietary messaging platforms.

Gmail is embracing and extending email.

AMP is embracing and extending website hosting.

Google News is embracing and extending free web news outlets.

Chrome is embracing and extending the open-source web browser community.

Android is embracing and extending the open-source mobile OS development community.

I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.

Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.

Careful readers will notice that you did not use the word extinguish in your reply.

There isn't a monolithic explicit strategy with the word "extinguish" in it. Instead there's a pervasive set of tactics which result in embracing, extending and, when successful, extinguishing open standards and communities.

Gmail is very far away from extinguishing open email, because that's such a huge target, but it certainly managed to make a dent. How many users have forever left the open ecosystem of smtp/imap/pop tools and service providers because of Gmail's growth? If Gmail hypothetically reached the market share necessary to mortally wound that open ecosystem, do we have any doubt that it would eventually do it?

And remember, email is the largest open ecosystem in my list. Where is the fully open alternative to iOS? Answer: it doesn't exist because Android captured all the momentum from the emerging community, and channeled it into a platform that is now closed for all practical purposes. In this case, extinction has already happened.

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.

How does that work in say, Firefox?

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.

Exactly the same, the preload list data is public and used by all the major browsers.

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?

See https://hstspreload.org/. And all major browsers. Chrome, Firefox, Safari, Opera, IE, and Edge for starters.

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?

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.

Reply on news.ycombinator.com