Google is getting rid of its 2038 cookies. That’s the year 2038, when Web browser cookies created by its Web sites over the past decade were set to expire. From now on, Google’s cookies will only last for two years from the date of your last visit to a Google site.
Does that really change much for Google users? No. But it should be a warning flag for corporate IT.
Consider this:
Why did Google cookies last until 2038? Because that was the latest they could expire. (The technical explanation: A cookie date is actually the number of seconds since Jan. 1, 1970, stored as a signed 32-bit integer with a maximum value of 2,147,483,647. So beyond 3:14:07 a.m. on Jan. 19, 2038, things get unpredictable.) Google’s developers didn’t have to make those cookies last as long as possible. It was just more convenient to do it that way.
That’s not the official explanation, of course. “We set the expiration far into the future — in 2038, to be exact — because the primary purpose of the cookie was to preserve preferences, not to let them be forgotten,” wrote Google privacy guru Peter Fleischer in a blog entry last week announcing the new policy.
Well, sure. But in practical terms, a cookie that expires after two years is just as good at preserving preferences as one that lasts for decades. In fact, since users are likely to change both their preferences and their PCs over long periods of time, cookies that last practically forever aren’t really that useful anyway.
No, the real reason for Google’s 2038 cookies was convenience. It was just easier for developers to slap that date into every cookie.
And now, after a decade of grumbling from privacy advocates, Google is finally shifting from doing what’s convenient to doing what’s reasonable — and a little more secure.
Hold that thought. Now ask yourself this: How many risks are your IT people and users taking because those risks are convenient?
How often are Social Security numbers used as unique personal identification numbers just because they’re available and, well, they’re unique IDs?
How often is unnecessary sensitive data downloaded to spreadsheets on user PCs because that’s easier than filtering out the unneeded fields?
How often do Web developers collect customer information that may never be used because collecting it easy to do — and then store it unsafely because securing it is hard? Chances are, you don’t know. If it’s happening, it’s probably all going on under your radar.
Like Google, you have a culture of convenience when it comes to handling data. Unlike Google, you have no one complaining about it.
At least not until those Social Security numbers or other pieces of sensitive data end up on a stolen employee laptop or lost CD. By then, it will be too late.
But before then, changing that culture of convenience will be miserably difficult. No one will want to change — not your overworked IT staff, and least of all your busy users. Between bad habits, long-standing traditions and simple inertia, you’ll have your work cut out for you.
You’ll have to get your Web developers and business analysts to stop capturing information they don’t have a use for — and a safe place to store.
You’ll have to require that database administrators generate unique ID numbers to go along with personal data, and that programmers create query scripts that deliver only the data users need.
And in general, you’ll have to create a new culture for your IT shop — one that makes it convenient for users to handle data securely, and difficult to do what’s risky.
Yes, it’ll be a long, slow process. And no, it’s not an emergency — yet. You don’t want it to become one. So heed the warning. Get started on eliminating that insecure culture of convenience now.
After all, getting rid of 2038 cookies only took Google 10 years.
Frank Hayes is Computerworld’s senior news columnist.
