Live data from Hacker News

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

blog.google

181–190 of 378 posts

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

#181

Earlier quoted context omitted.

Chagos is the preferred name for the atoll that the British named to be "their" Indian Ocean Territory in the colonial empire era. Chagos should get direct control of .io, but it is a weird political fight. One awareness campaign: http://www.thedarksideof.io/

I mean why would Chagos, free of ever having the British, end up with IO as a country code?

Well, there aren't any obvious alternatives, for one thing: .ch is Switzerland, .ca is Canada, etc.

I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.

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

#182

Supporting https is only an infinitesimal part of what makes downloading apps on the internet like playing Russian Roulette. It still doesn't prevent unsuspecting users from downloading malware, adware, ransomware, and apps that siphon user data. It also doesn't prevent users of sites depending on third party ad networks from being a victim of the same vulnerabilities they are now.

Agreed. The title made it sound like every application hosted from .app would be somehow vetted. Which would be... unconventional, but pretty interesting. Instead it's just another random foothold Google's found in its crusade against HTTP.

Not that I think HTTPS-everywhere is bad, I just think there are better ways to spend one's effort now that we have HTTPS-nearly-everywhere.

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

#184

Earlier quoted context omitted.

It's not arbitrarily. You can use the standard HSTS to be applied domain wide https://hstspreload.org/#tld

That’s fair, given that HSTS is after all a standard itself and Google is merely applying it. Then I guess my perplexity is towards IETF in that they allow for two conflicting standards to exist. What if I want to use local.my.app for development; Or, in a more textbook example, i want to use workstation-1.building-a.my.internal.my.app without https?

That's a bad idea but here you go https://stackoverflow.com/questions/44650854/how-to-disable-...

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

#185
I wish Google or someone else with a lot of money would go and register every word in the English dictionary and then sell domains for reasonable prices. And there should also be a rule against domain squatting, for example only allow five domains per person/company.

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

#186
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 efficiently allocate domains to those who want them the most, rather than allowing desirable ones to be snatched up by those with the intent of reselling them. It's the concert ticket problem in domain name form.

We are currently in the first day of EAP. Each price tier lasts for the entirety of the day, and then ticks over to the next lower tier at precisely 16:00:00.000 Z. There are price drops over the first four transitions, and then the final three days are all at the lowest price tier. EAP is a one-time acquisition fee; you do not pay that on subsequent renewal. Different registrars choose different amounts for EAP tiers just like they choose different rates for base registration. EAP began today at 2018-05-01 16:00:00 Z and ends precisely when GA begins, which is at 2018-05-08 16:00:00 Z.

The confusion around EAP is stemming from the fact that many registrars are offering preorders for specific EAP price tiers (or GA). So while we're not yet in the lowest price tier, you can put in a preorder for the lowest price tier now, and the registrar will then attempt to register the domain for you within the first moments of that price tier once it begins. Whereas if you buy a domain in the current price tier, the registration goes through immediately and there's no element of chance like there is for preorders. Typically preorders that you don't win are refunded, though some registrars may charge non-refundable application fees.

Separately from all of that, there are also premium domains; those prices are orthogonal to EAP and affect renewal prices as well as initial registrations. EAP fees disappear entirely once we hit GA, but premium fees persist. Again, the intent of all of these is efficient domain allocation. You may be asking "why both?", and the answer is that both pricing mechanisms are good at solving different aspects of the problem of efficient allocation.

For a full list of registrars selling .app, see https://get.app and https://www.registry.google/about/register.html

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

#188

Earlier quoted context omitted.

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

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

#189

Earlier quoted context omitted.

.app was a tiny bit more expensive to acquire than that ... http://www.businessinsider.com/google-just-paid-25-million-t... We're not expecting to make our money back on this one. And these amounts are a drop in bucket compared to many other Google products anyway. So a cynical profit motive is not why we're doing it. We're doing it for the stated reasons, to move security forward on the Web; see https://security.goo…

Thanks for the correction about the price. However, 10 years of 1 million domains, even if Google's cut is only $1 out of the registration price, is still $10 million per year * 10 years = $100 million. If Google's own registry is used and you capture more of the ($17/year ?) domain fee, it goes up by multiples of that. Correct me if I am wrong, but serving the DNS entries of .app will be almost the same as serving u…

Alphabet made $31B in revenue last quarter. [1] CydeWeys already addressed their costs, but $100M over 10 years doesn't exactly sound like something they get out of bed for, especially considering they're already out $25M and they really will have expenses to cover for this.

[1] https://abc.xyz/investor/pdf/2018Q1_alphabet_earnings_releas...

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

#190
post #89
post #73

Earlier quoted context omitted.

Except, .sh means nothing in particular in Linux. It just so happens people use .sh for shell scripts.

It just so happens people unnecessarily use .sh for shell scripts.

It's not. It helps you find stuff.
Post reply on HN