54 ms·

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

395 points by daniel-alex 8y ago

runnr_az 8y ago
Any plans to support IDNs?
dmart 8y ago
Excellent, this will surely cause no confusion with macOS executables.
- ryannevius 8y ago
  I'm not sure how a .app TLD could be mistaken for a .app executable.
  - sakuronto 8y ago
    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.
    - untog 8y ago
      The average user has no idea that the .app file extension even exists. macOS does not expose it in Finder.
    - gsich 8y ago
      Average user is able to learn.
      - gsich 8y ago
        I see, the downvote confirms the truth.
        dang 8y ago
        Please don't do this here; the site guidelines ask you not to: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - JeremyBanks 8y ago
      Referring to Mac applications as "Mail dot app" is a thing that only geeks do in the first place.
  - sam_goody 8y ago
    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.
- hyder_m29 8y ago
  Just like .com and windows executables, eh?
- sinatra 8y ago
  Just like .com didn’t cause confusion with DOS and Windows .com executables.
  - raimue 8y ago
    Just like .sh didn't cause confusion with the .sh extension for shell scripts.
    - adtac 8y ago
      Except, .sh means nothing in particular in Linux. It just so happens people use .sh for shell scripts.
      - cat199 8y ago
        It just so happens people unnecessarily use .sh for shell scripts.
        sbarre 8y ago
        I think it's used for UX reasons actually.. "Oh, I see this is a shell script" when listing a directory..
        hk__2 8y ago
        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?
        carapace 8y ago
        Should URLs end in .html?
        hk__2 8y ago
        Web servers respond to your requests stating what type of content they’re sending you. There’s no such thing for files on disk.
- gsich 8y ago
  Files vs. URLs. Windows-Users had it similar with .com.
- aussieguy123 8y ago
  evil.co/malware.app
dmurray 8y ago
> 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.
- CydeWeys 8y ago
  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-secure-more-of-web.html 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.
  - spronkey 8y ago
    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...
