I'm using PostgreSQL for my data warehouse. I needed a calendar table for doing joins and a quick way to populate it. So I created my calendar table with:
CREATE TABLE "CALENDAR" (
"YYYYMMDD" date NOT NULL
Then I populated it with the following SQL:
INSERT INTO "CALENDAR" ("YYYYMMDD") select to_date('20000101', 'YYYYMMDD') +
s.a as dates from generate_series(0,36524,1) as s(a);
This quickly puts records into the CALENDAR table for every day starting with 1/1/2000 and ending with 12/31/2099.
I've been thinking about all the Internet sites that I've created an account on for one reason or another. It has to be in the hundreds. Of those sites I wonder how many of them would let me delete my account completely. Very few I bet. Probably the most universal method of deleting my account--at a site I no longer want to have a relationship with and does not offer a "delete me" mechanism--is to poison the account with bogus information. I could change all the information about me to false information and, if allowed, change my e-mail address to something bogus as well.
In Rare Risk and Overreactions
Bruce Schneier writes, "If you want to do something that makes security sense, figure out what's common among a bunch of rare events, and concentrate your countermeasures there. Focus on the general risk of terrorism, and not the specific threat of airplane bombings using liquid explosives. Focus on the general risk of troubled young adults, and not the specific threat of a lone gunman wandering around a college campus. Ignore the movie-plot threats, and concentrate on the real risks."
I hate form spam. Whether the form is a contact form, a survey, or something else spamming can make life a pain. SANS has an interesting piece on techniques that can be used to reduce or prevent form spam. In my opinion the best solution is the one that has the least impact on legitimate users, is easy to implement, can be implemented in numerous ways, and has the highest negative impact on spammers. That's why I like the idea of including a form field that is required to be empty. To make it easier on legitimate users the field can be hidden using CSS. This way legitimate users aren't bothered with it, yet spambots are compelled to fill it in.
When was the last time you changed your e-mail password? If you're like most people, you probably can't remember. That means it's been too long. How about some external motivation? Consider the number of Internet processes that assume you have control of your e-mail account:
- e-commerce applications
- Web site membership enrollment processes
- domain registration and management
- hosting providers
What would happen if a bad guy figured out your e-mail password? He could change your password. But why would he do that when he could use your account at the same time as you. He could request a password change from any Web site that uses e-mail confirmations. Perhaps one of the worst things that could happen to you is to lose your domain name. Imagine if the bad guy transferred your domain name to another registrar into an account that he controlled. How much damage would that cause?
Web browsers have become the de facto client interface to Internet based applications. As we travel around the Internet, whether for pleasure or business, we find ourselves creating personal profiles for various Web sites. These profiles usually include access credentials (usernames and passwords). Good password management practice calls for many distinct passwords. But this proliferation of passwords results in the need for strong password storage. In addition to password management we need to give some thought to encrypted communications.
I was recently tasked with increasing the up time of my employer's main Web site. The site uses a content management system that lives on two Windows/IIS servers. (I know, the system was purchased before I was hired.) One server is for making changes to content (design-time server) and the other is the public web site (run-time server). The design-time server has a complete copy of the site which is replicated to the run-time server. Unfortunately the run-time server has a habit of refusing to serve pages at the most inopportune times, usually when I'm on vacation or somewhere without a computer.