Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.google

Post reply on HN
Print view View original

161–170 of 378 posts

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

#161

Post by simon_acca »

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?

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

#162

Post by ohitsdom »

komali2 wrote: post #153

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

Right beneath the domain available message should have been a note that these domains aren't available for purchase until May 8th.

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

#163

Post by therealmarv »

fulafel wrote: post #42

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

HSTS can be enabled for whole domain. See here: https://hstspreload.org/#tld

General information about HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

But you are right that it is a browser thing.

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

#164

Post by peterwwillis »

Why can't they add a new URL scheme "secure://" to Chrome that will only support HTTPS?

Adding a new scheme would support all existing https websites on the internet today with no need to pay anyone money or rush to reserve domains.

This .app thing is needlessly difficult, and just a way for Google to push its brand on technology concepts en-masse, like the .dev fiasco. Now everyone in the world has to register a new domain (and make it work for their site) to make sure their URL is always secure.

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

#165

Post by patrickg_zill »

detaro wrote: post #134
patrickg_zill wrote: post #130

Is being cynical about this allowed? Google throws down a few hundred grand to get the .app domain, in concert with modifying their web browser to deliberately mark others' traffic as "Insecure" (it is not necessarily!), and reaps the fees now and in perpetuity ever year thereafter for maintaining a simple database of DNS glue entries which you literally could maintain using MS Access (by which I mean, the database s…

Google won't get extra fees from sites running HTTPS. There is no indication that they will make any difference between sites on TLDs that enforce HTTPS and any other site with HTTPS enabled. Anyone running a new TLD can make it HTTPS-only if they think that's something domain-buyers want. Where's the problematic way of making profit for them? I don't think being HTTPS-only will do much for the success of .app.

True, they will not get extra fees from sites running HTTPS.

However, they will get extra fees from any .app domain registrations.

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

#166

Post by samschooler »

andybak wrote: post #114
ocdtrekkie wrote: post #93

Earlier quoted context omitted.

It was Microsoft's strategy roughly twenty years ago. It's Google's strategy today.

Can you provide an example? Something more specific than merely competing with existing businesses. The intent is key in the original definition of EEE.

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.

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

#167

Post by dragonwriter »

gkya wrote: post #155
prophesi wrote: post #135

Earlier quoted context omitted.

> (it is not necessarily!) HTTP traffic -is- necessarily insecure. It's trivial for anyone on your network to run Wireshark and see/modify all of your traffic. And a lack of HSTS leaves your site potentially vulnerable to SSLstrip.

And we have the first person to confound not having a .app with not encrypting the connection here. The comment you replied to did not imply that HTTP is not necessarily insecure, it said that you can (quite obviously) use HTTPS with any TLD.

The comment referred to Google flagging other content as insecure; Google does that for HTTP content, not non-.app content.

The problem is either the “not necessarily” part is wrong (in regard to flagging HTTP) or the criticism is directed at a fantasy that isn't actually occurring (in regard to flagging things that aren't .app). Either way, the criticism is defective.

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

#168

Post by ballenf »

patrickg_zill wrote: post #130

Is being cynical about this allowed? Google throws down a few hundred grand to get the .app domain, in concert with modifying their web browser to deliberately mark others' traffic as "Insecure" (it is not necessarily!), and reaps the fees now and in perpetuity ever year thereafter for maintaining a simple database of DNS glue entries which you literally could maintain using MS Access (by which I mean, the database s…

And it won't take many registrations to recoup the investment. They're charging $999 / year at least for pre-registrations. I clicked through to the price using godaddy and the $16.99 / year price quickly got replaced by the higher number which also indicated that $1000 was the yearly renewal price if one gets the domain through pre-registration. (Your money gets refunded if you don't get the domain.) I'm sure godaddy gets a decent portion of the $1k, but damn.

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

#169

Post by RyanZAG »

prophesi wrote: post #156
gkya wrote: post #155

Earlier quoted context omitted.

And we have the first person to confound not having a .app with not encrypting the connection here. The comment you replied to did not imply that HTTP is not necessarily insecure, it said that you can (quite obviously) use HTTPS with any TLD.

I'm getting it from here: > modifying their web browser to deliberately mark others' traffic as "Insecure" I'm assuming the parent comment meant how Chrome marks HTTP connections as insecure; they're not marking TLD's that aren't .app as insecure.

I think the idea would be that Chrome would sooner or later mark non-HSTS sites like .app as 'half secure' or add a special extra greener bar for .app sites. Given Google's track record, I wouldn't really doubt it.

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

#170

Post by detaro »

patrickg_zill wrote: post #165
detaro wrote: post #134

Earlier quoted context omitted.

Google won't get extra fees from sites running HTTPS. There is no indication that they will make any difference between sites on TLDs that enforce HTTPS and any other site with HTTPS enabled. Anyone running a new TLD can make it HTTPS-only if they think that's something domain-buyers want. Where's the problematic way of making profit for them? I don't think being HTTPS-only will do much for the success of .app.

True, they will not get extra fees from sites running HTTPS. However, they will get extra fees from any .app domain registrations.

Yes. How does the HTTPS stuff relate to that in a way that increases those?
Post reply on HN