Introducing .app, a more secure home for apps on the web • Hacker News Board

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

#251

Post by zapita » Tue, May 01, 2018, 11:51 PM UTC

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.

Gmail is embracing and extending email.

AMP is embracing and extending website hosting.

Google News is embracing and extending free web news outlets.

Chrome is embracing and extending the open-source web browser community.

Android is embracing and extending the open-source mobile OS development community.

I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emails with directives as explicit as Bill Gates did.. But they don't have to, because the EEE playbook is now well-understood by the rank-and-file. When Gmail PMs gradually introduce more and more proprietary features into the product, gradually widening the gap in functionality with IMAP clients, they know what they are doing. It's not an all-out assault on open email above all else. But the end result is the same.

Bottom line, EEE in 2018 looks different than EEE in 2000, but it's there, and it's just as dangerous. We should not give Google a pass just because they're more subtle in their implementation.

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

#252

Post by underyx » Tue, May 01, 2018, 11:51 PM UTC

s2g wrote: post #242

simon_acca wrote: post #177

Earlier quoted context omitted.

That’s fair, given that HSTS is after all a standard itself and Google is merely applying it. Then I guess my perplexity is towards IETF in that they allow for two conflicting standards to exist. What if I want to use local.my.app for development; Or, in a more textbook example, i want to use workstation-1.building-a.my.internal.my.app without https?

Arbitrarily across an entire TLD. Because IANA decided to start selling off the web for companies to abuse. > What if I want to use local.my.app for development; You can switch to .dev... oh right.

RFC-6761 [1] reserves .example, .invalid, .localhost, and .test — the latter two seem like nice alternatives.

[1]: https://tools.ietf.org/html/rfc6761

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

#253

Post by rtkwe » Tue, May 01, 2018, 11:59 PM UTC

carapace wrote: post #235

hk__2 wrote: post #172

Earlier quoted context omitted.

Web servers respond to your requests stating what type of content they’re sending you. There’s no such thing for files on disk.

file? https://linux.die.net/man/1/file

File is still only a best guess at content and relies on the format being known and having some identifying features.

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

#254

Post by fiatjaf » Wed, May 02, 2018, 12:04 AM UTC

Why do we have TLDs at all? If ANY COMBINATION OF LETTERS is now a TLD, we should be able to register myname.whatever if I want to, or in fact just whatever as a domain.

Ok, ok, I'll pay GOOGLE, the owner of the internet, for doing this now.

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

#255

Post by cobbzilla » Wed, May 02, 2018, 12:14 AM UTC

paultopia wrote: post #214

sah2ed wrote: post #208

Earlier quoted context omitted.

Desirable domains are by definition scarce -- there is not enough of them to go round to those who desire them. The current approach is essentially saying "if you really desire domain X badly, put your money where your mouth is". Do you have an alternative proposal on how these desirable domains could be allocated more efficiently?

"Efficiently" is a concept defined only by your target. If your target is economic value, then, sure this kind of auction does a pretty good job at allocating efficiently with respect to it. If your target is something like desire-satisfaction, or promoting novelty/creative use, then it might be worth trying to think about ways to preferentially allocate to people willing to put in more effort too, or, e.g., introduc…

In what units do you measure "desire-satisfaction" and "promoting creative use"? How do you know that an outcome was optimal?

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

#256

Post by rmwaite » Wed, May 02, 2018, 12:27 AM UTC

zapita wrote: post #251

andybak wrote: post #114

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.

Gmail is embracing and extending email. AMP is embracing and extending website hosting. Google News is embracing and extending free web news outlets. Chrome is embracing and extending the open-source web browser community. Android is embracing and extending the open-source mobile OS development community. I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emai…

Careful readers will notice that you did not use the word extinguish in your reply.

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

#257

Post by foobarbazetc » Wed, May 02, 2018, 12:39 AM UTC

dcosson wrote: post #125

CydeWeys wrote: post #55

Earlier quoted context omitted.

I can't speak specifically for Google Domains as that's a completely different team that we have limited interactions with. What I can say is that we are currently in the Early Access Period, and that General Availability begins on May 8 at 16:00:00.000 Z. That's when you'd expect to see any remaining registrars not yet selling them start to sell them.

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 want the big bucks for EAP registrations ($10.8-$16k depending on registrar).

If you have a TMCH registered mark you can get your .app for ~$20, though.

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

#258

Post by chrisfinazzo » Wed, May 02, 2018, 12:57 AM UTC

CydeWeys wrote: post #19

dmurray wrote: post #4

> The big difference is that HTTPS is required to connect to all .app websites...Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way. This sounds good but how does it really help users or developers compared to having a .com website that uses HTTPS? Expecting that users will think "oh, .app, must be sec…

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 any discussion within the Registry or Search teams about how to address these kinds of situations?

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

#259

Post by brlewis » Wed, May 02, 2018, 1:19 AM UTC

segmondy wrote: post #229

Yeah, 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

#260

Post by zapita » Wed, May 02, 2018, 1:22 AM UTC

rmwaite wrote: post #256

zapita wrote: post #251

Earlier quoted context omitted.

Gmail is embracing and extending email. AMP is embracing and extending website hosting. Google News is embracing and extending free web news outlets. Chrome is embracing and extending the open-source web browser community. Android is embracing and extending the open-source mobile OS development community. I understand what you mean by "the intent is important", and certainly no senior Google executive is sending emai…

Careful readers will notice that you did not use the word extinguish in your reply.

There isn't a monolithic explicit strategy with the word "extinguish" in it. Instead there's a pervasive set of tactics which result in embracing, extending and, when successful, extinguishing open standards and communities.

Gmail is very far away from extinguishing open email, because that's such a huge target, but it certainly managed to make a dent. How many users have forever left the open ecosystem of smtp/imap/pop tools and service providers because of Gmail's growth? If Gmail hypothetically reached the market share necessary to mortally wound that open ecosystem, do we have any doubt that it would eventually do it?

And remember, email is the largest open ecosystem in my list. Where is the fully open alternative to iOS? Answer: it doesn't exist because Android captured all the momentum from the emerging community, and channeled it into a platform that is now closed for all practical purposes. In this case, extinction has already happened.