Hacker News new | past | comments | ask | show | jobs | submit login
Introducing .app, a more secure home for apps on the web (blog.google)
395 points by daniel-alex on May 1, 2018 | hide | past | web | favorite | 366 comments



Yeah, the play store of websites. Where we need to get permissions and approvals and can get banned. No thanks, Google is trying to bring their walled garden idea for websites. Don't trust Google on this. They just turned off their service rather than support signal, what if signal was signal.app would they block em? Don't trust Google on this. It's a decent idea but no.


Actually I was searching for Terms of Service and Acceptable usage policy for .app domains and could find NOTHING specific. Not even on official site https://get.app/

I could only find Google Terms of Services, so they also apply to .app ??? So what if I host e.g. adult related material on .app will they ban me? The usage policy is totally in the dark for this domain.

UPDATE: Found something here https://v4.gandi.net/static/contracts/en/app/pdf/special_con... and here https://portal.icann.org/servlet/servlet.FileDownload?file=0...


Good sleuthing. ICANN's site can be arcane to navigate at times (like Dell's or Microsoft's).


> No thanks, Google is trying to bring their walled garden idea for websites.

It might affect your app's search rank if you don't comply ...


I've used DuckDuckGo for months. Only the very most esoteric of terms brings me back to Google, and I can count those times in the past months on one hand.


Yes, but good luck convincing the (potential) users of your app :)


It's certainly an issue to consider if you're starting a company.

If you are creating a organization that is less focused on making money as a core element like a business is, then you should feel fine using .org or any other domain.


Is there any precedent for a TLD owner doing what you describe? I think this is HSTS preload and nothing more.


ICANN has hundreds (thousands?) of pages of rules and procedures relating to the ngTLD program detailing exactly how all of this plays out. Spoiler alert: There's not and can't be.


yes, there are many domains which describe what is acceptable and what not on their usage policy or terms.



Both of those are articles are about registrars refusing to do business with one specific hate group. They're not about registries.


Yes, but that still represents a very serious problem. The EFF has written extensively on it since this occurred in August. Here's a starting point: https://www.eff.org/deeplinks/2017/10/eff-icanns-registrars-....

ICANN has worked very well so far, but if they don't put up a strong response to registrar-based censorship on already-registered domains and make this contractually impossible, the internet is going to be in big trouble. We can't let "you can't have a domain because we don't want you to be able to talk, as a matter of corporate policy" become a thing.


Is the problem worse with .app than with .com? If so, why?


Aren't Google and Godaddy both TLD owners?


GoDaddy is a registrar. Google has both a registrar and a registry, but the linked actions were taken on the registrar side (i.e. not relevant to what the registry can do with its TLDs). The list of TLDs run by the registry can be found here: https://www.registry.google


Yes, technically. But GoDaddy's GTLD (.godaddy) isn't available for public use, so your point is moot.


My point is that google will ban your website off the internet in whatever way possible for them, if they don't agree with what you're saying. They have demonstrated this as I linked. Just because their role is now TLD owner, doesn't mean they will not do what they think is necessary.


They violated terms of use. What's the problem?


No problem. I was just answering parent's question about precedent.


It's weird how Facebook is getting all the heat but Google is the real snake in the grass.

When Google bans you, they delete your drive, Gmail, photos and everything associated with it including the ability to search. Also they are associative; if one of your accounts are banned then any account, even business accounts, are all purged.

One of a startup in my previous cohort was completely deleted after one of it's employees who had a banned Google account logged into Google for business

Don't risk. Avoid


Are you saying that Google banned the whole organization based on the association of one employee with a banned account? And they withheld your data with no recourse? Did you consult a lawyer?


It's a widespread issue:

http://www.slate.com/articles/technology/future_tense/2013/0...

https://www.perrymarshall.com/2270/google-bans-your-account/

https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_...

Just curious, how can you even get a lawyer for issues like this? And in US it would all be a sham show (like the Zuckerberg senate hearing)


I was specifically asking about the business's organization being shut down because of an employee's unrelated banning.


It was a startup. I don't think they could afford it


You mean Signal the messaging app? Can you link to a news?



I don't understand why Google or Amazon are to blame here. It's like using an unofficial API and then complaining when it's taken down. Yes, it sucks that Signal can't hide behind them to bypass censorship, but as far as I understanding, it's not a good practice for these big sites to support Domain fronting in the first place.


Jesus, now Signal is useless.


Only if you live somewhere that blocks it.

And I suspect even then, you could still use a Signal server hosted by someone else.


Not with the official client.


Makes sense, given their mission to monopolize the internet.

Break up google.


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


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.


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.


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.


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.


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?


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.


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.


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.


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


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.


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


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


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.


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


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.


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


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.


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


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.


Sigh. As I’ve said before, we need stronger identity profiles and user agents that verify much more than legitimate-sounding names. A name alone should effectively be treated like it could be completely and utterly fake, period.

Yes, they’re requiring "https" but it’s not like it is hard to acquire a certificate anymore.

