Handy.

I'm rather fond of http://www.fakenamegenerator.com/

It gives names, (probably fake) addresses, credit card numbers, as well as a bunch else. It allows CSV export if you want up to 50,000 identities generated. It gives you options regarding the country too.

Definitely. I used to work with the people making fakenamegenerator.com, and I never realized how much it really tells you until getting a bit into the code. A fantastic site, to say the least.

What are the odds that it gave me the same birth date as my actual birth date? Month and day, but not year. That's quite the coincidence, though I suspect it's only something like 1:60.

1/365 I'd think. There are 365 days in a year and it has to match exactly one day. You might be interested in the Birthday Paradox though http://betterexplained.com/articles/understanding-the-birthd...

Birthdays are not uniformly distributed. http://www.panix.com/~murphy/bday.html

Yes, but the probability that it found the same month and day as iLoch's, depend on the uniformity and independence of the month/day generator, not the distribution of actual birthdays.

Yeah my guess was based on the birthday paradox. Though now I see that yes the software probably chose a random number between 1 and 365 so the birthday paradox wouldn't apply.

That would be 1:365.24

It would be 1 in 365, but leap years mess it up a bit.

Leap days are generated at the same frequency as regular days as far as I can tell. That simplifies things again to 1:366

That's neat, but be careful how you use this. Remember that there are real people living or working at these addresses.

That's partly why my "go to" fake US address is 1060 W Addision, Chicago, IL, 60613.

There's still real people working there, but they've been dealing with this for 35 years now I suspect: http://www.imdb.com/title/tt0080455/quotes?item=qt0320055

I don't need IMDB to know what that is, and I'm not even wearing sunglasses!

Also the lovely 623 E. 68th Street, NYC in the East River.

Ah, the headquarters of the Usenet Administration!

Indeed!

From time to time, I need to lease VPN services, VPS and so on. And I choose to do so pseudonymously, paying with Bitcoin. But bizarrely, sometimes providers want contact information. I need valid information, of course. And I do provide a working email address. But it's rare that a telephone number will be used. Sometimes I have setup VoIP. But mostly I just need a telephone number that won't raise alarm, if called. So I tend to pick restaurants that have recently failed, business hotels or hostels.

Sometimes I need a valid return address for mailing cash. In that case, I pick a homeless shelter or other charity. That way, if the letter is returned for whatever reason, the money goes to a good cause.

Valid address, why? I've used preloaded cards in the past and have never had issues making up addresses.

Maybe I'm just paranoid :)

If I were building a system that required addresses, I would validate them. Why bother asking, otherwise?

I'm guessing that OP's system is designed for systems that require validated addresses.

Edit: Once or twice, using gift cards, it's been necessary to speak with customer service before they'd accept the payment. That required a VoIP account. I only did that because I needed a VPS in a particular IP range.

> But bizarrely, sometimes providers want contact information.

And you trust those providers?

If you need to trust the provider, you're probably hosed already. (Depending,of course, on who your adversary is. Random untrustworthy VPN services are probably OK if you're just trying to protect against corporate network snooping or WiFi Pineapples at Starbucks. I'd be a little less sure about whether they'd protect you against a determined MPAA rights holder lawyer. If your adversary is a nation state, you need better advice about opsec than you'll get from a random like me on a website...)

I write a lot about this issue! Compartmentalization is a key aspect of good OPSEC. Trust partitioning, for example.

Consider Tor. Each circuit involves three relays aka ORs aka nodes: entry guard, middle relay and exit relay. An adversary could deanonymize a user by combining information obtained from the three relays used by one of their circuits to some honeypot.

One cannot trust any particular Tor relay to refrain from logging and cooperating with adversaries. However, the Tor design mitigates those risks by using three relays in a chain. An adversary would need logs from all three relays in a circuit.

One can also use nested chains of VPN services. That's far less anonymous than Tor, for many reasons. Tor creates circuits more-or-less randomly, and by default they change at ten-minute intervals. VPN chains, conversely, are typically static. But the bandwidth is much greater.

And then one can use Tor via VPN chains, and route VPNs through Tor. Also, although routing Tor through Tor doesn't work well or do much good, one can proxy through remote desktops on VPS. Latency sucks, but you get used to it.

I don't trust any provider :)

But yes, I tend to trust those providers less.

It seems odd to accept Bitcoins, and yet want contact information. And some of these providers actually emphasize that they're privacy friendly! But I suspect that it's just that they're using stock software that needs contact information to create accounts. Also, Bitcoin is just one payment option, and credit/debit card payments do require contact information.

So? There's real people living and working at every address.