ted0 8y ago
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.
- uptown 8y ago
  Ted, any reason why you don't permit pasting the 2-factor auth code into the input box?
  - ted0 8y ago
    trust me, it's on the backlog to fix.
    - uptown 8y ago
      Great, thanks.
    - tokyodude 8y ago
      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 :(
      - ted0 8y ago
        We introduced an alternative to 2FA SMS - Authy OneTouch. We're working on adding TOTP as well.
        et-al 8y ago
        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.
        ted0 8y ago
chatmasta 8y ago
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.
- hyder_m29 8y ago
  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.
- snarfy 8y ago
  How does that work in say, Firefox?
  - CydeWeys 8y ago
    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.
  - detaro 8y ago
    Exactly the same, the preload list data is public and used by all the major browsers.
    - chatmasta 8y ago
untog 8y ago
The defining feature here seems to be HSTS - all .app domains will connect via HTTPS by default, and never try HTTP. Which is nice. Otherwise... eh. In theory this becomes a home for web sites specifically related to apps. Certainly that seems to be what Google are suggesting. But are web apps "apps"? Is this native only? Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? (spoiler: no). So it's just another TLD, really.
- 0xCMP 8y ago
  If they're PWAs they get really close to being apps. Seems like Google is making a big push in Chrome and Android to provide that App experience for websites which do the work to support it.
- WorldMaker 8y ago
  > But are web apps "apps"? Both Google and Microsoft are both strongly in the "Yes" category here and are heavily pushing PWAs as a future of many types of apps. If a lot of PWAs also want to use .app as their TLD, that serves Google's purposes just fine, I'd imagine. > Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? Where's the creativity in that? The internet decided a long time ago that it would rather do interesting things with TLDs than strictly enforce them; use the origins and "purpose" of a TLD as a loose guideline. What's the harm in a restaurant deciding that .app fits their brand because they have the best apps (appetizers) in town? Is it any worse than all the startups that have been using Chagos' country TLD .io without having anything to do with the atoll of Chagos? (Which of course is made worse by the funds from .io going to British corporate colonialists rather than directly to benefit anyone in Chagos. How many startups even think of that when paying for their hip domain name?)
  - MichaelGG 8y ago
    Would Chagos get .io if it wasn't British Indian Ocean Territory?
    - WorldMaker 8y ago
eganist 8y ago
Moves like this intrigue me. On the one hand, I support creating new platforms with security built-in by default, but on the flip side, the Chrome team just axed HPKP without even so much as bothering to try to refine it to mitigate the footguns. I don't understand how the web-facing security decisions at Google are made. :/
- ovao 8y ago
  There are motivating reasons for that[0]. The Expect-CT header is its replacement, and is getting picked up by recent versions of Chrome. [0]: https://scotthelme.co.uk/im-giving-up-on-hpkp/ https://scotthelme.co.uk/im-giving-up-on-hpkp/
  - eganist 8y ago
    Yep. I contributed rather substantially to one of those reasons with a talk on abuse cases for hpkp at defcon two years back. I'm still disappointed. I don't feel expect-ct effectively covers the same use cases.
thedangler 8y ago
So what registrars are taking part Early Access Program?
- CydeWeys 8y ago
  See the list here: https://www.registry.google/about/register.html https://www.registry.google/about/register.html
stevoski 8y ago
What's the pricing? I couldn't find this info on the site.
- CydeWeys 8y ago
  We aren't (and cannot) sell directly to end users. Every domain name registrar sets its own price.
- asaph 8y ago
  On GoDaddy at least, pricing seems to vary by domain name. beer.app is $1,999.99 while hackernews.app is $16.99. You can check pricing on individual .app domains here: https://www.godaddy.com/tlds/app-domain https://www.godaddy.com/tlds/app-domain Edit: It appears this pre-registration doesn't even guarantee you'll get the domain. It just increases your chances :( I'm gonna pass...
  - VikingCoder 8y ago
    Yeah, this isn't Early Access. :(
  - jmelloy 8y ago
    How would it? Godaddy can't buy the domain until General Availability, so they can't guarantee that you'll get it. Someone else could buy it first.
dumbmatter 8y ago
Mandatory HTTPS? This discussion from 2 days ago seems relevant: https://news.ycombinator.com/item?id=16951831 https://news.ycombinator.com/item?id=16951831
thisisit 8y ago
In case someone is wondering about availability: https://www.registry.google/ 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").
- CydeWeys 8y ago
  And note that all transitions between phases occur at 16:00:00.000 Z.
- corobo 8y ago
  Anyone know of any registrars supporting the early access registration? My usual haunts all say they don't support .app
  - vincentmarle 8y ago
    I registered our (trademarked) .app through 101domain 2 weeks ago. And I believe GoDaddy also supports Early Access (with better prices).
  - rdrey 8y ago
    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.
  - _zie 8y ago
    Confirmed that gandi.net does support it
    - corobo 8y ago
      That must have been a just-missed thing - I checked Gandi just before my post
  - 8y ago
ihuman 8y ago
Is google domains not taking preorders? It says the .app extension is not supported.
- warent 8y ago
  This was ironic to me too. I had to preorder app domains from a third party called Marcaria. 101domain supports it as well.
fulafel 8y ago
How does this work technically? What prevents use of plaintext http on these domains? The preloading seems like a browser specific feature.
- gsich 8y ago
  It is only enforced by the browser. So curl and similar stuff still works. But on a sidenote: Why shouldn't it. It is just a domain, whatever is running on the resolving IP address is up to the server administrator.
- seabrookmx 8y ago
  I don't think there's anything stopping you from using plain http when _not_ using a browser, such as through a server-side http client or a random python script you could whip up in 2 minutes. From what I can tell, the only enforcement is this gentleman's agreement between the browsers.
- therealmarv 8y ago
  HSTS can be enabled for whole domain. See here: https://hstspreload.org/#tld https://hstspreload.org/#tld General information about HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security But you are right that it is a browser thing.
koolba 8y ago
If there's anyone with an x-rated business idea, f.app is available though it's marked as a "premium" domain, likely due to the single letter. It'll cost you a cool $1,790.88/year. I wonder how much of that goes to Google.
- ratsimihah 8y ago
  I mean, what kinda of app want's to be called Fapp for $1500+/yr?
  - always_good 8y ago
    An app that wants a memorable domain.
    - solarkraft 8y ago
      But all the success stories just post a simple intro to their apps (actually available on Android/IOS app stores) on their sites. Not valuable.
    - russh 8y ago
      Well I'm out, Cr is already taken.
      - ratsimihah 8y ago
        Well crap
panarky 8y ago
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 https://imgur.com/a/E9WRqTI
- CydeWeys 8y ago
  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.
  - lambda 8y ago
    Is there a list of which registrars are participating in the early access period? None of the ones I tried seemed to recognize .app.
    - VikingCoder 8y ago
      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
      - khc 8y ago
        the actual two hard problems are cache invalidation and naming things, but cash invalidation doesn't quite fit into that :-P
      - rtkwe 8y ago
        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.
    - 8y ago
ahmedfromtunis 8y ago
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?
- pducks32 8y ago
  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
- TheAceOfHearts 8y ago
  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.
superkuh 8y ago
HSTS seems to require the website to conform to what google defines as 'Serve a valid certificate.' Does this mean that self-signed certs will not be acceptable for a .app domain and centralized certificate authorities will be required?
- CydeWeys 8y ago
  Validity of SSL certificates is enforced by web browsers. If you choose to allow your self-signed certs in your browser then it will work for you, though of course not for other people.
rebelde 8y ago
> 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?
- skywhopper 8y ago
  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.
- l9k 8y ago
  Keyword here is "helping". It's only reducing the probability to get a malware.
enzanki_ars 8y ago
https://blog.google/topics/developers/introducing-app-more-secure-home-apps-web/ https://blog.google/topics/developers/introducing-app-more-s... It may just be on my end, but attempting to access the page using www.blog.google does not work, but blog.google works. The link may need to be changed... > nslookup www.blog.google Non-authoritative answer: Name: ghs-svc-https-sni.ghs-ssl.googlehosted.com Addresses: 2607:f8b0:4009:80b::2013 172.217.8.179 Aliases: www.blog.google > nslookup blog.google Non-authoritative answer: Name: blog.google Addresses: 2001:4860:4802:38::15 2001:4860:4802:32::15 2001:4860:4802:36::15 2001:4860:4802:34::15 216.239.32.21 216.239.36.21 216.239.38.21 216.239.34.21
dberg 8y ago
Does GoDaddy refund if you dont get the domain ? EDIT: Found the FAQ - Does pre-registering a domain guarantee I'll get it? No. Pre-registering reserves your place in our queue for that domain. The instant the registration phase opens, we'll submit our list of registrations electronically. If you don't get the domain you've pre-registered, we'll refund the cost of the registration. Any application fees are non-refundable however.
- scosman 8y ago
  Is the "Early Registration Fee" considered a "cost of registration" or "application fee"? It's listed as "Early Registration Fee (non-refundable)" in the cart.
guessmyname 8y ago
Here is a small script for the Terminal lovers. #!/bin/bash DOMAIN="${1:-google}" RESPONSE=$( curl -XGET -s \ -H "Accept-Language: en-us" \ -H "Accept: */*" \ -H "Connection: keep-alive" \ -H "Host: domain-registry.appspot.com" \ -H "Origin: https://get.app" \ -H "Referer: https://get.app/" \ -H "User-Agent: Mozilla/5.0 (KHTML, like Gecko) Safari/537.36" \ "https://domain-registry.appspot.com/check?domain=${DOMAIN}.app" ) echo "$RESPONSE" | sed "s/{\"/{\"domain\":\"${DOMAIN}.app\",\"/g"
- hk__2 8y ago
  Simpler: $ curl -sL https://domain-registry.appspot.com/check?domain=$DOMAIN.app {"status":"success","available":true,"tier":"standard"}
tenaciousDaniel 8y ago
Still waiting for them to release the .dev domains
- skunkworker 8y ago
  Everyone that has been using that for local development agrees. Though the writing on the wall has been there for awhile - https://iyware.com/dont-use-dev-for-development/ https://iyware.com/dont-use-dev-for-development/
- sixdimensional 8y ago
  .. and I am still waiting for .ing personally.
- CydeWeys 8y ago
  Me too, Dan. Me too.
limeblack 8y ago
Not surprisingly Google has already prevented registration(pre pre registration) of anything related to their services alphabet[1], chrome[2], chromeos[3], etc... I guess you can do whatever you want when you own the domain extension. [1] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=alphabet.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain... [2] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain... [3] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
- majewsky 8y ago
  Not sure why this is surprising to you. Of course I'll protect against namesquatting if I have the right to first dibs.
- QasimK 8y ago
  > Mar 29 - May 1: Trademark holders can register .app domains (known as the "Sunrise" period).
tomc1985 8y ago
Three arbitrary letters in a list of TLDs and they call it "innovation"...
- carussell 8y ago
  Did you fabricate a quote? (And if so, why?) Neither "innovation" nor any derivatives of "innovate" appear in this post.
sabertoothed 8y ago
It is very strange. 101domains wanted to charge me ~13,000 USD for a domain / year. gandi, however, allowed me to purchase it (the same domain!) for ~650 GBP / year. What is going on?
- the4004 8y ago
  I noticed this too. Has the domain actually been registered with Gandi yet? Maybe 13k gets you a fully registered domain, and the £650 is like buying an option or a chance to be in the running.
  - sabertoothed 8y ago
    Gandi was super intransparent about the phase and what they are actually selling. Indeed, Gandi did not actually obtain the domain. But merely offered to try to bid with the money once the price of the domain reached that point where it was available for that price. In my case, that failed. The domain was purchased by someone else at a higher price. I now have to fight to get my money back into my bank account. Gandi made their life extra hard by not being fully transparent.
- jameslk 8y ago
  I would assume one is for early phase registration (101domains - May 1-7), and one is general registration (gandi - May 8). If the domain isn't registered in the early phase, you'll be in line to have it registered on May 8.
  - sabertoothed 8y ago
    It looks like it, indeed. I was confused because gandi and 101domains did not explicitly state the phase. And gandi took my money and deducted it from my account but apparently did not actually obtain the domain yet.
    - deleted 8y ago
      [deleted]
ocdtrekkie 8y ago
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.
IloveHN84 8y ago
Are already sex.app and dating.app registered?
- guessmyname 8y ago
  sex.app returns this "available: false, reason: in use". dating.app returns this "available: true, tier: premium"
  - ThatHNGuy 8y ago
    why is it premium?
    - kowdermeister 8y ago
      Because it says dating :) Registrars can device on a set of names the wish to withhold, they are usually dictionary names with great interest involved.
