discuss Why .app when we have app stores?

[FavourB]

Hi everyone,

This question is mainly thrown to the veterans and those who have long time history with domains, i believe from there experience they can render some explanation, not like the owe we the newbie any, but out of curiosity i just wish to know why the .app extension was created.

1&half years into the industry and it still makes no sense to me

So please why .app when we have various app stores?

 

[FavourB]

Just 1 example

 

[Paul]

So please why .app when we have various app stores?

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

 

[mdrn]

Progressive Web Apps (PWAs) are replacing native apps, and .app is the only extension that best matches PWAs.

This and web apps in general, not only for mobile but desktop as well.

Many SaaS services could use .app and have it work well with their branding.

Wish I was able to register some names when .app first came out. One thing I don't like is that a lot of good names are premium and you have to pay the premium price yearly. Other than that caveat for increasing usage, I think .app will grow in the tech world during the next couple of years.

As always, time will tell.

 

[Steven McEvoy]

Why have any ngtld?

 

[mdrn]

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

Great points about the security benefits Paul.

Having a separate SLD, especially with the forced HTTPS, is a nice secure setup. I can definitely see companies adopting that framework.

 

[Masay]

. dev and .app is the best alternative for developer to handreg their desire names. most of them don't want to pay premium for .com domains.

Seems Google is not tired of creating boring extensions

for end user .dev .app is a good news.

 

[MadAboutDomains]

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

Great points about the security benefits Paul.

Having a separate SLD, especially with the forced HTTPS, is a nice secure setup. I can definitely see companies adopting that framework.

Unfortunately I think that there's been a misunderstanding about HSTS and communication over HTTPS...

It's not any use for enforcing security of back end systems, HSTS is a browser instruction. So there's no difference between .app and any other domain in this regard.

https://tools.ietf.org/html/rfc6797#section-2.3.2.2

One should restrict communication to their backend systems to HTTPS by other mechanisms.

As for subdomains not having the same security. What like?

 

[mdrn]

Unfortunately I think that there's been a misunderstanding about HSTS and communication over HTTPS...

It's not any use for enforcing security of back end systems, HSTS is a browser instruction. So there's no difference between .app and any other domain in this regard.

https://tools.ietf.org/html/rfc6797#section-2.3.2.2

One should restrict communication to their backend systems to HTTPS by other mechanisms.

As for subdomains not having the same security. What like?

No misunderstanding.

It is simply convenient for security out of the box. Automatically on HSTS preload list, so not possible of making http connection. If not on HSTS preload list, you run the risk of loading a redirect page of http to https which can be intercepted. Also with HSTS, you can prevent SSL Stripping Attacks (MitM).

You can add domains on this preload list if they meet the requirements, so every domain is capable of this - but you need to set it up.

From my experience, having a separate SLD is to simply sandbox your domain from your other domains. You can set up different rules for this domain. Can also mitigate risk during a DNS attack or hijacking depending on how/where your domains are stored. Doesn't need to be .app but again, since .app is on HSTS preload list, it makes for an easy and secure solution.

Any domain can achieve these benefits, as they should, but .app is conveniently secure out of the box. Not revolutionary but it sure is a positive benefit.

Using the word 'secure' loosely, please don't read into it more than necessary. Secure in HTTPS sense, nothing more.

 

[MadAboutDomains]

Automatically on HSTS preload list, so not possible of making http connection.

Using the word 'secure' loosely, please don't read into it more than necessary. Secure in HTTPS sense, nothing more.

It's not secure in a HTTPS sense when you can connect over HTTP.

It wouldn't automatically protect an app or communication on the backend, only when connecting through a browser that supports HSTS.

So as long as people know that it's all good.

As explained by this quick bit of command line:

 

[mdrn]

It's not secure in a HTTPS sense when you can connect over HTTP.

It wouldn't automatically protect an app or communication on the backend, only when connecting through a browser that supports HSTS.

So as long as people know that it's all good.

As explained by this quick bit of command line:

Show attachment 166693

Correct and I understand what you are saying, but backend you would ideally have it connect through HTTPS of course.

Thank you for the explanation.

 

[Paul]

It's not any use for enforcing security of back end systems, HSTS is a browser instruction. So there's no difference between .app and any other domain in this regard.

Yes there is: app is in the HSTS preload list with the includeSubDomains flag. That means that all websites on SLDs of app must use TLS--modern browsers will outright refuse to communicate with them over plaintext. Even if you try to enter http://example.app/ in your browser, and even if example.app were listening on port 80, your browser would never even attempt to connect over a plain connection.

That's pretty powerful. It's not the most important security feature, but it defeats certain kinds of attacks, and it mitigates the impact of common mistakes that a website operator might make.

It's no panacea; it's not going to magically defeat censorship under oppressive governments, nor is it going to secure clients that have otherwise defeated HSTS or TLS--such as cURL. However, choosing to host an API on an app SLD does mean that you've reduced the impact of human errors that might otherwise go unnoticed, especially on a website that will never be visible to the end-user (since it's just serving an API).

As explained by this quick bit of command line:

Yes, it's up to the client to enforce it. It's a safety net, not some magical security solution. Chances are if you're using the cURL command line utility, you're not a typical user. cURL is already difficult to use correctly (and securely)--as demonstrated by the mishandling of the text encoding in your screenshot.