This was fun, the first random dude it came up with for me was an improbably cool 81 year old (occupation Chef, car 2015 Dodge Charger - not actually an option in the country he's located but still, cool car).

This could be used to generate test data. I hope nobody would be tempted to use it for dubious purposes of any kind.

Edit: Oooo, another legitimate use occurs to me - help generate story ideas (or at least flesh out fringe characters) for authors.

I recently hit an odd accident that turned into a cautionary tale about test data.

Someone was testing one part of a new ecommerce system, at precisely the same time someone else was testing another part. No-one noticed until DHL returned a package that was addressed to the Death Star.

They still charged us shipping, but atleast we didn't have to swallow product cost too. But it did make me look at "random test data" quite differently.

Snap - I use [email protected] with the Pentagon's address.

In the interest of client-friendliness I also use Disney addresses, with names such as Ms. Sleeping Beauty. So with my test data stuff would get delivered by DHL to fictional people in these places with people signing parcels.

I use real addresses so I can check postage rates are correct. It would be really useful for me if there was a standardised list of test addresses used across industry and in the media. Doubly so if you had test code that worked on such a known list of test cases, adding address records for 'customers' without having to enter one's own test data.

Why would you put garbage in your production databases?

It wasn't supposed to be production. From what I gather, someone made sure the queue was empty before witching their component to the live system temporarily. Someone else managed to get a test order in, in the seconds between the check and the switch.

Add random errors to this, and you have the perfect way to test a universal address parser.

This is the only valid/legal/moral use case I can imagine for this project, but a good one.

What if you wanted to create an app that allows people to "crowd-fund" gifts to be mailed to random residential addresses with a note inside that contains a unique URL that the person can enter into their browser to visit a page explaining the gift and offering them a way to say thank you to all the givers?

Most addresses aren't households; of the ones that are, a great number of those aren't currently inhabited. A lot of packages would be sitting at the doorsteps of new townhouse developments or vacant apartments.

Instead of calling it a "valid" address, you should call it an "actual" address.

I thought at first this would generate real looking addresses that would pass automatic validation, but not actually be anywhere.

This is quite different!

I think it's fine. Well, "validity" is contextually sensitive of course. For example, if I want to test addresses against a regex I'm developing then, yes, they are valid but if I want to test my mapping application that geocodes addresses then made up addresses are "invalid".

Since the whole point of an address is that it resolves to a particular geographical location then I would have expected a "Random Valid US Address" to be able to be geocoded.

The same can be said about credit card or social security numbers - that they should validate to actual cards/people, yet a generator would be expected to not do that, but only produce series that match validation criteria.

Incidentally, Fakena is the name of a tiny village in Burkina Faso, Africa.

In a similar vein:

https://github.com/mindcrime/DummyDataGenerator

Generates names, addresses, phone numbers, email addresses, etc. But the addresses are not guaranteed to be valid, although many of them will be by happenstance. Same for phone numbers.. some will be valid by chance, but may will not. The emails generated by this program, OTOH, are most definitely guaranteed to not be valid, since they all use @example.com to prevent accidental spamming.

1st hit: a church

2nd hit: some normal-looking house

3rd hit: a church

Are there more churches than homes in the US? :)

How does this work? Where are the addresses pulled from?

You can get addresses from Google if you supply the coordinates. I don't know if this is how they do it, but it would be easy.

Google has false positives on addresses all the time. (What you say is true, though, but also goes against their ToS to build up a list like this.)

It says "random". I assume that the valid fields are defined using some syntax or another, and then populated from random generators or lists.

I use https://randomuser.me/ which gives me faces as well as everything else. Also the API lets me pick a nationality which is neat (for some reason not on the website it seems)

The passwords it generates (from this page: https://fakena.me/random/) are totally unrealistic. Better would be "qwerty12345" and "footba11"!

Was shown this address but it isn't valid:

    C/o Wlrk 51 West 52nd Street
    New York, NY 10019-0000

Curious where the data comes from. The USPS reserves almost all rights on addresses and only releases them to licensed vendors for certain uses, and I doubt this is one of them.

Even licensed vendors don't get the full list, they get an encrypted database of the address and a C library with which to query it. (Source: I worked for such a vendor and wrote code to interface with said C library.)

Getting a really large list of valid residential addresses in the united states is 100% completely trivial.

For example, all the registered voter databases are for sale or free (though generally only allowed to be used for "political purposes", and not "commercial purposes", if you get them from the state themselves).

> Was shown this address but it isn't valid

Wachtell, Lipton, Rosen & Katz would disagree with you: http://www.wlrk.com/

But perhaps you were referring to the fact that there should be a newline between the care-of and the street address?

    c/o WLRK
    51 West 52nd Street
    New York, NY 10019

Doesn't the US Census Tiger data contain everything you'd need to create "actual" US addresses?

Here is the german edition.. also with credit card numbers, Bank account and ID no. They are all real, cvv does not match and they are randomized off course.. Cheers! http://fake-it.biz/

I can imagine that you'd run into all kinds of legal issues when you use the address of some unknowing stranger as your own for whatever, probably not the most trustworthy, purpose.

Would not use.

I think that in every case where you're not entering into an agreement where you assert that

1) The physical address provided is an address at which you can receive correspondence or packages.

and

2) The information supplied is -to the best of your knowledge- correct.

and

3) You agree if you have knowingly supplied false or incorrect information, you will be subject to penalties or damages claims.

you'll be just fine.

4 Yawkey Way Boston, MA 02215

Cool.