scarface74 8y ago
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.
- benologist 8y ago
  Later google will launch .ampp for apps that are certified to only have Google and their thousands of partners sharing your PII 'securely'.
  - therein 8y ago
    That honestly doesn't even sound like a joke. I'd believe it if you said that's a quote from the article.
  - _o_ 8y ago
    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.
- _bxg1 8y ago
  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.
- Andrex 8y ago
  ...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.
theandrewbailey 8y ago
What if I put my app's REST backend on my .app domain? Are .app domains only allowed to host brochureware?
- CydeWeys 8y ago
  The only restriction with .app domains is that HTTPS is enforced when connecting from a web browser. We definitely encourage you to use .app for more than mere brochureware, and of course we also encourage you to encrypt all APIs (REST or otherwise). This will be enforced by browsers if said APIs are being hit from a webpage.
z3t4 8y ago
Does this mean all request's will go via Google servers ? Like cloudflare ? Or how else would they enforce httpS ?
- timdavila 8y ago
  No. The TLD ".app" is on the HSTS preload list shipped with the browser, so the browser will only accept connections over SSL. It's up to you as the domain registrant to make sure your site supports it.
patrickg_zill 8y ago
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?
- nathantotten 8y ago
  > 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.
- ucaetano 8y ago
  > and reaps the fees AFAIK Google does not have a monopoly on .app registrations: https://get.app/ https://get.app/
  - timdavila 8y ago
    Google owns and operates the TLD. Many registrars will sell .app names, but they pay a portion of every sale to Google.
- detaro 8y ago
  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.
  - brlewis 8y ago
    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 https://news.ycombinator.com/item?id=16968262
laktek 8y ago
Finally! I've been waiting for this for the last 11 years http://www.laktek.com/2007/05/18/app-tld-for-web-applications/ http://www.laktek.com/2007/05/18/app-tld-for-web-application...
ashwinpp 8y ago
Note that most registrars participating in EAP or landrush charge a non-refundable fee, which is major chunk of the price increase from day 7 to day 1. It doesn't seem that there is "no cost" to participating in this period if one doesn't get the domain name.
dmitriid 8y ago
So, Google paid big bucks to secure a juicy top-level domain name. Now it says it's good because "hey, if you pay us money, we'll get you in our registry, call you secure, prominently display you in search (not now, but logical next step), and pretend it's all for great good and not to extend and protect our dominance". IANA's decision to expand and auction off to-level donations was a horrible idea.
komali2 8y ago
Get.app said the domain I want is available, but none of the linked websites said they supported that tld Edit: any recommendations for what to do with my new domain, donaldtrump.app?
- ohitsdom 8y ago
  Right beneath the domain available message should have been a note that these domains aren't available for purchase until May 8th.
- CydeWeys 8y ago
  Try more registrars, further up in the list.
simon_acca 8y ago
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?
- therealmarv 8y ago
  It's not arbitrarily. You can use the standard HSTS to be applied domain wide https://hstspreload.org/#tld https://hstspreload.org/#tld
  - simon_acca 8y ago
    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?
    - therealmarv 8y ago
      That's a bad idea but here you go https://stackoverflow.com/questions/44650854/how-to-disable-chrome-hsts-permanently-for-a-subdomain#comment85342255_49130998 https://stackoverflow.com/questions/44650854/how-to-disable-...
      - simon_acca 8y ago
        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).
peterwwillis 8y ago
Why can't they add a new URL scheme "secure://" to Chrome that will only support HTTPS? Adding a new scheme would support all existing https websites on the internet today with no need to pay anyone money or rush to reserve domains. This .app thing is needlessly difficult, and just a way for Google to push its brand on technology concepts en-masse, like the .dev fiasco. Now everyone in the world has to register a new domain (and make it work for their site) to make sure their URL is always secure.
- SahAssar 8y ago
  How would "secure://" differ from "https://" https://"?
  - peterwwillis 8y ago
    Most people don't know what https:// https:// means, and is often confused with http:// http://. Plus, https:// https:// has allowed people to do things like click through certificate warnings, which secure:// should never do. Finally, secure:// should require all standard best practices for the security of web apps, first simply by refusing to render obviously insecure sites, and then by requiring extra parameters.
