Live data from Hacker News

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

blog.google

261–270 of 378 posts

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

#261

Earlier quoted context omitted.

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

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…

I have some really old sites myself running on Jetty 5. I recently put them behind nginx and set up letsencrypt. It wasn't terribly difficult.

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

#262

Earlier quoted context omitted.

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 Goog…

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 eve…

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

Like Google+?

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

#263

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

How would "secure://" differ from " https://" ?

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

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

#264

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…

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

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

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

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

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

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

#265

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.

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

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

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

#266

Earlier quoted context omitted.

The right hand cannot talk to the left hand in this case, however. It's a complicated space to operate in. Start here if you're a policy wonk: https://archive.icann.org/en/topics/new-gtlds/gac-board-regi... Whether registrars support EAP, and how they implement it, is entirely up to each registrar. If you have complaints about any specific registrar practices, or about registrars not supporting it full stop, then tho…

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.

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

#267
post #233

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

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

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

#268

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.

This is as usual skewed towards big players with lot of money to dump into buying every available .app domain to make some fucking money. As usual the small guys have no chances and it is not first come first serve only. Google just pays lip service but they are just a fucking bunch of liars.

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

#269
post #32

Earlier quoted context omitted.

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

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 ?

You can register at the registrars marked at EAP. Gandhi is one for example.

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

#270

Earlier quoted context omitted.

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?

They put this announcement out so they can sell spots on the "Priority Pre Registration" list for $16,000. It's just another fucking cash grab.

For end users it costs ~$20, right now from one of the EAP registrars.

Outrage is great, but it's a good idea to read before firing off like this.

Post reply on HN