All the ".app" domain will do is screw app developers into paying to register their chosen name on a particular domain. Again. After all, if you don’t register then someone else could, giving their site perceived legitimacy over yours. Let’s not forget, many apps are not making millions on top-10 lists; developers aren’t exactly eager to further cut into their meager earnings to cover web sites.

We already know that entire apps are being copied. Scammers have never been deterred from copying entire web sites either (just look at those E-mails from “your bank”). This new domain might serve mainly as a way for scammers to make stolen copies seem even more real. Frankly, I predict that all the real talented developers will be slowly discouraged from continuing to try to make money in an environment where obvious fakes can thrive so easily and the costs just keep going up.


HTTPS and SSL certificates are primarily used for encrypting the connection, thus protecting your data from snooping and modification in transit. They are not actually that useful for authenticating identity. Users tend to simply ignore the padlock icon, which is why Chrome is moving away from an affirmative security display model (which users don't pay much attention to) to displaying prominent warnings for insecure or hijacked connections, which users do pay more attention to. SSL certificates' inability to properly authenticate identity is also why many of the largest tech companies in the world do not even bother with EV certificates (e.g. Google, Amazon, and Facebook for starters).

In order to fully establish identity and provide strong authentication, you would need a much stronger centralized system. Additionally, browsers would need to refuse to make connections to endpoints not authenticated through this system, otherwise you'd have the same kind of lackadaisical user response as we see now to the padlock icon. I don't think anyone present here wants anything like that, and I'm sure that if we were proposing such a walled garden vision for the Internet, the responses would rightfully be much more negative. Instead, we just want everyone's connections to be encrypted.

As for some of your other points, having a strong, short, memorable domain name is good for overall Web security and does help cut down on fraudulent apps and the other problems you've identified. To give you one example, I recently saw an ad for an app called "Curb" (it's a yellow tax ride-hailing app). Out of curiosity I wanted to see more information about it, but there was no domain name on the app; it simply said "Download the Curb app". So I searched the app store for "Curb" and there were dozens of apps with that name, many of them clearly imitators. The best "security" measure was trying to remember what the app's icon looked like.

Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores. That's taking advantage of the global uniqueness property of domain names to guarantee that I won't be tricked away by a scammer. "curb.app" is short and memorable, gets users to the right place, and because .app is a fresh namespace, is still available. Good luck getting any domain name close to that good on .com. .com is fully mined out, and any good names that are available are being sold for minimums of tens of thousands of dollars by squatters and resellers.

I'll be talking about these issues and more in depth at I/O, if you'd like to watch/stream it: https://events.google.com/io/schedule/?section=may-8&sid=7ac...


> Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores.

Now imagine it's a year or two from now and you have the exact same problems that you had with curb.com.

What's the strategy for when .app gets mined out? Are we just going to keep creating new tlds over and over for eternity?

Bear in mind that the only way .app won't get mined out will be if either very few people use it, or if users ignore it and don't treat it any differently than any other namespace. Ironically, the only way this will be useful for developers like me is if Google's advertising campaign utterly fails and it's ignored by most people.

The solution to identity management can't be that users will stay one tld ahead of hackers. That's just never gonna happen. Users are slower than hackers.


> Are we just going to keep creating new tlds over and over for eternity?

Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.

In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squatters will always capture a rent, by guessing domain names that will be valuable latter on. The way to minimize that rent on the long run is to periodically reset the game by bringing new TLDs into existence, thereby devaluing the investment in older TLDs, thereby making squatting a more risky activity. The GTLD liberalization greatly diminished the price pressure on .com .org and the like.

Keep in mind the web has seen exponential increase in the last decades; the upside now is much more limited, maybe another order of magnitude until complete worldwide market saturation and web growth figures get more inline to global economic growth numbers. Once that is achieved the problem becomes much less serious.


> there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.

Zooko's triangle is a triangle - decentralization is not the only thing we could sacrifice. We could even start to layer multiple naming schemes on top of each other to mitigate some of those sacrifices.

What OP (makecheck) was getting at was that the .app tld doesn't really solve any problems except to block one very specific injection attack, and it's problematic for Google to market it as significantly more secure than any other namespace. I agree with that.

The problem isn't that new tlds are unsustainable in the long term (although they are), it's that they don't even solve anything in the short term. Right now, at this moment, I can't credibly tell my parents that they should trust a .app domain more than a .com domain. Within a month of its release, people will be using it to phish older websites - because malicious actors will always be faster than regular users and developers.

If you're trying to block Sybil attacks, I wouldn't be that surprised if introducing new namespaces ironically ends up making the problem even worse.


Wouldn't it be easier to just raise domain registration /renewal prices, making squatting a poor return on investment?


I think that would hurt small businesses more than it would dissuade squatters of truly valuable domains. The trick is to move money from the squatters to the public and domain owners, not to the registry itself, that is basically just another big squatter.

Maybe a TLD like .app could increase the annual renewal fee to something like $100 while bundling premium features like business Gmail, Adwords credits or Google Cloud services, all usable only on that domain name. This way, low level owners get their money back, big corporations don't care and squatters are hurt since they can't make use of the services.