peterbe 8y ago
I go to https://domains.google.com https://domains.google.com and search for my desired .app domain and it says "Google Domains does not support the .APP ending" :(
z3t4 8y ago
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.
- solarkraft 8y ago
  What if we just sell TLDs directly to consumers?
  - z3t4 8y ago
    I think it's important that any TLD is open for registration of domains. For example if Facebook bough .book they should need to allow others to register under it.
CydeWeys 8y ago
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 https://get.app and https://www.registry.google/about/register.html https://www.registry.google/about/register.html
- deleted 8y ago
  [deleted]
- paultopia 8y ago
z3t4 8y ago
I think this domain will be very popular as app means app in almost every language. I hope Google will do something about the domain snapping or all good names will be taken (and not used).
kiddico 8y ago
I was not aware .google was a tld. Can any company get a tld made? Who's even in charge of that sort of thing?
- notatoad 8y ago
  yes, any company willing to pay the application fee of $185k and able to pass a review as "capable" of operating a TLD can register a TLD. ICANN is in charge of it. https://newgtlds.icann.org/en/about/program https://newgtlds.icann.org/en/about/program
AngeloAnolin 8y ago
Just for fun, I tried these domain names via the url get.app: apple.app facebook.app instagram.app twitter.app ycombinator.app * snapchat.app * producthunt.app * whatsapp.app amazon.app microsoft.app google.app hotmail.app * dropbox.app intercom.app * pivotal.app * tesla.app dell.app ibm.app * * AVAILABLE
- itronitron 8y ago
  i call dibs on 'whats.app'
  - COil 8y ago
    haha, not available any more, this was the one to get indeed.
- domainhunter 8y ago
  Would I be sued (i.e is it legal?) if I buy some .app domains related to popular apps of my country and list their google play store and apple store link with some ads on those domains?
  - therealmarv 8y ago
    If your intention is to make some money and they have trademarks and already existing similar domains you are not acting legal! There were other people who already had the same thought as you... they failed!
6031769 8y ago
1. Register a .app domain 2. Serve content from it via HTTP only 3. Market it as the new dark web 4. ... 5. Profit!
dvfjsdhgfv 8y ago
Why on earth should I do it? Give me one good reason; enforcing HTTPS doesn't count as one. And yet, it seems like HN crowd is queuing o buy these... Are you planning to get them so that you can sell them at a higher price later? What makes you think this product of Google does better than Google+?
segmondy 8y ago
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.
- s2g 8y ago
  Makes sense, given their mission to monopolize the internet. Break up google.
- brlewis 8y ago
  Is there any precedent for a TLD owner doing what you describe? I think this is HSTS preload and nothing more.
  - CydeWeys 8y ago
    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.
  - dingo_bat 8y ago
    Yes: http://www.cbsnews.com/news/daily-stormer-being-dumped-by-godaddy-apparently-seized-by-anonymous/ http://www.cbsnews.com/news/daily-stormer-being-dumped-by-go... https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stormer-because-of-what-it-wrote-about-charlottesville-victim.html https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stor...
    - edem 8y ago
      They violated terms of use. What's the problem?
      - dingo_bat 8y ago
magoon 8y ago
This is confusing because Mac apps literally end in that extension, and if I say Messages.app you would know what I mean. Also, if I say “dingus dot app” it confuses people because that’s not a mobile app, it’s a site or web app.
- askvictor 8y ago
  Old DOS executables (actually, commands) (which still run on Windows) ended in .com ; there was an overlap with the Internet when they were still quite common (command.com was how you started a command prompt on windows 95), and no-one seemed to get confused
  - magoon 8y ago
    This is a fair & fun point, however maybe a bit of a stretch to compare here; DOS binaries were almost all .EXE well into DOS 3.x, which was many generations before Windows 95. I would say the exception to that had been command.com
JasonSage 8y ago
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.
- icebraining 8y ago
  From another post in this thread, ICANN rules prevent the two from coordinating.
jest3r1 8y ago
Starting today at 9:00am PDT and through May 7, .app domains are available to register as part of our Early Access Program, where, for an additional fee, you can secure your desired domains ahead of general availability. Additional fee: hackernews.app is available! CA $25.72 per year (pre-registration) CA $16,082.01 (early access) Helluva fee. https://www.name.com/preorder/app?domain=hackernews.app&tld=app https://www.name.com/preorder/app?domain=hackernews.app&tld=...
makecheck 8y ago
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.
- CydeWeys 8y ago
  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=7ac8be59-1ecc-4d90-aea5-e62deab5ee7f https://events.google.com/io/schedule/?section=may-8&sid=7ac...
fiatjaf 8y ago
Why do we have TLDs at all? If ANY COMBINATION OF LETTERS is now a TLD, we should be able to register myname.whatever if I want to, or in fact just whatever as a domain. Ok, ok, I'll pay GOOGLE, the owner of the internet, for doing this now.
keyle 8y ago
Seen on name.com... https://imgur.com/kYyNQQg https://imgur.com/kYyNQQg ?!
pknerd 8y ago
so a web based product can be called an _app_ and get hosted for a certain *.app domain?
koyao 8y ago
Why does "his.app" cost $499.99 for pre-registration, but "her.app" only costs $249.99? :) Is this some built-in gender bias?
- kiproping 8y ago
  Christ!
- friend-monoid 8y ago
  It's a bidding war. Someone already bid 249.99 for "his.app". Next step up is 499.99. If you buy her.app for 249.99, then both will cost 499.99.
- domainhunter 8y ago
  I am new to domain trading. I have one question - Would I be sued (i.e is it legal?) if I buy some .app domains related to some popular apps of my country and list their google play store and apple store link with some ads on those domains?
  - icebraining 8y ago
    I don't know if it's illegal, but unless you have a trademark on those names, you're almost certain to lose them.
kahnpro 8y ago
No, Google. Just no.
odammit 8y ago
Registration opens May 8th. I went through a few of the registrars and got error messages that the TLD wasn’t supported. Godaddy of course has a solidly gouging pre-registration price. Set an alarm to park park park. Edit: Godaddy isn’t straight up gouging. Seems like dictionary words are much more expensive than made up words or non-dictionary brand names. Name.com somehow has a “buy it now” option in the 10k+ range. Curious how that works.
- runnr_az 8y ago
  .app is in the sunrise phase right now -- I think all the registrars pay the same wholesale rate and it's possible that the actual price is set as well. It'll drop to the regular price on 5/8.
