12 ms·

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

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 schema and maintainence is bog-simple). How is the coming Chrome modification not "tying"? Anyone familiar with anti-trust laws care to comment?

nathantotten 8y ago
> it is not necessarily Sure, but labeling a site as “Possibly not secure” wouldn’t be a very effective way of communicating the risks to users.
ucaetano 8y ago
> and reaps the fees AFAIK Google does not have a monopoly on .app registrations: https://get.app/ https://get.app/
- timdavila 8y ago
  Google owns and operates the TLD. Many registrars will sell .app names, but they pay a portion of every sale to Google.
detaro 8y ago
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.
- brlewis 8y ago
  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 https://news.ycombinator.com/item?id=16968262
- patrickg_zill 8y ago
  True, they will not get extra fees from sites running HTTPS. However, they will get extra fees from any .app domain registrations.
  - detaro 8y ago
    Yes. How does the HTTPS stuff relate to that in a way that increases those?
- chatmasta 8y ago
  An HTTPS-only web is very much in Google’s economic interest, as it vastly increases the barrier to entry of tracking users across the web, which is Google’s core business.
prophesi 8y ago
> (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.
- gkya 8y ago
  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.
  - dragonwriter 8y ago
    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.
    - gkya 8y ago
      Nope: > 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 This is what patrickg_zill's comment said, just with some newlines and emphasis to make it more understandable. The not necessarily does not refer to HTTP, it refers to non-.app domains. And there is no "criticism is directed at a fantasy", there is a cynical prediction which is completely possible in all respects. You---or I---may think that that'll never be the reality, but regardless, that's what the comment said, and the other commenter misunderstood. I don't get why I get downvotes and criticism for this.
      - prophesi 8y ago
        It still reads to me like they meant non-HTTPS connections, as that is what they mark insecure in concert with buying the .app domain. They -could- have meant .app, but we'd need the guys word to know for sure. It's not as straightforward of a comment as you think it is.
ballenf 8y ago
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.
- hahla 8y ago
  That preregistration amount changes based on the domain you are trying to register. More popular terms cost significantly more.
- icebraining 8y ago
  also indicated that $1000 was the yearly renewal price if one gets the domain through pre-registration. That's just on GoDaddy. "EAP is a one-time acquisition fee; you do not pay that on subsequent renewal." https://news.ycombinator.com/item?id=16971246 https://news.ycombinator.com/item?id=16971246
CydeWeys 8y ago
.app was a tiny bit more expensive to acquire than that ... http://www.businessinsider.com/google-just-paid-25-million-to-buy-the-entire-app-web-domain-2015-2 http://www.businessinsider.com/google-just-paid-25-million-t... We're not expecting to make our money back on this one. And these amounts are a drop in bucket compared to many other Google products anyway. So a cynical profit motive is not why we're doing it. We're doing it for the stated reasons, to move security forward on the Web; see https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... and https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html https://security.googleblog.com/2018/02/a-secure-web-is-here... Also, I could talk your ear off about the design of our infrastructure for hours. Suffice it to say, it's a lot harder than you're making it out to be, particularly as regards to scaling. Our registry platform is open source, so feel free to inspect the code at https://nomulus.foo https://nomulus.foo . And that's not even getting into DNS hosting, which involves a very large number of instances distributed around the entire globe.
- RyanShook 8y ago
  I'm seeing prices from $17 - $15,000 for preregistration and the pricing tiers seem very arbitrary... is there any documentation on how Google sets the pricing?
  - CydeWeys 8y ago
    Please see my top level comment here that I've since left. Note that registrars ultimately set the pricing that you see, which is why it's different across different registrars, same as if you wanted to buy, e.g., a .com domain.
- patrickg_zill 8y ago
  Thanks for the correction about the price. However, 10 years of 1 million domains, even if Google's cut is only $1 out of the registration price, is still $10 million per year * 10 years = $100 million. If Google's own registry is used and you capture more of the ($17/year ?) domain fee, it goes up by multiples of that. Correct me if I am wrong, but serving the DNS entries of .app will be almost the same as serving up a DNS entry for another domain like .com: the HSTS/https-only requirements will be set up in the browser, not the DNS server. And serving DNS has been handled successfully and profitably by Namecheap/GoDaddy/Moniker et al for years.

nathantotten 8y ago

> it is not necessarily Sure, but labeling a site as “Possibly not secure” wouldn’t be a very effective way of communicating the risks to users.

ucaetano 8y ago

> and reaps the fees AFAIK Google does not have a monopoly on .app registrations: https://get.app/ https://get.app/

timdavila 8y ago
Google owns and operates the TLD. Many registrars will sell .app names, but they pay a portion of every sale to Google.

detaro 8y ago

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.

brlewis 8y ago
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 https://news.ycombinator.com/item?id=16968262
patrickg_zill 8y ago
True, they will not get extra fees from sites running HTTPS. However, they will get extra fees from any .app domain registrations.
- detaro 8y ago
  Yes. How does the HTTPS stuff relate to that in a way that increases those?
chatmasta 8y ago
An HTTPS-only web is very much in Google’s economic interest, as it vastly increases the barrier to entry of tracking users across the web, which is Google’s core business.

prophesi 8y ago

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

gkya 8y ago
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.
- dragonwriter 8y ago
  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.
  - gkya 8y ago
    Nope: > 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 This is what patrickg_zill's comment said, just with some newlines and emphasis to make it more understandable. The not necessarily does not refer to HTTP, it refers to non-.app domains. And there is no "criticism is directed at a fantasy", there is a cynical prediction which is completely possible in all respects. You---or I---may think that that'll never be the reality, but regardless, that's what the comment said, and the other commenter misunderstood. I don't get why I get downvotes and criticism for this.
    - prophesi 8y ago
      It still reads to me like they meant non-HTTPS connections, as that is what they mark insecure in concert with buying the .app domain. They -could- have meant .app, but we'd need the guys word to know for sure. It's not as straightforward of a comment as you think it is.

ballenf 8y ago

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.

hahla 8y ago
That preregistration amount changes based on the domain you are trying to register. More popular terms cost significantly more.
icebraining 8y ago
also indicated that $1000 was the yearly renewal price if one gets the domain through pre-registration. That's just on GoDaddy. "EAP is a one-time acquisition fee; you do not pay that on subsequent renewal." https://news.ycombinator.com/item?id=16971246 https://news.ycombinator.com/item?id=16971246

CydeWeys 8y ago

.app was a tiny bit more expensive to acquire than that ... http://www.businessinsider.com/google-just-paid-25-million-to-buy-the-entire-app-web-domain-2015-2 http://www.businessinsider.com/google-just-paid-25-million-t... We're not expecting to make our money back on this one. And these amounts are a drop in bucket compared to many other Google products anyway. So a cynical profit motive is not why we're doing it. We're doing it for the stated reasons, to move security forward on the Web; see https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... and https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html https://security.googleblog.com/2018/02/a-secure-web-is-here... Also, I could talk your ear off about the design of our infrastructure for hours. Suffice it to say, it's a lot harder than you're making it out to be, particularly as regards to scaling. Our registry platform is open source, so feel free to inspect the code at https://nomulus.foo https://nomulus.foo . And that's not even getting into DNS hosting, which involves a very large number of instances distributed around the entire globe.

RyanShook 8y ago
I'm seeing prices from $17 - $15,000 for preregistration and the pricing tiers seem very arbitrary... is there any documentation on how Google sets the pricing?
- CydeWeys 8y ago
  Please see my top level comment here that I've since left. Note that registrars ultimately set the pricing that you see, which is why it's different across different registrars, same as if you wanted to buy, e.g., a .com domain.
patrickg_zill 8y ago
Thanks for the correction about the price. However, 10 years of 1 million domains, even if Google's cut is only $1 out of the registration price, is still $10 million per year * 10 years = $100 million. If Google's own registry is used and you capture more of the ($17/year ?) domain fee, it goes up by multiples of that. Correct me if I am wrong, but serving the DNS entries of .app will be almost the same as serving up a DNS entry for another domain like .com: the HSTS/https-only requirements will be set up in the browser, not the DNS server. And serving DNS has been handled successfully and profitably by Namecheap/GoDaddy/Moniker et al for years.