That's what Google did here, by having an early period during which domains cost more.

And this is the predictable response: https://news.ycombinator.com/item?id=16972813


That would effectively be introducing a gatekeeper, just one that's not particularly good at filtering bad actors (money).

There are a lot of benefits to allowing hobbyists and students to cheaply (or even freely) register domains.


Considering your "Go to curb.app" solution, to be brutally honest I think at least 50% of the world has no idea what the difference between "Go to curb.app" and "Download the Curb app" is. They are both practically the same. "Guarantee that I won't be tricked away by a scammer" - yeah, no. There are already too many TLDs to squat on that remove any usefulness of a "short and memorable name" on a new one.

I feel like there's some sort of legitimate blockchain solution to be had here that doesn't involve a centralised authority. Who got there first, what domains they have owned continuously, and what products they control perhaps...


If 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 to a .app domain.

It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. Also, and this is just a feeling, it seems obtrusive for google to force such a policy across the TLD. Of course it’s their right since they own the TLD, but the cynic in me can’t help but think it sets an overbearing precedent. Based on Google’s behavior in the past, this looks like the second step of the “embrace/extend/extinguish” cycle Google has used so effectively in the past.


> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security.

On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement.

.app will be HTTPS only from the start and for the foreseeable future, so (at least in my opinion) there's no need to care about HTTP, or even open port 80 at all.

Granted you could do this before with HSTS preload, but setting that up yourself requires fiddling with headers and waiting a bit while browsers update with the new list. With ".app" it happens automatically, so it lowers the barrier, making it easier for strong encryption to be used by everyone for anything and everything.

This makes HTTPS easier than HTTP, which doesn't look like much on paper, but is (again, in my opinion) one of the best ways to increase security overall.


> if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff.

Except the part where the `.app` domain is only "https-only" in Chrome.


It's not just Chrome.

Chrome maintains the list that most browsers use, but it's not the only browser using the list.

Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's.

You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly.

As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo).

[0] https://github.com/mozilla/gecko-dev/blob/master/security/ma...


This is more about expectations though. The idea is that you shouldn't make a request over HTTP to a .app website and expect it to succeed.


"embrace/extend/extinguish" is Microsoft's invention [1].

What are examples of Google's use of EEE?