- odammit 8y ago
  If you are looking to park an obvious bell-ringer it looks like just about every Fortune 500 has already had their domains pre-registered. Even McDonalds.app is registered. Happy hunting.

395 points by daniel-alex 8y ago

runnr_az 8y ago

Any plans to support IDNs?

dmart 8y ago

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

ryannevius 8y ago
I'm not sure how a .app TLD could be mistaken for a .app executable.
- sakuronto 8y ago
  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.
  - untog 8y ago
    The average user has no idea that the .app file extension even exists. macOS does not expose it in Finder.
  - gsich 8y ago
    Average user is able to learn.
    - gsich 8y ago
      I see, the downvote confirms the truth.
      - dang 8y ago
        Please don't do this here; the site guidelines ask you not to: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - JeremyBanks 8y ago
    Referring to Mac applications as "Mail dot app" is a thing that only geeks do in the first place.
- sam_goody 8y ago
  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.
hyder_m29 8y ago
Just like .com and windows executables, eh?
sinatra 8y ago
Just like .com didn’t cause confusion with DOS and Windows .com executables.
- raimue 8y ago
  Just like .sh didn't cause confusion with the .sh extension for shell scripts.
  - adtac 8y ago
    Except, .sh means nothing in particular in Linux. It just so happens people use .sh for shell scripts.
    - cat199 8y ago
      It just so happens people unnecessarily use .sh for shell scripts.
      - sbarre 8y ago
        I think it's used for UX reasons actually.. "Oh, I see this is a shell script" when listing a directory..
      - hk__2 8y ago
        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?
        carapace 8y ago
        Should URLs end in .html?
        hk__2 8y ago
        Web servers respond to your requests stating what type of content they’re sending you. There’s no such thing for files on disk.
gsich 8y ago
Files vs. URLs. Windows-Users had it similar with .com.
aussieguy123 8y ago
evil.co/malware.app

dmurray 8y ago

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

CydeWeys 8y ago
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-secure-more-of-web.html 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.
- spronkey 8y ago
  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...

ted0 8y ago

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.