Security in layers. HSTS is a powerful tool; were I making an API today, I'd definitely opt for a TLD that's in the preload list. Why not? Users are never going to see it, and it's a nice safety net.

 

[MadAboutDomains]

Cheers Paul and mdrn. I agree that it's not a panacea and I also think it's great to have cause it's essentially ubiquitous in browsers now. It's a bug bear of mine when I see websites that aren't enforcing HTTPS, but what I'm trying to express (badly, it would seem) is that it's not going to protect back end systems out of the box because it requires client software to enforce it. Whereas we can and should protect our website and app backend APIs from the server side... HSTS is no excuse for not having that sown up.

Yes, it's up to the client to enforce it. It's a safety net, not some magical security solution. Chances are if you're using the cURL command line utility, you're not a typical user. cURL is already difficult to use correctly (and securely)--as demonstrated by the mishandling of the text encoding in your screenshot.

hehehe. Yes, I searched Google and the 3rd result down was open on port 80 and it happened to be non-English. I'm surprised that I found one that quickly.

 

[dirk]

Also, let's not forget about subdomain hijacking. It happens more than you would think.

 

[Lox]

URL Noise reduction (latency) e.g.

mymoneymakingapp.noisereduction-domainname.com/faster?morefaster=&index=1

vs

product.shortname.app/fast?morefast=&index=q

and forced SSL

 

[Bname.com]

I don't like the suffix

 

[Bob Hawkes]

This week's NamePros Blog post deals with the .app extension and includes some information on real-use of the extension, the topic of this thread.

https://www.namepros.com/blog/two-years-plus-of-app-domain-name-sales.1207846/

Bob

 

[FavourB]

This week's NamePros Blog post deals with the .app extension and includes some information on real-use of the extension, the topic of this thread.

https://www.namepros.com/blog/two-years-plus-of-app-domain-name-sales.1207846/

Bob

I notice Zb.app still redirects its users to download the app from Google play.

So what am trying to say is, I don't understand the .app value if...wait how do I put this, grrrrrrr

Like I think .app will be valuable if the build an app it, like no need to take me to play store or any app store, like I should be right on the app when I visit the website, you understand what I mean?

Trust me if this happens .app will go plantinum

 

[Bob Hawkes]

So what am trying to say is, I don't understand the .app value if...wait how do I put this

As I view it in most cases it is to have a site so that potential users can go to your app and learn about it, and then have the links for versions at all app sites. Also, it is a site for providing customer support, that by definition needs to in most cases be outside the app. I believe that the app stores (at least iOS does) has a rule that you must have a site to give for customer support.

Now some who use .app are not for that use. For example, if I was an app developer, wanting one for my career site, it makes sense to use my or my company name with .app.

Another use I would see is if some companies mainly have some website NAME.com, but they want to direct users for support for an app they also use they could say go to NAME.app (in same way many are using .news for the news site).

I think that ultimately .app has made medium progress. If it became so much the norm that when needing support for an app you would guess it would be at Name.app, in way people now in USA and to some degree in other parts guess the company site is at .com, then the demand for the .app would grow to some millions. Who knows if that will happen.

Not sure if you have gone to the links in the article with the examples Google are showcasing, or other examples I am giving.

I see .app as having a future as an extension. I am less clear about as a domain investment. I personally have none in my portfolio currently (had one in past).

Bob

Edit: Added note the website for an app does not have the same restrictions, on length, media etc, that the description in an app store does. As such it can be a more effective way to promote an app. This is not an argument for .app per se, since a .com or .tech or .io can do same, but is an argument re why we still need a website with an app.

 

[Masay]

like I should be right on the app when I visit the website, you understand what I mean?

it's PWA, https://en.m.wikipedia.org/wiki/Progressive_web_application

 

[Jim H]

Isn't it better to have more channels to get network traffic.

As I view it in most cases it is to have a site so that potential users can go to your app and learn about it, and then have the links for versions at all app sites. Also, it is a site for providing customer support, that by definition needs to in most cases be outside the app. I believe that the app stores (at least iOS does) has a rule that you must have a site to give for customer support.

Now some who use .app are not for that use. For example, if I was an app developer, wanting one for my career site, it makes sense to use my or my company name with .app.

Another use I would see is if some companies mainly have some website NAME.com, but they want to direct users for support for an app they also use they could say go to NAME.app (in same way many are using .news for the news site).

I think that ultimately .app has made medium progress. If it became so much the norm that when needing support for an app you would guess it would be at Name.app, in way people now in USA and to some degree in other parts guess the company site is at .com, then the demand for the .app would grow to some millions. Who knows if that will happen.

Not sure if you have gone to the links in the article with the examples Google are showcasing, or other examples I am giving.

I see .app as having a future as an extension. I am less clear about as a domain investment. I personally have none in my portfolio currently (had one in past).

Bob

Edit: Added note the website for an app does not have the same restrictions, on length, media etc, that the description in an app store does. As such it can be a more effective way to promote an app. This is not an argument for .app per se, since a .com or .tech or .io can do same, but is an argument re why we still need a website with an app.

I suggest you register some .apps just to invest the future.Sir.
I've already got some.