[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...


It was Microsoft's strategy roughly twenty years ago. It's Google's strategy today.


Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.


Google Reader would be the often mentioned first example: Google entered the RSS reader market, became the best, added a bunch of features and really became "the" de facto place to read feeds. ...Then closed up shop and killed much of the ecosystem outright, directing people towards proprietary places to get their news like social networks or Google News.

Hangouts did very much the same with XMPP, a move which a Googler once suggested to me was viewed internally as a betrayal of the company's values.

I think we may be approaching EEE territory with email: Gmail's already centralized a large portion of the email industry, to the point that Google has about two-thirds of all emails on one side or the other, and now they're moving into introducing a proprietary email format (AMP 4 Email), which isn't being developed in a standards-focused way.

I'm sure the same argument could be made for their push into RCS over texting, browsers (now pushing Chrome-only websites and features in a lot of places), Android (embracing third party OEMs before moving into locking down much of newer Android functionality and launching a first party iPhone competitor), etc.

If there was a movie quote that best exemplified Google's business strategy, it would be "I have altered the deal. Pray I do not alter it any further."


Google Reader does not fit the pattern of EEE; if anything, it shows their failure to pursue it. EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system. What they actually did was lose a bunch of people for alternative readers, for Twitter and for Facebook.

AMP for email does seem a good example.

RCS is not developed by or supported exclusively by Google. They weren't even the first; Vodafone had it on their phones for years. Google is late to the party.

--

My opinion is not that Google is ethically above doing EEE; it's that they're often too disorganized and erratic to actually pull it off even if they wanted to.


> EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system

Like Google+?


No. The intent might have been to move Reader users to G+, but they did not perform an EEE to accomplish it.


Reader didn't transform into Google+. Google+ was a Facebook clone.


Google Reader is pretty much the opposite of EEE. They built and publicised the market and then walked away.

Just having the best app isn't EEE.


Gmail is embracing and extending email.

AMP is embracing and extending website hosting.

Google News is embracing and extending free web news outlets.

Chrome is embracing and extending the open-source web browser community.

Android is embracing and extending the open-source mobile OS development community.

I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.

Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.


Careful readers will notice that you did not use the word extinguish in your reply.


There isn't a monolithic explicit strategy with the word "extinguish" in it. Instead there's a pervasive set of tactics which result in embracing, extending and, when successful, extinguishing open standards and communities.

Gmail is very far away from extinguishing open email, because that's such a huge target, but it certainly managed to make a dent. How many users have forever left the open ecosystem of smtp/imap/pop tools and service providers because of Gmail's growth? If Gmail hypothetically reached the market share necessary to mortally wound that open ecosystem, do we have any doubt that it would eventually do it?

And remember, email is the largest open ecosystem in my list. Where is the fully open alternative to iOS? Answer: it doesn't exist because Android captured all the momentum from the emerging community, and channeled it into a platform that is now closed for all practical purposes. In this case, extinction has already happened.


GChat/Hangouts is a prime example. The embraced XMPP and Jabber much to the delight of the open protocols communities. They then expanded on the protocol adding stickers and drawings and other stuff. Then closed off their XMPP gateway once they were huge (stickers no longer work with the protocol they said), essentially killing the future (at least mainstream) of XMPP, and pushing more people to proprietary messaging platforms.


I was thinking primarily of Google AMP when I wrote that. Google's strategy is not necessarily the same as Microsoft's was; often it's a bit more subtle, but the common theme is that Google pushes standards that are primarily beneficial to itself, but often paints them disingenuously as "helping the web" or some equally meaningless BS.

Some examples which might not qualify specifically as EEE, but certainly qualify as Google pushing for biased standards:

- Google AMP (not clearly EEE, but definitely anti-open web)

- Google Chrome (not quite EEE, but barrier to entry in browser market is now extremely high)

Some more clearly EEE examples:

- GChat (clear EEE strategy on XMPP)

- Google flights (EEE the travel industry)

- Google shopping (EEE affiliate offers)

- ....

Note that these examples are not solely "competing with an existing business" as you described, because the initial announcement of them was usually welcoming and open, e.g. opening with federated xmpp compatibility, promoting it, and then extinguishing it later. If developers back then had known google would shut down xmpp, maybe they would have put effort into building a better federated xmpp ecosystem instead of wasting time interoperating with google's system. That kind of bait and switch is the hallmark of an EEE strategy.


Gmails embraces and extends regular email with new features that only work when sending Gmail to other Gmail users.


Barrier to enter browser market is now just fork Chrome source and apply your logo, thanks to Google (see Opera, Brave and hundred others as an example).

Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.


That's not competition in the browser space that's just giving Google more power.

Google is an incredibly evil company and are hellbent on destroying the open web.


I can:

Chrome.

Sadly the Chrome team together with web devs everywhere are creating a web where "works best in IE6^h^h^hChrome" is making a very unwelcome comeback.

This should be so unnecessary in 2018.

I don't think the devs are necessarily doing this on purpose. I do however wish they'd be somewhat more considerate about the web ecosystem.

I'd also wish they hadn't used their dominant position in ads to push Chrome as "a better browser" for years to everyone including people who already used modern browsers.


How does that work in say, Firefox?


The HSTS preload list is built into Firefox too (like all major browsers), and automatically rewrites any affected http URLs to https before issuing any requests over the network.


Exactly the same, the preload list data is public and used by all the major browsers.


What is the "single source of truth" for the HSTS preload list? It must be on a server somewhere... who runs the server? Which browsers use this list by default?


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?


Yes, the major browsers ship the HSTS preload list compiled directly into the build. That's why it can take months for a domain to, once submitted, actually be preloaded across a majority of users -- because the browser nightly/beta/release build cycle alone is 2-3 months, plus the time that it takes the average user to update their browser.

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.


I think that if .app becomes widely popular, it would set a precedent to force HTTPS across the web. That's really the only positive I see here. Other than, it just feels like a marketing gimmick to sell domains.


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.


Later google will launch .ampp for apps that are certified to only have Google and their thousands of partners sharing your PII 'securely'.


That honestly doesn't even sound like a joke. I'd believe it if you said that's a quote from the article.


I really like the .app idea, it will save me some time.

echo ".app" >> lists/google/domains

/usr/local/xxxxxxxxx/ufdbConvertDB.sh

service ufdbguardd reload

Problem solved. It is just a matter of fashion, black or white dress? Last few years, black fits better.


...and I'm not sure Google has claimed any different. Just that HSTS enforced on the TLD level is more secure than otherwise, which it is.


Because telling my grandma ".app urls are safer because Google" is like saying "here's a loaded handgun, but the safety is on, go nuts!"

actually that's a bad example because even then my grandma knows to be careful. but she's tech illiterate enough that if she hears something is "safer" she will put blind faith in it.

This isn't an issue for me and you, the readers of HN, this is an issue for Jane Doe, who already has low standards, and is now going to lower those standards even further for a set of websites.


Jane Doe is not reading the Google Blog. The article is directed at developers.


When grandparents start seeing .app urls, they are going to be naturally wary. And they might even avoid clicking them. Then someone is going to ask about them to someone who is only partially tech savvy.

And that someone will tell them that those are safer URLs. And that gets misinterpreted and soon you have people saying they are special approved by google URLs that are guaranteed to be safe.

Regardless of who the article is for, tech illiterate people are going to ask "what is this new URL thing, and should I trust it?"


I don't see what's so difficult about explaining this to your grandpa:

"What's .app?"

"it's like .com or .org, don't worry about it"


That is exactly what I would do. The issue arises when some semi-technical person reads this blog and their response is:

"it's like .com or .org, but it has some stuff in there to make it more secure, and it's managed by Google"

I'm also not the only person my grandparents get to ask about things.

I'm not saying this is all a bad thing. Just that we should be aware that giving things a little security can make people more careless.


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.


Is 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 schema and maintainence is bog-simple).

