« April 2005 | Main | June 2005 »

May 31, 2005

Understanding Microsoft's PostScript print driver "PSINJECT"

Warning: this is only interesting if you write Windows printer drivers

One of my frequent projects is Windows print-driver development, and I'm getting rapidly up to speed on customizing the OEM PostScript driver. The Microsoft documentation on this is complete, in the sense that it provides mostly technically correct information, but there is very little big-picture on how it all fits together, or how one might use it to build an extension plugin.

After doing substantial researching on this, I managed to collect enough information to warrant putting into a Tech Tip. I've decoded the various injection points and shown them in the context of a full print job. I've not found anything even close to this anywhere on the internet.

• Unixwiz.net Tech Tip: Understanding Microsoft's PostScript print driver "PSINJECT"

Corrections welcome.

Posted by steve at 01:47 PM | Comments (0) | TrackBack

May 25, 2005

SBC and Privacy - Huh?

SBC's and privacy I recently called SBC (née Pac*Bell) to convert my ISDN line into just a regular POTS line. I've not made an ISDN call in years, and I only needed one phone line anyway; no need to be dependent on my trusty Motorola Bitsurfr Pro ISDN TA.

Putting aside the fact that it took hours to find the right person to take the order (and to fix it several days later), I received a confirmation of the service change via US Mail. I was shocked to see my Social Security Number in the address line in the envelope's window (click the thumbnail).

I can't see how the SSN should appear anywhere in a service confirmation order, especially since they ask me for the last four digits when I'm talking to them about it, but maybe there is actually some good reason. It doesn't appear on my monthly bill.

But there is no conceivable reason why it should appear in "cleartext" in a postal address, as if it's somehow contributing to routing through the US Mail. Because it appears inside the address, it's not just a case of private data inadvertently appearing in a window after the page shifted.

Checking the SBC Privacy Policy, they talk generally about how securely they keep my private data, but I don't see how this practice could possibly square with it. I'm going to contact SBC and see what they say about this, but I'm skeptical that I'll find anybody who even understands what this is about. Has anyone else seen this?

Update - It seems that California law explicitly forbids doing what they're doing. Thanks to Kasia for her peerless research skills, Section 1798.85(a)(5) of the Civil Code generally forbids mailing of Social Security numbers, but provides some exceptions that seem generally reasonable. But in any case:

"A social security number that is permitted to be mailed under this section may not be printed, in whole or in part, on a postcard or other mailer not requiring an envelope, or visible on the envelope or without the envelope having been opened."

It's hard to see how they might talk their way out of this one. From what I can tell, this is a self-contained "Steal Steve's Identity Kit".

Update #2 - I called SBC and got a really helpful agent; he found that some previous agent had typed my SSN in the wrong field, which he removed immediately after apologizing and agreeing that it was a bad thing. I don't think I could have asked for a better response, and this suggests a one-time screwup rather than a systemic programming issue and/or sloppy data security practice. Not sure there's really anywhere to go with this.

As an aside, why is ISDN still handled out of the Emerging Products Center? I wonder if Touch Tone is "Emerging" too?

Posted by steve at 05:14 PM | Comments (0) | TrackBack

May 02, 2005

A Proposal for Secure Storage of Credit Card Data

A customer asked for advice on how to secure their storage of customer credit card data, which to date has been done essentially in cleartext with no real protections. I was really surprised to find that there just isn't much big-picture advice, just "encrypt the database".

I'm not any kind of crypto expert, and it was frankly a little scary to go down this road even if using known-good algorithms (such as RSA), because it's really easy to do it badly. But, never one to be daunted by my own ignorance, forged ahead.

The result of this adventure is this Tech Tip, which raises issues that the others and I were able to think about. This is more about how to think of the problem in the big picture than it is about a recipe for a solution in a particular case. Indeed: I didn't touch on specific of my customer's environment.

This has circulated privately for some time now, and so far nobody has pointed out any bonehead issues, though many have made suggestions that were good but were not applicable to our environment.

With all the headlines about 50,000 or 500,000 identities being stolen due to poor information security, there ought to be a lot of enterprises thinking about this road: I hope that this paper serves as a useful starting point for them.

Feedback (including "that's a bonehead mistake") welcome.

Unixwiz.net Tech Tip: A Proposal for Secure Storage of Credit Card Data

Posted by steve at 11:41 PM | Comments (1) | TrackBack