uptown 8y ago
Ted, any reason why you don't permit pasting the 2-factor auth code into the input box?
- ted0 8y ago
  trust me, it's on the backlog to fix.
  - uptown 8y ago
    Great, thanks.
  - tokyodude 8y ago
    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 :(
    - ted0 8y ago
      We introduced an alternative to 2FA SMS - Authy OneTouch. We're working on adding TOTP as well.
      - et-al 8y ago
        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.
        ted0 8y ago

chatmasta 8y ago

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.

hyder_m29 8y ago
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.
snarfy 8y ago
How does that work in say, Firefox?
- CydeWeys 8y ago
  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.
- detaro 8y ago
  Exactly the same, the preload list data is public and used by all the major browsers.
  - chatmasta 8y ago

untog 8y ago

The defining feature here seems to be HSTS - all .app domains will connect via HTTPS by default, and never try HTTP. Which is nice. Otherwise... eh. In theory this becomes a home for web sites specifically related to apps. Certainly that seems to be what Google are suggesting. But are web apps "apps"? Is this native only? Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? (spoiler: no). So it's just another TLD, really.

0xCMP 8y ago
If they're PWAs they get really close to being apps. Seems like Google is making a big push in Chrome and Android to provide that App experience for websites which do the work to support it.
WorldMaker 8y ago
> But are web apps "apps"? Both Google and Microsoft are both strongly in the "Yes" category here and are heavily pushing PWAs as a future of many types of apps. If a lot of PWAs also want to use .app as their TLD, that serves Google's purposes just fine, I'd imagine. > Are Google going to be actively monitoring these to make sure the content is related to the .app TLD? Where's the creativity in that? The internet decided a long time ago that it would rather do interesting things with TLDs than strictly enforce them; use the origins and "purpose" of a TLD as a loose guideline. What's the harm in a restaurant deciding that .app fits their brand because they have the best apps (appetizers) in town? Is it any worse than all the startups that have been using Chagos' country TLD .io without having anything to do with the atoll of Chagos? (Which of course is made worse by the funds from .io going to British corporate colonialists rather than directly to benefit anyone in Chagos. How many startups even think of that when paying for their hip domain name?)
- MichaelGG 8y ago
  Would Chagos get .io if it wasn't British Indian Ocean Territory?
  - WorldMaker 8y ago

eganist 8y ago

Moves like this intrigue me. On the one hand, I support creating new platforms with security built-in by default, but on the flip side, the Chrome team just axed HPKP without even so much as bothering to try to refine it to mitigate the footguns. I don't understand how the web-facing security decisions at Google are made. :/

ovao 8y ago
There are motivating reasons for that[0]. The Expect-CT header is its replacement, and is getting picked up by recent versions of Chrome. [0]: https://scotthelme.co.uk/im-giving-up-on-hpkp/ https://scotthelme.co.uk/im-giving-up-on-hpkp/
- eganist 8y ago
  Yep. I contributed rather substantially to one of those reasons with a talk on abuse cases for hpkp at defcon two years back. I'm still disappointed. I don't feel expect-ct effectively covers the same use cases.

thedangler 8y ago

So what registrars are taking part Early Access Program?

CydeWeys 8y ago
See the list here: https://www.registry.google/about/register.html https://www.registry.google/about/register.html

stevoski 8y ago

What's the pricing? I couldn't find this info on the site.

CydeWeys 8y ago
We aren't (and cannot) sell directly to end users. Every domain name registrar sets its own price.
asaph 8y ago
On GoDaddy at least, pricing seems to vary by domain name. beer.app is $1,999.99 while hackernews.app is $16.99. You can check pricing on individual .app domains here: https://www.godaddy.com/tlds/app-domain https://www.godaddy.com/tlds/app-domain Edit: It appears this pre-registration doesn't even guarantee you'll get the domain. It just increases your chances :( I'm gonna pass...
- VikingCoder 8y ago
  Yeah, this isn't Early Access. :(
- jmelloy 8y ago
  How would it? Godaddy can't buy the domain until General Availability, so they can't guarantee that you'll get it. Someone else could buy it first.

dumbmatter 8y ago

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

thisisit 8y ago

In case someone is wondering about availability: https://www.registry.google/ 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").

CydeWeys 8y ago
And note that all transitions between phases occur at 16:00:00.000 Z.
corobo 8y ago
Anyone know of any registrars supporting the early access registration? My usual haunts all say they don't support .app
- vincentmarle 8y ago
  I registered our (trademarked) .app through 101domain 2 weeks ago. And I believe GoDaddy also supports Early Access (with better prices).
- rdrey 8y ago
  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.
- _zie 8y ago
  Confirmed that gandi.net does support it
  - corobo 8y ago
    That must have been a just-missed thing - I checked Gandi just before my post
- 8y ago

ihuman 8y ago

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

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

fulafel 8y ago

How does this work technically? What prevents use of plaintext http on these domains? The preloading seems like a browser specific feature.

gsich 8y ago
It is only enforced by the browser. So curl and similar stuff still works. But on a sidenote: Why shouldn't it. It is just a domain, whatever is running on the resolving IP address is up to the server administrator.
seabrookmx 8y ago
I don't think there's anything stopping you from using plain http when _not_ using a browser, such as through a server-side http client or a random python script you could whip up in 2 minutes. From what I can tell, the only enforcement is this gentleman's agreement between the browsers.
therealmarv 8y ago
HSTS can be enabled for whole domain. See here: https://hstspreload.org/#tld https://hstspreload.org/#tld General information about HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security But you are right that it is a browser thing.

koolba 8y ago

If there's anyone with an x-rated business idea, f.app is available though it's marked as a "premium" domain, likely due to the single letter. It'll cost you a cool $1,790.88/year. I wonder how much of that goes to Google.

ratsimihah 8y ago
I mean, what kinda of app want's to be called Fapp for $1500+/yr?
- always_good 8y ago
  An app that wants a memorable domain.
  - solarkraft 8y ago
    But all the success stories just post a simple intro to their apps (actually available on Android/IOS app stores) on their sites. Not valuable.
  - russh 8y ago
    Well I'm out, Cr is already taken.
    - ratsimihah 8y ago
      Well crap

panarky 8y ago

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 https://imgur.com/a/E9WRqTI

CydeWeys 8y ago
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.
- lambda 8y ago
  Is there a list of which registrars are participating in the early access period? None of the ones I tried seemed to recognize .app.
  - VikingCoder 8y ago
    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
    - khc 8y ago
      the actual two hard problems are cache invalidation and naming things, but cash invalidation doesn't quite fit into that :-P
    - rtkwe 8y ago
      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.
  - 8y ago

ahmedfromtunis 8y ago

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?

pducks32 8y ago
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
TheAceOfHearts 8y ago
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.

superkuh 8y ago

HSTS seems to require the website to conform to what google defines as 'Serve a valid certificate.' Does this mean that self-signed certs will not be acceptable for a .app domain and centralized certificate authorities will be required?

CydeWeys 8y ago
Validity of SSL certificates is enforced by web browsers. If you choose to allow your self-signed certs in your browser then it will work for you, though of course not for other people.

rebelde 8y ago

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

skywhopper 8y ago
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.
l9k 8y ago
Keyword here is "helping". It's only reducing the probability to get a malware.

enzanki_ars 8y ago

https://blog.google/topics/developers/introducing-app-more-secure-home-apps-web/ https://blog.google/topics/developers/introducing-app-more-s... It may just be on my end, but attempting to access the page using www.blog.google does not work, but blog.google works. The link may need to be changed... > nslookup www.blog.google Non-authoritative answer: Name: ghs-svc-https-sni.ghs-ssl.googlehosted.com Addresses: 2607:f8b0:4009:80b::2013 172.217.8.179 Aliases: www.blog.google > nslookup blog.google Non-authoritative answer: Name: blog.google Addresses: 2001:4860:4802:38::15 2001:4860:4802:32::15 2001:4860:4802:36::15 2001:4860:4802:34::15 216.239.32.21 216.239.36.21 216.239.38.21 216.239.34.21

dberg 8y ago

Does GoDaddy refund if you dont get the domain ? EDIT: Found the FAQ - Does pre-registering a domain guarantee I'll get it? No. Pre-registering reserves your place in our queue for that domain. The instant the registration phase opens, we'll submit our list of registrations electronically. If you don't get the domain you've pre-registered, we'll refund the cost of the registration. Any application fees are non-refundable however.

scosman 8y ago
Is the "Early Registration Fee" considered a "cost of registration" or "application fee"? It's listed as "Early Registration Fee (non-refundable)" in the cart.

guessmyname 8y ago

Here is a small script for the Terminal lovers. #!/bin/bash DOMAIN="${1:-google}" RESPONSE=$( curl -XGET -s \ -H "Accept-Language: en-us" \ -H "Accept: */*" \ -H "Connection: keep-alive" \ -H "Host: domain-registry.appspot.com" \ -H "Origin: https://get.app" \ -H "Referer: https://get.app/" \ -H "User-Agent: Mozilla/5.0 (KHTML, like Gecko) Safari/537.36" \ "https://domain-registry.appspot.com/check?domain=${DOMAIN}.app" ) echo "$RESPONSE" | sed "s/{\"/{\"domain\":\"${DOMAIN}.app\",\"/g"

hk__2 8y ago
Simpler: $ curl -sL https://domain-registry.appspot.com/check?domain=$DOMAIN.app {"status":"success","available":true,"tier":"standard"}

tenaciousDaniel 8y ago

Still waiting for them to release the .dev domains

skunkworker 8y ago
Everyone that has been using that for local development agrees. Though the writing on the wall has been there for awhile - https://iyware.com/dont-use-dev-for-development/ https://iyware.com/dont-use-dev-for-development/
sixdimensional 8y ago
.. and I am still waiting for .ing personally.
CydeWeys 8y ago
Me too, Dan. Me too.

limeblack 8y ago

Not surprisingly Google has already prevented registration(pre pre registration) of anything related to their services alphabet[1], chrome[2], chromeos[3], etc... I guess you can do whatever you want when you own the domain extension. [1] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=alphabet.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain... [2] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain... [3] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domainToCheck=chrome.app https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...

majewsky 8y ago
Not sure why this is surprising to you. Of course I'll protect against namesquatting if I have the right to first dibs.
QasimK 8y ago
> Mar 29 - May 1: Trademark holders can register .app domains (known as the "Sunrise" period).

tomc1985 8y ago

Three arbitrary letters in a list of TLDs and they call it "innovation"...

carussell 8y ago
Did you fabricate a quote? (And if so, why?) Neither "innovation" nor any derivatives of "innovate" appear in this post.

sabertoothed 8y ago

It is very strange. 101domains wanted to charge me ~13,000 USD for a domain / year. gandi, however, allowed me to purchase it (the same domain!) for ~650 GBP / year. What is going on?

the4004 8y ago
I noticed this too. Has the domain actually been registered with Gandi yet? Maybe 13k gets you a fully registered domain, and the £650 is like buying an option or a chance to be in the running.
- sabertoothed 8y ago
  Gandi was super intransparent about the phase and what they are actually selling. Indeed, Gandi did not actually obtain the domain. But merely offered to try to bid with the money once the price of the domain reached that point where it was available for that price. In my case, that failed. The domain was purchased by someone else at a higher price. I now have to fight to get my money back into my bank account. Gandi made their life extra hard by not being fully transparent.
jameslk 8y ago
I would assume one is for early phase registration (101domains - May 1-7), and one is general registration (gandi - May 8). If the domain isn't registered in the early phase, you'll be in line to have it registered on May 8.
- sabertoothed 8y ago
  It looks like it, indeed. I was confused because gandi and 101domains did not explicitly state the phase. And gandi took my money and deducted it from my account but apparently did not actually obtain the domain yet.
  - deleted 8y ago
    [deleted]

ocdtrekkie 8y ago

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.

IloveHN84 8y ago

Are already sex.app and dating.app registered?

guessmyname 8y ago
sex.app returns this "available: false, reason: in use". dating.app returns this "available: true, tier: premium"
- ThatHNGuy 8y ago
  why is it premium?
  - kowdermeister 8y ago
    Because it says dating :) Registrars can device on a set of names the wish to withhold, they are usually dictionary names with great interest involved.

