Live data from Hacker News

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

blog.google

121–130 of 378 posts

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

#121

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.

Google Reader would be the often mentioned first example: Google entered the RSS reader market, became the best, added a bunch of features and really became "the" de facto place to read feeds. ...Then closed up shop and killed much of the ecosystem outright, directing people towards proprietary places to get their news like social networks or Google News. Hangouts did very much the same with XMPP, a move which a Goog…

Google Reader does not fit the pattern of EEE; if anything, it shows their failure to pursue it. EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system. What they actually did was lose a bunch of people for alternative readers, for Twitter and for Facebook.

AMP for email does seem a good example.

RCS is not developed by or supported exclusively by Google. They weren't even the first; Vodafone had it on their phones for years. Google is late to the party.

--

My opinion is not that Google is ethically above doing EEE; it's that they're often too disorganized and erratic to actually pull it off even if they wanted to.

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

#122

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.

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

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

I think it's used for UX reasons actually.. "Oh, I see this is a shell script" when listing a directory..

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

#124

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 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 as Google pushing for biased standards:

- Google AMP (not clearly EEE, but definitely anti-open web)

- Google Chrome (not quite EEE, but barrier to entry in browser market is now extremely high)

Some more clearly EEE examples:

- GChat (clear EEE strategy on XMPP)

- Google flights (EEE the travel industry)

- Google shopping (EEE affiliate offers)

- ....

Note that these examples are not solely "competing with an existing business" as you described, because the initial announcement of them was usually welcoming and open, e.g. opening with federated xmpp compatibility, promoting it, and then extinguishing it later. If developers back then had known google would shut down xmpp, maybe they would have put effort into building a better federated xmpp ecosystem instead of wasting time interoperating with google's system. That kind of bait and switch is the hallmark of an EEE strategy.

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

#125
post #32

Earlier quoted context omitted.

Trying to register via google domain says "Google Domains does not support the .APP ending". Is that on purpose (Google domain is listed on get.app as compatible) ? A cache issue ?

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?

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

#126

What if I put my app's REST backend on my .app domain? Are .app domains only allowed to host brochureware?

The only restriction with .app domains is that HTTPS is enforced when connecting from a web browser. We definitely encourage you to use .app for more than mere brochureware, and of course we also encourage you to encrypt all APIs (REST or otherwise). This will be enforced by browsers if said APIs are being hit from a webpage.

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

#127

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…

Barrier to enter browser market is now just fork Chrome source and apply your logo, thanks to Google (see Opera, Brave and hundred others as an example).

Other examples are simply competitive products, nothing EEE about having a generic product in your portfolio.

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

#128
post #96
post #63

Earlier quoted context omitted.

So would someone be able to register on namecheap and have a chance at a .app domain against someone that used priority pre-registration at godaddy?

The GoDaddy thing is basically, "Pay us extra and we'll click for you automatically on May 8th." It's like paying Southwest Airlines $15 to check you in right at t-minus 24 hours before your flight...

[deleted]

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

#129
post #96
post #63

Earlier quoted context omitted.

So would someone be able to register on namecheap and have a chance at a .app domain against someone that used priority pre-registration at godaddy?

The GoDaddy thing is basically, "Pay us extra and we'll click for you automatically on May 8th." It's like paying Southwest Airlines $15 to check you in right at t-minus 24 hours before your flight...

They say they will completely refund you if you don't get the domain.

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

#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 schema and maintainence is bog-simple).

How is the coming Chrome modification not "tying"? Anyone familiar with anti-trust laws care to comment?

Post reply on HN