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.
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!
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.
> 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.
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?
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.
GoDaddy is confusing. They only have "Pre-Registration" and "Priority Pre-Registration", the latter showing the days of the EAP, but it only says you can "increase your chances of getting this domain", not that you get it right now.
Aka GoDaddy is running a dirty scam. There should be no such thing as "priority pre-registration". They're just trying to grab more money. GoDaddy is the worst company you could ever look at for domain registration. Use literally anybody else.
To be blunt, this is a horrible roll-out by Google. It is a perfect example of the right hand not talking to the left hand, or the rest of the body for that matter. Several significant issues:
1) The announcement is made by Google, yet Google is not accepting EAP registrations. Very confusing.
2) The registrars accepting EAP are not as widely known as you would expect for something like this, meaning that I am going to have to pay to registrar now and then a transfer fee to transfer to my primary register down the road.
3) GoDaddy is listed as an EAP registrar, however, they are only accepting pre-registrations at this time. On top of that, they found a way to be even more shady by charging a $173.99 for "Priority Pre-Registration".
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.
There has to be an error somewhere on a couple registrars. Trying through 101Domain adding a domain to the cart results in a total of $12,025.16 USD. I can get it slightly cheaper at Yay.com for $10,209.09.
Different registrars set different prices. .com domains cost different amounts across different registrars too. It's not a mistake, and if price factors into your determination of which registrar to use, then that totally makes sense.
Right - so you've just built this to give bdirty scammers another way with which to rip everybody off. Thanks for that. Lucky "Do no evil" isn't written on the wall there anymore...
This is not true. One of my friends and myself have both paid for registration of different .app domains and some ten hours later it still says pending at two different vendors listed there as EAP providers.
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.
IIRC, .app isn't the first TLD to be included in HSTS preload list. I hope the registrars will make it clear to customers that .app itself is in the HSTS preload list to prevent any confusion.
As nice as an HSTS preload list is, using .app and .dev for this is infuriating.
Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.
Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
I've been told by a few people that it's my own fault, that I should have used something else like .test, etc.
I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution.
Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
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?
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.
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.
> 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.
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.
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.
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.
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).
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.
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?)
Well, there aren't any obvious alternatives, for one thing: .ch is Switzerland, .ca is Canada, etc.
I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.
Ok but that sort of takes away the entire argument that .io "belongs" to these people somehow. It doesn't, it's purely a political issue. It's not some natural resource or anything they'd have claim to otherwise. (And seems that Mauritius might have claim, meaning no extra ccTLD.)
It's fine if people want to raise awareness to Brits behaving badly. But saying .io should go to those people is misleading.
.vi is controlled directly by residents of the US Virgin Islands. The primary contact address is on St. Thomas, and the NIC follows some pretty restrictive domain naming rules to favor the residents of the US Virgin Islands. It's run by the local telecom and presumably all money generated from .vi revenue goes to the island economies.
That is much closer to the ccTLD original intent than any of the British territories have seen (.io, .vg, etc). It's not misleading to suggest that the territory control their own ccTLD's destiny, given that was the original presumption of the early IETF and many of the original NICs.
Of course it's not a "natural" resource as a digital artifact of the internet economy, but that doesn't mean the ccTLDs weren't intended to be a resource to a specific locality, and that that specific locality shouldn't most control or best benefit when that ccTLD is exploited by foreign interests find a different use/meaning/domain-hacks for that TLD.
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. :/
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
Edit: It appears this pre-registration doesn't even guarantee you'll get the domain. It just increases your chances :( I'm gonna pass...
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 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.
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.
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.
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.
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.
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.
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?
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.
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.
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...
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.
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.
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.
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.
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.
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.
377 comments
[ 2.6 ms ] story [ 240 ms ] threadhttps://news.ycombinator.com/newsguidelines.html
https://linux.die.net/man/1/file
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.
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!
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.
HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Preloading the entire TLD rather than individual domains has a number of benefits, including the fact that (a) it's effective now rather than several months from now for a newly created domain, (b) you don't individually have to configure anything, and (c) it keeps the size of the list down (which is important since the list is built into web browsers).
And in addition to all that, you're right, it is a play to move more sites to HTTPS, which is better for the safety and security of the web overall. Chrome is soon going to display "Insecure" for every single http site, which is another nudge to help move the web towards a secure future.
What 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.
The full list of registrars onboarded for .app, including annotations for those supporting EAP, is here: https://www.registry.google/about/register.html
It's just another fucking cash grab.
Outrage is great, but it's a good idea to read before firing off like this.
(You can use your TMCH SMD file to register your trademark.app for ~$20, but that’s not really what we’re taking about here.)
If you have a TMCH registered mark you can get your .app for ~$20, though.
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.
They're just auctioning off all the good names - same as every other domain squatting rent seeker...
So you have your answer.
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?
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.
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 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.
Authy OneTouch pushes you towards some fairly strong platform and vendor lock-in, which I always try to avoid.
Check out this older thread from 2014: https://news.ycombinator.com/item?id=8254757
"We're rolling out Google Authenticator support sometime in the fall." What happened? :(
Lots of registrars are in there that aren't part of the Early Access Program.
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?
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.
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.
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.
Except the part where the `.app` domain is only "https-only" in Chrome.
Chrome maintains the list that most browsers use, but it's not the only browser using the list.
Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's.
You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly.
As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo).
[0] https://github.com/mozilla/gecko-dev/blob/master/security/ma...
What are examples of Google's use of EEE?
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
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."
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.
Like Google+?
Just having the best app isn't EEE.
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.
Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.
Google is an incredibly evil company and are hellbent on destroying the open web.
Chrome.
Sadly the Chrome team together with web devs everywhere are creating a web where "works best in IE6^h^h^hChrome" is making a very unwelcome comeback.
This should be so unnecessary in 2018.
I don't think the devs are necessarily doing this on purpose. I do however wish they'd be somewhat more considerate about the web ecosystem.
I'd also wish they hadn't used their dominant position in ads to push Chrome as "a better browser" for years to everyone including people who already used modern browsers.
AMP is embracing and extending website hosting.
Google News is embracing and extending free web news outlets.
Chrome is embracing and extending the open-source web browser community.
Android is embracing and extending the open-source mobile OS development community.
I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.
Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.
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.
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.
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?)
Chagos should get direct control of .io, but it is a weird political fight.
One awareness campaign: http://www.thedarksideof.io/
I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.
It's fine if people want to raise awareness to Brits behaving badly. But saying .io should go to those people is misleading.
That is much closer to the ccTLD original intent than any of the British territories have seen (.io, .vg, etc). It's not misleading to suggest that the territory control their own ccTLD's destiny, given that was the original presumption of the early IETF and many of the original NICs.
Of course it's not a "natural" resource as a digital artifact of the internet economy, but that doesn't mean the ccTLDs weren't intended to be a resource to a specific locality, and that that specific locality shouldn't most control or best benefit when that ccTLD is exploited by foreign interests find a different use/meaning/domain-hacks for that TLD.
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. :/
[0]: https://scotthelme.co.uk/im-giving-up-on-hpkp/
I'm still disappointed. I don't feel expect-ct effectively covers the same use cases.
Edit: It appears this pre-registration doesn't even guarantee you'll get the domain. It just increases your chances :( I'm gonna pass...
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").
https://www.registry.google/about/register.html
From what I can tell, the only enforcement is this gentleman's agreement between the browsers.
General information about HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
But you are right that it is a browser thing.
It'll cost you a cool $1,790.88/year. I wonder how much of that goes to Google.
Apparently the "additional fee" for early access is extraordinarily high from some registrars.
For example -> https://imgur.com/a/E9WRqTI
$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
https://shop.gandi.net/en/domain/suggest?search=whatthefucki...
Taking recommendations for what to do with my new domain, donaldtrump.app
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
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.
Can somebody explain this claim? How does HTTPS protect against malware? Does no malware use HTTPS, so it all gets blocked?
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...
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.
[1] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
[2] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
[3] https://www.godaddy.com/dpp/find?checkAvail=1&tmskey=&domain...
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?
Maybe 13k gets you a fully registered domain, and the £650 is like buying an option or a chance to be in the running.
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.
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.