How is the coming Chrome modification not "tying"? Anyone familiar with anti-trust laws care to comment?


.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.googleblog.com/2017/09/broadening-hsts-to-s... and https://security.googleblog.com/2018/02/a-secure-web-is-here...

Also, I could talk your ear off about the design of our infrastructure for hours. Suffice it to say, it's a lot harder than you're making it out to be, particularly as regards to scaling. Our registry platform is open source, so feel free to inspect the code at https://nomulus.foo . And that's not even getting into DNS hosting, which involves a very large number of instances distributed around the entire globe.


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 up a DNS entry for another domain like .com: the HSTS/https-only requirements will be set up in the browser, not the DNS server.

And serving DNS has been handled successfully and profitably by Namecheap/GoDaddy/Moniker et al for years.


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


I'm seeing prices from $17 - $15,000 for preregistration and the pricing tiers seem very arbitrary... is there any documentation on how Google sets the pricing?


Please see my top level comment here that I've since left.

Note that registrars ultimately set the pricing that you see, which is why it's different across different registrars, same as if you wanted to buy, e.g., a .com domain.


But not only to take care of internet security, but also to protect our children from terrorist and pedophiles, right? I wonder where I have heard similar use of wording that introduced a bunch of new laws harmfull for anything related with freedom...


> So a cynical profit motive is not why we're doing it

That's, if anything, less reassuring.

Google doing it to make money makes sense. THey are a for profit company, it's what they do.

Goodness of our hearts just makes me suspect it's more evil. Quit being evil google.


> (it is not necessarily!)

HTTP traffic -is- necessarily insecure. It's trivial for anyone on your network to run Wireshark and see/modify all of your traffic. And a lack of HSTS leaves your site potentially vulnerable to SSLstrip.


And we have the first person to confound not having a .app with not encrypting the connection here. The comment you replied to did not imply that HTTP is not necessarily insecure, it said that you can (quite obviously) use HTTPS with any TLD.


The comment referred to Google flagging other content as insecure; Google does that for HTTP content, not non-.app content.

The problem is either the “not necessarily” part is wrong (in regard to flagging HTTP) or the criticism is directed at a fantasy that isn't actually occurring (in regard to flagging things that aren't .app). Either way, the criticism is defective.


Nope:

> 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

This is what patrickg_zill's comment said, just with some newlines and emphasis to make it more understandable. The not necessarily does not refer to HTTP, it refers to non-.app domains. And there is no "criticism is directed at a fantasy", there is a cynical prediction which is completely possible in all respects. You---or I---may think that that'll never be the reality, but regardless, that's what the comment said, and the other commenter misunderstood. I don't get why I get downvotes and criticism for this.


It still reads to me like they meant non-HTTPS connections, as that is what they mark insecure in concert with buying the .app domain.

They -could- have meant .app, but we'd need the guys word to know for sure. It's not as straightforward of a comment as you think it is.


That is probably because you want to understand it so. I give up, they completely meant HTTP vs. HTTPS...


I'm getting it from here:

> modifying their web browser to deliberately mark others' traffic as "Insecure"

I'm assuming the parent comment meant how Chrome marks HTTP connections as insecure; they're not marking TLD's that aren't .app as insecure.


I think the idea would be that Chrome would sooner or later mark non-HSTS sites like .app as 'half secure' or add a special extra greener bar for .app sites. Given Google's track record, I wouldn't really doubt it.


non-HSTS sites like .app

What?

add a special extra greener bar for .app sites

That would be really weird, considering that most Google sites are not .app, and would be quite a pain to change. Suddenly every competitor to their services get a special greener bar for a few bucks?


If I read correctly they meant the opposite, i.e. marked insecure if not .app.


