Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing .app, a more secure home for apps on the web

blog.google

Post reply on HN
Print view View original

1–10 of 378 posts

Re: Introducing .app, a more secure home for apps on the web

#4

Post by dmurray »

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

Re: Introducing .app, a more secure home for apps on the web

#5

Post by sakuronto »

ryannevius wrote: post #3
dmart wrote: post #2

Excellent, this will surely cause no confusion with macOS executables.

I'm not sure how a .app TLD could be mistaken for a .app executable.

You severely overestimate the technical skill of the average user. And even people who know their way around computers rely heavily on patterns in order to identify relationships, so a strong pattern without an underlying relationship is, of course, going to lead to confusion.

Re: Introducing .app, a more secure home for apps on the web

#8

Post by chatmasta »

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.

Re: Introducing .app, a more secure home for apps on the web

#9

Post by untog »

The defining feature here seems to be HSTS - all .app domains will connect via HTTPS by default, and never try HTTP. Which is nice.

Otherwise... eh. In theory this becomes a home for web sites specifically related to apps. Certainly that seems to be what Google are suggesting. But are web apps "apps"? Is this native only? Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? (spoiler: no).

So it's just another TLD, really.

Re: Introducing .app, a more secure home for apps on the web

#10

Post by untog »

sakuronto wrote: post #5
ryannevius wrote: post #3

Earlier quoted context omitted.

I'm not sure how a .app TLD could be mistaken for a .app executable.

You severely overestimate the technical skill of the average user. And even people who know their way around computers rely heavily on patterns in order to identify relationships, so a strong pattern without an underlying relationship is, of course, going to lead to confusion.

The average user has no idea that the .app file extension even exists. macOS does not expose it in Finder.
Post reply on HN