Yeah, the play store of websites. Where we need to get permissions and approvals and can get banned. No thanks, Google is trying to bring their walled garden idea for websites. Don't trust Google on this. They just turned off their service rather than support signal, what if signal was signal.app would they block em? Don't trust Google on this. It's a decent idea but no.
Actually I was searching for Terms of Service and Acceptable usage policy for .app domains and could find NOTHING specific. Not even on official site https://get.app/
I could only find Google Terms of Services, so they also apply to .app ??? So what if I host e.g. adult related material on .app will they ban me? The usage policy is totally in the dark for this domain.
It's weird how Facebook is getting all the heat but Google is the real snake in the grass.
When Google bans you, they delete your drive, Gmail, photos and everything associated with it including the ability to search. Also they are associative; if one of your accounts are banned then any account, even business accounts, are all purged.
One of a startup in my previous cohort was completely deleted after one of it's employees who had a banned Google account logged into Google for business
Are you saying that Google banned the whole organization based on the association of one employee with a banned account? And they withheld your data with no recourse? Did you consult a lawyer?
I've used DuckDuckGo for months. Only the very most esoteric of terms brings me back to Google, and I can count those times in the past months on one hand.
It's certainly an issue to consider if you're starting a company.
If you are creating a organization that is less focused on making money as a core element like a business is, then you should feel fine using .org or any other domain.
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.
ICANN has worked very well so far, but if they don't put up a strong response to registrar-based censorship on already-registered domains and make this contractually impossible, the internet is going to be in big trouble. We can't let "you can't have a domain because we don't want you to be able to talk, as a matter of corporate policy" become a thing.
GoDaddy is a registrar. Google has both a registrar and a registry, but the linked actions were taken on the registrar side (i.e. not relevant to what the registry can do with its TLDs). The list of TLDs run by the registry can be found here: https://www.registry.google
My point is that google will ban your website off the internet in whatever way possible for them, if they don't agree with what you're saying. They have demonstrated this as I linked. Just because their role is now TLD owner, doesn't mean they will not do what they think is necessary.
I don't understand why Google or Amazon are to blame here. It's like using an unofficial API and then complaining when it's taken down. Yes, it sucks that Signal can't hide behind them to bypass censorship, but as far as I understanding, it's not a good practice for these big sites to support Domain fronting in the first place.
> The big difference is that HTTPS is required to connect to all .app websites...Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.
This sounds good but how does it really help users or developers compared to having a .com website that uses HTTPS? Expecting that users will think "oh, .app, must be secure" doesn't seem like an improvement over expecting them to look for key icons in the browser, or showing them scary alerts for non-https sites.
The only play I see here is that if the new TLD becomes so popular that everyone must have one, then, well, everyone must have HTTPS. But that's not going to happen either. Even .com never reached a high enough level of importance that absolutely every website, including those who weren't interested in providing HTTPS, needed to use .com for their domain.
Tech lead of Google Registry here. I can help answer some questions.
HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Preloading the entire TLD rather than individual domains has a number of benefits, including the fact that (a) it's effective now rather than several months from now for a newly created domain, (b) you don't individually have to configure anything, and (c) it keeps the size of the list down (which is important since the list is built into web browsers).
And in addition to all that, you're right, it is a play to move more sites to HTTPS, which is better for the safety and security of the web overall. Chrome is soon going to display "Insecure" for every single http site, which is another nudge to help move the web towards a secure future.
I'm not saying I agree with his stance, but I think it's important to mention Dave Winer's concerns re how the ongoing transition to HTTPS will affect older sites. Many of these played an important role in the web's rise to prominence, but could lose out if HTTPS becomes the baseline for trustworthy content.
Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been any discussion within the Registry or Search teams about how to address these kinds of situations?
Can you give an example of a site that couldn't be moved to HTTPS? I would expect that even if the serving stack doesn't support HTTPS you could put a proxy in front of it.
Winer's argument seems to be that he owns a number of sites that don't need the explicit security that HTTPS provides (a blog archive, for example), but that shouldn't affect how Google and the rest of the web view whether or not the content is trustworthy.
Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS.
As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases.
You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with.
The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.
As long as the CA is in a jurisdiction that can require revoking access, it becomes an attack vector if HSTS is enabled and you’re at the mercy of preloaded root CAs.
There are many preloaded root CAs. Are you saying you're worried that every single one of them will simultaneously be required to revoke your certificates?
As nice as an HSTS preload list is, using .app and .dev for this is infuriating.
Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.
Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
I've been told by a few people that it's my own fault, that I should have used something else like .test, etc.
I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution.
Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
IIRC, .app isn't the first TLD to be included in HSTS preload list. I hope the registrars will make it clear to customers that .app itself is in the HSTS preload list to prevent any confusion.
Trying to register via google domain says "Google Domains does not support the .APP ending". Is that on purpose (Google domain is listed on get.app as compatible) ? A cache issue ?
I can't speak specifically for Google Domains as that's a completely different team that we have limited interactions with.
What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.
Wait, so you put out this launch announcement telling people they can early register .app domains. It links to a bunch of partners including Google Domains, but you have no idea whether I can actually register a domain there or not? Why promise it in your launch announcement then?
Choice of domain registrar is up to the end user. We cannot recommend any one over the other. There are plenty that are offering the full range of registrations/preorders (including EAP), and you need to pick your own.
It costs end users ~$20, for whatever's left over after the seven rounds of expensive "priority access" pick over the namespace carcass... At least for the two out of three resellers I tried (Google themselves still don't appear to know this exists...)
You can register a domain name at this moment during the Early Access Period through any registrar which supports it (which includes GoDaddy and many others listed at https://www.registry.google/about/register.html ). It's not a pre-registration; the domain is created and assigned to you immediately.
To be blunt, this is a horrible roll-out by Google. It is a perfect example of the right hand not talking to the left hand, or the rest of the body for that matter. Several significant issues:
1) The announcement is made by Google, yet Google is not accepting EAP registrations. Very confusing.
2) The registrars accepting EAP are not as widely known as you would expect for something like this, meaning that I am going to have to pay to registrar now and then a transfer fee to transfer to my primary register down the road.
3) GoDaddy is listed as an EAP registrar, however, they are only accepting pre-registrations at this time. On top of that, they found a way to be even more shady by charging a $173.99 for "Priority Pre-Registration".
Whether registrars support EAP, and how they implement it, is entirely up to each registrar. If you have complaints about any specific registrar practices, or about registrars not supporting it full stop, then those should be directed at the registrar in question.
The complaint is against Google, not any particular domain registrar, to be fair. At first glance it seems like you’ve botched this roll out for the (preventable) reasons mentioned above. Wordpress, although I didn’t agree with some choices they made when doing it, did a wonderful job rolling out the dot blog TLD, as a counterpoint.
We literally cannot coordinate anything between the registry and registrar though. I agree with you that we (the registry) could have done a better job on our marketing website in making it clearer which registrars offer support for which phases, but beyond that? Not sure.
GoDaddy is confusing. They only have "Pre-Registration" and "Priority Pre-Registration", the latter showing the days of the EAP, but it only says you can "increase your chances of getting this domain", not that you get it right now.
Aka GoDaddy is running a dirty scam. There should be no such thing as "priority pre-registration". They're just trying to grab more money. GoDaddy is the worst company you could ever look at for domain registration. Use literally anybody else.
This is not true. One of my friends and myself have both paid for registration of different .app domains and some ten hours later it still says pending at two different vendors listed there as EAP providers.
There has to be an error somewhere on a couple registrars. Trying through 101Domain adding a domain to the cart results in a total of $12,025.16 USD. I can get it slightly cheaper at Yay.com for $10,209.09.
Different registrars set different prices. .com domains cost different amounts across different registrars too. It's not a mistake, and if price factors into your determination of which registrar to use, then that totally makes sense.
Right - so you've just built this to give bdirty scammers another way with which to rip everybody off. Thanks for that. Lucky "Do no evil" isn't written on the wall there anymore...
Sigh. As I’ve said before, we need stronger identity profiles and user agents that verify much more than legitimate-sounding names. A name alone should effectively be treated like it could be completely and utterly fake, period.
Yes, they’re requiring "https" but it’s not like it is hard to acquire a certificate anymore.
All the ".app" domain will do is screw app developers into paying to register their chosen name on a particular domain. Again. After all, if you don’t register then someone else could, giving their site perceived legitimacy over yours. Let’s not forget, many apps are not making millions on top-10 lists; developers aren’t exactly eager to further cut into their meager earnings to cover web sites.
We already know that entire apps are being copied. Scammers have never been deterred from copying entire web sites either (just look at those E-mails from “your bank”). This new domain might serve mainly as a way for scammers to make stolen copies seem even more real. Frankly, I predict that all the real talented developers will be slowly discouraged from continuing to try to make money in an environment where obvious fakes can thrive so easily and the costs just keep going up.
HTTPS and SSL certificates are primarily used for encrypting the connection, thus protecting your data from snooping and modification in transit. They are not actually that useful for authenticating identity. Users tend to simply ignore the padlock icon, which is why Chrome is moving away from an affirmative security display model (which users don't pay much attention to) to displaying prominent warnings for insecure or hijacked connections, which users do pay more attention to. SSL certificates' inability to properly authenticate identity is also why many of the largest tech companies in the world do not even bother with EV certificates (e.g. Google, Amazon, and Facebook for starters).
In order to fully establish identity and provide strong authentication, you would need a much stronger centralized system. Additionally, browsers would need to refuse to make connections to endpoints not authenticated through this system, otherwise you'd have the same kind of lackadaisical user response as we see now to the padlock icon. I don't think anyone present here wants anything like that, and I'm sure that if we were proposing such a walled garden vision for the Internet, the responses would rightfully be much more negative. Instead, we just want everyone's connections to be encrypted.
As for some of your other points, having a strong, short, memorable domain name is good for overall Web security and does help cut down on fraudulent apps and the other problems you've identified. To give you one example, I recently saw an ad for an app called "Curb" (it's a yellow tax ride-hailing app). Out of curiosity I wanted to see more information about it, but there was no domain name on the app; it simply said "Download the Curb app". So I searched the app store for "Curb" and there were dozens of apps with that name, many of them clearly imitators. The best "security" measure was trying to remember what the app's icon looked like.
Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores. That's taking advantage of the global uniqueness property of domain names to guarantee that I won't be tricked away by a scammer. "curb.app" is short and memorable, gets users to the right place, and because .app is a fresh namespace, is still available. Good luck getting any domain name close to that good on .com. .com is fully mined out, and any good names that are available are being sold for minimums of tens of thousands of dollars by squatters and resellers.
> Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores.
Now imagine it's a year or two from now and you have the exact same problems that you had with curb.com.
What's the strategy for when .app gets mined out? Are we just going to keep creating new tlds over and over for eternity?
Bear in mind that the only way .app won't get mined out will be if either very few people use it, or if users ignore it and don't treat it any differently than any other namespace. Ironically, the only way this will be useful for developers like me is if Google's advertising campaign utterly fails and it's ignored by most people.
The solution to identity management can't be that users will stay one tld ahead of hackers. That's just never gonna happen. Users are slower than hackers.
> Are we just going to keep creating new tlds over and over for eternity?
Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.
In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squatters will always capture a rent, by guessing domain names that will be valuable latter on. The way to minimize that rent on the long run is to periodically reset the game by bringing new TLDs into existence, thereby devaluing the investment in older TLDs, thereby making squatting a more risky activity. The GTLD liberalization greatly diminished the price pressure on .com .org and the like.
Keep in mind the web has seen exponential increase in the last decades; the upside now is much more limited, maybe another order of magnitude until complete worldwide market saturation and web growth figures get more inline to global economic growth numbers. Once that is achieved the problem becomes much less serious.
> there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.
Zooko's triangle is a triangle - decentralization is not the only thing we could sacrifice. We could even start to layer multiple naming schemes on top of each other to mitigate some of those sacrifices.
What OP (makecheck) was getting at was that the .app tld doesn't really solve any problems except to block one very specific injection attack, and it's problematic for Google to market it as significantly more secure than any other namespace. I agree with that.
The problem isn't that new tlds are unsustainable in the long term (although they are), it's that they don't even solve anything in the short term. Right now, at this moment, I can't credibly tell my parents that they should trust a .app domain more than a .com domain. Within a month of its release, people will be using it to phish older websites - because malicious actors will always be faster than regular users and developers.
If you're trying to block Sybil attacks, I wouldn't be that surprised if introducing new namespaces ironically ends up making the problem even worse.
I think that would hurt small businesses more than it would dissuade squatters of truly valuable domains. The trick is to move money from the squatters to the public and domain owners, not to the registry itself, that is basically just another big squatter.
Maybe a TLD like .app could increase the annual renewal fee to something like $100 while bundling premium features like business Gmail, Adwords credits or Google Cloud services, all usable only on that domain name. This way, low level owners get their money back, big corporations don't care and squatters are hurt since they can't make use of the services.
Considering your "Go to curb.app" solution, to be brutally honest I think at least 50% of the world has no idea what the difference between "Go to curb.app" and "Download the Curb app" is. They are both practically the same. "Guarantee that I won't be tricked away by a scammer" - yeah, no. There are already too many TLDs to squat on that remove any usefulness of a "short and memorable name" on a new one.
I feel like there's some sort of legitimate blockchain solution to be had here that doesn't involve a centralised authority. Who got there first, what domains they have owned continuously, and what products they control perhaps...
If it’s not clear from the article, HTTPS is required for all .app domains, which Google accomplished by adding the .app TLD to the default chrome HSTS preload list.
Interestingly that will only ensure HTTPS only when using a browser with HSTS enabled with a preload list that includes the .app TLD.
Therefore non-web code, or code in browsers without the TLD in the HSTS preload list, will be able to make HTTP requests to a .app domain.
It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. Also, and this is just a feeling, it seems obtrusive for google to force such a policy across the TLD. Of course it’s their right since they own the TLD, but the cynic in me can’t help but think it sets an overbearing precedent. Based on Google’s behavior in the past, this looks like the second step of the “embrace/extend/extinguish” cycle Google has used so effectively in the past.
> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security.
On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement.
.app will be HTTPS only from the start and for the foreseeable future, so (at least in my opinion) there's no need to care about HTTP, or even open port 80 at all.
Granted you could do this before with HSTS preload, but setting that up yourself requires fiddling with headers and waiting a bit while browsers update with the new list. With ".app" it happens automatically, so it lowers the barrier, making it easier for strong encryption to be used by everyone for anything and everything.
This makes HTTPS easier than HTTP, which doesn't look like much on paper, but is (again, in my opinion) one of the best ways to increase security overall.
Chrome maintains the list that most browsers use, but it's not the only browser using the list.
Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's.
You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly.
As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo).
Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.
Google Reader would be the often mentioned first example: Google entered the RSS reader market, became the best, added a bunch of features and really became "the" de facto place to read feeds. ...Then closed up shop and killed much of the ecosystem outright, directing people towards proprietary places to get their news like social networks or Google News.
Hangouts did very much the same with XMPP, a move which a Googler once suggested to me was viewed internally as a betrayal of the company's values.
I think we may be approaching EEE territory with email: Gmail's already centralized a large portion of the email industry, to the point that Google has about two-thirds of all emails on one side or the other, and now they're moving into introducing a proprietary email format (AMP 4 Email), which isn't being developed in a standards-focused way.
I'm sure the same argument could be made for their push into RCS over texting, browsers (now pushing Chrome-only websites and features in a lot of places), Android (embracing third party OEMs before moving into locking down much of newer Android functionality and launching a first party iPhone competitor), etc.
If there was a movie quote that best exemplified Google's business strategy, it would be "I have altered the deal. Pray I do not alter it any further."
Google Reader does not fit the pattern of EEE; if anything, it shows their failure to pursue it. EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system. What they actually did was lose a bunch of people for alternative readers, for Twitter and for Facebook.
AMP for email does seem a good example.
RCS is not developed by or supported exclusively by Google. They weren't even the first; Vodafone had it on their phones for years. Google is late to the party.
--
My opinion is not that Google is ethically above doing EEE; it's that they're often too disorganized and erratic to actually pull it off even if they wanted to.
Google News is embracing and extending free web news outlets.
Chrome is embracing and extending the open-source web browser community.
Android is embracing and extending the open-source mobile OS development community.
I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.
Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.
There isn't a monolithic explicit strategy with the word "extinguish" in it. Instead there's a pervasive set of tactics which result in embracing, extending and, when successful, extinguishing open standards and communities.
Gmail is very far away from extinguishing open email, because that's such a huge target, but it certainly managed to make a dent. How many users have forever left the open ecosystem of smtp/imap/pop tools and service providers because of Gmail's growth? If Gmail hypothetically reached the market share necessary to mortally wound that open ecosystem, do we have any doubt that it would eventually do it?
And remember, email is the largest open ecosystem in my list. Where is the fully open alternative to iOS? Answer: it doesn't exist because Android captured all the momentum from the emerging community, and channeled it into a platform that is now closed for all practical purposes. In this case, extinction has already happened.
GChat/Hangouts is a prime example. The embraced XMPP and Jabber much to the delight of the open protocols communities. They then expanded on the protocol adding stickers and drawings and other stuff. Then closed off their XMPP gateway once they were huge (stickers no longer work with the protocol they said), essentially killing the future (at least mainstream) of XMPP, and pushing more people to proprietary messaging platforms.
I was thinking primarily of Google AMP when I wrote that. Google's strategy is not necessarily the same as Microsoft's was; often it's a bit more subtle, but the common theme is that Google pushes standards that are primarily beneficial to itself, but often paints them disingenuously as "helping the web" or some equally meaningless BS.
Some examples which might not qualify specifically as EEE, but certainly qualify as Google pushing for biased standards:
- Google AMP (not clearly EEE, but definitely anti-open web)
- Google Chrome (not quite EEE, but barrier to entry in browser market is now extremely high)
Some more clearly EEE examples:
- GChat (clear EEE strategy on XMPP)
- Google flights (EEE the travel industry)
- Google shopping (EEE affiliate offers)
- ....
Note that these examples are not solely "competing with an existing business" as you described, because the initial announcement of them was usually welcoming and open, e.g. opening with federated xmpp compatibility, promoting it, and then extinguishing it later. If developers back then had known google would shut down xmpp, maybe they would have put effort into building a better federated xmpp ecosystem instead of wasting time interoperating with google's system. That kind of bait and switch is the hallmark of an EEE strategy.
Barrier to enter browser market is now just fork Chrome source and apply your logo, thanks to Google (see Opera, Brave and hundred others as an example).
Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.
Sadly the Chrome team together with web devs everywhere are creating a web where "works best in IE6^h^h^hChrome" is making a very unwelcome comeback.
This should be so unnecessary in 2018.
I don't think the devs are necessarily doing this on purpose. I do however wish they'd be somewhat more considerate about the web ecosystem.
I'd also wish they hadn't used their dominant position in ads to push Chrome as "a better browser" for years to everyone including people who already used modern browsers.
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.
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.
What is the "single source of truth" for the HSTS preload list? It must be on a server somewhere... who runs the server? Which browsers use this list by default?
Thanks for that. But that site doesn’t seem to mention the loading process across browsers. Generally speaking , do the major browsers ship the HSTS list compiled into the build? Or do they update it at runtime? If so, from where do they fetch the updated list, and how often?
Yes, the major browsers ship the HSTS preload list compiled directly into the build. That's why it can take months for a domain to, once submitted, actually be preloaded across a majority of users -- because the browser nightly/beta/release build cycle alone is 2-3 months, plus the time that it takes the average user to update their browser.
Incidentally, this is one of the major advantages of HSTS preloading at the TLD level, namely, that all .app domains are already preloaded and have been since 2017.
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.
Because telling my grandma ".app urls are safer because Google" is like saying "here's a loaded handgun, but the safety is on, go nuts!"
actually that's a bad example because even then my grandma knows to be careful. but she's tech illiterate enough that if she hears something is "safer" she will put blind faith in it.
This isn't an issue for me and you, the readers of HN, this is an issue for Jane Doe, who already has low standards, and is now going to lower those standards even further for a set of websites.
When grandparents start seeing .app urls, they are going to be naturally wary. And they might even avoid clicking them. Then someone is going to ask about them to someone who is only partially tech savvy.
And that someone will tell them that those are safer URLs. And that gets misinterpreted and soon you have people saying they are special approved by google URLs that are guaranteed to be safe.
Regardless of who the article is for, tech illiterate people are going to ask "what is this new URL thing, and should I trust it?"
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.
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.
(a) transferring wealth from the secondary market to registrars, and
(b) guaranteeing that desirable domain names get allocated purely on economic value terms, thus effectively shutting out non-profit-oriented enterprises from the best domain names. If someone with some quirky desire to name a domain name after their cat would like to grab the domain name and refuse to sell, this pricing scheme guarantees that such sentimental value counts for zero in the "efficient allocation" measure.
"Efficiently" is a concept defined only by your target. If your target is economic value, then, sure this kind of auction does a pretty good job at allocating efficiently with respect to it. If your target is something like desire-satisfaction, or promoting novelty/creative use, then it might be worth trying to think about ways to preferentially allocate to people willing to put in more effort too, or, e.g., introduce some kind of lottery system for some domains for non-commercial uses.
Without a system like this you don't get your quirky cat domain name, someone swoops in on minute 0 with a script and registers the top 1000 desirable domain names and squats them.
Anything that wouldn't have been swooped up by squatters will _also_ still be available when the early access period is over and everything is $20.
On the other hand this seems like a pretty decent way to prevent mass domain squatting, because screw those guys. I'm sure there are still some people doing complicated cost/benefit analyses and squatting strategically but I think it'll be much less rampant.
A couple easy metrics: Existing brand names/trademarks, existing websites on other TLDs, and length of domain with additional weighting for actual words (maybe additional weighting based on word/tuple frequency in say the google books corpus).
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.
Ah, looks like the registrars were still coming online when I tried. When I first tried Gandi, it didn't seem to like .app, but now it does and lets me choose "landrush," which I assume is the way to buy a domain during the EAP.
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.
I just tried to buy one. Got an email saying I'd be invoiced on allocation of that domain to the registrar. WTF does that mean? How can they take my money if they don't even know they'll have the domain to sell?
Barely related question: does Google plan to deploy the .google gTLD for use in its services, i.e. will mail.google.com become mail.google, and drive.google.com change to drive.google just like they did for blog.google and registry.com?
I think they’d like to possibly but there are concerns. I have had trouble with vanity tlds and I can imagine with google being so ubiquitous, there could be so many issues.
And also security. I know there’s an implicit trust of .com and so I wonder if seeing just google will lead to people thinking it’s safer. I have Metcalfe.rocks and more than once I’ve had people try Metcalfe.rocks.com
The funny thing about their blogs is that many of em are still on the regular domain. I'd imagine there's many hurdles in migrating so many large services, and there's barely any benefits to doing so. In addition, I'm not sure if all their supported legacy browsers can even handle gTLDs.
If I were in their position I'd probably use it for new deployments, with a low priority task for evaluating the possibility of migrating existing systems.
Arbitrarily picking web standards seems like an abuse of power. If this is the direction in which they want the internet to steer (a great one as far as I’m concerned) Google should advocate for the deprecation of HTTP in the appropriate bodies instead though.
It baffles me that TLDs are at the mercy of private companies... I guess I should read more about the history of the internet to understand how this came to be.
Finally, maybe the management of authoritative DNS is one of the few applications for which a blockchain could actually make sense. Still pondering on the specific model though, does anybody know of existing projects in this direction?
That’s fair, given that HSTS is after all a standard itself and Google is merely applying it.
Then I guess my perplexity is towards IETF in that they allow for two conflicting standards to exist.
What if I want to use local.my.app for development;
Or, in a more textbook example, i want to use workstation-1.building-a.my.internal.my.app without https?
>What if I want to use local.my.app for development; Or, in a more textbook example, i want to use workstation-1.building-a.my.internal.my.app without https?
uh... don't do that?
if you're developing locally or internally, use my.app.local or workstation-1.building.internal. If you want to use public domains for non-public things i guess go ahead, but you can't expect everybody else to support your weird thing. Or if you really need to run your internal dev stuff on public domains, get a certificate for it.
Well, disabling HSTS is a badidea as long as the logical (or legal) entity creating the subdomain is the same one that enforces HSTS, which was the case up until this point, (in that being the same entity they know which subdomains need HSTS and which ones don't).
> Google should advocate for the deprecation of HTTP in the appropriate bodies instead though
I agree with your larger point. For instance, I believe Google purposefully avoided implementing some privacy-preserving features in its QUIC protocol.
However, in this case, it was the ISPs and wireless carriers that fought against deprecating HTTP, while Google and Mozilla wanted to deprecate it. It's why I think they only enabled the HTTPS version of HTTP/2 in their browsers. The carriers and ISPs wanted the web to stay on HTTP so they can mine everyone's data, as they're already doing with the sites that have remained on HTTP.
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.
It helped a little that .com executables were pretty much obsolete by the time the web became common, but that was still a pretty nice gift to early malware authors.
Having a name ending in '.sh' is less reliable than the output of file for identifying shell scripts, since any file can be named with that ending.
cat199 said '.sh' is unnecessary and that is correct. I am surprised that this is controversial. (except wait, no, this is the internet... I'm not surprised. ;-)
No. It works with some of them, because, as the parent wrote, it’s just the automated equivalent of "let’s look at content of the file and guess what it is". It’s not perfect, and so doesn’t always work. If you write "echo 42" in a file, `file` will only tell you it’s "ASCII text".
We humans are used to identify things with their name. `.sh` is not necessary to execute a shell script; but it’s so convenient you must have a good reason not to use it.
There are over a hundred shell scripts in my /usr/bin/ dir that don't end in '.sh'. There are even Python scripts in there that don't end in '.py'. The world hasn't gone mad?
Ending the filename of a shell script in '.sh', while a useful and common convention, is unnecessary (I appreciate you that you acknowledge that) so using that to identify shell scripts is a heuristic, just like what file does.
Look, I don't want to argue about this. cat199 was catching downvotes for pointing out, quite correctly, that the '.sh' extension was just a convention, and, well... https://www.xkcd.com/386/
Filename extensions have always been a crappy hack to get around the omission of useful metadata associated with a file on some early filesystems. Gnome file viewer thing doesn't even sort by them!
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.
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.
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.
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.
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 :(
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.
So I have a Namecheap account and trying looking at an .app domain just now, but it says "We don't support this TLD". Because of this I am now on GoDaddys page pre-registering there.
The GoDaddy thing is basically, "Pay us extra and we'll click for you automatically on May 8th." It's like paying Southwest Airlines $15 to check you in right at t-minus 24 hours before your flight...
I bet all registrars are stoked when any new gTLD comes out, that auction and "valuable word"-based system must bring loads of cash. This one of the most outrageous, user-hostile things I've ever seen. It only preys on the need for brands to protect themselves while bringing no value and only confusion to end-users.
I definitely wouldn't say "loads of cash." .Com is still a very major part of any registrar's business. However, I like when new registries try new things that go beyond the namespace - requiring HTTPS could have a meaningful impact. Completely disagree that it's user-hostile — there are far fewer registration options in .com so opening up a new namespace gives users more flexibility in what they can register.
I just went onto one of the EAP registrars website and spoke with a 'domain consultant'.
This individual assured me for today our available .app domain can be registered and fully usable for $11999. Tomorrow the price goes down to $2999 or something like that.
How is this possible if Landrush is only a preregistration expression of interest?
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
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
.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.
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.
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.
