Live data from Hacker News

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

blog.google

131–140 of 378 posts

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

#131

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 know TLD's doesn't affect SEO, but does Google enhance .app domain SEO when people search for apps on Google search?

> I know TLD's doesn't affect SEO

So you have your answer.

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

#132

It is very strange. 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?

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.

It looks like it, indeed.

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.

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

#133

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 reaps the fees

AFAIK Google does not have a monopoly on .app registrations:

https://get.app/

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

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

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

#135

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.

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

#136
post #42

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

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.

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

#137

Earlier quoted context omitted.

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

Gmails embraces and extends regular email with new features that only work when sending Gmail to other Gmail users.

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

#138
post #16

Earlier quoted context omitted.

trust me, it's on the backlog to fix.

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

We introduced an alternative to 2FA SMS - Authy OneTouch. We're working on adding TOTP as well.

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

#139

Here is a small script for the Terminal lovers. #!/bin/bash DOMAIN="${1:-google}" RESPONSE=$( curl -XGET -s \ -H "Accept-Language: en-us" \ -H "Accept: */*" \ -H "Connection: keep-alive" \ -H "Host: domain-registry.appspot.com" \ -H "Origin: https://get.app" \ -H "Referer: https://get.app/" \ -H "User-Agent: Mozilla/5.0 (KHTML, like Gecko) Safari/537.36" \ "https://domain-registry.appspot.com/check?domain=${DOMAIN}.a…

Simpler:

    $ curl -sL https://domain-registry.appspot.com/check?domain=$DOMAIN.app
    {"status":"success","available":true,"tier":"standard"}

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

#140
post #89
post #73

Earlier quoted context omitted.

Except, .sh means nothing in particular in Linux. It just so happens people use .sh for shell scripts.

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