Live data from Hacker News

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

blog.google

151–160 of 378 posts

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

#151

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.

I can:

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.

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

#152
So, Google paid big bucks to secure a juicy top-level domain name. Now it says it's good because "hey, if you pay us money, we'll get you in our registry, call you secure, prominently display you in search (not now, but logical next step), and pretend it's all for great good and not to extend and protect our dominance".

IANA's decision to expand and auction off to-level donations was a horrible idea.

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

#154
post #140
post #89

Earlier quoted context omitted.

It just so happens people unnecessarily use .sh for shell scripts.

Why would that be unnecessary? Are we supposed to use extension-less filenames and then guess their type every time by looking at their content?

Should URLs end in .html?

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

#155

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…

> (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.

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

#156
post #155

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.

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.

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

#157
post #134

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.

Anyone running a new TLD can make it HTTPS-only if they think that's something domain-buyers want

How does that work? I thought they needed cooperation from browser makers.

Edit: explained here: https://news.ycombinator.com/item?id=16968262

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

#158
post #57
post #47

Took me a while to figure out that Google Domains isn't participating in the Early Access Program. Apparently the "additional fee" for early access is extraordinarily high from some registrars. For example -> https://imgur.com/a/E9WRqTI

have you checked other registars? it's about 20eur on gandi. https://shop.gandi.net/en/domain/suggest?search=whatthefucki...

Cheers for this link.

Taking recommendations for what to do with my new domain, donaldtrump.app

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

#159
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.

If I read correctly they meant the opposite, i.e. marked insecure if not .app.

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

#160

Earlier quoted context omitted.

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.
Post reply on HN