Hacker News Reader

Comment by dmurray | Hacker News Reader

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

View on HN

Tech lead of Google Registry here. I can help answer some questions.

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.

What are your thoughts on HSTS for a TLD when a CA can then revoke a site’s cert, preventing access entirely (See: Comodo and Sci-Hub).

You can always get a new SSL certificate from someone else quite easily (e.g. Let's Encrypt). So that's a temporary problem at worst.

As long as the CA is in a jurisdiction that can require revoking access, it becomes an attack vector if HSTS is enabled and you’re at the mercy of preloaded root CAs.

There are much worse attack vectors if the entire connection is unencrypted, though.

There are many preloaded root CAs. Are you saying you're worried that every single one of them will simultaneously be required to revoke your certificates?

Finally, "there are several dozen CAs and some are really sketchy" becomes a strength, rather than a weakness!

Sketchy CAs that issue certificates to people that don't actually own the domains in question tend to get nuked from the chain of trust very quickly.

Historically, I'd disagree with you, although it is improving with Certificate Transparency monitoring and alerting.

Fair enough, but it's getting better, especially thanks to CT as you point out.

Trying to register via google domain says "Google Domains does not support the .APP ending". Is that on purpose (Google domain is listed on get.app as compatible) ? A cache issue ?

I can't speak specifically for Google Domains as that's a completely different team that we have limited interactions with.

What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.

Wait, so you put out this launch announcement telling people they can early register .app domains. It links to a bunch of partners including Google Domains, but you have no idea whether I can actually register a domain there or not? Why promise it in your launch announcement then?

Choice of domain registrar is up to the end user. We cannot recommend any one over the other. There are plenty that are offering the full range of registrations/preorders (including EAP), and you need to pick your own.

The full list of registrars onboarded for .app, including annotations for those supporting EAP, is here: https://www.registry.google/about/register.html

They put this announcement out so they can sell spots on the "Priority Pre Registration" list for $16,000.

It's just another fucking cash grab.

For end users it costs ~$20, right now from one of the EAP registrars.

Outrage is great, but it's a good idea to read before firing off like this.

It costs end users ~$20, for whatever's left over after the seven rounds of expensive "priority access" pick over the namespace carcass... At least for the two out of three resellers I tried (Google themselves still don't appear to know this exists...)

That’s misleading. That won’t fire until May 9 (GA). If it’s left.

(You can use your TMCH SMD file to register your trademark.app for ~$20, but that’s not really what we’re taking about here.)

The cash would be grabbed anyway, if not by them then by squatters.

They want the big bucks for EAP registrations ($10.8-$16k depending on registrar).

If you have a TMCH registered mark you can get your .app for ~$20, though.

Godaddy enables you to preregister at the moment. This is only a preorder and doesn't guarantee the domain.

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.

This list is useful, but the early access domains are mostly unfamiliar to me. Does anyone have any recommendations?

GoDaddy is confusing. They only have "Pre-Registration" and "Priority Pre-Registration", the latter showing the days of the EAP, but it only says you can "increase your chances of getting this domain", not that you get it right now.

Aka GoDaddy is running a dirty scam. There should be no such thing as "priority pre-registration". They're just trying to grab more money. GoDaddy is the worst company you could ever look at for domain registration. Use literally anybody else.

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 to have to pay to registrar now and then a transfer fee to transfer to my primary register down the road.

3) GoDaddy is listed as an EAP registrar, however, they are only accepting pre-registrations at this time. On top of that, they found a way to be even more shady by charging a $173.99 for "Priority Pre-Registration".

The right hand cannot talk to the left hand in this case, however. It's a complicated space to operate in. Start here if you're a policy wonk: https://archive.icann.org/en/topics/new-gtlds/gac-board-regi...

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.

The complaint is against Google, not any particular domain registrar, to be fair. At first glance it seems like you’ve botched this roll out for the (preventable) reasons mentioned above. Wordpress, although I didn’t agree with some choices they made when doing it, did a wonderful job rolling out the dot blog TLD, as a counterpoint.

We literally cannot coordinate anything between the registry and registrar though. I agree with you that we (the registry) could have done a better job on our marketing website in making it clearer which registrars offer support for which phases, but beyond that? Not sure.

The $173 is a "Phase 7 Pre Registration", for the low low just for you price of $16,000 you can have a Phase 1 Priority Registration!

They're just auctioning off all the good names - same as every other domain squatting rent seeker...

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.

Different registrars set different prices. .com domains cost different amounts across different registrars too. It's not a mistake, and if price factors into your determination of which registrar to use, then that totally makes sense.

Right - so you've just built this to give bdirty scammers another way with which to rip everybody off. Thanks for that. Lucky "Do no evil" isn't written on the wall there anymore...

This is not true. One of my friends and myself have both paid for registration of different .app domains and some ten hours later it still says pending at two different vendors listed there as EAP providers.

You can register at the registrars marked at EAP. Gandhi is one for example.

I know TLD's doesn't affect SEO, but does Google enhance .app domain SEO when people search for apps on Google search?

> I know TLD's doesn't affect SEO

So you have your answer.

I'm not saying I agree with his stance, but I think it's important to mention Dave Winer's concerns re how the ongoing transition to HTTPS will affect older sites. Many of these played an important role in the web's rise to prominence, but could lose out if HTTPS becomes the baseline for trustworthy content.

Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been any discussion within the Registry or Search teams about how to address these kinds of situations?

I have some really old sites myself running on Jetty 5. I recently put them behind nginx and set up letsencrypt. It wasn't terribly difficult.

Can you give an example of a site that couldn't be moved to HTTPS? I would expect that even if the serving stack doesn't support HTTPS you could put a proxy in front of it.

Winer's argument seems to be that he owns a number of sites that don't need the explicit security that HTTPS provides (a blog archive, for example), but that shouldn't affect how Google and the rest of the web view whether or not the content is trustworthy.

Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS.

As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases.

You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with.

The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.

IIRC, .app isn't the first TLD to be included in HSTS preload list. I hope the registrars will make it clear to customers that .app itself is in the HSTS preload list to prevent any confusion.

As nice as an HSTS preload list is, using .app and .dev for this is infuriating.

Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.

Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...

I've been told by a few people that it's my own fault, that I should have used something else like .test, etc.

I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution.

Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.

Reply on news.ycombinator.com