And it won't take many registrations to recoup the investment. They're charging $999 / year at least for pre-registrations. I clicked through to the price using godaddy and the $16.99 / year price quickly got replaced by the higher number which also indicated that $1000 was the yearly renewal price if one gets the domain through pre-registration. (Your money gets refunded if you don't get the domain.) I'm sure godaddy gets a decent portion of the $1k, but damn.


That preregistration amount changes based on the domain you are trying to register. More popular terms cost significantly more.


also indicated that $1000 was the yearly renewal price if one gets the domain through pre-registration.

That's just on GoDaddy.

"EAP is a one-time acquisition fee; you do not pay that on subsequent renewal."

https://news.ycombinator.com/item?id=16971246


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.


An HTTPS-only web is very much in Google’s economic interest, as it vastly increases the barrier to entry of tracking users across the web, which is Google’s core business.


Anyone running a new TLD can make it HTTPS-only if they think that's something domain-buyers want

How does that work? I thought they needed cooperation from browser makers.

Edit: explained here: https://news.ycombinator.com/item?id=16968262


True, they will not get extra fees from sites running HTTPS.

However, they will get extra fees from any .app domain registrations.


Yes. How does the HTTPS stuff relate to that in a way that increases those?


> it is not necessarily

Sure, but labeling a site as “Possibly not secure” wouldn’t be a very effective way of communicating the risks to users.


> and reaps the fees

AFAIK Google does not have a monopoly on .app registrations:

https://get.app/


Google owns and operates the TLD.

Many registrars will sell .app names, but they pay a portion of every sale to Google.


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


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 pricing scheme guarantees that such sentimental value counts for zero in the "efficient allocation" measure.

Both of these seem pretty shitty to me.


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?


"Efficiently" is a concept defined only by your target. If your target is economic value, then, sure this kind of auction does a pretty good job at allocating efficiently with respect to it. If your target is something like desire-satisfaction, or promoting novelty/creative use, then it might be worth trying to think about ways to preferentially allocate to people willing to put in more effort too, or, e.g., introduce some kind of lottery system for some domains for non-commercial uses.


In what units do you measure "desire-satisfaction" and "promoting creative use"? How do you know that an outcome was optimal?


Without a system like this you don't get your quirky cat domain name, someone swoops in on minute 0 with a script and registers the top 1000 desirable domain names and squats them.

Anything that wouldn't have been swooped up by squatters will _also_ still be available when the early access period is over and everything is $20.


On the other hand this seems like a pretty decent way to prevent mass domain squatting, because screw those guys. I'm sure there are still some people doing complicated cost/benefit analyses and squatting strategically but I think it'll be much less rampant.


Why is (a) shitty?


what defines a domain name as premium?


A couple easy metrics: Existing brand names/trademarks, existing websites on other TLDs, and length of domain with additional weighting for actual words (maybe additional weighting based on word/tuple frequency in say the google books corpus).


Machine learning.

(Not joking.)


Took me a while to figure out that Google Domains isn't participating in the Early Access Program.

Apparently the "additional fee" for early access is extraordinarily high from some registrars.

For example -> https://imgur.com/a/E9WRqTI


The Early Access Period is a descending price ("Dutch") auction. The fee will decrease every day at 16:00:00 Z for the first four days throughout the week-long period.


Is there a list of which registrars are participating in the early access period? None of the ones I tried seemed to recognize .app.


See https://www.registry.google/about/register.html -- the ones supporting EAP are annotated as such.


Ah, looks like the registrars were still coming online when I tried. When I first tried Gandi, it didn't seem to like .app, but now it does and lets me choose "landrush," which I assume is the way to buy a domain during the EAP.


hexonet.net does.

$11,080

then $3,205

$1,625

$1,130

$690

$580

This sucks. This is like, truly evil.

There's two hard problems:

Naming things

Cashing [sic] : Paying for the right to name things


It's only for the current early access period, so if you don't have a named project already I'd suggest just waiting for the period to end then your pricing is steady. We know how to design good auctions but I'm not sure there's any design that'll be kind to purchasers who can't easily evaluate the value of the item to them while still meeting other more basic goals.


the actual two hard problems are cache invalidation and naming things, but cash invalidation doesn't quite fit into that :-P


I just tried to buy one. Got an email saying I'd be invoiced on allocation of that domain to the registrar. WTF does that mean? How can they take my money if they don't even know they'll have the domain to sell?


I believe that, as a general policy, registrars refund your money if they don't actually manage to acquire the domain name on your behalf.


"on allocation" means if/when they acquire it themselves to assign to you. If that doesn't happen, you don't get invoiced.


webnames.ca says "If the domain cannot be registered on your behalf for any reason, there will be no cost to you."


have you checked other registars? it's about 20eur on gandi.

https://shop.gandi.net/en/domain/suggest?search=whatthefucki...


Cheers for this link.

Taking recommendations for what to do with my new domain, donaldtrump.app


It's $15 after early access ends on yay.com


This might be a good litmus test to see which registrars look out for their customers.


I'd be pretty uncomfortable basing my online identity on a domain where the registrar is already picking which web standards do and don't work.


Barely related question: does Google plan to deploy the .google gTLD for use in its services, i.e. will mail.google.com become mail.google, and drive.google.com change to drive.google just like they did for blog.google and registry.com?


I think they’d like to possibly but there are concerns. I have had trouble with vanity tlds and I can imagine with google being so ubiquitous, there could be so many issues.

And also security. I know there’s an implicit trust of .com and so I wonder if seeing just google will lead to people thinking it’s safer. I have Metcalfe.rocks and more than once I’ve had people try Metcalfe.rocks.com


The funny thing about their blogs is that many of em are still on the regular domain. I'd imagine there's many hurdles in migrating so many large services, and there's barely any benefits to doing so. In addition, I'm not sure if all their supported legacy browsers can even handle gTLDs.

If I were in their position I'd probably use it for new deployments, with a low priority task for evaluating the possibility of migrating existing systems.


Arbitrarily picking web standards seems like an abuse of power. If this is the direction in which they want the internet to steer (a great one as far as I’m concerned) Google should advocate for the deprecation of HTTP in the appropriate bodies instead though.

It baffles me that TLDs are at the mercy of private companies... I guess I should read more about the history of the internet to understand how this came to be.

Finally, maybe the management of authoritative DNS is one of the few applications for which a blockchain could actually make sense. Still pondering on the specific model though, does anybody know of existing projects in this direction?


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?


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

uh... don't do that?

if you're developing locally or internally, use my.app.local or workstation-1.building.internal. If you want to use public domains for non-public things i guess go ahead, but you can't expect everybody else to support your weird thing. Or if you really need to run your internal dev stuff on public domains, get a certificate for it.



Well, disabling HSTS is a badidea as long as the logical (or legal) entity creating the subdomain is the same one that enforces HSTS, which was the case up until this point, (in that being the same entity they know which subdomains need HSTS and which ones don't).


Anyone registering a .app domain knows it will have HSTS, so they feel it's appropriate for their site to use it.


Arbitrarily across an entire TLD.

Because IANA decided to start selling off the web for companies to abuse.

> What if I want to use local.my.app for development;

You can switch to .dev... oh right.


RFC-6761 [1] reserves .example, .invalid, .localhost, and .test — the latter two seem like nice alternatives.

[1]: https://tools.ietf.org/html/rfc6761


What makes .net OK but .app is "selling off the web"? I mean, besides traditionalist conservatism?


> Google should advocate for the deprecation of HTTP in the appropriate bodies instead though

I agree with your larger point. For instance, I believe Google purposefully avoided implementing some privacy-preserving features in its QUIC protocol.

However, in this case, it was the ISPs and wireless carriers that fought against deprecating HTTP, while Google and Mozilla wanted to deprecate it. It's why I think they only enabled the HTTPS version of HTTP/2 in their browsers. The carriers and ISPs wanted the web to stay on HTTP so they can mine everyone's data, as they're already doing with the sites that have remained on HTTP.


How about namecoin ? You can use it to buy .bit domains, but ICANN doesn't recognize those, so users need a special addon to access .bit websites.


> does anybody know of existing projects in this direction?

namecoin


In case someone is wondering about availability:

https://www.registry.google/

Here are the important dates to be aware of in 2018:

Mar 29 - May 1: Trademark holders can register .app domains (known as the "Sunrise" period).

May 1 - May 8: Anyone can register available .app domains for an extra fee (known as the "Early Access" period).

May 8 and onwards: Anyone can register available .app domains (known as “General Availability").


Anyone know of any registrars supporting the early access registration? My usual haunts all say they don't support .app


Have a look at the list against .app with 'EAP' against their names:

https://www.registry.google/about/register.html


Getting out a hotfix on uniregistry.com right now... Typically our pricing is very competitive, but haven't checked the markup on these. Sorry about the self-promotion. Edit: EAP is live.


I registered our (trademarked) .app through 101domain 2 weeks ago. And I believe GoDaddy also supports Early Access (with better prices).


Confirmed that gandi.net does support it


That must have been a just-missed thing - I checked Gandi just before my post


And note that all transitions between phases occur at 16:00:00.000 Z.


Excellent, this will surely cause no confusion with macOS executables.


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.


I remember when I first started hearing about the web (around circa 95) and I was playing alot with DOS thinking that the two were connected.


Just like .sh didn't cause confusion with the .sh extension for shell scripts.


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.


Why would that be unnecessary? Are we supposed to use extension-less filenames and then guess their type every time by looking at their content?


Should URLs end in .html?


Web servers respond to your requests stating what type of content they’re sending you. There’s no such thing for files on disk.



File is still only a best guess at content and relies on the format being known and having some identifying features.


It works with shell scripts.

Having a name ending in '.sh' is less reliable than the output of file for identifying shell scripts, since any file can be named with that ending.

cat199 said '.sh' is unnecessary and that is correct. I am surprised that this is controversial. (except wait, no, this is the internet... I'm not surprised. ;-)


> It works with shell scripts.

No. It works with some of them, because, as the parent wrote, it’s just the automated equivalent of "let’s look at content of the file and guess what it is". It’s not perfect, and so doesn’t always work. If you write "echo 42" in a file, `file` will only tell you it’s "ASCII text".

We humans are used to identify things with their name. `.sh` is not necessary to execute a shell script; but it’s so convenient you must have a good reason not to use it.


There are over a hundred shell scripts in my /usr/bin/ dir that don't end in '.sh'. There are even Python scripts in there that don't end in '.py'. The world hasn't gone mad?

Ending the filename of a shell script in '.sh', while a useful and common convention, is unnecessary (I appreciate you that you acknowledge that) so using that to identify shell scripts is a heuristic, just like what file does.

Look, I don't want to argue about this. cat199 was catching downvotes for pointing out, quite correctly, that the '.sh' extension was just a convention, and, well... https://www.xkcd.com/386/

Filename extensions have always been a crappy hack to get around the omission of useful metadata associated with a file on some early filesystems. Gnome file viewer thing doesn't even sort by them!


I think it's used for UX reasons actually.. "Oh, I see this is a shell script" when listing a directory..


It's not. It helps you find stuff.


I'm not sure how a .app TLD could be mistaken for a .app executable.


You severely overestimate the technical skill of the average user. And even people who know their way around computers rely heavily on patterns in order to identify relationships, so a strong pattern without an underlying relationship is, of course, going to lead to confusion.


The average user has no idea that the .app file extension even exists. macOS does not expose it in Finder.


Referring to Mac applications as "Mail dot app" is a thing that only geeks do in the first place.


Average user is able to learn.

gsich on May 1, 2018 [flagged]

I see, the downvote confirms the truth.


Please don't do this here; the site guidelines ask you not to:

https://news.ycombinator.com/newsguidelines.html


Apple Finder (magnify glass in top right) by default will search both local executables on your computer, and (as a second best option) the net. If a user sees *.app in finder, they might be very well getting something they don't expect.


Files vs. URLs. Windows-Users had it similar with .com.


evil.co/malware.app


Just like .com and windows executables, eh?


Why is Google launching a TLD and you cannot purchase it through Google Domains?

It's currently showing as "Not Supported" even though they link to Google Domains from get.app.

It's mind-boggling to think they couldn't come up with a "coming soon" blip if somebody tries to look up a Google-owned TLD on Google Domains.


From another post in this thread, ICANN rules prevent the two from coordinating.


Mandatory HTTPS? This discussion from 2 days ago seems relevant: https://news.ycombinator.com/item?id=16951831


> HTTPS is required to connect to all .app websites, helping protect against ad malware

Can somebody explain this claim? How does HTTPS protect against malware? Does no malware use HTTPS, so it all gets blocked?


It doesn't. They are likely referring to some malware attack vectors that rely on hijacking local DNS or routing between the web browser and the server (eg, at your coffee shop wifi, or your ISP injecting junk into the HTTP stream), and requiring HTTPS makes such attacks a little bit harder. But there are plenty of other ways to send "ad malware" to browsers that work just fine over HTTPS. And as for ISPs, they could easily (in some places, they likely do, and someday most probably will) require you to install their own custom certs in your trusted store and MITM all your web traffic. TLS 1.3 tried to work around this threat as well, but enterprise security people who "need" to monitor all traffic in and out of their network blew that up. But your browser will show a green lock icon, so it's fine.


Keyword here is "helping". It's only reducing the probability to get a malware.


Is google domains not taking preorders? It says the .app extension is not supported.


This was ironic to me too. I had to preorder app domains from a third party called Marcaria. 101domain supports it as well.


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.


Ted, any reason why you don't permit pasting the 2-factor auth code into the input box?


trust me, it's on the backlog to fix.


Is everything on the backlog? Still not supporting long DKIM keys. Still using deprecated and discouraged SMS as 2factor. Are your margins really that thin? It's been years :(


> It's been years :(

Check out this older thread from 2014: https://news.ycombinator.com/item?id=8254757

"We're rolling out Google Authenticator support sometime in the fall." What happened? :(


We introduced an alternative to 2FA SMS - Authy OneTouch. We're working on adding TOTP as well.


Hey Ted, since you're here, may I please suggest that the future implementation of 2FA not require a separate app? Even though Namecheap is using Authy OneTouch, it still requires a dedicate app, which is unnecessary. Thanks.


We partnered with Authy/Twilio on this integration to try something new. Totally get that we need additional options.


Thanks for the reply Ted. Looking forward to something more standardised!


Just wanna give a quick +1 to this request. The lack of proper 2FA is one of my complaints as well.

Authy OneTouch pushes you towards some fairly strong platform and vendor lock-in, which I always try to avoid.


Great, thanks.


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.


Preregistrations don't really mean anything. We only do GA launches, which is on May 8.


Please get google to add you to https://www.registry.google/about/register.html

Lots of registrars are in there that aren't part of the Early Access Program.


Thanks. Definitely will.


So would someone be able to register on namecheap and have a chance at a .app domain against someone that used priority pre-registration at godaddy?


The GoDaddy thing is basically, "Pay us extra and we'll click for you automatically on May 8th." It's like paying Southwest Airlines $15 to check you in right at t-minus 24 hours before your flight...


Not exactly. Their Early Access Program actually guarantees you the name but the price point is higher.


They say they will completely refund you if you don't get the domain.


Not from what I see. It's listed as "Early Registration Fee (non-refundable)" in the cart.


I bet all registrars are stoked when any new gTLD comes out, that auction and "valuable word"-based system must bring loads of cash. This one of the most outrageous, user-hostile things I've ever seen. It only preys on the need for brands to protect themselves while bringing no value and only confusion to end-users.


I definitely wouldn't say "loads of cash." .Com is still a very major part of any registrar's business. However, I like when new registries try new things that go beyond the namespace - requiring HTTPS could have a meaningful impact. Completely disagree that it's user-hostile — there are far fewer registration options in .com so opening up a new namespace gives users more flexibility in what they can register.


I just went onto one of the EAP registrars website and spoke with a 'domain consultant'.

This individual assured me for today our available .app domain can be registered and fully usable for $11999. Tomorrow the price goes down to $2999 or something like that.

How is this possible if Landrush is only a preregistration expression of interest?


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: