I want to clarify some details on how the Early Access Program (EAP) works because I'm seeing some confusion here in the comments. EAP is a 7-day period in advance of General Availability (GA) during which domains can be registered immediately (not pre-ordered). EAP is a descending price ("Dutch") auction, meaning that prices start off high and then decrease as the auction goes on. The reason for this is to efficient…
Introducing .app, a more secure home for apps on the web
211–220 of 378 posts
Re: Introducing .app, a more secure home for apps on the web
#212Earlier quoted context omitted.
You can register a domain name at this moment during the Early Access Period through any registrar which supports it (which includes GoDaddy and many others listed at https://www.registry.google/about/register.html ). It's not a pre-registration; the domain is created and assigned to you immediately.
To be blunt, this is a horrible roll-out by Google. It is a perfect example of the right hand not talking to the left hand, or the rest of the body for that matter. Several significant issues: 1) The announcement is made by Google, yet Google is not accepting EAP registrations. Very confusing. 2) The registrars accepting EAP are not as widely known as you would expect for something like this, meaning that I am going…
Whether registrars support EAP, and how they implement it, is entirely up to each registrar. If you have complaints about any specific registrar practices, or about registrars not supporting it full stop, then those should be directed at the registrar in question.
Re: Introducing .app, a more secure home for apps on the web
#213I want to clarify some details on how the Early Access Program (EAP) works because I'm seeing some confusion here in the comments. EAP is a 7-day period in advance of General Availability (GA) during which domains can be registered immediately (not pre-ordered). EAP is a descending price ("Dutch") auction, meaning that prices start off high and then decrease as the auction goes on. The reason for this is to efficient…
what defines a domain name as premium?
(Not joking.)
Re: Introducing .app, a more secure home for apps on the web
#214Earlier quoted context omitted.
Both pricing mechanisms are great at: (a) transferring wealth from the secondary market to registrars, and (b) guaranteeing that desirable domain names get allocated purely on economic value terms, thus effectively shutting out non-profit-oriented enterprises from the best domain names. If someone with some quirky desire to name a domain name after their cat would like to grab the domain name and refuse to sell, this…
Desirable domains are by definition scarce -- there is not enough of them to go round to those who desire them. The current approach is essentially saying "if you really desire domain X badly, put your money where your mouth is". Do you have an alternative proposal on how these desirable domains could be allocated more efficiently?
Re: Introducing .app, a more secure home for apps on the web
#215Earlier quoted context omitted.
Just like .com didn’t cause confusion with DOS and Windows .com executables.
It helped a little that .com executables were pretty much obsolete by the time the web became common, but that was still a pretty nice gift to early malware authors.
Re: Introducing .app, a more secure home for apps on the web
#216Earlier quoted context omitted.
You can register a domain name at this moment during the Early Access Period through any registrar which supports it (which includes GoDaddy and many others listed at https://www.registry.google/about/register.html ). It's not a pre-registration; the domain is created and assigned to you immediately.
There has to be an error somewhere on a couple registrars. Trying through 101Domain adding a domain to the cart results in a total of $12,025.16 USD. I can get it slightly cheaper at Yay.com for $10,209.09.
Re: Introducing .app, a more secure home for apps on the web
#217Is being cynical about this allowed? Google throws down a few hundred grand to get the .app domain, in concert with modifying their web browser to deliberately mark others' traffic as "Insecure" (it is not necessarily!), and reaps the fees now and in perpetuity ever year thereafter for maintaining a simple database of DNS glue entries which you literally could maintain using MS Access (by which I mean, the database s…
Google won't get extra fees from sites running HTTPS. There is no indication that they will make any difference between sites on TLDs that enforce HTTPS and any other site with HTTPS enabled. Anyone running a new TLD can make it HTTPS-only if they think that's something domain-buyers want. Where's the problematic way of making profit for them? I don't think being HTTPS-only will do much for the success of .app.
Re: Introducing .app, a more secure home for apps on the web
#218Re: Introducing .app, a more secure home for apps on the web
#219Earlier quoted context omitted.
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?
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.