Google WhoIs Protection Doesn't Protect

So, I own the domain ribbeh.com but not its content. All my domains I've registered through google (and they then register it with enom) because it used to be pretty simple to register and then configure, it was a consistent $10, they didn't try to upsell me a gazillion things, and their auto-renew policies are kind. (I lost a domain to iDotz before. Never Again.) Additionally they provided whois protection for free. I don't really care about that these days but it was more important to me then (and should have been more important to an old acquaintance I once freaked out when I discovered their name and address simply by checking whois...), in any case it's a nice to have, especially because I hate being forced to be dishonest to protect something. The last name I gave Google was fake as you'll see, but the address used to be a place I lived.

Tonight I was going through my spam folder because gmail's spam filtering has gotten a lot worse than it once was. Found a non-spam email of course. And then I found a spam email about the above domain name expiring this month and telling me to click a link to pay for renewal. (If you actually check the whois, you'll see that it doesn't expire until January.)

What startled me was that it contains the very fake last name and once real address (from which you could infer my last name of course if you wanted to do it the hard way) that google knows, but isn't part of the public whois record. So what gives? How did the info leak? Was there a DB breach I didn't hear about? Or is it trivial to just contact the whois privacy agents and get the real data?

See Full Post and Comments

Tooling is the problem, not the type system

I'm firmly in the dynamic typing camp, but I also recognize that some dynamic languages like JavaScript leave a lot to be desired. I think that almost all of the things that might be desired can be addressed with tooling, however, and that tooling can be addressed in three ways.

The first way is on the language level. This is best because there's nothing more to do. Common Lisp is more than just a language, it's also a runtime, and a compiler, and the runtime itself ships with a COMPILE function. Normal operation is to COMPILE every piece of Lisp code into assembly and execute it with runtime wrappers (just like C compilers end up converting C to assembly with runtime wrappers around things like calling conventions). The artifacts that go along with being COMPILED let you later tell the runtime to TRACE something, or profile something, or BREAK and debug something step by step (with other much richer debugging options than you normally get with gdb or eclipse with java), they let you ask the runtime "who calls this function?", or "where is this thing referenced?", or "who sets this?" The answers to those questions will be complete as of right now because you're asking a living program.

In Java Land, I commonly ask about who calls what, or to find references for something. It's often slow, and that's even after it's done its indexing work. Yes, in Java Land these questions are derived statically, which means they can be wrong because you might not have statically seen everything, in addition to they might be wrong if they're stale because you're asking again in the future. With Lisp, you just have the second possibility of wrongness. Another advantage is that you tell the Lisp compiler how you want your source compiled right there, in the source, so you can of course tell it to optimize purely for speed and no safety and perhaps not full support for everything that might only be useful at development time.

See Full Post and Comments