Live data from Hacker News

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

blog.google

361–370 of 378 posts

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

#361
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…

As nice as an HSTS preload list is, using .app and .dev for this is infuriating.

Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.

Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...

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

#362

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…

Considering your "Go to curb.app" solution, to be brutally honest I think at least 50% of the world has no idea what the difference between "Go to curb.app" and "Download the Curb app" is. They are both practically the same. "Guarantee that I won't be tricked away by a scammer" - yeah, no. There are already too many TLDs to squat on that remove any usefulness of a "short and memorable name" on a new one.

I feel like there's some sort of legitimate blockchain solution to be had here that doesn't involve a centralised authority. Who got there first, what domains they have owned continuously, and what products they control perhaps...

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

#363

Earlier quoted context omitted.

Is there any precedent for a TLD owner doing what you describe? I think this is HSTS preload and nothing more.

Yes: http://www.cbsnews.com/news/daily-stormer-being-dumped-by-go... https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stor...

They violated terms of use. What's the problem?

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

#364
post #363

Earlier quoted context omitted.

Yes: http://www.cbsnews.com/news/daily-stormer-being-dumped-by-go... https://www.cnbc.com/2017/08/14/godaddy-boots-the-daily-stor...

They violated terms of use. What's the problem?

No problem. I was just answering parent's question about precedent.

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

#365

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.

It's weird how Facebook is getting all the heat but Google is the real snake in the grass. When Google bans you, they delete your drive, Gmail, photos and everything associated with it including the ability to search. Also they are associative; if one of your accounts are banned then any account, even business accounts, are all purged. One of a startup in my previous cohort was completely deleted after one of it's em…

Are you saying that Google banned the whole organization based on the association of one employee with a banned account? And they withheld your data with no recourse? Did you consult a lawyer?

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

#366

Earlier quoted context omitted.

It's weird how Facebook is getting all the heat but Google is the real snake in the grass. When Google bans you, they delete your drive, Gmail, photos and everything associated with it including the ability to search. Also they are associative; if one of your accounts are banned then any account, even business accounts, are all purged. One of a startup in my previous cohort was completely deleted after one of it's em…

Are you saying that Google banned the whole organization based on the association of one employee with a banned account? And they withheld your data with no recourse? Did you consult a lawyer?

It's a widespread issue:

http://www.slate.com/articles/technology/future_tense/2013/0...

https://www.perrymarshall.com/2270/google-bans-your-account/

https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_...

Just curious, how can you even get a lawyer for issues like this? And in US it would all be a sham show (like the Zuckerberg senate hearing)

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

#367

Earlier quoted context omitted.

I mean why would Chagos, free of ever having the British, end up with IO as a country code?

Well, there aren't any obvious alternatives, for one thing: .ch is Switzerland, .ca is Canada, etc. I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.

Ok but that sort of takes away the entire argument that .io "belongs" to these people somehow. It doesn't, it's purely a political issue. It's not some natural resource or anything they'd have claim to otherwise. (And seems that Mauritius might have claim, meaning no extra ccTLD.)

It's fine if people want to raise awareness to Brits behaving badly. But saying .io should go to those people is misleading.

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

#368

Earlier quoted context omitted.

Well, there aren't any obvious alternatives, for one thing: .ch is Switzerland, .ca is Canada, etc. I don't know, it's a problem for politicians and standards bodies. Even if not "British", Chagos is still inside the "Indian Ocean", so the reason for the country code remains.

Ok but that sort of takes away the entire argument that .io "belongs" to these people somehow. It doesn't, it's purely a political issue. It's not some natural resource or anything they'd have claim to otherwise. (And seems that Mauritius might have claim, meaning no extra ccTLD.) It's fine if people want to raise awareness to Brits behaving badly. But saying .io should go to those people is misleading.

.vi is controlled directly by residents of the US Virgin Islands. The primary contact address is on St. Thomas, and the NIC follows some pretty restrictive domain naming rules to favor the residents of the US Virgin Islands. It's run by the local telecom and presumably all money generated from .vi revenue goes to the island economies.

That is much closer to the ccTLD original intent than any of the British territories have seen (.io, .vg, etc). It's not misleading to suggest that the territory control their own ccTLD's destiny, given that was the original presumption of the early IETF and many of the original NICs.

Of course it's not a "natural" resource as a digital artifact of the internet economy, but that doesn't mean the ccTLDs weren't intended to be a resource to a specific locality, and that that specific locality shouldn't most control or best benefit when that ccTLD is exploited by foreign interests find a different use/meaning/domain-hacks for that TLD.

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

#370
post #253

Earlier quoted context omitted.

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. ;-)

> It works with shell scripts.

No. It works with some of them, because, as the parent wrote, it’s just the automated equivalent of "let’s look at content of the file and guess what it is". It’s not perfect, and so doesn’t always work. If you write "echo 42" in a file, `file` will only tell you it’s "ASCII text".

We humans are used to identify things with their name. `.sh` is not necessary to execute a shell script; but it’s so convenient you must have a good reason not to use it.

Post reply on HN