Ted from Namecheap here - we've been excited about this TLD launch for a couple of years now and we plan to sell .app domains! Stoked it's launching very soon.
Introducing .app, a more secure home for apps on the web
11–20 of 378 posts
Re: Introducing .app, a more secure home for apps on the web
#12If 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…
Re: Introducing .app, a more secure home for apps on the web
#13Ted from Namecheap here - we've been excited about this TLD launch for a couple of years now and we plan to sell .app domains! Stoked it's launching very soon.
Re: Introducing .app, a more secure home for apps on the web
#14Ted from Namecheap here - we've been excited about this TLD launch for a couple of years now and we plan to sell .app domains! Stoked it's launching very soon.
So I have a Namecheap account and trying looking at an .app domain just now, but it says "We don't support this TLD". Because of this I am now on GoDaddys page pre-registering there.
Re: Introducing .app, a more secure home for apps on the web
#15On the one hand, I support creating new platforms with security built-in by default, but on the flip side, the Chrome team just axed HPKP without even so much as bothering to try to refine it to mitigate the footguns.
I don't understand how the web-facing security decisions at Google are made. :/
Re: Introducing .app, a more secure home for apps on the web
#16Ted from Namecheap here - we've been excited about this TLD launch for a couple of years now and we plan to sell .app domains! Stoked it's launching very soon.
Ted, any reason why you don't permit pasting the 2-factor auth code into the input box?
Re: Introducing .app, a more secure home for apps on the web
#17Excellent, this will surely cause no confusion with macOS executables.
Re: Introducing .app, a more secure home for apps on the web
#18Ted from Namecheap here - we've been excited about this TLD launch for a couple of years now and we plan to sell .app domains! Stoked it's launching very soon.
Re: Introducing .app, a more secure home for apps on the web
#19> 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 sec…
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-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.
Re: Introducing .app, a more secure home for apps on the web
#20If 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…