scarface74 8y ago

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.

benologist 8y ago
Later google will launch .ampp for apps that are certified to only have Google and their thousands of partners sharing your PII 'securely'.
- therein 8y ago
  That honestly doesn't even sound like a joke. I'd believe it if you said that's a quote from the article.
- _o_ 8y ago
  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.
_bxg1 8y ago
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.
Andrex 8y ago
...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.

theandrewbailey 8y ago

What if I put my app's REST backend on my .app domain? Are .app domains only allowed to host brochureware?

CydeWeys 8y ago
The only restriction with .app domains is that HTTPS is enforced when connecting from a web browser. We definitely encourage you to use .app for more than mere brochureware, and of course we also encourage you to encrypt all APIs (REST or otherwise). This will be enforced by browsers if said APIs are being hit from a webpage.

z3t4 8y ago

Does this mean all request's will go via Google servers ? Like cloudflare ? Or how else would they enforce httpS ?

timdavila 8y ago
No. The TLD ".app" is on the HSTS preload list shipped with the browser, so the browser will only accept connections over SSL. It's up to you as the domain registrant to make sure your site supports it.

patrickg_zill 8y ago

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?

nathantotten 8y ago
> 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.
ucaetano 8y ago
> and reaps the fees AFAIK Google does not have a monopoly on .app registrations: https://get.app/ https://get.app/
- timdavila 8y ago
  Google owns and operates the TLD. Many registrars will sell .app names, but they pay a portion of every sale to Google.
detaro 8y ago
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.
- brlewis 8y ago
  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 https://news.ycombinator.com/item?id=16968262

laktek 8y ago

Finally! I've been waiting for this for the last 11 years http://www.laktek.com/2007/05/18/app-tld-for-web-applications/ http://www.laktek.com/2007/05/18/app-tld-for-web-application...

ashwinpp 8y ago

Note that most registrars participating in EAP or landrush charge a non-refundable fee, which is major chunk of the price increase from day 7 to day 1. It doesn't seem that there is "no cost" to participating in this period if one doesn't get the domain name.

dmitriid 8y ago

So, Google paid big bucks to secure a juicy top-level domain name. Now it says it's good because "hey, if you pay us money, we'll get you in our registry, call you secure, prominently display you in search (not now, but logical next step), and pretend it's all for great good and not to extend and protect our dominance". IANA's decision to expand and auction off to-level donations was a horrible idea.

komali2 8y ago

Get.app said the domain I want is available, but none of the linked websites said they supported that tld Edit: any recommendations for what to do with my new domain, donaldtrump.app?

ohitsdom 8y ago
Right beneath the domain available message should have been a note that these domains aren't available for purchase until May 8th.
CydeWeys 8y ago
Try more registrars, further up in the list.

simon_acca 8y ago

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?

therealmarv 8y ago
It's not arbitrarily. You can use the standard HSTS to be applied domain wide https://hstspreload.org/#tld https://hstspreload.org/#tld
- simon_acca 8y ago
  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?
  - therealmarv 8y ago
    That's a bad idea but here you go https://stackoverflow.com/questions/44650854/how-to-disable-chrome-hsts-permanently-for-a-subdomain#comment85342255_49130998 https://stackoverflow.com/questions/44650854/how-to-disable-...
    - simon_acca 8y ago
      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).

peterwwillis 8y ago

Why can't they add a new URL scheme "secure://" to Chrome that will only support HTTPS? Adding a new scheme would support all existing https websites on the internet today with no need to pay anyone money or rush to reserve domains. This .app thing is needlessly difficult, and just a way for Google to push its brand on technology concepts en-masse, like the .dev fiasco. Now everyone in the world has to register a new domain (and make it work for their site) to make sure their URL is always secure.

SahAssar 8y ago
How would "secure://" differ from "https://" https://"?
- peterwwillis 8y ago
  Most people don't know what https:// https:// means, and is often confused with http:// http://. Plus, https:// https:// has allowed people to do things like click through certificate warnings, which secure:// should never do. Finally, secure:// should require all standard best practices for the security of web apps, first simply by refusing to render obviously insecure sites, and then by requiring extra parameters.

peterbe 8y ago

I go to https://domains.google.com https://domains.google.com and search for my desired .app domain and it says "Google Domains does not support the .APP ending" :(

z3t4 8y ago

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.

