Live data from Hacker News

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

blog.google

231–240 of 378 posts

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

#231
post #226

Earlier quoted context omitted.

> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement. .app will be HTTPS only fro…

> if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. Except the part where the `.app` domain is only "https-only" in Chrome.

It's not just Chrome.

Chrome maintains the list that most browsers use, but it's not the only browser using the list.

Firefox, Opera, Safari, IE 11, Edge, and others are all using HSTS-Preload lists based off Chromium's.

You can see for yourself that Firefox is preloading the `app` TLD in it's preload list at [0], and Opera is using the Blink engine, so it's using Chromium's list directly.

As for the other browsers, sadly they aren't open sourced so you can't see their exact list that they use, but seeing as they base their list off Chromium's, I'd wager that they will include this TLD in their lists as well soon enough. They both already include other TLDs which are in the HSTS preload list (like .bank, .google, and .foo).

[0] https://github.com/mozilla/gecko-dev/blob/master/security/ma...

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

#232
post #226

Earlier quoted context omitted.

> It does seem like a positive step, but to be honest the solution seems a bit clumsy and ineffective, closer to security theater than actual security. On it's own I could see the argument for it being more security theater, but if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. That's a real security improvement. .app will be HTTPS only fro…

> if I had an app on the ".app" TLD I can now stop listening on port 80 altogether without as much worry that I'm breaking stuff. Except the part where the `.app` domain is only "https-only" in Chrome.

This is more about expectations though. The idea is that you shouldn't make a request over HTTP to a .app website and expect it to succeed.

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

#234
Why is Google launching a TLD and you cannot purchase it through Google Domains?

It's currently showing as "Not Supported" even though they link to Google Domains from get.app.

It's mind-boggling to think they couldn't come up with a "coming soon" blip if somebody tries to look up a Google-owned TLD on Google Domains.

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

#235
post #172

Earlier quoted context omitted.

Should URLs end in .html?

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

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

#236

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.

Makes sense, given their mission to monopolize the internet.

Break up google.

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

#237

Earlier quoted context omitted.

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.

That's not competition in the browser space that's just giving Google more power.

Google is an incredibly evil company and are hellbent on destroying the open web.

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

#238

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…

.app was a tiny bit more expensive to acquire than that ... 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.goo…

> So a cynical profit motive is not why we're doing it

That's, if anything, less reassuring.

Google doing it to make money makes sense. THey are a for profit company, it's what they do.

Goodness of our hearts just makes me suspect it's more evil. Quit being evil google.

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

#239
Starting today at 9:00am PDT and through May 7, .app domains are available to register as part of our Early Access Program, where, for an additional fee, you can secure your desired domains ahead of general availability.

Additional fee:

hackernews.app is available! CA $25.72 per year (pre-registration) CA $16,082.01 (early access)

Helluva fee.

https://www.name.com/preorder/app?domain=hackernews.app&tld=...

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

#240

Arbitrarily picking web standards seems like an abuse of power. If this is the direction in which they want the internet to steer (a great one as far as I’m concerned) Google should advocate for the deprecation of HTTP in the appropriate bodies instead though. It baffles me that TLDs are at the mercy of private companies... I guess I should read more about the history of the internet to understand how this came to be…

> does anybody know of existing projects in this direction?

namecoin

Post reply on HN