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

foo@bar.com

bar.com

Post reply on HN
Print view View original

131–140 of 301 posts

Re: foo@bar.com

#131

Post by not2b »

Sharlin wrote: post #29
lifthrasiir wrote: post #9

Earlier quoted context omitted.

Note that `foo@bar.com` is frequently used to get around the email address requirement, so it is not really for testing. I wouldn't be surprised if prominent websites block any address from example.com or so.

But people who know and use the words foo and bar are almost exclusively developers, so they should know better eveb when typing a fake address to a random form. But it’s easy to type reflexively, without thinking, so I’m not surprised people do it.

The fact that it is a valid address is a feature, as some sites that demand email addresses (so they can spam you) verify the address for correctness. People are intentionally choosing an address that appears valid, because it is valid. So, sorry to the guy who bought bar.com, but that's what he signed up for.

Re: foo@bar.com

#132

Post by CydeWeys »

nitrogen wrote: post #118
ludamad wrote: post #57

Earlier quoted context omitted.

I don't think fresh launches, even with bold new parameters, are always considered 'huge changes' in that sense. The fact that it could break local environment's was probably not even documented in those specific environments

There was a time when the creation of a new TLD was unthinkable, so it seemed safe to use a domain syntax internally that was never going to become a public TLD. Then the TLD money grab happened and what was assumed to be safely isolated wilderness was sold out from under everyone.

There never was such a time, and IANA never said "We won't make any more". TLDs have been continually created for at least the past two decades. Look up the history of e.g. .biz, .info, .museum, .aero, .mobi, .cat, .asia, all the various ccTLDs that are created as new countries form (.ss), etc. And none of that is even counting the new gTLD expansion round that kicked off in 2012.

Re: foo@bar.com

#133

Post by walrus01 »

KitDuncan wrote: post #18
CydeWeys wrote: post #14

This guy is really committed to the joke, seeing as how he could easily sell bar.com for millions of dollars. Note also that there is a .bar gTLD, and there is a foo.bar domain as of 2014 (though it doesn't seem to be hosting any content). I run the .foo gTLD, and bar.foo is a real domain (though admittedly not as good as foo.bar). There is no .baz; next round maybe?

How does one get to run a TLD?

form a company with enough money behind it, google "donuts llc"

then pay a lot of money to ICANN

Re: foo@bar.com

#134

Post by jedberg »

captn3m0 wrote: post #128
CydeWeys wrote: post #80

Earlier quoted context omitted.

.app, .dev, .prod, and .zip all had substantial volume of problematic traffic that was discovered during the Controlled Interruption period (which occurs prior to launch and consists of a wildcard DNS entry placed on the entire TLD). You would not believe some of the brokenness that was happening there. .zip may need some explanation -- apparently there are lots of library API calls out there that take a path string…

ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.

But it made them so much money!!

Re: foo@bar.com

#135

Post by giantrobot »

jdxcode wrote: post #130
giantrobot wrote: post #124

Earlier quoted context omitted.

I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dot something and attempts to treat it as a URL. A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip…

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

I think that ends up as user unfriendly as requiring the dot after the TLD. I don't read up on all the gTLDs so I didn't realize zip was one for the longest time. I think ICANN just went nuts with TLDs, especially ones like .app and .zip that have long-standing associations with ubiquitous file extensions. That combined with the "smart bar" just leads to trouble.

Re: foo@bar.com

#136

Post by lozaning »

CydeWeys wrote: post #77
Sharlin wrote: post #29

Earlier quoted context omitted.

But people who know and use the words foo and bar are almost exclusively developers, so they should know better eveb when typing a fake address to a random form. But it’s easy to type reflexively, without thinking, so I’m not surprised people do it.

I'll be honest, even I do this when it's a form that has an email requirement but that I don't otherwise care about at all. I'm not gonna sign myself up for spam. Sometimes example.com and whatever other testing TLD that comes to mind is blocked because they want something that could plausibly be a real email address, so I give them something that could plausibly be a real email address, like asfgjklahsfgjklh@asdfogh…

That's why I own fakefakefake.email it gives me some minor pleasure to provide this email address to people who insist on having an email address for me.

Re: foo@bar.com

#137

Post by Ekaros »

jdxcode wrote: post #130
giantrobot wrote: post #124

Earlier quoted context omitted.

I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dot something and attempts to treat it as a URL. A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip…

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

Re: foo@bar.com

#138

Post by basch »

jdxcode wrote: post #130
giantrobot wrote: post #124

Earlier quoted context omitted.

I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dot something and attempts to treat it as a URL. A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip…

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

or go back to left to right reading.

http//com.google.www.

vs

http//com.google.www./file.zip

Re: foo@bar.com

#139

Post by Chirael »

I’ve always wondered if “foo” and “bar” was specific to a certain (now older) generation of programmers and would eventually fade into obscurity. Or has that bit of programmer culture been passed on to newer generations too?

Re: foo@bar.com

#140

Post by CydeWeys »

throw0101a wrote: post #126
CydeWeys wrote: post #102

Earlier quoted context omitted.

This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet. See https://jdebp.eu/FGA/dns-use-domain-names-…

> This applies to every domain name though Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.) Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail. Now, with the post-Google TLD changes, if you type one of those things, and the loca…

This applies to any TLD though, not just .dev and .prod, not just gTLDs generally, and not even just real TLDs (that's right, you could be using a fake TLD on an internal network somewhere and the "creation" of a domain on that fake TLD on that network could cause your previously working hostname shortcuts to start failing).

Relying on DNS search lists to find the right host is a bad security practice that has caused security incidents even outside the context of the creation of new TLDs. It's best to always use fully-qualified domain names. A lot of people responsible for implementing DNS search lists in the first place now regret having ever created them.

More info at https://www.icann.org/en/system/files/files/sac-064-en.pdf (particularly section 4.1.3 and the preceding logic leading up to it).

Post reply on HN