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…
Introducing .app, a more secure home for apps on the web
261–270 of 378 posts
Re: Introducing .app, a more secure home for apps on the web
#262Earlier 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…
Like Google+?
Re: Introducing .app, a more secure home for apps on the web
#263Why 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://" ?
Re: Introducing .app, a more secure home for apps on the web
#264Sigh. 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…
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
#265Yeah, 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.
Re: Introducing .app, a more secure home for apps on the web
#266Earlier 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.
Re: Introducing .app, a more secure home for apps on the web
#267This 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
Re: Introducing .app, a more secure home for apps on the web
#268Yeah, 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.
Re: Introducing .app, a more secure home for apps on the web
#269Earlier 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 ?
Re: Introducing .app, a more secure home for apps on the web
#270Earlier 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.
Outrage is great, but it's a good idea to read before firing off like this.