solarkraft 8y ago
What if we just sell TLDs directly to consumers?
- z3t4 8y ago
  I think it's important that any TLD is open for registration of domains. For example if Facebook bough .book they should need to allow others to register under it.

CydeWeys 8y ago

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 https://get.app and https://www.registry.google/about/register.html https://www.registry.google/about/register.html

deleted 8y ago
[deleted]
paultopia 8y ago

z3t4 8y ago

I think this domain will be very popular as app means app in almost every language. I hope Google will do something about the domain snapping or all good names will be taken (and not used).

kiddico 8y ago

I was not aware .google was a tld. Can any company get a tld made? Who's even in charge of that sort of thing?

notatoad 8y ago
yes, any company willing to pay the application fee of $185k and able to pass a review as "capable" of operating a TLD can register a TLD. ICANN is in charge of it. https://newgtlds.icann.org/en/about/program https://newgtlds.icann.org/en/about/program

AngeloAnolin 8y ago

Just for fun, I tried these domain names via the url get.app: apple.app facebook.app instagram.app twitter.app ycombinator.app * snapchat.app * producthunt.app * whatsapp.app amazon.app microsoft.app google.app hotmail.app * dropbox.app intercom.app * pivotal.app * tesla.app dell.app ibm.app * * AVAILABLE

itronitron 8y ago
i call dibs on 'whats.app'
- COil 8y ago
  haha, not available any more, this was the one to get indeed.
domainhunter 8y ago
Would I be sued (i.e is it legal?) if I buy some .app domains related to popular apps of my country and list their google play store and apple store link with some ads on those domains?
- therealmarv 8y ago
  If your intention is to make some money and they have trademarks and already existing similar domains you are not acting legal! There were other people who already had the same thought as you... they failed!

6031769 8y ago

1. Register a .app domain 2. Serve content from it via HTTP only 3. Market it as the new dark web 4. ... 5. Profit!

dvfjsdhgfv 8y ago

Why on earth should I do it? Give me one good reason; enforcing HTTPS doesn't count as one. And yet, it seems like HN crowd is queuing o buy these... Are you planning to get them so that you can sell them at a higher price later? What makes you think this product of Google does better than Google+?

segmondy 8y ago

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.

s2g 8y ago
Makes sense, given their mission to monopolize the internet. Break up google.
brlewis 8y ago
Is there any precedent for a TLD owner doing what you describe? I think this is HSTS preload and nothing more.
- CydeWeys 8y ago
  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.
- dingo_bat 8y ago
  Yes: http://www.cbsnews.com/news/daily-stormer-being-dumped-by-godaddy-apparently-seized-by-anonymous/ http://www.cbsnews.com/news/daily-stormer-being-dumped-by-go... https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stormer-because-of-what-it-wrote-about-charlottesville-victim.html https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stor...
  - edem 8y ago
    They violated terms of use. What's the problem?
    - dingo_bat 8y ago

magoon 8y ago

This is confusing because Mac apps literally end in that extension, and if I say Messages.app you would know what I mean. Also, if I say “dingus dot app” it confuses people because that’s not a mobile app, it’s a site or web app.

askvictor 8y ago
Old DOS executables (actually, commands) (which still run on Windows) ended in .com ; there was an overlap with the Internet when they were still quite common (command.com was how you started a command prompt on windows 95), and no-one seemed to get confused
- magoon 8y ago
  This is a fair & fun point, however maybe a bit of a stretch to compare here; DOS binaries were almost all .EXE well into DOS 3.x, which was many generations before Windows 95. I would say the exception to that had been command.com

JasonSage 8y ago

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.

icebraining 8y ago
From another post in this thread, ICANN rules prevent the two from coordinating.

jest3r1 8y ago

Starting today at 9:00am PDT and through May 7, .app domains are available to register as part of our Early Access Program, where, for an additional fee, you can secure your desired domains ahead of general availability. Additional fee: hackernews.app is available! CA $25.72 per year (pre-registration) CA $16,082.01 (early access) Helluva fee. https://www.name.com/preorder/app?domain=hackernews.app&tld=app https://www.name.com/preorder/app?domain=hackernews.app&tld=...

makecheck 8y ago

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.

CydeWeys 8y ago
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=7ac8be59-1ecc-4d90-aea5-e62deab5ee7f https://events.google.com/io/schedule/?section=may-8&sid=7ac...

fiatjaf 8y ago

Why do we have TLDs at all? If ANY COMBINATION OF LETTERS is now a TLD, we should be able to register myname.whatever if I want to, or in fact just whatever as a domain. Ok, ok, I'll pay GOOGLE, the owner of the internet, for doing this now.

keyle 8y ago

Seen on name.com... https://imgur.com/kYyNQQg https://imgur.com/kYyNQQg ?!

pknerd 8y ago

so a web based product can be called an _app_ and get hosted for a certain *.app domain?

koyao 8y ago

Why does "his.app" cost $499.99 for pre-registration, but "her.app" only costs $249.99? :) Is this some built-in gender bias?

kiproping 8y ago
Christ!
friend-monoid 8y ago
It's a bidding war. Someone already bid 249.99 for "his.app". Next step up is 499.99. If you buy her.app for 249.99, then both will cost 499.99.
domainhunter 8y ago
I am new to domain trading. I have one question - Would I be sued (i.e is it legal?) if I buy some .app domains related to some popular apps of my country and list their google play store and apple store link with some ads on those domains?
- icebraining 8y ago
  I don't know if it's illegal, but unless you have a trademark on those names, you're almost certain to lose them.

kahnpro 8y ago

No, Google. Just no.

odammit 8y ago

Registration opens May 8th. I went through a few of the registrars and got error messages that the TLD wasn’t supported. Godaddy of course has a solidly gouging pre-registration price. Set an alarm to park park park. Edit: Godaddy isn’t straight up gouging. Seems like dictionary words are much more expensive than made up words or non-dictionary brand names. Name.com somehow has a “buy it now” option in the 10k+ range. Curious how that works.

runnr_az 8y ago
.app is in the sunrise phase right now -- I think all the registrars pay the same wholesale rate and it's possible that the actual price is set as well. It'll drop to the regular price on 5/8.
odammit 8y ago
If you are looking to park an obvious bell-ringer it looks like just about every Fortune 500 has already had their domains pre-registered. Even McDonalds.app is registered. Happy hunting.