Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.google

Post reply on HN
Print view View original

301–310 of 378 posts

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

#301

Post by [deleted] »

CydeWeys wrote: post #264
makecheck wrote: post #249

Sigh. As I’ve said before, we need stronger identity profiles and user agents that verify much more than legitimate-sounding names. A name alone should effectively be treated like it could be completely and utterly fake , period. Yes, they’re requiring "https" but it’s not like it is hard to acquire a certificate anymore. All the ".app" domain will do is screw app developers into paying to register their chosen name…

HTTPS and SSL certificates are primarily used for encrypting the connection, thus protecting your data from snooping and modification in transit. They are not actually that useful for authenticating identity. Users tend to simply ignore the padlock icon, which is why Chrome is moving away from an affirmative security display model (which users don't pay much attention to) to displaying prominent warnings for insecure…

[deleted]

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

#302

Post by notatoad »

simon_acca wrote: post #177
therealmarv wrote: post #171

Earlier quoted context omitted.

It's not arbitrarily. You can use the standard HSTS to be applied domain wide https://hstspreload.org/#tld

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?

>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?

uh... don't do that?

if you're developing locally or internally, use my.app.local or workstation-1.building.internal. If you want to use public domains for non-public things i guess go ahead, but you can't expect everybody else to support your weird thing. Or if you really need to run your internal dev stuff on public domains, get a certificate for it.

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

#303

Post by _o_ »

benologist wrote: post #113
scarface74 wrote: post #103

Supporting https is only an infinitesimal part of what makes downloading apps on the internet like playing Russian Roulette. It still doesn't prevent unsuspecting users from downloading malware, adware, ransomware, and apps that siphon user data. It also doesn't prevent users of sites depending on third party ad networks from being a victim of the same vulnerabilities they are now.

Later google will launch .ampp for apps that are certified to only have Google and their thousands of partners sharing your PII 'securely'.

I really like the .app idea, it will save me some time.

echo ".app" >> lists/google/domains

/usr/local/xxxxxxxxx/ufdbConvertDB.sh

service ufdbguardd reload

Problem solved. It is just a matter of fashion, black or white dress? Last few years, black fits better.

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

#304

Post by sam_goody »

ryannevius wrote: post #3
dmart wrote: post #2

Excellent, this will surely cause no confusion with macOS executables.

I'm not sure how a .app TLD could be mistaken for a .app executable.

Apple Finder (magnify glass in top right) by default will search both local executables on your computer, and (as a second best option) the net. If a user sees *.app in finder, they might be very well getting something they don't expect.

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

#305

Post by _o_ »

CydeWeys wrote: post #174
patrickg_zill wrote: post #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 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…

But not only to take care of internet security, but also to protect our children from terrorist and pedophiles, right? I wonder where I have heard similar use of wording that introduced a bunch of new laws harmfull for anything related with freedom...

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

#307

Post by carapace »

rtkwe wrote: post #253
carapace wrote: post #235

Earlier quoted context omitted.

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.

It works with shell scripts.

Having a name ending in '.sh' is less reliable than the output of file for identifying shell scripts, since any file can be named with that ending.

cat199 said '.sh' is unnecessary and that is correct. I am surprised that this is controversial. (except wait, no, this is the internet... I'm not surprised. ;-)

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

#309

Post by cornholio »

danShumway wrote: post #293
CydeWeys wrote: post #264

Earlier quoted context omitted.

HTTPS and SSL certificates are primarily used for encrypting the connection, thus protecting your data from snooping and modification in transit. They are not actually that useful for authenticating identity. Users tend to simply ignore the padlock icon, which is why Chrome is moving away from an affirmative security display model (which users don't pay much attention to) to displaying prominent warnings for insecure…

> Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores. Now imagine it's a year or two from now and you have the exact same problems that you had with curb.com. What's the strategy for when .app gets mined out? Are we just going to keep creating new tlds over and over for eternity? Bear in mind that the only way .app won't get mined out…

> Are we just going to keep creating new tlds over and over for eternity?

Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes.

In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squatters will always capture a rent, by guessing domain names that will be valuable latter on. The way to minimize that rent on the long run is to periodically reset the game by bringing new TLDs into existence, thereby devaluing the investment in older TLDs, thereby making squatting a more risky activity. The GTLD liberalization greatly diminished the price pressure on .com .org and the like.

Keep in mind the web has seen exponential increase in the last decades; the upside now is much more limited, maybe another order of magnitude until complete worldwide market saturation and web growth figures get more inline to global economic growth numbers. Once that is achieved the problem becomes much less serious.

Post reply on HN